Message Received?

Companies that require highly reliable Web services are building in their own guarantees.

1 2 Page 2
Page 2 of 2

Danske also has a structured library for its services and their corresponding interfaces. The library also houses information about the relationships between its functional and process models. There's even a librarian that developers can call for help. But the library didn't launch until a year ago—"a lot later than we should have been doing that," Schleidt says.

Governance

When push comes to shove, a governance body can help a company stick to its SOA principles. Danske Bank has steering committees in 18 different business areas for product, process and IT development. But when business managers are anxious to beat the competition, they're sometimes tempted to forgo the generic SOA approach if it takes longer to complete.

"You need a governance process where you can handle situations like that," says Schleidt. "We always have the time to change things afterwards, so why not try to turn it around and do it right the first time?"

The quick-hit approach can have long-term consequences. Danske now has two personalization engines, four interactive customer communication services and four payment-handling applications, Torp says.

Two years ago, The Hartford formed a central group called the Property and Casualty Architects Collective to examine how it would adopt a SOA across the enterprise. The group put together a reference architecture outlining recommended approaches, practices and products to be used in a particular context.

"It's about shared architectural thought and reuse of thought processes. That's where the hard work and value is," says James McGovern, an enterprise architect at The Hartford.

A separate application infrastructure delivery group is responsible for selecting and implementing the management platform, business process engine and UDDI registry, as well as making sure the WSDL files used to describe service interfaces conform to standards. An architect not involved with a particular project reviews the project's application design to make sure services aren't duplicated.

At Cendant, project managers have that responsibility. The service name and input and output fields are accessible through an XML-based layer in its Rosetta Stone business domain model. A single group is responsible for updating the business domain model.

"This is how we control reuse," Wiseman says.

If a business domain owner spots a service already in the registry, the service is flagged as a candidate for reuse. A SOA governance board, largely consisting of IT managers, then takes over. Developers need not apply.

"The programmer is the last person that should make the decision," says Wiseman. "They will always want to write something new."

1pixclear.gif

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 Inc., Stamford, Conn.

Special Report

Web Services Hurdles

Stories in this report:

Copyright © 2004 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
  
Shop Tech Products at Amazon