Table of contents for Building Business Capability 2015
- Business Analysis and Architecture with Decision Modeling
- Extending Business Architecture with Regulatory Architecture using Decisions and DMN
- Good Old UServ Product Derby in the Brave New World of Decision Management
- Avoiding Risk Management Failure: A Case Study in Process Improvement and Risk Mitigation
- 50 Ways to Boost Your Business and Decision Analysis
- Lessons learned from the real-life deployment of Decision Management at scale
- DMN Demystified: The Decision Modeling Revolution Starts Now!
Gagan Saxena, also of Decision Management Solutions kicked off the first day of sessions for me at this year’s Building Business Capability show in Las Vegas. Gagan has been working on a large financial services client’s regulatory initiative and presented on the role of decisions and DMN-based decision models on regulatory compliance. A business architecture with decisions at its center, he says, is increasingly central to the way you can manage regulations and laws.
The problem at issue is how to ensure compliancy and traceability with respect to large, complex regulations. These regulations represent knowledge that is meant to influence our decision-making yet in most organizations there has been no attempt to understand and formally describe these decisions. This is made more complex by the number of players – layers of interpretation of the regulations get created in addition to the core regulation. All this verbiage is condensed into requirements and then implemented, creating potential confusion and a lack of traceability/explicability.
This organization tried to use business rules in this process but this remained very complex as it is easy to create many rules without it being clear how to manage and structure these rules – by line of business, geography, or something else? All choices seem equally bad due to overlap and reuse between the rules. In addition the different players were adding their own layers of rules, policies, guidelines and interpretations. This adds to the complexity.
All this led the organization to refocus on decisions. It became clear to some folks in the organization that the decisions in their operational processes, the day to day decisions that are meant to be constrained by the regulation, were the persistent and most applicable element in their solution. Decisions they saw could be used as a structuring element for all these different rules, grouping them into the decisions that must be made regardless of the source of the rules. This decision-centric approach is a way to deliver on the promise of the knowledge economy, building knowledge-driven processes by focusing explicitly on the decisions involved.
Decisions are real and tangible, they can be identified, described and managed. Once identified, decisions allow you to inject your knowledge (and your regulations) into your processes effectively. This knowledge might be rules-based but it could also be analytic or mathematical knowledge. And an understanding of the decision making allows you also to identify the information that is needed. This is particularly critical when thinking about organizational decision-making rather than just individual decision-making, especially in a large organization where there many players.
The moment of clarity for this client was the recognition that decisions break down into pieces – into other decisions that are required before the overall decision can be made. For this client this allowed them to re-assess how much decision-making can be automated – where does the automation boundary fall today and tomorrow? It also let them see how the various decision-making technologies (business rules, data mining, predictive analytics, optimization….) fit together, how they can be used in combination.
To model these decisions the client picked the new Decision Model and Notation standard. DMN allows you to describe the question you have to answer to make the decision and then model the information and knowledge needed to make this decision as well as the other, smaller decisions that must be made first. And this needs to be put into an organizational and business context – who is involved, who cares, who has to approve and facilitate. All of this can be captured in a decision requirements model and mapped into the business context.
Critically for this client these decisions are made in the context of the processes the client used to run their business. It also had to be linked to the other elements of this client’s business architecture – i’s data architecture, systems architecture and so on.
To develop the Decision Architecture, this client began with the regulation itself. Identifying the decisions that it is intended to influence. These need to be modeled, using a decision requirements model, and put into the context of a process model. These decision requirements models can then be extended with a specific information model and decision logic in decision tables to fully define how the decision should be made.
The regulations themselves are generally logical and mathematical, laying out rules about how you are supposed to make decisions. One can find the decisions in these regulations by framing the questions that the rules are meant to impact. Threshold values, definitions and more can be turned into knowledge while the data being considered can be mapped to the information in the decision. Critically the client found that a decision requirements model built from the regulations could be used to engage all the various groups involved. Legal teams could add their interpretation into the model directly, business owners could see the implications of the regulations and more. And overlapping pictures from different sections of the regulation could be combined to see reuse, common decision-making, standard information etc. This is where this model started to become an architecture with shared data, shared decisions, multiple elements referencing the same specific sections of the regulation.
The decision models built are widely usable and understood, supporting a wide range of analysis techniques – prototyping, agile development, workshops, executive support and sponsorship. Many of these models were developed collaboratively by groups from very different silos – from legal to IT.
Challenges including shifting data and systems architecture. In particular some old systems contained logic that had to be replaced with this decision model and this kind of legacy modernization is tricky.
Moving forward this client is looking at rules beyond those driven by regulations. A focus on the business concepts and a more decision-centric culture is also helping simplify business processes by externalizing and managing decisions. There is also some interest in adding big data analytics into these decisions, using the models to see how machine learning and data mining could drive the decision making. Finally could this approach be used to specify how dashboards and visualizations need to support decision-making consistently and accurately?