This year marks the fifteenth anniversary of Method and Style, and over the years it has held up well. Method and Style is a set of conventions layered on top of the BPMN standard - and, more recently, DMN and CMMN as well - intended to make the meaning of the model clear and complete from the printed diagrams alone. As a standard based on diagrams, BPMN promises "What you see is what you get,"
One of the most common mistakes beginners make with BPMN stems from lack of clarity as to what exactly BPMN means by a process. A BPMN process is a defined set of sequences of activities, performed repeatedly in the course of business, starting from some triggering event and leading to some final state. The key word here is "repeatedly". The same process definition is followed by each instance of the process.
Last month we discussed a valuable low-code implementation pattern using Business Automation Services to create event-driven database apps in the cloud. Upon receipt of a business event - a REST API call - the pattern involves a straight-through process that retrieves various database records, calls a decision service to generate additional records, and then inserts the new records in the database. The beauty of this pattern is that by using BPMN, DMN, and OData, subject matter experts can create executable implementations themselves without developer resources, greatly increasing business agility.
In my BPMN Method and Style training, I show the following BPMN and ask students, "What does this diagram say?" You really cannot tell. It says something happens and then either the process ends or something else happens. Not very informative. But if you run Validation against the rules of the BPMN spec... no errors! As far as the spec is concerned, it's perfect. But if the goal is to communicate the process logic, it's useless.
In my BPMN Method and Style training, we use examples like the one below to illustrate the difference between interrupting and non-interrupting boundary events: Here an Order process with four subprocesses could possibly be cancelled by the Customer at any time. As you can see, a single physical Cancellation message from Customer is modeled as multiple message flows. That's because the Cancellation message is caught by four different message boundary events, representing four different ways the message is handled depending the state of the process when Cancellation occurs.
[This post is my presentation at Decision Camp 2022, delivered September 27, 2022.] As a longtime DMN practitioner and from the beginning one of its biggest boosters, I am what you call a true believer. But while DMN continues to gain traction, even I would have to admit it has so far underperformed in the marketplace. The industry analysts say, "OK, we're aware of it... But what's the killer app?" It may not be what you think.
Occasionally in my BPMN Method and Style training, a student will submit a Certification exercise containing a Conditional event. I have always rejected that. Conditional events are not part of Method and Style, and that's because I have always considered them to mean "some magic occurs". According to the spec, a Conditional event may be used either as the Start event of a process or event subprocess, a Catching Intermediate event, or a Boundary event, triggered when its Boolean expression attribute becomes true.
For many years my work has focused on non-executable BPMN using a set of conventions called Method and Style. In the past year or two I have turned my attention to Low-Code Business Automation, based on executable BPMN. When I wrote my book BPMN Method and Style - over a decade ago! - I imagined that harmonizing executable BPMN with Method and Style would be a natural thing, but that never happened.
Cloud datastores are a new feature of the Trisotech Automation platform. They are most useful in BPMN, but they can serve also as input data in DMN. Datastores are a standard BPMN element representing persisted storage, accessed by a process task via data association but available for external access as well. In Trisotech's implementation, each datastore is a single relational table. It acts like a database but requires none of the extra work involved in using something like OData.
Recently I viewed a DecisionCamp presentation on an application of DMN to a public-facing portal in the Netherlands for what we call in the USA building permits. Here is the link. The scope of the project is impressive, combining regulations defined at the national, provincial, and municipal level, plus those of special districts. The ultimate decision on what kind of permit is required depends on not only the location of the property but the nature of the property improvement.