By automating critical business decisions, a Business Rules Management System (BRMS) can increase the productivity, consistency, and quality of your most important business processes. To realize these benefits, a BRMS must make it easy to capture your company’s expertise as rules, must enable administrators to manage all aspects of the project lifecycle, and must deliver key insight to all project stakeholders.
With your business likely under pressure to deliver more value for less money, you may be tempted to consider low-cost solutions (let’s face it, you would be foolish not to). For example, open source Drools is available for free, and Red Hat packages Drools and supports it as Red Hat JBoss BRMS for what sounds like not a whole lot more. However, does it actually meet your enterprise needs? IBM Operational Decision Manager (IBM ODM – formerly IBM ILOG JRules BRMS) provides advantages over Red Hat’s JBoss BRMS that ultimately will save you in development and administration costs, and more significantly, will enable you to realize much greater business value from your rules-based application. If there was one thing for you to remember from this article, it would be this – depending on the application, long term increased business efficiency trumps software license costs by many orders of magnitude. Of course, the exact benefits depend on the business size and complexity.
The major enterprise advantages that IBM ODM has over Red Hat JBoss BRMS include the following:
1. Productivity. Rule capture designed for business experts, not programmers
2. Collaboration. The ability to share expertise in order to define rules quicker and with higher quality
3. Governance. Allow business experts to manage changes for greater security and accountability
4. Insight. Reporting to identify gaps and overlaps in rules as well as to provide greater visibility to business experts and other stakeholders
Let’s look at these four considerations in more details.
Business experts can be more productive with IBM ODM
Since building a rules system is basically about capturing the knowledge of your business experts, making those experts productive is arguably the most important feature in pulling off a rules system. IBM ODM makes it easy for business experts to define rules and understand them by representing rules in a more natural language form rather than programming syntax. ODM’s rule editor allows a rule creator to define a rule by selecting fields to form a roughly sentence-like syntax. For example, if the rule triggers when the “ship to” state is Massachusetts, the expert creates the statement “if the state of the address of the ship to of the PurchaseOrder is ‘MA’.” While not quite conversational language (frankly, it sounds to me like something Yoda would say), ODM’s rules can be created without fear of syntax errors and can be read by experts who otherwise could not read programming languages. To make it even easier for experts to create rules in a way that is natural and comfortable for them, ODM allows them to define rules in Microsoft Word (for if/then Action Rules) or Microsoft Excel (for decision tables).
Simple action rule defined in Microsoft Word with natural language
Drools/Red Hat JBoss BRMS does not use a natural language approach, making it harder for business experts to create rules or to understand rules created by a programmer. One approach that Drools/Red Hat JBoss BRMS uses is DRL, which has a Java-like syntax for creating rules. I don’t mind it, but I don’t think that a business expert is going to use this.
Drools/Red Hat JBoss BRMS does offer what it calls “Guided Rules,” which allow a rule creator to select the fields that form the rule, but it still is too technical for a business expert to implement rules or even to interpret them. For all of the trouble that Guided Rules involved, I probably would stick with coding the DRL rules.
The cost of Drools/Red Hat JBoss BRMS’s approach is that business experts cannot directly define business rules. Instead, they somehow must capture their rules, perhaps in a document, so that a programmer can read them and translate them into the technical rule syntax. The risk of this translation is compounded by the expert’s difficulty in understanding the DRL technical syntax, making it harder for him to verify that the rule has been translated successfully. These difficulties mean that a Drools/Red Hat JBoss BRMS project would require more time to define rules and would require more time to verify and debug them.
Watch me demonstrate rule creation.
Experts can collaborate to produce better decisions with IBM ODM
Your business knowledge does not reside in the mind of one grizzled veteran who has “seen it all” and can define all of your business rules from his vast experience. Instead, you likely will have a team of experts working together to define rules for a particular functional area while additional teams cover other areas of the business. In such an environment, effective collaboration will increase your teams’ productivity and minimize misunderstandings and mistakes that can cost you considerable expense if they are not discovered until the applications get into the hands of your customers.
IBM ODM’s Business Console allows business experts to use social networking mechanisms to quickly identify work that is of interest to them and to share thoughts and ideas with colleagues. For example, a business expert can “follow” a rule or project so she can find it from her home page and easily identify changes that may have been made to it by her colleagues.
When experts directly seek feedback from each other, they can “mention” each other in the stream, and that comment will appear at the top of the mentioned expert’s home page for a more immediate response.
When “Paul” mentions “Bea,” Bea sees the comment on her home page in ODM’s Business Console
IBM ODM’s approach delivers greater productivity and accountability than relying on the company email or instant messaging systems. For an application with a large team of experts, managers, developers, and stakeholders, ODM’s built-in collaboration enables all parties to communicate and share in the implementation process.
Drools/Red Hat JBoss BRMS has no built-in collaboration. All that it offers is a “Discussion” section of its rule Metadata, but without the ability to follow rules of interest, mention colleagues, or view a stream that combines a record of comments and actions, this approach does little to improve productivity or accountability.
The cost of Drools/Red Hat JBoss BRMS’s lack of collaboration is a lessening of productivity as the size of the application and the implementation team grows. Developers and experts will have little alternative to direct communication with each other, precluding their colleagues from sharing in the discussion and making it difficult for a project manager to correlate the exchange of ideas with changes to business rules.
Watch me demonstrate rule collaboration.
Project managers can better manage changes with IBM ODM
For a rules-based application that involves teams of experts, managers, developers, and administrators, good governance ensures that application releases consist of rules for which all changes are properly accounted and tested. As a programmer, I consider governance a nuisance, but I admit that you wouldn’t want to build an enterprise-quality project without doing it right. With IBM ODM, a project manager not only creates releases, but she also can create activities with specific goals and deadlines. For example, she might create an activity with a goal of updating a set of rules, then she would specify the team members who are authorized to make the updates and the team members who are authorized to approve those changes. In this fashion, the project manager can restrict who can change what and assign tasks to individual participants.
An ODM change activity with goals, deadlines, and specified approvers and authors
Individuals can manage their status from the Business Console in order to make it easy for all stakeholders to know when the authors and approvers have completed their tasks. In order to make it easier for stakeholders to understand the modifications made to an application, ODM provides a “timeline” that visually depicts project changes:
In addition, stakeholders can compare rule versions in order to better understand any changes:
IBM ODM can compare rule versions to more easily identify changes
Drools/Red Hat JBoss BRMS manages project changes more in the style of a Source Code Management system (in this case, Git) instead of through a governance framework. Developers or managers can view a primitive version history as part of the Metadata for each rule:
Unlike IBM ODM, Drools/Red Hat JBoss BRMS lacks the ability to define activities and assign and manage tasks. Drools/Red Hat JBoss BRMS also lacks the ability to view a change timeline or compare rule versions.
Programmers may be okay with that, but again the approach limits the visibility to all of the less technical people who are involved with the project, such as business experts, managers, and executives. The cost of this lack of a robust governance framework is that there is a greater danger of unwanted or unaccounted for changes to a Drools/Red Hat JBoss BRMS project, resulting in time-consuming and expensive tracking and debugging. Such robustness may appear less important for Proofs of Concept or small projects with a limited development team, but for true enterprise applications, this shortcoming exposes your projects to considerable risk and cost.
Watch me demonstrate rule governance here.
Project stakeholders gain greater insight and visibility with IBM ODM
Besides automating decisions, a rules application can give your business greater insight and visibility into the decisions that it makes. An important part of this insight is having the confidence that the right rules are triggered under the right circumstances. For example, do you lack rules for certain conditions, or do your rules overlap, leaving confusion as to which one would apply?
IBM ODM helps you answer these questions through its reporting and analysis. A project stakeholder at the click of the mouse can run an analysis that will identify any missing rules (e.g., you have no rule if the claim amount is in between $500 and $1000) or overlapping rules (e.g., two rules would trigger if the customer’s age is over 55).
In addition, IBM ODM can provide a simple report that presents the rules in a form that is easily read by even the least technical stakeholder.
Drools/Red Hat JBoss BRMS lacks any of this reporting and analysis. As a result, an application with a sizeable number of rules developed by different teams may inadvertently have rules that conflict or have gaps. Without the analysis that IBM ODM provides, how can the project team identify these problems? Unless the team reads through all of the rules to try to determine if any problems exist, the business will have to be prepared to find the problems only when an unexpected result occurs during testing (if they are lucky) or in production when a customer complains or an order is lost (if they are not). I wouldn’t want to be the guy who has to read through fifty rules to figure out if anything is missing or overlaps, would you?
Watch me demonstrate rule insight here.
IBM Makes a Decision Management Solution an Easy Decision to Manage
IBM Operational Decision Manager offers a solution truly worth the investment, enabling your business experts to turn their hard-earned insight into business value quickly, collaboratively, and efficiently. With Drools/Red Hat JBoss BRMS, by comparison, the Return on Investment is likely to be poor, since without the key features that IBM has, the implementation and maintenance costs would be higher and the benefits for your business would be lower in spite of IBM’s higher licensing cost. IBM ODM can transform your business expertise into a key competitive advantage, and Drools/Red Hat JBoss BRMS, in spite of its low initial cost, is not “good enough” to be worth the time, money, and effort.