There are a number of clients (particularly investment banks) that are using business rule management systems BRMS tools to maintain business rules. They all firmly believe that this is a best practice that will bring a great benefit. But IT practitioners are still the stewards and custodians of these rules – so have these august organisations missed the whole point of business rules?
The main value proposition of business rules is safe agility: the ability to evolve the business behaviour and decision logic of a system quickly and without incident. By this means, businesses can keep up with changes mandated by new business practices or explore alternative, more profitable business models and lead the way as innovators. The key is speed: the more quickly you can effect these changes, the more likely you will have a competitive edge.
Normally this agility is achieved by separation: separating the business logic of an IT system from its infrastructure code, technical artifacts and business orchestration and expressing it as a separate business asset. Then it can be changed, and experimented with, without the overhead typically associated with a software release cycle. In effect your create two nested change cycles: the software/infrastructure release cycle (heavy) and the business rule release cycle (light).
The business rule change cycle is light because, once this separation described above is achieved “business specifications are no longer requirements that support the development of IT design, they are the business configuration that is expected to be loaded into the IT system” (McWhorter). In other words, the translation between business requirement and IT design is avoided: business requirements are expressed in business rules which are, in effect, directly executable, because they act as configuration of a system. This has a double payoff because the translation (from business specifications to system design) is time consuming, resource hungry and error prone. Naturally you need more than business rule technology to achieve this vision (traceability between rules and business drivers, automated regression testing, an orchestrated change control process and a fact model to name but a few). But it is nonetheless a powerful and realistic goal.
This way of working requires that business analysts and SMEs become the custodians of the business rules. If IT practitioners persist in this role (as they do in many companies today) the translation, and all of its attendant costs, remain. Furthermore the business will be disenfranchised and not own the rules, casting serious risk on their validity. IT teams are still pivotal in the process: they still need to support the abstractions and concepts that the business rules manipulate in the underlying infrastructure. IT must also retain ownership of the purely technical rules that also benefit from separation. However they should no longer be the bottleneck of business rule change. Control and authorship of the business rules should and must rest with the business. Otherwise the full promise of rules will not be realised.
Conclusion
If your business seeks the safe agility promised by the business rule approach, ensure that your business analysts and SMEs are the true custodians of the business rules. Only by this means will business change be separated from the inherently slower pace of software infrastructure change. As IT practitioners usually introduce BRMS technology to an organisation and business personnel are often shy of this new technology this situation will not occur naturally. It will need to be vigourously encouraged by a campaign of training, mentorship and cultural change.
Recent Comments