The development of a service-oriented architecture (SOA) has become one of the key pillars of the IT strategy in companies across the globe. IT leaders, analysts and vendors all agree that SOA has the potential to reinvigorate IT’s corporate reputation, as it ushers in a new era of agile, responsive, business-driven IT. Amid the fanfare, it can be easy to overlook that such a revolution will be no cakewalk; progress will be hard won.

The claims being made for SOA are bold, in some cases even overblown. One SOA expert and author, JP Morgenthal, goes as far as saying that SOA has ramifications far beyond the world of technology. “It is a design pattern that can be applied to any type of system in the world, including purely human-based systems, such as order taking at McDonald’s.”

But for most organisations, SOA has a more mundane, yet still profound purpose: to ensure that IT becomes the engine room of business agility, rather than the anchor it is often characterised as today. And there are now sufficient numbers of CIOs energised by SOA that its momentum looks unstoppable. Information Age’s own Effective IT research indicates that more than 50% of enterprises have adopted web services strategies.

The reasons for SOA’s popularity are well documented. Traditional enterprise application integration techniques are unwieldy, difficult to code and absorb significant cost without adding much in the way of competitive advantage. SOA offers new hope: the ability to quickly compile new applications from component services should make for an IT operation that is reactive to fluctuating demand, making the enterprise more agile. 

SOA is also predicated on open standards, which should make integrating applications simpler and faster. And the ability to reuse code in establishing new services, and to reuse services in multiple applications, should reduce the amount of development work that is required in any project, and therefore reduce costs.  

Hidden dangers

The allure of SOA is palpable and, according to IT advisory group Forrester Research, adoption is gathering pace. As of late 2006, 20% of European organisations have a fully formed SOA strategy, Forrester reports, up 6% from 2005. A further 20% are applying SOA technologies selectively (again an increase on the 2005 figures – up 4%). The key drivers, Forrester notes, are increased business and application agility, followed by lower software development time and reduced costs.

But not all companies that have begun to service orient their IT infrastructures have found the switch to be as edifying as expected. One in five US companies that have taken the SOA plunge has found that the move introduced unexpected complexity, reports IT analyst group Ovum.

One of the chief criticisms levelled against SOA is that the anticipated return on investment (ROI) will not materialise for many years. Researchers at market watcher Saugatek Technology believe that SOA will not substantially reduce IT costs for those organisations already adopting it until after 2012. The desired payback will be stalled by the investment in training that is necessary to deliver SOA and the lack of genuinely open standards that will allow competitive products to interoperate. Those expecting a quick return, the report’s authors conclude,  will be sorely disappointed.

None of this calls into question the wisdom of SOA. Indeed, given its status as a ‘design principle’ rather than a technological product set, it is almost impossible to question its wisdom: a failed SOA implementation is a failure in the application of the principles, not of the principles themselves.

But it certainly highlights that, despite the mounting excitement around the model, there is a real danger that SOA projects will make IT more complicated and more expensive, not simpler and cheaper.

So what is it that stands in the way of businesses in their attempts to realise the benefits of SOA? Examined here are a number of pitfalls that can either undermine the chances of gaining a return on investment from SOA, or even result in systems that simply fail to work. They can be roughly grouped into technological concerns and organisational concerns, as the task of becoming a service-oriented enterprise demands both new technological skills and a new approach to technology.

Design flaws

The ideal end-point for an SOA implementation may be regarded as a collection of discrete web services, well-documented, engineered to be reliable and scalable, and easily linked to business functions. However, each of these aims present its own hurdles to be overcome.

Creating this collection of autonomous web services throws up the first problem. Ideally, by the end of the SOA transformation, business architects, with a deep understanding of operational processes, will be able to rapidly compile a number of these services to automate a discrete process. IT’s role in this is to make sure the services work and can be integrated satisfactorily.

To date, however, the task of creating these services has been almost too easy, says Steve Craggs, president of Saint Consulting, an SOA services company. “I have seen a lot of what I call the ‘right click syndrome’. This is where developers use tools to turn every single piece of application functionality into services. It is often a complete disaster.”

A simple function – say that of retrieving a customer’s address – might depend on a collection of legacy systems and a number of operations. For example, the accessing of the customer name from a database, the conversion of that name into a unique identifier, and then a third function that looks up the customer number and returns address details. The order in which these are conducted is vital to the successful completion of the task.

“In the ‘right click syndrome’, each one of these functions is turned into its own service,” explains Craggs. “That means that any application which needs to retrieve a customer address must be programmed to understand the order in which these services are called. And if you are to change the way the service works, the calling application will again need to be updated.”

Such examples demonstrate how the inappropriate creation of services can make more integration and coding work necessary, instead of less. What should be created instead is a discrete service that conducts all three functions, so that the service reduces complexity rather than adding to it, says Annraí O’Toole, CEO of enterprise service bus vendor Cape Clear. “You should be able to bring a business person in and explain to them what the service does,” he says, otherwise it is an unnecessary service.

Unless CIOs are fearless in evaluating what services are absolutely necessary there is a danger that the new architecture will simply repeat mistakes made before, he adds. “You have got to remember that that the incumbent vendors have a lot to protect; they want you to keep using their stuff,” he says. “But unless you really understand what services you are going to create, and why, there is no point in doing SOA. You must have a revolutionary approach.”

The way in which services interact with one another must also be addressed. Developers grounded in Java coding may be tempted to build synchronous services, which, having issued a call, wait for responses before continuing. “When you are building large-scale applications, such as an SOA, if you build them in a tightly-coupled, request-response fashion then the result will be very brittle and the whole thing will inevitably break down,” says O’Toole.

It may also be tempting to include service level agreement provisions into services. For example, a company with a subset of customers to whom it promises a higher availability of services, may prioritise traffic associated with those accounts at peak times.

A common error, says O’Toole, is to design this traffic control into services. This means that any time the service level agreements are changed, all services that relate to the SLAs must be recoded. “If you build SLAs into services, you are coding in years of misery,” he says. Instead, an over-arching SLA governing service that can be applied to all other services is the appropriate solution.

Pitfalls

The implementation of SOA also demands careful consideration of the infrastructure that supports it, warns Ravi Kalakota, VP for strategy and solutions management at system integrator Unisys. “We have seen numerous examples where the software architects move the SOA into production, only to find that it has worse performance than the old mainframe.”

Companies instigating SOA often discount the significance of the underlying infrastructure, says Kalakota. “If your infrastructure is fragmented, so for example a service is based on 25 different servers, consolidation is the first step. That message is not getting through.”

“If you don’t fix the infrastructure, but you have a great SOA, you will have to over-compensate with more servers. And that kills your ROI,” he explains.

Virtualisation technology may help businesses to consolidate their server infrastructure, but it also important to keep a close eye on how hardware resources are being consumed by services, says Kalakota. The field of business service management is a complicated area, he says, and achieving a comprehensive map of how services relate to infrastructure is a massive undertaking that might not always deliver a satisfactory ROI. At the very least, though, “you have to have a feedback mechanism constantly monitoring what is going in and coming out of the service bus.”

The impact of SOA design upon infrastructure performance is often untested until the systems go into production, which Cape Clear’s O’Toole reports is the most common cause project failure. “Failed SOA projects all share the characteristic that scaling and performance testing have been left to the end.”

Mike Scott, the former head of innovation at BT, now at TCS Global Services, experienced the dangers of poor scalability testing first hand while at the telco. “We had an ERP system, which we wrapped as a service so we could push it out to suppliers at one end, and BT at the other. When we went into production the whole system locked, costing us two weeks fixing it.”

“We argue that testing should begin in the first week,” says O’Toole. “Most problems can be solved with some simple architecture redesign, but it has to be done early.”

Scott also attests to potential complexity of keeping track of the link between services and hardware: “The configuration management [the process that links hardware assets to application functionality] must really be under control; but you only need two or three configuration products. At BT, we had everything going.”

Service culture

Finally, SOA dictates a fundamental mind-shift for IT practitioners and business leaders alike. Developers, says Saint Consulting’s Craggs, must be actively encouraged to engage in the reuse of code if any ROI is to be realised. “Vendors will tell you that agility is the return for SOA, but most companies have justified their investments in SOA by demonstrating that it will reduce development costs and the time to market for new services. Both of these depend on reuse,” he says.

“But most developers worth their salt are loath to reuse code; by their nature they want to find new solutions to old problems. So you need cultural training to make them do it.”

At US financial services giant Wachovia Bank, this reuse has been encouraged through the use of bonuses – the more code developers reuse, the more they get paid.

Reuse is also endangered by the differing requirements of various departments within the organisation, says Craggs.

“Often a developer will publish a service, and then a certain department will say it doesn’t do what they need it to, so the developer will create a new one,” he explains. “So instead of reuse, you get a proliferation of services. You need cross-departmental agreement when defining services, or there is little change of ROI.”

Deciding how service requirements are to be defined in the face of differing departmental requirements – and establishing which departments are responsible for which services – calls for strong leadership from the top.

“You need to decide where the locus of control is going to reside,” says Bruce Graham, senior VP at middleware vendor BEA’s global SOA practice. “That decision impacts the way services are going to developed, so you need to take it early on. And because that involves a lot of company politics, it can take months to reach agreement.”

Graham says that the design of an SOA calls for the CIO to become unusually engaged in the nitty gritty of technical design and departmental ownership. “In the most successful projects I’ve seen, the CIO has been directly involved in governance. That’s a significant shift; they need to step down and get close to the process.”

But others believe that CIO buy-in alone is not enough; SOA success requires the business to be involved from the outset. And therein lies an irony: For many organisations, in terms of SOA, the carrot on the end of the stick is the closer alignment of IT and business. But if any SOA project is to be successful, that alignment must already have been achieved before any work can be successfully undertaken.

Further reading in Information Age

Also from the March 2007 issue:

Untangling the data knot – Data management in SOA

More articles can be found in the SOA Briefing Room