James Taylor and I addressed requirements capture in great detail in chapter 12 our book ‘Real-World Decision Modeling with DMN’. It would be difficult to cover all the details here. Our approach on projects has been to split the work into a four stage iterative cycle: identify decisions, describe them, specify decision requirements and iteratively define them until it’s time to go through the completion checklist. I’ve already discussed where decisions come from in the webinar presentation, so here are some best practices:

1. Ensure the level of completion of your decision model fits the purpose: it will be different if you are capturing manual processes, trying to find an automation boundary, structuring decision logic or providing context for the use of analytics/cognitive decision-making.
2. Build your models incrementally – top down. Be driven by business need – not implementation detail. Otherwise you’ll get mired in the detail.
3. Ensure the value/effectiveness of decisions are measurable – there must be a return on your investment. Some projects forget to assign key performance indicators to projects and experience difficulties in proving their value later.
4. You must have a release and governance process defined. Decision models are not one-shot deliverables, they will evolve over time. You must have a means of supporting their iterative evolution. It will be dependent on the type of decision model: regulatory compliance and marketing decision models are likely to evolve in different ways. Manage models in a version controlled repository.
5. Run discovery workshops to look for new unidentified decisions periodically. This is especially important for digital transformation because you want to find new ways in which you can address the specific needs of customers as they emerge. If you company is first to spot and address the emerging needs of a new tranche of customer you will be more successful.

We covered this question thoroughly in our article Decisions and Rules: whats the difference.

In summary, although decisions and rules both have the goal of externalizing business logic from technical infrastructure, they are not the same. Decisions have a different level of granularity and a strong business (rather than technical) orientation. Decisions:

• answer a tangible business question (and are always known to the business);
• require business transparency because consensus must be reached on the decision-making process;
• have business owners and stakeholders;
• impact a business directly and have measureable performance (that can be associated with KPIs); and
• have outcomes that steer business processes.

Business rules are often too fine grain to have any of these properties.

Perhaps the biggest difference is that decisions articulate their dependencies (on sub-decisions, knowledge and data) explicitly, whereas rules do not. This means that decisions are much more scaleable than rules and able to tackle much more complex problems.

Finally, decisions have are represented using a standard notation (DMN), whereas there are as many different standards for representing business rules as there are BRMS vendors.

The webinar covered the fact that there are decision model execution engines that can compile and execute decision models directly. There is a frequently held misconception that the performance of these compares poorly to native programming languages.

Trisotech have a few partners who produce DMN execution engines: Red Hat, IDIOM and RapidGen. RapidGen, also partners of ours, has decades of experience optimizing the performance of decision table networks in aerospace, telecommunications and commercial applications. They’ve produced an engine which can process 100,000’s of decisions per second(*) if you require a high-performance DMN execution engine you should investigate this product.

(*) Performance of a baseline ‘loan origination’ decision model on a i7 laptop, details available.