Services-orientated architecture is the new great white hope for application development and deployment which is going to protect companies’ investment in their legacy systems while making both existing and new applications more useful, flexible and adaptable in today’s constantly-changing business environment. With customers clamouring for access to SOA, we’re seeing new and complete offerings coming from the major software development, management and middleware vendors. 

Organisations around the world have been grappling with ways to move their businesses forward with new and innovative IT solutions, while protecting the sizeable investments they have made over the years in software development.
And it’s not just the investment: legacy systems are to be found at the heart of many mission-critical systems and, without them, many businesses would grind to a halt.
It’s imperative, therefore, to keep those systems running, while simultaneously introducing new products and services based on both these and newly-developed software.
Services-orientated architecture (SOA) could be the answer these companies have been looking for and, certainly, initial uptake in the concept has been positive.
Very simplictically, SOA is about breaking programs down into their seperate individual processes and exposing these processes as a service.
Again simplistically, this would involve isolating the code to, say, generate a delivery note, encapsulating it to form a standalone object and providing it with an identity and integration capabilities.
In theory, developers can then use these existing pieces of code, now exposed as services, together with new services representing either IT of business processes to craft enterprisewide services, processes or applications.
Services can be mixed and matched in various applications, while the ability to re-use them any number of times is an attractive selling point.
If this sounds surprisingly like object-orientated programming, there’s a good reason for that: the idea of using little pieces of code to construct bigger applications and re-use as necessary is as old as the art of programming itself.
The idea of taking little pieces of code (objects or components) and exposing them as services isn’t really new either: Web services, together with the eco-systems from Microsoft and Sun Microsystems that cater to these services have also been around for some years.
Software AG’s Dr Stefan Ried explains that many companies have been using object-orientated programming methods, and developing Web services for some time.
The problem – and the reason why there’s some scepiticism now around SOA – is that while companies have been using the programming techniques, they haven’t created the whole eco-system to sustain their development.
“SOA is in a bit of a trough at the moment,” says Ried. “The thing is, many people have created an overwhelming number of Web services, but many have no clue about managing the total cost of ownership (TCO) or service level agreements (SLAs), or things like that.
“Companies have been trying to run without first learning to walk and, as a result, have come to believe that SOA is not reliable – and the first thing our customers want it high reliability.”
Software AG was the first company off the blocks with a new eco-system designed to facilitate the creation, storage and management of services in a truly reliable, enterprise-class product set.
Ried is quick to point out that SOA is not a product itself, rather a philosophy, but that Software AG’s CentraSite is a “productised” version of the concept.
“The idea is to guide our customers through the many steps required for discovery, bluepriting, implementation and optimisation of an SOA strategy.
“We cycle them through the steps, and have products at each step that support the process.”
Marco Gerazounis, country manager at Tibco SA, believes SOA provides an opportunity for IT to reconnect with the business – but unless an SOA architecture is built and deployed in line with business process requirements, alignment cannot be achieved and the benefits of re-use, flexibility and faster development cycles will not be realised.
“If SOA, as some would have it, stands for “same old architecture”, then it begs the question: what is different this time around?” asks Gerazounis.
“The fact that today’s SOAs are built around a whole raft of commonly-agreed standards with significant momentum behind them in most parts of the vendor community is only part of the difference.”
The difference today, he says, is that SOA projects are being built in line with changing business requirements.
“The ICT community is waking up to the fact that architecture is not something that can be hard-coded to meet a particular pain point or built once in isolation from the business problem and deployed many times over – the traditional packaged software model.
“Instead, SOA as a discipline dictates a particular approach to design, development and deployment, and applied to an organisation’s business processes, it brings significant advantages over traditional approaches.,” Gerazounis says.
Connecting together new developments is difficult, he adds – and organisations have employed point-to-point connections to pull in data from previous developments, creating a spaghetti code of integrations unable to maximise the benefits of each successive round of effort.
“Analyst group Macehiter Ward-Dutton says the IT/business disconnect manifests itself in four areas: the high cost and risk of technology integration; the difficulty of getting access to the right information at the right time; the time and effort involved in modifying systems; and the uncomfortable truth that IT expenditure is bloated and fixed.
“The argument for adopting SOA is appealingly simple: if elements of functionality can be offered as services, then these services can be re-used from one project to the next.”
The wider benefits of SOA come from the flexibility provided to the entire software architecture for future change, and the speed with which these changes can be achieved, Gerazounis says.
“Users have documented significant productivity gains from an SOA approach to development, finding developers are not only freed from the grunt work of writing low-level code but also as a consequence of this, have more time to focus on what is really important to the business.
“They also point out that productivity improvements do not come immediately in an SOA, but incrementally as successive projects are implemented.”