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

Involve the business. The SOA is all about aligning services with business processes - and no-one understands these better than the business managers. Forrester Research advises IT architects to involve business people at an early stage - they may, for example, want to change or simplify processes. "The business has to understand it, or its not a business process," says one Forrester analyst.

Focus on the architecture. The Gartner Group warns: "SOA, like all forms of reuse, requires planning, discipline and documentation." Although the SOA is flexible, design flaws will create serious problems later. Ian Howells, global marketing director for See Beyond, suggests that organisations categorise processes into three groups. Those that are unique to an application should be left where they are; those that are replicated in several applications should be extracted and offered as one service; and those that span many applications should be implemented at the SOA service layer.

Choose the platforms carefully. Many different products promise to support SOA. Their limitations and strengths need to be clearly understood and the most suitable combination chosen. The SOA is an opportunity to reassess and maybe switch key software suppliers.

Retrain the developers. Unless the right mindset is adopted for web services development, say advisors, enterprises risk losing the gains they have made in a spaghetti of poorly managed services. Peter Bell, Microsoft's ISV strategy manager at its platform strategy group, says that the company is working to educate developers about SOA and plans to include SOA development techniques in the next version of Visual Studio. "You need to layer SOA on top to get any far-reaching benefits."

Understand the granularity issues. Many developers have a more granular approach to programming than SOA might require - perhaps because of their backgrounds in object-oriented programming. But more services means more complexity, more traffic and more points of failure.

Scrutinise external services. Orchestration is difficult, especially where there are multiple interdependencies. But it becomes even harder if the web services come from external suppliers. "If you are using a web service and it takes an hour to give you a response, then it isn't going to benefit the business," says Mike Lucas, regional technology manager of Compuware. Where possible, use service-level agreements.

Test for reliability and scale. In switching to an SOA, many organisations may be switching to a less proven, less reliable technology than they have used in the past. Cornell University research associate Werner Vogel's weblog on building distributed systems warns: "The current state of web services technology is very limited compared to distributed object systems. The latter is a well-established technology with very broad support, strong reliability guarantees and many, many support tools and technologies." Disasters can be avoided by modelling and testing.

Beware proprietary interfaces. The limitations of web services will encourage many to bypass standard interfaces to improve function or performance. This should be avoided where possible, because it significantly reduces flexibility. Lawrence Wilkes, technical director of advisor CBDi, highlights SAP's implementation of web services. "SAP has a web services interface now. If I access it, will I be agile and loosely coupled now? Well, no, because the web services exposed are still very, very specific to the way SAP works."

Keep it simple. The most common advice given by early adopters of SOA is that the key to successfully orchestrating web services is the same as in most developments - keep it as as simple as possible and closely allied to business processes.