Excerpted with permission from Building Business Solutions:  Business Analysis with Business Rules (2nd Ed.), by Ronald G. Ross with Gladys S.W. Lam, Business Rule Solutions, LLC, 2015, 308 pp.  URL:.  http://www.brsolutions.com/bbs

Managing the creation and deployment of a business solution requires a project.  Project definitions (or charters) should never be confused, however, with architectures.  They are fundamentally different.  Many approaches stumble badly in this regard resulting in confusion, waste, and missed opportunities.

Let's suppose your company today has an inadequate business capability in some area, or none at all.  The business wants to address the problem.  The challenge you face as a business analyst is determining what the new business capability should look like.  That's the purpose of the business architecture.  The business architecture details the new or revised business capability in the form the business capability is to operate in the future.

Engineering Future Form

Engineering future form is an architectural issue.  It's the same kind of challenge you would personally face if you needed a new home.  Let's say your family is growing and you need more space with the right features for children and pets.  You also need more storage space and enough room to entertain a widening circle of friends.  What should the new or remodeled house look like?  How do you go about envisioning that future form?

You hire an architect.  Together you brainstorm the new family solution and she draws up a blueprint.  Then you hire a contractor to build to spec.

As a business analyst, you too need to be an architect, but for business capabilities instead of homes.  You too need to develop a business blueprint before the contractors (read 'software developers') are 'hired'.

Project vs. Architecture

Let's say today some business capability in your business is operating at point A.  In its future form, the business needs it to operate at point B.  The business architecture should describe the business capability in the new, improved form it is to operate at point B.

How will you get the company from point A to point B?  For that you need a project.  This project, however, is about managing transformation, not architecture per se.  Project definition and business architecture can and should be cleanly separated.

Architectural Scope

Following John Zachman, a ballpark view of architectural scope can be achieved by creating lists of business items.  There should be six scope lists based on the fundamental questions:  what, how, where, who, when, and why.  For each question, a particular kind of scope item is listed.

Each scope list should generally include from three to twelve scope items.  (7 +/- 2 is generally recommended.)  Let's say the average for each scope list is just over eight items.  Your ballpark architectural scope will consist of approximately 50 scope items (6 x 8, rounded up).

The actual number of scope items in each scope list is less important, however, than that the scope lists outline architectural scope as clearly and as completely as possible.  The scope lists should omit nothing needed for a business solution.

As illustrated by Figure 1, the six scope lists allow you to 'box' the business solution space and to roughly determine its size.  Job One is not to leave any of the six sides of the box open; otherwise the contents can and will spill out (read 'scope creep').

Figure 1.  Boxing the Business Solution Space

Initial scope lists can be extracted by business analysts from many sources:  business-case documentation, feasibility studies, problem statement, project description, sponsor(s), etc.  These initial scope lists should then be reviewed and approved by the business leads.

Summary

The first step in creating a business architecture is to take a quick survey of the target business capability.  Putting some stakes in the ground produces a first-cut or ballpark view of architectural scope.  This ballpark view provides a collective sense of which business items are in scope and which ones aren't. 

Establishing a well-grounded architectural scope early, purely in business terms and with participation of business leads, is essential in avoiding subsequent 'scope creep' during design and development of systems.  Is it really possible?  Yes, it's a proven fact.

For further information, please visit BRSolutions.com      

# # #