Jon Collins, Computing
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
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.