Taking the horror out of SOA

SOA has been the victim of montrous hype

Why SOA makes sense

It is more than 75 years since the story of Frankenstein’s monster first hit the big screen, with Boris Karloff’s iconic character spawning an entire genre of movies. In the film, a mad doctor assembled stolen body parts and brought the result to life in a storm of electricity. The monster that emerged was left to discover for itself that it was not quite human, before heading out on a rampage of self-discovery.

One is forced to wonder whether similar techniques were used to create the bandwagon we refer to today as service-oriented architecture, or SOA. In principle, it is difficult to gainsay the benefits of adopting a software architecture oriented around the principle of services. SOA brings together a number of old but rather fundamental concepts:

• The role of middleware to break IT silos and support distributed processing, information sharing and service delivery.
• The need for modularity in well-formed IT systems ­ – a principle that goes back to 1975 and probably before.
• The importance of standardisation in the way that application elements communicate with other systems and people.
• The continued tendency for commonly used functionality to become commoditised and move into the platform.
• The need for ”joined-up thinking” between the development of business-facing IT services, and their subsequent deployment, operation and
  management.
  

These are all tried and trusted ideas, which bring a number of benefits that are reflected in SOA as a whole. When Freeform Dynamics researched this last year, we were careful not to box respondents into a corner by making assumptions about what they saw as SOA. On analysing the results we found that respondents who had already adopted SOA were seeing more flexible applications and faster time to delivery.

What is not to like? In practice however, a number of agendas and vested interests, hype and due diligence failures have resulted in the tragic-comic situation we face today. SOA discussions have been seen as a lever for product sales and/or business consulting, neither of which is always necessary or indeed desirable. SOA-as-common-sense has been corrupted into SOA-as-bandwagon ­ – a monster, despite having all the right bits in the right places.

SOA has been overhyped, oversold and set up to fail. When we see headlines decrying failures of strategic SOA projects we want to weep ­ – in many cases, organisations that required some straightforward extensions to their existing architecture were up-sold into putting in place unwieldy architectures that proved impossible to deploy. It’s a bit like a town needing a bypass, but somewhere along the way the project became Milton Keynes.

Which brings us to recent attempts to kill SOA. While such efforts may be for the best possible reasons, film aficionados will know it is impossible, not because of some esoteric storytelling issue - though it generally requires beauty to kill a beast, a factor sadly lacking in IT - but because the industry has too much invested in the franchise.

And so, the SOA bandwagon will continue to lumber on regardless of what common sense might suggest. There will always be Dr Frankensteins around peddling their dubious creations ­ – we’ve seen event-driven architectures and web-oriented architectures, both of which have been created to supersede SOA in some way. But just as SOA should never have existed as it does, neither should it be replaced by another half-cocked attempt to force half-cooked ideas onto the market.

What would we advise? Essentially, to ignore the hype and get on with delivery. As one commenter on the backlash to the backlash (you can’t make this stuff up) said: “If we weren’t developing applications today using SOA principles and best practice, how the heck else would we be doing it?”

The last thing any organisation should do is to reject SOA outright ­ rejection efforts should be focused on the bandwagon, not the base principles.

In these cash-strapped times there is little room for highbrow strategies in general, never mind ones that have such a troubled history as SOA. However, by focusing on the principles behind SOA, there is plenty of scope for tactical opportunities to reduce waste, increase efficiency and deliver higher levels of service. Here’s the rub: by keeping attention on what can be delivered tangibly and practically, a spin-off benefit is that oxygen is denied to the SOA bandwagon. Perhaps there is a way of killing the monster after all.

Jon Collins is managing director of analyst
Freeform Dynamics.

Read the blog here: http://freeform.computing.co.uk

SOA do’s and don’ts

Implementing a comprehensive service-oriented architecture (SOA) infrastructure can be a daunting and expensive task. Architects, developers and IT operation specialists face steep learning curves as a lot of application infrastructure technologies need to be purchased, deployed and operated.

To minimise costs and risks and maximise benefits, Gartner has identified some critical do’s and don’ts.

Do analyse short, medium and possibly long-term requirements to design an SOA-enabling application infrastructure – the so-called “SOA backplane”.

Do select vendors that can provide as much as possible of the SOA backplane, but in a modular, incremental fashion. This allows organisations to buy what they need when they need it and minimise the initial investment to what is needed to support the first few projects. Further investment can be justified on a project-by-project basis.

Do consider adopting SOA backplane building blocks in the form of open-source technologies or cloud/software-as-a-service services. Although adoption of these kinds of building blocks might be more challenging from a technical perspective, it can turn some capital expenditure into operational costs, which are usually easier to justify.

Do delegate. Segregate duties so application design teams take care of service consumers and service providers while the infrastructure design team is responsible for establishing and maintaining the SOA backplane. Such a team can be easily converted over time into a fully-fledged SOA centre of excellence.

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