Think small. Prashanth Ajjampur, vice president of architecture at The Hartford Financial Service Group Inc., encourages beginners to kick off their service-oriented architecture with a project of manageable size. That way, an organization can quickly demonstrate service-oriented architecture's benefits and win management support for future projects. But while initial projects should be modest, adopters should keep the big picture in mind as they roll out new services. "We start with the basic premise that we will have a lot of reuse," Ajjampur says. "How do you ensure that, without understanding the broader business requirements?"

Don't neglect security. Services carry payloads and, like explosives, can do damage if mismanaged, says Toby Redshaw, corporate vice president in Motorola Inc.'s information technology organization. Communications between services and other applications can occur through eXtensible Markup Language messages, which can be vulnerable to attacks.

Educate the stakeholders. To make service-oriented architecture click, organizations need to educate both the technology and business sides of the organization. Technical staffs need to be sold on the efficacy of SOA, while business representatives should be brought up to speed as well. Concentrating on both will facilitate discussions between the two groups and unlock the value of service-oriented architecture much more quickly.

Keep legacy systems in mind. SOA may involve new software development, but adopters shouldn't forget their old standbys, says Kevin Bohan, chief information officer at data-integration software maker Proginet Corp. Older applications can be exposed as services—via point-to-point integration, messaging queue tools, or middleware, for example—and link to the broader architecture.

Don't underestimate the testing task. Since a service may end up in several applications, a change or a bug fix in one service can have a ripple effect. Organizations deploying services must understand all the dependencies and test accordingly.