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 …
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 …
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 …
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 …
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, …
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 …
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 …
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 …
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 …
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 …