In practice, the concept of service and service management is rooted in customer value. How does that apply to SOA? First, the definition suggests the primary consideration be given to customer outcomes and customer value propositions. This concept isn't usually associated directly with IT, however; it's more of a business notion.

So the "service" in SOA isn't really about technology, objects, interfaces, granularity, messaging, reuse, mashups, product stacks, standards, platforms, openness or damn near anything else. It's about mapping business processes to a software implementation that facilitates stakeholder outcomes and value.

Indeed, SOA is more about business processes than it is about services. Before you embark down a SOA path, you need to understand, if not specifically enumerate, the business processes the SOA will map. Only once that's done can you turn your attention to implementation details, which should also be rooted in customer value. That will drive the technology decisions, organically, into their appropriate realms.

I wonder what would happen if we changed the buzzword from "SOA" to "BPOA," meaning Business Process Oriented Architecture? Would anyone seriously talk about BPOA 2.0, or "advanced BPOA?"

Next week I'll bring you inside the first of several successful BPOAs—er, I mean SOAs—through one-on-one interviews with the IT leaders steering them. While the technological underpinnings vary wildly, each exists in the context of the total built environment, and is rooted in customer value. The results speak for themselves, and I hope you'll listen in.