One of the main motivations that James Taylor and I had for writing our book Real World Decision Modeling with DMN was sharing our experience of using decision modeling on many large projects and training engagements. One specific question that interested us was: “who uses Decision Modeling?”
James recently discussed how Decision Modeling is used. Assuming your organization is persuaded of the benefits of Decision Modeling, which specific project team members are most often tasked with building and maintaining a decision model (using DMN, TDM or any other notation)? We present our project experiences here. Let us know if and how yours are different.
In our experience this responsibility normally falls to (in descending order of likelihood):
- Business Analysts. The most common group of users, BAs are often tasked with producing precise and transparent representations of locally defined or externally regulated business decisions. An increasing number prefer to use a standard notation, like DMN, rather than an ad-hoc one.
- Process Designers. Many business process modelers see the benefit of decoupling the structure and logic of business decisions from the sequence of business processes. Many are drawn by the natural interface between BPMN and DMN.
- Subject Matter Experts. In practice SMEs use decision modeling less than I would hope. This seems to be because business experts are less comfortable or familiar with precise representations of business decisions. They tend to view precision as a matter for implementors—a sentiment with which I heartily disagree.
- Business Rules or Code Developers. To my surprise, many developers are drawn to the way in which decision models manage complexity and are keen to share the responsibility of maintaining a decision model, especially when it exhibits direct traceability with existing implementation artifacts (i.e., business rules or code).
- Data Architects/Scientists. Increasingly we observe this community using decision modeling, specifically the requirements level of DMN, to provide a context for analytical models.
- Business/Application Architects. Architects sometimes use decision modeling to define the interface of a collection of decision services, understand their stakeholder value and prioritize their implementation.
- Project Managers. This is a rarity admittedly, but I come across two PMs who have co-developed and promoted decision models as resources to train new team members and to facilitate independent review of decision services prior to committing development resources.
What is your experience? Who uses decision modeling in your organization?
That’s consistent with my experience. One question: Decision models are an excellent way of perceiving the boundary conditions and scope of business decisions – have you ever seen testers maintain or consume decision models?
Dave, Interesting point. I don’t recall ever having seen that, although it makes perfect sense.
Not only would the Decision Logic Level would be a powerful way of generating tests (Decision tables are really good at defining boundary conditions as you say), but the Decision Requirement Level would be even more useful as a means of scoping tests. You could use the separate clusters of sub-decisions depicted in DRDs as a way of identifying the best set of small independent test scenarios to minimize (and prioritize according to reuse) your testing effort.
The dependencies between decisions that the DRD depicts would provide an excellent overview for a tester: yielding data requirements (from Input Data), test data (from Knowledge Sources) and test targets all in one view.