Web Services: Managing the Building Blocks

Computerworld - Danske Bank A/S's trailblazing work to build a service-oriented architecture had gotten so advanced that it exposed more than 1,000 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 Inc., 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."

The Services

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 1,365 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 modeling 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."