Ask anyone in charge of constructing an SOA (service-oriented architecture), and they'll tell you that the hardest part isn't the technology; it's redrawing the business processes that provide the basis for the architecture -- and the often contentious reshuffling of roles and responsibilities that ensues.

Many SOA practitioners say that, so it must be true. But the technology part isn't necessarily easy, either. After all the planning and strategising is complete, services and their messaging infrastructure must be provisioned and managed, alongside whatever platforms, applications, and systems are already in place.

The ultimate objective of SOA is a supremely agile infrastructure, where IT develops composite applications atop of a layer of abstraction that spans multiple platforms and domains across the enterprise. But nobody can "boil the ocean" and achieve that goal all at once. Practical SOA initiatives begin with a related set of business processes that would clearly benefit from greater flexibility -- where market conditions are in constant flux, for example, or new services must be deployed on the fly for competitive reasons. At some point that top-down approach meets the bottom-up reality of existing software assets and infrastructure.

When that rubber meets the road, technologists must make key decisions about the platforms on which to build services, as well as how those services will be exposed, managed, and mediated. Some companies may opt for an ESB (enterprise service bus) to connect services, whereas others may focus on standards-based services designed for maximum reuse. Examining the decisions companies make in the real world provides valuable lessons for those who actually need to build -- rather than just talk up the benefits of -- an SOA.

Building, exposing, and monitoring services

Choosing a platform on which to build services is probably the easiest decision IT faces. When cooking up services from scratch, most organisations simply go with their developers' strength, as Web service creation tools have matured across all the major development platforms, from Java app servers to .Net on Windows to COBOL on z/OS. When exposing the functionality of existing applications as services, however, some companies also use ESBs as a platform because services can be provisioned via configuration rather than coding.

What matters from the start is building services in accordance with Web services -- and in some cases Java -- standards, says Martin Moseley, chief architect of integration architecture solutions at Intuit. Standardising on XML and SOAP means that you can use the widest possible range of tools to orchestrate services. John Turato, vice president of technology at car-rental company Avis Budget Group, is on the same page. As he puts it: "We avoid the add-ons and stick to the vanilla."

After a service has been built and tested, developers publish it in a registry so authorised folk can discover it and other services or applications can consume it. Today, most registries are coupled with repositories that point to metadata about services -- including policies governing service development, such as security design rules, and run-time governance parameters, such as SLAs or expected load.

"We recognised at the outset that we needed a repository tool," says George Glass, head of strategy and architecture at BT (formerly British Telecom). But repository tools didn't really exist when BT's SOA efforts started, so the company used its Borland design tools as the repository, exposing the services to business analysts through a Web interface it created from scratch.

The Hartford publishes available services in a UDDI registry but uses Excel spreadsheets and a database for its repository, says Ben Moreland, director of foundation services at The Hartford, an insurance company. As part of its enterprise-wide reference architecture effort, The Hartford is looking at a more formal repository system. Moreland is glad his company waited because current registry/repository products now handle metadata effectively. "So now we can create a better solution than if we jumped in early," he says.

"Much faster than you thought [after you deploy services], you'll have people using them," says James Barrese, vice president of systems development at eBay. "So you need the basic infrastructure in place: a central directory of consumers and publishers, detailed logging of operations, and operations monitoring technology like dashboards."

Repository metadata about services generally describes what should happen rather than what's actually going on. In an SOA, real-time service performance, availability, and usage must be monitored -- often with the help of service management products provided by vendors such as Actional (recently purchased by Sonic Software), AmberPoint, or Blue Titan (recently acquired by SOA Software). These solutions also support version control, fail-over, and message logging, providing a centralised view to gauge the overall health of a network's worth of services.

eBay includes QoS parameters in its service templates, so rate-limiting and logging are built in. As Barrese puts it, this functionality is "abstracted from the engineers" to ensure it's implemented universally and consistently. Dashboard services monitor logs to detect performance issues, and services that are overburdened know it and can request that a clone service be initiated or an IT analyst be notified.

BT follows a similar approach. "All services have measuring and monitoring built in within the XML message set. All transactions are traced, so we can measure at every stage," BT's Glass says. A combination of homegrown and commercial monitoring tools analyse the data "footprints" generated by services, alerting BT when mission-critical services fail to meet service-level commitments. The services' built-in logging functions can be turned on or off, allowing BT to monitor services more closely when desired, such as when first deployed or when performance issues crop up. IT can also perform historic analysis on service logs using BI tools.