Monolith or brick?
Today there is a little philosophy about the architecture of software systems - monolithic or modular. When and which modularity is useful, whether it is always good or not. Well, more specifically about the ERP system 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 operable only in its only configuration and volume of program code. Modular system is a software package consisting of independent self-sufficient software systems.
The definition gives a little tautology, but it is impossible to draw an extremely clear boundary between modular and monolithic systems. If only because the concept of a software package does not have a clear definition. If we talk in terms of fuzzy logic, then the probability that the system is monolithic increases with a decrease in the number of external interfaces of the modules and calls to any external systems. In turn, the system is more modular than a larger number of interfaces present in the system.
Monolithic systems also differ in isolation - the data of the modules are available only to the module owners, the remaining modules receive information through external interfaces. In the case of ERP systems, this means the separation of these modules down to different DBMS for each module.
Having dealt with the definitions go to the theses.
In the realities of ERP systems, we have just such a sample - the functionality of existing, intensively interacting subsystems is changing. The cost of interruption is extremely high.
ERP systems, one of the most complex software systems created by mankind (also operating systems, games, Google and Facebook) have a need to change along with changes in business processes, which causes them to change faster than other software systems. That is why modular systems are beginning to suffer greatly from accumulating changes in exchange protocols due to the lack of formal quality control mechanisms.
Summing up, we have - modular systems are an excellent architectural solution for a stabilized 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 a monolithic architecture.
The modular architecture has either systems that are experimental in nature, or systems that have received a modular architecture as a result of a series of acquisitions and the conversion of purchased software systems into system “modules”. Such systems, as a result, have a very sophisticated functional of message exchange, interface conversion and other mechanisms for implementing the interaction between modules. In our experience, complexity grows very quickly with increasing number of modules.
Not so long ago, one of the colleagues in the article complained about the lack of modularity in 1C. I do not think that the developers of 1C would be glad of the abundance of various checks about the presence of a particular module. Only companies supporting 1C would be pleased that now it is necessary to configure not one program, but several modules at once, and also some middle-ware of their integration.
We turn to the features of modular ERP-systems where the modules are accounting, warehouse, financial management, staff, etc.
At a minimum, the ERP system should reflect the real situation in the company. For example - how many goods are in stock. Or how much money in the current account. The modular system, due to the weak connectivity and isolation of the modules, is rapidly slipping into duplication of information. And further to the discrepancy of indicators.
For example - the warehouse module deducts 10 pieces of goods from the warehouse. The financial module must write off their cost as a separate transaction. However, in the course of work, there appear to be minor events like a channel failure, a change in the exchange protocol. After some time, it turns out that there is no product in the warehouse - zero pieces, and in the data of the financial module of this product in the warehouse lies a hundred rubles. As a result, a special correction appears in the financial module, and further, such errors propagate through the system. In monolithic systems, writing off from a warehouse is a single operation (in our case, a single record) about the movement of money and commodity units, which significantly increases the reliability of the data.
The data of monolithic systems lie in a single database, all the rules of referential integrity are executed for them, and the change in the data structure is the same for the entire system. Therefore, the probability of data corruption is significantly reduced, not to mention the appearance of several variants of reality.
Finally.
Among developers (as well as among any people and even birds, there are many irrational prejudices. Among them is about the architecture of software systems, that modularity and weak connectivity are better than solidity. As an essence.
PS If anyone is interested, a critical look at the problems of modularity from the point 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 operable only in its only configuration and volume of program code. Modular system is a software package consisting of independent self-sufficient software systems.
The definition gives a little tautology, but it is impossible to draw an extremely clear boundary between modular and monolithic systems. If only because the concept of a software package does not have a clear definition. If we talk in terms of fuzzy logic, then the probability that the system is monolithic increases with a decrease in the number of external interfaces of the modules and calls to any external systems. In turn, the system is more modular than a larger number of interfaces present in the system.
Monolithic systems also differ in isolation - the data of the modules are available only to the module owners, the remaining modules receive information through external interfaces. In the case of ERP systems, this means the separation of these modules down to different DBMS for each module.
Having dealt with the definitions go to the theses.
- The advantage of 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 parts.
Perhaps at the beginning of the history of computer technology and there were problems with placing the entire program on the equipment, but such problems disappeared as a class. And now there is no problem to place the entire software complex on the hardware. The advantages of supplying the system with modules are obvious to the seller, and absolutely not obvious to the buyer. However, this is a somewhat separate topic, referring to it to our article . - • Modular systems are easy to maintain. In fact, in a modular system it is easy to create new modules. However, modular systems fail when a significant change in the functionality of two or more interacting modules is required. Weak connectivity becomes a problem not allowing to test at the compilation stage.
In the realities of ERP systems, we have just such a sample - the functionality of existing, intensively interacting subsystems is changing. The cost of interruption is extremely high.
ERP systems, one of the most complex software systems created by mankind (also operating systems, games, Google and Facebook) have a need to change along with changes in business processes, which causes them to change faster than other software systems. That is why modular systems are beginning to suffer greatly from accumulating changes in exchange protocols due to the lack of formal quality control mechanisms.
Summing up, we have - modular systems are an excellent architectural solution for a stabilized 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 a monolithic architecture.
The modular architecture has either systems that are experimental in nature, or systems that have received a modular architecture as a result of a series of acquisitions and the conversion of purchased software systems into system “modules”. Such systems, as a result, have a very sophisticated functional of message exchange, interface conversion and other mechanisms for implementing the interaction between modules. In our experience, complexity grows very quickly with increasing number of modules.
Not so long ago, one of the colleagues in the article complained about the lack of modularity in 1C. I do not think that the developers of 1C would be glad of the abundance of various checks about the presence of a particular module. Only companies supporting 1C would be pleased that now it is necessary to configure not one program, but several modules at once, and also some middle-ware of their integration.
We turn to the features of modular ERP-systems where the modules are accounting, warehouse, financial management, staff, etc.
At a minimum, the ERP system should reflect the real situation in the company. For example - how many goods are in stock. Or how much money in the current account. The modular system, due to the weak connectivity and isolation of the modules, is rapidly slipping into duplication of information. And further to the discrepancy of indicators.
For example - the warehouse module deducts 10 pieces of goods from the warehouse. The financial module must write off their cost as a separate transaction. However, in the course of work, there appear to be minor events like a channel failure, a change in the exchange protocol. After some time, it turns out that there is no product in the warehouse - zero pieces, and in the data of the financial module of this product in the warehouse lies a hundred rubles. As a result, a special correction appears in the financial module, and further, such errors propagate through the system. In monolithic systems, writing off from a warehouse is a single operation (in our case, a single record) about the movement of money and commodity units, which significantly increases the reliability of the data.
The data of monolithic systems lie in a single database, all the rules of referential integrity are executed for them, and the change in the data structure is the same for the entire system. Therefore, the probability of data corruption is significantly reduced, not to mention the appearance of several variants of reality.
Finally.
Among developers (as well as among any people and even birds, there are many irrational prejudices. Among them is about the architecture of software systems, that modularity and weak connectivity are better than solidity. As an essence.
PS If anyone is interested, a critical look at the problems of modularity from the point of view of the operator.
Source: https://habr.com/ru/post/246299/
All Articles