At the time of writing there are two major industry standards for modeling business decisions: The Decision Model (TDM) defined by Sapiens Inc, established in 2009 and documented in The TDM book by Larry Goldberg and Barbara von Halle and The Decision Model and Notation (DMN) an open standard defined by the Object Management Group (OMG) in 2014 and version 1.1 is due to ratified later this year.
In this article we explain why, given the choice, you should model your business decisions using DMN as opposed to any other notation. Decision modelers should understand how TDM and DMN are similar, how they differ and their comparative strengths and weaknesses.
A Few Words About Decision Modeling Notations
Once you accept the benefits of Decision Management and Decision Modeling you will know what Business Decisions are and the need to use a single notation, across your enterprise, to model them. Using a single, defined notation allows your models to be unambiguously understood, and shared, among distributed teams of business analysts. It increases the effectiveness of team collaboration and avoids misunderstandings. It allows consumers of Decision Models to focus on the underlying meaning of decisions and their accuracy—free from the need to understand the vagaries of each analyst’s preferred notation.
Why Use an Industry Standard Notation?
Industry standard notations have been designed and refined to maximise their effectiveness by many expert practitioners over years. The same cannot be said of a home grown notation. Furthermore, well designed notations can improve the integrity of business logic by exposing contradictions and gaps. Finally, use of industry standards makes it easier to procure expert help from the marketplace.
Why Use DMN?
It’s an Open Standard
DMN is an open standard which means it is not, like TDM, owned by a specific vendor or subject to restricted distribution. DMN is defined, ratified and freely published by the Object Management Group (OMG). The Object Management Group Inc. is an international, not-for-profit, technology standards consortium specializing in the development and custodianship of standard notations used by businesses in over twenty market verticals.
A full, current definition of TDM is reserved only for clients of Sapiens Inc (the 2009 book only partially documents the standard) and the only full implementation of TDM is their DECISION toolset (we discount superficial implementations like Visio templates). DMN (according to the DMN Tool Catalog) is supported by twelve toolsets (as of January 2016) and more are planned. The OMG ensure that the definition of the standard is available to all and this promotes competition.
It’s Built by Many Experienced Practitioners
OMG are also responsible for, among others, three world dominant standards for data, business process and model driven architecture modelling: UML, BPMN and MDA. The vendor team behind DMN includes Decision Management Solutions, Fair Isaac Corporation (FICO), IBM, Knowledge Partners International, Oracle and TIBCO Software Inc. This represents an enormous amount of collective experience in Decision Modeling. and standards administration.
It is Evolving
DMN was first made available as a beta draft in early 2014, version 1.1 is shortly to be ratified by the OMG and new versions will follow. There are number of web materials and a book on the integration of business process and decision modeling. In contrast the public definition of TDM has changed little since 2010.
DMN Has a Richer Set of Features
DMN Decision Requirements Diagram
Like TDM, DMN models have two views: the Decision Requirements Diagram (DRD), depicting the structural dependencies of decisions, and the Decision Logic Diagram (DLD), defining decision logic in detail.
The TDM structural view only depicts the dependency of decisions on sub-decisions (rule families), the DMN DRD depicts these but also includes dependencies on: Input Data nodes which depict sources of information; Knowledge Sources, or authorities, which are references to external business know-how, best practices, analytical models or compliance documents and Business Knowledge Models, a reusable element of business logic.
Both DMN and TDM define decision logic using decision tables. However DMN has many unique options that TDM does not offer:
- Representation of logic in many other formats such as text, decision flows, decision trees or a PMML analytic models.
DMN Decision Table
- Depict each rule as a row (as in the example), or a column or even in a crosstab.
- Specify a Hit Policy which determines the number of rules that may be satisfied simultaneously against one datum, the number of conclusions that can be generated, how these are ordered and—where multiple rows are eligible but only one result is required—how an outcome is selected.
- Support aggregation to yield one outcome from multiple satisfied rules.
- Support validation by constraining the values of specified columns.
TDM does provide a modeling method, structural and integrity principles and best practices (which DMN lacks). However these can all be applied to DMN.
DMN has Solid Foundations
All expressions and values in DMN are underpinned by an algebraic expression language (the ‘Friendly Enough Expression Language’—FEEL). FEEL is used for calculations and expressing conditions. It is powerful, has a well defined syntax and a rich set of types. TDM lacks this foundation and users of this notation are limited to using simple values or defining their own expression syntax which undermines the value of using a standard notation.
The Future
TDM is a closed standard, defined and exclusively owned by Sapiens Inc. Many aspects of TDM have not been formally published and are embodied only in privately available white papers and in the Sapiens DECISION product. Other TDM tools exist, but as the owner of TDM is a tool vendor, a two-tier support model has evolved. TDM is evolving closer to DMN, but its trajectory is known and controlled exclusively by Sapiens.
DMN is a relatively new open standard, rigidly defined by a widely circulated, publicly available specification. At least twelve vendors are currently working on tool support. Although little experience of using DMN exists in the market at the time of writing, it is very likely that this is where the bulk of future innovation and vendor support will lie in the coming years.
You can find out more about DMN and Decision Modeling from our new book and we now offer decision modeling training courses and mentorship.
Good article – succinct and very compelling.
I agree with many of your points but would highlight a couple of key observations, in my opinion:
– Evolution of DMN vs TDM – I agree that TDM being a closed standard and the fact that its documentation is limited to a book from 2009 means that, from a practitioner point of view where that practitioner is not using DECISION, its evolution is hidden from public view. However, putting that aside, comparing the evolution of DMN to TDM is like comparing an adult to a child; the child is constantly learning new things that an adult will already know, because they’ve gone through childhood themselves. There are things that have been debated in the DMN community during the evolution of 1.0 that were put to bed years ago by TDM.
– Features and foundations – again, agree that there are more features that TDM doesn’t have. However, as we know, with DMN being a standard there is no methodology (thus, step in the consultant with their definitive training and books). So what this actually presents in the first instance is a reduction in accessibility and a higher risk for confusion, complication, and growth of very poor practice. FEEL is going to be very challenging to business users; I’d go as far as to say FEEL may well put decision modelling out of reach of business users. In addition, without normalisation principles etc (which only come from a methodology) what you will see is what is in evidence by organizations that adopt BPMN or Agile – they’ll do it their way. Yes, some will come knocking for training, but the vast majority will not want to acknowledge the required investment. So what you will get is huge decision tables, some in rules-as-rows, some as columns, some as crosstab and what will result is an unholy mess. This is less of an issue with tooling, which, as you point out, is going to be more readily available through an open standard. However, if you look at BPMN and the proliferation of Visio, what you will know is that the actual implementation of usable BPMN, particularly at an enterprise, automated, level is very limited.
Despite these points, I do agree that the use of the open standard is the way forward, because it does make it more accessible overall. I think, like UML and BPMN, organisations will start to go for DMN properly when it hits 2.0.
Best of luck with the book – I look forward to reading it!
Nick
Thanks for your insightful comments, Nick. It’s good to hear from you again.
I was prompted to write this article not because James Taylor and I are writing a book about DMN, but rather to address a query from a long term client: “after training, mentoring and performing TDM consultancy for four years, why are Lux Magi now offering DMN courses and consultancy at the front of their service offerings?”
I absolutely agree that TDM has reached a level of maturity that DMN has yet to achieve. TDM has an elegant simplicity and its structural, integrity and declarative principles are highly valuable to clients and prevent poor modeling practices. I’ve written articles on this blog extoling the virtues of TDM. For this reason, Lux Magi still teaches and mentors TDM teams and would still recommend TDM to certain clients. However, my concern with TDM and the reason we usually recommend DMN to clients (if given a clear choice) is threefold:
• TDM, like an elderly adult is set in its ways and is less flexible than the younger DMN. For example, as you know: TDM insists that decision logic can only be defined by decision tables, other forms of logic (including analytical models as described in my articles) are not supported; TDM does not support the parameterized reuse of decisions as DMN does and TDM does not represent the dependencies of decisions on Knowledge Sources or Input Data. We have encountered projects where TDM’s lack of flexibility in these (and other areas) was a real liability. TDM is just too focused on decision tables and you know this isn’t suitable for all business logic.
• Many of the advantages of TDM arise from the fact that DMN is just a notation whereas TDM offers an approach to decision modeling including a method, best practices and the principles I mentioned above. Here’s the snag though: many of the benefits and best practices baked into the TDM approach can easily be applied to DMN (albeit with minor modifications), but the converse is not true. It’s easier to apply TDM best practices using DMN than to extend TDM to obtain DMN’s flexibility and power.
• DMN continues to grow, thrive and enjoy widening support at a much faster rate than TDM. This level of competitive evolution just keeps generating better tools and new ideas. So when a client asks us to recommend an approach for the long-term, it seems risky to propose TDM.
Now I realise that you probably have access to a more recent version of TDM than we do and it may be that some of the issues I’ve raised have been addressed by this newer version. My concern is that, in order for client to benefit from this newer version, they would have to select a specific vendor, Sapiens. I’m still not convinced by standards owned by individual vendors.
I agree that DMN is missing a methodology and a foundation of best practices, this is why I encourage our DMN trainees to read the TDM book and partly the reason I am collaborating with James on our book: to bring our collective experience of decision modeling to DMN users . Lux Magi is a strong believer in a well-defined decision modeling method. However, I’m not sure why you assert that this results in “a reduction in accessibility and a higher risk for confusion, complication, and growth of very poor practice”—using decision modeling for the first time is never just about obtaining a notation, buying a tool or even reading a book, surely it’s about building a partnership with an experienced practitioner who can guide you through your first projects and teach you best practices by application. Just as few people would learn to drive by buying a car and trying it out solo on the freeway, no one should expect good results by simply buying a tool and “having a go”—be it with TDM or DMN.
I think the concerns you raise about lack of training and the chaos this can lead to are entirely valid. But to some extent some TDM projects also veer this way as ‘power users’, anxious to overcome its considerable out-of-the-box limitations, graft their own ideas onto it with dire consequences .
However in two important respects I agree with you wholeheartedly: the unfettered use of certain DMN features (FEEL, certain hit policies, Business Knowledge Models to name a few) does invite ruin and FEEL will be very challenging to business users. Certainly it’s our view that FEEL should be avoided as much as possible by newcomers.
Thanks for the detailed reply, Jan. I certainly agree that the flexibility offered by non-decision table logic is one of the key advantages – the key will be the best usage of the different types, but that’s something that just comes with the development of best practice, which I’m sure is to come.
I also agree with your concerns re standards owned by an individual vendor; as we’ve seen with the likes of Apple, it can certainly work, but there must be an irrefutable and highly compelling offering to go with it.
It will be great to see how the book you and James put out will compare to Bruce Silver’s recent publication – it’s an exciting time for decision modelling and I think that is to do in a big way to the openness of the competition that stems from DMN’s evolution.
I concur: with the flexibility that DMN offers comes the responsibility of judiciously applying the right modeling techniques at the appropriate time. Ill-disciplined use of complex features for the sake of it could lead to decision models which are opaque to all but the most IT literate. The most important job of DMN (and TDM) is to communicate requirements and this is often, best realized using the simplest approach possible. Part of our book will address how to select which DMN features to use and which features are best avoided entirely.
I haven’t got a copy of Bruce’s book yet, but I have high expectations. I suspect it will be a hard act to follow.
Good article. The discussion however misses the critical distinction between a standard and a whole product. Sapiens/TDM is a product not a standard. A product can have a methodology and market-specific features that would be impossible to include in a multivendor standard. Nothing prevents a DMN tool from providing those. It’s a maturity issue. The anti-FEEL comments are also off base. It is only “hard” for complicated logic. You could say the same for Excel.
Also (sorry) I think Sapiens and I would both disagree with you that these languages are merely requirements definition for programmers using ODM or Drools. If that is all they ever are, they will have failed.
I see your first point, but the goal of this article was just to compare notational standards, not products or methodologies. I wanted to make that quite clear and avoid any confusion between these three concepts.
Sapiens DECISION is certainly a product that supports TDM. Is TDM a product or a standard? I think it is much less clear cut. Firstly because there are publications discussing the definition and use of TDM as a notational standard outside the Sapiens context, secondly because there are other tools, besides DECISION, that support the TDM notation and lastly because there are teams using TDM notation independently of Sapiens. I would argue that these three things make TDM a standard notation in its own right, albeit one with an evolution that is dominated by one product with an associated method.
That point that TDM has been combined with method and made into a product and that DMN could also benefit from this evolution was alluded to in my article, but, as I said, this article was focusing on notations, not products. I never asserted that DMN could be not be associated with a method as part of a product, in fact I think it’s already being done.
I have to say my project experience of FEEL must be very different to yours. Having taught the concepts to hundreds of people and mentored many projects, we are finding that FEEL is a challenge for many business subject matter experts and analysts. Great care has to be taken to avoid obscuring business meaning with FEEL. I totally agree with your point about Excel. Excel can be a powerful force in helping to convey business requirements, but its more powerful features can obscure the simplest requirements. However, the big difference between them is that FEEL is designed to represent and communicate business requirements clearly, Excel is not – it is just a spreadsheet. So FEEL should be held to a higher standard for clarity of communication.
Finally, I’m not sure how you got the impression that I said “these languages are merely requirements definition for programmers using ODM or Drools” – I don’t recall ever having said that and I certainly don’t think it. Indeed, in my article on “How DMN is Different” (http://blog.luxmagi.com/2016/11/how-dmn-is-different/), I point that that (in agreement with an earlier article of yours) the fact that DMN is executable is crucially important to its value and success. I would argue that clear communication of requirements is a central goal of all decision modeling notations because, in the absence of that, the remainder is much less compelling.