Why The Decision Model

An Overview of the Decision Model

The Decision Model is a new model that impacts not just technology trends, but also business
management practices. It brings to the world of business rules a well-defined structure based on
the inherent nature of logic, extended with integrity and normalization principles. This is similar
in concept to what the Relational Model brings to the world of data.

How It Began
Before the advent of commercially available computers, a business carried out its processes
through human effort guided by human thinking and logic. In many cases, critical processes were
documented as a set of tasks and important check- points, along with guidance for carrying out
decisions along the way. Indeed, such documentation exists today for many processes that are
partly or wholly carried out by humans. The documentation together with training informs the
processes and evolves them over time.
In the age of commercial computer processing, important business processes, or parts
thereof, have become ideal targets for automation. The sequences of steps along with the
business logic for making decisions behind those steps have been translated into program code.
Businesses have gained a great deal by automating business processes. The ability to process
transactions quickly, in greater volume, and with more consistency has made all the difference in
the world to most businesses. The gains have been enormous and, consequently, the wave of
business automation has grown beyond initial expectations. So, too, have the sophistication of
technology and the way automated systems are designed. However, a price has been paid for
these great advances. That is, many, if not most, enterprises have lost track of and control over
the business logic that is embedded in these systems. This is a natural result of how the design
and development of automated systems have evolved.

What is Business Logic?

Business logic is simply a set of business rules represented as atomic elements of conditions
leading to conclusions. As such, business logic represents business thinking about the way
important business decisions are made. Business logic represents the “rules of the business” that
operate perhaps thousands of times a day in service to customers and partners. They are the
present and the future of the company.

Why Separate Business Logic?

Yet, many “rules of the business” are buried in program code or in people’s heads.
Sometimes, the business rules executing in program code are not what the business thought they
were or even what the business needs them to be. They are an important consideration in
implementing change and delivering enterprise agility. However, today they operate as a silent,
invisible business asset rather than one worthy of being managed separately from other
dimensions. As a result, they remain buried, scattered, and resistant to change. Even when
captured separately from models and requirements, the technology for storing business logic
ranges from documents, spreadsheets, modeling tools, repository tools, and proprietary
software, to home-grown databases. They are managed as a catalog or list of business rule
statements, tied in one way or another to related deliverables. They are not managed in a
common model as data is managed today. The historic impact of a common model for data is
worth contemplating.

The Need for a New Model

So, a very simple question comes to mind: Is there a model of business logic that is simple to
create, interpret, modify, and automate? Is there a rigorous, repeatable, and technology-
independent model that is based only on the inherent nature of business logic itself and nothing
more? Such a model would provide a missing link in today’s technologies, methodologies, and
business practices and also lead to technology advances that preserve the technology-
independent view of business logic. As the Relational Model did for data, it would enable the
separation of business logic from other concerns by providing a very specific representation for
its maintenance and automation.

The Decision Model structure is based on the premise that business logic has its own
existence, independent of how it is executed, where in the business it is executed, and whether or
not its execution is implemented in automated systems. The Decision Model has a recognizable
structure that is not the same as the structure of other kinds of models. With the introduction of
the Decision Model, it is improper to impose (and thereby bury again) business logic onto other
kinds of models because business logic now has its own model.

Five Most Interesting Characteristics of the Decision Model

It is important that the Decision Model have its own notation and principles that make it a
totally different model from other kinds of models. Five overall characteristics that make it
interesting are as follows:

1. It defines a technology-independent way of organizing an important, some- what intangible

business intellectual asset. That asset is business logic.
2. The Decision Model is a pure representation of business logic. That is, it is devoid of biases
from process, data, or technology. It possesses three significant features of technology-
independent models: a simple structure, declarative nature, and optimal integrity.
3. Despite being independent of technology, it is easily implementable in technology and
transcends current and future technology products.
4. The Decision Model is neither a language nor a grammar. It is a model. Yet, languages and
grammar can be defined over the Decision Model in much the same way that SQL, as a language,
was built over the Relational Model.
5. It is a model that addresses an important unsolved problem: how to effectively manage
business logic and business rules, not as lists or annotations attached to or buried in other
models, but in a model of their own.

The Decision Model as an Impetus for change

The Decision Model has the potential to change current business management practices and
future technology, enabling both business and IT professionals to rethink the way they view,
design, execute, and govern business logic. Practice indicates that the Decision Model makes it
possible for nontechnical business people to interact intuitively with their own business logic.
This leads to natural business governance over business directions and agility.

Industry analysts predict significant growth* in the technology areas of Service- Oriented
Architecture (SOA), Business Process Management (BPM), and Business Decision Management
(BDM—also, and interchangeably, referred to as Enterprise Decision Management (EDM)). Major
corporations investing in one or more of these technologies span all industries. The interest in
these areas stems from a growing need to enable business agility, leverage current investments
in IT infrastructure, and gain control over IT governance.
Each of these trends promises to deliver supporting infrastructure around an important and
proprietary business asset: the business’s logic that should drive its operational transactions in
the most desirable manner. Therefore, a model of such business logic is at the center of all of
these emerging areas. Industry analysts, vendors, and practitioners proclaim that such business
logic today needs to be separated from other logic so as to be reusable, changeable, and deployed
in corresponding technology. It needs to be delivered in appropriate technology and made avail-
able to all business processes and systems that need it and across emerging SOAs. However,
without a well-formed model of business logic, there is little rigor and no solid roadmap for
achieving this. Based on experience, the Decision Model has the potential to bring about the
following kinds of changes:

 IT and business management methodologies that promote business decisions

and corresponding Decision Models to the level of prominent management levers
 Commercial automation software that supports decision services derived from Decision
Models
 Commercial modelling and requirements software that enable specification and
governance of Decision Models from business to technology
 Delivery of domain-specific decision logic that become standard commodities
 Business leaders who will view, value, challenge, and simulate their own business logic,
before, after, and even if it is not, automated history.
 A person with a poor job history, a large mortgage, and a significant number of
miscellaneous loans is considered very likely to default on a loan.
  A person with a low credit rating must not be granted an unsecured loan.
 A person’s credit rating is computed according to proprietary formula

First of all, each of these statements is expressed in the way that a business person might
express it. None is stated in terse, forced, unnatural, or pseudocode format. The expressions are
business-friendly and serve as a starting point. The goal is to discover the intended business logic
behind the statements and translate it into a more rigorous form in a Decision Model. In fact, a
natural language statement can be generated from the Decision Model that is more precise than
the raw material from which it started.
For now, each of the foregoing statements is, simply, one business conclusion. That is, each
statement comes to a simple or complex conclusion (e.g., a loan applicant is considered to have a
poor job history) based on facts (e.g., how many jobs a person has held in the past five years).
The first two statements come to a conclusion about a person’s job history. The third one
arrives at a conclusion regarding a person’s likelihood of defaulting on a loan. The fourth comes
to a conclusion about granting an unsecured loan. And, the fifth comes to a conclusion about the
value assigned to a person’s credit rating.
In the fourth statement, the conclusion seems like an unconditional constraint because it
defines a situation that must never be true. In the fifth statement, the conclusion is the result of a
computation because it provides a specific formula. Regardless, each of these statements still
arrives at a conclusion using certain facts as input (i.e., conditions) specified by business leaders.
Capturing business logic, from conditions to conclusions, and refining it until it is atomic,
precise, unambiguous, and aligned with business objectives is what the Decision Model and its
principles are all about. A Decision Model is a prescription for how the business arrives at fact-
based conclusions that collectively represent the intended business logic behind a business
decision.
These individual conclusions and their representation in a Decision Model are independent
of whether they support complex custom software, purchased software packages, or processes
carried out by humans. In fact, a Decision Model conforms to all Decision Model principles
regardless of type of automation or lack thereof. In practice, it is best to develop a Decision Model
up front and then deter- mine whether the Decision Model is best carried out by technology or by
humans. If technology is most appropriate, the Decision Model can assist in selecting the
technology that best fits the characteristics of the business logic behind the business decision.*
The next section introduces the basic concepts about Decision Model structure.

From Business Logic to Decision Model Structure

A quick way to learn about the Decision Model is to start with a business statement and
translate it into a structural element of a Decision Model.
Suppose a financial institution provides various kinds of loans. Recently, the number of
customers defaulting on loans has increased so significantly that the business experts want to
sharpen the business logic that determines the likelihood of such default. The business experts,
therefore, need a Decision Model that comes to a conclusion about a person’s likelihood of
defaulting on a loan. This new Decision Model needs to be put into action. The business then
needs to monitor the frequency and magnitude of subsequent loan defaults. A comparison of past
to future defaults measures the effectiveness of the new Decision Model. If the improvement is
not what the business anticipated, the business logic within the Decision Model will be changed,
perhaps tested against sample loan applications, put into play in the business, and the results
measured again.

Decision Model Notation and Supporting Software Tools

To fully represent the Decision Model and its principles, a Decision Model notation is needed for
at least two different kinds of diagrams: the Rule Family table and the Decision Model diagram.
* One of the principles, for example, prescribes that a Rule Family have only one conclusion
column.
The Decision Model Diagram
The Decision Model diagram depicts only the Decision Model’s structure and not the detailed
content of its Rule Families. A Decision Model diagram, such as the one in Figure 2.1, begins with
an octagonal shape that represents the entire business decision. It is this shape that relates to
tasks within business process models and to steps within use cases, pre- cisely at places in those
models where the business decision is in play. The business decision shape also connects to
business objectives, business tactics, and business requirements.
The Rule Family directly connected to the business decision shape is called the Decision Rule
Family because its conclusion is the conclusion sought by the entire Decision Model.

Rule Family Table

A Rule Family table provides a complete view of the content of a Rule Family. Clearly, each Rule
Pattern in the diagram may represent from one to many rows of business logic statements. The
Decision Model diagram enables a view of the structure of the model without having to deal with
the detailed content.

Business Logic and Business Rules

In the previous lesson we indicated that, informally speaking, business logic is nothing more
than a set of business rules represented as atomic elements of conditions leading to conclusions.
For the most part, this is true, although there are various definitions for the phrase “business
rules.”* For the purpose of this book, the Decision Model constrains atomic elements expressed
within business rules or expressed in other ways and their arrangement to produce one and only
one proper structure. This means that any business rule or statement that can be expressed in a
language or diagram as atomic elements of conditions leading to conclusions can be depicted in a
Decision Model. Yet, it is important to note that not all such statements are created equal.
Specifically, some have more value to the business than others.
So, in practice, the Decision Model is most useful for business rules or statements that can
be expressed as conditions leading to conclusions that are of measurable business impact.* The
reason for this distinction is that there are many kinds of statements and rules that are
sometimes called business rules but which are not the ideal target for a Decision Model (even if it
is possible to put them in a Decision Model).
Business logic best targeted for a Decision Model is of a purely business nature, involves
evaluation of facts leading to a conclusion, represents one business decision, is not easily
represented by another means, and is subject to change. These considerations lead to a model
that is of high and measurable value to the business.

Each is explained in more detail in the following subsections.

Consideration #1: The Logic Is of a Purely Business Nature

Logic of a purely business nature does not include logic for determining data quality, data
transformations, workflow routing, or driving interface sequences. Data validation rules are an
example worth exploring.† Most often, data validation rules are not the optimum target for a
Decision Model. One reason is that they do not arrive at a business-oriented conclusion. Rather,
data validation rules ensure that data meets certain requirements so that it is of good quality.
Once data validation rules have been applied to data, the data can be used as facts leading to a
conclusion in a Decision Model. However, the data validation rules themselves are typically not
part of the Decision Model, but external to it.‡ Transformation rules contain logic for translating
data from one format and representation to another. Data transformation rules do not result in a
business- oriented conclusion. Workflow or process-routing rules contain logic regarding where
to send work. However, this conclusion is about managing workloads, not making purely
business-oriented conclusions. User or system interface rules come to conclusions about a
particular navigation sequence through Web pages or some other interface, but do not result in a
purely business-oriented conclusion.

Consideration #2: The Logic Is Intuitively Represented as Conditions and Conclusions

When this is so, an entire web of interconnected logic emerges based on the very nature of the
logic itself. For example, data validation rules for an address are usually a list of constraints for
each field in an address. A state code must be two characters drawn from the set of standard
state codes. A zip code has its own type, length, and domain. The same is true for street number,
street name, and town name, and other possible pieces in an address. Although it is possible to
express these data validation rules as conditions leading to a conclusion of either “valid field” or
“invalid field,” this is not the most intuitive way to represent them. Further, most data validation
rules are simple, and the set of validation rules for one field may be unrelated (or minimally
related) to the validation rules for other fields. Therefore, they do not form a very interesting
cohesive logic model.

Consideration #3: The Logic Has a Natural Boundary

The Decision Model captures business logic bounded by the limits of a business decision. This
means that the logic is about business reasoning, not other kinds of reasoning. In this book,
business decision is defined as a conclusion that a business arrives at through business logic and
which the business is interested in managing. So, Characteristic #3 institutes a realistic boundary
around a Decision Model. Characteristic #3 requires that an entire web of business logic (i.e., a
whole Decision Model) arrive at an externalized conclusion worth managing. It is the notion of
business decision that elevates business logic to its highest business value.

Consideration #4: The Logic Is Not Known Otherwise

This may include logic that lies buried within system code, peoples’ heads, or in imprecise,
outdated manuals. On the other hand, logic that stems from a reliable, proven representation,
such as data validation rules, is not the optimum choice for a Decision Model. For example, logic
that can be derived from a data model (i.e., “the brother of my father is my uncle”) is best
ascertained by following relationships in a data model that provide the definition of uncle. A
Decision Model, while it can represent this logic, is probably not needed. Security and
authorization rules are sometimes considered as business logic for a Decision Model and
sometimes not. One reason they are usually not the optimum choice for a Decision Model is they
come to a conclusion about a very narrow type of judgment. The conclusion is about access to
systems, data, or other resources. There are other more common and practical ways to manage
these kinds of rules, usually within security and authorization software.

Data validation rules are most often represented as part of data-oriented deliver- ables (e.g., data
models, database Data Definition Language), data transformation rules in Extract Transform
Load (ETL) deliverables, workflow rules in BPMS, and so on. There is usually no pressing need to
represent such rules in two different ways when current practice suffices.

Consideration #5: The Logic Needs to Change Often

The Decision Model is for managing important business logic, especially the business logic that
enables enterprise agility. If target business logic hardly ever changes, other forms of
documentation may suffice. Again, an example is data validation rules. These tend to be very
static, once defined. So, these are not the optimum target for a Decision Model. However, for
business logic that changes, a Decision Model (and Decision Modeling tool) provides traceability
for impact analysis. This traceability includes connections to other Decision Models, business
process models, use cases, systems code, and business metrics impacted by changes.