It has been quite a while ... lots of things have happened that have stopped me from writing ... but today reviewing my posts I thought about something important:
SOA only looks after ONE aspect of a business solution.
And it is not that this aspect is not important: a "service oriented" design will enhance all aspects of a business solution, "architecture" ... well this word is so misused it is difficult to find it within this context.
If using an analogy, I.T. business solutions were construction, the 'end-to-end' solution (software, hardware, costs of operations) would be THE CONSTRUCTION -. So you wouldn't call a plumber a "PIPING ARCHITECT" nor you would call an electrician an "ELECTRICAL ARCHITECT" (what about a "PLASTERING ARCHITECT?") ... your plumbing would be done by a DESIGNER that understand how the PIPING DESIGN fits in your overall ARCHITECTURE.
And the same with SOA - I have seen in plenty of situations how misunderstandings from 'Service Orientated Architects' can cause havoc in an organisation - thinking only of conceptual without any context into real building blocks for a solution (typical examples are proxying, security, synchronous vs asynchronous and pure design vs real life compromises), what happens ? The business doesn't perceive SOA as an enabler - because the P.R. people ('architects') understand only one aspect of what 'enabling' really means.
So what would be an 'extended' or 'expanded' SOA - one that considers ALL services (think about utility computing?): networking is a service, virtualisation is a service, processing power is a service, operating system is a service, application servers are a service, business logic is a service ... at the top of all this, you have your 'Service Oriented Design' which are expressed in a language that the business can understand (or could closely understand, like BPEL?).
This would obviously be a more compelling 'SOA' proposition to non-technical people ...