Information Age: News, analysis & insight for IT & business leaders

Service-oriented architecture is proving its potency – but only when fully embraced and aligned with the business

After years of high expectations, and equally elevated hype, the reality behind service-oriented architecture (SOA) – the principle that software is best delivered as a series of discrete services that can be combined and reused to make new applications – is beginning to emerge. But even some of SOA’s cheerleaders are prepared to admit that things are not going entirely smoothly.

At the November 2007 launch of a joint venture between consultancy Accenture and integration technology vendor BEA, for example, the former’s CTO, Donald Rippert, declared that the progress that SOA was supposed to be forging had stalled.

Businesses may have successfully wrapped up their legacy applications so that they can operate as open standards-based web services, he said. But the promised end point of a software architecture that can be dynamically restructured to reflect changes in business processes is still more of a goal than a reality.

Elsewhere, research shows that the majority of SOA projects have yet to deliver a return on investment (RoI). Of the more than 100 organisations questioned by IT industry analyst Nucleus Research on their use of SOA development practices, only 37% reported evidence of an RoI.

That said, the poll did show some positives. Developer productivity had increased 28% as a result of SOA adoption. According to the research, 32% of published services were reused – supporting one of the main benefits of SOA in terms of reduced time, effort and cost. That number might be disappointing for many proponents of SOA’s principles, but they argue that any organisation failing to draw the full benefit from SOA is simply not doing it right.

A report by the Aberdeen Group found that those organisations that had wholeheartedly adopted a full SOA infrastructure (built around an enterprise service bus, registry and repository) had been twice as successful at achieving application lifecycle cost reduction and user satisfaction as those that had merely wrapped some legacy applications as web services.

Be that as it may, it is clear that for many organisations adopting the practice, the promised business benefits of SOA have yet to materialise.

That is perhaps not all that surprising. Even though it has been billed as a catalyst to an agile and responsive IT function that is aligned to the business, SOA is no different from any other enterprise technology: it must be designed and implemented with business objectives in mind – from day one – if the desired payback is to be achieved.

Unfortunately for IT departments undergoing an SOA transformation, the typical business manager has no understanding of SOA, and no desire to gain any. This makes finding the middle ground where business objectives and IT best practice meet all the more difficult.

But developments in three areas – business process management (BPM), application vendor adoption of SOA and the decoupling of the user interface – suggest that the business case for SOA may become more immediate, more tangible and more readily realised.

Leave BPM to the business

The two technology fields of BPM and SOA are closely linked. SOA infrastructure vendors pitch their technology as the enabler of BPM, while BPM vendors pitch theirs as the easy route to SOA. According to Gartner analyst Elise Olding, this close coupling has led to an inappropriate confusion of responsibilities.

BPM projects, writes Olding, are often led and managed by the IT department. It is easy to see why – they are technologically complex and, on the face of it, more akin to application development than anything the business usually undertakes. However, Olding argues that BPM is a quintessentially different beast to application development, and the assumption that IT is best placed to lead BPM projects explains why so many have failed.

“IT leaders are inclined to design for the solution and then fit the process into it,” says Olding. BPM projects require a detailed understanding of the way in which business processes operate at the moment and what kind of changes could be made to improve them.

Under IT’s guidance, Olding continues, “there is a rush toward a solution, which is usually to automate the process. This leap to automation can result in very little change to the process and a diminished return on investment.”

A BPM framework gives the business a reason to adopt SOA. Not only will business leadership in BPM improve the chance of success and return on investment, it will imbue any work by the IT department towards an SOA with a business case above and beyond reducing the cost of development through reuse. Indeed, it may even improve reuse, as the business will be in control of code through the prism of BPM.

The invisible SOA

Another factor that promises to make SOA a concern of the business – explicitly or otherwise – is the trend among applications providers to sell new versions of their software as SOA-ready services.

Mid-market ERP specialist Infor, for example, announced in 2007 that it is to bake an enterprise service bus from Progress Software into forthcoming editions of its applications, thereby providing its customers with what Bruce Gordon, the company’s CTO, describes as an “invisible” SOA.

“At the end of the day, companies in the mid-market do not want to buy SOA technology, they want to buy business solutions,” he explains. “So we have to be able to hide the complexity inside the application.”

In the enterprise space, Oracle will release its Fusion range of applications – the culmination of a strategy to provide an amalgam of middleware and applications – in 2009. The company has converted its existing enterprise application stack into SOA-ready services.

Both companies share the same impetus to make this SOA conversion: both have built up such broad portfolios of applications as a result of numerous acquisitions that they have had to push the SOA agenda on customers as a means of ensuring interoperability across the product range.

But despite the arguably self-serving motivation of such software vendors, as more applications are sold in SOA-ready states, the flexibility and customisability of service-oriented applications will eventually trickle down to the business audience. That will stoke demand, which will in turn necessitate back-end infrastructure investment.

Further reading

Back to the Effective IT 2008 Report contents page

Structural hazard Service-oriented architecture has won many converts, but its popularity should not mask the challenges of delivery

Process report Early adopters of business process management highlight how success is linked to a strong commitment to the underlying technology and a deep understanding of the organisation’s processes

Find more stories in the SOA & Development Briefing Room