We are exposed to stereotypes early in life. Stereotypes become so ingrained that we can be unaware that we filtering our perceptions through a stereotype. Stereotypes often become cliché, such as in cowboy movies where the stranger rides into town on a dark horse, wearing black clothes and a black hat.

As we get older we gain more experience and perceive situations with greater clarity. We realize the limitations of stereotypes. We do not speak of refining a stereotype; we say, break a stereotype. However, we do refine a model. Based on our initial model we start making assumptions. Sometimes our assumptions are valid, sometimes not. When things turn out differently than we expect, we need to question our assumptions. That is, we need to question whether our model is wrong.

In the following discussion, we will walk through a detailed example of working with a simple model. Working with a model is not easy; but just providing an overview would misrepresent the painstaking process, so bear with us.

We have all had the experience of walking into a dark room, flicking on the wall light switch and being surprised (annoyed) when the table-lamp light doesn't go on.

This type of problem solving is largely the ability to match the patterns of indicators, symptoms, and test results; to a list of candidate causes and repairs. This matching process is based upon a model of normal function. Above we listed the symptom, the light did not go on when we turned on the wall switch.

In order to diagnose the problem, we need a model of how a lamp normally functions:

• The bulb needs to in good working order, and the bulb needs to be properly seated in the lamp socket.
• The lamp switch needs to be in the proper position, and the lamp cord needs to be properly plugged in.
• The wall switch has to be in the correct position.
• There has to be electricity available from the outlet to the lamp.

We also need a set of tests and their associated repairs. This particular problem appears to be simple, and certainly does not require a planned approach to resolve. However, it can demonstrate the usefulness of models and the basic differences in different problem solving approaches. Consider the following problem solving scenario:

Step-1: The 99% case tells us that the light bulb is bad. Our first activity is to replace the light bulb.

While this appears to be a good first step, we are not done. We need to determine how long the light bulb has been operating. If it is burning out every week then we are seeing the symptom (burned out bulb) and not the problem.

Step-2: We inserted a new bulb and the light still did not go on. Now we actually have to begin to think about the problem. Now we need the model. Now we need the problem-solving checklist. Now we need a plan.

A review of the model allows us to divide our tests into chunks or layers. We may have more than one problem. We use the model to test our current environment. We resist speculating about the problem. We may be thinking, “what could be wrong?”, but we stay focussed and perform tests to see if our environment matches the model.

Test-1: We check to see that the lamp switch is in the on position.

Test-2: We check to see that the lamp cord is plugged into the correct wall socket.

Test-3: We check to see that the bulb is working. In our initial solution (step-1), we replaced the bulb with a new bulb, but the new bulb has never been tested. Therefore, we need to retrieve a bulb that is currently installed in another lamp, and working, and install it in our non-working lamp.

Approach-1: Using an electrical testing tool we assume: (1) if there is the power to the lamp socket then we must have crossed our hands with the bulbs and never really place a good bulb in the lamp socket or, the bulb was never seated correctly or, (2) if there is no power to the lamp socket and there is power to the wall socket then the lamp must be faulty, or (3) if there is no power to the wall socket then we must continue our diagnoses.

Approach-2: Using a substitute for a calibrated tool we assume: (1) if the new lamp works then our original lamp may be faulty, or (2) if the new lamp does not work then there is no power to the wall socket.

Approach-1 is a pure test and will provide non-ambiguous results. Approach-2 is a “substitution model” test and by its nature has ambiguity. Approach-1 is preferred, but in some cases, the necessary tools may not be available. When “substitution” tests are used, we must extend our tests to eliminate the ambiguities. For example, notice that with the substitution test (approach-2, test-1) we concluded that the original lamp might be faulty. This is the same result we obtained with approach-1, test-1, where the actual problem was a faulty test with the light bulb replacement, not a faulty lamp. Continuing on we will assume we are now at the state where there is no power to the wall socket.

At this point, we can state clearly that the lamp will not work without power. A correlating test would be to plug our original lamp into the wall socket where our substitute lamp worked. This test will verify that our lamp and bulb are working correctly.

The problem of no power to the wall socket further escalates the issues of tools and knowledge. To further diagnose the problem we now need a different model. Our original model assumed power from the wall socket, the “lamp” model. We now need a model of the electrical wiring in the house:

• We must have power to the main circuit box for the house.
• The circuit breakers must all be on.
• The wall sockets and wall switches must be wired correctly.
• The electrical draw from any given circuit must not exceed the breakers maximum.

Test-1: Check the circuit breaker for the wall socket in question. We find that the breakers are not all labeled, but we check each and every breaker by turning it off and then on again. After completing this test, we must re-test the power at the wall socket; and it is still absent power.

Test-2: We remove the wall socket plate and check the wiring. It appears to be okay.

Test-3: We remove the wall switch plate and check the wiring. We find that the hot-wire from the switch to the wall socket is disconnected, never allowing the circuit to complete no matter what the position of the light switch.

We correct the light switch wiring problem and then reconnect the original lamp to the wall socket and finally solve our problem. Later we find that the painter's had removed the wall switch plate the previous day in order to replace the wall switch with a new one matching the new wall color; they forgot to reconnect the new switch.

We have described a scenario using a very analytical approach to problem solving. Contrast the analytical approach with the just fix-it approach.

With a hypothesis in mind, we typically determine what the repair should be. When the repair works, we often assume our hypothesis is correct. This conclusion is premature, and could lead us to some unwarranted follow-up activities.

Actually, we need to clearly separate repair and test. Just because the repair action worked doesn't mean that, the hypothesis, our model, was correct. There are four possible situations:

	Case A.	Correct fault identification, repair works.
	Case B.	Incorrect fault identification, repair works.
	Case C.	Correct fault identification, repair doesn't work.
	Case D.	Incorrect fault identification, repair doesn't work.

You may be wondering, Okay, cases A and B make sense, but why bother with cases C and D? Case C is valuable because sometimes we get discouraged when a repair doesn't work, and we abandon our original hypothesis. If the hypothesis is correct, the correct action is perseverance, which can be hard to do when we lose faith. Case D is the degenerative case - we simply aren't on the right track. Now that we have a perspective, let's look at the problem-solving events for each case.

Here are the problem solving events in Case A:

Case A: Correct fault identification, repair works

Symptom:	light won't go on
Hypothesis:	loose bulb
Test:	Step 1: flip lamp switch off
	Step 2: tighten bulb
	Step 3: flip lamp switch
Confirmation:	light goes on
Diagnostic conclusion:	loose bulb
Follow up:	none

Case B: Incorrect fault identification, repair works

The hypothesis is that bulb is bad. We replace the bulb et voilà, light! We assume the bulb was bad. Since it was our last “back-up” bulb, we go out and buy a 6-pack of new bulbs. Comment: In fact, the bulb was loose, and not broken. Certainly, we'll eventually use all the bulbs, but the capital expenditure at this time was unnecessary.

Case C: Correct fault identification, repair doesn't work

The hypothesis is that bulb is bad, but replacing it doesn't cause the light to turn on. A possible follow-up would be to conclude the lamp is broken and it's time to get a new one. Comment: In fact, there are two faults, the lamp isn't plugged in all the way AND the bulb is bad. It was unnecessary to buy a new lamp.

Case D: Incorrect fault identification, repair doesn't work

This is classification for all the degenerative cases. Here's a somewhat extreme conclusion: Since the lamp didn't work when we turned on the wall switch, we hypothesis that there has been a power failure and we go to the circuit and flip all the breaker switches. Comment: Unless we can see other evidence of a power failure - flashing 12:00 on the VCR for example, this power-failure hypothesis has low probability and isn't worth testing early in the hypothesize-test cycle of machine repair. Nevertheless, people jump to conclusions like that all the time.

Solving the room is dark problem is trivial, but it illustrates some fundamental principles:

• The choice of model in essence lays out the problem-solving plan. Realize that our internal model of a problem affects how we go about solving it.
• As we are following the plan, we may realize that we need to change our model.
• We don’t need sophisticated testing equipment or methodologies; a great deal of the assumptions can be verified with simple tests.
• Once you have confirming test data for the model; persevere with the model. A common reason for project failure is giving up too soon.

In business, the reasons for wanting to make changes are usually related to profit and loss, distinguishing oneself from one's competition. For example, the perceived culprit may the paperwork associated with fulfilling an order. The solution provider is told, Get rid of those data entry clerks! Just have the users enter the orders and go from there. Let's become a paper-less business! However, is the paper management the real issue? Is it the only issue? What does paperless mean?

If we listen carefully, we can hear underlying problems:

• Employing data entry clerks costs money
• There's so much paper and it moves through so many departments that we loose the paper
• We have to generate and process the paper
• The information on the paper isn't legible

Why does the paperwork need to move through so many departments? Why is the information on the paper not legible? Without a clear model of how the business functions, we should not presume that paper management is the sole problem to be resolved.

In this case, blindly going forth and installing scanners, OCR systems, and workflow would be as foolish as taking antacids for continuing chest pain. Conversely, when the business model is correct, it will not only solve these problems, but it is likely to apply to other situations as well.

• Customer Service - Help Desks
• Real Time Data Analysis - Heating and Cooling systems
• Static Data Analysis - Credit Worthiness
• Design - Integrated Circuit
• Policy and Regulatory Interpretation - Who qualifies for benefits?
• Order Management - Purchasing just about anything
• Routing and Scheduling - Transporting a package from point A to point B

For example, in the transportation industry we can assume that a large number of the business issues we will deal with will have routing and scheduling components. What we may not think about are the customer service and order management issues that are also part of the core of a successful business. Improving a company's information infrastructure requires that we perceive all aspects of the business, not just what has been presented to us as the problem. We don't need to be a walking library of business models to build good business applications. Given a specific business activity, the objective is to recognize the general model and test it to validate that it will solve 80% of the problem. We must balance our intuition about the problem with an analytic approach and empirical test results.

In the past two years, the authors have taken informal surveys of a unique population in Silicon Valley, software developers. Most software developers are quite proud of the fact that they either do their banking through ATMs. We will go to great lengths to avoid going into a bank. That's fine for software developers, but what about the majority of the consumer banking population? Most people prefer to go into the bank, stand in line, and talk with a human teller.

The bank still wants to find ways to cut cost and distinguish itself from its competition. Technology is still perceived as the most effective way to make a difference in business processes. Whom does the bank rely on to provide technology-based solutions? Software developers. What do we already know about the headset of software developers with respect to technology? Not only are we predisposed to use it; we will make an extra effort to use it. We do not represent the general population.

It is incorrect to assume that based on gut feeling alone, software developers could design and implement a system that would appeal to non-ATM users. In this situation, the business has made a decision based on other factors to go ahead with ATMs. Consider what has developed since the ATMs Online home banking services.

To be fair, the personal computer is becoming increasingly common in the homes of middle class Americans. Nevertheless, who is most likely to have home computing equipment? Software developers or people in the information service industries. What about the majority of the consumer banking population?

A measure of success for a business solution is that it is adopted by a large percentage of the targeted community of their own accord.

In determining an appropriate business model from which to drive a solution, we need to consider the requirements, the trade-offs, and the time and money available. In our next discussion, we will address how the right business model yields 80% of the business requirements.

Consider the confusion and complexity of the following problem:

Our Help Desk needs help. We established it so we could track how many requests we were really getting - we were just consolidating all the little projects that various departments had started. Now, the Help Desk people want to attend the Help Desk Institute conference each year - the Help Desk has gone from being a project to being a department. The trouble is, we still don't know if we've made things any better for our customers.

- the Help Desk Manager's Manager

Companies put Help Desks in place when standard business processes break down. If things actually worked the way people think they should work, then people wouldn't need help. In fact, things often work in ways that were never planned for, and since the plan and the reality don't match, Help Desks spring up. We can easily imagine a situation in which employees (internal customers) can't get what they need or want, and frustrated corporate administration departments (providers) who are doing the best they can but are always perceived as being difficult to work with.

Now, let's set up a model of our innate understanding of the customer? How much do we know? Quite a lot, actually.

Still, in some cases, we will have to notify the provider that something is not right with what we have received. We expect that the provider will apologize, and make every effort to correct the situation as quickly as possible with no extra cost to us. If we are satisfied with the service, we are likely to be pleasant to work with, and we will tell our friends about how easy it was to get what we needed. If we aren't satisfied with the service, we might show our annoyance. Certainly, we will complain to our friends about the poor service.

Within the transportation industry, whether the business is expedited freight or trans-oceanic shipping, whether the goods travel by air, or on rubber wheels or steel wheels, consigned goods will all have business requirements focussed on the following data:

• who consigned the goods
• who the goods are to be delivered to and how quickly
• the commodity type
• the weight and volume
• the value of the goods
• whether or not the goods require special services such as refrigeration, and
• whether or not the goods are controlled or hazardous.

• Yield management - controls for profit margin
• Regulations on the transport of commodities
• Inter-state, inter-province, inter-national customs procedures
• What the competition is doing

It is unnecessary to do a six-month requirements collection exercise because we can identify a business model in less than a month. We can test the model in less than three months using simple substitution tests. The test of the business model is the implementation of the first end-to-end thread. Then, once we have run the first end-to-end thread, we have our first real set of reality-validated requirements. The reality may surprise our users. Hopefully, we won't be surprised

Let's look at an end-to-end thread. Then we will come back and discuss scenarios and the role of the architect.

Mountain View, California 94043-2715 
+ 1 650.965.9690