SOA Success: Five Actions CIOs Say You Should Take - ' Retool the IT Department '

Success generally boils down to five action items, according to chief information officers and systems architects who have employed SOA as a software design practice. Those items include:

Action No. 1: Retool the IT Department

Organizations need to take a hard look at their IT shops before taking on service-oriented architecture projects. Developers will likely require retraining, and the department may need to rethink the way it assigns development responsibilities.

"You can explain this whole space in terms of enterprise computing, reusable components, and a better, faster construction methodology," says Toby Redshaw, corporate vice president of IT strategy, e-business and development at $37 billion Motorola Inc., based in Schaumburg, Ill. Service-oriented architecture is a straightforward concept, he says, but it involves a steep learning curve for those who deploy it. "It's a significant paradigm shift for [IT] shops," Redshaw explains.

The services approach revolves around the creation of reusable software components—services—as opposed to monolithic applications. Developers schooled in traditional practices will need to learn to break down coding into smaller pieces.

The trick is to get a core group of developers on board with services and let the practice spread from there. Tarrant County, Texas, which includes the area around Forth Worth, devised its own training program with help from one of its service-oriented architecture vendors, Progress Software Corp. Progress' Sonic ESB, an enterprise service bus, serves as the foundation of the county's service-oriented architecture strategy. (An enterprise service bus provides a messaging layer that lets services communicate.) Progress' Sonic ESB training provides an overview of SOA concepts and technical requirements, and covers such areas as enterprise-service bus development.

But retraining developers may not be enough to institutionalize services. The broader structure of the IT department may have to change from one that mirrors monolithic application development to one that facilitates the service design. Tech shops may need to divvy up assignments to different teams of developers, given the componentized nature of services.

The MedicAlert Foundation International, a nonprofit healthcare organization based in Turlock, Calif., split its developer team into two groups to better accommodate its services push. The foundation sought to build services and a security infrastructure—the means for governing who can access services—in which they could operate. Managers decided an individual developer shouldn't be assigned both chores, in light of the different skills sets involved. So MedicAlert launched two developer teams: one to handle security infrastructure, and one to write the organization's core business services, notes Jorge Mercado, manager of MedicAlert's service-oriented architecture and software architecture group. "We decided that developers accustomed to developing code should only be concerned with writing business applications or Web services, and not concerned and burdened with security," Mercado says.

Next page: Establish an Oversight Group to Get Results