A Different Kind Of Complexity Holds Business-IT Alignment Hostage

Business-IT alignment is one of those persistent "Top 3" CIO issues. It has been this way just about as long as I’ve been in IT. You would think this would have been solved by now. After all, you put in business-driven IT governance, relationship managers, and some really nice dashboard, and you’ve covered about 90% of the advice out there. I’m going to suggest that business-IT alignment is being held hostage by complexity. Not technology complexity, since business leaders seem to be coming to terms with that. And not the mind-numbing spaghetti charts that show how complex our application and infrastructure landscapes are. They don’t understand these charts, but since we don’t understand them either, we can hardly expect business execs to. The complexity I’m referring to lies between their goals and the "stuff" IT delivers. They don’t see the connection. And since we see business execs having lots of goals, which shift over time, and strategies that also shift, we can’t show the connection. Instead, we say, "This is what you asked for, and this is what we delivered."

Quick illustration -- this is how it’s supposed to work: The senior execs all share one goal -- say, "be premier supplier of widgets to the traveling business exec," and one strategy -- "design lots of widgets and see which ones people like." This strategy is translated into one program -- "get really good at designing lots of widgets," which turns into one IT project -- "implement new widget design application." Clear connection between goal, strategy, program and deliverable. Well-aligned IT, happy business. What you hear in the real world: "We have lots of goals, it depends on who you talk to." "Our strategy is very high-level because we want to see what people come up with." "Well, of course our strategy changes, things are changing." "Yes, this program may be touching many aspects of how we do business, but we want you to focus on the IT projects." "What do you mean, my IT project won’t get done (or is deferred or maybe canceled) – this is really important to my goals!" "It’s great that you delivered this project on-time, on-budget, but here are a list of changes I need." "You IT guys don’t add value, you are slow and you are not aligned with enterprise needs."

In the real world, companies have: More than one goal once you get a click below EPS and earnings growth. Strategies that are more themes than plans. Business change initiatives that have many moving parts. Change in all of these -- goals, strategies, initiatives. IT project requests that exceed capacity and so only some get done, others are deferred, and others go on the waiting list. IT delivers projects -- some on-time, on-budget but others delayed due to "unclear business requirements." IT did what it was asked, but business isn’t happy, and the result is "not well aligned IT." So what does this have to do with EA? Jeff Scott, in his recent blog, gave the direction, "Before you embark on a business architecture program, figure out what problems you want to solve." One of the key problems is IT-business alignment. Business architecture helps IT-business alignment by helping execs clarify goals, strategies, and the needed changes in the business operating model, and by helping IT understand and deliver to these goals, strategies, and needed changes. There are several approaches to doing this -- we believe that business capability maps – incorporated into governance, relationship management, and IT dashboards -- are the most versatile and useful approach. I’m currently working on a keynote speech at the Forrester IT Forum on this topic. And EA track sessions will go into more detail on how capability maps work to achieve this better IT-business alignment. I’d love to hear your thoughts on this issue and this blog post, as it will help me develop a better keynote speech.

The Early Bird rate for IT Forum expired April 9. If you haven’t registered already, call our Events Team at 617.613.5905 with discount code ITXBLG, and they’ll extend the $200 discount for you.


Business - IT alignment

Dear Alex

You make a very interesting point in reference to the reasons for the persistent Business - IT gap. Those of us who have been involved with business architecture long before it was acknowledged as an integral part of Enterprise Architecture find it rewarding to also read about business capabilities. It is certainly not a new discovery since the terms "capabilities" and "competences" have been widely used in Strategy and Operations for years.

But we have recently realized that business capabilities, within the realm of Enerprise Architecture, may be the building blocks for bridging the Business - IT gap at long last. How is that? Well, first of all in order to align business and IT you need common elements. Application Systems have what IT people call functionality, for which the business couldn't care less, but this functionality supported by the right technologies and the right people leads to system capabilities. The more advanced and state-of-the-art the systems are, the more capabilities they have. Sometimes you feel they can do just about anything. Now it starts getting intersting doesnt it? We may have found the common element, capabilities. Business capabilities mapping what the business can do and system capabilities mapping what IT an do to help the business. The only challenge remaining is to match these capabilities (one-on-one is very difficult since there may be, say, three system capabilities covering/ being able to support one business capability). One might say that the "language" that we use to understand capabilities may be different because IT capabilities are expressed in different terms than business capabilities. But we have seen from project experience that in fact when you drift away from functionality and technology thinking you tend more and more to describe capabilities in terms that make sense to the business.
Therefore when you match system capabilities to business capabiliites and elevate this practice to perfection you create an extremely agile organization ready to react to any change, internal or external and this agility may be the ultimate competitive advantage.

Thanks for this comment. I agree 100%

Hello, George

You provide a very good perspective on several aspects. The first is that Capabilities are a higher-level concept that business can relate to on their terms. Now we are 'speaking their language' - a bit of empty advice often given to IT people, but now with some real substance behind it. A firm I was talking to recently who have a similar model to this (same concepts, different terms) related a comment from a business VP: "you IT folks have never talked to me this way before. I like it..."

The second perspective, implied in your comment, is that the capabilities which describe a business, need to be persistent in terms of their purpose, although they can be very dynamic in terms of how they are performed. With persistent capabilities, you can map the functionality IT provides to the details of how the capabilities are performed - and then map improvement goals for a capability to improvements to functionality. This view of 'persistent capabilities' is in contrast to a common usage of capabilities as 'new things' - which leads to the demand for new systems, and leaves existing systems in limbo. You can't track improvement over time in an organization's business capabilities if you only view capabilities as new things in response to new needs.

One question I have which relates to your last few sentences is around the term IT capabilities and the mapping of IT capabilities to business capabilities. Many firms I know talk this way. However, I am wondering if we shouldn't instead talk about IT's Business Services instead, mapping them to business capabilities. I think IT people understand the concept behind services (SOA or ITIL), and this brings both of these together into business services - combining people, process and technology.

What do you think?

You don't need to bridge a gap if everybody is on the same side

Hello Alex,

Thanks for following up on my comment.

I think our discussion unavoidably contains both "philosophical" as well as technical elements. By philosophical I mean the understanding we have about a certain mentality and mindset within businesses that affects operations and how we can influence that mentality. So let me say a few words on this and then I will address the more technical stuff.

IT is for the transactional part of the business the equivalent of Machinery - assembly lines, specialized equipment, robots - for the factory level: Means for executing business processes using technology for speed, integrity, accuracy and increased overall productivity and competitiveness. But in the factory level no one talks about any gap between business and machinery and ways of bridging it. In an automated assembly line the process is defined within the equipment much as it is with IT for the transactional or service level. The people who design and implement assembly line components make an effort to understand what is required of them by the business, not the other way around. Those building assembly lines for automobiles know automobiles very well. I am not sure I can say that people implementing IT for banks understand banking very well (to be fair, some do).

Because IT in the form of business applications was such a revolution, it led to IT people overestimating their role, their responsibility for the business and their contribution. It is not arrogance; it is a mentality that business is nothing without IT. Now, if business people also think that IT is not crucial, there's your gap and it can be a huge one. What you have in this case is IT creating systems as they see more suitable or "state-of-the-art" and the business side using these systems ala cart - partially, occasionally or not at all. Sounds familiar? A telco may have a fault management system in place to handle trouble tickets and the whole fault-to-restoration process but it can easily bypass this using email, telephone and paper if users don't see or don't get any benefit.

Now, on the technical part: The idea of using business services as combinations or "packages" of web services in a SOA environment - if I understand it correctly - is excellent. However, it still allows IT people to "slice-up" end-to-end processes that deliver value to customers without requiring them to "see" the entire process and the reason for it. In this way they will venture to improve the slices, by providing more elegant web services, but they will never be able to help reinvent the process and in doing so help reinvent the business to the customer's delight. But isn't this what factory automation offers with kaizen and lean manufacturing? We claim to have spread the idea of lean thinking to all levels of business, including the transactional, but waste in business IT abounds. Multiple applications for similar processes, proliferation of databases, lack of data integrity and security, multiple technology standards.
So what is the solution? The only solution I see is for IT people to become experts in the business, either by selection - e.g. hiring banking experts who know IT and let them lead IT and not the other way around - or by training and job/management rotation. And you will know this is happening when, down the road, we see more CEOs coming from IT.