Software Tools for The Decision Model – Part 1

“Because the book does such a great job of explaining the decision model I have a hard time dinging it because of the lack of tools. It is very thorough and a very good read. The theory is sound and has a ton of potential. I highly recommend reading this book for the theory itself, and if modeling tools become available you will be a step ahead in the industry.” – T. Anderson, Amazon.com Review, April 2010

In April of 2010, we understood the concern about the lack of software tools to support The Decision Model. At that time, the book was five months old and knowledge of The Decision Model was new to most people. However, as 2010 draws to a close, the predictions proved true. Software support is no longer lacking! In fact, The Decision Model is supported by excellent software from visionary vendors, with more software coming. This two-part column looks at Decision Model software available today and what we know to be on the immediate horizon.

In Part 2, we divide software tools that support The Decision Model into two major categories. One is repository software by which a business user can author and maintain The Decision Model. The other is deployment software by which technical experts automate and test The Decision Model. The distinction between these two categories is blurry in some cases, but you will want to be aware of both.

In Part 1 below, we ask four questions, beginning with the one most obvious.

Question #1: What Do We Mean by a Software Tool for The Decision Model?

A software tool for The Decision Model supports the entire life cycle of Decision Management. This includes the authoring, analysis, testing and deployment of entire decision models. Whether managed by the business – as some people consider ideal – or managed by IT or business analysts on behalf of the business – as others consider necessary – business decisions need not only a repository for storing decision models, but a range of functions to manage them effectively. This is similar to the idea that business processes need a repository for storing process models and also need functions for managing them over time.

Question #2: What are the Basic Functions Required of a Software Tool for The Decision Model?

Because The Decision Model is a new technique (compared to other models), the functions required of a supporting software tool specific to the creation and maintenance of decision models are also new. Let us start with a list of ten basic functions:

1. Graphical Modeling for The Decision Model Diagram Notation
   The software supports the creation and maintenance of developing Decision Models from the top-down (i.e., creating the Decision Model structure first followed by Rule Family tables) or bottom-up (i.e., creating Rule Family tables first followed by Decision Model structure). It can generate the Decision Model Diagram from Rule Family tables and vice versa.
2. Rule Family Table Development
   The software drills down from the Rule Family shapes on The Decision Model Diagram into the Rule Family tables. It supports population, manipulating and managing of Rule Family tables. It recognizes Rule Patterns within a Rule Family.
3. Robust Glossary Function
   The software captures definitions of, and access to, fact types and their domains. Fact types are accessible directly from The Decision Model Diagram and Rule Family Tables.
4. Integrity Analysis of Business Logic
   The software analyzes Rule Family Tables and whole Decision Models for missing, inconsistent or contradictory logic and adherence to the Decision Model Principles.
5. Testing and Test Case Generation
   The software generates test cases from Rule Family tables and whole Decision Models and tests the output from Rule Family tables or whole Decision Models for a given set of inputs.
6. Traceability
   The software traces the impact of any change to a Decision Model, Rule Family Table, or Fact Type. This traceability supports the “where used” function for any aspect of a Decision Model in the repository (e.g., Rule Family, Decision Model, Fact Type).
7. Connectivity
   The software connects Decision Models to related tasks in process models, fact types to appropriate objects in the object and data models, and so on. The software can export the decision logic into a target deployment environment such that there is no need for a human to convert it into code. Instead, it is automatically deployed or tested.
8. Governance
   The software supports the formal process of validation and approval of business decisions, decision models, and fact types among stakeholders.
9. Enterprise Support
   The software has a repository that is “federated”, which is to say that a given view of a decision model may be managed at an Enterprise, a business unit, and a project level, with the ability to promote changes from one level to another. The glossary function would also allow fact types to have a different set of valid values (domains) from one level of the enterprise to another.
10. Analytics
    The software provides a direct relationship between a decision model or a Rule Family (or even a row of logic in a Rule Family) and scenarios in an analytic tool measuring the business impact of that given logic. This enables both a “what-if” analysis using models, but also measurements over time to determine the optimum logic for a given circumstance. In the highest levels of decision management maturity (see Question #3 below), the analytics tools are connected to the business logic such that the logic may be heuristically and – perhaps – automatically changed to optimize the logic against results.

There are other “nice to have” functions of a robust software tool for The Decision Model. However, the ten functions above suffice to provide a solid foundation for a comprehensive tool. Those of you who have read our book Business Rules Revolution (von Halle and Goldberg, HappyAbout, 2006) will recognize much of the functionality in Chapter 8, John Semmel’s excellent piece entitled “Better Rules through Rules Authoring Software”. The impact of the software that John describes in that article was profound on that particular business rules project. But that software was custom-developed for a target testing and automation environment. A general tool for The Decision Model must achieve this same level of functionality (and more), but for all, or at least the most common, decision modeling and deployment environments.

Question #3: How to Assess the Maturity of a Software Tool for The Decision Model?

While a robust decision-modeling tool supports these ten functions, there are (and will continue to be) tools that support a subset as well as those that deliver more. However, not all Decision Model projects or organizations require all of these functions.

Therefore, a practical way to understand the maturity of a software tool for The Decision Model is to understand first, the target maturity level of a target decision model project itself. Organizations use the Business Decision Maturity Model to determine the right level of maturity for the objectives of a project, a group of projects, or a business unit or the entire enterprise. See Figure 1(1).

Each level of the BDMM aims for different objectives. The higher the level, the more sophisticated, mature, and perhaps more challenging, the objectives are. Here is a brief description of the objective of each level associated with the functionality needed from a software tool for The Decision Model.

• Level 0: Unmanaged Business Decisions
  • Objective: There is no awareness of business decisions or The Decision Model and consequently, no objectives for them.
  • Software Functionality: There is no corresponding functionality that can solve the problems arising from this level.
• Level 1: Visible Business Decisions
  • Objective: The objective is the discovery, authoring, and revealing of business decisions.
  • Software Functionality: There is a need for the basic functions – decision model diagrams, Rule Family tables, glossary maintenance, and so on. Level 1 also implies that the discovery of logic is at the local, or project level, and not at the enterprise level, and that there is no need for traceability from the business decisions to automation. Automated analysis and possibly even testing of the decision models are desirable.
• Level 2: Agile Business Decisions
  • Objective: The key differentiator in objectives between this and the previous level is the traceability of The Decision Models to implementation into automated systems.
  • Software Functionality: This requires an automated pathway to deployed code. At the very least this means traceability to it, but ideally it means an automated way of deployment and impact analysis. It implies automated analysis and testing of the decision models prior to deployment.
• Level 3: Aligned Business Decisions
  • Objective: The objective at this level is to share business decisions across projects.
  • Software functionality: Related functions include fact type aliases, as well as differences in domains. In addition, some advanced features of The Decision Model (e.g., views) are needed to create decision model logic that varies for different projects, customers, geographical locations, and so forth. Decision model governance becomes more important, and more complex, as there is a need to arbitrate differences in approach among projects.
• Level 4: Predictive Business Decisions
  • Objective: The objective at this level is to share business decisions across the enterprise, and the complexities first emerging at level 3 become pronounced.
  • Software Functionality: Corresponding advances in software functions means a federated repository among organizations.
• Level 5: Autonomic Business Decisions
  • Objective: The objective at this level is for decision model logic to adjust itself automatically without human intervention based on changing conditions.
  • Software Functionality: The functions needed now include a programmed interface among business models, analytics and the business logic, with a real time representation of changes taking place in business intelligence and the underlying logic.

Figure 1: Business Decision Maturity Model

Question #4: How to Align Software Functionality with a Target Maturity Level?

The easiest way to select an appropriate software tool for The Decision Model is first to identify your target maturity level using the BDMM. Second, understand the functionality you need in a tool at that level. Third, select an available tool that provides that functionality. Table 1 correlates, in a simple way, the functionality needed in a tool for each BDMM level. Next month, in Part 2, we investigate the categories and actual tools on the market that support The Decision Model and the functionality they support.

Table 1: Correlation of Software Functionality to Maturity

Summary

Perhaps you can envision the creation of Decision Models by business people using a simple, intuitive interface supporting very basic functionality, such as Decision Model Diagrams, and Rule Family population. Today, this is happening in many places. From here, business analysts can embellish these deliverables with metadata, versions, perhaps automated analysis. Even further, the deliverables move along the life cycle to developers and enterprise architects. The need for software tools becomes obvious. The good news is that adoption of The Decision Model has been more rapid than originally anticipated. The other good news is that software support is catching up quickly! And it’s only just begun.