Buridan's ass and composition configuration
Today there are few lyrics: how do we decide what falls into the basic functionality of the solution and what does not.
The theme of this text was given by the well-known (in Habré) article about 1C , which covered, among other things, the approach of a reputable corporation to the development of the functionality of box configurations.
Our platform is united with 1C by the concept of a monolith (as opposed to the modular scheme of some colleagues, which is widely known ), but the approach to the composition of the basic configuration is completely opposite to 1C.
Traditionally, first agree on the meaning of words.
All ERP systems known to the author logically consist of some kind of “platform” and an application code implemented on it - it is called a “configuration” (in 1C and in our country) or a “solution”.
All vendors known to the author (and we including) independently support the functionality of the platform and the base configuration / solution.
')
For historical reasons, at the time of entry into the market in our basic configuration, the functionality developed ever from the very beginning was fully present. Just over.
Like Lexus once: one grade, it is the maximum
And at first it was very good - we very quickly deployed solutions. However, with each new client there were new problems.
For understanding - the volume of the application code (that is, the configuration / decision code) was about 15Mb.
However, the amount of configuration code was not a problem in itself.
The problem was the gradual obsolescence of the base configuration.
In each new implementation, a new functionality appeared. It was not possible to transfer it to the base configuration due to a conflict with the previously implemented functionality.
As a natural consequence, the basic configuration was not enriched and not actualized and gradually lost in consumer properties.
On the other hand, in the process of implementation, the extensive branched functionality of the basic solution as is became a problem - most of it was completely redundant to the next implemented client, while creating new popular or updating old functions due to complex interactions was difficult (from the standpoint of an individual operator) .
As well as risky in terms of bug generation — in fact, “who served, he knows,” and for those less immersed in the topic of readers, the parallel: if you just put a stone on flat ground, there is nothing more stable in the world. And if you “just” put it on the slope of a mountain consisting of the same stones, you are very likely to get an avalanche catastrophe.
Having a designed base configuration in the manner described above, we stood in a long line of colleagues: the desire to have the most saturated basic solution functionality unites almost all ERP vendors.
Similar problems with implementations flow naturally and inevitably. The problem, in fact, is well described in that article about 1C.
Mark Twain urged: "If you are in the majority, think carefully."
When developing the second generation of the platform, we abandoned backward compatibility, so the application code, in any case, had to be written from scratch.
And - seven troubles one answer - they decided to change the approach from the “maximum” of the functional to the reverse: minimum minimorum, dear readers. Necessity on invention is cunning.
The minimum is the most laconic functionality that will be in constant or close to the form claimed by all the many future operators. Regardless of the type of business.
For ourselves, inside we call it “infrastructure functionality”: reference books of goods, customers, employees, financial documents, cost accounting, budgets, cashless payments, etc.
If this functionality becomes obsolete, it is extremely leisurely (in our practice, no significant changes have been found since 2004).
It was included in the basic configuration.
But only.
For comparison, for the second generation of Ultima Businessware platform, the amount of code for the basic configuration is 2 MB.
The advantages of this approach for implementation and support are invaluable and obvious.
However, the advantage of the richest functionality disappears (real or fictional is the subject of a separate text, but from the point of view of marketing, “rich functionality” is undoubtedly a plus).
We solve the problem of the presence of the “richest functionality” through the device of business cases: the results of implementation and operation of a logically selected functional block from an individual client .
Their combination, in some way, is an open knowledge base - including from the point of view of management decisions.
The functionality of each business case works and — most importantly — develops in the context of a real live business.
Every time a new client needs the functionality of a separate business case or its group that is not part of the infrastructure, the actual code is transferred from one project to another. Any related nishtyaki type of natural code-review is implied, but not described by virtue of triviality.
If the projects are managed by different partners, the communication can be supported by the Ultima Partner Center - but, as a rule, its intervention is not required.
Due to the hammer simplicity of the basic configuration (well, and platform development tools , of course), the external functionality is relatively easy to integrate.
Some efforts from the developer, of course, are required - but incomparably less than in the case of the implementation of the conflicting functionality.
Eventually:
PS Returning to the beginning - the complaint of the author of the article about 1C on, in his opinion, the fundamental defects of the solidity of architecture.
If cats are able to cook, monolithic architecture - ogogo!
The theme of this text was given by the well-known (in Habré) article about 1C , which covered, among other things, the approach of a reputable corporation to the development of the functionality of box configurations.
Our platform is united with 1C by the concept of a monolith (as opposed to the modular scheme of some colleagues, which is widely known ), but the approach to the composition of the basic configuration is completely opposite to 1C.
Traditionally, first agree on the meaning of words.
All ERP systems known to the author logically consist of some kind of “platform” and an application code implemented on it - it is called a “configuration” (in 1C and in our country) or a “solution”.
All vendors known to the author (and we including) independently support the functionality of the platform and the base configuration / solution.
')
For historical reasons, at the time of entry into the market in our basic configuration, the functionality developed ever from the very beginning was fully present. Just over.
Like Lexus once: one grade, it is the maximum
And at first it was very good - we very quickly deployed solutions. However, with each new client there were new problems.
For understanding - the volume of the application code (that is, the configuration / decision code) was about 15Mb.
However, the amount of configuration code was not a problem in itself.
The problem was the gradual obsolescence of the base configuration.
In each new implementation, a new functionality appeared. It was not possible to transfer it to the base configuration due to a conflict with the previously implemented functionality.
As a natural consequence, the basic configuration was not enriched and not actualized and gradually lost in consumer properties.
On the other hand, in the process of implementation, the extensive branched functionality of the basic solution as is became a problem - most of it was completely redundant to the next implemented client, while creating new popular or updating old functions due to complex interactions was difficult (from the standpoint of an individual operator) .
As well as risky in terms of bug generation — in fact, “who served, he knows,” and for those less immersed in the topic of readers, the parallel: if you just put a stone on flat ground, there is nothing more stable in the world. And if you “just” put it on the slope of a mountain consisting of the same stones, you are very likely to get an avalanche catastrophe.
Having a designed base configuration in the manner described above, we stood in a long line of colleagues: the desire to have the most saturated basic solution functionality unites almost all ERP vendors.
Similar problems with implementations flow naturally and inevitably. The problem, in fact, is well described in that article about 1C.
Mark Twain urged: "If you are in the majority, think carefully."
When developing the second generation of the platform, we abandoned backward compatibility, so the application code, in any case, had to be written from scratch.
And - seven troubles one answer - they decided to change the approach from the “maximum” of the functional to the reverse: minimum minimorum, dear readers. Necessity on invention is cunning.
The minimum is the most laconic functionality that will be in constant or close to the form claimed by all the many future operators. Regardless of the type of business.
For ourselves, inside we call it “infrastructure functionality”: reference books of goods, customers, employees, financial documents, cost accounting, budgets, cashless payments, etc.
If this functionality becomes obsolete, it is extremely leisurely (in our practice, no significant changes have been found since 2004).
It was included in the basic configuration.
But only.
For comparison, for the second generation of Ultima Businessware platform, the amount of code for the basic configuration is 2 MB.
The advantages of this approach for implementation and support are invaluable and obvious.
However, the advantage of the richest functionality disappears (real or fictional is the subject of a separate text, but from the point of view of marketing, “rich functionality” is undoubtedly a plus).
We solve the problem of the presence of the “richest functionality” through the device of business cases: the results of implementation and operation of a logically selected functional block from an individual client .
Their combination, in some way, is an open knowledge base - including from the point of view of management decisions.
The functionality of each business case works and — most importantly — develops in the context of a real live business.
Every time a new client needs the functionality of a separate business case or its group that is not part of the infrastructure, the actual code is transferred from one project to another. Any related nishtyaki type of natural code-review is implied, but not described by virtue of triviality.
If the projects are managed by different partners, the communication can be supported by the Ultima Partner Center - but, as a rule, its intervention is not required.
Due to the hammer simplicity of the basic configuration (well, and platform development tools , of course), the external functionality is relatively easy to integrate.
Some efforts from the developer, of course, are required - but incomparably less than in the case of the implementation of the conflicting functionality.
Eventually:
- Ultima solutions are easy to maintain.
In the basic configuration there is exclusively used functionality.
There is no "covered" functionality.
No sheets of settings and checks. - The functionality of the implemented solution is always relevant.
“Infrastructure” functionality does not age.
The external functionality of business cases is relevant due to the conditions of its existence - in contrast to the “rich basic solutions”, in which individual sections of the code could get a dense number of years ago and pupate.
In a running business, the functionality evolves. In a well-functioning, it evolves quickly, and under the influence of a huge number of independent actors — employees, and sometimes clients . When initially the same functionality evolves for different clients in different ways , the output is a rich palette of solutions of different efficiency for different conditions.
No vendor can ever even come close to this - for obvious reasons of principle.
PS Returning to the beginning - the complaint of the author of the article about 1C on, in his opinion, the fundamental defects of the solidity of architecture.
If cats are able to cook, monolithic architecture - ogogo!
Source: https://habr.com/ru/post/250685/
All Articles