Site Tools


introduction:modules

...modules...

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.

"Me163S 7" by Jürgen Klüser. License: CC BY-SA"Updated Mustang" by Mike (https://www.flickr.com/photos/pmiaki/). License: CC-BY

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.

Ecosystem Participant Benefits

The following list shows some of the benefits for the users of the modularized software:

  • Lower (long term) maintenance and development costs. As explained by the LEGO plane analogy above, it is easier to handle changes to small modules than to the entire system. Also, modules may be re-used – by the same system as well as other (perhaps future) systems. This implies that there may be more contributors sharing the cost of maintaining the module. Furthermore, when developing the next system (in the LEGO analogy it could be e.g. a car or a house), some of the pieces are already at hand.
  • Avoiding rusting monoliths. Over time, any system will tend to grow deep roots in an organization. Furthermore, over time, software “rusts” – i.e. becomes outdated, only runs on old hardware, becomes incompatible with new systems, or doesn't support “the next big thing”. A rusty monolith with deep roots in an organization can be a huge and expensive challenge. With a modularized system, on the other hand, continually exchanging the rusty parts with new parts keeps the system up-to-date. Furthermore, in many situations, the modularized architecture can be leveraged to avoid major “big-bang” system changes (with the inherent risk of big-bang failure) as the architecture encourages a “small-step” and “natural” evolution.
  • Wider selection of (SME) providers. As the modularized system separates concerns and the need for specialized knowledge into individual modules, the task of modifying, replacing, adding, or removing a single module requires less effort and less knowledge about the entire system. This means that smaller teams can handle these tasks, and it is easier to assign such tasks to new teams who have had no prior experience with the system. Therefore smaller providers (perhaps single individuals or small enterprises) can handle such tasks – and of course this means that it is possible to reduce the extend of contracts, having many small low-risk contracts rather than a few big high-risk contracts. For public purchasers the additional advantage of this strategy may be to keep the contract price-tags below the EU public procurement de minimis thresholds – reducing the administration overhead of both purchaser and contractor.

From the point-of-view of the developers of such modules (often small or medium-sized enterprises), some of the advantages of modularization are:

  • Gentle learning curve. The amount of context to learn before initiating a task is much better delimited – and there is likely less context as well as less complexity.
  • Isolate the need for specialist-knowledge. As explained on the page about standards, there are literally dozens of standards for document formats and data exchange between telemedicine IT systems. For smaller enterprises, it is not realistic to have in-house practical experience with all these standards and interfaces. However, just as JPEG image or MP3 audio files can be handled by dedicated modules by anyone (with no knowledge about image or audio compression techniques), the standards of telemedicine data exchange can be packaged into software modules by specialists, so that everybody else do not need to acquaint themselves with all these standards and interfaces.
  • Isolation of critical elements for certification. Some software functions may be more critical than others, for instance software that classifies measurements or assists in clinical decision-making would be more critical than the software that paints graphical elements on the screen. The critical software parts require a lot more scrutiny and testing as well as a meticulous development process. As these software parts are isolated in dedicated modules, the thorough and time-consuming processes would apply only to these modules rather than all the software.

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.

Software Quality Benefits

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.

Learn More

introduction/modules.txt · Last modified: 2018/12/12 13:27 (external edit)