Buridanov donkey and configuration composition
Today is a bit of lyrics: how do we decide what falls into the basic functionality of the solution and what does not.
The topic of this text was given by the well-known (on the Habré) article about 1C , highlighting, among other things, the approach of a respected corporation to the development of the functionality of boxed configurations.
Our platform is united with 1C by the concept of monolith (as opposed to the modular scheme of some colleagues, which is well known ), but the approach to composition of the basic configuration is completely opposite in comparison with 1C.
Traditionally, we first agree on the meaning of the words.
All ERP systems known to the author logically consist of a certain “platform” and application code implemented on it - it is called a “configuration” (in 1C and ours) or a “solution”.
All vendors known to the author (including us) independently support the functionality of the platform and the basic configuration / solution.
For historical reasons, at the time of entering the market in our basic configuration, the functionality developed ever from the very beginning was fully present. A little more than that.
Like Lexus once: the equipment is the same, it’s the maximum.
And at first it was very good - we quickly deployed the solutions. However, with each new client, new problems arose.
For understanding - the volume of the applied code (that is, the configuration / solution code) was about 15 MB.
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, new functionality arose. It was not possible to transfer it to the basic configuration due to a conflict with previously implemented functionality.
As a natural consequence, the basic configuration was not enriched or updated and gradually lost in consumer properties.
On the other hand, in the process of implementation, the extensive extensive functionality of the basic solution as is became a problem - most of it was completely redundant for the next client being deployed, while creating new features or updating old functions due to complex interactions was unjustified (from the point of view of an individual operator) difficult .
It’s also risky in terms of bug generation - in fact, “those who served know it,” but for less readers who are less interested in the topic, there’s a parallel: if you just lay 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 likely to get an avalanche disaster.
Having in our hands the above-described basic configuration, we stood in a long line of colleagues: the desire to have the most saturated functionality of the basic solution unites almost all ERP vendors.
Similar problems with implementations arise naturally and inevitably. The problem, in fact, is well described in that very article about 1C.
Mark Twain called: “If you are in the majority - think carefully.”
When developing the second generation of the platform, we refused 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 “maximum” functionality to the opposite: minimum minimorum, dear readers. Goal for fiction is cunning.
Minimum is the most concise functional that will be in constant or close to that form demanded by all the many future operators. Regardless of the type of business.
For ourselves, we call it “infrastructure functionality”: directories of goods, customers, employees, financial documents, cost accounting, budgets, cashless payments, etc.
Such functionality, if it becomes obsolete, is extremely leisurely (in our practice, no significant changes have been detected since 2004).
He was included in the basic configuration.
But only.
For comparison, for the second generation of the Ultima Businessware platform, the volume of the basic configuration code 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 - 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 availability of “rich functionality” through the apparatus of business cases: the results of the implementation and operation of a logically allocated functional block for an individual client .
Their combination, in a way, is an open knowledge base - including in terms of managerial decisions.
The functionality of each business case works and - what is especially important - develops in a real living business.
Each time a new client requires the functionality of a separate business case or its group, which is not part of the infrastructure, the actual code is transferred from one project to another. Any associated nishtyaki type of natural code review are implied, but not described due to triviality.
If the projects are managed by different partners, communication can be supported by the Ultima Partnership Center - but, as a rule, its intervention is not required.
Because the basic configuration of the hammer simplicity (well, and means of development platforms , of course) with respect to outer functional easily integrated.
Of course, some efforts are required from the developer - but incomparably less than in the case of the implementation of conflicting functionality.
Eventually:
PS Returning to the beginning - the author’s complaints about the 1C article on, in his opinion, fundamental flaws in the monolithic architecture.
If cats can cook, monolithic architecture is awesome!
The topic of this text was given by the well-known (on the Habré) article about 1C , highlighting, among other things, the approach of a respected corporation to the development of the functionality of boxed configurations.
Our platform is united with 1C by the concept of monolith (as opposed to the modular scheme of some colleagues, which is well known ), but the approach to composition of the basic configuration is completely opposite in comparison with 1C.
Traditionally, we first agree on the meaning of the words.
All ERP systems known to the author logically consist of a certain “platform” and application code implemented on it - it is called a “configuration” (in 1C and ours) or a “solution”.
All vendors known to the author (including us) independently support the functionality of the platform and the basic configuration / solution.
For historical reasons, at the time of entering the market in our basic configuration, the functionality developed ever from the very beginning was fully present. A little more than that.
Like Lexus once: the equipment is the same, it’s the maximum.
And at first it was very good - we quickly deployed the solutions. However, with each new client, new problems arose.
For understanding - the volume of the applied code (that is, the configuration / solution code) was about 15 MB.
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, new functionality arose. It was not possible to transfer it to the basic configuration due to a conflict with previously implemented functionality.
As a natural consequence, the basic configuration was not enriched or updated and gradually lost in consumer properties.
On the other hand, in the process of implementation, the extensive extensive functionality of the basic solution as is became a problem - most of it was completely redundant for the next client being deployed, while creating new features or updating old functions due to complex interactions was unjustified (from the point of view of an individual operator) difficult .
It’s also risky in terms of bug generation - in fact, “those who served know it,” but for less readers who are less interested in the topic, there’s a parallel: if you just lay 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 likely to get an avalanche disaster.
Having in our hands the above-described basic configuration, we stood in a long line of colleagues: the desire to have the most saturated functionality of the basic solution unites almost all ERP vendors.
Similar problems with implementations arise naturally and inevitably. The problem, in fact, is well described in that very article about 1C.
Mark Twain called: “If you are in the majority - think carefully.”
When developing the second generation of the platform, we refused 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 “maximum” functionality to the opposite: minimum minimorum, dear readers. Goal for fiction is cunning.
Minimum is the most concise functional that will be in constant or close to that form demanded by all the many future operators. Regardless of the type of business.
For ourselves, we call it “infrastructure functionality”: directories of goods, customers, employees, financial documents, cost accounting, budgets, cashless payments, etc.
Such functionality, if it becomes obsolete, is extremely leisurely (in our practice, no significant changes have been detected since 2004).
He was included in the basic configuration.
But only.
For comparison, for the second generation of the Ultima Businessware platform, the volume of the basic configuration code 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 - 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 availability of “rich functionality” through the apparatus of business cases: the results of the implementation and operation of a logically allocated functional block for an individual client .
Their combination, in a way, is an open knowledge base - including in terms of managerial decisions.
The functionality of each business case works and - what is especially important - develops in a real living business.
Each time a new client requires the functionality of a separate business case or its group, which is not part of the infrastructure, the actual code is transferred from one project to another. Any associated nishtyaki type of natural code review are implied, but not described due to triviality.
If the projects are managed by different partners, communication can be supported by the Ultima Partnership Center - but, as a rule, its intervention is not required.
Because the basic configuration of the hammer simplicity (well, and means of development platforms , of course) with respect to outer functional easily integrated.
Of course, some efforts are required from the developer - but incomparably less than in the case of the implementation of conflicting functionality.
Eventually:
- Ultima solutions are easy to maintain.
In the basic configuration there is exclusively used functionality.
There is no "hidden" functionality.
There are no sheets of settings and checks. - The functionality of the implemented solution is always relevant.
“Infrastructure” functionality does not age.
The external functionality from business cases is relevant due to the conditions of its existence - as opposed to “rich basic solutions”, into which individual sections of the code could get a prime number of years ago and pupate.
In a running business, functionality is evolving. When it works well, it evolves quickly, and under the influence of a huge number of independent actors - employees, and sometimes customers . When initially the same functionality evolves in different ways in different clients, the output is a rich palette of solutions of various efficiencies for different conditions.
No vendor can ever even come close to this - for obvious reasons of a fundamental nature.
PS Returning to the beginning - the author’s complaints about the 1C article on, in his opinion, fundamental flaws in the monolithic architecture.
If cats can cook, monolithic architecture is awesome!