In December 2006 my colleagues and I at the IBM Executive Business Institute began development on a new program titled Aligning IT & Business Strategies. This program is intended to provide vital contemporary management thinking for CIOs The title --- and associated “governing principle” for the program was selected simply because “alignment of strategies” has continuously been shown in studies and surveys for over a decade to be the first (usually!) or second (occasionally) issue of concern to CIOs. This new program will incorporate important thinking on Component Business Modeling and Service Oriented Architecture --- two subjects on which there is virtually no management-level education emerging yet. Thus, we plan to be on the leading edge of meeting this need.
We decided, given the program title we selected, to “dust off” a strategic framework that had been one of our institute’s favorites for over a decade: the Business-IT strategic alignment model. This tool was originally developed around 1990 by Dr. John Henderson of Boston University Graduate School of Management and has been widely and successfully used by our institute, in several courses for about a decade and a half. John and his colleague N. Venkatramon published IBM's first article on this model in the IBM Systems Journal in 1993.
Our team substantially updated the terminology used in this model, to make it applicable to the CBM/SOA world. When we finished, the model appeared thus:
As with most such frameworks, it’s helpful to first see it all together, this in order to get the big picture of all the elements and how they relate to one another (NOTE: The image to the left is a "thumbnail" --- click on it to see the full size model). The four boxes are called ‘domains’. I know the print didn't translate clearly into this jpg format --- the domain names, clockwise from opper left, are "Business Strategy and Business Model," "Strategy & Business of IT," "IT Organization & Structure," and "Business Organization." Dividing the model horizontally you see two “domains” of strategy and two of structure. Divide it vertically and you see two “domains” of business and two of IT. These are the business issues we concern ourselves with through this model. Second, you also see that each domain has three “elements” which are the fundamental building blocks of each strategy and structure. There is a set of relationships depicted by the eight arrows (i.e., four bi-directional arrows). These relationship arrows depict the various aspects of the business-IT alignment process.
We start by proposing that every business starts with the process depicted on the left side. You first develop a strategy. Strategy is all about making the high level choices about the nature of your business and how you will go about doing it. Next, you have to make the investments required to actually do that business --- make it executable. That activity is building the business structure. But we really need to look at the fundamental elements of both of these “domains.” First, strategy . . . .
As you see we propose that you can summarize business strategy and business structure, each, into 3 elements. Even though your business strategy may be a lengthy document filling a whole 3 ring binder, we would bet that just about anything in it can be categorized into one of the elements shown here. And we also propose to you that the same is true of your business structure. We’ll come back to that. Also important is that relationship arrow. Traditionally, professors of strategy have taught that “structure follows strategy” (just as an architect says “form follows function”), but today we recognize that the relationship is not so neatly “one way.” Maybe it never was! So, if you’re thinking that it can go both ways, you’re right, and we’re showing it this way. We call the relationship depicted by this bi-directional arrow “strategic fit.” First of all, let’s take a detailed look at the business strategy domain . . .
It’s about “What business are we in?” The answer to that is a collection of items that, taken together, fall under the title “Scope.” First are your products and services. You may wish to separate products from services, or simply consider that a service is a product --- it doesn’t matter. What’s important is you provide some value that somebody wants to buy. Next: “who’s your customer?” You think that’s easy to answer? Not always. We’re surrounded by everyday evidence that plenty of businesses struggle with this. Examples: 1. Pharmaceuticals. Traditionally this industry considered the physician their customer, but now we see TV and magazine advertising for prescription drugs directed at the consumer. 2. Pet food (which was the traditional business school example for years). Does your dog go shopping and select his own food? Next: geography. This one in particular gets complicated in this era of e-commerce, because if you’re doing business on the net, you are likely to find that you have de facto become a global business without having intended, or even having wanted, to do so. Such a discovery will have significant implications for how you define the geography of your business, and who your customers are.
Strategic competencies are organizational capabilities that you select to give you competitive advantage, or to create preference in the marketplace for your business and its offerings. Attention to these competencies didn’t start with the information age, but IT has opened the doors to countless examples of them. Financial service institutions offer an array of value-added services to both consumer and business customers, sometimes as direct revenue generators, but other times at small profit margins --- because such services are known to have the effect of “locking in” the customer, i.e., making it costly or otherwise unattractive to switch providers. You see a similar effect with telecommunications offerings. Sometimes, if you’re in a “commodity” business, there is a desirable competency to be “low cost producer,” i.e., compete on price. In choosing your strategic competencies always keep in mind the importance of innovation. Strategic competencies are to create competitive advantage; and today innovation is a vital element of competitive advantage.
Alliances are external relationships, sometimes called partnerships. We propose that you won’t find a business anywhere today --- at least not in the for-profit sector --- that operates standalone and owns all its own processes. You used to see many (IBM example: more than 30 years ago every piece of hardware, worldwide, carrying the IBM logo was produced in an IBM plant. Today the figure is no more than 30%, and is declining!). Your decisions about this element go hand in hand with your decisions about competencies. Once you decide on your strategic competencies, you next determine which make sense for you to own in house, and which you want to “partner” for. Yes, today we will partner for strategic competencies --- something that was unthinkable previously!
Structure is easy to describe: it’s your org chart --- “who owns what.” The hierarchical, “command and control” structures we knew have been replaced in many organizations by flatter, and often matrixed, structures. Such structures have more complex information and communication needs; and information technology has both facilitated this restructuring, and evolved to meet the needs of these new organizational forms.” Also, remember to keep your alliances in mind, and include in your structure the linkages to your strategic partners.
Business processes are the structures of workflows and information flows --- and your process descriptions must include outsourced processes. Your don't limit yourself here to processes that are “strategic.” You have lots of processes that aren’t. How do you decide what is a “strategic process” and what isn’t? A good --- maybe not exhaustive, but good --- criterion is: if it’s directly involved with designing, producing, or selling a product, or providing a service to a customer, or executing a linkage to a supplier, it’s strategic. Along with the new structures we just commented on, our business processes have evolved --- not only becoming cross-functional but also responding to the need for seamless passing of information both internally and externally. Businesses have been evolving into a meshed organization with the need to have end-to-end business process workflow, monitoring and management for the entire enterprise.
Skills are human resources --- the executors of your processes, both strategic and non-. Here too you need to define the skills you require whether you “own” them in house or partner for them. This reference is to business skills, not IT --- those will come on the other side of the model. For example: we recommend focusing on the skills involved in delivering your core business, i.e., product design and build, service delivery, customer service, and sales.
The IT side of the model is strongly analogous to the business side (the characteristic that enables the model to be so effective as a tool for studying alignment) --- Scope, competencies, and alliances appear in both strategies. Down in the structure domain, architecture is to IT what structure and responsibilities (your org chart) is to the business. And both sides have processes; and both sides have skills. Another proposal, and a very important one, we’re making to you at this time is: the elements we’re defining for IT strategy are different from what you may have thought of as the building blocks of an IT strategy. You don’t see in our IT strategy any mention of network topologies, or server acquisition plans --- or any of the technical stuff that you may have traditionally thought would go into an IT strategy. Instead, it looks like a business strategy --- which should not be surprising. Look at the title of the domain “Strategy and Business of IT.” The operative word here is “business.” That said, it should look like business strategy. Now that we’re looking at the entire IT side of the model for the first time, let’s decompose it as we previously did the business side . . .
Remember the question “What business are we in?” The answer to that question was business scope. Now think of “the most fundamental question the CIO can ask.” It’s “What business is IT in?” The answer is IT scope -- the strategic technologies the organization invests in, the technologies that support and enable the elements of business strategy. A frequently seen example today is a technology that enables a strategic competency that is core to execution of the business. This means it’s revenue-generating, or customer-touching, or in general connected with delivery of the core products or services of the business.
Now that you’ve defined your strategic technologies you next address the critical capabilities of those technologies. As we did on the business side, we call these “competencies.” The visual suggests a couple of examples, i.e., availability, flexibility. Regarding availability, 24/7 availability needs to be taken for granted today. Other examples of IT competencies are connectivity, information accessibility. To achieve these competencies the IT strategy should address IT customer relationship management, IT business management, risk and compliance, and the development, deployment and support of IT services.
When you see “IT Alliances” often the first thing that comes to your mind is “outsourcing;” and indeed this is a very good example of an IT Alliance. Over a couple of decades IT outsourcing has progressed from a way for an organization to transfer non-core capital assets off the books, to an important partnership relationship. Especially in light of the fact that business process outsourcing of non-core applications is a trend today. You can view almost any IT service ---- e.g., SaaS --- as a way to engage with the application provider, as an IT alliance. But you have to do more than “view” it as such, you have to manage it as a true partnership. This implies a variety of things, the most important of which is that you and your partner treat your relationship as a relationship of (if we may coin another term) “Strategic equals.” This means the relationship is strategic to both of you!
Dropping down to the next domain, “IT organization & structure” which addresses how to execute the IT strategy. The first element to consider is IT architecture. This element is analogous to “structure & responsibilities” over on the business side --- and indeed you can think of your IT architecture as an org chart (of sorts) for IT. Your architecture is the physical realization of the choices you made in IT strategy, when you defined IT scope and IT competencies. For example, say your IT scope included a choice to invest in a flexible service-oriented architecture which uses a shared infrastructure and shared application components or an ERP system. When designing IT architecture you decide how to implement the business application or ERP system: selecting a vendor (SAP, Oracle, or whatever) and determining whether to go “single vendor” or “best of breed”.
“IT Services & processes” are essentially what the title implies: application development, systems management (which itself contains a variety of sub-elements such as SLAs, Data security, etc.) For example: risk management may include the plans and policies addressing security, continuous business operations, compliance and business resilience. Information management services and process may include the information architecture, knowledge resource management as well as data and content management policies and decisions. Systems management disciplines are implemented as IT services and processes supported by the IT organization and structure.
IT Skills are the human resources of IT. Remember that not all these skills are “owned” by your organization --- some, perhaps a lot, of your IT skill needs may be met by partnering. New skills in IT include “being more business savvy.” The products and services available today allow for better business dialog with the business executives. There are new evolving curricula called “services science” in the universities today addressing this need of business acumen for IT.
We’ll provide a journal of our activities. In this post we haven’t even scratched the surface of using this model as a management tool --- that will come in future posts.
To discuss these matters we invite you to use this blog; or contact one of our team, who are:
Celeste Gonzalez
Steve Roehm
Me (Tom Curtin)
