GDPR undoubtedly represents one of the most onerous regulatory mandates of the past decade—the first to explicitly demand an after-the-fact ability to explain your decision-making. So how can decision management help? (more…)
In this article I propose that every business analyst should be capable of identifying and modeling business decisions precisely and transparently. They should use a prescribed, standard format to describe decision-making that can be understood by other analysts with minimal explanation, rather than the individualistic, ad-hoc spreadsheets, text documents or technical business rules that they so often use today. Business analysts should be as proficient in modelling decision as they are with data or process and decision modeling should be a recognized as a ‘tool of the trade’. Being able to precisely represent business data, process and decisions should be seen as essential to the analyst role.
Without this skill, vital business knowledge will be buried in the volumes of incoherent verbiage that constitutes most written specifications; lost in the heads of SMEs who ultimately leave the company; or obscured in millions of lines of programming code or equally obscure excel spreadsheets where it may safely hide without fear of discovery.
In a recent article on the LinkedIn Group ‘The Decision Model and Notation (DMN)’, and on his own blog, Bruce Silver elegantly described why DMN is different to (and better than) other means of representing business decision models and asserted that these differences are set to make DMN of crucial importance to businesses that rely on their operational decisions. While I agree with Bruce’s feature list, I have some reservations about some of his observations.
While James Taylor and I were collaborating on our Decision Modelling book and discussing our experiences of using DMN with clients, the question “what additional features should be adopted in the next major release?” frequently arose. We found that our respective wish lists had a lot in common, reflecting our views on decision modeling best practice. We decided to describe these proposed new features in a series of posts and encourage readers to give their own opinions.
We’ve already explained our wishes for the decision logic level of the standard. Here we consider the requirements level, mainly the Decision Requirements Diagram (DRD). As with the previous article in this series, wish items were constrained to new or amended notation, not method or approach.
Given this, do you agree with our items? What features would you like to see included in the decision requirements level of the standard?
(more…)
While James Taylor and I were collaborating on our Decision Modelling book and discussing our experiences of using DMN with clients, the question “what additional features should be adopted in the next major release?” was a frequent subject of conversation. We found that our respective wish lists had a lot in common, reflecting our views on decision modeling best practice. We decided to describe these proposed new features in a series of posts and encourage readers to give their own opinions.
DMN (The Decision Model and Notation) is a way of representing Decision Models using diagrams and text; it does not address issues such as method or approach. Therefore wishes must be constrained to new or amended notation. Given this, do you agree with our items? What features would you like to see included in the decision logic level of the standard?
When James Taylor and I began our collaboration on our new book ‘Real World Decision Modeling with DMN’ it begged the question: ‘Why is a book on DMN necessary? After all there is a well-documented specification.’
The Decision Model and Notation (DMN) standard—a document defined and published by the Object Management Group (OMG)—does define the notation, so why is a book on Decision Modeling, and specifically DMN, needed? What can it do that the specification cannot? What should users of DMN be aware of that the specification cannot tell them? (more…)
Recent Comments