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.