Join Lux Magi and business partner, Trisotech, to discover how Decision Management addresses the key risks of regulatory compliance. This webinar outlined the practical difficulties of supporting mandatory regulatory compliance in finance IT systems and described how a key technique of Business Decision Management—Decision Modelling—can overcome these challenges. The benefits of using the Decision Model and Notation (DMN) were also presented.
The complexity and pace of change of regulatory compliance continues to escalate, as does the need for companies to explain their actions after the fact. Worse, corporations are expected to satisfy an ever increasing portfolio of regulatory mandates against shortening deadlines and many are overwhelmed.
This webinar explained how decision management and a decision model based approach can overcome many of the challenges of implementing compliance systems: aggressive deadlines, increasing complexity, inconsistent and ambiguous requirements, misunderstood data dependencies, constant change requests and the need for after-the-fact explanation and transparency. We illustrated the benefits of decision modeling using real examples from financial regulatory compliance. Join Lux Magi and Trisotech to discover:
- How DMN enables a model-driven approach to compliance that reduces the needs for code development, lowers the risk of error and improves agility
- Insights into how to automate and improve the transparency of your compliance implementations using the Decision Model and Notation (DMN), an open standard for modeling complex business decisions
- A live demonstration using Trisotech DES and DMN to model parts of a regulatory system
- Tried and tested DMN techniques for quickly determining your true data dependencies, handling change and improving accountability
Note: The webinar was held on October 19, 1700BST (1200EST) and a recording is available here.
Questions and Answers
This webinar raised some interesting questions about the process of decision modeling, how it relates to business rules and the performance of decision model execution engines. A summary of the points covered follows.
What are the best practices for requirement gathering at each phase?
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:
- 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.
- Build your models incrementally – top down. Be driven by business need – not implementation detail. Otherwise you’ll get mired in the detail.
- 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.
- 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.
- 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.
The decisions tables look a lot like rules, what’s the difference between decisions and rules?
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.
How well do decision execution engines perform?
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.