Dispelling the myths about SOA
What exactly is Service-Oriented Architecture (SOA)? In this business which sometimes seems to take pleasure in making things more complex than they need to be, it can be difficult to tell. The IT industry has frequently been compared to the motor industry, with all of its innovation, commoditisation and general impact on the world at large. Just as valid perhaps is to compare IT to the earlier days of the pharmaceutical industry, before such obligations as clinical trials and, well, actually proving a drug could do what its manufacturer said it could do. For all the flashing lights and so on, our illustrious business has retained its fair share of snake oil salesmen (and nobody is immune to this – just remember Y2K).
Against this background, it is perhaps inevitable that such complex constructs as SOA should be castigated as over-hyped and under-achieving. The purpose of this article is to pick apart some of this criticism, dispelling some of the myths to help organisations take advantage of the benefits of SOA, without being distracted by the marketing hype. First however, it’s worth reviewing a bit of history. Without spending too much time wallowing in past nostalgia (of course the mainframe guys got it all right, deal with it), let’s recall from whence SOA has come – which of course is the same as working out why we are now in the position we’re in.
SOA is the conjunction, convergence or collision of several technological trends – to the extent that the forbears of each still believe they “own” it. Here are the major themes, though of course these brief categorisations do none of them justice:
• Object orientation and component based development – from which we
have the principles of cohesive units of service, delivered through
code via a defined, externally visible interface.
• Middleware and Enterprise Application Integration (EAI) – giving us
both the understanding and the wherewithal for applications to
communicate, and dispensing with the idea of silo-ed apps that work in
isolation.
• Internet-based applications and Web services – providing the globally
accessible networking infrastructure and simplified, standardised
protocols to enable units of software (apps, components, web scripts)
to communicate with each other, wherever they are.
• Enterprise Architecture – bringing up to date and distilling the
capabilities of business and systems analysis, process and data
modelling, to understand business needs and map them onto IT
capabilities in a way that treats IT as an interconnected framework,
not as individual components.
All of these combine to provide facets of what we call SOA. Historically however, while each of these categories has seen much progress, against the background of a marketing-led IT industry, we have also seen a number of myths come into being around SOA. Let’s look at them.
Myth 1: SOA is a product
Of course (goes the cry), SOA isn’t a product, it’s an architecture, surely that’s what the “A” in SOA is referring to? This may be so, but (as should be unsurprising in this marketing-led industry that we live in), vendors have done what they can to define SOA in terms of what they can package up – otherwise of course, they have nothing to sell. That wouldn’t be a problem in itself necessarily, but the result is that SOA becomes a competitive stance, with one vendor’s SOA being better than another’s, and so on. In this case vendors and other pundits have chosen the wrong three letter acronym to try to hype.
Rather than trying to pump up SOA as a product, an alternative strategy can be to pick a product category and sell it as the SOA silver bullet: unsurprising that the four trends listed above are the source of many such products. We’ve seen this for example, with the Enterprise Service Bus (ESB), which is an evolution of the EAI capabilities of the past. Useful it may be to support an SOA deployment, but ESB is not SOA any more than SOA can be simplified to something as tangible as ESB.
Myth 2: SOA is different to the past
As we have already seen, SOA is a point on a continuous evolutionary path, that builds on the key strengths of a number of areas of IT. While it does offer a logical next step, that doesn’t mean that SOA in some way needs organisations to throw everything away and start again – which of course, would not be an option for most organisations, even if it were necessary.
SOA offers a way to think about how application elements can communicate, a framework to enable this, and an approach to help us achieve such intercommunication in a way that will be the most useful. None of these elements are new – what is perhaps different is how we are thinking about them all in one go, rather than piecemeal.
Myth 3: SOA is the same as the past
Paradoxically of course, Myth 2 doesn’t mean that we want to hang onto everything that we relied upon in the past. The co-ordination we wish to achieve through SOA requires a level of joined-up thinking that encompasses all dimensions of IT, not just development, integration, operations or whatever. From their historical standpoints, certain groups have sought to define SOA in terms that make sense only for them – developers for example, which see SOA purely as a set of mechanisms or standards, or architects who see SOA as being more about alignment between IT and the business.
At its most fundamental roots, SOA starts and ends with the concept of “service” – which is the thread binding together all areas of IT and its delivery. For SOA to succeed, it is as much about the operational side of IT getting its house in order (to deliver services scalably and consistently, for example), as it is about developers and architects defining, building and integrating applications in a service-oriented way.
Myth 4: SOA has been and gone
This is a myth fabricated entirely by people who don’t see SOA as anything more than a marketing construct – which, for some peddlers of Myth 1 for example, it is. Overheard for example, was a conversation between IT marketing types: “What’s next? SOA is past its sell-by date, we need something new.” There have been others saying that SOA should in some way be superseded by other architectural constructs, such as (say) event-driven architecture, EDA.
Trouble is, SOA isn’t something that can go away, precisely because it is a logical, evolutionary step that brings together several strands of IT. If we were to move on from SOA, that would mean throwing away not just the term but all the best practices that have been learned over the past 40 years. And what of EDA? Absolutely it has validity – but it takes a product mindset (see Myth 1) to believe that architectural constructs should be mutually exclusive, or in some way competing.
Myth 5: SOA has to be enterprise-wide
There is a clear tendency to believe that SOA is appropriate only for the largest of strategic projects, or indeed, that to do SOA “properly”, it needs to be implemented as a broad framework across the organisation. This could partly be as a result of Myth 2, but equally Myth 1 has probably led to the belief that new, improved SOA should be the broom to sweep away all of the old, inferior architectural constructs that went before. SOA offers an alternative to silo-ed applications, but that doesn’t mean that all silos should be abolished.
This myth has been exacerbated by some IT architecture types, who would like to see enterprise-wide initiatives to define, model or otherwise capture the interface between business and IT. To counter this, a well-worn phrase in architecture circles these days is, “Don’t boil the ocean,” recognising both the impossibility and the futility of such a task. The alternative is to focus on achievable goals, using SOA as a framework to solve a specific set of challenges – the roll-out of a new application that needs to be integrated with a number of legacy platforms, for example. Setting tangible goals for SOA also sets an appropriate scope for what needs to be understood and modelled architecturally.
Myth 6: Business people don’t get SOA
IT’s habit to try to solve its own problems perhaps leads to the biggest myth of all, namely that SOA should in some way be confined to the technologists, and is not relevant or too complex for the business. Business people do “get” service orientation, if it is explained to them without being dressed up in techie terminology. Indeed, in recent Freeform Dynamics research, the majority of senior business respondents were either already familiar with SOA or thought it made sense when service orientation was explained to them.
Indeed, for SOA to succeed as more than an integration mechanism, it is vital that the business does understand what IT is trying to achieve. As already discussed, an architecture oriented around services can draw together a number of threads from all areas of the IT organisation, including its interface with the business. It is good to know, then, that as long as SOA is presented without technical baggage, we are pushing against an open door when we want to talk to the business in this way.
So, what can we conclude? While SOA may still be cursed with a number of myths, a final reality is that SOA is inevitable, a consequence of how IT is evolving. In the future, in order to achieve a successful integration between such areas as those listed above, we need (a) to think in terms of architecture, and (b) to consider the primary purpose of IT – to deliver services to its users – as the central tenet. Does IT need SOA? That’s unclear. To move forward, do we need to think in terms of an IT architecture and delivery mechanism that is, in itself, oriented around services? Undoubtedly – but rather than promulgating myths, it will only be by adopting clear vision of what SOA has to offer that we really stand a chance of achieving its promises.