Much has been said about the importance of business alignment.  I daresay no one would argue much against it.  It's like motherhood and apple pie.  But for all the hand-waving, real questions remain.  What are you aligning?  How do you align?

Discussions of business alignment generally center on aligning IT with the business.  But shouldn't that be a given?!  Methodologists recommend having lots of touch points in your IT development approach and creating and maintaining good interpersonal relationships.  But does that ensure good business practices — or just good GUIs?  And why just IT?  Aren't there other kinds of projects in the business?

I think it's time we put aside the tired notion of IT alignment.  In its place, we should focus on engineering real business solutions to real business problems based on deliberately structured business strategy.  Our approach should work exactly the same whether the business solution involves comprehensive automation, just partial automation — or none at all.  We should be aligning business solutions with business strategy, not simply IT with the business.

In short, if you want your business and IT architectures both to become smarter (and who doesn't these days?!), your approach to solution engineering should become strategy-driven.  What does that mean in practice?  Here's what it means to me.

Timeframes and Scope

Before explaining further, we need to consider timeframes and scope and some misconceptions about them.  When you hear "strategy" or "strategic", there's a natural tendency to think longer term, rather than shorter term.  And to think more broadly (e.g., some entire line of business or the enterprise as a whole), rather than more locally (e.g., some particular business process or business capacity^[1]).  Hence, what is "strategic" is generally differentiated from what is "tactical" and "operational".

It does not follow, however, that strategy is irrelevant at shorter timeframes or more narrow scopes.  Indeed, becoming strategy-driven requires coordinated engineering of business solutions at each level of timeframe and scope.  It makes no more sense to have strategy and not align activities with shorter timeframes or more narrow scope with that strategy, than to operate minute-to-minute and month-to-month with no strategy at all.

Let's take a closer look.  Table 1 outlines each of the three focal points of a strategy-driven approach.^[2]

Table 1.  The Three Focal Points of a Strategy-Driven Approach

Several points stand out from this analysis.

• First, a well-thought out strategy — or more accurately, strategies — are appropriate at each of the first two levels, not just the first.  Indeed, in terms of the work that most business analysts do, developing strategies at the second level (for business capacities) is probably more directly relevant than the first.^[3]  By the way, contrary to what you might think, developing a Business Capacity Strategy does not take a lot of time — if you have the right approach^[4] and the right people in the room.
  
  
• Second, alignment should occur (must occur) for the second level with respect to the first, and the third level with respect to the second.  However, the kind of alignment in these two cases is naturally different.
  
  
• Third, the kind of alignment appropriate for the third level involves the performance of operational decisioning, not the performance of business processes per se.  There is widespread confusion on this point.  When many experts talk about the performance of business processes they may or may not also mean the performance of operational decisioning with respect to business goals, risks, and policies (i.e., strategy).  Even when they do also mean that, unfortunately they seldom say it very clearly.

Structured Strategy

To clear up this confusion, let's examine the notion of strategy more carefully.  Is a strategy something you can see and touch?  Does it have form and texture?  You may have noticed earlier that I used the words deliberately structured in conjunction with strategy.  Can a strategy really have deliberate structure?

Absolutely!  In fact, there is even a standard now for it.^[5]   Strategy is definitely something you can model.

By the way, a model of a strategy looks nothing whatsoever like a model of a process.  The latter focuses on transforms (tasks) and inputs and outputs.  The former focuses on ends and means — that is on goals and objectives, and tactics and business policies, respectively.  It also focuses on how you arrived at those particular ends and means in the first place^[6] — in particular, risks.  These are not the kinds of things you should see in a process model.

Lest there be any doubt in your mind, becoming strategy-driven in no way diminishes the importance of business process models.  Nothing gets done in a company (or at least done very well) without well-organized processes.  Of course they should be modeled!  Processes produce the actual value add and puts it into the hands of customers.

But processes alone simply aren't enough.  With processes you can streamline workflow, but not respond intelligently to emerging risks and opportunities.  You can measure throughput and identify bottlenecks, but not assess whether your business policies are actually effective in achieving the results management wants.  You can standardize work for large numbers of people doing repetitive work, but not fine-tune the results of minute-to-minute decision-making.

What business process models lack is a direct connection to a key ingredient in any business strategy — business policies.  What are business policies?  Think about them as business rules in the making.  Business policies usually require additional clarification (read 'disambiguation') before they become fully practicable.^[7]

More importantly for this discussion, business policies provide criteria for making optimal decisions during actual minute-to-minute business operations, often in highly risky or sensitive matters.  The point is that becoming strategy-driven ties directly to enterprise decision management (EDM).  As Raden and Taylor say in their ground-breaking book Smart Enough Systems,^[8]  "All [operational business] decisions must be driven by your strategy if you are to deliver effectively on that strategy."

Measurement

How do you demonstrate business alignment?   Like many, I believe it's something you must be able to measure.  In other words, to prove you have business alignment you must measure the business performance of actual business operations.

In recent years, much discussion in this regard has centered on business activity modeling (BAM).  Frankly I find much of this discussion clouded by a narrow focus on business processes.  Measuring the effectiveness of business processes is simply not the same thing as measuring the effectiveness of a strategy.

Where can we look for greater clarity?  Roger Burlton has famously said, "The really rapid change is in the rules, not in the processes.  If you separate the rules, you can develop remarkably stable processes."

I think that hits the nail on the head.  With business processes, the focus is on the stability of how you operate; in strategy the focus is on rapid response and the capacity (or necessity) to evolve (read "change") your decisions as quickly as possible.  With strategy you need to measure the dynamic aspects of operational business activity.  These are very different animals.  Appropriate separation of concerns is presented in Table 2.

Table 2.  Process-Driven vs. Strategy-Driven Measures of Business Performance

The bottom-line is this.  To achieve business alignment you must become strategy-driven.  To be strategy-driven you must be able to respond dynamically and effectively to change.  To respond dynamically and effectively to change you need business rules and enterprise decision management (EDM).  It's really as simple as 1-2-3.

References

[1]  Business capacity is a term that Business Rule Solutions (BRS) uses to refer to some area of business capabilities that represents substantially less than the whole enterprise, but still encompasses significant business activity.  A business capacity often, but not always, corresponds to a complete business process.  In other cases, it might pertain to a complex set of operational decisions the company must perform on a continual basis.  

[2]  BRS's methodology, Proteus, identifies an additional area of strategy concern pertaining more directly to automation.  This additional area arises in developing IT requirements as follows.  The strategy developed for engineering a business solution for a business capacity (i.e., a Business Capacity Strategy) is an initial step in developing a more complete business model with business people and business analysts.  Assuming significant automation, the key elements of this business model must be analyzed to determine what implications they hold for system development.  The distillation of these implications into a structured form embodies a System Solution Strategy, which is used to kick-off more traditional IT requirements development.  

[3]  The seminal piece on using strategy as part of business modeling for re-engineering business processes and business capacities was written in 1998 by Gladys S.W. Lam, Co-Founder and Principal of BRS.  Refer to "Business Knowledge -- Packaged in a Policy Charter," DataToKnowledge Newsletter, Vol. 26, No. 3 (May/June 1998), URL: http://www.BRCommunity.com/a1998/a385.html.  Deliberately-structured strategy that is truly business-oriented rather than project-oriented is notoriously missing in most IT methodologies still today.  

[4]  The focus must be on envisioning the day-to-day 'to-be' business and the risks associated with its on-going operation.  It has nothing to do with project strategy, business case, cost-benefit analysis, etc.  

[5]  The Object Management Group (OMG) released a finalized version of the standard in September, 2007.  The standard was originally produced by the Business Rules Group (BRG) as "The Business Motivation Model:  Business Governance in a Volatile World" and is available free on www.BusinessRulesGroup.org.  For the OMG's UML version, see: http://www.omg.org/technology/documents/br_pm_spec_catalog.htm.  

[6]  In the Business Motivation Model, these are called Assessments.  

[7]  Practicable is an SBVR term.  The test for whether a rule is practicable is this:  Given a rule and a business situation where the rule applies, could a person (worker) who knows about the rule and who understands the associated vocabulary (important!) decide directly whether or not the business was in compliance?  

[8]  Smart (Enough) Systems, by James Taylor & Neil Raden, Prentice-Hall, 2007, p. 12.  

# # #