Motorola"s three-year-old campaign to build an SOA has yielded deployment of 180 services so far, and is expected to expand to 1,000 by early next year, a company official said at the InfoWorld SOA Executive Forum in San Jose, California, on Thursday. "

The company anticipates that the number of services will ultimately top out at 1,500, said Toby Redshaw, Motorola corporate vice president for IT architecture, emerging technology, and e-business. He cited the competitive edge afforded by an SOA while also noting deployment issues.

"One-hundred-eighty doesn"t sound like a lot but that clearly puts us in the top 5 percent globally, maybe a little better than that," Redshaw said. Motorola"s SOA, as would be expected, relies heavily on Web services.

"We think we"re in a competitively advantageous [position] because we"ve been playing this for three years," Redshaw said. He also emphasized the benefits of "small agile" over "big slow" in business automation.

Brought into Motorola to turn around the company"s IT systems, SOA was to be the basis on which the company"s strategy relied. "Back then, we called it a service-based architecture," Redshaw said.

"We believe this will let us add business services [at a] two- to three-times rate of speed," Redshaw said. SOA also allows Motorola to do more with less, he added.

Citing the need for SOA, Redshaw said companies these days cannot afford to be less efficient with their computers than their competitors can. "Today, your company will get killed in four to five quarters," he said.

"It sounds like a light beer commercial, but [an SOA is] faster, it"s cheaper, it"s better," at providing a more coherent IT strategy, Redshaw said. Motorola also expects its IT suppliers to be supporting SOA.

Motorola"s SOA features business activity monitoring for Siebel and Oracle applications as well as a supply chain management system. Building an SOA allows IT staff to "drill down into the legacy spaghetti and harvest the gold," by expressing legacy systems as Web services used in a component layer, Redshaw said.

Deploying an SOA, however, requires critical components such as a UDDI directory and Web services security, management, and governance, Redshaw said. Although UDDI has been considered disappointing in enabling provision of Internet-based Web services directories, Redshaw is a believer. "If you don"t have a good directory to go find these things in, it"s "game over." I don"t care how good the other parts are," he said.

Web services security and management are important, given corporate priorities on security and the potential of destructive payloads in a Web services message, according to Redshaw. "[The] fastest path to get fired in IT today is a big security problem," he said. A governance layer, meanwhile, enables optimization in an SOA, Redshaw explained.

An SOA allows for team-based development, building of business projects based on existing processes and reuse of components. It also lets IT staff deliver exactly what business teams asked for, according to Redshaw.

SOA has had its drawbacks, Redshaw acknowledged. Examples include immature standards in early years, security challenges of loosely coupled architectures and performance concerns caused by loose coupling of software components and bandwidth-intensive XML. "The security issues are not small. You need some serious pros on your team to address this," Redshaw said.

An audience member said his organization is not yet using an SOA but is considering one to integrate legacy systems with new initiatives. An SOA can solve problems pertaining to information exchange among disparate business systems as well as address the need to provide services to multiple parts of an organization, said Lou Absher, data manager at the University of California, Santa Barbara.

"I do think the key ... is you have to have the rules of implementation and you have to refer back to them as you are going through this process," Absher said.

BEA Systems CTO Mark Carges also spoke this morning, emphasizing the transformational nature of an SOA.

"This is not something that happens overnight," Carges said.

SOA is intended to address technology "pain points", including providing more flexible architecture, application and data integration, and business process implementation. Other goals of SOA include boosting enterprise portal initiatives and enabling customized application development and composite applications, according to Carges.

Business pain points to be addressed by SOA include streamlining supply chains, more effective integration with business partners, and allowing employee self-service.

Challenges in SOA deployments include platform heterogeneity, message brokering, data silos, security, and lifecycle management, Carges said. Security and the issue of data silos can be addressed through security and data services layers respectively, he said.

Metadata and service-level agreements also are critical in an SOA, Carges said.

The true measure of an SOA is its ability to enable service reuse, Carges said. "At some point, someone has to stop writing code," he commented.