Cheat Sheet: SOA

SOA?
It stands for service-oriented architecture. Sometimes people talk about SOAs, even pronouncing it as a word.

Oh great, another alphabet soup acronym to confuse us all. Give me the 35,000ft view. And why should I care?
SOA actually does what it says on the tin. It's an IT architecture based around common platforms, protocols and reusable code. It can be used to support and connect services and business processes across an enterprise.

Eh? Come again, in English this time please...
SOA is essentially a collection of loosely coupled functions across the IT infrastructure - internal and external - that communicate with each other to provide a particular service or business process.

And why's that good?
The alternative is to stay with siloed, standalone applications that can't easily talk to each other. Non-SOA applications are designed to carry out fairly specific functions and the code in them is often not easily reusable. To modify and customise them so they can talk to other applications becomes costly and complex.

OK, I think I get that but give me an example of how it actually works in practice.
One real-world example is the London Stock Exchange, which has used an SOA to enable its systems to communicate directly with those of the various financial firms it must work with. Other hypothetical examples might be the bank that has grown by one acquisition after another - for example allowing the systems of its retail banking, insurance and mortgage arms to speak with each other and a common CRM system - that uses the SOA middleware layer to pull information from the various legacy systems. Or the travel agent that uses SOA to allow its customers to book cars from a separate car rental company.

Sounds like the web services promise of five years ago. Isn't that all SOA is?
That's a common misconception. The SOA approach has actually been around for more than a decade but it's only started to come into more widespread use in businesses now because of the standard technologies, protocols and languages associated with web services, especially XML. To put it simply, web services is the connectivity that enables various applications or functions in an enterprise to plug in and talk to each other and provide the 'service' in SOA.

What are the other benefits of a service-oriented architecture?
By reusing the functionality in applications instead of developing lots of standalone apps it cuts development costs as well as simplifying an enterprise's IT infrastructure and making it much more flexible and agile. In an SOA, services can be quickly adapted to new or changing business processes where previously it might have meant completely redesigning existing applications or buying in expensive new packages.

And how does this all differ from another annoying TLA: EAI - enterprise application integration?
Good question. There are plenty of vendors and IT services players out there for whom the distinction is blurred. They are two approaches towards the same goal, in many cases, if we harp back to - say - the above example of a bank trying to get a single view of a customer, a single version of the truth, as they say. In outcomes EAI bears some similarity to SOA but they are not the same thing.

Is it easy to implement an SOA?
No it isn't and some analysts predict that doing so will eat up 40 per cent of your IT budget. Gartner says that by 2008 SOA will be the prevailing software engineering practice and warns that organisations which haven't started on the SOA path by then will be placing themselves at a competitive disadvantage.

Is that something users see?
Put it this way, in a recent silicon.com CIO Jury two-thirds of respondents said they have already moved or are planning to move to an SOA platform. Financial services companies in particular seemed pretty excited and generally there was a view that SOA equals greater agility. Those who weren't smitten pointed to "more marketing over substance".