Uploaded byDecision Management Solutions
Extending Business Architecture with Regulatory Architecture using Decisions and DMN
This document discusses extending a business architecture to include regulatory architecture using decisions and decision modeling notation (DMN). It describes how a financial services company built a regulatory decision architecture by identifying key decisions from regulations, modeling decision requirements, and establishing automation boundaries. This helped connect business architecture to regulations, simplify implementation of rules, and inject analytics into decision-making processes. Challenges included gaining skills in decision management and integrating technologies, but a decision-centric approach drove process simplification and improved decision-making.
More Related Content
Similar to Extending Business Architecture with Regulatory Architecture using Decisions and DMN
Extending Business Architecture with Regulatory Architecture using Decisions and DMN
- 1. Extending Business Architecture withRegulatory Architecture using Decisions and DMN BUILDING BUSINESS CAPABILITY 2015 LAS VEGAS Gagan Saxena, VP & Principal Consultant Decision Management Solutions
- 2. We help organizationsplan, design, build and operate Decision Management Systems. Automate high-volume operational decisions using Big Data Analytics, Business Rules and Optimization Algorithms. 1 Decision Management Solutions
- 3. 2 Agenda 1. What isthe Problem we are Solving 2. Why Decisions and DMN were applicable 3. How does Architecture come into play 4. How was the Decision Architecture built and deployed 5. What were the Results 6. Challenges along the way 7. The Path Forward
- 4. Take Away Pointsfrom Today 3 • Business Architecture in Action • Central Role of Decisions in pulling Architecture together • Regulations and Laws can be managed and automated • Regulations = Rules = Policies = Guidelines
- 5. 4 Regulations: Compliance &Traceability • Regulations are ‘Knowledge’ that influence how decisions are made • But Decisions have never been formally described • Several layers of Legal Interpretation • Long lead times in 'programming' regulations • Implementing Business Rules was almost as bad as programming, since • No traceability or organizing structure
- 6. 5 Regulations = Rules= Policies = Guidelines • One decision can consume multiple ‘rules’ (and analytic models) • Some from regulators and others internal to the business • A coherent and consistent set of rules improves decision making
- 7. 6 Decision-Centric Knowledge Economy • Beyond Process Centric • But Big Data Centric • Predictive Analytics and Optimization Algorithms • Taming the Robot Overlords
- 8. 7 Why Decisions areImportant • First, Decisions are real, tangible ‘things’ that can be described, managed and improved • Decisions inject knowledge (rules, analytics, algorithms) into Processes • Decisions consume Information or Data • Decisions can be automated and automation boundaries established for clarity • Decisions Requirements drive Business Rules Implementation • Decision Requirement direct Project Portfolio Management and Prioritization
- 9. DECISION Information Knowledge ACTION Learnt Rules Patterns Predictions Trade-Offs Big Data BusinessRules Data Mining Predictive Analytics Optimization Information Knowledge DECISION MANAGEMENT TECHNOLOGY DECISIONCONSIDER FIRST DECISION ✔ 8 Harnessing New Technologies
- 10. ü Guidelines, Policy documents ü HumanExpertise ü Regulations ü Data describing the situation ü External reference data ü Predictive Analytic Models ü Data Mining Results ü The results of other Decisions 9 What is required to make a Decision?
- 11.
- 12. 11IMAGE COURTESY: IBM Can’tkeep Decisions in your Head To build fancy gizmos, we need to first document what is inside the head
- 13. 12 From Individual toOrg Decision Making • Capture Organizational Decision Making – Transparent, Reproducible
- 14. 13 Describing Decisions =DMN • Everyone need not describe their decision making in their own words
- 15. INDUSTRY STANDARD FROM OBJECT MANAGEMENTGROUP January 2014 14 Decision Management Solutions is one of the original DMN submitters Decision Model and Notation (DMN)
- 16. Information • What isneeded? • Where does it come from? Knowledge • How to make it? • How to improve it? Precision • Exactly how? • Specificity without technical details Context • Application • Organization • Business Goals 15 Need to Describe Decisions Formally
- 17. FIRST CANDIDATE FOR AUTOMATION 16 Knowledge Information Decision ManageAutomation Boundaries
- 18. 17 Decisions Connect BusinessArchitecture
- 19. 18 Key Steps: RegulatoryDecision Architecture Example – Regulation CFTC 43 Decision Catalog Decision Requirements Model Business Process Model Knowledge Source & Info Source Automation Boundaries Decision Table
- 20. 19 • Legal Language= Logical and Mathematical, Conditional • Rules about *how* to make decisions • Discover Decisions by framing Questions the Rule wants to consider • Definitions, Threshold Values = Knowledge • Entities under consideration = Information Sources Analyzing the Regulations
- 21. 20 CFTC Part 43Decision Requirements • Decisions Requirement Diagram for CFTC Part 43 • Decisions ‘discovered’ • Knowledge Sources identified • Information Sources identified • Overall dependencies and structure captured
- 22. 21 Common Decision PatternIdentified • Decision Requirement Diagrams from multiple Regulators built • Common Decision Patterns Identified • Common, reusable Decision taken forward for automation
- 23. 22 Block Trade SizeCalculation Decision • Automation Boundary established • Detailed Decision Requirement Diagrams built • Logic requirements captured as Decision Tables
- 24. 23 Techniques • Prototyping • AgileDevelopment • Formal Training Classes • Informal Check-in and Practical Hands on Work • Coaching and Guidance • Executive sponsorship and ownership • Constantly collect and share learning
- 25. 24 Results • Simplification • Consensus • Data Requirements • Implementation Plans • Shared Components • Governance and Ownership Structures
- 26. Agile Decision Requirements • Build diagrams quickly, finding and reusing objects or importing existing information Connect Decisions, Processes, Systems, Orgs • Put decisions into context, linking them to process, systems and organizations. Collaborate across silos • Accessible from anywhere, a social powered and collaborative environment supports multiple perspectives Integrate with your Approach • Define your own completeness levels and link to your BRMS, Analytics and Optimization 25 Decision Modeling Imperatives
- 27. 26 Challenges • Need toget up to speed on the concept of Decisions • Unclear distinction between Rules and Decisions • Limited or no skills in Decision Management • Need to demonstrate reuse and sharing of components • Constantly evolving process context; unclear workflows • Common Data Model evolving • Multiple technologies and systems, owned by multiple, independent tech teams
- 28. 27 The Path Forward • Beyond Regulations – Most Business Rules can be automated • Business Concepts need to be formally defined • Decision Centric Culture drives Process Simplification, Elimination • Decisions inject Big Data and Predictive Analytics into Processes • Decision Centric Culture key for ‘manual’ Decision-Making too
- 29. Take Away Pointsfrom Today 28 • Business Architecture in Action • Central Role of Decisions in pulling Architecture together • Regulations and Laws can be managed and automated • Regulations = Rules = Policies = Guidelines More at DecisionManagementSolutions.com