Richard Turner at Microsoft caught my eye yesterday. He had spotted a post from July by Martin Fowler on SOA. Martin's title (Service Oriented Ambiguity) probably tells you all you need to know about his opinions in this area :-)
It is also worth reading David Ing's response - some excellent points are being made.
David is certainly correct that there is too much "cleverness" flying around. I take the view that, as an intelligent, educated person that I should be able to understand any entry-level or intermediate-level presentation in this space. If I can't, then it's the material that's at fault, not me. The interesting thing about this is that a couple of years ago I started seeing SOA pitches and they were completely incomprehensible. However, the ones I'm seeing now are far, far better. This is good.
David also totally nailed (to steal his phrase) the component- and integration- approaches to talking about SOA. Are we selling a component container or are we helping to add integration points to existing (and new applications)?
I think the reason why previous attempts to explain SOA (and even implement them) have been less than successful is for precisely the reason that these two approaches aren't different, they're complementary.
Yes: you need to be able to integrate with existing systems (and any new ones you build) if you're bought into the idea of composing new applications from existing services so building what he calls "integration gateways" into systems is essential. But - and this is the key point - you need somewhere to build your new applications that provides appropriate qualities of service and which can abstract away all the hard work of having to worry about the fact that these services live somewhere else. In short, advocating the use of a container that understands composition of components to build solutions and which can seamlessly invoke services exposed elsewhere - and expose services to others is not a bad thing.
However, Martin's original point stands - the industry needs to get far sharper over our terminology and our definitions.