Modelling business decisions
Published:
Content Copyright © 2016 Bloor. All Rights Reserved.
Also posted on: The Norfolk Punt
I am a huge believer in using business rules management software, embedded in automated systems, to handle the business decision logic. Business rules can be related directly to the day-to-day experience of the business and are thus easily verified. They are also easily changed, perhaps by the business users themselves, without any risk of breaking the automated technology system they are embedded in, so rules are inherently more agile than the equivalent business logic implemented in low-level code. Business rules management software is, in effect, a very high level “no-code” language for describing what the business does, that can be executed to produce business outcomes.
But, can you go beyond this? I think so; and the evidence for this is probably the evolving Decision Model and Notation (DMN) standard from the Object Management Group, designed to complement the BPMN (Business Process Model and Notation) standard. This aims at not only providing a documentary definition for a manual decision-making process (specifying its “requirements”) but also at providing a complete and verifiable model for automated decision-making, that can be executed directly.
In conjunction with BPMN, DMN facilitates the building of a very high-level, no-code, standards-based, application development environment – driven from the business and verified directly by the business. In fact, I see this less as “application generation” and more as “business outcome automation”. The difference implies a move of power – ownership – away from IT and technology to the business, although I still see a role for the IT technicians, facilitating the operation of DMN and BPMN execution. In practice, of course, many organisations will choose to generate actual code, for portability and low-level maintainability, rather than rely on direct execution (although they’ll need the self-discipline to make changes only to the models and not to change the generated code); and, for a long time, they will have conventionally-coded systems too.
What I am now describing as “Decision Management” is a model-driven generator of practical, automated, business decision management systems embedded in model-driven, automated, process management systems. Do I hear cries of “we’ve been here before, but is it really practical this time?” Well, model-driven development in general (eg, Mendix) is certainly widely accepted now; and I’m not sure we’ve actually been here before precisely, as a decision management system is a lot more than just a business rules engine. The obvious question now is “in what way is it ‘a lot more’?” and this is understandable, as the world is full of vendors of “Business Rules Engines” re-branding themselves as selling “Decision Management” systems.
Basically, as I see it, sophisticated “natural language” Business Rules engines (which can check for rules consistency and coverage) may be evolving into Business Decision Management systems, but most are not there yet. My personal understanding is that the use of a structured Decision Management Model (with completeness/consistency checking and a more-or-less standard framework to comply with) is the key differentiator between Business Rules Management and Business Decision Management.
So, something like IBM ODM will have a set of natural-language-like Rules that can be checked for inconsistencies, and embedded in automated processes, but there is a discontinuity between Business Process and the rule system, which isn’t reliably bridged by relying on having well-named natural-language Rules, with good search facilities.
With a standards-based decision management model, you, potentially, have better governance from a structured, hierarchical model, which can be validated against the OMG DMN standard, as well as internally (for logical consistency and completeness), and which has formal (vendor independent) links to business process models. Or, as an interesting company called Sapiens Decision describes it: “The Decision Model (TDM) builds business logic structures within the scope of a single business decision. Each decision consists of families of business rules that can be represented graphically… Although the resultant image abstracts the details of individual business rules, further drill-down can reveal “rule families” in the form of decision tables. A rule family allows for the analysis of the logic of a business rule to ensure its integrity. TDM graphically displays business rules at several levels of decomposition detail, with each decision a connection point in the process”.
More importantly, perhaps, there are already some commercial implementations of DMN: Signavio Decision Manager for example (there’s a White Paper describing its methodological approach with DMN here); and Sapiens Decision, already mentioned, which has the most provenance.
Sapiens Decision by itself can point to enough successful use cases to make the ideas behind DMN well worth considering, especially as organisations start to struggle with the increasing complexity around operating in an agile fashion in increasingly regulated environments. The reinvention of the US Freddie Mac organisation, a federally backed mortgage conservatorship, which just about fell apart in the US mortgage crisis, is its prime success story, but it has others; and managing consent for GDRP (the EU General Data Protection Regulation), for example, suggests that there will be many future opportunities for its products.
Sapiens Decision, which I’ve been looking at recently:
1/ Has its origins in Knowledge Partners Inc and the work of Barbara von Halle and Larry Goldberg, who developed TDM and set up Knowledge Partners International (KPI) in 2007. They published a book about TDM in 2009. There’s an early paper on TDM in which, “using real-world statistics, Freddie Mac explains how decision modeling enables quick analysis and implementation of policy changes” here;
2/ Is built around enterprise-grade software developed by Sapiens and was instrumental, with KPI, in setting up the OMG DMN specification project in 2012. Sapiens acquired KPI in 2014 and formed a wholly managed subsidiary, Sapiens Decision. Sapiens Decision now operates largely independently of its owner, Sapiens;
3/ Now uses its version of TDM (it’s a bit in advance of the DNM standards roll-out; but Sapiens Decision committed to supporting the DMN standard as it evolves) to facilitate collaborative understanding of decision logic in order to support constant business change – in what Bloor would see as the Mutable Enterprise.
I see model-driven-development, of any sort, as a high-maturity activity – there’s nowhere to hide from the business (it’s highly transparent); it’s hard to hide misconceptions and inefficiencies in impenetrable code; and it helps the business to take ownership of its technology. So, it is interesting that Sapiens Decision also talks about a Decision Maturity Model, with maturity levels from 0 (unmanaged) to 5 (autonomic), and dimensions of business value, business architecture, and business stewardship. There’s no space here to discuss this in detail, but you can read more about it here.
Perhaps one of the most immediate benefits from this work is the innovative thinking it encourages. Take a look at Decision Infohub, for example. It’s a fast, efficient, data virtualisation tool, which can be made to capture just the subset of data needed for decision management. See Sapiens Decision’s pdf on this product here – it makes interesting reading.
In conclusion, please watch the DMN space as it evolves. I think a decision management modelling approach is going to be able to cope well with the conflicting demands for agility and better governance (at the same time) that are now affecting businesses as they journey towards being “mutable”. In addition, there is already significant investment being made in this approach; Signavio, for example, got 31 million euros from Summit Partners at the end of 2015, in order to “Fuel Growth”.