Monolith or brick?
Today there is a little philosophy about the architecture of software systems - monolithic or modular. When and what modularity is useful, is it always good or not. Well, and more specifically about ERP systems as a topic close to us.
Definitions.
Before fanning the flames of controversy, it is necessary to agree on definitions.
A monolithic system is a software package that is operational only in its only configuration and amount of program code. A modular system is a software package consisting of independent, self-contained software systems.
Definition gives a little tautology, but it is impossible to draw an extremely clear line between modular and monolithic systems. If only because the concept of a software system does not have a clear definition. In terms of fuzzy logic, the probability that the system is monolithic increases with a decrease in the number of external interfaces of modules and calls to any external systems. In turn, the system is more modular than the greater number of interfaces present in the system.
Monolithic systems also differ in isolation - the data of the modules are available only to the owner modules, the rest of the modules receive information through external interfaces. In the case of ERP systems, this means the separation of these modules up to different DBMSs for each module.
Having dealt with the definitions, we move on to the theses.
In the realities of ERP systems, we have just such an example - the functionality of existing, intensively interacting subsystems is changing. The cost of disruption is extremely high.
ERP systems, one of the most complex software systems created by mankind (also OSes, games, Google and Facebook) have a need to change along with changing business processes, which makes them change faster than other software systems. That is why, modular systems begin to suffer greatly from the accumulating changes in the exchange protocols due to the lack of formal quality control mechanisms.
To summarize, we have - modular systems are an excellent architectural solution for a stable application, in a stable environment where only an increase in the functionality of the system is required, in the form of creating NEW functions.
More or less modern, actually used systems (created after 1995) have a monolithic architecture, or gravitate to a monolithic architecture.
Modular architecture has either experimental systems or systems that have received a modular architecture as a result of a series of acquisitions and the conversion of purchased software systems into “modules” of the system. Such systems, in the end, have very sophisticated functionality for exchanging messages, converting interfaces, and other mechanisms for implementing interaction between modules. In our experience, complexity grows very rapidly with the number of modules.
Not so long ago, one of the colleagues in the articlecomplained about the lack of modularity in 1C. I do not think that 1C developers would be happy with an abundance of all kinds of checks about the presence of one or another module. Only companies supporting 1C would be glad that now it is necessary to configure not one program, but several modules at once, and even some middle-ware of their integration.
Let's move on to the features of modular ERP-systems where the modules are accounting, warehouse, financial management, employees, etc.
At a minimum, the ERP system should reflect the real situation in the company. For example - how much product is in stock. Or how much money is in the current account. The modular system, due to the loosely coupled and isolated modules, quickly rolls to duplication of information. And further to the divergence of indicators.
For example, a warehouse module writes off 10 pieces of goods from a warehouse. The financial module must write off their value in a separate transaction. However, in the process of work, insignificant events appear - channel failure, change in the exchange protocol. After some time, it turns out that the goods are not in stock - zero pieces, and in the data of the financial module of this goods in stock lies one hundred rubles. As a result, a special correction appears in the financial module, and further, such errors propagate through the system. In monolithic systems, write-off from a warehouse is a single operation (in our case, a single record) about the movement of money and units of goods, which significantly increases the reliability of the data.
The data of monolithic systems are in a single database, all referential integrity rules are followed for them, and changing the data structure is the same for the entire system. Therefore, the likelihood of data corruption is significantly reduced, not to mention the emergence of several options for reality.
Finally.
Among developers (as well as among any people and even birds, there are many irrational prejudices. Among them are the architecture of software systems that modularity and weakly-connectedness are better than monolithicity. As an entity.
PS If you are interested, take a critical look at the problems of modularity from the point of view of view of the operator.
Definitions.
Before fanning the flames of controversy, it is necessary to agree on definitions.
A monolithic system is a software package that is operational only in its only configuration and amount of program code. A modular system is a software package consisting of independent, self-contained software systems.
Definition gives a little tautology, but it is impossible to draw an extremely clear line between modular and monolithic systems. If only because the concept of a software system does not have a clear definition. In terms of fuzzy logic, the probability that the system is monolithic increases with a decrease in the number of external interfaces of modules and calls to any external systems. In turn, the system is more modular than the greater number of interfaces present in the system.
Monolithic systems also differ in isolation - the data of the modules are available only to the owner modules, the rest of the modules receive information through external interfaces. In the case of ERP systems, this means the separation of these modules up to different DBMSs for each module.
Having dealt with the definitions, we move on to the theses.
- The advantage of a modular system is the ability to increase the functionality of the system by adding new modules.
What does this really mean? That the recipient of the system receives the system in parts.
Perhaps at the beginning of the history of computer technology there were problems with placing the entire program on equipment, but such problems disappeared as a class. And now there is no problem placing the entire software package on equipment. The advantages of delivering the system with modules are obvious to the seller, and not at all obvious to the buyer. However, this is a somewhat separate topic, for it I refer to our article . - • Modular systems are easy to maintain. In fact, it is easy to create new modules in a modular system. However, modular systems fail when a significant change in the functionality of two or more interacting modules is required. Weak connectivity becomes a problem that does not allow testing at the compilation stage.
In the realities of ERP systems, we have just such an example - the functionality of existing, intensively interacting subsystems is changing. The cost of disruption is extremely high.
ERP systems, one of the most complex software systems created by mankind (also OSes, games, Google and Facebook) have a need to change along with changing business processes, which makes them change faster than other software systems. That is why, modular systems begin to suffer greatly from the accumulating changes in the exchange protocols due to the lack of formal quality control mechanisms.
To summarize, we have - modular systems are an excellent architectural solution for a stable application, in a stable environment where only an increase in the functionality of the system is required, in the form of creating NEW functions.
More or less modern, actually used systems (created after 1995) have a monolithic architecture, or gravitate to a monolithic architecture.
Modular architecture has either experimental systems or systems that have received a modular architecture as a result of a series of acquisitions and the conversion of purchased software systems into “modules” of the system. Such systems, in the end, have very sophisticated functionality for exchanging messages, converting interfaces, and other mechanisms for implementing interaction between modules. In our experience, complexity grows very rapidly with the number of modules.
Not so long ago, one of the colleagues in the articlecomplained about the lack of modularity in 1C. I do not think that 1C developers would be happy with an abundance of all kinds of checks about the presence of one or another module. Only companies supporting 1C would be glad that now it is necessary to configure not one program, but several modules at once, and even some middle-ware of their integration.
Let's move on to the features of modular ERP-systems where the modules are accounting, warehouse, financial management, employees, etc.
At a minimum, the ERP system should reflect the real situation in the company. For example - how much product is in stock. Or how much money is in the current account. The modular system, due to the loosely coupled and isolated modules, quickly rolls to duplication of information. And further to the divergence of indicators.
For example, a warehouse module writes off 10 pieces of goods from a warehouse. The financial module must write off their value in a separate transaction. However, in the process of work, insignificant events appear - channel failure, change in the exchange protocol. After some time, it turns out that the goods are not in stock - zero pieces, and in the data of the financial module of this goods in stock lies one hundred rubles. As a result, a special correction appears in the financial module, and further, such errors propagate through the system. In monolithic systems, write-off from a warehouse is a single operation (in our case, a single record) about the movement of money and units of goods, which significantly increases the reliability of the data.
The data of monolithic systems are in a single database, all referential integrity rules are followed for them, and changing the data structure is the same for the entire system. Therefore, the likelihood of data corruption is significantly reduced, not to mention the emergence of several options for reality.
Finally.
Among developers (as well as among any people and even birds, there are many irrational prejudices. Among them are the architecture of software systems that modularity and weakly-connectedness are better than monolithicity. As an entity.
PS If you are interested, take a critical look at the problems of modularity from the point of view of view of the operator.