- Adaptive Enterprise
In my previous post I discussed my Three Decision Model Predictions and how they were realized by BiZZdesign Enterprise Studio.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.
Then I will show that BiZZdesign has become the first vendor to enable TDM models to form inter-model relationships and the advantages that brings to IT and the business.
Wikipedia defines ArchiMate (a technical standard of the Open Group) “[as] an open and independent enterprise architecture modeling language to support the description, analysis and visualization of architecture within and across business domainsin an unambiguous way.”
It was Foote & 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 each aspect separately as well as the entire application.
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 The Decision Model (TDM). All previous attempts had failed in creating a modeling language that could both tame the complexity of business logic and at the same time make it understandable to both business and IT users.
One of the brilliant insights that the inventors of The Decision Model (Barbara Von 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.
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.
For further information on the 15 The Decision Model principles read the book “The Decision Model : A Business Logic Framework Linking Business and Technology” by Barbara von Halle and Larry Goldberg.
Business and IT could now use The Decision Model to extract all the business logic that is 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.
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 modeled for the following reasons:
In fact since business rule tasks are determining a business decisions and should really be called decision tasks. It is possible in BPMN to 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.
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.
If an executable BPM modeling language like BPMN 2.0 is used, then it is possible to execute the BPMN process models in a BPM engine which consumes Enterprise Studio models in the form of Decision Services running in a business rules engine.
Enable the Model-Driven Application (MDA) generation of code and other executable artefacts
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. Once all the dependencies between a The Decision Model model and other dependent models are determined and modeled it is often possible for software to convert these models into executable artefacts with reduced programmer input leading to increased productivity and reduced defects.
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.
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.
Using The Decision Model to Manage IT Operational Systems
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.
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.
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.
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.
It is important to realize 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.
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.
Linking The Decision Model with Strategic Models
One of the advantages of ArchiMate is that it includes the Motivation extension for modeling (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.
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.
Requirement is defined as a statement of needs that must be realized 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 modeled as goals. Requirements can therefore be considered the “means” to realize goals.
The The Decision Model models that are of strategic interest to stakeholders are those key business decisions that are critical or important to the realization of the strategic goals. Since The Decision Model is about modeling 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.
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.
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).
However linking The Decision Model models that realize strategic business decisions, that are required to realize 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”.
Strategy Models and Skeleton The Decision Model models
When modeling and connecting The Decision Model models with strategic and other Enterprise Architecture models it is important to realize 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 modeled.
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.
Then later in the The Decision Model design process these initial The Decision Model skeleton models can be 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.
A Skeleton TDM model
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.
Enterprise Architecture The Decision Model modeling 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.
BiZZdesign is the only tool vendor that has produced a TDM-aware platform that enable the rich modeling landscape outlined above to be realized.
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 modeled by The Decision Model, the information domain modeled by UML and the process domain modeled by Amber and BPMN 2.
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.
There is no doubt that Enterprise Studio 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 modeling standard (within its Architect toolset) with Enterprise Studio sets BiZZdesign as the clear leader in The Decision Model tool innovation.
ArchiMate is particularly suited for modeling 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.
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.
ArchiMate is an extendable modeling language, for example:
All the inter-model relationships I have outlined in this post can be modeled by a combination of ArchiMate and Enterprise Studio. BiZZdesign's decision to bring The Decision Model-awareness to ArchiMate’s extensive modeling capabilities is going to transform Enterprise Architecture and decision modeling practice.
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 modeling capabilities.