The hype around Service Oriented Architecture (SOA) is tremendous—it will revolutionize IT, make life easier, streamline business, and provide untold flexibility and responsiveness. Of course, it’s not quite that easy, especially when you already have layers of legacy technical architecture, a high maintenance and support burden, and rabid business clients demanding new solutions yesterday.

So, how do you realize the potential of SOA without raising expectations so high that they will come back to bite you? Which issues do you need to address first? And, what is a realistic timeline and approach?

Faster, Faster, Faster!

Over the last 20 years, the pace of business has quickened. Things that used to take days or weeks now take minutes or seconds. Products that used to sell for years or even decades are now obsolete in just two or three years. As a result, business is being forced to react to change far more frequently. And, that pressure to be responsive and handle rapid change is being passed directly on to IT.

Layer Cake Architecture

Unfortunately, in most large organizations, it is impossible for IT to keep up. Decades of investment in IT have left many with an architecture that resembles a layer cake. Solutions have been created by adding layers of new technology on top layers of old technology.

At the time it made sense—we were leveraging existing investments, avoiding reinvention of the wheel, and not fixing what wasn’t broken. However, the problem now is that changing a system that consists of anywhere between four and seven layers of mainframe, mini, client server, ERP, N-tier, web, portal, and integration technology is a nightmare. And, because every layer still needs to be maintained and supported ‘lights-on’ costs are huge.

The IT Catch 22

CIOs and IT departments are in a Catch 22. In order to become more responsive, more cost effective, and more flexible, IT must first become less responsive, more expensive, and less flexible. It’s the same as a highway expansion project—while you are constructing the new lanes and mass transit that will reduce traffic jams, you need to close some of the existing lanes.

For IT to deliver faster, better, cheaper solutions and be more responsive to business change, the layer cake architecture will need to be replaced. But, even if a CIO can get the organization to buy off on the potentially massive investment necessary to replace its legacy systems, what should they replace them with? After all, there’s no point in replacing legacy with solutions that will be inflexible, expensive or the legacy systems of the future.