Surviving the Paradigm Shift

SOA has taken quite a battering over the years. There are a lot of disenchanted businesses out there burned by failed SOA implementations. Despite this battering, SOA has not only survived but still attracts considerable attention from businesses across a broad range of industries.

But how long will this last? Does SOA hang by a thread? How many failed SOA implementations will it take for businesses to simply give up? Perhaps the reason why they have not done so already is that the fundamental business needs that SOA addresses (the need for agility and efficiency) are stronger than ever.

We as SOA practitioners need to examine why so many SOA implementations either fail completely, or fail to meet expectations and address these issues as a matter of priority.

One of the key reasons why we have so many bad architectures based on SOA is that many SOA practitioners in the field do not have a good understanding of the best practices and principals around applying SOA in a business context.

This is perpetuated by the proliferation of bad guidance in the SOA space. Some vendors are in part responsible for this, pushing their own guidance that aligns well with their existing EAI stacks rather than with SOA best practice.

The vendors however do not take full responsibility here. Most SOA practitioners have their background in software development; the problem being that many of the traditional object oriented programming paradigms are anti-patterns in SOA. As such, many of the lessons they have learned are invalid in the SOA arena.

Examples of where we see traditional programming approaches being employed in the application of SOA is in the preference for command messages, synchronous request-reply and the use of RPC interactions. Another example is the tendency to prefer centralised data architectures and CRUD interfaces.

We need SOA practitioners to unlearn what they have learned in order to accommodate the coarse grained nature of services, the need for asynchrony, the fallacies of distributed computing and the fact that services must and will evolve independently as they are under different ownership domains.