George presented a fairly detailed analysis of the application of rules technologies to business problems at Union Pacific Railroad.
The key motivation behind the usage of rules technology to solve those problems is the need to make the supporting systems adaptive and agile. The challenge is that this does not come cheap – you have to implement the discipline to separate business data and logic from implementation code, and render their manage agile and adaptive. That touches data stores, transformations, logic execution, user interfaces, etc… It’s a hard problem.
The whole story behind the introduction and success of BRMS is precisely that – through business rules management, the business logic can be made adaptive and agile.
George went into the details of a classification for types of rules that he uses:
- “simple rules” – rules operating on a single business entity, following a common structure – usually represented in spreadsheets and decision tables
- “moderate rules” – rules that may apply to one or more business entity, but do follow a common structure – manageable by business users
- “complex rules” – rules that have no common structure, not manageable by business users
While I am all for classifications, I do not think that this classification is a good guide to managing the choices of representation – and I do not think George suggested that, it’s just that too frequently I have seen efforts fall into that trap. The representation choice is for me much more a question of how the business user thinks about the rules, and not what the rules are about or their level of commonality. Furthermore, I do believe that all representations need to be built in such a way that they are tolerant to exceptions – or else they break and introduce enormous friction which defeats the purpose – another reason for not pushing forward hard and fast classifications.
George also proposed a model of the roles involved in managing business rules through their lifecycle, as well as their expected interactions. To support the corresponding lifecycle, a real Enterprise BRMS is needed – and George went through the options available in the commercial and OSS world, and some elements that can be used to decide what to select.
His example is a good illustration of what really goes on in a significant Enterprise Decision Management effort. I recognized many of the issues that I have seen our customers go through.
George coincides with Carole-Ann and myself that the #1 challenge in these efforts is getting the rules management UI right. This is absolutely correct, and it’s easy to underestimate the business value of it.
It has to be understandable, usable, expressive, reusable, customizable, easily accessible, and testable.
Making sure the rules are “good” (which actually combines technical correctness with business validity) is also important. Being able to simulate, test in a champion-challenger model, all that is key to ensure the success of an enterprise business rules deployment. George described how to use FIT – Framework for Integrated Test – for this purpose.
George then went into a discussion on what CEP is with respect to BRMS. This is one more polemic subject – both may use similar underlying technology (for example, some CEP implementations rely on Rete or derivations of it) but the focus is really different, and the rest of the non-engine features is different.
A good industry case of what it takes today to implement business rules in enterprise applications.
Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager
