11 years, 2 days ago

The Decision Model, Enterprise Architecture, ArchiMate and “The Decision Modeler”

<p class="p1"><span class="s1">In my previous post I discussed my Three Decision Model Predictions and how they were realised by BiZZdesign ‘<a href="http://www.bizzdesign.com/tools/the-decision-modeler/" target="_blank"><span class="s2">The Decision Modeler’</span></a> – a new TDM tool.</span></p><p class="p1"><span class="s1">In this post I shall first explore the relationships between The Decision Model (TDM) and various Enterprise Architecture and design models, and why it is important to be able to model the dependences between TDM and other design and IT domains. </span></p><p class="p1"><span class="s1">Then I will show that BiZZdesign, using “The Decision Modeler” and ArchiMate tools, has become the first vendor to enable TDM models to form inter-model relationships and the advantages that brings to IT and the business.</span></p><p class="p1"><span class="s1">Wikipedia defines <a href="http://en.wikipedia.org/wiki/Archimate" target="_blank"><span class="s2">ArchiMate</span></a> (a technical standard of the Open Group) “[as] an open and independent enterprise architecture modelling language to support the description, analysis and visualization of architecture within and across business domains</span><span class="s1">in an unambiguous way.”</span></p><h2 class="p1"><span class="s1"><b>The Big Ball of Mud</b></span></h2><p><span class="s1">It was Foote &amp; Yoder who in 1997 described early application software as being a “big ball of mud” because all the aspects and concerns of an application were all mixed together without any perceivable architecture.  Later, it became apparent (see figure 1) that if one could separate out each aspect or concern of an application into its own component model, that it would be much easier to develop and maintain separately each aspect as well as the entire application.</span></p><p><span class="s1"><img alt="Balls of mudd or software applications?" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-software-applications_400x307.png" style="width: 400px; height: 307px;" title="Software applications are balls of mudd"/></span></p><p><span class="s1">However there was one aspect which did not have a rigorous technology independent model and that was the business logic component, or business rules.  This problem was solved with the invention of <a href="http://www.kpiusa.com/index.php/The-Decision-Model/the-decision-model.html" target="_blank"><span class="s2">The Decision Model</span></a> (TDM).  All previous attempts had failed in creating a modelling language that could both tame the complexity of business logic and at the same time make it understandable to both business and IT users.</span></p><p class="p1"><span class="s1">One of the brilliant insights that the inventors of The Decision Model (Barbara Van Halle and Larry Goldberg) had was to tame the complexity of business logic using “business decisions” as a first class business logic concept, and then to invent a business logic model based on the inherent structure of logic and the business logic required to reach a business decision.</span></p><p class="p1"><span class="s1">The next insight they had was to choose a graphical notation that was simple for the business to understand yet expressive enough for IT; and then to marry this graphical notation with the 15 The Decision Model principles (declarative, structural and integrity principles) required to provide The Decision Model models with logical rigour.</span></p><p class="p3"><span class="s2">For further information on the 15 The Decision Model principles read the book “<span class="s3"><a href="http://www.amazon.com/Decision-Model-Framework-Technology-Management/dp/1420082817" target="_blank">The Decision Model : A Business Logic Framework Linking Business and Technology” by Barbara von Halle and Larry Goldberg.</a></span></span></p><p class="p1"><span class="s1">Business and IT could now use The Decision Model to extract all the business logic that are embedded within existing enterprise architecture, design and IT models and code into separate The Decision Model models, each linked to a business decision that the business wants to manage.</span></p><h2 class="p1"><span class="s1"><b>Integrating The Decision Model models with other models</b></span></h2><p>Having separated out from the “big ball of mud” and created The Decision Model models there is also a need for the integration and connections between The Decision Model models and other design and IT models to be modelled for the following reasons:</p><ul><li class="li2"><span class="s1"><strong>Creating Decision-aware process models.</strong> <br/> Having extracted business logic from a process   model and created one or more The Decision Model model, it is essential that a connection between a process task that is to execute a business decision and the The Decision Model model for that business decision.<br/><br/><span class="s1">This connection can be modelled graphically using shared metadata (in this case the name of each the business decision that is to be evaluated (see figure 2).  in BPMN notation the connection point is the name of the business rule task having the same decision name as a The Decision Model model. Figure 2 (taken from The Decision Modeler) shows the link between a business rule tasks (in the process domain) and the The Decision Model models (in the business logic domain).<br/><img alt="Business rule tasks and The Decision Model" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-rule-tasks_399x283.png" style="width: 399px; height: 283px;" title="link between a business rule tasks and the The Decision Model models"/></span></span><br/>   <p class="p1"><span class="s1">In fact since business rule tasks are determining a business decisions and should really be called decision tasks. It is possible in BPMN to a define decision task as a stereotype of a business rule task and then to decorate the decision task with the The Decision Model blue octagon, to differentiate between an ordinary business rule task and a decision task.</span></p> <p class="p2">The Decision Model models do not implement actions directly; they only determine decisions based upon the execution of business logic. The results from the execution of a The Decision Model model can be returned to a decision gateway in the process model; which then determines and routes the subsequent actions that are to be executed based on the results returned.</p> <p class="p2">If an executable BPM modelling language like BPMN 2.0 is used, then it is possible to execute the BPMN process models in a BPM engine which consumes The Decision Modeler models in the form of Decision Services running in a business rules engine.</p> </li> <li class="li2"> <p class="p2"><strong>Enable the Model-Driven Application (MDA) generation of code and other executable artefacts.</strong> <br/><span class="s2">Figure 3 shows the natural connections that exist between The Decision Model models and many types of models, these include UML, Logical data models, Use Case, Object Model, Fact Models, Business Process Models, etc.<span class="s2">Once all the dependencies between a The Decision Model model and other dependant models are determined and modelled it is often possible for software to convert these models into executable artefacts with reduced programmer input leading to increased productivity and reduced defects.<br/><img alt="The Decision Model has natural connections with other models" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-natural-connections_400x311.png" style="width: 400px; height: 311px;" title="Natural connections between The Decision Model and many other models"/></span></span><br/><br/><span class="s1">MDA-driven and The Decision Model-based applications offer the potential for a new frontier in enterprise applications. Gone will be the days of expensive consultants tailoring complex enterprise applications where all the business logic has been hard-coded into the application code.  Instead a customer need only tailor the relevant The Decision Model models (provided by the enterprise application vendor) to their requirements and then “re-generate” the enterprise application – saving substantial costs and increased business agility.<br/><br/> This The Decision Model frontier is yet to arrive but I predict it will be 5 years before such applications arrive – driven by the next generation of agile The Decision Model-driven enterprise application vendors.</span></p> </li> <li class="li2"> <p class="p2"><span class="s1"><span class="s2"><strong>Using The Decision Model to Manage IT Operational Systems.</strong> </span><br/> Many middleware and Service Oriented Architecture (SOA) vendors are now designing their technologies so that a combination of business rules, complex event and BPM engines can be used to model and implement the business logic required to operate and manage their infrastructure.</span><br/><img alt="Service Oriented Architecture" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-service-oriented-architecture_316x272.png" style="width: 316px; height: 272px;" title="Service Oriented Architecture (SOA)"/></p> <p class="p1"><span class="s1">In fact many Enterprise Service Bus (ESB) middleware contain the ability to perform routing based on dynamic rule bases. There is nothing to prevent the business logic that an ESB requires to be developed and maintained using from The Decision Model models.</span></p> <p class="p1"><span class="s1">The ability to connect The Decision Model models that are being used to manage IT middleware (such as Figure 4) to components within the architecture is an exciting new development for The Decision Model.</span></p> <p class="p1"><span class="s1">Until now, The Decision Model was being considered primarily for developing business applications rather than for controlling and managing complex IT execution platforms and middleware.</span></p> <p class="p1"><span class="s1">It is important to realise that The Decision Model models can be automatically converted not only into rules that can executed in rules engines but can be converted into languages such as Java, XML, etc.</span></p> <p class="p1"><span class="s1">The ability to model the inter-model relationships between models of IT infrastructure components and The Decision Model models will be required to meet traceability and governance requirements.</span></p> </li> <li class="li2"> <p class="p1"><strong><span class="s1"><span class="s1"><span class="s2">Linking The Decision Model with Strategic Models.</span></span></span></strong><br/><span class="s1">One of the advantages of ArchiMate is that it includes the Motivation extension for modelling (among others) stakeholders, business goals, principles and requirements, which can be linked to the elements in the architecture that realize them.  In this way, we can achieve full traceability from goals and requirements to architecture, design and implementation.</span><br/><img alt="Motivation Extention" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-motivation-extention-metamodel_550x238.png" style="width: 550px; height: 238px;" title="Motivation Extention Metamodel"/></p> <p class="p1"><span class="s1">Figure 5 shows the key concepts of the Motivation metamodel.  The Drivers are the things, internal or external that creates, motivates change in the organisation.  Assessment is defined as the outcome of some analysis of some driver. Goals are the intended end states that a stakeholder seeks to achieve.  </span></p> <p class="p1"><span class="s1">Requirement is defined as a statement of needs that must be realised by a system. In fact Requirements model the properties of the elements (e.g. business process, business decision logic, application component) that are needed to achieve the “ends” that are modelled as goals. Requirements can therefore be considered the “means” to realise goals.</span></p> <p class="p1"><span class="s1">The The Decision Model models that are of strategic interest to stakeholders are those key business decisions that are critical or important to the realisation of the strategic goals.  Since The Decision Model is about modelling the business logic behind business decisions these strategic The Decision Model models can be considered high-level requirements that should be linked to Requirements in the Motivation model.</span></p> <p class="p1"><span class="s1">Not all The Decision Model models should, in my view, be directly linked to Requirements.  For example data-quality The Decision Model models, valuable as they are need not be linked to Requirements.</span></p> <p class="p1"><span class="s1">Of course some The Decision Model models need not be directly linked to the Motivation model. For example a Requirement in the Motivation model may be linked to a ArchiMate process model in the business layer which may then be linked to a TDM and BPMN models (see figure 10).</span></p> <p class="p1"><span class="s1">However linking The Decision Model models that realise strategic business decisions, that are required to realise business goals, are of immense value to stakeholders. Because these The Decision Model models can be linked to metrics which then drive a corporate balanced scorecard forming a feed-back loop that is required for  good  strategic planning and implementation. More information on this will be discussed in my third guest post ”Business Performance Management and The Decision Model”.</span></p> </li> <li class="li2"> <p class="p1"><strong><span style="font-size: 11px; line-height: 19px;">Strategy Models and Skeleton The Decision Model models</span><span style="font-size: 11px; line-height: 19px;">​</span></strong><br/> When modelling and connecting The Decision Model models with strategic and other Enterprise Architecture models it is important to realise that The Decision Model models can be linked to Enterprise Architecture and other design models in their skeleton form before individual rules within Rule Families have been modelled.</p> <p class="p1"><span class="s1">Assuming that one is using the top-down methodology for developing The Decision Model models one could start with the business decision and then add the supporting Decision Rule Family. This initial minimal The Decision Model model can be linked to other models including strategic motivation models.</span></p> <p class="p1"><span class="s1">Then later in the The Decision Model design process these initial The Decision Model skeleton models can expanded until the model is complete. Then the process of completing the individual rows (business rules) in each Rule Family table. The diagram below shows a The Decision Model model in a skeleton form.</span><br/><img alt="Skeleton form" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-skeleton-form_450x320.jpg" style="width: 450px; height: 320px;" title="The Decision Model model in a skeleton form"/></p> </li> <li class="li2"> <p class="p1"><strong>A Skeleton TDM model</strong><br/> The diagram below show what you see when you drill down and expand a Rule Family and see the contents of a Rule Family Table (shown in yellow below). Each row within a Rule Family Table is equivalent to a single rule.  </p> <p class="p1"><span class="s1">Enterprise Architecture The Decision Model modelling does not require that you use completed The Decision Model models. Over time during the design phase the The Decision Model models will be completed and the inter-model links will ensure that the latest The Decision Model model will always be linked.<br/><img alt="Rule families" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-rule-families_450x327.png" style="width: 450px; height: 327px;" title="The Decision Model rule families"/></span></p> </li></ul><p class="li2"> </p><p class="p1"> </p><h2 class="li2"><span class="s1">BiZZdesign, ArchiMate and The Decision Modeler</span></h2><p><span class="s1">BiZZdesign is the only tool vendor that has produced TDM-aware tools that enable the rich modelling landscape outlined above can be realised.</span>​</p><h2><span class="s1">The Decision Modeler – Integrates Business Logic, Information and Processes</span></h2><p><span class="s1">The integration between business logic, Information and Processes is illustrated in figure 7 and is directly implemented within The Decision Modeler; with business logic being modelled by The Decision Model, the information domain modelled by UML and the process domain modelled by Amber and BPMN 2.</span></p><p><span class="s1"><img alt="Information and processes can be related" class="left" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-integration-of-business-logic-information-processes_301x275.png" style="width: 301px; height: 275px; float: left;" title="Integration of business logic and information and processes"/><img alt="Policy and claim relation" class="right" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-relation-policy-claim_300x192.png" style="width: 300px; height: 192px; float: right;" title="Relationship between policy and claim"/></span></p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p> </p><p><span class="s1">Figure 8 show the relationship between Policy and Claim classes and their attributes in the information domain using UML. Figure 9 shows that same information model with a summary of how The Decision Modeler integrates Process, The Decision Model, Rule Family, Rule Family Tables, Fact Types, Glossary and UML.</span></p><p><span class="s1"><img alt="Modeling domains summary" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-summary-relations-modeling-domains_450x365.png" style="width: 450px; height: 365px;" title="Summary of relations between modeling domains"/></span></p><h2 class="p1"><span class="s1">Integrating ArchiMate with TDM – The BiZZdesign Advantage</span></h2><p class="p1"><span class="s1">There is no doubt that The Decision Modeler integration of The Decision Model, UML and BPMN 2 (and Amber) has resulted in an excellent TDM tool.  However, BiZZdesign integration of the ArchiMate enterprise architecture modelling standard (within its Architect toolset) with The Decision Model sets BiZZdesign as the clear leader in The Decision Model tool innovation.</span></p><p class="p1"><span class="s1"><img alt="Interrelationships" src="http://www.bizzdesign.com/assets/BlogDocuments-2/20130528_SuleimanShehu/The-Decision-Modeler-interrelationships_451x273.png" style="width: 451px; height: 273px;" title="Interrelationships"/></span></p><p class="p1"><span class="s1">ArchiMate is particularly suited for modelling the interrelationships between different domains (see figure 10). So in an ArchiMate model we can show what the main products are; which business processes realize them, which information and business decisions are used in these processes, which applications support them, etc. </span></p><p class="p1"><span class="s1">Then we model the details in each of these domains in the appropriate languages, e.g., business processes in BPMN, business decisions and business logic in The Decision Model, information and applications in UML. If we use the same tool suite for these models, we can link these models to elements in the ArchiMate model (using references or inter-model relationships), to link to each other.</span></p><p class="p1"><span class="s1">ArchiMate is an extendable modelling language, for example:</span></p><ul><li class="li2"><span class="s1">It is possible to define new attributes and relationships and to create new concepts based on the specialisation of existing concepts. </span></li> <li class="li2"><span class="s1">It is possible to define new domain specific languages (DSLs) as user defined profiles. </span></li></ul><h2 class="li2"><span class="s1">​Conclusions</span></h2><p class="p1"><span class="s1">All the inter-model relationships I have outlined in this post can be modelled by a combination of ArchiMate and The Decision Modeler. BiZZdesign decision to bring The Decision Model-awareness to ArchiMate’s extensive modelling capabilities is going to transform Enterprise Architecture and decision modelling practice.</span></p><p class="p1"><span class="s1">In one leap BiZZdesign has gone from a standing start, in The Decision Model tools, to being the most innovative The Decision Model tool vendor.  In due course, other The Decision Model tool vendors will respond, but for now BiZZdesign leads the The Decision Model vendors with its modelling capabilities.</span></p><p class="p1"> </p><div class="p1" style="background:#eee;border:1px solid #ccc;padding:5px 10px;"><span class="s1">Suleiman Shehu is the CEO, of Dublin based <a href="http://www.azinta.com" target="_blank"><span class="s2">Azinta Systems Ltd</span></a>. Azinta Systems is a business transformation, business integration and consultancy company. Azinta is a KPI The Decision Model consulting partner for the Europe, Middle-East and Africa (EMEA).</span><br/>Azinta has recently signed a strategic business partnership with BiZZdesign for EMEA region and Azinta will be providing TDM consulting and TDM methodology training services for those looking to start using TDM with the Decision Modeler.<br/><strong>Suleiman can be contacted at Suleiman.shehu@azinta.com.</strong> </div>