Business Architecture, Business Requirements, and System Design Building Business Capabilities

Ronald G.  Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal and Co-Chair, Building Business Capability (BBC) Read Author Bio       || Read All Articles by Ronald G. Ross
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:

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.

Table 1. The Six Basic Engineering Questions and
Related General Ability Statements (GAS)

Basic Engineering Question


General Ability Statements (GAS)



Ability to record data and use that data to guide system behavior by evaluating the then-current business rules.



Ability to execute processes and use those processes to create value-add according to the then-current business rules.



Ability to address geographical or spatial distribution, and organize transport, logistics, and business communications, all according to the then-current business rules.



Ability to interact with users and support those users in achieving desired behavior, as permitted and guided by the then-current business rules.



Ability to orchestrate business milestones and schedule execution of processes, all according to the then-current business rules.



Ability to demonstrate that business goals are being met, that business risks are being mitigated, and that the then-current business rules are achieving the desired business ends.

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.

Table 2. Vocabulary for Business Architecture vs. System Design

Basic Engineering Question

Business Architecture

Instead of …

System Design

We talk about …


business vocabulary
(concept model)

data model
and/or class diagram


business processes

system processes
(computationally viable
but platform-independent)


business geography

system nodes and links


business organization

use cases and GUIs


business events
(business milestones)

system events
and states


business strategy
(Policy Charter)


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      

# # #

Standard citation for this article:

citations icon
Ronald G. Ross, "Business Architecture, Business Requirements, and System Design Building Business Capabilities" Business Rules Journal, Vol. 17, No. 2, (Feb. 2016)

About our Contributor:

Ronald  G. Ross
Ronald G. Ross Co-Founder & Principal, Business Rule Solutions, LLC , Executive Editor, Business Rules Journal and Co-Chair, Building Business Capability (BBC)

Ronald G. Ross is Principal and Co-Founder of Business Rule Solutions, LLC, where he actively develops and applies the BRS Methodology including RuleSpeak®, DecisionSpeak and TableSpeak.

Ron is recognized internationally as the "father of business rules." He is the author of ten professional books including the groundbreaking first book on business rules The Business Rule Book in 1994. His newest are:

Ron serves as Executive Editor of and its flagship publication, Business Rules Journal. He is a sought-after speaker at conferences world-wide. More than 50,000 people have heard him speak; many more have attended his seminars and read his books.

Ron has served as Chair of the annual International Business Rules & Decisions Forum conference since 1997, now part of the Building Business Capability (BBC) conference where he serves as Co-Chair. He was a charter member of the Business Rules Group (BRG) in the 1980s, and an editor of its Business Motivation Model (BMM) standard and the Business Rules Manifesto. He is active in OMG standards development, with core involvement in SBVR.

Ron holds a BA from Rice University and an MS in information science from Illinois Institute of Technology. Find Ron's blog on For more information about Ron visit Tweets: @Ronald_G_Ross

Read All Articles by Ronald G. Ross

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.