Every IT project has a number of stakeholders that need to collaborate to make the project a reality. This is of course also true of projects that have a Decision component, or of projects that are strictly Decision-based. And like any project they risk, depending on the organization, falling into the silo effect, where each group of stakeholders lives in its own little island, and very little communication takes place between the silos. This spells almost certain doom for the success of the project…
How can teams talk about their decisions?
For teams to be able to share a common understanding about the organization’s decisions, a way to describe these decisions needs to be used, and it needs to be accepted throughout the organization. There are several common options for describing decisions: free-form text, constrained text, tables, a business process model (BPM) or some other notation.
Free-form text can be used to describe decisions either using English sentences or in a pseudo-language. English sentences are understandable by everyone, but would often be verbose, and use jargon which may or may not be accepted by different teams. A pseudo-language, on the other hand, would need to be sufficiently expressive to precisely describe all situations, but would suffer from not being guaranteed of being accepted by everyone in the organization and of being used in a consistent fashion. Free-form text is however commonly used as it is easy to start with.
Constrained text is a variant of free-form text: here you would use some software constraining text entry to make sure that what is being expressed is done so in a manner that is consistent by all those contributing to the decision design. This would usually be enforced by a set of pre-populated or custom phrase templates.
Tables are very commonly used to describe decisions. Usually called decision tables, they provide quite a concise means to express them: in its simplest form, all the inputs to a decision are shown in the headers of all columns but the last, while the output of that decision is shown in the header of the last column; the values of the inputs and the output are shown in the cells of the table. This representation is effective to define what the inputs and output of a decision are, and to make sure that, relative to these inputs and output, no case is missed. It is also effective in being easy to understand by everyone in the organization, as long as what is in the cells is simple enough. This representation has however the drawback of making exceptions to the common cases a bit difficult to show, and also can be a bit redundant sometimes. To cater for this last issue, variants may be used, such as decision trees or decision graphs (which have the property of being able to bring together parts of rows that have the same value in the form of nodes).
A business process model (BPM) is a representation of a process in the organization; the OMG maintains a standard graphical notation for business process models, the Business Process Model Notation (BPMN). With appropriate training, all stakeholders in the organization can share the same way to describe a process, which may include business rules. The drawback to BPMN is that business rules are just represented as a task –so you still need a way to represent those rules on top of what BPMN provides.
Your organization may also come up with its own custom graphical notation. But the OMG has something else up its sleeve: the Decision Model and Notation (DMN). The DMN allows the description of decision models graphically, using a very small number of concepts (which makes it easy to approach). It also has the advantage as being supported by a number of tool vendors, thus making it easier to exploit and to ensure that the concepts are used appropriately.
Part 2 will describe DMN as a collaboration tool.
Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager
