Call us at 650-400-3029 (PST)

3 Reasons Rules Architects Are Adopting Decision Modeling:  #1 Business Engagement

Business EngagementRules Architects we work with are increasingly using decision modeling as part of their business rules management system (BRMS) implementations. This month’s blog series 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, that 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.

One version of the rules, maintained by the business, managed by a DecisionsFirst Modeler decision model.

Next week I’ll talk about the power of decision modeling to improve traceability and impact analysis.

If you want to learn more, check out our white paper on how decision modeling helps you maxmize the value of business rules.

Read the rest of the series: