What is the difference between a crow and a desk Or the difference between “theirs” modules and “our” components
Actually, this text serves as a development of the topic about the comparative advantages of modular and monolithic systems .
Educational practice has once again given rise to an interesting question. “Well, why are you vainly scourging the flaws of modular systems , and you are selling components yourself . What is the difference, actually? ”
Fiercely, in solidarity with Solidarity with Descartes, we first agree on the meaning of the words.
What is a module.
NB: hereinafter it is exclusively in the context of the conceptual apparatus of ERP-systems.
So, a “module” is a system functionality that has its own data processing logic and implements a block of business processes within itself .
The module can be implemented as a separate application, or be part of another.
The module is weakly dependent on the rest of the system (in fact, the totality of the remaining modules).
A module can either have a separate storage for data (the need for synchronization with the main data storage follows), and create its own structures in the main storage.
An abstract example is the storage module.
It assumes the presence of some logic for storing data. In the spirit of the shelf on which a particular product lies, etc.
Therefore, the warehouse module must have the following directories (shelves etc).
If the warehouse module is implemented as a separate application (historically, in many cases, by acquiring a company that produced warehouse software), then it will store the data in its own storage, and in one way or another replicate to the main storage.
However, it can immediately work with the main repository, this is actually not so important.
Components.
A component for the Ultima Businessware platform is a stand-alone application that integrates with the platform using one protocol or another (REST API, SOAP, or its own binary protocol).
The component does not store primary data in its system, but always transfers it to the central system . The component acts as a "data store" or client application in relation to the application server.
Primary data - business-relevant data generated by users of the system (including customers through external interfaces). For example, the contents of the waybill, delivery address, payment date, etc.
The component, unlike the module, does not have its own business logic , sharing the code that implements business logic (encapsulated, as in any system of a full 3-tier architecture, inside the application server) with all other parts of the system.
A component may have its own data store, but it is used exclusively for caching information.
For example, the engine for creating online stores Ultima eStoreIt has its own mini-database for intermediate storage of price cache, stock balances and description of goods. But only.
When registering users or creating an order in the eStore mini-database, no data remains; they are transmitted online through the application server to the main storage. Therefore, we note in parentheses that the procedure for creating a client when registering on the website independently or by the operator when calling the call center / seller in the store is absolutely identical, the difference is only in the interface used.
A slightly different option for using local storage is observed in the case of the component for warehouse automation Ultima MobileWMS .
Operating conditions require the maximum speed of processing a scanned barcode - therefore, wherever possible, the database of barcode residues is loaded into local storage.
The data of the local storage is used solely to answer the question: does the scanned barcode belong to the right product, yes \ no. Due to caching in local storage, you can quickly report typing errors. The “correct” barcode is sent to the application server, further processing is carried out according to the general business logic of the system.
But the component for the Ultima Door-to-Door salesman or the Ultima MobileView mobile viewer / signer does not have a local storage at all in any way.
Because there is no need: operational requirements make it possible to work directly with a central database.
Thus, Ultima Businessware components, on the one hand,
and on the other,
As a result, development and testing is significantly simplified and accelerated. Speaking in money, the support of the system as a whole becomes cheaper, and at the same time it is not at the expense of quality.
Formulating from the point of view of the consumer, the component approach allows you to get all the pluses of the modules without their minuses - that is, completely preserving the solidity of the architecture as a whole.
Educational practice has once again given rise to an interesting question. “Well, why are you vainly scourging the flaws of modular systems , and you are selling components yourself . What is the difference, actually? ”
Fiercely, in solidarity with Solidarity with Descartes, we first agree on the meaning of the words.
What is a module.
NB: hereinafter it is exclusively in the context of the conceptual apparatus of ERP-systems.
So, a “module” is a system functionality that has its own data processing logic and implements a block of business processes within itself .
The module can be implemented as a separate application, or be part of another.
The module is weakly dependent on the rest of the system (in fact, the totality of the remaining modules).
A module can either have a separate storage for data (the need for synchronization with the main data storage follows), and create its own structures in the main storage.
An abstract example is the storage module.
It assumes the presence of some logic for storing data. In the spirit of the shelf on which a particular product lies, etc.
Therefore, the warehouse module must have the following directories (shelves etc).
If the warehouse module is implemented as a separate application (historically, in many cases, by acquiring a company that produced warehouse software), then it will store the data in its own storage, and in one way or another replicate to the main storage.
However, it can immediately work with the main repository, this is actually not so important.
Components.
A component for the Ultima Businessware platform is a stand-alone application that integrates with the platform using one protocol or another (REST API, SOAP, or its own binary protocol).
The component does not store primary data in its system, but always transfers it to the central system . The component acts as a "data store" or client application in relation to the application server.
Primary data - business-relevant data generated by users of the system (including customers through external interfaces). For example, the contents of the waybill, delivery address, payment date, etc.
The component, unlike the module, does not have its own business logic , sharing the code that implements business logic (encapsulated, as in any system of a full 3-tier architecture, inside the application server) with all other parts of the system.
A component may have its own data store, but it is used exclusively for caching information.
For example, the engine for creating online stores Ultima eStoreIt has its own mini-database for intermediate storage of price cache, stock balances and description of goods. But only.
When registering users or creating an order in the eStore mini-database, no data remains; they are transmitted online through the application server to the main storage. Therefore, we note in parentheses that the procedure for creating a client when registering on the website independently or by the operator when calling the call center / seller in the store is absolutely identical, the difference is only in the interface used.
A slightly different option for using local storage is observed in the case of the component for warehouse automation Ultima MobileWMS .
Operating conditions require the maximum speed of processing a scanned barcode - therefore, wherever possible, the database of barcode residues is loaded into local storage.
The data of the local storage is used solely to answer the question: does the scanned barcode belong to the right product, yes \ no. Due to caching in local storage, you can quickly report typing errors. The “correct” barcode is sent to the application server, further processing is carried out according to the general business logic of the system.
But the component for the Ultima Door-to-Door salesman or the Ultima MobileView mobile viewer / signer does not have a local storage at all in any way.
Because there is no need: operational requirements make it possible to work directly with a central database.
Thus, Ultima Businessware components, on the one hand,
- allow you to take out specific specific professional functionality (by and large, a special interface)
and on the other,
- do not lead to the sad consequences characteristic of classical modular systems. Described, in turn, in articles, links to which have already been given above.
As a result, development and testing is significantly simplified and accelerated. Speaking in money, the support of the system as a whole becomes cheaper, and at the same time it is not at the expense of quality.
Formulating from the point of view of the consumer, the component approach allows you to get all the pluses of the modules without their minuses - that is, completely preserving the solidity of the architecture as a whole.