If you ask 10 CIOs to define service-oriented architecture (SOA), you'll likely get as many different answers. Most, however, would know that it's about breaking down their software infrastructure into smaller, reusable building blocks to make application development cheaper and faster.

And Chris Curran has some advice for CIOs considering moving to an SOA: Make sure you build on solid foundations.

"SOA adds a whole new level of complexity," said Curran, chief technology officer (CTO) of Diamond Management and Technology Consultants in Chicago. "You have to have solid capabilities in project delivery and governance if you're going to handle integrating multiple services. Otherwise you're likely to fail."

One goal of SOA is the creation of composite applications made up of underlying services that snap together like Lego pieces, letting developers rapidly change applications as needed to deal with compliance issues or technological changes.

The most widely adopted implementation of the SOA concept to date involves Web services that use XML-based open standards to enable communication between existing applications.

As public-sector CIOs shift from SOA planning to implementation, some find that vendors and consultants have overstated SOA's short-term potential, leading them to underestimate the cultural transformation required in dealing with governance, security and finance issues.

A 2006 survey of federal IT decision-makers by the Merlin Federal SOA Coalition, a consortium of vendors, found that although 56 percent of federal agencies said they thought they would benefit from SOA, only 22 percent said they had participated in a successful implementation, with 78 percent noting partial or no success.

"There was a lot of hype about this new and emerging technology, and in many cases, the expectations exceeded where the adoption curve may have been," said Mark Zalubas, CTO of Merlin International in Englewood, Colo., which leads the SOA coalition. People building their first applications using the SOA framework can't yet tell whether what they've created will evolve or adapt, he added. "You won't know that until the third, fourth or fifth application you build."

The key to achieving the holy grail of SOA, he said, is to get to a critical mass of services available with new and interesting functionality. "I point back to the object-oriented model. Object orientation was hailed for its reusability, but it didn't really take off until there was a critical mass of objects to pick and choose from," Zalubas explained. "SOA is not going to hit its stride until there is a mass of business services to choose from. Having a registry listing one Web service is like having a Yellow Pages with one phone number in it."

The survey also asked about the challenges inhibiting governmentwide SOA adoption. Twenty-one percent of civilian agency respondents cited a lack of SOA knowledge among IT staff, while 28 percent of Department of Defense respondents cited interagency turf battles as the No. 1 impediment.

And just as there are myriad definitions of the terms "SOA" and "Web services," there is disagreement about how much real SOA development activity takes place in the public sector.

A 2006 Forrester Research survey found that SOA is the "hottest three-letter acronym in government IT circles," and that SOA adoption is stronger in government than in the private sector. But Ron Schmelzer, senior analyst at Baltimore-based ZapThink, a research firm specializing in SOA, said adoption varies considerably at different levels of government. At the federal level, there's been quite a bit of activity because the Federal Enterprise Architecture basically mandates large agencies to start facilitating information sharing.

"At the state and local level, it's been more patchy," Schmelzer noted. "Local CIOs don't tend to stick around long enough to see something like this through. This is not a two-year project, so staying power is an issue."

Schmelzer also said that SOA doesn't make sense for everyone. If