June 20, 2013 at 10:27BRMS 150 years ago and today: decision rule repositories
Attempts to master the business logic for IT systems began in our country around the 1820s. Then one of the founders of Russian cybernetics, a state adviser (and the son of a colonel engineer) Semen Nikolaevich Korsakov did two of these things: A
straightforward homeoscope
Simple comparator
This is what we would today call the mechanical rudiments of modern expert systems.Remember the news that IBM spreads its artificial intelligence to hospitals? So, S. N. Korsakov began to do something similar at least 150 years before. His idea was extremely simple: you need to distribute the devices to the doctors in the field, and then the doctors will be able to accumulate experience together, not make common mistakes and generally treat by standards. The comparator served as a means of differential diagnostics, and a simpler homeoscope could act as an automaton, where the doctor entered the symptoms and received the disease at the exit.
That is, in other words, Korsakov tried to create a repository of medical knowledge and a rule management system . Because I did not believe that the same diseases would be treated in all corners of the country equally effectively and accurately.
Modern business processes in many ways resemble the work of such a mechanical device. For example, a rule may work for a bank: if a client has been using the services for more than 3 years (they moved one lever) and the amount of his account is more than 3 million rubles (they moved the second), then he should be considered a VIP-client (the system concluded). Another example of a business rule is if the amount of the contract is more than $ 300,000, then agreement with the financial director is necessary.
Now imagine that you are running a large bank or insurance company. You have a problem with making local decisions very randomly. As rural doctors will use 100 of their own custom approaches to patients with the same problem, each of your departments will decide whether to grant a loan or risk assessment almost by the phase of the moon. Of course, the first thought is to introduce clear rules based on heuristics or linear comparisons.
So, it is for the implementation of these rules that BRMS systems are used. The beauty is that these are now not Excel tablets, not the opinion of the commercial director of the branch and not the advice of a colleague, but specific mechanics. The company’s business rules are maintained in a single repository in a user-friendly way. Enterprise systems invoke the calculation of rules from BRMS and get the result.
At the same time, business users change the rules without IT, and these rules can change really quickly without coding. All systems always use a single version of the rules. There is control of mandatory compliance with the rules.
Why is it important?Well, for example, I know of one large retail network where only custom development is used for automation. To do this, they have a regional development office, where 200+ developers sit. Business is growing rapidly, and management rightly considers flexibility one of the important competitive advantages. Therefore, if necessary, change something in business processes or business rules, even in small things, they sit down at their code and quickly rewrite it. The complexity of making changes is growing, and deadlines are always tight, so crutches are often piled up. Of course, such a system is extremely unstable. Plus you have to be almost an archaeologist to reuse the code that was once written. I think you are familiar with this situation very well from projects where you fled in horror.
Such an implementation brings no less problems to the owner of the business - he becomes attached to specific people, specific solutions and as a result begins to pay more and more. Entropy is growing.
On the other hand, large companies that thought about it in advance and started building a competent architecture can avoid such problems. In particular, one of the elements of a “correct” architecture can be BRMS.
It works like this: there is a user interface for setting rules, there is a rule store itself, and there is an engine for executing business rules. For example, a site may request a calculation of the size of the discount, your 1C may request an account check for certain parameters, etc. The BRMS-system “feeds” the incoming data to the rules stored in the repository and produces the result. By the way, among other things, this allows you to do analytical things, for example, to track cars that have been repaired during the week for the same breakdown in different places (a frequent example of fraud on spare parts in car services).
One possible implementation is IBM ILOG JRules (now IBM WODM). For example, on it we made a BRMS system for one large insurance company with four hundred branches in the country. There it was important to take into account a bunch of rules for CTP and CASCO, calculate the commission, quickly make changes to the rules, make sure that the tariff description exactly matches the calculation in the system, plus allow the customer to make changes to the rules on their own.
The initial situation was as follows: tariff calculation algorithms were wired in the code of information systems and in Excel calculators. To change the tariffs, the standard IT cycle “task setting - development - testing - deployment" was used. The change cycle took several weeks. The result after implementation is the rate of tariff change for several days, underwriters change the rules, and IT only accompanies the process; there is a single source of rules (for employees and systems), thanks to this there is complete transparency and accuracy of calculations in all systems.
During implementation, the main work was done by the analyst, engineer and manager. They collected more than 200 parameters for calculating the rules, received tens of thousands of basic rules. At the output - the time of one decision by the system is less than 1 second, and 30,000 calculations are performed in less than 3 minutes.
The charm of the system is its flexibility and the possibility of almost any settings. The rules are set in simple human language, such as "If the agent’s sales for a period> 1,000,000 rubles, then set the commission to 20%."
Of course, in addition to ILOG, there are solutions from other vendors, for example, Oracle Automation Policy, plus there are open source platforms, the most famous of which is JBoss Drools.
Least:
If you look at the large companies in North America and Europe, you can see that they have gone much further both in automating the business as a whole and in using tools that increase the efficiency of the expensive IT professionals. In particular, many have already taken the next step in abandoning tons of developed code, which is difficult to maintain, towards using more flexible technologies such as BRMS.
IT independence. Now you don’t have to knock on the developers to change tariffs, for example. This means that the speed of adoption and implementation of decisions within the company is growing sharply.
Another important point is that relations between departments are improving, because if there used to be a classic misunderstanding of “why do you need to change one digit in the same place” versus “you have to rebuild and test everything”, now users don’t think that IT comes up with excuses not to do.
She knows how to do event-processing. That is, to let through yourself a stream of hundreds of thousands and millions of events that are processed by specified business rules. This can be useful for identifying patterns. An example with the search for dishonest actions of car service personnel I have already cited. Another example is the search for market trends, for example, certain alerts with, say, a decrease in traffic consumption by subscribers of a cellular operator with certain signs. There is fraud detection, for example, making decisions on the fact of two withdrawals: at a restaurant in Moscow and at an ATM in China after two hours.
Manually programming each such rule is not difficult, but when there are hundreds of them, it’s logical not to code handlers for every case, but to write a system that allows you to configure everything. By the way, this is what developers often do by implementing various frameworks and other mechanisms for declaratively setting logic in their systems. In essence, this is BRMS.
In my practice, a bunch of undocumented rules are discovered. They just need to be described in BRMS. It is much more fun that at almost every implementation for the company’s management it comes as a surprise what rules are used where they did not even look. It happens that some prehistoric makeshift, written by the first programmer of the company in 15 minutes and with a bunch of bugs, becomes the basis for the module for calculating something important, and overgrow with all kinds of integrations like mushrooms. Another surprise for a number of contracting and internal developers of the company - the level of dependence on them immediately decreases. There is no longer need for "hangers", which are the only ones who understand how the module works - everything is described in a single system.
A common problem is to find out, in general, where the legs grow from the calculation. For example, it happens that there is a certain formula. The formula was written by a financial director who has not been with the company for five years. Where does the coefficient come from? Nobody knows; they are used as constants. They begin to understand, compare the business processes of departments - and it turns out, for example, that you can save on something. Because they understood how to calculate the coefficient.
There are perhaps two main indicators when to use BRMS: the presence of a large number of rules and the need for their regular change. For example, an average insurance company uses about 2,000 business rules. Of course, not all business rules need automation. For example, “a contract worth more than 300,000 rubles must be approved by a commercial director” - this is a rule that directly requests control through BRMS. And “only the respirator enters the territory” - rather, on the actions of the security guard on the spot. Everything that requires analytics, uniformity, control and strict adherence to information systems should be submitted to BRMS.
If we talk about industries, then BRMS are actually suitable for use in any industry where information systems are actively used.
To begin with, try to evaluate how difficult it will be for you to implement the BRMS approach. If you have one point, few people, business rules are simple and errors of violation of the rules are not very critical, then it is cheaper without the introduction of a new system. If the company is large, the price of an erroneous decision is high, IT solutions change slowly, plus you want to have more control over the situation - then BRMS may be your choice. It should be noted that licenses for such software are expensive - the amounts are tens of thousands of dollars (however, there are also open source solutions).
I’ll add that in my practice, for this to really work this way, you need a manager who is ready to implement the system precisely for the sake of increasing business efficiency, and not a report to shareholders.
PS If you have questions that you do not want to ask in the comments, write toIomehin@croc.ru .
straightforward homeoscope
Simple comparator
This is what we would today call the mechanical rudiments of modern expert systems.Remember the news that IBM spreads its artificial intelligence to hospitals? So, S. N. Korsakov began to do something similar at least 150 years before. His idea was extremely simple: you need to distribute the devices to the doctors in the field, and then the doctors will be able to accumulate experience together, not make common mistakes and generally treat by standards. The comparator served as a means of differential diagnostics, and a simpler homeoscope could act as an automaton, where the doctor entered the symptoms and received the disease at the exit.
That is, in other words, Korsakov tried to create a repository of medical knowledge and a rule management system . Because I did not believe that the same diseases would be treated in all corners of the country equally effectively and accurately.
In general, we are not very far from the 1800s
Modern business processes in many ways resemble the work of such a mechanical device. For example, a rule may work for a bank: if a client has been using the services for more than 3 years (they moved one lever) and the amount of his account is more than 3 million rubles (they moved the second), then he should be considered a VIP-client (the system concluded). Another example of a business rule is if the amount of the contract is more than $ 300,000, then agreement with the financial director is necessary.
Now imagine that you are running a large bank or insurance company. You have a problem with making local decisions very randomly. As rural doctors will use 100 of their own custom approaches to patients with the same problem, each of your departments will decide whether to grant a loan or risk assessment almost by the phase of the moon. Of course, the first thought is to introduce clear rules based on heuristics or linear comparisons.
So, it is for the implementation of these rules that BRMS systems are used. The beauty is that these are now not Excel tablets, not the opinion of the commercial director of the branch and not the advice of a colleague, but specific mechanics. The company’s business rules are maintained in a single repository in a user-friendly way. Enterprise systems invoke the calculation of rules from BRMS and get the result.
At the same time, business users change the rules without IT, and these rules can change really quickly without coding. All systems always use a single version of the rules. There is control of mandatory compliance with the rules.
Why is it important?Well, for example, I know of one large retail network where only custom development is used for automation. To do this, they have a regional development office, where 200+ developers sit. Business is growing rapidly, and management rightly considers flexibility one of the important competitive advantages. Therefore, if necessary, change something in business processes or business rules, even in small things, they sit down at their code and quickly rewrite it. The complexity of making changes is growing, and deadlines are always tight, so crutches are often piled up. Of course, such a system is extremely unstable. Plus you have to be almost an archaeologist to reuse the code that was once written. I think you are familiar with this situation very well from projects where you fled in horror.
Such an implementation brings no less problems to the owner of the business - he becomes attached to specific people, specific solutions and as a result begins to pay more and more. Entropy is growing.
On the other hand, large companies that thought about it in advance and started building a competent architecture can avoid such problems. In particular, one of the elements of a “correct” architecture can be BRMS.
It works like this: there is a user interface for setting rules, there is a rule store itself, and there is an engine for executing business rules. For example, a site may request a calculation of the size of the discount, your 1C may request an account check for certain parameters, etc. The BRMS-system “feeds” the incoming data to the rules stored in the repository and produces the result. By the way, among other things, this allows you to do analytical things, for example, to track cars that have been repaired during the week for the same breakdown in different places (a frequent example of fraud on spare parts in car services).
Example
One possible implementation is IBM ILOG JRules (now IBM WODM). For example, on it we made a BRMS system for one large insurance company with four hundred branches in the country. There it was important to take into account a bunch of rules for CTP and CASCO, calculate the commission, quickly make changes to the rules, make sure that the tariff description exactly matches the calculation in the system, plus allow the customer to make changes to the rules on their own.
The initial situation was as follows: tariff calculation algorithms were wired in the code of information systems and in Excel calculators. To change the tariffs, the standard IT cycle “task setting - development - testing - deployment" was used. The change cycle took several weeks. The result after implementation is the rate of tariff change for several days, underwriters change the rules, and IT only accompanies the process; there is a single source of rules (for employees and systems), thanks to this there is complete transparency and accuracy of calculations in all systems.
During implementation, the main work was done by the analyst, engineer and manager. They collected more than 200 parameters for calculating the rules, received tens of thousands of basic rules. At the output - the time of one decision by the system is less than 1 second, and 30,000 calculations are performed in less than 3 minutes.
The charm of the system is its flexibility and the possibility of almost any settings. The rules are set in simple human language, such as "If the agent’s sales for a period> 1,000,000 rubles, then set the commission to 20%."
Of course, in addition to ILOG, there are solutions from other vendors, for example, Oracle Automation Policy, plus there are open source platforms, the most famous of which is JBoss Drools.
What does this mean in terms of IT?
Least:
- There is less routine coding for the implementation of business rules. They can be defined declaratively.
- As the code gets smaller, it’s easier to maintain.
- More efforts will have to be spent on integrating systems, which requires higher qualifications of developers.
If you look at the large companies in North America and Europe, you can see that they have gone much further both in automating the business as a whole and in using tools that increase the efficiency of the expensive IT professionals. In particular, many have already taken the next step in abandoning tons of developed code, which is difficult to maintain, towards using more flexible technologies such as BRMS.
What does this mean from the point of view of the user?
IT independence. Now you don’t have to knock on the developers to change tariffs, for example. This means that the speed of adoption and implementation of decisions within the company is growing sharply.
Another important point is that relations between departments are improving, because if there used to be a classic misunderstanding of “why do you need to change one digit in the same place” versus “you have to rebuild and test everything”, now users don’t think that IT comes up with excuses not to do.
What else can a BRMS system do?
She knows how to do event-processing. That is, to let through yourself a stream of hundreds of thousands and millions of events that are processed by specified business rules. This can be useful for identifying patterns. An example with the search for dishonest actions of car service personnel I have already cited. Another example is the search for market trends, for example, certain alerts with, say, a decrease in traffic consumption by subscribers of a cellular operator with certain signs. There is fraud detection, for example, making decisions on the fact of two withdrawals: at a restaurant in Moscow and at an ATM in China after two hours.
Manually programming each such rule is not difficult, but when there are hundreds of them, it’s logical not to code handlers for every case, but to write a system that allows you to configure everything. By the way, this is what developers often do by implementing various frameworks and other mechanisms for declaratively setting logic in their systems. In essence, this is BRMS.
What surprises are revealed during implementation?
In my practice, a bunch of undocumented rules are discovered. They just need to be described in BRMS. It is much more fun that at almost every implementation for the company’s management it comes as a surprise what rules are used where they did not even look. It happens that some prehistoric makeshift, written by the first programmer of the company in 15 minutes and with a bunch of bugs, becomes the basis for the module for calculating something important, and overgrow with all kinds of integrations like mushrooms. Another surprise for a number of contracting and internal developers of the company - the level of dependence on them immediately decreases. There is no longer need for "hangers", which are the only ones who understand how the module works - everything is described in a single system.
A common problem is to find out, in general, where the legs grow from the calculation. For example, it happens that there is a certain formula. The formula was written by a financial director who has not been with the company for five years. Where does the coefficient come from? Nobody knows; they are used as constants. They begin to understand, compare the business processes of departments - and it turns out, for example, that you can save on something. Because they understood how to calculate the coefficient.
Where can i use it?
There are perhaps two main indicators when to use BRMS: the presence of a large number of rules and the need for their regular change. For example, an average insurance company uses about 2,000 business rules. Of course, not all business rules need automation. For example, “a contract worth more than 300,000 rubles must be approved by a commercial director” - this is a rule that directly requests control through BRMS. And “only the respirator enters the territory” - rather, on the actions of the security guard on the spot. Everything that requires analytics, uniformity, control and strict adherence to information systems should be submitted to BRMS.
If we talk about industries, then BRMS are actually suitable for use in any industry where information systems are actively used.
How to understand whether the company is ripe for BRMS?
To begin with, try to evaluate how difficult it will be for you to implement the BRMS approach. If you have one point, few people, business rules are simple and errors of violation of the rules are not very critical, then it is cheaper without the introduction of a new system. If the company is large, the price of an erroneous decision is high, IT solutions change slowly, plus you want to have more control over the situation - then BRMS may be your choice. It should be noted that licenses for such software are expensive - the amounts are tens of thousands of dollars (however, there are also open source solutions).
I’ll add that in my practice, for this to really work this way, you need a manager who is ready to implement the system precisely for the sake of increasing business efficiency, and not a report to shareholders.
PS If you have questions that you do not want to ask in the comments, write toIomehin@croc.ru .