Rules Architects are increasingly using decision modeling as part of their business rules management system (BRMS) implementations. This article will explore three key benefits of using decision modeling and a BRMS.
- Business Engagement
- Expanded Traceability and Impact Analysis
- Using agile not waterfall to write the rules
A decision model based on the Decision Model and Notation (DMN) standard is a graphical representation of a decision-making approach. It lets you take a repeatable business decision like Approve Claim, Validate Application, Calculate Discount or Select Supplier and break it down into its component pieces. Dividing up the decision-making into understandable, atomic and reusable decisions simplifies even the most complex decision and the model shows where each piece of business data is used. To make sure you really understand the decision you can show what policies, regulations, best practices and know-how is driving the decision so you know where your business rules are coming from.
Rules architects find that building a model like this immediately engages their business partners – business analysts, subject matter experts and business owners – in the project. Instead of diving straight in with detailed rule analysis as step 1, decision modeling let’s everyone see the forest not just the trees.
Because DMN decision models work just as well for manual decisions as for rules-based automated decisions, the whole project can be modeled the same way making it easy to see what should (and should not) be in the BRMS. And if you build the decision model using a collaborative tool like DecisionsFirst Modeler, then the ability to share read-only models in mobile-friendly HTML pages engages an even greater range of participants.
Getting business partners engaged early is hugely beneficial but rules architects know they need to keep them engaged. Rules architects use a BRMS on projects where regular, rapid even constant change is going to be the normal state of affairs. A decision model helps here too. Being able to come back to a graphic model they are familiar with, which they built, gives business experts a visual guide to the decision they are maintaining. They can quickly identify the part of the decision that needs to change and put that change in context.
But what about the rules that define the decisions in these models? Traditional rule analysis approaches and tools lead to a business version of the rules that’s captured outside the BRMS. Mostly the original intent was just to do this initially and then to “move” the rules into the BRMS. But business experts and analysts can get attached to these rules and define their changes in terms of those rules, not the ones that actually run in the BRMS. And suddenly you’re back to business throwing “spec” documents over the fence to IT. All that’s changed is that the documents are rules-based ones.
Using DecisionsFirst Modeler Enterprise Edition and its integration with leading BRMSs like IBM ODM and Red Hat JBoss BRMS solves this problem too. Now the decision model is linked directly to the rules in the BRMS. Business owners can navigate from a familiar decision model to a web-based, friendly editor in the BRMS. They can go directly to the rules that implement a specific decision in the model, make a change and push it through the governance approach established in the BRMS.
A modern BRMS provides good tools for rules-level traceability. Seeing which rules use which data fields and tracing rule execution on historical transactions is a key element of the transparency delivered by a BRMS. A modern BRMS also does a great job of showing you the impact of a change to the rules, letting those who change the rules run suites of tests or simulations against historical data. Being able to quickly visualize and assess the business impact of a change to the business rules is a key feature of a BRMS. Rules architects know that BRMS level traceability and impact analysis is necessary for success, but it is not sufficient.
Integrating a decision model with the rules in a modern BRMS using DecisionsFirst Modeler lets you take traceability to the source. Decision models capture the original sources of the rules in your BRMS as Knowledge Sources. Knowledge Sources represent real documents such as policies and regulations, the expertise of subject matter experts or analytic model results.
Knowledge Sources are where change begins. A decision model makes it easy to trace a new policy or a changed regulation to the decisions based on it and then to the decision tables, decision trees or rules that implement that decision. Business entities like Customer, Order, Supplier or Location are captured too. Which decisions use that data can be seen in the diagrams you build and DecisionsFirst Modeler also keeps track of all the Decisions that use a piece of data across all your diagrams. Easy, business-friendly traceability.
And when there are rules changes, a decision model in DecisionsFirst Modeler lets you take impact analysis further. A decision model in DecisionsFirst Modeler linked to a BRMS implementation shows exactly how a change to the rules will impact the business.
A decision model makes it easy for business experts to find all the decisions (automated or manual) that will be impacted, directly or indirectly, when the implementation changes. The SME sees who needs to be informed or give permission, because those decisions are mapped to the organization’s responsibilities. They can see which processes involve any of these decisions. And most importantly they can see which business metrics will be impacted so they can make sure they understand the change in terms of its impact on business performance.
BRMSs like IBM’s ODM and Red Hat’s JBoss BRMS are great at delivering rule-centric traceability and impact analysis. Integrating your BRMS implementation with a decision model in DecisionsFirst Modeler extends that to a business-level, decision-centric traceability and impact analysis too.
Techniques for capturing and documenting business rules have been around a long time. Many of these pre-date modern BRMSs and were developed before decision modeling established itself as a best practice for describing decision making. These rules-first approaches all have something in common: They begin by capturing all the rules in a business or a business area and documenting them consistently. Only once all the rules are documented can a second stage begin to see which rules should go into the BRMS, at which point the rules are translated from the documentation format to the BRMS format.
A problem with the rules-first approaches is that they drive a waterfall approach. If you have to gather all the rules first, then you have to complete your requirements phase before you can begin design and build. Rules Architects know that this is not going to fly any more – organizations don’t like to wait that long before seeing some results, time to market is too important, and many business partners no longer believe that this kind of project will ever deliver anything no matter how long they wait.
A decisions-first approach based on decision models works seamlessly with an agile, iterative project methodology. The first iteration describes the critical decision(s) and draws a high level model to scope the decision service and shows what data is needed. An immediate skeleton can now be built in the BRMS to support testing.
This high level model then is expanded to identify the key sub-decisions. Using DecisionsFirst Modeler, new diagrams can be developed that take these key sub-decisions and model them in turn. The ability to reuse objects across diagrams and create multiple views lets you rapidly develop a decision model for each area. As decisions are identified and described, an implementation component (a decision table, decision tree or ruleset for instance) can be created I the BRMS and linked.
The rules for each atomic decision can be captured directly in the BRMS, taking maximum advantage of the BRMS’s ability to validate, verify and govern the rules as they are entered. Each iteration can be deployed delivering value incrementally. Each subsequent iteration can reuse and depend on previous iterations, minimizing rework. Once the whole scope is implemented, subsequent iterations can focus on refinement and improvement, using the decision model as a map of the implementation.
A modern BRMS makes it quick and easy to edit and manage the rules. There’s no need for a big waterfall analysis phase. A decision model provides the framework and approach rules architects need to deliver an agile business rules solution.
