SOA implementations thus far have been fairly small. For instance, according to this IT World article, the benchmarking non-profit APQC reports that 43 percent of its respondents report having at least one SOA service in production, but the average is three. That would seem to corroborate what analysts and consultants are saying: Mostly, companies are doing proof-of-concept SOA services rather than full-scale implementations.

Of course, this is destined to change. Already, I'm starting to see more focus on the question, "How should IT talk about SOA to the business?"

Good question. The smart money seems to be on: Whatever you do, don't talk about the technology. Talk about what SOA can do for the business.

In this Linkedin.com question and answer, a self-described "IT representative to the business" asks "What does SOA (Service Oriented Architecture) mean to Business Folks?" A CTO responds, "First, don't talk about SOA." He continues on, adding a bit later:

I'm constantly frustrated by the excessive focus on the technology of SOA at the expense of the real potential of SOA to transform the way a company does business. And, almost all SOA projects come from the IT department and just talk about the technical/infrastructure pieces.

His response is well worth reading. I really like his point about not pushing business process automation when most companies still haven't Web-enabled many, many legacy applications.

Microsoft employee Avinash Nicklas Chan Kumar Malik (Nick Malik) also recently tackled this question on his blog, Inside Architecture. He compares the way IT currently sells SOA to an architect trying to sell him on a house addition by talking about how easy it will be to add on a room or how he'll use standard wood and wiring. Instead, the architect talked to him about aesethics, lifestyle and functionality. IT can take a lesson, he argues. Malik writes:

I've decided that the best way to "Sell SOA" to the business is not to sell SOA to the business. Let's talk about the aesthetics, the features, the speed and reliability, the automation of their business processes to allow them to focus and innovate where it counts. Let's not talk about standard parts.

Both of these items make excellent points about how you can talk about SOA.

That said, I'm going to respectfully disagree with the contention you shouldn't talk about the technology aspects when you talk about SOA.

Let me explain.

First, when you ask, "How do I talk to the business about SOA," what you really want to know is: "How do I convince business executives to spend money on retraining and new SOA tools -- whether that's middleware, development tools or new hardware? And then how do I explain why they should put up with the inevitable application deployment delays, increased testing and the numerous meetings with business managers and users as we shift to service-oriented architecture?"

And therein lies the problem. Much of the benefits of SOA -- agility, quicker deployments, less cost for development -- won't come immediately. And even if you could reap that ROI immediately, there's still the credibility problem.

You see, IT has promised all of this before. And in recent years, the business has grown impatient with spending money on technology solutions that promise to fix business problems, only to find next year IT wants more money, again to fix the same problems.

Imagine if Malik's architect came back and told Malik he was going to have to rebuild that house addition. Wouldn't you want to know why? And if that architect said, "Because it will be better... and because the first room didn't follow coding standards." The architect would probably be fired. But let's assume he isn't. My guess is, Malik and anyone else in that position is suddenly going to be very interested in having conversation about standards and materials and foundations.

Plus, it's a bit condescending to think business won't understand the technology reasons behind this change. Real life isn't like Greg the Architect: Business leaders don't need to hear the words "ROI" to understand benefits of SOA.

Of course, you shouldn't start out the conversation by talking about the technical aspects of SOA. Business value is definitely the place to begin. But be prepared to discuss services and explain why SOA is better that EAI or standard development practices -- my guess is, there will be questions.