Processes and a Decision Modeling Notation

In the Eighties many developers discovered the power of rules when they learned about Artificial Intelligence and, specifically, expert systems. In essence, a software algorithm — an inference engine — could use logic to process a set of rules, and arrive at a logical conclusion. The developer did not need to arrange the rules in any particular order: He or she merely needs to state the rules correctly; the inference engine would then examine the rules and create its own logical sequence. Using this approach, a system can easily analyze a problem that involves hundreds or thousands of rules and reach conclusions with accuracy that most humans would have trouble duplicating.

Those who followed the expert systems market in the Eighties, as I did, watched as the early rule-based tools evolved into hybrid expert system tools that combined objects and rules. The objects, in effect, created a structured network of concepts and grouped the rules into sets associated with specific facts and concepts to enable more efficient processing.

Many companies developed expert systems. Some are still in use. Most expert systems, however, have now disappeared. The problem with expert systems is that expert knowledge changes so quickly that, given current techniques, it costs more to maintain the expert system than it is worth.

For awhile, in the early Nineties it seemed as if all the expert system software vendors and their software products would disappear. They were saved by the insight that smaller rule-based systems – which I have usually called knowledge systems — could be very valuable. Moreover, if one focused on business rules that are derived from company policies and were used in routine decisions, the rule bases do not get too large, and the knowledge doesn't change nearly as rapidly as the knowledge possessed by cutting-edge human experts. In other words, don't try to build an expert system to predict the stock market; focus instead on developing smaller decision systems to help loan officers make routine loans for autos or houses. Better, focus on helping clerks make decisions about the most cost effective way to route shipments to various distributors.

Every organization has hundreds of processes that require decisions. A quick calculation will show that if you could improve each of those decisions so that the average employee consistently did as well as the best employee, your organization would be making a lot more money.

At the same time that the early Business Process Management Software vendors were offering the first BPMS products, a variety of consultants were offering to help companies define their business rules, and in many cases, were happy to show them how to automate their business rules in simplified expert system tools. Having developed from two different technological traditions, there was, initially little in common between marketing presentations of process and rules vendors.

Within a short time, however, a couple of the leading business rules vendors decided that they could reconceptualize their tools to serve the BPMS market. The rule vendors already had the concept of grouping rules into objects with various kinds of inheritance. Now, instead, they grouped rules into business processes, and used the rules to manage the decision-making activities that occurred within various activities.

Many of us who work in process analysis, however, have long realized that there was something missing. In essence, rules are a very fine grained way of talking about the decisions that take place within processes.

In the past decade the business rules marketplace has begun to change and is now more commonly described as the decision management market. This, in turn, has accelerated the merger that has been occurring between the business rule and process vendors and consultants. In last month's advisor on IBM's BPMS offering, I noted that IBM now treats BPMS and Business Rules – which they now term Decision Management – as two sides of the same coin. One uses BPMS to describe what the organization is trying to do. Then, as one drills down, one looks at specific process activities and decides if they are essentially procedural or if they involve decisions (or a mixture of both). If the activities involve decisions, then one considers using Decision Management to describe the decision logic of the activity.

To formalize this emerging understanding, the Object Management Group (OMG) has established a task force to consider how rules, decision management and processes ought to work together and this task force is currently working on a draft Decision Model and Notation (DMN) (bmi/2012-11-12) [1].

Figure 1 illustrates the high level model that the OMG has included in the current draft of their Decision Model and Notation (DMN) document. (I have expanded the diagram in the OMG DMN 1.0 draft document to incorporate some items that are discussed in the model but were not shown in their current diagram.) At the top is a BPMN process model that includes an activity in which a decision is made: In this case, whether or not to accept an application. The activity: Decide routing, includes a small icon for “Business rules” (Which in a future version of BPMN will probably be renamed “Decision.” )

What DMN provides is a way to think about how one might describe how the decision in the activity is to be made. DMN begins with a Decision Requirements Diagram (DRD). This is what has been missing in standard business rules formulation – a middle layer of abstraction that lies between the process activity and the business rules.

The DRD includes several elements. First there is the decision or decisions that are taken during the process or activity being referenced. These decisions are often arranged in a hierarchical manner and numbered. Then there is the business knowledge required to make the decision – what we would have captured in a semantic net and the knowledge base in a classic expert system. And there is input data from the external world that is required to make the decision – whether from a user, a database or an application. The DRD may also include information on the Knowledge source – the person, book, or whatever that the organization relies on to validate and update the Business knowledge. I won't go into the details at this point, but between decisions and business knowledge models, and input data, we have mid-level concepts that make it much easier to define the initial decisions that take place in process activities. (The DMN standard also introduces a new software language – FEEL, based on XPath and Java that can be used by software developers to define the Decision Logic level with precision.)

Figure 1 illustrates a very simple decision process. There could be many different decisions, and DRD even allows for the possibility that decisions could be decomposed into smaller Decision Requirements Diagrams.

Figure 1: Levels of modeling

(After the OMG's Decision Model and Notation (DMN)
Separate from the DRD, there is Decision Logic. Decision Logic could be a decision table, business rules, or an executable analytic model. The latter is important because it is at this point that business rules and Analytics merge – both are all simply types of support for decisions [2].

Obviously one block of Business Knowledge could contain dozens or hundreds of tables or business rules. (Increasingly business rules are represented on spreadsheets in a decision table format. They don't have to be, but many business people find this representation the easiest to understand.)

Both the Decision Requirements Diagram and the Decision Logic, collectively, comprise a Decision Model and the specific elements illustrated in Figure 1 constitute the notation.

Finally, at the lowest level in Figure 1 we have what is termed a Decision Service. In essence a decision service is a software application that automates some or all of a Decision Model.

The entire DMN being developed is compatible with BPMN and with various BPMS standards. Thus, this notation makes it possible for process developers to create models that describe the high-level process flow, the decisions required by various specific process activities, and the tables or rules (on Analytic models) required to make the decisions.

Taken together, the BPMN and DMN represent a merger of business process and business decision (or business rule) technologies. This is a major step forward in our ability to smoothly integrate these two, seemingly separate technologies, into a common approach.

DMN is not complete yet. There will probably be at least one more draft and perhaps two. Similarly, slight changes will probably take place in the next release of BPMN to support the integration of the two standards. We will continue to report on developments as they occur. At this point, however, enough has been done to make it clear that henceforth processes and decision management will be part of any comprehensive business process improvement effort. Moreover, this work already makes it important that business process professionals add the ability to describe Decision Requirements to their basic set of process analysis tools.


  1. The team that has developed the first draft on the DMN includes: Martin Chapman (Oracle), Bob Daniel (Escape Velocity), Alan Fish (Fair Isaac, now FICO), Larry Goldberg (KPI), John Hall (Model Systems), Gary Hallmark (Oracle), Dave Ings (IBM), Fernando Jorge (Fair Isaac, now FICO), Robert Lario (Visumpoint), Christian de Sainte Marie (IBM), James Taylor (Decision Management Solutions), Barbara von Halle (KPI), Jan Vanthienen (KU Leuven) and Paul Vincent (TIBCO). In addition, the following persons contributed valuable ideas and feedback that improved the content and the quality of this specification: Bas Janssen (Rule Management) and Mark Linehan (IBM).
  2. If you have been following the recent work on Analytics, then you can easily reconceptualize Davenports model of the various types of analytic approaches as various types of Decision Models. (For an example, see Figure 1-2 in Thomas H. Davenport and Jeanne G. Harris's book: Competing on Analytics (HBR, 2007)). In essence, analytics focuses on identifying opportunities to create decision support tools for managers which are then embedded in processes, while the DMN approach is broader and focuses on how to analyze and define any possible decision that might be used in a business process. (Another recent trend is to speak of Analytics working with “Big Data” referring to the sense in which an Analytic system might mine large data bases to reach a decision. Again, for the DMN perspective, a large data base is just one more type of Input data.)
  3. If you want to learn more about the Decision Management approach, I recommend the following three books:
    • Barbara von Halle and Larry Goldberg. The Decision Model. CRC Press, 2010.
    • James Taylor. Decision Management Systems. IBM Press, 2011.
    • Alan N. Fish. Knowledge Automation. Wiley, 2012.

PDF Version

Paul Harmon

Paul Harmon

Executive Editor and Founder, Business Process Trends In addition to his role as Executive Editor and Founder of Business Process Trends, Paul Harmon is Chief Consultant and Founder of BPTrends Associates, a professional services company providing educational and consulting services to managers interested in understanding and implementing business process change. Paul is a noted consultant, author and analyst concerned with applying new technologies to real-world business problems. He is the author of Business Process Change: A Manager's Guide to Improving, Redesigning, and Automating Processes (2003). He has previously co-authored Developing E-business Systems and Architectures (2001), Understanding UML (1998), and Intelligent Software Systems Development (1993). Mr. Harmon has served as a senior consultant and head of Cutter Consortium's Distributed Architecture practice. Between 1985 and 2000 Mr. Harmon wrote Cutter newsletters, including Expert Systems Strategies, CASE Strategies, and Component Development Strategies. Paul has worked on major process redesign projects with Bank of America, Wells Fargo, Security Pacific, Prudential, and Citibank, among others. He is a member of ISPI and a Certified Performance Technologist. Paul is a widely respected keynote speaker and has developed and delivered workshops and seminars on a wide variety of topics to conferences and major corporations through out the world. Paul lives in Las Vegas. Paul can be reached at

Speak Your Mind


This site uses Akismet to reduce spam. Learn how your comment data is processed.