I recently came across an article in CIO magazine entitled The Truth about SOA where they raise the question of communicating with the business about SOA. The answer they provide is: don't.
Q: SOA is a technology architecture. How do you make a business case for a new technology architecture?
A: You don't. "Don't talk to the business about SOA because the business doesn't care," says Forrester Research analyst Randy Heffner. The business's interest in SOA extends only as far as it cuts the cost of applications and gets them running faster. But simply rewriting code in the form of a service doesn't deliver those kinds of benefits. To start down the road to building an SOA, there needs to be multiple redundant IT applications that can be consolidated into a single service, or the possibility for multiple areas of the business to use a single service.
I couldn't disagree more. Let's leave aside the apparent mixing of SOA (business planning as it relates to technology) and web services (a particular implementation technology that happens to complement SOA very nicely), and the narrow definition of SOA as specifically a technology architecture.
You must communicate at least the broad concept of SOA, because in its implementation you're going to change the IT (and possibly) business governance structure substantially. The business must be involved in this process, and they must understand the implications of moving from (in most cases) tightly integrated silo applications and infrastructure to an SOA environment with all its advantages, and disadvantages.
One of the disadvantages are the potential implications of change and change management. Someone needs to be responsible for these services, and to ensure that changes and impacts within the business are met. The must ensure the service levels, extensions to the service, and predict and plan change as the business changes.
For the business to agree and endorse these changes they must understand some of the fundamentals. In particular, in my organization, the difference between the presentation (offering) layer, the service layer(s). For most businesses used to running applications in silos and managing the silo from top to bottom (as a "product") this likely implies a major change -- or at least a consideration -- in the way the business, in addition to the technology, is governed.
Richard just posted on SOA Service Ownership, and some of the specific issues we're having with regard to SOA service governance.
As in most business/technology communication efforts one of the primary issues has been coming up with terms and definitions that we can all agree upon amongst the business and technology folk -- and those of us stuck between. We've just recently come to a consensus on some of the key terms in my organization. Perhaps I'll post some of these terms and definitions once they're a little more stable.