Extending SOA

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 ...