|
alignmentbusiness / system / technology |
|
Business-IT alignment is ...
|
I find the concept of IT/business alignment rather outdated, for three
main reasons.
![]() |
Firstly because I can no longer think of business separately from IT. In the past, perhaps, IT was merely an instrument for achieving a business strategy. Nowadays, the IT strategy is an essential component of the business strategy. |
![]() |
Secondly because the goals of IT should be the same as the goals of the rest of the enterprise - alignment with market demand and delivery of added value. IT no longer needs to be a subservient partner, following closely on the heels of non-IT players who are the "true" deliverers of value. |
![]() |
Thirdly because business/IT alignment is of no intrinsic worth - it is a means to an end, not an end in itself. |
Metaphor: in health care, we're not interested in nurse/doctor alignment for its own sake - we're interested in patient care. If there is too much conflict between nurses and doctors, or not enough coordination, then this may well be harmful to patients. But's that's not the primary focus.
However, the official (or "espoused") business strategy typically overlooks or trivializes this contribution, and therefore represents a serious distortion of what's really going on in the company.
In these companies, the challenge is not that IT should become a component of business strategy, but that its contribution should be legitimized and properly articulated.
I'm certainly not saying that alignment is a bad thing. Alignment may often be appropriate as a tactical goal - bringing the official business strategy and the official IT strategy closer together will perhaps surface some of the underlying problems. But I'm already looking beyond business-IT alignment, and asking where it leads next. Perhaps some companies will be able to go straight there, and not bother much with business-IT alignment as an intermediate goal.
However, I'm also concerned that too much alignment might lead to tight coupling between business and IT. If IT people are to get involved in every aspect of business, and business people are to be consulted at every stage of every IT project, then maybe we have lost an important separation of concerns.
But for most of us today, that assumption doesn't apply. Both IT and business are dancing around each other, never quite touching, narrowly missing treading on feet.
A particular case of this is in E-Commerce. Traditional requirements analysis doesn't make sense, because nobody knows what the requirements are, everyone is experimenting, everyone is watching everyone else, some hoping to get ahead of the game, others just hoping to catch up.
And when we've haven't even sorted E-Commerce, along comes M-Commerce, following by XYZ-Commerce.
The enterprise of IT is encircled by accelerating rates of change: the business world generates an unending flow of urgent demands for new and enhanced IT systems; meanwhile the technological world generates an unending flow of fascinating new opportunities.
Faced with this situation, many IT writings retreat into solutions that aim to improve IT potency, by addressing the productivity and quality of the IT process. If we can satisfy business demands faster and more accurately, then perhaps we will catch up.
Worthy though these attempts are, they are doomed to fail, because they allow both IT and Business to position themselves as passive: IT is merely responding to demands from an insatiable Other, while Business is crying out for satisfaction from an unreliable Other. In our new book, we shall explore how business and IT can engage actively with demanding change.
The focus of the business agenda is shifting from processes to relationships. Although business processes remain important, the strategic issues for many large organizations have to do with external and internal relationships.
This has been part of the debate surrounding large packages such as SAP, Baan and PeopleSoft. To what extent are these packages underdetermined, leaving a wide range of configuration and operational choices to the companies that acquire them? And to what extent are these packages overdetermined, imposing a particular structures and procedures on these companies? These questions are crucial for controlling the implementation costs of such packages.
At the other end of the spectrum, some general-purpose software products have an enormous range of possible uses. For example, Lotus Notes can be used in many different ways. If a large organization installs a thousand copies of Lotus Notes on a thousand workstations, each copy may be used in a different way. In a manner of speaking, there isn't a single product called Lotus Notes, but a thousand different products, all called Lotus Notes. We refer to such general-purpose products as a platform.
A large organization that acquires a general-purpose platform such as Lotus Notes needs to understand this variation, and the limits of control, so that the use of the platform is aligned with the business purpose for which it was acquired.
![]() |
Alignment is an ongoing process, not a one-time outcome. |
![]() |
Deep alignment demands attention to the causes of misalignment, not just the symptoms. |
![]() |
Alignment demands mutual adaptation of business plans, system plans and technology plans. |
![]() |
Total alignment is unachievable - and probably undesirable. |
![]() |
Should technology be aligned to business, or should business be aligned to technology? |
![]() |
What are the typical symptoms of misalignment?
How can symptoms be alleviated? |
![]() |
What are the common underlying causes of misalignment?
How can underlying causes be addressed? |
![]() |
How can anyone judge whether alignment is good enough?. |
top | ![]() |
|
|
Copyright © 1994-2001 Veryard Projects Ltd http://www.veryard.com/sebpc/bsta.htm |