Software developers are problem-solvers, and developing or reworking an application provides an opportunity to wade deep into a problem and solve it with new code. In SOA, development is not about creating new software but composing software from available services. And when new services are needed, they need to be developed to solve not just the immediate problem, but to anticipate other uses in the future. This is a fundamental shift for developers, who will need training in service-oriented thinking as well as incentives to work in the SOA way.

“The more you focus on immediate tactical requirements, the greater the risk is the service won’t work well with other services,” warns consultant Thomas Erl. Risks include inability to scale, service contracts that are too rigid, and inappropriate levels of granularity.

Another issue is that services can introduce extra overhead, making performance management a more critical issue than in traditional development, says Kemper CIO Siever. “In SOA, you gain architectural simplicity but pay a performance penalty,” he says.

One way to lighten that penalty is to be careful about adopting an ESB (enterprise service bus), which typically adds considerable overhead. “Not everything needs to be on the bus,” he notes — especially services with few interactions. He also suggested avoiding the use of BPEL (business process execution language) engines, which are used to orchestrate services and may also affect performance. Ultimately, however, he expects vendors to overcome performance issues as they redesign their development and runtime tools based on increased SOA experience.

IT will need to create the right frameworks, methodologies, training, and incentives to help developers make the mental shift to SOA, says Steve Rogers, chief architect for North America at the Capgemini consultancy. It often helps to have a centralized IT group so the overall enterprise architectural perspective is maintained from project to project, and so reuse opportunities are easier to identify and take advantage of, he adds. When IT is owned by specific departments, turf wars over services are more common, Rogers says.

“It can be job security not to share,” notes Justin McPherson, a managing director at the consultancy PricewaterhouseCoopers.

A danger in how SOA is often presented — as rearranging existing services in some sort of assembly-line approach — is that developers may feel their work is less interesting and challenging, creating resistance to the SOA approach, warns The Hartford’s Ajjampur. In fact, he sees service development as more challenging, akin to playing chess, where you have to think many moves ahead to anticipate the likely moves of your opponent.

Back to intro | Avoiding vendor lock-in