What Are the Challenges?

Security is a big one. "It’s always easier to secure a closed system than an open architecture," says Silk Road’s Bass. CIOs must deal with the lack of security standards for Web services (see "Calculated Risks," www.cio.com/printlinks). To overcome some of these security roadblocks, Bass advises that companies move slowly when setting up an SOA, focusing first on business processes that don’t require a high level of security.

Trying to manage the complexity of a services configuration can be tricky as well, says Bass, and requires a good SOA governance model. For example, if you have nodes on a network that are service-oriented and 100 people are using a certain interface, how do you communicate with those users if someone decides to change the interface?

Another issue is network monitoring. "As we create the capability to orchestrate complex Net-centric business processes in a service-oriented architecture, we also create complex monitoring and auditing requirements," says Bass. For instance, when a transaction goes awry on a service-oriented network, which could involve multiple service providers, finding out what went wrong or where the transaction dropped or whether someone put bad information in the network can be a challenge. "The current Web services technical standards are only beginning to scratch the surface in making these lofty service-oriented distributed collaboration, process orchestration and monitoring goals a practical reality," Bass claims.

Finally, there’s the cost issue. Building an SOA isn’t cheap; reengineering your existing systems architecture is going to cost some serious money. It also requires significant human capital, including business analysts to lay out the business processes, systems architects to turn processes into specifications, software engineers to develop the new code and project managers to track it all.

Are There Any Generally Accepted Best Practices for Building an SOA?

It may sound obvious, but having a blueprint for your SOA is critical. It’s very easy for companies, especially large enterprises with disparate operations, to buy new technologies or integrate applications without regard to how they fit into the overall plan. The challenge in building an SOA is to keep people?including both IT and business-side staff?focused on the architecture goals.

IT execs will also need to identify the right level of service to provide. And those services shouldn’t have too fine a granularity?that defeats the goal of services, which is to function at a higher, business-process level. Too narrow a focus creates a need for more services, which increases development time. And in the worst case, too many services can flood a network. You should also employ an SOA where it will do the most good. Bass notes that quality of service needs to be taken into account when implementing SOAs. He says that a loosely coupled architecture is good for systems that don’t require near-real-time responses. Pick systems where, if information doesn’t get where it needs to be on time, the consequences are minor, not catastrophic. (For example, an SOA-based air-traffic control system would be a bad idea.)