3 Reasons Rules Architects Are Adopting Decision Modeling
James Taylor
![James Taylor]()
James Taylor
Leading authority on Digital Decisioning and delivering business impact from AI and machine learning
We work with a lot of business rules architects and we see that more and more of them are using decision modeling as part of their business rules management system (BRMS) implementations. I recently wrote a series of blog posts - 3 Reasons Rules Architects Are Adopting Decision Modeling - over on our company blog. You can find the posts here:
- #1 Business Engagement
Rules architects find that building a decision model (especially one using the Decision Model and Notation (DMN) standard immediately engages their business partners – business analysts, subject matter experts and business owners - because decision modeling let’s everyone see the forest not just the trees. - #2 Expanded Traceability and Impact Analysis
Decision models link the business context to the business rules, enabling traceability all the way to the knowledge sources that drive rules and impact analysis all the way to the business objectives. - #3 Using Agile Not Waterfall to Write the Rules
Unlike traditional rules-first approaches, decision models lend themselves to iterative development and agile project approaches.
Of course you need a decision modeling tool to make this work, one that is integrated with your BRMS. If you are interested, you can see how we have done this with our DecisionsFirst Modeler – BRMS integrations in action in these demonstrations:
Consultant/Coach/Trainer (Business Analysis/Architecture, BPMN, DMN, Agile/Scaled Agile)
8 年Excellent points. Architects (business/enterprise) should indeed pay more attention, and adopt, both BPMN and DMN in their practices. Unfortunately, there are many architects (especially in a certain... Guild;) that seem to have some kind of process-allergy, if I can put it that way. They often like to emphasize that Capabilities as the "what" of what an enterprise does and not the "how", which they say it's captured by "operational processes" (which they never quite define). Nothing wrong with Capabilities, but I'm puzzled about their examples of Level 2 & 3+ capabilities and value-maps (with different stages) stated as... operational processes (I guess, in disguise). Kind of inconsisten, isn't it?Probably not a fair statement (on my behalf) to say all this out of context, but I felt it was worth noticing. By the way, if I recall well, Paul Harmon (BPTrends) commented on that, too. I wouldn't be surprised to see same architects have a similar view on Decision Models... unfortunately. Putting aside my digression (my apologies if in the wrong place), 100% in agreement with your points.