This page is the 3rd chapter of the 4S story:
4S is an ecosystem for providers and users of open source modules for telemedicine / telehealth systems based on national (Danish) and international standards.
The intention of providing the software as individual and independent modules is fundamental to the vision of 4S. To understand the importance, compare the process of building a model of a plane in wood with the process of constructing it using LEGO®: it is clearly much easier and faster to build the model in LEGO, and perhaps more importantly, it is much faster to make changes, corrections, adaptations, and updates to the design.
Designing the software as modules with common interfaces has many advantages, as we shall see below. However, just like the development and perfection of the LEGO system of interlocking bricks has been costly and time consuming, so is the design of software modules and their interfaces. For short-lived systems (e.g. prototypes) the extra effort of breaking the system down into modules (i.e. developing the necessary “LEGO” system) is rarely worthwhile, but for more permanent systems the long-time gain outweighs the initially larger investment.
The temptation to build a “monolith” (the wooden plane) rather than a modularized system (the LEGO plane, including designing and constructing all the necessary “LEGO parts”) can be great as the initial cost is so much cheaper – especially when the software is open source, which means that the full development costs must be covered up-front. Furthermore, to the user there is no functional benefit of the modularized design compared to the monolith (you cannot tell the difference from the user interface or the functionality of the software). It is, however, important to consider the entire lifetime (total cost of ownership) of the software where such things as general maintenance, development of new features, changes in use, platforms, interfaces to other systems etc. requires continued development – which is why the modularized system wins over a longer period of time.
The following list shows some of the benefits for the users of the modularized software:
From the point-of-view of the developers of such modules (often small or medium-sized enterprises), some of the advantages of modularization are:
As mentioned on the page on ecosystems, some of the prerequisites of a healthy, thriving ecosystem is a diversity of participants and plenty of “food”. In this case, the “food” is the many different high quality modules (represented by different types of LEGO parts in the analogy above) and the diversity of participants is ensured by the benefits listed above, which improve the possibilities of the smaller enterprises and invite them to develop their own innovative products based on these modules.
A popular summary statement of the philosophy behind the Unix family of operating systems goes: "Do One Thing and Do It Well". The Unix family of operating systems (including among others: Android, Linux, OS X and iOS) have existed for almost half a century and outlived many of its younger competitors (like CP/M and MS-DOS), and to this day it remains the most popular family of operating systems on devices ranging from tiny wrist watches to the largest supercomputers. The soundness of the fundamental architectural design of these operating systems have thus been empirically proved to persevere over almost 50 years of IT evolution!
The “Do One Thing and Do It Well”-lesson from Unix underscores the point of creating reusable modules with one and only one responsibility. This has also been formulated as the "Single Responsibility Principle", which basically says that a module should have only one reason to change – if it has more than one reason, it should be partitioned. For example, to transmit some content from A to B, the content must be put in some “file” or “document” (at least one module), this document must be sent according to some transmission protocol (at least one module), and all of it must be separated from the operating system (by at least one module). So if (and only if) the document standard is changed, the first module must be changed; if (and only if) the transmission protocol is changed, the second module must be changed; and if (and only if) the operating system is changed (for instance porting to a different platform), the third module must be changed.
Another software quality related benefit from having this clear separation of responsibility between modules is that it is much easier to ensure that all functions are developed and maintained by domain experts. For instance, a security expert (or a company specialised in delivering security software) may develop and maintain security-related modules, while an Android-developer may develop and maintain the Android-specific modules.
See also the following pages:
The following pages explain the fundamental idea of 4S: