It's all about the architecture

When down in the trenches, it's easy to get caught up in tactical decisions such as whether to buy an ESB and from whom. But IT needs to be wary of letting the tail wag the dog. The whole point of SOA is to create an architecture that supports a desired end state of streamlined business processes, but with a level of flexibility in rearranging those processes missing from old-fashioned "re-engineering" projects.

"There's a fair amount of misrepresentation about what SOA is or is not. But none can be successful without thinking about IT and business together," says Sohrab Kakalia, vice president at systems integrator Infosys.

The architecture describes the standard aspects of services to deliver those business processes, including governance and policies, process management, the business logic itself, data management and access, definitions within and interfaces between services so they cooperate easily, and a messaging framework -- typically tackled in that order. "These layers should exist in every service," TekFinancial's Adiletta says.

And you can't even worry about the service until you understand the business processes they are delivering. "You have to think about standardising the business processes first," Avis Budget's Turato says.

Britain's telecom giant BT has developed 14 service platforms. "Each platform has a set of services that have operations associated with them -- like a method in object-oriented programming. A service resides in one and only one platform," BT's Glass says. And each platform has an architect assigned to it, who ensures that all services -- whether developed in-house, provided by a partner, or bought from a vendor -- adhere to the architecture. To enforce that compliance, if a BT project doesn't meet the architecture, the development team loses a quarter of its annual bonus.

To provide business flexibility and consistent process execution, "the architecture is independent of any technology implementation. Newer technologies may come along and be deployed, but the architecture is sustainable; the SOA strategy stays," GM's Zhang says.

With a laser focus on the underlying business process, SOA discourages technological dependencies that may later limit a company's ability to change or add business processes. In addition to a strategic decision about architecture, successful SOA deployment relies on IT routinely recognising project opportunities for a reusable service or business process.

"It's not a big bang that we then go off and do," Avis Budget's Turato says. Anyone who thinks that the use of a technology such as SOAP or WSDL to deliver a function or integrate applications means they're doing SOA is missing the point, Intuit's Moseley says. The technologies are a means to an end, not the end itself.