When is a project a “Business Rules” project?
Business rules management systems (BRMS) are a very generic kind of software. They are very much domain-agnostic and therefore lend themselves to many uses. They basically let you design and manage an important part of an application – the business logic – independently from the rest. And they do this by using quite different metaphors than those used by software developers, simply and foremost because they are not supposed to be used by software developers – but business people, or in other words – the domain experts.
When you build a software application, there always is business logic somewhere. And this business logic can be implemented using a BRMS. But is this always the right way and adequate for every project?
Here’s a list of indicators for a “business rules” project:
Does the business logic contain key decisions with a high business value?
High value decisions are a sure candidate for a BRMS, because it is the business user’s responsibility to make the right decisions, and only they understand the difference between good and bad decisions. Many BPM or BPA projects identify these key decision points within processes. Giving business users direct control of these decisions via a BRMS helps to introduce the neccesary competitiveness and agility into IT systems, and it allows business users to continually strive for maximizing the business value of every decision.
Is there a need for changing the business rules once the application is in place?
Software always needs to be changed as the business requirements change. What you really must consider is the frequency, size and effect of these changes. The higher the frequency, the larger the size and the more relevant the effect of changes are, the more important and rewarding the use of a BRMS may be. Why? Because BRMS have specific features that help to make changes quickly and to bring them to production quickly, while at the same time ensuring that the changes have the desired effect. And all that is done with full auditability. And because the rules are separated from the rest of the application code, you can eliminate or at least isolate side effects between these two parts much more easily.
Who knows what the rules need to be and who wants to be changing the rules?
If business users are explicitly asking for more control, if they really feel unhappy about having to go to IT every time they want a change, and they are willing to take over the responsibility, then a BRMS will surely help.
But even when business users do not take over the full responsibility and leave a good part of it in IT, a BRMS may be an excellent way to improve the communication of requirements between the two parties with a lot less potential for misunderstandings.
Do you want the business logic to be transparent and shared?
After a while, program code has the tendency to become a mystery to everyone except for the original programmer. That’s a huge problem especially when this code contains business critical decision logic. Business rules, on the other hand, are separate from program code and much more readable and accessible to business users. It is also much easier to share the knowledge about the rules. This produces a huge long term advantage in regards to maintenance of a software.
Are there regulations that require the documentation and auditing of decisions?
BRMS provide built-in mechanisms for change management, rule versioning and tracing of decisions. These capabilities make it very easy to review any business decision ever made. What was the decision? What were the rules applied? What was the data? Being able to answer these questions, even after years, is a regulatory requirement in many industries.
Do you know other reasons for using a BRMS? Please let us know.