Professionals should always focus on business solutions first, then and only then on designing systems. Not just lip service, I mean applying the power techniques of true business architecture.[1] Three of those techniques are discussed briefly below.

Structured Business Strategy

True business solutions of any size or description hinge on strategy. Not project or IT strategy — not business case or project objectives — but real business strategy. Are you sure you really know the difference? Time and time again I find that many business analysts don’t. Here are two quick tests.

Test 1.

Are you aware of the standard The Business Motivation Model (BMM).[2] Have you actually read it?

If not, I’d say the issue is at doubt. Real strategy is about ends and means, not about change or how you plan, design, or engineer such change. Change is inevitably involved of course — but that’s what projects and project plans are about.

Test 2.

Which of the following is closest to your thinking about alignment?

  • IT needs to be aligned with the business.
  • Business capabilities need to be aligned with business strategy.

If you instinctively went with the former, I’d say the issue again is at doubt.

Business Processes and Business Rules

True business solutions require architecting both the following:

  • What is done to create value-add (business processes)
  • What ensures value-add is created correctly (business rules)

Many professionals are unclear about the respective roles of business processes vs. business rules. At the risk of stating the obvious, let me make the following clarifications.

  1. Business processes and business rules are different. They serve very different purposes. A business process is about doing the right things; business rules are about doing things right.
  2. There is no conflict whatsoever between business rules and business processes. In fact, they are highly complementary. Each makes the other better.
  3. You need both. Neither can substitute for the other.

Structured Business Vocabulary and Concept Models

The value-add that companies produce today is based on rich operational business knowledge. No business solution can prove truly effective if business people (and the tools they use) are unable to communicate about that knowledge clearly. Who profits from operating in a Tower of Babel?

A concept model[3] is about identifying the correct choice of terms to use in business communications (including statements of business rules), especially where subtle distinctions need to be made. A concept model starts with a glossary of business terms and definitions. It puts a premium on high-quality, design-independent definitions, free of data or implementation biases. It also gives structure to business vocabulary.

Essential for any true architecture is stability over time. Are the core concepts of an operational business stable over time? Yes.[4] Did you know that?!

Next Article: The Big Picture – Part 4 of 4

In the fourth and final part of this four-part series, Ron talks about what’s really needed to move your organization to a new level of business capability.


[1] Refer to the newly-published second edition of Building Business Solutions: Business Analysis with Business Rules, an IIBA Sponsored Handbook, by Ronald G. Ross with Gladys S.W. Lam, 2015.

[2] Free at

[3] The standard for concept models is the OMG’s Semantics of Business Vocabulary and Business Rules (SBVR). Refer to the SBVR Insider section of

[4] Ronald G. Ross, “How Long Will Your Fact Model Last? The Power of Structured Business Vocabularies,” Business Rules Journal, Vol. 12, No. 5 (May 2011).