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, October 2015, 308 pp.  URL:.  http://www.brsolutions.com/bbs

Business architectures need not be enterprise-wide.  Analysis and design of a business capability needs a business architecture too.

The blueprinting techniques used for business architecture should apply exactly the same, no matter how wide the scope — project, business process, whole business, whole supply chain, etc.  Only the level of detail might be different.

We define a business architecture as a:

structural representation of a business solution as it relates to creating business value and achieving business goals

A business architecture is a blueprint for a business capability based directly on real-world things and ideas.  It enables business people and business analysts to engage in discussion using business language about what needs to be created, managed, operated, transformed, and discontinued in the business.

A business architecture for a business capability comprises component models.  Examples include:

• strategy for the business solution (e.g., Policy Charter),
  
  
• business process models,
  
  
• structured business vocabulary (concept model),
  
  
• business milestone models,
  
  
• decision models (e.g., Q-Charts),
  
  
• etc.

A business architecture and each of its component models are always subject to the business rules specified for it.

Developing a business solution using a business architecture does not necessarily imply software development, but if software development does ensue (as it usually does) the business architecture provides a solid grounding.

System Design

For many years John Zachman has explained that a business model (row two) is always about real-world things.  These real-world things are as the business leads see or define them.

A system model (row three) in contrast comprises "… surrogates for the real-world things so that the real-world things can be managed on a scale and at a distance that is not possible in the real world."  Surrogates include:

• data entities in place of real-world things,
  
  
• GUIs and use cases in place of face-to-face, real-world communication,
  
  
• network nodes in place of real-world locations,
  
  
• system events rather than operational business events,
  
  
• etc.

We define a system design as a:

design for an automatable system that is computationally competent

A business architecture must be transformed into a system design — there is no slippery slope.

Business Requirements

The business architecture you create to express a business solution can be evaluated to produce many business requirements.  These business requirements form the basis for designing a well-aligned system, one that best handles business rules.

The key word in understanding business requirements is interpretation.  You interpret the business architecture to identify key features for a system design.  Work on developing business requirements should not commence until the business architecture is complete.

Merriam-Webster Unabridged Dictionary [MWUD] defines requirement as something called for or demanded.  We therefore define a business requirement as:

something called for or demanded by a business architecture that business operations or a system design must support

We always use the term business requirement to mean business requirement for a system design.  We don't mean requirements for doing business.  Be sure to clarify this point with business leads should any confusion arise.

In our approach a business requirement is expressed in the form of an ability statement.  An ability statement identifies how some aspect(s) of the business architecture should be supported within the yet-to-be-designed system.  In general, an ability statement serves as a first-cut interpretation of some selected business architecture item(s) into appropriate system features.

Ability statements are more or less equivalent to functional requirements except that ability statements are always interpreted from a business architecture.

Working directly from the business architecture to identify system features dramatically reduces not only the number of design choices that designers must make, but the time required to make the remaining choices as well.  Asking the right questions in the right ways of the right people at the right times doesn't slow you down; it speeds you up!

Ability statements apply only to the automatable parts of the business architecture.  Non-automatable portions (including any business rules) must be assessed and allocated as job responsibilities and non-automated procedures.

What Business Requirements Should Cover

Following Zachman, a complete system design should address the six areas (basic engineering questions) in Table 1.  Table 1 also presents six general ability statements (GAS), which serve as guiding principles for developing business requirements.

In addition, a system design should address integration relationships.  In business analysis with business rules, integration relationships for the business architecture have been captured and expressed as business rules.

Note the all-important modifier the then current before 'business rules' in the description for each of the six general ability statements in Table 2.  A key goal in business analysis with business rules is support for continuous change to business rules, the key to business agility.

The vocabulary of system design naturally diverges from the vocabulary of business architecture, as indicated at a high level in Table 2.

We also start talking about system rules rather than business rules.  A system rule is a:

rule that is dependent on, or aimed at, the manner in which data is received, stored, or displayed in a system design

Always remember that the representation of something in a system design is not the same as the something in the real world.  For example, what you know about an employee represented as data is not the same as the flesh-and-blood person in the real world.  Don't confuse business people or IT professionals — or yourself — by failing to make this important distinction.

When Are Business Requirements 'Done'?

Your work on business requirements is done when ability statements have addressed all parts of the business architecture to be automated.  The level of detail for different sets of ability statements, however, can vary.  Much depends on good lines of communication among business leads, business analysts, and IT staff.  Familiarity of the IT staff with business rules can also make a big difference.

We think of ability statements as a contract between business analysts and system designers.  In writing contracts you generally hope for the best, but prepare for the worst.

Worst case.  Communication between business analysts and system designers is tenuous.  Poor communication frequently results from geographical separation, language barriers, or business disconnects (e.g., as often is the case in outsourcing).  It can also result from IT developers not being given clear direction (or decent requirements).  Not infrequently the business leads themselves seem to want the IT staff to do their business thinking for them.  (So the IT staff does, in code.)  Sometimes everybody just seems to want a miracle to happen — a perfect running system before the business problem is fully understood and a business solution worked out.  To top it all off is the issue of learning curves.

Best case.  Communication between business analysts and system designers is excellent.  Both are dedicated to achieving the best results for the business.  Effective project management is in place.  There's no significant learning curve.  Ample patience and trust is evident on all sides.

Your case.  You know your circumstances best.  In the worst case, your ability statements may need to cross every 't' and dot every 'i'.  In the best case, you can probably just let much of the business architecture and many or all of the business rules 'speak for themselves'.  You need to determine the best answer in your own situation.

For further information, please visit BRSolutions.com      

# # #