Road Maps for Business Rules Discovery
Technology alone is rarely, if ever, a silver bullet. Yet technology deployed with intelligence becomes interesting and powerful. When you deploy technology so that it externalizes and manages the thinking or decision-making capacity of an organization, you empower the business to use that technology as an extension of intellectual power.
Such is the goal of business rules systems. Parts 1 and 2 of this series defined a business rules system as an automated system in which the "rules of the business" are separated (logically, perhaps physically) and shared across data stores, user interfaces and applications.
Part 2 of this series suggested a business rules approach should incorporate at least four methodology tracks within six methodology phases. The four tracks are an application/process/ workflow track, data track, technology track and a rules track. The six phases (and you can conduct them in parallel to some extent) are scope, plan, discover, analyze, design and deliver.
This month's article will provide important insights into the business rules approach to the discovery phase.
The first phase is the scoping phase, the precursor to discovery. Scoping is the process of capturing high-level business requirements and boundaries for a new or enhanced information system. The discovery phase uncovers detailed system requirements but remains technology neutral.
Perhaps the most unique aspect of the discovery phase for a business rules approach is the perception of a business event as a set of decision-rich activities. That is, in following a business rules approach, you unravel a business event as a set of decisions. Moreover, you make sure the decisions occur in concert with organizational policies. You dissect the decisions and policies into executable and precise business rules that guide the business event in a predictable and desirable manner.
This dissection is possible because the rules are the thinking behind the business event. When a rule executes, it references pieces of information. A rule may a create a new piece of information called knowledge. Decisions, rules, information and rule-created knowledge are intellectual assets. With proper analysis, these assets can be shared across organizational boundaries when appropriate for the business. All of these intellectual assets are important focal points in a business rules approach.
To produce the separation of business rules from other artifacts, this series divides the discovery phase into two pieces. The first is the discovery of basic system behavior. The second is the discovery of the underlying rules and data. During an actual project, you may combine these two pieces into one discovery effort.
In a business rules approach, the purpose of discovering basic system behavior is to document only the essential aspects at first. These aspects lead you to the discovery of the underlying data and rules. For our purposes, essential aspects can be determined using the following steps.
Step 1 Understand the Business Event or Its Process. In this step, you aim to understand the details behind a business event, but only enough to uncover rules. You can understand the details by studying response interactions, tasks within a use case, low-level processes or even concrete scenarios in search of processes driven by decision-making activity.
To avoid endless debates, use an approach that is comfortable for your audience. Also, remember that you are not concerned with sequence at this point; you are looking for a fast path to the decisions and rules behind the event.
As an example, assume you need to understand the business event "admit a child into an Internet theme park." A businessperson identifies six activities behind this event merely to start the conversation on familiar ground. The activities are:
- Activity 1: Request login information from child.
- Activity 2: Qualify (or identify) child.
- Activity 3: Ask child- specific admission questions as established by child's guardian.
- Activity 4: Determine if child admission is allowed based on answers to the questions.
- Activity 5: Determine if child admission is allowed based on guardian billing status.
- Activity 6: Send child's answers to guardian (for guardian's reference).
Step 2 Add Concrete Scenarios. A concrete scenario is an imaginary or actual instance of a business event. Listing scenarios is often a useful and fun way to start or solidify a conversation about the business event. Later, concrete scenarios prove useful for validating the system and all of its rules.
Your business audience for the Internet park may propose the following scenarios for the business event "enroll child in the park":
Scenario 1: Mary is a single parent with a 14-year-old daughter. She wants to enroll her daughter in all theme park functions. Her daughter always does her homework and her chores. Mary merely wants to ask her daughter, prior to park admission, if she received any good grades that day. Her daughter can have one hour in the game park every day but gets an extra 30 minutes for every good grade. Mary is a new customer. We don't know if she is a good credit risk or not.
Scenario 2: John and Barb want to en-roll a 10-year-old boy. He is to be tutored in reading for 30 minutes a day using the tutoring function of the park before he can enter the game park. His reading skill level is age 8. He can have one hour of access to the game park per day. John and Barb are existing customers with another child enrolled. Past history indicates that they do not have good credit.
Step 3 Identify the Decisions Behind the Event. In this series, a decision is a judgment to be made. Sometimes a decision is simply the execution of one rule. For example, if the decision is that a product is in stock if there is at least one of the product on the shelf, the decision is made by executing one rule. That rule is: If the quantity of the product on the shelf is greater than zero, then the product is in stock.
Often, however, a decision results from the execution of many rules. As an example, suppose the business adopts a policy to leave the last 10 products on the shelf for preferred customers. The policy may be enforced by two rules, each of which is compliant with the policy. One rule states that if you are a preferred customer, the product is in stock if there is at least one on the shelf. The other rule states that if you are not a preferred customer, the product is in stock only if there are eleven or more on the shelf, because the business needs to reserve the last 10 for preferred customers.
For the Internet theme park example, your participants confirm that the system makes decisions only in Activities 2, 4 and 5. Figure 1 documents the decisions for Activities 4 and 5.
Figure 1: Activities and Decisions
Discovery of Rules and Data
You are now ready to discover rules and data. While full details are beyond the scope of this series, consider the following steps for discovering rules and data.
Step 4 Identify Rules Sources. A rules source is a place to go to begin to find rules. A rules source can be a person, document or program code.
Step 5 Select a Rules Discovery Road Map. A rules discovery road map is a description of the journey you will take with the rules sources in search of rules. A rules discovery road map consists of the rules- related deliverables, a prescription for and samples of those deliverables, and steps for how you will travel from the starting point to a set of rules.
You create a rules discovery road map because rules do not come to the surface by themselves. You lead business experts (or program and data inspectors) in articulating the rules or in finding them within documents or code.
You can deploy a mission-policy road map, which starts with the business mission, moves to policies and then to rules. You can craft a use- case- decision road map, which starts with a use case, proceeds to decisions and then to rules. Or, you can choose a process-decomposition-decision road map, which begins with a traditional process decomposition diagram, proceeds to decisions and then to rules. You can also create a workflow-decision road map, which begins with a workflow deliverable and seeks rules at various points. A data- analysis-rule road map starts with the data model and uses it to search for rules.
For the Internet theme park example, we will use a version of an event-decision road map, which starts with a business event, proceeds to decisions and then to rules.
Step 6 Scope the Rules for Discovery. You must determine the kinds of rules you want to discover and manage formally. You will need rule-naming conventions. You will also need to decide how to express rules.
For the Internet theme park, we want to manage complex constraints, guidelines, computations, inferences and action- enabler rules as standalone rules. We will store them in a homegrown rules repository. Rule names will indicate the classification for a rule (constraint, guideline, computation, inference or action-enabler) and the entity or attribute it most closely governs.
Step 7 Discover the Rules. This step simply involves executing your rules discovery road map.
For the Internet theme park, let's look at Activity 5 and the decision within it: Does guardian have sufficient money to pay for member entrance?
Starting with constraint rules, you can ask participants if there are circumstances that will prevent the child from entering the park. In this example, your participants mention one constraint: the guardian must have an acceptable billing status to allow a child entrance to the park. The details behind a guardian's billing status are determined by inference rules. You can uncover these rules right away or table them until you move on to discovering inference rules.
When moving on to inference rules, participants discuss how guardian billing status can be based on guardian payment method, guardian credit and amount of prepaid hours. This leads to the four inference rules in Figure 2.
You next seek guideline rules. Your participants find no circumstances that give rise to warnings. Therefore, as yet, there are no guideline rules.
You seek computation rules. It seems likely that "guardian prepaid hours" and "member theme park allowed time" may be computed values. You will need to uncover the computation rules for these values.
Finally, you search for action enablers that initiate external events. In these examples, there are none.
Figure 2 captures Activity 5, its underlying decision, preliminary rules behind each the decision and the classification of each rule.
Figure 2: Decision- Rules Table
Step 8 Authenticate the Rules. To authenticate the rules, you must make sure the rules are positioned to guide all relevant business behavior. Specifically, make sure the rules are active where the business leaders want them to be and congruent with the business context. Authenticating rules should be part of a rules stewardship program.
Essentially, there are two important aspects in authenticating rules. The first is full rule jurisdiction. A rule's jurisdiction refers to the territory in which the rule guides behavior so that common business objectives are more likely to be achieved. The jurisdiction can be expressed as:
- Geographical locations where the rule is relevant (such as by state, country, continent)
- Political boundaries within which the rule is relevant (such as corporate, division, department)
- Types of actors for which the rule is relevant (such as preferred customers, undesirable customers)
The second aspect in authenticating rules is parties whose consensus is required to approve or change rules. These may be regulatory agencies, the overall enterprise, divisions, organizational representatives or end customers.
For the Internet theme park, all participants agree that all of the guardian billing status rules should be enforced for all guardians and all members in all locations.
The member services and finance departments need to approve rules and rule changes.
Step 9 Give the Rules Business Value. You now drive the business context of the rules to completion. If possible, tie each rule to the policies it implements. Doing so allows future analysis of policies (do they continue to support changing objectives, for example) as well as analysis of rules (do they, in fact, support those policies).
In the absence of formal policies, consider connecting rules to common business motivations. For example, why is the organization enforcing or suggesting a specific rule? Possible reasons are to:
- Comply with regulatory mandates
- Bring value (delight) to the customer
- Increase revenue
- Increase profit
- Minimize risk
- Open new opportunities
For example, suppose you have a rule that allows a preferred customer to take the last item on a shelf. This rule exists not for compliance to regulatory requirements, but to delight the customer. If someone requests a change to that rule, the rules steward should evaluate the change as to whether it has a positive or negative impact on delighting the customer or whether the idea of delighting the customer is no longer a priority.
Step 10 Define Terms Behind the Rules. A term is noun or noun phrase with an agreed-upon definition. If you are a data professional, you recast terms into entities and attributes. Examples of terms are: customer, customer credit code and customer total dollar amount.
For the Internet theme park, there is a rule as follows: Input member login ID must be in the set of Member Login IDs.This rule contains two terms:
- Member: a person between the ages of 11 and 14 who is enrolled in Park Services (probably an entity in the data model)
- Member login ID: a preassigned character string that uniquely identifies a Member to the park system (probably an attribute of Member).
Step 11 Uncover Facts Behind the Rules. A fact is a complete statement connecting terms (via verbs or prepositions) into sensible, business-relevant observations. If you are a data professional, you recast facts as relationships among entities or as the association of an attribute to an entity. Examples of facts are "customer places order," "customer qualifies for a credit code" and "customer is worth a customer total dollar amount." Facts can be difficult to find. You may not find them until a data analyst builds the detailed data model.
Revisiting the Internet theme park, consider the following rule: If guardian payment method is credit and guardian credit rating is good, then guardian billing status is sufficient for park entrance. This rule's underlying facts seem to be:
- Guardian "is assigned" guardian payment method (probably a base fact, entered by someone with authority).
- Guardian payment method can be "credit" (may become a domain constraint).
- Guardian "qualifies" guardian credit rating (probably a base fact, entered by someone with authority).
- Guardian "earns" guardian billing status (inferred fact, value is created by a rule).
- Guardian billing status can be "sufficient for park entrance" (may become a domain constraint).
Step 12 Begin to Develop a Term/Fact Model or Detailed Logical Data Model. A term/fact model is a representation of the terms and facts comprising the vocabulary of the business, where the vocabulary is used to express rules. Alternately, and more commonly, you may develop a detailed logical data model of entities, attributes and relationships.
Step 13 Tie Each Rule to Information it References. Remember that a rule references pieces of information to determine compliance to a constraint, compliance to a guideline, compute a formula or qualification for an inferred-knowledge or action-enabler rule. In your rules repository, associate each rule to those pieces of information (or knowledge that has been created by another rule) that the rule references. Doing so allows you to perform impact analysis should any of those pieces of information change in any way.
Step 14 Tie Each Rule to the Knowledge it Materializes. A subtle, but most valuable aspect of rules is that rules can create information called knowledge. You now associate each rule with the knowledge it creates, if any.
A computation rule creates a value for the computed attribute. An inferred-knowledge rule creates an existence of an entity, sets a flag or sets another attribute value. Guidelines, constraints and action-enablers create a truth-value (a yes or no indicator denoting whether or not the constraint or guideline is violated or the conditions for action are met). An atomic rule creates only one piece of new information or knowledge. Tie each rule to the knowledge it creates again so you can perform impact analysis. This will prove useful as you move into rule analysis.
Step 15 Add Concrete Scenarios for Completeness Testing. In Step 2, you began to collect a list of scenarios. At the end of the discovery phase, create a matrix correlating scenarios to the rules tested by each one. For rules not tested by any scenarios, craft additional scenarios to ensure completeness.
During rules discovery, you dig deeper into tasks, looking for knowledge-intensive activities where decisions are made or computations executed. The activities themselves and their sequence are not yet important. Decisions and rules take priority as they represent executable thinking. Activities and execution sequence will wrap around the rules later.
Discovery ends where it begins with business context. In this way, you solidify the reason for a rule's existence, the motivation behind instituting it and the value it is expected to deliver to the business. After all, every rule costs money. Every rule should earn its keep. Every rule is an instrument of business change and an element of organizational intelligence.
Without a business rules approach, these requirements have always been addressed, but not as artifacts separate from data and process. If we separate the rules from other artifacts, we will be able to perform more advanced analysis of them and leverage new rules-oriented technology. A formal approach to fully understanding and managing business rules is very important to the intelligent enterprise.
Next month, this series continues by looking at the inclusion of inferred knowledge in data models as well as the ingredients of rules analysis, such as rule dependencies and rule patterns. Interesting opportunities arise when you position your organization to analyze its rules. This analysis enables an organization to fine-tune its decision- making capabilities and even redefine itself.
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.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access