I like everything about SOA except the acronym and the way SOA is described. To make more sense, let me tell you a story I read in a piece of paper stuck on somebody's cube. The story goes something like this:

A person flying somewhere in a balloon gets lost. He lowers his balloon and asks a man on the ground. "Excuse me! Could you please tell me where I am?" The person on the ground responds, "You are in a balloon about 25 feet above the ground." Hearing the response, the balloon man correctly guesses, "You must be an IT person. What you said is correct but it's of no use to me." The ground man replies (also guessing correctly), "You must be a business person. You don't know what you want, you are not asking the right questions, yet you want me to solve your problem."

The story applies very well to SOA. While the idea behind SOA is to promote a set of architectural principles that, by design, support a better alignment between business and IT, we failed to include the B for Business in the acronym. Not only that, we do a poor job at explaining it to non-technical people. Those guys have absolutely no idea what we are talking about when we use terms like service, architecture, loose coupling, interoperability etc. They only care about satisfying the business requirements. They care about business agility. They care about return on investment. And they care about not having to write an enhancement request and spend a ton of money when all they want is to see an additional field on their screen.

You see, when we 'do' SOA, we knowingly or unknowingly look at it from technical perspective. Our respected architect tells us, "You should really expose this and that system as a set of services." If he knows BPM, he would probably add, "You should also analyze your business process and identify business services from them." The architecture team starts identifying the 'toolset' to do this. The team starts debating on the granularity of services and someone keeps repeating "SOA doesn't have to be implemented using web services." (What's up with that? Enough already!)

I say, for every potential SOA project, we go back to the basics and think about the value proposition of SOA and what it does for the business. I say, we use that value proposition to explain to the business how SOA is about deriving IT architecture from business. I say, we recognize and acknowledge (rather than defend) the IT pain points business typically has and try to show how SOA helps ease the pain.

While I don't see the acronym changing, I definitely see a potential to change our approach to SOA. Remember, there is a B in SOA; you just have to find it.