Strategic Use of IT

An instrument for assessing your alignment

Early in the use of the strategic alignment model, an executive organizational assessment survey was developed for use with it.  The first version of this instrument was authored by Professor (now Dean!)  James Thomas of the Smeal School of Business of Penn State university. This assessment asks respondents to rate the relative degree of definition, clarity, and understanding by their organization of the elements that make up the model. 

To refresh you --- or if you haven’t read the earlier post on this blog that described the elements and structure --- the four boxes in this model depict the four domains of strategic choice.  (See the graphic at left.  This and the other graphics shown on the blog are “thumbnails,” and you should click on the graphic to see a full-size graphic) 

Any strategy decision involves decisions in one or more domains.  At any point in time, one domain drives, enables, or otherwise impacts activities in one or more of the others.  When you take the assessment the results are analyzed by first looking at the strongest and weakest domains as self-rated by you, the respondent. The domain you view as the strongest is typically the one in which you have the most understanding of decisions made.  It is also probably the domain you see driving decisions in other domains.  Your weakest domain is typically the one in which you have the least understanding of decisions made. 

For example, a CEO may readily identify "business strategy" as the strongest domain and the same CEO may identify "IT structure" --- or perhaps "IT strategy" --- as his/her weakest.  An IT executive, particularly one with a technical background, is likely to have the exact opposite views of strength and weakness.  This knowledge is valuable when translated into an action plan by those two executives to improve communication with each other and increase understanding of each other's role and contribution.

Just as valuable as recognizing strength and weakness within a domain is recognizing them in the relationships among the domains --- particularly understanding the effects of decisions in one domain upon the others.  Let's say that an organization adopts a revolutionary change in structure, going from a traditional functional-hierarchical model to a flat, or matrix, or line-of-business model.  This organization's IT executive responds by architecting an IT structure appropriate to the new organization.  That IT executive's success --- indeed, survival --- hinges on understanding the effect of this organizational structure decision on I/T structure.

Getting real value from the alignment model lies in not only achieving but maintaining alignment between I/T and the business.  This calls for the executive team to continuously monitor the issues addressed in the model.  Doing so will open doors to marvelous opportunities for increased return on the IT investment.

If you want take this assessment I recommend you go the IBM Executive Business Institute web site, click on “Spotlight,” then follow the instructions that come up on the next web page.

You will be presented with 36 questions, 12 of which address the four domains of the Business-IT Alignment Model, and 24 of which address the relationships among the four domains.  The vertical relationships are called “strategic fit”.  The horizontal relationships are called “strategic alignment”.  The relationships are two-way between adjacent domains of the model.  There are three questions for each relationship. 

You answer the questions on a scale of 1 to 7 where 1 is “To a small Extent” and 7 represents “To a large Extent” with a midpoint, 4, neutral, which is neither a small or large extent. 

The result will represent your perspective at the point in time you answered the questions  (The most interesting results happen when two or more executives from the same organization each answer these questions individually.  Discussing the similarities and differences between the results could bring a major breakthrough in communications and strategy).

The results represent your opinion on the state of the twelve elements of the Business-IT Strategic Alignment Model in your organization.  It is important that we keep emphasizing that each set of results represents your point of view.

After you complete the instrument, the responses are compiled and presented in a graphic format as shown in this graphic.  This graphic is a typical result (one of many different possibilities) and is in fact from an executive who took our program Aligning IT & Business Strategies.

There are two images making up the result.  First look at the larger one, the one on the right.  The figures inside the domain squares are rounded to one decimal place, while those on the relationship arrow elements are rounded to integers.  The instrument calculates the best-fit "alignment perspective" and displays it on the left side.  The algorithm determines the perspective by using the strongest and weakest domain, using the relationship arrow scores as “tie-breakers.”

Every perspective contains one domain identified as strongest and one as weakest.  We name these as follows:

·         Anchor.  In every perspective the strongest domain is called the anchor.  In the above example the person  declared (in responses to the questions) the strongest domain in the organization to be “Business Strategy & Business Model.”  This domain is the one where decisions have the best ability to positively influence decisions in other domains. 

·         Pivot.  Every perspective also has a weakest domain, called the pivot simply because it’s where the perspective path “turns the corner,” i.e., pivots.  In the above example the person declared (in responses to the questions) it to be “Business Organization.”  The reason why the path moves direct from anchor to pivot is probably perfectly clear: you want to leverage (or lead from) strength to build up weakness. 

In addition there’s an important third domain:

·         Impacted.  As the perspective path turns it naturally moves into a third domain, called the impacted domain.  This is so-called because we see the management process of leading from strength to build up weakness will next influence the decisions to be made there. 

Comments on the "Strategy Execution Perspective," shown here: This perspective often results when the business has a strong business strategy and model, but a weak fit with the business organization (structure/responsibilities, processes, and skills). The organization should leverage the business strategy and model to build up the business organization and improve alignment with the IT organization & structure for automating business processes. 

Areas of focus are: 

1.      Building and improving strategic fit on the business side,

2.      Building and enhancing the business organization,

3.      Assessing the impact on the IT infrastructure as a result of changes to the business organization.

For focus area  1 - building and improving strategic fit on the business side:

·         What new products, services, and/or markets can be added or leveraged to improve the business organization?

·         What strategic competencies (i.e., pricing, distribution, value-add services, sales, marketing, etc.), can be added or leveraged to improve the business organization?

·         How can strategic alliances with external organizations be leveraged to improve the business organization?

For focus area 2 - building and enhancing the business organization: 

·        What are the issues with the business processes supporting business strategy?

·        Is the ownership of business processes clear; and are the outcomes clear, accountable and linked to the strategy?

·        Are the processes appropriate, or missing, low-functioning, etc in support of the business strategy?

·        What additional skills do you need to execute the key business processes?

·        How well does the business organization understand the business strategy?

For focus area 3 - assessing the impact on the IT infrastructure as a result of changes to the business organization:

·        How will the changes that come from building and enhancing the business organization impact your IT organization & structure (architecture, IT services/processes, IT skills)?

·        Will your architecture accommodate these changes; and if not, what architectural changes will be required?

·        What IT services/processes will be required to support any changes made to the business organization?

·        What IT skills will be required to support any changes made to the business organization?

Any result can be due to any of a variety of causes.  We have suggested plausible or likely reasons for thus result based on our experience, but of course in every case you are the best judge of why you answered the questions as you did.

Alignment (or lack of it!) confronts us in daily life

With the massive pervasiveness of information technology in society and business today, it should not be surprising that we routinely run into examples of good and bad "strategic alignment" --- or perhaps I should say "Examples of alignment and non-alignment."  The following tale will be recognized by New Yorkers.

The great and venerable cultural institution Metropolitan Opera has, after appointing a new general manager prior to last season, been undergoing some significant transformation aimed at expanding their following and audience base.  The opera announced a free, public open house to be held the week prior to opening night in September, to include attendance at a full dress rehearsal of the opening night production.  There one was one hook: you needed tickets --- an obvious requirement for crowd control!  It is easily predictable that when a "free" event of this quality is announced, the volume of response will beggar description.  However, this does not appear to have been so predictable to the Met Opera management.  Tickets would be available (free, remember!) via phone or web only, beginning at 10:00 AM the third day prior to the event.  And of course, by about 20 seconds after 10:00 both the reservation phone number and the Met web site were totally brought to their knees and had become non-functional.  I understand they had 4000 people in the queue although I have no idea how they were able to count them (Incidentally. the opera house seats about 3900).

The point of this tale is it shows a monstrous lack of "Strategic fit," i.e., a complete imbalance between strategy and structure.  The Met's management is admirably focused on growing the scope of the business (specifically, broadening the customer set) but has a telecommunications and IT infrastructure totally unable to respond to the initiative they designed in this case.  Of course, "what to do about that" is an interesting problem.  Can --- or should -- any organization invest in enough infrastructure capacity to handle a once-a-year huge peak?  Such an investment is clearly impossible for most businesses to justify  (Notice, I said "most" because exceptions do exist).  The alternative is to maintain strategic fit by keeping your strategic initiatives in line with either your existing infrastructure capabilities, or your capacity to invest.

The Strategic Alignment model

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)

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)

Welcome

The phrase --- and the concept of --- "strategic use of I/T" first began to gather serious attention around 1984 (even though it had been practiced in certain of the most forward-thinking organizations for a while prior to that). Over the intervening couple of decades since then the subject has spawned numerous articles, multiple books, and a couple of well-known executive education programs at major business schools. Far more importantly, it has fired up massive global investment in IT products and services --- one widely published 2004 estimate quoted almost $1 trillion a year, not counting telecommunications. It’s safe to say acceptance of the concept has been one of the major driving forces to create the "information economy" of today.

So where is the state of this concept today? The overall condition of the IT industry suggests it’s alive and well. On the other hand, vociferous debates about it in print the past couple of years make clear that it is being questioned in some quarters.

This writer personally weighs in on the "alive and well" side. While it is true that widespread adoption of e-commerce, e-government, customer relationship management, and a host of other front-end applications are making it increasingly challenging for any player to conceive the kind of creative and innovative IT solution that provides the holy grail of "first mover advantage," it’s also true that "challenging" doesn’t mean "impossible," or even "not worth it." The CIOs and IT leaders that I routinely come into contract with in my IBM executive programs by and large enthusiastically agree with me.

I cordially invite all views on all aspects of this important subject

Tom Curtin