Evolving the Decision Model With Views


Evolving the Decision Model with ViewsWhen introducing the Decision Model we frequently quote John Zachman’s classic gem “It occurs to me that once the underlying structure of a discipline is discovered, friction goes to zero! The processes (methodologies) become predictable and repeatable.” Every project in which we have implemented the Decision Model has seemed to bring further proof that – in the world of business logic or business rules, it seems to create a frictionless environment. We see “Ah ha!” moments time and again when people realize the simplicity to which their complex logic or business rules may be reduced by applying the model.

However, just last week, in reviewing the Decision Model (The Decision Model: A Business Logic Framework Linking Business and Technology, Auerbach 2009) we realized that our practices have already evolved in the use of the Decision Model quite significantly since the book was completed. Not in the basic theory – that seems to remain constant, whatever curved balls we throw at it – but in the practices involving implementing model. The processes that Zachman talks about seem amenable to quite a bit of tweaking.

It shouldn’t be that surprising. In the preface to the book we invoke Edmund Phelps, the great US Economist, and Nobel Laureate, when says that it is not necessarily the important discoveries, but actually the practical knowledge that is learned when implementing those discoveries – the “tweaking” that the practitioners are able to achieve – that is the cause of the great leaps in value in economy. So we see the elimination of friction due to the implementation of a theory that accurately reflects the underlying structure of the logic; but it is in the practice that we see refinements that bring about great leaps in productivity.

We first proposed the theory of the Decision – in an unpublished paper – just three years ago, and completed the first draft of the book over two years ago: the many redrafts and the publishing took care of the time elapsed since then. But all this while we worked with close clients to test and implement the theory. The results were very heartening. In chapter 7 of the book we detail a fictional case study that in large part was drawn from actual experiences with client engagements during this period.

It is now a year since we handed the manuscript to the publisher, and in this time our practice of the Decision Model has evolved very significantly. In this piece we would like to bring you up to date with one of the exciting new developments in Decision Modeling, the one that has had the most profound effect on our practice, and that is the Decision Model View.

Business rules, or business logic, in the enterprise can be very complex. If we consider one of the more challenging business rule environments, the nationwide, multi-line insurance company, we soon realize the nature of challenge. Such a company must operate in up to 55 different regulatory regimes, each with its own rules and practices, while at the same time managing business lines as diverse as property and casualty life, and perhaps health care, subdivided still further into many different lines of business and yet further orthogonally delineated into personal and commercial lines – which could be yet further divided in small to medium business, and large commercial and so on. Not to mention several possible specialty lines. And of course, this could be yet further complicated by having several different channels of sales. Business rules not only abound in this environment, but are segmented, sub-segmented, and cross-segmented in very complicated ways. While this may be an extreme case, it does represent the challenge that is faced in trying to model logic across any enterprise.

Take the model that is used in Chapter 7 of The Decision Model, and illustrated in Figure 1.


Figure 1 - Decision Model from Chapter 7 (click for larger version)

Adapted from: The Decision Model: A Business Logic Framework Linking Business and Technology, von Halle & Goldberg, © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher.

This Decision Model determines whether a policy is to be renewed automatically, or needs to be reviewed manually by an underwriter. The underlying logic (the business rules) evaluates several conditions that lead to this determination. Would, however, that it were always this easy. In the case of the multi-state, multi-line insurance company, there would be numerous exceptions and differences depending on the State, and depending on the line of business. It would be necessary to add many condition fact types to each of the Rule Families: at the very least, the fact types of State and Line of Business would have to be included in many, while fact types specific to the logic of each individual locality and line of business would also have to be included. Some of these added fact types may be derived, and be dependent upon supporting Rule Families, increasing the number of Rule Families. Each business rule that is specific to a State or group of States, or Line of Business would potentially add many rows to the Rule Families, increasing size and complexity and making analysis increasingly more time consuming. Assume that there are but two additional fact types per State, and two additional fact types per line of business, there could be a few hundred additional fact types, and many potentially many additional Rule Families. Figure 2 is an illustration of a complex Decision Model, demonstrating the challenge of such complexity. This is from an actual client’s enterprise Decision Model, but the resolution has been reduced to protect the business logic for client confidentiality.

Figure 2 - Illustration of a Complex Decision Model (click for larger version)

It’s not as if this is a Decision Model specific problem. It is the source of the difficulty of managing large bodies of complex business rules: they typically have a great deal of inter-dependencies, and without the Decision Model it is difficult to trace the impact of a one change across the whole rule base. This is what leads to the very high cost of developing and maintaining business rules. The Decision Model greatly simplifies this, but the question remains how to better manage the complexity of the enterprise model.

Thus the notion of the Decision Model View. Put simply, the View is like looking at the Decision Model through a filter, just as one may look at a complex database through the filter of a SQL View to focus on just the data that is of interest at a given time. In fact, the Decision Model View is created by integrating relational model principles into Decision Model structures. Using this approach Decision Models are created, managed, analyzed and implemented as Views of the underlying Enterprise Decision Model. In fact our practice is to no longer manage Decision Models, but their Views; this is similar to the concept of never permitting application developers to directly address tables in RDBMS, but limit their access to Views only. This enables the Data Modeler to completely isolate and make changes to the schema without perturbing applications accessing the data.

Figure 3 - The FL View for Determine Policy Renewal Method (click for larger version)

An illustration of the use of Decision Model Views is shown in Figure 3. Imagine that the Decision Model in Figure 1 has been expanded to a nation-wide insurance company with a great deal of State specific logic, extending the Decision Model accordingly. In Figure 3 the View is of one State only, Florida, thus filtering out all the complexity of all the other States. The Rule Families that have been modified from the Base View (the “Base” is the name of the default View of the Decision Model) are highlighted and marked with an asterisk. It can readily be seen that there are two additional Fact Types relating to Florida specific issues, Florida Rider in the Rule Family Policy Discount and Hurricane Zoning Change in Rule Family Insured Major Location Change. There may be a single View for each State or for a group of States. Views can also be compound: there could be a View for a State/Line of Business combination, such as a View of a particular Decision Model for Workmen’s Compensation for the State of New York.

Views bring a very great deal of agility to the Decision Model, enabling a generalized model to be made specific for a host of reasons: perhaps to customize the business decision for a given group of customers, or even individual customer; perhaps to provide for specific logic to be applied to a product group or range of products, and so on. Our early experiences with Views teach us that this is the future direction to pursue using the Decision Model.

To support Decision Model Views, the notation has been extended. This is illustrated in Figure 3: the View name is shown in both the Decision and the Rule Family shapes. The convention is to omit the View name when modeling the Base view, but to display the View name for all Rule Families, even those that are not modified in the View. Those that are modified by the View are indicated by an asterisk, and the View name is displayed in bold text. This way it can be seen at a glance which Rule Families are affected by the change. In the case of Rule Families that are redundant in the View, the Rule Family shape, Rule Family name and View name are displayed with no lines; this indicates that the Rule Family is omitted in the View.

The development of Views in Decision Modeling is an opportunity to solve problems inherent in modeling logic across complex domains, and a clear roadmap toward the higher levels of the Business Decision Management Maturity Model. Most importantly, it is proving itself in practice. 

Author: Barbara von Halle and Larry Goldberg of Knowledge Partners International, LLC (KPI)

Larry Goldberg is Managing Partner of Knowledge Partners International, LLC (KPI), has over thirty years of experience in building technology based companies on three continents, and in which the focus was rules-based technologies and applications. Commercial applications in which he played a primary architectural role include such diverse domains as healthcare, supply chain, and property & casualty insurance.

Barbara von Halle is Managing Partner of Knowledge Partners International, LLC (KPI). She is co-inventor of the Decision Model and co-author of The Decision Model: A Business Logic Framework Linking Business and Technology published by Auerbach Publications/Taylor and Francis LLC 2009.
Larry and Barb can be found at www.TheDecisionModel.com

Like this article:
  4 members liked this article


zarfman posted on Wednesday, January 6, 2010 12:12 AM


I don't see what the big deal is about SQL views. They've been used extensively for years. RDBMS systems can handle millions of rows of data. How the query is written makes a huge difference in response time.

Larry Goldberg posted on Wednesday, January 13, 2010 4:26 PM
Zarfman - I am in violent agreement with you that there is no big deal about SQl views! Our article, on the other hand, involves Decision Model Views, which is a very different and unique animal, and non-existent before now. I personally know of no manipulation language for business logic, and this is functionally what we have implemented with Decision Model Views. Different, and quite effective.
zarfman posted on Saturday, January 16, 2010 5:24 PM

I think I may have figured out what bothers me about the decision model approach detailed in your writings.

The system that I understand is a three tier system. User interface, middle-ware and some sort of DBMS. The middle-ware level accesses the business/decision rules table. If all is well, the process continues. This technology has been around for sometime.

In an earlier issue (maybe December) you displayed some of the rules tables. I would expect another column or two containing the dates for which a single rule was valid. At least that’s what I’ve seen in other systems.

Would it be reasonable to call your system a rules based decision model?

Are the views you refer to up-datable and by whom?

I’m still not sure that we are on the same page, if not, at least you know what’s in my head.


Larry Goldberg posted on Saturday, January 16, 2010 6:37 PM
Zarfman - OK, we are definitely not on the same page.

We are not selling a system. We are proposing a technology independent model of business logic (call it business rules, if you wish), that is nothing but a model, an intellectual concept.

Several companies are business implementing the model into technology, but our focus is simply the model. Just like, for example, the relational model. That model is a universal, technology independent model. IBM, Oracle, Microsoft, and several others have implemented it in their RDBMS technology, but they are all able to use the same standard ANSI SQL commands to manipulate the data in their RDBMS' because they, as is SQL, are based on the relational model.

So, in response to your specific points:

Question: "The system that I understand is a three tier system. User interface, middle-ware and some sort of DBMS. The middle-ware level accesses the business/decision rules table. If all is well, the process continues. This technology has been around for sometime."
Answer: You could certainly implement the model in this approach: or you could use a BRMS (Business Rule Management System). Several of our clients maintain the model in MS Visio (for the diagrams) and MS Excel (for the Rule Families). Other have adapted various products to implement the system, such as RuleGuide, Rule Express, System Architect, and so on. As I said above several software vendors are looking to implement the model directly into the BRMS or BPMN tools.

Question: In an earlier issue (maybe December) you displayed some of the rules tables. I would expect another column or two containing the dates for which a single rule was valid. At least that’s what I’ve seen in other systems.
Answer: The Rule Families are the tables of logic that are represented by the green tablet shapes, and yes there would be metadata for each column, row, or cell, typically that would include effective date, expiration date, perhaps version date, source, governance, business motivation, and much else. This metadata is not displayed in the tables, just as properties for data columns are not displayed in data tables.

Question: Are the views you refer to up-datable and by whom?
Answer: In any implementation of the model, we would expect a role based access to the Views and their underlying Rule Families.

I hope this makes it all clearer than we have done in the past.

zarfman posted on Monday, January 18, 2010 7:39 PM

Your recent post cleared up many things.

Now that two start-ups I am involved with are up and running, I'll have time evaluate some of the Business Rule Management Systems you mentioned.

Decision making seems to be a big deal now, given our economic problems. The Harvard Business Review has lots of articles on how to make better decisions.

What concerns me, that some of the articles seem (at least to me) imply these rule systems can be predictive in nature. The Wall Street Quants, economists, etc. track records in these areas are miserable.

Thanks again.

The old accounting and finance dude - aka zarfman
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC