1. Peter Schooff
  2. BPM Discussions
  3. Thursday, January 26 2017, 09:49 AM
  4.  Subscribe via email
Keith Swenson recently wrote this blog post on DMN. Do you see Decision Management and DMN playing a central role in the future of BPM?
Emiel Kelly Accepted Answer
In the end we need decisions, not decision models. But to support those decisions or to automate them, why not?

Oh wait; you said a "central" role in BPM. Not sure about that. That will still be the coordination of cases, I think.
Sharing my adventures in Process World via Procesje.nl
Keith Swenson Accepted Answer
I think that a large component of what a business process is to do is to process things correctly, and a large part of that is deciding what to do. A help desk or support processes is almost purely about deciding what is wrong and what to tell people. In the past the nodes in a process than branched the flow of the work have been called by "decision nodes" by some people. Some BPM processes were drawn for production use with many such boolean branches to end up with a "decision" about how to handle a case.

Breaking this logic out of the process diagram is a recognition that the flow of work, and the flow of the logic should not be tied together. Forcing the branches to occur at particular steps in the process forces the process to sometimes be constrained in unnatural ways. DMN represents a maturing of how we model and automate the work that people do.
  1. https://social-biz.org/2017/01/18/dmn-technology-compatibility-kit-tck/
  2. https://social-biz.org/2017/01/25/how-do-you-want-that-standard/
  3. https://social-biz.org/2016/05/10/dmn-at-bpmnext-2016/
One underestimated implication might be easy bridging of classical BPM to AI and BI through DMN because it actually encodes decision trees, which are so common in these disciplines.
  1. Boris Zinchenko
  2. 3 weeks ago
@Keith.. Good point re ". . . the flow of work, and the flow of the logic should not be tied together", the main reason being that flow is heavily dependent on data content and on resource constraints.

Not sure what to say re "Forcing the branches to occur at particular steps in the process forces the process to sometimes be constrained in unnatural ways".

For sure, when we get to a stage where it becomes necessary to branch, but no data input is needed (all of the needed data has already been picked up at upstream nodes), then why not automate?

Decision boxes in my system distinguish between manual (requiring a particular class of user to make a selection) and "auto-commit" where the step has a routing of "system" and thus never gets to be seen by an "person".

It is, however, essential that the step be in the history, with its date/timestamp and "user" signature plus which node(s) fired.

For QA, it's never encumbering (except to the mappers) to have auto-exec "gatekeeper" nodes across a process (again, encoded to "system") - extremely useful for holding up processing until an external event posts data that is referenced at the gatekeeper node rule set. i.e. has the external part arrived?

Lest we let people think that IoT is "new", it is good to remind them that industrial process control systems are mostly made up of remote devices that contribute data and that the data causes branching (i.e. reduce the fuel to the furnace if the temperature goes above 1,500 deg F).
  1. karl walter keirstead
  2. 3 weeks ago
As far as I understand, DMN does not cover behaviour rules. Can a contract be formalised in only DMN to become digital?

Of course it can cover that as well, sometimes by itself, sometimes in conjunction with BPMN flow constraints, sometimes in conjunction with interface authorization constraints.
DMN can out-of-the-box deal with most computation rules either via the FEEL language or via the COLLECT hit policy of decision tables.
And of course some decision engines are compatible with general scripting languages (eg Javascript, Groovy) in order to model and execute any kind of business rules one would dream of.
  1. Bogdan Nafornita
  2. 3 weeks ago
My customers have been using what we call "Branching Decision Boxes" for years.

If you were to put today's question to them, they would respond with NO, given the wide range of needs for branching (e.g. user single pick or multi pick not based on upstream data; auto-branching to a single sub-path based on upstream data collected, .. to two or more sub-paths, to all sub-pathways).

In some process maps our customers build you might find nothing more than one or two branching decision boxes, in others you might find that 20% of the nodes are branching decision boxes.

Here is an extract from an article I wrote "Decisions, Decisions, Decisions" (2014/12/02).

Click on the link below if you would like to read the entire article.

Decision Branching Boxes along Process Template Instances
Branching Decision Boxes accommodate selective branching to one or more downstream sub-pathways at certain steps along process map templates.

Not all Process Steps need to be “performed” – some steps do nothing more than cause branching to one or more sub-pathways downstream and we call these steps “Branching Decision Boxes”.

In some environments, a decision box can be formed simply by lassoing two or more ordinary process steps and making certain that each has the capability of resolving to TRUE under certain conditions.

Clearly you need a Boolean variable at each step that best starts off with a value of FALSE, with an ability to evaluate to TRUE under certain conditions as detailed in a Rule Set.
  1. http://wp.me/pzzpB-CX
David Chassels Accepted Answer
Decision making is just part of any end to end process and should readily be supported by both BPM thinking and the Digital Business Platform.....might be a case for very specialist need but really think DMN will head same way as BPMN....RIP....!
Without BPMN and/or DMN, how will work be systematically automated? BPMN and DMN are "public languages". They can be deployed completely, or via subsets. If they are not used, then the only alternative -- by definition -- is "private language". In other words, home-grown code, frameworks, less-popular process and decision languages, pieces of paper, or built-in to someone else's on-prem or cloud application. The work still has to be done, work defined as "process"+"decisions"+"data". And in all but the simplest businesses or smallest projects, processes and decisioning can benefit from using common, shared, public specified languages. Business can do accounting on spreadsheets -- but it's much better to use standard accounting practices and accounting software. Process and decisioning are not yet at the same level of social organization as accountning -- and may never be, but they are proceeding in that direction.
  1. John Morris
  2. 3 weeks ago
Agree. Decision management services must be available for BPMN as well as "normal" applications and services.
  1. Dr Alexander Samarin
  2. 3 weeks ago
One of aspects of "systematically automated" is that the same business rule is defined once and is used from everywhere. Separating of process routing logic and business logic allow to use the latter in internal processes, classic applications, batch scripts, customer interactive forms, etc. Usually, it is done by extracting the business logic from monoliths and wrapping it as a set of microservices.
  1. Dr Alexander Samarin
  2. 3 weeks ago
Next generation with low no code will remove need for Notation languages with all business logic including rules events decision making etc just ready to customise by Business people....already proven just a question of time.....
  1. David Chassels
  2. 3 weeks ago
@Alex -- per your comment on "systematically automated" -- you have described the normalization of rules -- which like the normalization of data (OK, rules are a structured superset of data, we could use the term ontology too) is essential for managing complexity.
@David - low code is still code -- and the code itself must be based on a language (a.k.a. a "notation", although an executable language is bigger than a notation). Without language, it is just "ad hocery", which you might say is "real time entropy". : )
  1. John Morris
  2. 3 weeks ago
John.....our 20+ years of R&D and working with early adopters have proven that my proposition some even Bill Gates call the dream holy grail etc to remove need to code is now a reality. The recent discussions indicate how but at core is fact the support people or machines where new information is created never changes...the delivery does the pony express is now the web....the horseman does the same things ....think about it....? We identified as tasks then code as generic capabilities just needing easily configures and of course I included powerful linking. All stored in a relational database bit like SOA in a box with build in graphical designer click and declares to RDBMS where a process engine automatically sets up ready to run. No code generation or compiling makes change easy....Brings order where disorder exists......
  1. David Chassels
  2. 3 weeks ago
John Morris Accepted Answer
Bravo the work of systematising operational decisioning thru DMN!

As @Keith points out in his blog post, vendors are only implementing part of the DMN spec so far. But the whole spec is a huge step forward from decision tables, and the more that can be implemented, the better.

From a management perspective, "decisioning" is not just "one of the things that managers do", it's almost the only thing that managers are or should be paid for. Decisions are where value is created -- whether at a micro operational level or a macro strategic level.

Consider systems theory or biology, an enterprise, actor or entity navigates it way through hazardous space (e.g. a forest, or competitive space), and is constantly sensing the environment, analyzing alternatives -- and taking decisions. In Europe (mostly), the term cybernetics is applied to this process, and is based on the idea of the "steersman", i.e. the decision-maker.

So, if from a management perspective decisioning is centrally important, any good effort to engineer the technology of decisioning is also centrally important. Why should accounting and ERP and process management all be automated -- and not decisioning? To bring decisioning under the umbrella of automation and engineering to reach another frontier of modern rational management. (I'm using the term "automation" here in the most general sense of "technology which helps us with our work", and not only as "doing work autonomously".) Recall too the benefits of modern rational management: transparency, manageability, governability, accountability, etc. All these things can be achieved "manually", but decisioning is enhanced when deployed in purpose-specific technology.

If BPM is to move beyond STP ("straight through processing" ) of commodity business processes, then that achievement will be because BPM is able to better handle the richness of reality -- to respond better to complex situations. A big part of handling complexity better is decisioning, based on sensing and analysis. (And as DMN is moving into market, our ability to sense and analyze is also exploding.)

DMN enables BPM to move from commodity business processes to business processes with greater value-add. DMN makes BPM better.

DMN is centrally important to the future of BPM technology.
DMN is centrally important to DBP not only BPM.
  1. Dr Alexander Samarin
  2. 3 weeks ago
@Alex -- good point about "the platform". It would be worth defining examples, via architecture, as to where managed decisioning in an enterprise happens both (a) standalone and (b) as part of a managed business process.
  1. John Morris
  2. 3 weeks ago
You bring up a good point about the kind of decisions that managers do. DMN uses the word "decision" but it really is only about routinized formal logic processing a set of discreet data values. That is useful to make "smarter" automated business processes, but it will not in our lifetimes replace a manager. In BPMN the exclusive gateway really only handles if-then-else kinds of logic, which can express a lot, but DMN makes it much easier to express much more complicated logic. But --- this is not going to replace people any time soon.
  1. Keith Swenson
  2. 3 weeks ago
@Keith +1 your comment about replacing people. I completely agree -- and managers everywhere will be relieved to consider they still have a reason to come in to work (they actually know this of course -- it's the technologists and boards who sometimes don't perceive the complexity and value of many so-called routine jobs). Your comments could apply to AI too I think -- and AI is amazing for sure -- but life and work are richer than we think in terms of complexity. None of this realism though should detract from the value of DMN: for those systematic things that managers already organize, DMN will prove very useful. (It will be interested to see the rate of adoption.)
  1. John Morris
  2. 3 weeks ago
Boris Zinchenko Accepted Answer
Personally, I admire DMN for elegance and clarity, even apart from bright prospects on compatibility of execution. This apparent clarity is not accidental. There exists deeply rooted and not justified prejudice about BPM as a world of diagrams. However, BPM is a world of processes, and processes are not always best viewed as diagrams.

Graphs, which serve as an adequate abstraction for most BPM processes, can be represented in multiple ways. Diagrams are only one way of their representation, universal but not always ideal. There exist multiple powerful techniques to visualize graphs as tables. For example, adjacency lists [1, 2] are well suited for decision trees [3]. Tabular representation is often preferable to traditional diagram representation. Not accidentally, tabular process view is getting more and more popular in mainstream BPM software. It is enough to mention connection matrices in ARIS.

DMN is another excellent illustration on how productive can be tabular process representation for business processes. Simplification and clarity in reduction of classical BPMN gateways into compact DMN tables is simply stunning. With all limitations, DMN illustrates how powerful can be even a local generalization of process rules in a compact rule set for interoperability of process tools. Hopefully this way of small unified steps will make more for ultimate BPM standardization than many global and universal initiatives, which failed before.

  1. https://www.khanacademy.org/computing/computer-science/algorithms/graph-representation/a/representing-graphs
  2. http://courses.cs.washington.edu/courses/csep521/99sp/lectures/lecture01/sld029.htm
  3. https://en.wikipedia.org/wiki/Decision_tree
  4. http://www.saedsayad.com/decision_tree.htm
Bogdan Nafornita Accepted Answer
Executable Decision Modelling will be huge (hopefully DMN can take the lead before it is accused of choking decision-making innovation :D )

I see three main reasons for that:
1/ change management - a change-driven process architecture (does any other kind even make sense?) must have at its core a decision engine - in most change cases, it is not the process that gets changed but actually the rules by which the flow of work is conducted;
2/ execution automation - what we call today decision tables are actually rules tables. A rule is an automated decision, it doesn't imply thinking at run-time, only at design time. This type of automation is already available, but will eventually (hopefully) grow in adoption;
3/ decision auditing - for the non-automated decisions, decision engines will retain the information context in which that particular decision was made. This creates new opportunities for an evolved role of the business auditor.
Managing Founder, profluo.com

I'm fascinated by "a . . . . process architecture must have at its core a decision engine".

All of the rules we work with are set plan side. This seems consistent with your “change management” rules.

At run-time, however, we have no ‘decision tables’ or ‘rule tables’ – rather, rules are parked at forms that have been attached to process steps. These rules only “wake up” as and when steps become current along a workflow.

There are three types of rules recognized in our mapping environment
a) Calculation Rules that operate on data that is available at the time a step becomes current
b) Final Rules operate on data and / or calculation rules
c) Form Rules that allow forms to ‘fire’.

There is no opportunity for “thinking” at run time if a process step is of the type auto-commit. Auto-commit means the step has a routing of “system” so no humans are able to intervene, other than do a supervisory override to move the processing along.

If the step is not of type auto-commit, the user can take action based on any warning messages (or ignore such messages in the case of ‘soft rules’) or, they can take note of the results of rule set processing and make any number of decisions impacting forward processing (or loopback or exit).

I recall other discussions about the relative merits of handling rules one way or another. It might be interesting/beneficial to explore different rule set configuration pros/cons in a separate discussion.

A good starting position would be for each ‘school’ to list what their rules have problems with and see if the other side has a way of handling such problems.

My general approach is to prevent execution of a process if things are not right and then within any executing process prevent engagement of a step if things are not right. Another objective is to require re-execution/re-engagement if things are not right on exit from a process or a process step.

In this discussion about standards, it’s a bit scary to have two seemingly separate ways of accommodating decisions based on rules – evolving a standard for one of these would result in sub-optimization if the choice proves to be less effective/efficient than the other.

See below “Check Your Business Rules on the way in and out” (2014/05/31)
  1. http://wp.me/pzzpB-yz
How much language, how much notation is needed for user-friendly BPM?

How much effort is needed to build, test and roll out a process template?

If you are curious, click below to view a 14-minute video on mapping a 6-step e-Learning Application process followed by rollout and production use of the resulting template in a run-time Case environment.

The video builds the process from scratch, builds six data collection forms from scratch, sets global variables, builds rule sets, and sets process step routings followed by rollout and processing of two instances.
  1. https://youtu.be/tFkNcc-jw58
  • Page :
  • 1

There are no replies made for this post yet.
However, you are not allowed to reply to this post.