What You Want Your CIO to Know (Continued)

SOA Challenges Ahead
Although much of the hype around SOA tends to make it sound like a done deal, you'll want to point out to management that work remains to be done in several areas. That includes evolving standards, including some important security standards. Legitimate questions about performance also arise, as well as management of Web services and SOAs themselves.

Performance is a common issue that comes up regarding Web services, and by implication service-oriented architectures. Does moving to an SOA, with its web of loosely coupled services and heavy use of XML, mean network performance will suffer? After all, by their nature, loosely coupled Web services will have more overhead than their tightly coupled counterparts. Also, Web services' use of XML tends to mean larger messages. It all adds up to slower-moving traffic—and more of it.

Most analysts and observers agree that hardware will continue its historic pattern of more processing power at lower prices, thus keeping up with increased traffic and more complex software demands. But performance, and your infrastructure's ability to handle the associated additional overhead with Web services, is definitely something to keep in mind during an SOA design.

For starters, you'll want to steer management to consider where in your organization an SOA makes sense—and where it doesn't. Many applications don't need super-fast response times. In cases where they do, the loose coupling implicit in an SOA might not be the best approach.

It comes down to using SOAs appropriately. "They're especially good when you have changing business requirements," said ZapThink's Bloomberg. "But they're not good when you have very high performance requirements—I wouldn't want my anti-lock braking system to be a service-oriented architecture. I want it to be tightly coupled and to respond in milliseconds."

According to consultant Doug Barry, who has written a book on SOAs (see the sidebar, "SOA Resources"), good design makes the difference. Because an SOA tends to mandate sending large, somewhat slow messages, your Web services and SOA design should address that—for one thing, by considering the granularity of services, Barry suggested. For example, a good design ensures the network isn't sending numerous small XML messages back and forth unnecessarily. Organizations that previously used DCOM or CORBA dealt with this same design issue, he pointed out.

Performance questions go back to the need for overall planning and organization as you move to Web services and an SOA. "You can architect [the system] poorly, and it will still work. But it will come back to haunt you," according to Michael Liebow, vice president of Web services for IBM Global Services. Precisely because Web services are bandwidth-intensive and potentially resource-demanding, "you need to be mindful of their impact on your organization," Liebow said. "Technically, they're not elegant. They're heavy, they're resource hogs." Design with that in mind.

Security, always an issue, is no more or less a concern with Web services and SOAs than elsewhere in your enterprise. You can reassure management that just as elsewhere in the organization, security depends on careful design and implementation. In fact, Bloomberg argues that security can be tighter with an SOA, because "with SOA, it should be handled on the enterprise level and fully policy-based. If you get that right, you'll be more secure than in doing security on a silo basis."

Developing security standards are important, so you'll want to help your company keep an eye on the premier security standard for Web services, WS-Security, and others that will evolve within that framework. WS-Security is a fairly mature standard and can handle complex authentication and encryption, but more security standards are in the works.

What about management? Who keeps track of all of these services, running anywhere across your company or anywhere in the world? Who's responsible when something breaks? Eventually, the promise of a well-designed SOA is less management, not more. "If you build an SOA properly," according to ZapThink's Bloomberg, "operations management should be simpler. Your infrastructure should be metadata-driven. Instead of all these different instances of functionality and business logic locked up in all these different systems, where you need special technology to access it, the goal is to have metadata that describes these systems—and the metadata can be managed in a central way."

On some levels, management simply isn't an issue yet because most companies don't have enough Web services in place. When they do, according to Bloomberg, the software tools to help will be available—a rare case of technology actually preceding the market.

Once again, a well-designed and easy-to-manage SOA comes from careful planning. "You're not going to get around putting some thought into this," Grand Central's Linthicum warned. "You've got to do your homework up front—don't just start throwing technology at it."