Part 3   Defining the Business Problem, or,
What's an Architect Good For?


I n t r o d u c t i o n

  • The purpose of this discussion is to expose two common problems in software development: Defining the problem in terms of the solution, and, not understanding the role of the system architect.

    Once a business has determined that they (the customer) want to solve a particular problem, and they have identified a solution provider, the customer has to describe the problem. It is human nature for the customer to express requirements as solutions. It is the responsibility of the solution provider to educate the customer about the true nature of problem, and about the ramifications of the solution space. Often the availability of technology obscures the true problem.

    In the example below, we describe three types of interactions between characters. A solution team typically consists of people who can serve the roles of architects, designers. analysts, and programmers. We have simplified the solution team by making the architect an amalgam of the four roles. Let's revisit the Pennies cases.


    C A S E   1 

  • Only the obvious attributes of the situation are examined, and, the problem data is accepted without asking any questions. Ralph must be a bit dim-witted to not be curious about why Shoko has $100,000 tucked away in pennies. Ralph presumes that he has to provide the solution all by himself. When he realizes the job is a lot more than he expected he has one recourse, "no bid".

    As an architect, Ralph is in the dark (uninformed).


    C A S E   2 

  • When Kuan-Yin begins to examine what it would take, she initially goes down the same uninformed path as Ralph. However, at least she addresses issues of scale to achieve an acceptable level of value.

    With some reflection, Kuan-Yin sees a better solution, but she is still locked into Shoko's solution-oriented definition of the problem. A sack of hundred dollar bills stuffed in a mattress isn't a good solution.

    As an architect, Kuan-Yin is not doing much conceptual block-busting.


    C A S E   3 

  • Jamie considers the nature of request:

    How much will you charge me to go pick up the money from San Jose and bring it back to my new home in San Francisco, and it's in pennies, and ... the key to the back door, and ... the dogs.

    Asking a few questions results in a less colorful but still unstructured statement of the problem:

    Get the $100,000 in pennies from San Jose to a bank and provide me with a means to draw on the funds so I don't have to pay for groceries with a shopping cart full of pennies.

    Here's an even more structured version of the problem:

    Client has $100,000 that is not accessible, not in a form that is easy to store safely, and not convenient for commerce. Make it accessible to her from a secure location so that she can conduct financial transactions via standard means.

    With a structured definition of the problem, she can go about it in a completely different way. Here are the issues she knows she must deal with:

    Issue 1. That a shipment of many pennies weighs tons. She needs a transportation resource that can handle the job.

    Issue 2. Counting that many pennies is going to be a big job for any coin processing service provider. She needs a coin processing resource that can handle the job, and it may not necessarily be a consumer bank.

    Issue 3. Once the pennies are counted, then the amount must be converted to a monetary form that can be stored safely and easily accessed.

    Issue 4. The dogs need to be kept safe during the transfer of the payload.

    Issue 5. Shoko needs a way to manage the large sum of money.


    S U M M A R Y

  • Now both the tactical and the strategic attributes of situation have been addressed, not just the surface attributes. Jamie has investigated a possible solution from an informed perspective. However, what does this have to do with business models and business requirements? Thus far, we have only seen two leverage points, the business model itself, and the expertise of the architect. Now it's time to look at the third leverage point, scenarios.

    Back to Balsamfir Home Page
     

    Mountain View, California 94043-2715 
    email: cecilie.hoffman at comcast.net 

     


    Copyright © 1997 Cecilie Hoffman
    Updated October 15, 2005