On Twitter someone posted to me: "Have you ever seen a short overview of BPMN that makes sense to people who have never heard of it?" Hmmm... Probably not. So here is my attempt. Business Process Modeling Notation, or BPMN, is a process diagramming language. It describes, in a picture, the steps in a business process from start to end, an essential starting point whether you are simply documenting the process, analyzing it for possible improvement, or defining business requirements for an IT solution to a process problem.
A frequent complaint about BPMN is that it cannot adequately describe many common business process scenarios, particularly when all possible flow paths are not known in advance. Actually, it can handle a good number of those, but many fall into a "gray area" - patterns that may or may not be technically allowed, depending on your interpretation of the spec. One of those scenarios concerns variant forms of an activity. If activity A has only two or three variants, the modeling is straightforward: You just have a gateway that branches to variant X, variant Y, and variant Z, each shown explicitly as a separate activity in the diagram.
Details of my BPMN Master Class on June 2 and 9 have now been finalized. If you know BPMN Method and Style and you want to take the next step, this class is for you! The class is split into two 5-hour sessions one week apart, so students will have time to complete problem sets assigned at the end of the first session and mail them in before the second session, when selected solutions will be presented.
This post is based on a talk I gave at the BBC conference in November. DMN, which stands for Decision Model and Notation, is a relatively new OMG standard. By unifying business decision modeling and execution, it hopes to do for Business Decision Management what BPMN did for BPM over the past decade, which is radically transform the business. Like BPMN, it is intended for business analysts and business users, not programmers.
By:
Bruce Silver
December 29, 2016
dmn
Read More
The one part of the spec that every DMN tool supports is the Decision Requirements Diagram, or DRD. It provides a business-friendly picture of the dependencies of a high-level business decision on supporting information. Rectangles in the diagram represent decision nodes. A decision has a name (the label in the rectangle) and a value determined by the node's decision logic, or value expression, such as a decision table. In a DRD, the solid arrows into each decision represent its information requirements, either a supporting decision or an input data element, the oval shape.
By:
Bruce Silver
December 29, 2016
dmn
Read More
A second key feature supported by every DMN tool is the decision table. In DMN, decision tables are one form of expression used to determine the value of a decision or BKM. Decision tables have been around for 40 years, but DMN defines specific formats and rules for their construction. In one common format, the columns of the table represent inputs and outputs, and the rows represent decision rules. The combination of an input column heading, called input expression, and an input table cell, called input entry, defines a Boolean expression.
By:
Bruce Silver
December 29, 2016
dmn
Read More
If DMN just wanted to be a requirements-gathering notation along the lines of BPMN 1.x, DRDs and decision tables would be enough. (And unfortunately, to many decision management vendors and consultants, those are enough!) But DMN has higher aspirations. Like BPMN 2.0, it seeks to unify modeling and execution in a single language, accessible to business people but powerful enough to handle real-world decision logic. In the end, DMN had to invent that language, called FEEL.
By:
Bruce Silver
December 29, 2016
dmn
Read More
Last time I mentioned that FEEL is just an expression language not a programming language. It does not have statements. It cannot create variables. But, of course, you need those to define executable decision logic! So where do they come from? What makes DMN business-friendly is that variables and their value expressions are created graphically, in diagrams and tables. We've already seen how each decision node in the DRD defines a variable of the same name, and how a decision table provides its value.
By:
Bruce Silver
December 29, 2016
dmn
Read More
All of the conceptual elements of DMN - their names, attributes, relationships to each other, whether they are required or optional, and so forth - are formally defined in the specification by a metamodel, a set of UML class diagrams. Here, for example, is the metamodel for a Decision: Closely related to the metamodel is the XML Schema, or XSD, defining the standard XML interchange format for DMN models. Here is the XSD for decision table inputs: The metamodel and schema define the internal plumbing of DMN.
By:
Bruce Silver
December 29, 2016
dmn
Read More
While unifying decision modeling and execution is a laudable goal, OMG realizes not all DMN vendors and practitioners want to do that. So DMN defines three levels of conformance to the standard. A tool vendor can implement just a sliver of DMN and still proudly slap that "standards-based" label on their software. Conformance Level 1 (CL1) applies to tools that support DRDs and non-executable decision tables. Non-executable means the decision logic may be defined informally, in natural language, for example, and makes no presumption of completeness, consistency, or even common sense.
By:
Bruce Silver
December 29, 2016
dmn
Read More
