Consider a software which runs on a dedicated system (basically a Linux box), and controls some machinery. The system has all the required hardware interfaces for the task. The software also has a GUI for controlling said machinery.
However, this system should later be able to be used from external devices, so other software, using the same or similar GUI will be running on various PCs, smartphones, etc. The central SW will contain a TCP server through which the external devices will connect. The central device with its software is to be developed first, and the controlability from external devices will be a later add-on.
My proposal for the "central" software would be to split it into two separate programs. One would be a server without any GUI at all, which will handle all the controlling and hardware interfacing stuff, and a separate software would fulfill solely the roles of the GUI.
Of course, a good MVC separation is possible even within a single program, but the main advantage I see for splitting the program is that the GUI part will be much more easily portable to other systems. Actually, in case of a PC as an external device, the same software can be re-used 100%. For other systems, I guess it would be much easier to port a program 1 to 1, than to port only the GUI part of a more complex program.
The main disadvantage of this solution is that the initial system will be a more complicated, as the GUI needs to communicate via TCP with the controlling part, instead of directly inside the same program.
Are there other major advantages and disadvantages of splitting the application in two separate programs communicating over TCP?
The scope of the project is up to 2 years for a small, 2-3 person team.