Taking the horror out of SOA

Do deliver the SOA backplane first. The first SOA project must deliver measurable benefits, but must also be a test bed for an initial set of SOA-enabling technologies. To effectively support application projects the SOA backplane must be implemented, tested and validated against a sensible proof of concept before application development starts.

Don’t underestimate the amount of testing required. Given the many moving parts in an SOA project, integration testing is particularly important and at least 25 per cent of the development effort should be allocated to this activity.

Don’t be afraid of monitoring too much. The whole SOA backplane as well as the service and applications must be instrumented for monitoring and management from the start. Retro-fitting is incredibly difficult and expensive.

Don’t forgo governance – or technology. Lack of governance is a major cause of SOA failures. Governance – the processes, rules and responsibilities that drive organisations through decision making – is paramount for SOA initiatives, but technology is also important. In the early stages of SOA adoption, organisations do not need to enforce rigid governance processes and do not even need to set up complex technology platforms. However, as the reach of SOA grows to support multiple projects, the complexity and sophistication of the supporting technology infrastructure multiply risks of failure due to bad technology decisions.

Don’t overspend or underspend on any one aspect. Balance investments at every stage of adoption. In the early stages of SOA, technology and investment should be kept as low as possible to make it feasible to build a reasonable return on investment. It does not make sense to spend a lot of money on application infrastructure components that are unlikely to be used. Similarly, setting up overly complex and rigid governance processes could kill an SOA initiative in the cradle – too much governance can be as deadly as too little of it.

Don’t drop the SOA ball, even in a tough economic climate. Under the pressure of doing more with less, some IT organisations may be tempted to scale down or postpone SOA initiatives. Although this may make sense in some cases, SOA can help to reduce costs and, looking further ahead, restart operations quickly when things improve.

Last point: SOA benefits don’t happen by magic. They come through hard work, discipline, commitment, flexible planning and change management processes. SOA requires a change in the culture of the IT department. Project leaders and developers need to get used to thinking about re-use, which can be a massive change in mindset. Change does not happen spontaneously. It must be encouraged through a carefully crafted system of incentives to reward ability to develop re-usable services and the willingness to re-use services developed by somebody else. Even in the era of SOA, a bit of “stick and carrot” often proves the most effective way to make change happen.

Massimo Pezzini is a vice president and fellow at analyst Gartner.

Gartner analysts and SOA users will explore how SOA has changed at the Gartner SOA & Application Development and Integration Summit 2009 in London on 24-25 June. For more information, visit www.europe.gartner.com/soa