Recently, I was using the website of my favorite airlines to book my reservations for my regular flight. For some reason, it wasn’t showing up in the list of nine flights the website showed as
available for between the cities during the time periods I’d specified. Finally, in frustration, I called the reservations line where the customer service representative easily located my
preferred flight. I didn’t want to make the reservations over the phone because of the premium charged for using the airline’s employee to booked flights. With the knowledge that my flight was
available, I repeatedly entered the same query into the website until the flight showed up.
All the evidence indicates that the business rules being used by the airline’s reservation channels were different. While, I like the freedom to choose the channel I use to interact with an
organization, I do expect to the same result through each.
For years, the Data Management community has lobbied that data must be managed as a resource that is shared across the enterprise. But, shared data is not enough to ensure consistent behavior from
one channel to the next. The business rules that guide an organization’s response to a given business event must also be consistently applied. Its necessary to identify those business rules and
processes that apply to all channels and which are channel specific.
To prescribe consistent behavior, consider the flow of a typical business event. Greg Loomis is placing a reservation to rent a car for his next business trip to Washington D.C. This is Greg’s
first reservation since joining the Loyalty Program.
The event beings with Greg submitting his reservation request to the car rental company, invoking the “Place a Reservation” business process. The details of the reservation (e.g. the pickup date
and location, requested car group, return date and location) plus the information maintained in the company’s knowledgebase about Greg, such as he is a member of the loyalty program, provide the
context for the event. The context represents the current state of the objects involved in the event: Greg and the location where the car is going to be picked up. This context determines which
business rules apply to the event. For example, if the pickup location does not have the car group that Greg wants to reserve, the reservation can not be accepted.
The business rules determine the path through the business process. That path determines the final result (the behavior) of the event. Because Greg is a member of the loyalty program, business
rules apply that will cause different behavior for this car reservation process than if the reservation was for a non-loyalty program member. Based on the context of the event, the following
business rules are invoked.
The resulting behavior is that Greg’s reservation includes a one car group upgrade from what he originally requested.
Finally, the knowledgebase is updated to reflect the new state:
- Reservation with upgrade
- Greg no longer qualifies as a New Loyalty Program Member
The “Place Reservation” scenario illustrates the synergy that exists between the business process, the state of the related business objects, as represented in the enterprise’s knowledgebase,
and the business rules. If an organization wants to ensure consistent and predictable behavior for its business events, a business model that addresses all three perspectives must exist. The
Business Behavior Triad™ provides a framework for developing that business model.
The Business Behavior Triad (BBT) models the desired business behavior in response to events by specifying your organization’s:
- Knowledge, using Business Concepts to build its Vocabulary
- Business Rules, using an formal grammar that enables business rule analysis for consistency and dependency
- Business Processes, that specifies the activities that are performed in response to an event
The BBT uses a test-driven approach through the use of event scenarios to discover the business model and validate the expected event behavior.
Knowledge
Knowledge is everything your organization must know to successfully conduct business. That knowledge may be explicitly recorded or may be implicit knowledge known only to a few key employees. Some
business rule efforts are primarily launched to recover the implicit knowledge of employees who are planning to retire. Organizations are recognizing the value of that knowledge and want to make
sure that it doesn’t walk out the door with the person. Knowledge may be unstructured, held within a variety of media (e.g. documents, images, recordings, and video). To ensure consistent behavior
for a given business event, knowledge must be structured in a manner that can support an automated process.
Knowledge is structured by, first, identifying all the business concepts that are used to express that knowledge. Each business concept is defined and all the terms used to reference that business
concept are listed, along with each community within the enterprise that uses each term.
The approach I use to represent business concepts is loosely based on Dr. Terry Halpin’s Object Role Modeling. Initially, no attempt is made to classify a business concept as an entity or an
attribute. The intention is simply to develop a Business Concepts Catalogue that serves as the enterprise’s vocabulary, dictionary and thesaurus. As business rules are identified that relate
business concepts together (known as fact business rules), the nature of each business concept will emerge.
Business states hold a special position within BBT as many business rules apply to business entities only when they are in a specific state. For example, the following business rules for assigning
cars to reservations are dependent on the state of the car.
Business Rules
“A Business Rule is a Directive, intended to govern, guide or influence business behavior, in support of Business Policy that has been formulated in response to an Opportunity, Threat, Strength,
or Weakness.”[2]
In BBT, a business rule is a statement of business policy that can be made actionable in an automated system. The intention is to separate Business Policy expressed as Business Rules from the
Business Processes they control. Business rules are usually more volatile then the associated business processes. In fact, often, it is the changes to business rules that cause corresponding
business processes. When business rules are treated independently of business processes, it is possible to determine impact of a business rule change on the behavior of a Business Event as is flows
through a Business Process. This treatment of business rules is not that dissimilar to the separation of data from process. Business rules can become actionable when they are expressed using a
grammar that can be readily transformed into information systems. The first step is to create a classification scheme that allows business rules to be expressed, analyzed, simulated and,
ultimately, implemented within the applications portfolio. In BBT, at a high level, the business rule classification scheme consists of three categories.
Structural business rules (also known as fact types) provide the foundation of the BBT business model. They tie all the business concepts together, “much as ligaments connect bones together in the
human skeleton”. [3] All other business rules and processes are expressed in terms of business concepts and structural business rules.
Structural business rule statements are expressed as . Every structural business rule is expressed in a manner that can be read with either business entity as the subject of the sentence, as shown
in the following examples of the primary structural business rule categories. Structural business rules are stated unconstrained. Validation Integrity business rules specify any constraints that
pertain to these types of business rules.
The business concepts diagram (or fact model) depicts the business concepts for the business domain being analyzed and the relevant structural business rules.
There are currently no standard notation for depicting a business concepts diagram. BBT uses one that is based on Object Role Modeling (ORM) and Unified Modeling Language (UML). All business
concepts, including knowledge properties, are represented in a box. Business states are connected to the business entity they subset through the triangle symbol.
Data modelers have asked why a standard data model, either conceptual or logical, can’t be used as the business concepts model. It depends on your definition of those models. To many, a conceptual
model consists of high level, almost subject level entities, with no attributes or, often no verb statements. Business terms are used to reference the entities in the conceptual model. Logical
models have been subjected to relational normalization, often using the “name for clarity” rule. In this case, business terms may have been modified to support data management standards,
associative entities have been introduced that may not correspond to any business recognized concepts and derivable attributes may have been normalized out of the model.
Under these definitions, these data models can’t be used as the business concept model. Business rules are written using the applicable attributes expressed in business terms. What is needed is
something in between, in essence, a fully attributed conceptual data model. If your definition of a conceptual or logical data model matches this definition of a business concepts model, then use
your data models. Certainly, the analysis approach for developing the business concepts model is identical to data modeling and analysis.
Integrity business rules ensure that the result of every business event leaves the structured information contained in the enterprise’s knowledgebase in a rational state.
Behavioral business rules determine the path an event taked through a business process.
Business Process
The business process brings the knowledge and business rules together by specifying the activities that are performed to complete the business event while ensuring that the integrity of the
knowledgebase is maintained.
Business Process Management Notation (BPMN) is the newest standard for depicting business processes. The notation was originally developed by the Business Process Management Initiative (BPMI)
organization, who has recently joined the Object Management Group (OMG).
The following BPMN diagram shows the flow for assigning cars to the day’s reservations. The diagram depicts the events, processes, decision points (as gateways) and data objects. A data object is
the BPMI equivalent of a business concept. Business states are identified in parentheses within the data object icon.
Business rules are attached to the business processes to complete the business model, as illustrated in the following table.
Where to Start
I’m often asked what is the right starting point for developing a BBT business model. With the business processes, business concept model or the business rules? It depends on the objective of the
project.
If the intention is to re-engineer the business process with minimal changes to the business concepts or business rules, then start with the business process analysis. Very often, what you will
actually be doing is re-allocating the business rules to different activities in the process, consolidating business rules or removing those that are dormant.
If the intention is to understand a specific subject area (e.g. what is customer, partner, product), then you will probably spend your initial time discovering the business concepts and structural
business rules about that subject area, then move into the integrity business rules. Finally, you will explore and specify the new business processes and behavioral business rules that will be
needed to support the insights gained from developing the business concepts model.
When the objective is to insert a new capability into the existing business process, such as entering into a new market, introducing a new product or responding to new regulations, it is best to
flush out the business rules, including changes to existing rules, and then identify the impact on the business process and business concepts models.
Regardless of the starting point, you are not finished until all aspects of the BBT have been fully specified and analyzed. Your completeness analysis will hunt for any of the following situations:
- Activities in the business process model that have no related business rules.
- Business process activities that have no associated business concepts as input or output.
- Business concepts that are not used by any business rule.
- Business concepts that are not input or output of any business process.
- Business rules that are not used by any business processes.
Finding these situations does not mean that the business model is incomplete, but each situation should be investigated to ensure that the business model is actually complete.
The Business Behavior Triad is a valuable approach for analyzing your business from all perspectives that results in a business model that is complete, consistent and integrated across your
vocabulary, business rules and business processes. With this approach, you can easily identify business rules and processes that are common across a business event, regardless of the channel used.
Plus, those business rules that are channel specific, like the additional charge that the airline charged when making reservations through the customer reservation call center.
[1] Knowledge Property is a concept that I borrowed from Dan Tasker’s in his object-oriented book “The Problem Space”.
[2] The Business Motivation Model, Business Governance in a Volatile World, Prepared by The Business Rules Group, Release 1.2, September, 2005
[3] Business Rule Concepts, Getting to the Point of Knowledge, Second Edition, Ronald G. Ross,
