SOA: Myth or reality?

There is a continuing (and welcome) debate about the merits of “SOA”, although the position of some contributors doesn’t seem to be coming across very clearly. Clemens Vasters suggested on Monday that maybe SOA doesn’t really exist. This caused some outcry from those arguing that you can build a service oriented architecture. Richard Turner repeats his calls for caution around the SOA nomenclature.

We have two groups: the SOA crowd and SO crowd, the latter being those supporting service orientation but as part of the picture and trying to avoid the marketing hype.

Here’s the thing: none of these people believe that service orientation is without merit. They all agree that there is value in building distributed systems using services. Mostly they think a pragmatic approach is valuable. Aside from the fact that it’s difficult to find two people who agree on the definition of a service oriented architecture (there are different views of n-tier and probably client-server), it seems from my standpoint that the main disagreement is about the impact of service orientation on the overall architecture of systems. The SOA group suggest that services are the foundation of a system architecture and make such a fundamental difference that this is the centre piece of the design. The SO group propose that service orientation take its place alongside object orientation as a tool making up part of a bigger picture, a significant one nonetheless.

As you probably guess, I’m currently with the SO people: in talking with customers and discussing how to approach their application architectures using services it quickly becomes clear that this isn’t the be all and end all. Sure it’s important and it places emphasis on issues such as managing change that are sorely needed but it isn’t enough and you still need skills in distributed applications within those services. Don’t get me wrong, I’m not dismissing the notion of SOA because it isn’t new; I’m dismissing it because it isn’t complete. Yes, with WinDNA you still needed other skills but the difference was generally that those skills were related more to implementation and less to architecture, which was already wrapped up.

So here we are: service orientation has its place, a really important one, but to my mind it doesn’t qualify as an architecture just yet.