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?
It’s time we move beyond simple “business alignment.” In its place, we should focus on engineering real business solutions to real business problems based on deliberately structured strategy. The 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.
Principle #1. Align 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 our1 definition:
Strategy-driven: having a consistent ability in any set of circumstances to make a timely decision that, given all that you then know, is most likely to be optimal for the organization as a whole
TIME FRAMES AND SCOPE
Before explaining further, we need to consider time frames 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 capability2). Hence, what is “strategic” is generally differentiated from what is “tactical” and “operational.”
It does not follow, however, that strategy is irrelevant at shorter time frames or more narrow scopes. Indeed, becoming strategy-driven requires coordinated engineering of business solutions at each level of time frame and scope.
Principle #2. Strategy applies at each level of time frame and scope.
Let’s take a closer look. Table 1 outlines a strategy-driven approach.
Several points stand out from this analysis.
- 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 capabilities) is probably more directly relevant than the first3. By the way, contrary to what you might think, developing a Business Capability Strategy does not take a lot of time—if you have the right approach4 and the right people in the room.
- Alignment should occur (must occur) for the second level with respect to the first, and for the third level with respect to the second.
- The kind of alignment appropriate for the third level involves the performance of operational business decisions, not the performance of business processes per se.
There is widespread confusion on the last point. When many experts talk about the performance of business processes, they may or may not also mean the performance of operational business decisions 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.
Principle #3. To align at the operational level, look at the performance of operational business decisions, not of business processes per se.
STRUCTURED STRATEGY
To clear up the 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 a standard for it5. Strategy is definitely something you can model explicitly and succinctly.
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 place6—in particular, risks. These are not the kinds of things you should see in a process model.
Principle #4. Strategy has structure.
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. 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-making7. Business policies usually require additional clarification (read “disambiguation”) before they become fully practicable8.
More importantly for this discussion, business policies provide criteria for making optimal operational business 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 decision management9. As Neil Raden and James Taylor said in their 2007 book Smart Enough Systems10, “All [operational business] decisions must be driven by your strategy if you are to deliver effectively on that strategy.”
Principle #5. Becoming strategy-driven requires business rules and decision management.
MEASUREMENT
How do you demonstrate business alignment? You must be able to measure it. In other words, to prove you have business alignment you must measure the business performance of actual business operations.
In the past, much discussion in this regard centered on business activity modeling (BAM). Frankly, I found much of that 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.
Principle #6. Strategy-driven measures of business performance are about the capacity to change.
The bottom-line is this. To achieve business alignment, you must become strategy-driven. To be strategy-driven, you must be able respond dynamically and effectively to change. To respond dynamically and effectively to change, you need business rules and decision management. It’s really as simple as 1-2-3.
Footnotes
1. Business Rule Solutions, LLC (BRS), www.BRSolutions.com
2. Business capability is a term BRS uses to refer to an area that represents substantially less than the whole enterprise, but still encompasses significant business activity. A business capability often, but not always, corresponds to a complete business process. In other cases, it might pertain to a complex set of operational business decisions the company must perform on a continual basis.
3. The seminal piece on using strategy as part of business modeling for re-engineering business processes and business capabilities was written in 1998 by Gladys S.W. Lam, co-founder and principal of BRS. Refer to “Business Knowledge—Packaged in a Policy Charter,” available on www.BRCommunity.com, 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 ongoing operation. It has nothing to do with project strategy, business case, cost-benefit analysis, etc. Refer to chapters 1, 2, and 4 of Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA® Sponsored Handbook, Business Rule Solutions, LLC, 2011, 304 pp, http://www.brsolutions.com/bbs
5. “The Business Motivation Model: Business Governance in a Volatile World” by Business Rules Group (BRG), available free on www.BusinessRulesGroup.org. Also an OMG standard. 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. Refer to Business Rule Concepts: Getting to the Point of Knowledge, (4th edition), by Ronald G. Ross, April 2013 www.brsolutions.com/publications.php
8. Practicable is a notion from the OMG standard SBVR. 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. For more about SBVR, see the SBVR Insider section on www.BRCommunity.com.
9. For techniques to support decision management, see http://www.brsolutions.com/b_ipspeakprimers.php
10. Smart (Enough) Systems, by James Taylor & Neil Raden, PrenticeHall, 2007, p. 12.
