SIDEBAR: Four Challenges

The development of service-oriented applications requires the following steps:

1. UNDERSTANDING which processes can be turned into services.

2. BUILDING a foundry of application processes. This will come increasingly from business applications that are designed as a set of services.

3. ESTABLISHING the granularity of services at the right level to ensure that services are effectively reusable. Too much granularity makes services too specific to be used; too little granularity makes them too general to be used.

4. FOSTERING a reuse culture is essential to consistent, repeatable success in capturing and using business processes. It enables an organization to deliver processes as a well-defined set of services and to make those services easily available to developers.

Source: Daryl Plummer, analyst, Gartner (US)

SIDEBAR: Managing the Building Blocks

You could have hundreds of Web services. Here's how to make sure you can organize, catalogue, find and reuse them

Danske Bank A/S's trailblazing work to build a service-oriented architecture had got so advanced that it exposed more than 1000 services from its mainframes and application servers. But the Copenhagen-based bank found itself in a frustrating predicament.

"We couldn't find them," says Claus Torp, the company's chief architect.

The problem threatened to wipe out one of the main benefits of service-oriented architectures (SOA) - reuse. So Danske set about revising its concept of a service, refining its repository and establishing a governance process to enforce best practices.

The result was a collection of 140 services that is far more manageable.

An in-depth look at several SOA pioneers shows that the steps Danske Bank took are key to a company's ability to reuse code, build applications with greater speed and efficiency - and ultimately save money. But it's not easy, and the implementation sequence is important. Sun Microsystems, for instance, built a registry and set up an architecture review board. But the IT department is just now circling back to do a closer examination of Sun's 80 to 100 Web services.

Karen Casella, an IT director at Sun, recommends that a company starting down the SOA path first look at its business requirements and identify which Web services are needed. "We learned the hard way," she says. "We put some of the infrastructure in place before we completely understood what we needed to have in play."

Companies need to figure out which business processes can be turned into services, carefully design and define the services and distinguish them from components.

When Danske Bank began building standard interfaces to expose its legacy programs, it defined a service as "one function". Now it describes a service at a higher level, as a logical grouping of functionality and data, such as "customer" or "account". The company's 140 services are each composed of about 10 "operations", or components, that are essentially more granular services. There are currently more than 1365 operations. Danske expects to eventually have 250 services.

How well a company can break down its business processes and application functions into services will determine the level of flexibility and reuse it gets, Torp says. Danske uses modelling tools to develop logical maps of the functional building blocks and business processes. Then it matches the business processes to the services to make sure it has solved the right problem. "A lot of doing service-oriented development is making sure you can run different business processes on top of the same service building blocks," says Torp. "If you want to be effective, you have to make sure there is only one place to do the same function."

Cendant Corporation's Travel Distribution Services division spends a considerable amount of time determining the optimal granularity of its services and service components, according to CTO Robert Wiseman. A service is something that can be called externally through Cendant's business domain model, dubbed Rosetta Stone. A service component, such as logging, is called only internally. So a "get hotel" service might call several low-level services, such as a latitude/longitude "destination finder" that the company makes available to customers. But Cendant's currency converter is a component, since it currently isn't exposed to customers.

Cendant expects an ongoing project to extract components from monolithic applications to have a big payoff, Wiseman says. For instance, passenger name record (PNR) is a basic unit of data used by booking engines and global distribution systems such as Cendant's Galileo. By making "Super PNR" available as a service, the IT department won't have to maintain six or seven instances of PNR in different applications.

The Hartford Financial Services Group built pockets of Web and other services over three years ago, but its enterprise-scale SOA work didn't start until 18 months ago. A good candidate for an enterprise service is one that two or more applications need, says Benjamin Moreland, Hartford's manager of application infrastructure delivery. "But not everything should be a service," Moreland warns, noting the potential performance hit from exposing services.