I’ve been to dozens of SOA lectures, presentations and conferences and though I considered some (the first ones) to be very interesting as I approached the subject, it soon started to get a bit boring as I easily could anticipate what the presenters were going to say: why adopt SOA, how will your company benefit from SOA, the possibilities SOA gives you, etc. etc.

It’s fair to say that there is a lot of confusion and false expertise in this area and often these conferences are more a PR and sales show rather than a valid review of what SOA really is.

But why all this fuzz about SOA?

A SOA expert/sales man once said at a seminar:

At first I thought it was funny as it sounded more like some kind of disease... ‘oh crap! when...!? It must have been that Thai stuff...’.

But then he went on saying that SOA is a brand new (fantastic of course) technology... but...wait a moment... how can it be a new technology if I already have it? Am I a pioneer?

What on the spot seemed an exaggerated way to express his excitement about SOA was probably a smart way to sell SOA to the mass of CIOs attending the conference.

Is there a better way to make you buy something than saying you already have it? Don’t ask yourself if you want it, you or someone for you already made that choice, so just keep on following the (right) path...

But he was indeed right to some extent. Some aspects of SOA are commonly accepted and adopted and some parts of SOA are new.

At the same time it’s a bit like saying that just because I name something that had no specific name I created it, it doesn’t really work that way.

Vague, undocumented and double or triple meaning definitions are not uncommon to the IT world but I must say that SOA beats them all. If there is a commonly accepted definition I haven’t found it yet, the ones I have encountered so far not only differ on what SOA is but they do it on so many different levels of abstraction that it is indeed difficult to get a good picture of what SOA stands for.

Some people speak of SOA from a technical point of view, web services, SOAP, REST, etc, others see SOA as a set of techniques that work together in order to create a better alignment between business and technique.

Then maybe that’s why web services are such an integral part of SOA.. If we build a web service exposing that method would we have SOA then. Well, no, or yes according to some. Now I can call my service from any other application outside the original domain, that sounds indeed like some kind of SOA, but is that it?

I could have done that using JMS, RMI or any other communication technology, so do web services automatically give me SOA? No, in fact you can and you often do have SOA without web services.

A key to understanding SOA is probably the distinction between services and Business Services.

A service is, as said before, just something doing something. A Business Service is a service that is relevant to the business we are running and therefore creates some kind of added-value for the organization.

But how do I know if a service is a Business Service? Well, if your development department created it without consulting your business then it’s probably not a Business Service. In order to create a Business Service you need to know what your business requires and this has to be done in cooperation with the business itself. Of course you can try to create what you think is a good Business Service, and you probably will succeed to some extent, but that’s in my eyes not the way to go.