(And How toUse This to Your Advantage)
Portions of this article are drawn from the book, The Decision Model: A Business Logic Framework Linking Business and Technology, von Halle & Goldberg, © 2009 Auerbach Publications/Taylor & Francis, LLC. This article consists, in part, of abstracts from the book; directly quoted passages, diagrams and tables are cited, and are copyright © 2009 Auerbach Publications/Taylor & Francis LLC. Reprinted with the permission of the Publisher
The quest for The Decision Model began about seven years ago. It began with a very simple, intriguing question: Can there be a model for business logic (business rules) as there is for data?
By that comparison, the model must be simple to create, interpret, modify over time, and automate. It must also have a rigorous foundation so that its creation is repeatable, technology-independent, and reflects only the nature of business logic itself and nothing more. But there was one more important criterion. It must be understandable and useable by pure business people so that it becomes a business deliverable first and a technical deliverable second.
And so, after several years of research and practice, The Decision Model came into being. But this was merely the beginning. There were additional important questions to consider.
The Bigger Questions
Would organizations use such a model? What kinds of organizations? Who in those organizations would introduce it and create them? What would organizations use it for? How successful would these decision models be? After seven years, we have answers. They tell an interesting story about the birth and usage of this new kind of model.
History and Why It Is Important
In some ways, the stage was set for The Decision Model as far back as the 1960s. This was a time when people began to use models to represent the structure of what seemed like intangible program code. In the decades since then, different kinds of models came into practice and industry standards for some of them emerged. The stage was set for the latest one, The Decision Model.
This month’s column looks at the interesting evolution of decision model usage to date. The purpose is twofold. The first is to reveal the nature and speed of decision model adoption so that you are comfortable considering decision models as new deliverables. The second is more important. By defining three distinct stages of current decision model usage (so far), you can use these to understand where your organization is, where it can go, and how you can be part of that journey. For example, if your organization is at the very early stage of decision model usage, you can focus on the kinds of decision models such organizations have done successfully. If your organization is in a later stage, you can get a glimpse of the next stage, and so on.
This month’ column starts with Stage 1 which represents the earliest decision model experimentations and successes. It then continues to Stage 2 which is where full project-level adoption occurs. Finally, the column concludes with Stage 3, which is where enterprise-level adoption begins along with decision models for business transformation.
Technology Adoption Life Cycle, In General
It is useful to draw some comparison of the evolving usage of decision models to the familiar concept of technology adoption life (TALC). “The technology adoption lifecycle model describes the adoption or acceptance of a new product or innovation, according to the demographic and psychological characteristics of defined adopter groups.”[1]
The word technology actually means “use of science in industry, engineering to invent useful things to solve problems.” In the world of IT, most think of technology as a software, hardware, or combination of the two as solutions. The Decision Model, as an intellectual template, truly exists outside the realm of software but has interesting roots in related software support and future innovations.
Technology Adoption Life cycle for The Decision Model, In Particular
There are some similarities of current decision model usage to TALC but also interesting differences at this point in time. TALC defines five categories of adopters fitting into the adoption bell curve. In our experience so far, decision model usage seems best described in three stages and the adopter groups are more varied. TALC begins with innovators, then early adopters, then early majority, then late majority, then laggards. Decision model usage today draws from all of these groups.
Stage 1: Experimentation, Business Rule Archeology and Quick Fixes [2]
In the spirit of total honesty, in our first decision model project, the phrase “decision model” never surfaced. We simply applied its concepts to a particular business decision needing improvement within a client organization. We analyzed program code to unearth the criteria behind that decision, drew our first ever decision model structure diagram, and facilitated business conversations around that diagram. The reaction was awe-inspiring. We then changed the content of the logic in that diagram based on business insights and tested various changes against real data. After merely a few weeks, we delivered a whiteboard decision model of highest quality logic that hit business objectives. It was implemented in a COBOL system.
From this humble beginning, between 2006 to 2009, we introduced The Decision Model more formally to selected clients, under NDA. These early users applied decision models in three different ways. One way was to refine existing, small-scoped decisions operating in program code. An example was deciding the most appropriate renewal method of existing insurance policies coming due. Another usage was to clarify difficult decisions carried out by humans and document them in policy manuals. An example here was deciding whether treatments on healthcare claims are appropriate for specific diagnosis codes. The third usage was to document, for business people, the technical rules already implanted (but not well understood) in existing BRMS products. These included deciding whether a new dependent is eligible on a healthcare plan.
Stage 2: Full Decision Model Projects [3]
While Stage 1 decision models crept their way into existing projects and systems, in 2009-2010 they became the very center of full projects. This means, decision models were, in fact, a primary focus of projects for solving significant business problems. Some projects involved many decision models, consisting of more than twenty Rule Families each. The decisions themselves were complex and often included different views of the same decision models. Examples in this stage include complex eligibility decisions for loan programs and student financial aid options. Also, in this stage were robust data quality decisions and critical compliance decisions.
Stage 3: Decision Models Enterprise-Wide [4]
Today, 2013, many decision model projects (and those on the horizon) are not only large-scale projects, but often instigated from an enterprise perspective. Sometimes the enterprise perspective originates from the formation of a Center of Excellence for decision modeling. Other times, it is instigated by an Enterprise Architecture Group seeking technology useful across multiple projects. These projects often involve decision models within broad business transformation projects, those for delivering unique competitive advantage, or those for quick adherence to compliance requirements. In this stage, the idea of industry-specific decision models arises.
The enterprise interest often involves a new desire to deploy one decision model to multiple target technologies (e.g., open source, commercial, and home-grown). This opportunity is ground-breaking. It is possible because The Decision Model is a vendor-neutral and technology-neutral representation. The single-model-multiple-deployment-capability allows an organization to evaluate the same decision model in multiple target technologies as part of making a purchasing decision. It also allows complex organizations to manage easily different deployments of the same decision models across various technology environments in different business units.
Figure 1 illustrates how such organizations manage decision models from a single decision model, deployed to multiple target technologies, and service multiple applications. The figure includes software called a BDMS, not to be confused with a BRMS. A BDMS is a Business Decision Management system that orchestrates creation, validation, testing, and deployment of decision models to target environments. A BRMS, on the other hand, is one of many target environments. A BDMS is where all decision model creation and changes take place, by business and non-technical people. As shown in Figure 1, various applications interface with the BRMS for those executions.
Figure 1: Decision Models in Multiple Deployments
Interesting Comments by Practitioners
In an Executive Blog, under Technology Transforming the Secondary Market, Rob Lux SVP and Chief Information Officer at Freddie Mac, stated on March 4, 2013: “It only took Freddie Mac 17 business days to write, test, and deploy the 100+ rule changes comprising Hurricane Sandy disaster relief policies for the systems lenders use to sell and service Freddie Mac mortgages. That is about 90 percent less time than it took to operationalize policy changes following disasters like Hurricane Katrina or the 2012 New England floods.”[5]
A project manager at a different organization, stated “For me personally the question that has been answered is what decisions are we making in our processes and what factors in that decision (sic) lead us to reach a specific conclusion or if put in regulatory terms, what factors and risk drivers result in our products attracting a particular regulatory charge. Answering that question allows us to make the necessary change with the greatest of impact.”
A change implementation professional stated, “A big win from my perspective though, is that the BA’s own the business logic when they find the result isn’t as anticipated they can just refactor their Decision model and output new code. Largely I just have to plug in the new function, which probably saves 80-90% of my time.”
Decision models operate well in small and large scale implementations very effectively. On the larger size, one client manages in one community almost 12,000 distinct rows in their rule families, that represent ab0ut 200,000 rows of logic in production – a re-use rate of almost 17:1. In addition, there are an average of 400 changes every month (the equivalent of about 7,000 rule changes a month and managed by a team no larger that was (not) managing 1500 rules with 60 changes a month about five years ago!
The Decision Model Increases the Value of the Business Analyst (BA)
Today, most BA’s play a documenter role, striving to elicit and formulate high-quality requirements and manage changes to them over time. Figure 2illustrates how The Decision Model (with and without special software) elevates the role of the BA in accelerating business logic specification to deployment. A BA can deliver to IT full decision models, already analyzed for errors (manual or automated), tested against test data (manual or automated), and even generate executable code (with special software).
This breaks a business-to-IT barrier with measurable savings in time and money. The BA emerges as the catalyst for doing so.
Figure 2: Elevating the Role of the BA
Wrap Up
Figure 3 summarizes the three stages of decision model usage today.
Figure 3: General Stages of Decision Model Adoption to Date
Figure 3reflects that, five years after publication of the book, we have been involved in building thousands of decision models (and there are many more we don’t know about), including for several of the largest financial institutions in the world. These include enterprise scale solutions, sharing of logic across multiple lines of business, multiple domains within a single enterprise, and plans for decision model sharing between institutions.
Adopting The Decision Model without related technology is essentially risk-free. There are free templates for decision models (www.kpiusa.com) using standard MS/OFFICE products. Again, wherever your organization is in the stages of decision model usage, there are many benefits and success stories for proceeding. Decision modeling transcends boundaries – small and large companies, single project and enterprise wise, and across all industries.
Authors: 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.
[1] http://en.wikipedia.org/wiki/Technology_adoption_lifecycle
[2] Stage 1 represents organizations at Business Decision Management Maturity (BDMM) Level 1 where Level 1 seeks to make business logic visible to business audiences, not just an artifact understood by technical audiences.
[3] Stage 2 represents organizations achieving BDMM Levels 2 and 3, where Level 2 maximizes agility in making business logic changes and Level 3 aims for consistency across organizational boundaries.
[4] Stage 3 represents organizations entering BDMM Level 4, where Level 4 aims to control and predict short-term futures and assess impact of change on those futures.
[5] http://www.freddiemac.com/news/blog/robert_lux/20130304_tech_transforming.html