Performance, Security and Run-Time Governance

When ESBs aren't enough for your SOA, XML appliances fill in the gaps.

1 2 Page 2
Page 2 of 2

What does matter is engineering your SOA efforts, taking the architecture and business processes and then figuring out the implementation requirements, acceptable trade-offs, likely data and process flows, and management and performance needs. With those understood, you can use whatever technologies you like to construct the actual services and supporting infrastructure.

“SOA deployments should follow a federated model, of incremental deployments in a loose way, but with the same goals and direction,” consultant Hurwitz says. “Start off with a set of rules on how you do SOA, so people have the same philosophy and approach in mind on each project.”

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 standardizing 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 recognizing 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.

Eric Knorr is executive editor at large at InfoWorldGalen Gruman is contributing editor at InfoWorld.

This story, "Performance, Security and Run-Time Governance " was originally published by InfoWorld.

Copyright © 2006 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
7 secrets of successful remote IT teams