Experts and advisors promoting the many business and technical benefits of the service-oriented architecture will give all sorts of good advice: involve the business manager; don’t use services that are too fine; test all services in advance.

But above all, they advise that the modern SOA requires a planned, architectural approach. The complexities of trying to link together multiple components, business processes and web services – some internal, some external –

are simply far too great to attempt without first laying down a solid, organised, foundation.

This requirement immediately puts up barriers to implementing the SOA. First, the architectural approach demands a good understanding of a complex, immature and shifting marketplace in products, concepts and standards. Second, effective implementation requires a certain amount of re-engineering of existing systems – although this can be done over time.

And third, for most customers, an effective SOA implementation requires a big investment in new software products (see article Implementation tools).

The fundamental and revolutionary idea of the SOA is that functions and business processes can be exposed as services – effectively separated from the bigger, perhaps monolithic, applications in which they may be contained. These services can then be ‘loosely coupled’ with other systems to create end-to-end processes or even completely new composite applications.

At the architectural heart of this will be one or more products that make up the service backbone into which all the various functions, delivered as web services, link.

This backbone has many different names: the web services orchestration layer; the services integration layer; the enterprise service bus; the service infrastructure layer; the web services management platform.

The functions of this layer are many: it must manage security, interaction of different web services, execution of composite (multiple service) applications, workflow, management and control, analytics, ensure performance, and integration of different and often non-standards based systems.

Several different types of products are being used to address these needs. They include traditional integration brokers, enhanced application servers, new pure play web services orchestration tools, and the emerging technology known as the enterprise service bus (ESB).

The role of this backbone product or product set is viewed as so vital by the leading vendors that a huge battle for control of this sector is underway.

SAP, for example, positions its NetWeaver product in this role; Microsoft has its .NET framework and Biztalk Server, IBM with WebSphere, BEA has its WebLogic suite and its “liquid computing” message, and there are many others.

The architectural and product issues are further complicated because the service orientation approach embraces new development, legacy systems, external services and, of crucial importance for most large organisations, it must embrace existing, strategic business applications such as the ERP system.

In each case, existing products need to reviewed or refreshed in order to ensure that they conform to the SOA edict – that functions should be delivered as loosely coupled services that are either whole business processes or coherent reusable sub-processes.

Analysts are now advising customers to be extremely wary of buying any business application whose supplier does not have a strategy for service-enabling their products. This means that functions must be exposed in a way that they can be accessed as a web service.

This requirement will certainly cause difficulties. Many legacy applications, for example, scarcely have accessible interfaces at all. This is where specialist suppliers such as WRQ, Seagull and Micro Focus can help. At the same time, analysts and some suppliers are busy warning that the web services aspect of the SOA has been oversold. Most businesses have established communications between their systems that work extremely well – using standards such as Corba, Com+, RPC, EDI, JMI and many others. Replacing these may not make sense – so any architectural platform should be able to support non-web services interfaces.

It is notable that almost every published case study about SOA in action involves some use of these older, ‘legacy’ standards. In addition, some of these applications may never be suitable for service orientation. As Gartner’s David McCoy says: “Beware extremism… Not all software should be service-oriented.”

A final architectural consideration relates to how new ‘applications’ or even automated business processes should be created and managed. At present, software that is introduced into an organisation usually falls into one of two categories: a new, bespoke application; or a packaged application, probably configured customised the user’s needs.

But increasingly, new applications will be made from existing services or components. Sometimes these will consist of large blocks of functions and so will be labelled ‘composite applications’; at other times, these will consist more of fine grained components and services and so will considered to be new.

Ultimately, as the various products converge, there may be little difference between the tools used to put these applications together. But it is clear that a management layer, which enables business people and software architects to assemble and monitor these applications, will also be needed.

The SOA is simple in concept, but gets more and more complicated as the project progresses. This is why it will be vital to create a competent team to manage the process: good architecture requires trained architects.