As I discussed in my last column, scenarios are gaining popularity within the object-oriented (OO) community. You can use them in the analysis of a business or in business rule discovery. You can use the different types of scenarios to examine the business from different perspectives. Last month, I went over two of these types of scenarios, business event simulation and life cycle analysis. In this column, I will continue exploring scenario-based analysis by discussing a third perspective where scenarios are valuable: reality knowledge assessment. Then I'll provide some tips on developing robust scenarios.
An enterprise's knowledge base reflects what the organization knows at any point in time. In some cases, that knowledge may be faulty because it does not reflect the true reality of the situation. In the Wagner household example from my last column, the bank's knowledge base was initially incorrect with respect to the members of the Wagner household because it didn't reflect Amber's existence. However, adding Amber to the Wagner household doesn't necessarily mean that the bank's knowledge about the Wagner household is complete; other household members that the bank doesn't know about may also exist. A "reality knowledge assessment" scenario can be effective in determining the degree to which an enterprise's knowledge base reflects reality.
The scenario starts by describing a hypothetical customer relationship, such as the bank's relationship with the Wagner household. The people in the household are identified along with their contact points (addresses, phone numbers, and so on) and relationships with other parties outside the household (such as employers and schools). This household configuration represents the "reality" of the household by describing what the enterprise wants to know about the household to manage its customer relationship effectively with the people that make up the household.
Next the analyst examines the business events that are intended to be the source of information about the household to determine how closely the organization's knowledge base will reflect reality. For example, the events being analyzed are:
•The acquisition of information about households through third-party data
•The tracking of responses to campaigns.
For example, the bank purchases data about households from a third-party source that includes information about the Wagner household. After the data has been processed, the bank knows that the Wagner household exists, that Mary Wagner is the head of household, that there is a teenager and a preteen in the household, and where the family lives. We don't, however, know the names and exact ages of the children or that Mary owns her own business. Next, because the Wagner's home is located in an upscale neighborhood, the Wagner household is included in a mass mailing campaign offering special pricing for a homeowner's package that includes checking, savings, investment, and life of credit products. Mary responds by calling the bank's campaign telemarketing line to inquire about the products offered. She opens the accounts and establishes accounts for her business, Caligraphics. Once this event is completed, the bank's knowledge base reflects Mary's relationship to Caligraphics.
As each event is analyzed, it becomes apparent that the bank is dependent on information volunteered by the customer. An assessment of the bank's business practices and information systems may reveal that they are not positioned to support and manage the information about households that the current competitive banking environment requires. The scenario analysis approach can be instrumental in highlighting which types of knowledge you can fill by purchasing third-party data about households and which information is only available through direct interaction with the customer. You can also use this scenario in assessing the risk of missing information to the bank's customer-relationship management strategy.
A scenario is intended to illustrate one or more aspects of the business under analysis by depicting real-world situations that can be encountered in the course of conducting business. Although the people and companies represented in the scenario may be fictitious, the scenario should represent a situation that can be encountered within the business domain being examined.
Analysis of a complex subject may require several scenarios. For example, many companies who provide services or products to consumers are interested in how the people in a household collectively influence buying behavior. The typical definition of a household is a group of individuals who can be treated as a unit when examining how they use a company's products or services, but this definition is broad and, in its current state, open to interpretation. You can use scenarios that illustrate different configurations of people to refine the definition of what an enterprise really considers a household to be. The scenarios should start with a simple household configuration and progress to more complex situations (see Table 1).
Once you have identified the various situations of interest to the organization, create your scenarios by fully describing the context. For households, you need to create people, companies, families, addresses, email addresses, and phone numbers. Name the people and companies. Give them meaningful addresses and phone numbers. Make the scenarios as real as possible. With the wealth of clip-art images available, you can give your people faces as well as names. Draw pictures to represent the household configurations (see the scenarios depicting the Wagner family in my June column). Using real customer relationships as the basis of your households can be effective. The family relationships of the people participating in the analysis sessions can often yield rich examples of household interactions. The objective is to make the scenario as real as possible.
Developing a scenario should be a creative and fun endeavor. For example, one southern company used characters from "Gone with the Wind." The mood of the analysis session definitely lightens up when you have Scarlett O'Hara calling in to place an order for your products. In another situation, an upscale bank wanted to demonstrate all the computer systems that must be used to answer some basic business questions. Using one of its real customers, a famous rock star, the bank developed a scenario around a hypothetical situation: The rock star (we'll call him Elvis) wanted to take his entourage out for a night on the town after a successful concert. The gate receipts from the concert ($100,000) had been deposited into Elvis's business account the night before. Elvis had exceeded his credit limit on his credit card, so he needed an emergency credit line advance of $10,000. The bank was willing to make credit extensions to customers if the combined balances from all accounts (both personal and business) exceeded the desired credit. The scenario illustrated all the screens a banker had to navigate through in order to find out that the deposit for the gate receipts actually existed. The use of this scenario as the basis of a live demonstration of the current workflow to the bank's CEO was instrumental in gaining the funding for a project to integrate and streamline these computer systems.
While the base set of scenarios should be developed with the business subject matter experts (SMEs) in facilitated sessions, the scenarios for the more complex situations should probably be developed by the business rule analysts offline. You want to maintain control of a certain set of scenarios that you use to represent specific aspects of the business into which you want to delve deeper. The SMEs will probably develop a set of scenarios that meet about 80 percent of the situations their organization will encounter. It's that remaining 20 percent that can hide many of your organization's rich and interesting business rules. Probe the boundary conditions--those situations that the business still wants to know about but that rarely occur. Often, the more upscale the customers, the more complex their interrelationships become.
Your consistent set of scenarios has a life beyond just the business rule analysis sessions. You can use them as the basis of the business examples and sample data instance tables you create as part of your data or object-class model. Once a prototype of the information system is available, I use the situations from the scenarios as test cases. Because the SMEs are familiar with the people, organizations, relationships, products, and events depicted in the scenarios, they can easily determine whether the supporting system is behaving correctly. If the SMEs are not happy with the prototype, you can use the scenarios to determine where the miscommunication exists. If you assume that the prototype accurately supports the business rules specified in the scenarios, then either the scenarios or business rules are not properly stated. Correct the scenarios if they don't really reflect the situation properly. Examine the business rules carefully to determine if they have been misstated. You can use the prototyping effort to test and validate each scenario and its related business rules interactively.
Successful scenarios tend to have long lives. As applications are enhanced to encompass new functionality, the scenarios become the focus of the business rule- gathering sessions. The scenarios tend to grow as the applications are enhanced. In one case in which I started a scenario using Dick, Jane, and their dog Spot as my household, the company was still using and enhancing the scenario several years after I had left the organization.
Terry Moriarty is president of Inastrol, a San Francisco-based information management consultancy, and she specializes in customer relationship information and metadata management. You can reach her at terry_moriarty@compuserve.com.
| Situation | Scenarios |
|---|---|
| Everyone living at the same address with the same last name |
1. "Traditional" family (husband, wife, and children) 2. "Traditional" family who has a parent living with them 3. Siblings who live together |
| Everyone living at the same address, regardless of the last name |
1. "Traditional" family where the wife uses her maiden name 2. Second marriage where the children have different last names from the adults 3. Roommates 4. People with common last names (such as Smith, Gomez, or Lee) who live in the same apartment complex but didn't include their apartment number in their address |
| People and organizations at the same address | Home office |
| People with multiple addresses | Vacation home |
| "Extended" families whose members reside at different addresses | 1. College student who lives away from home 2. Divorce situations where children live with one parent 3. Parents of the adult members of a household |