If you ask any software architect, how he/she imagines an ideal architecture of his/her system, you would definitely hear – “a one built from modules”. The modules cooperate with each other, this one is responsible for that, that one for that etc. Probably no one would say that the preferable choice would be a spaghetti architecture. There are some very strong reasons behind the modularity. Interestingly, not all those reasons are technical. Some of them are more political which means that some part of the popularity is gained because of the impression made by presentations for management.

Replaceable components

Substantial majority of the modern software languages supports, encourages and even enforces us (software developers) to build our software as a construction made from components. Software architects do the same. Nowadays, it is like an obvious truth which does not need to be justified that an ideal software architecture should look like the one below.

Some time ago, I heard on one of the software conferences that a good architecture diagram always is a mixture of blocks and arrows. It was going to be funny that time and it actually was, but a serious conclusion was – people think it is good if software consists of modules.

Why modules seem to be so good? There are multiple reasons, some of them are:

1. Easier maintenance.
   Components can have different and separate responsibilities. If sending emails has a defect, you can look for a problem in an email sender component as it is the one which actually sends emails.
2. Cheaper development.
   If you develop a new functionality and at some point of data processing it requires to send some emails, you know you do not need to write everything yourself because there is already a component that probably does exactly that. It is substantial enhancement as it probably covers not only a happy path (sending emails) but also errors handling, gathering statistics, queueing etc.
3. Makes refactoring or modular rewrite possible.
   I am sure you have seen software that is a spaghetti code. Where everything is connected to everything, the same code is written multiple times in different parts of the system. Can you imagine fixing such architecture? Introducing queueing and asynchronous sending emails in the whole system? I do not think so. If a software is consisted of components and they have well defined responsibilities and interfaces, you can add queueing to the email sender module or even rewrite it from scratch and it will be doable task because how big that module can be? It is not even close to the size of the whole system.

Generally, I agree on the points above. Obviously, real life is not that simple. It might be difficult to keep responsibility separation, developing modules can be more expensive in a short run but it can be treated as an investment for the future maintenance.

That is great, but …

If a system is modular, theoretically each module can be replaced with a new one. The new one can be written by you, a team from your company, outsourced or even some existing commercial or open source library can be used. It is theoretically extremely easy if the module provides standard widely-known interfaces. Then it can be replaced with another one that applies the same standards. A good example is a message queue in Java. At some point the JMS specification was created. Multiple providers adopted it like Apache ActiveMQ, Oracle WebLogic, JBoss Messaging, WebSphere MQ and many other. Theoretically, if you use one of them in your system, you can easily replace it in the future with any other that is cheaper or more reliable. It seems great, doesn’t it? If you are tired fighting with defects of one implementation or licensing cost became unacceptable, you can change the vendor.

It supposed to be as simple as that. In practice, it is not. In spite of the standards, there are some differences between the queueing systems that makes the replacing task difficult … The world was going to be so beautiful …

Last word

Creating modules we believe that we will take a serious advantage of them by replacing one at some point in time. In practice … I do not think that happens often. I can bet that if you face a problem forcing you to make a significant change in the code, you would rather rewrite the whole of it instead trying to replace one part which would eventually not be that easy.

Of course, no matter whether we take real advantage of the possibilities offered by the modular architecture or not, they are catchy slogans for management that really likes to hear about investments, reusing and replacing components because it means cost saving in the future.

In my opinion, the modular architecture is a big achievement of IT industry which is worth adopting but it is very easy to incorrectly assign some advantages to it which are almost never used in real development life.

You might wonder, why I care. So … I care because there is a straight path from talking about the modular architecture and writing database agnostic software.