|Sign-Up for Free Exclusive Services:||Portals|||||eNewsletters|||||Web Seminars|||||dataWarehouse.com|||||DM Review Magazine|
|Covering Business Intelligence, Integration & Analytics||Advanced Search|
Building a Business Rules System, Part 2 of 5
The Business Rules Difference in Methodology Phases
An important new technology and methodology is reshaping the way we deliver business systems today. This technology and surrounding methodology may prove crucial to business success and survival in the years to come.
With this in mind, Part 1 of this series defined the emergence of a new kind of system called a business rules system. In this series, a business rules system is an automated system in which the "rules of the business" are separated (logically, perhaps physically) and shared across data stores, user interfaces and applications.
What is a Business Rules Approach?
Building a business rules system requires a business rules approach. The phrase "business rules approach" includes both a methodology by which rules of a business are captured, managed and automated, as well as a technology for managing the rule automation (and change) process.
A unique benefit to a business rules approach is that it has tentacles in both business and systems development communities. For the business community, a business rules approach is a methodology by which business leaders utilize business rules as instruments of proactive and creative organizational change. For the systems development community, the business rules approach is a methodology for implementing, tracing and changing the rules that guide automated systems behavior.
What are Business Rules?
Last month, this series suggested that you think of business rules as the set of conditions that govern a business event so that it occurs in a way that is acceptable to the business (or customer). Further, you can think of three major categories of business rules: terms, facts and rules. Terms and facts are the underpinnings of the information architecture. They define the vocabulary of the business and how it fits into meaningful sentences.
The new excitement is in the third category - rules. Rules utilize information for creating new information (knowledge), making decisions and taking action. Moreover, for our purposes, it is useful to think of rules as being of five possible types: constraint, guideline, computation, inference and action- enabling.
Constraint rules and guideline rules test data values and either restrict behavior or warn about it. Computation rules arrive at a new data value by applying a formula to known data values. Inference rules arrive at a conclusion by testing conditions. Action-enabler rules evaluate data values prior to initiating action.
This article presents an overview of the tracks and methodology phases in building a business rules system. A quick overview of the tracks provides a basis for understanding the discussion about the phases. Note that each phase will consist of tasks and deliverables for each track.
If you are a seasoned systems developer, you will rightfully conclude that you already address all of the items discussed. The difference is that a business rules approach places more emphasis, importance and formalism on the rules of the business and, hence, the delivery of rules within corresponding system logic. Specifically, a business rules approach recognizes all five types of rules as part of a tangible business asset. The rules are worthy of being captured, managed and changed deliberately to hit business objectives. The rules are readily accessible to all who need to know and behave by them - and change with them.
Business Rules Methodology Tracks
Figure 1 highlights the four tracks in a business rules approach. The technology track focuses on the logical and physical separation of the target system into technology tiers, even if the environment does not include rule-specific technology products. The focus of the application/workflow/process track is the sequence of human/system interactions and system processing (but devoid of the rules guiding those interactions). The focus of the data track is the vocabulary and grammar of business events and transactions. The focus of the new rules track is the set of computations, constraints, inferences, guidelines and action-enabling rules that utilize the information to guide actions. Let's look at each track in more detail.
The Technology Track
The technology track includes methodology steps for the selection, customization and support of technology to leverage the business rules system design approach.
The Application/ Workflow/Process Track
The application/workflow/process track focuses on understanding actor interactions, the sequence of interactions between humans and the system, as well as interactions between the system and other automated pieces (databases or other systems). Therefore, as you follow the methodology steps within the application/workflow/process track, you will deliver a list of all business events served by the target system, the business event's associated business process and the decisions that are made on behalf of the process in servicing the business event. As soon as you transition from understanding the event's process to uncovering the decisions behind the event, you transition from the application/workflow/process track into the rules track. The transition from business events to processes to decisions to rules is a natural one.
The Data Track
The data track produces the data models and the eventual database. When you follow the methodology steps in the data track, you uncover the vocabulary and grammar with which the rules are expressed and you create a stable data structure to represent that vocabulary. Specifically, as you uncover rules, you make sure each word or phrase is represented in the data model and database. The transition from rule collection to data constructs is also a very natural one.
For now, keep in mind that a data model and the eventual database for a business rules system may be very different than those for non-business rules systems. This series will later highlight some of these crucial distinctions.
The Rules Track
The fourth track represents the set of rules behind the interactions and over the data, where the rules are managed as a separate, externalized, logical component. The methodology steps for the rules track lead you in the capture, analysis, automation and change of the business rules. These rules represent the foundational logic that guides decisions and actions within the business organization (or for a specific customer) and now within a business rules system. The rules track aims to externalize the business rules so that the target user community (even one customer) can know what those rules are and understand how they guide interactions and decisions.
The rules track, like all tracks, is prevalent in all phases of the methodology. Starting with the scoping phase, for example, the rules track is evident as you seek the business context for rules. In the discovery phase, the rules track includes steps for capturing decisions and rules. In the analysis phase, the methodology includes steps for reducing those rules to a minimal but complete set. During the analysis phase, you analyze dependencies among rules as well as correlations from rules to data items and database operations.
Business Rules System Methodology Phases
A business rules approach to systems development, like most systems development methodologies, has six conceptually different phases. These are shown in Figure 2 as scope, plan, discover, analyze, design and deliver. Each phase has steps and deliverables for each of the four tracks.
Figure 2 does not intend to suggest an old-fashioned, waterfall approach to systems development. However, it is important to understand the conceptual differences between the phases. It is very important to do a thorough job scoping and planning. Keep in mind that a business rules approach aims to deliver a strong architectural foundation (to accommodate future business changes). This means that incremental systems delivery becomes the adding, changing and retiring of rules or rule sets within that foundation. This requires that the first increment include the stabilizing aspects of the information architecture, rule jurisdictions and rule stewardship. When this is so, the discovery phase can occur in incremental pieces, followed by analysis, design and delivery, while more discovery occurs in parallel.
Following is a description of each phase. Because subsequent parts of this series will address details behind the discovery and analysis phases, the following descriptions provide more insights into the differences in scoping and planning when building a business rules system.
The Scoping Phase
Scoping is the process of capturing high-level business requirements and boundaries for a new or enhanced information system. In this respect, the scoping phase for a business rules system is not unlike that of other kinds of systems.
However, from a business rules perspective, there are three business rules-oriented considerations during scoping. The first is the business context for the eventual business rules. The second consideration is the set of scoping deliverables in preparation for rules, specifically the identification of policies as precursors to rules. The third is the purpose for managing the rules behind the system.
Scoping the Business Context for Rules
The business context is the business foundation to be supported and guided by the rules. According to the Business Rules Group (Organizing Business Plans: The Standard Model for Business Rule Motivation, www.BusinessRulesGroup.org), "The basic idea is to develop a business model for the elements of the business plan before system design or technological development is begun." The business context includes an organization's mission, vision, strategies, goals, tactics, objectives and policies. Let's look at a subset of these.
Following the Business Rules Group's definition, a mission "indicates the ongoing operational activity of the enterprise." It should contain action, product or service, and customer. An objective is an end state that is measurable and time-targeted. A strategy "represents the essential course of action to achieve ends - goals in particular." A tactic is a "course of action that represents part of the detailing of strategies." Finally, a policy aims to guide the enterprise and is less specific than its underlying rules.
Scoping Deliverables in Preparation for Rules
Most systems development methodologies include common deliverables in a scoping phase. It is most useful to create, as the major deliverable from scoping, a project charter. Typically, a project charter includes reasons (benefits) for the system, business events to be handled by the system, high-level data subjects behind the business events and risks.
During the scoping phase, it is important to a business rules system that you begin to identify policies. These policies, during the discovery activities, will lead you to related decisions and underlying business rules. The policies will be ones that support the objectives of the system as well as those that minimize risks of the system. Figure 4 illustrates a sample risk mitigation table with risk mitigation policies.
Purpose for Managing Rules Behind the System
For a business rules system, it is important to determine, with the sponsor and stakeholders, whether the management of rules aims to:
Another important characteristic of the scoping phase is the planning for rules management, including methodology, repository and organizational infrastructure. This brings us to the planning phase.
The Planning Phase
Often the planning phase is simply the last part of the scoping phase. During planning, you create a project plan for building the business rules system. It should include tasks and deliverables for the following:
There are at least five aspects of your project plan that are needed to accommodate a business rules approach.
The first aspect to consider is the set of tasks for establishing rule standards. The second is the set of tasks and guidelines specifically for discovering, analyzing, designing and delivering automated rules as a separately managed asset. More details on this will be found in subsequent articles in this series. The third aspect incorporates the opportunity to test and deploy business rules technology.
The fourth new aspect to your project plan addresses at least four new roles for dealing with rules. A rules analyst is responsible for capturing rules from business conversations, documents or program code. A rules designer is responsible for determining where rules are to be enforced within application architecture. A rules implementor is accountable for coding the executable rules, although application developers or database administrators, depending on where the rules are implemented, may play this role. A rules integrator or manager is responsible for analyzing rules across business events and across applications to ensure high quality rules for the organization. The rules integrator probably also selects and manages the repository into which rules are entered and from which rules are managed.
The fifth new aspect is the set of tasks for your rules repository. These include documentation of meta data and rules repository requirements, a rule metamodel and the decision on a rule storage mechanism. You will need a rules repository user guide and, perhaps, training materials. If your project involves excavating rules from existing systems, you will need procedures for this and, perhaps, training materials here also. You may need to know the priority sequence in which to seek rules (from people or from program code). If you are fortunate, you will include tasks for establishing a rules stewardship program which identifies formally the roles in the organization that accept responsibility for policy, which leads to responsibility for rules.
When you have completed these tasks, you are ready for the discovery phase.
The Discovery Phase
The discovery phase uncovers detailed system requirements, but remains technology-neutral. For ease of understanding, this series divides the discovery phase into two pieces. The first is the discovery of system behavior. The second is the discovery of rules and data.
The purpose of discovering system behavior is to document only the essential aspects of the system behavior because these lead you to the discovery of the underlying data and rules. For our purposes, essential aspects of system behavior include five items: the tasks or activities behind each business event, the decisions made on behalf of those tasks or activities, the information referenced in making those decisions, the knowledge created or judgments made by those decisions and, finally, sample (real or imaginary) event scenarios for testing completeness of the system behavior.
A significant difference in a business rules approach emerges when during the discovery phase, you shift from discovering system behavior to unearthing decisions and rules behind business events. That is, you quickly shift your focus from events and processes (the doing aspect) to the discovery and formal analysis of the decision making (the intellectual aspect) behind a business event.
Therefore, the purpose of discovering rules and data is to begin (and never stop!) capturing rules and also to solidify the data behind the rules. Keep in mind that rules discovery will, and should be, an iterative process. In a business rules world, rules discovery essentially, never ends. After all, it is not really just a phase. You intend to build an information system designed to change its rules, add new ones and retire old ones. So, rules discovery is a continuous dialog with the business community, and that's good.
There is a fundamental shift in emphasis in an information systems development methodology that follows a business rules approach. You start the discovery process by understanding only the essentials of system behavior. You move quickly to discovering the organizational intelligence behind the event. From here, you discover the information referenced and the knowledge created by the event. Finally, you focus on the processes that employ the intelligence. Most other methodologies start with the processes.
The Analysis Phase
The analysis phase applies discipline to artifacts collected in each track. Specifically, the steps in the rules track apply familiar and new discipline to the rules collection, in much the same way that data analysis adds discipline to a collection of data elements. The methodology steps of the analysis phase lead you to find rule inconsistencies and redundancies. It includes steps for producing rule dependency chains, which unearth the essential "thinking flow" that emerges when you know the rules.
During the analysis phase, you determine which decisions (and underlying rules) are to be shared across organizational and application boundaries. The important concept to realize during discovery is that business events follow policies and require decisions to be made. When rules execute, they reference pieces of information and may create new pieces of information, called knowledge, in order to carry out decisions. All of these intellectual assets (decisions, rules, base information and rule-created knowledge) can be shared across organizational boundaries, with proper analysis, when appropriate for the business.
The analysis phase includes tasks for analyzing rules into high-quality rules sets, creating the logical data model, creating a rules- enriched logical data model, assessing the quality of source data and mining rules from source systems, if appropriate. You may validate rules through rules validation workshops. You make the decision whether to optimize the rule set for the business prior to initial rule implementation or to do so later. Data conversion specifications are written at this time.
The Design Phase
Within the rules track, the design phase includes steps for classifying rules into types that can be assigned to implementation options. A rule may be implemented in the presentation layer, middle layer, database layer or a combination of those layers. The rules design steps lead the rules designer in determining how to implement those rules in those layers. Options include business rules technology, homegrown code, DBMS stored procedures and triggers, and so on.
Therefore, during the design phase, rules are assigned to the target technology, the database is designed for its target technology, rules support within the DBMS may be designed and application process flow is designed - tailored - around rules dependency chains. Utilities are designed and conversion specifications become physically oriented. Target technology is installed, customized, tested and ready to go.
Keep in mind that target technology may not be rules-oriented technology at all. Rather, the design phase may include the design of shared program code to enforce rules (outside or within the DBMS) and the database design team may be key players here. You are aiming for well-managed rules automation. This ensures that rules are no longer redundantly (and possibly inconsistently) implemented in application code.
The Delivery Phase
During the delivery phase, data definitions are entered into database technology and perhaps also into rules technology. Databases are loaded, screens are created, and rules are defined and redefined. Users are trained and testing begins. New and modified rules are added as needed. The next delivery increment can then begin.
A Business Difference
In some respects, this article does not contain any outrageously new ideas. Of course, that's because we have had to consider all aspects of systems when we delivered them, no matter what systems development paradigm we chose. However, this article proposes that the rules track, including rules discovery, analysis, design and delivery, may make all the difference in the world to the business itself.
Therefore, your project plan (and approach) should include the rules-oriented tasks and roles specified earlier. These tasks are new tasks or familiar tasks modified to accommodate the new rules perspective. Pay special attention to these tasks because it is within these tasks that change in philosophy, focus, techniques and even products comes into play. It is within these tasks that very small changes take place. These small changes, however, bring about the big differences in the business. These are the changes that externalize and manage the policies and rules of the business so that the business can become what it wants to become. Information technology becomes the weapon of change and not a barrier to future possibilities.
The business rules differences and advantages mentioned in this article are:
Ultimately, a business person should be able to query a rules repository in many ways. The repository can produce a history of the rule - an explanation of the business objectives it aims to serve. A business rules approach puts the business people at the helm of the business and also at the helm of systems development. The business people steer the behavior of resulting systems by supplying, adding, changing or archiving rules to effect business change. Business change then ceases to be disruptive to systems delivery and to the business itself. Instead, business change becomes a proactive, strategic business weapon. The business rules become the fuel to energize the business change.
Next month, the third part of this series digs deeper into the business rules paradigm shift, discussing some of the details behind the discovery phase of business rules systems development.
Acknowledgment: The material in this article is adapted from an upcoming book to be published by Wiley & Sons in 2001. Significant contributions to the content came from Janet Wall, Art Moore, Linda (Jeney) Nieporent and Neville Haggerty.
For more information on related topics visit the following related portals...
Business Intelligence (BI).
Barbara von Halle is the founder of Knowledge Partners, Inc. (www.kpiusa.com), a consulting company specializing in information architecture, data warehousing and business rules systems development. Von Halle has also been a strategic consultant and journalist. She co-authored the Handbook of Relational Database Design and co-edited The Handbook of Data Management. She can be reached at email@example.com.