Changing Developer Culture
The last thing developers want are SOA "governance cops" telling them what they can and can't do. To change the individualist developer culture, create the right incentives.
“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.
Galen Gruman is contributing editor at InfoWorld.



