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.
So, we have Business Services and services, which are the most important in a SOA? Business Services, without doubt. If you really want to create something that is going to profit your company then you have to focus on the business. You can have a great SOA infrastructure, ESB, registry/repository, BPM etc. but if you don’t identify what your business needs are you are not exploiting your infrastructure, not more at least than cutting your development costs by creating an infrastructure of reusable services, but that’s not where SOA’s power lies.
Bringing it to an extreme, you could have good Business Services building upon an unstructured services infrastructure and still your company would profit from it (though not to the maximum possible extent as creating new services would probably require more time than if you had a good services infrastructure, thus affecting your time to market).
That’s not true the other way around, bad Business Services relying on a well implemented services infrastructure give little or no gain.
When to promote a service to a Business Service is very hard to tell and it depends on the company’s specific business.
SOA is both business and technique. Once you are done implementing your infrastructure it is going to be there supporting the ever changing business needs. That’s why standardization is so important, it allows you to focus on what really matters, that is creating business value.
Some SOA principles are common to services as well as Business Services. For example, abstraction. In order to build good services you try to create services that are reusable and therefore try to abstract them from the their context, such as the application using them, in that way when another application needs the same functionality, it’s already there. Business Services work in the same way, but the consumer is different, meaning that you try to create Business Services that are reusable so that when the next business needs the same functionality... well... it’s already there.
To try to make things a bit more clear, by abstraction I mean that for a service to be reusable it must be so general that any consumer needing that specific functionality can use it. Using the typical car rental company example (I said I’ve been to a lot of conferences...) a service, or rather, a Business Service, could be ‘check car availability’ returning ok or not ok depending on the data provided. This service could be reused by any other company wanting to rent a car thus benefiting both the car company hosting the service that could hire out cars to customers it would not reach otherwise and other companies that would have lost money not having an own car to hire out ( that is, of course, at the condition that the company offering the service has an overflow of cars).
Then we have standardization. Services profit from being written in a uniform way, therefore web services have become so important in a SOA, abstracting the technique lets you focus on the services itself and makes it easy and almost effortless to expose them.
In the same way one could say that business SOA is moving more and more towards standards, like BPMN attempting to make processes easily understandable.
I believe that the hidden revolution embedded in SOA is yet to come and it has to do with the capability of creating a global network of services and consumers able to look up and use services with little or no manual interaction, discovering the required functionality (I know this is probably the SOA utopia but I still believe there is much to be done and that can be done in this area). And of course it has to do with new techniques such as SaaS (Software as a Service) that can now flourish as SOA infrastructures and awareness improve.
Although this sounds promising not much has been done in this direction so far, most of the companies that have adopted or are adopting SOA are still struggling with publishing and managing internal services and little has been done to ‘go public’(except by those companies that are leading the transition). With SOA becoming more mature we will see an increasing number of efforts in this direction.