Examining the Pieces of the Service Puzzle

Last week, I promised to explore the difference between architectures and service-oriented architectures. Here’s the kicker: There isn’t a difference. Or there’s a world of difference. It gets down to semantics.

There isn’t a difference if you agree (as I argued last week) that a software architecture is, by definition, always designed to exist in the context of the total built environment—that is, the business environment. When every custom application is designed to this simple yet profound standard, then every application should, by definition, be a puzzle piece that fits perfectly into the total business application puzzle.

Things get more interesting when the business application puzzle includes customers, partners, suppliers, technology vendors and others (the tax man, anyone?). It’s a practical notion today, given the availability of a global Internet and low-cost broadband.

There’s a world of difference, however, when businesses don’t agree on what constitutes a puzzle piece; that is, how large or small each puzzle piece should be, and the technical mechanism by which these puzzle pieces should communicate. In other words, what is a service? The answer is … it depends!

Consider the following:

• In Software as a Service (SaaS), the term refers to canned applications that exist in the cloud, and are typically provided on-demand, sold under a subscription model.

• In Web services, the term refers to a set of XML messaging technologies (WS-*) and the “stuff” to which the WS-* connects. Or, as the W3C puts it, “the programmatic interfaces made available [for application to application communication].”

• In cloud services, we’re talking about an architecture that takes the shape of an application running in the cloud, calling upon services running within and provided by the operator of the cloud,” says Amazon.

And then there are the service providers: application service providers (ASP), managed service providers (MSP), Internet service provider (ISP). Indeed, I could go on for several paragraphs (TCP/IP Services, anyone?). Clearly the term “service” is overloaded. Or is it? It turns out there is a common definition that unites IP-based applications, including those apparently disparate examples listed above.

Once again I turn to ITIL v.3.0, which defines service as, “A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.” ITIL v.3.0 goes on to define service management as, “A set of specialized organizational capabilities for providing value to customers in the form of services.”

Now snap these definitions together. Note the unifying theme: “value to the customer.” Here’s a simplistic example. Consider what happens when you flip a light switch. All you care about is that the lights change their state, on demand. You don’t care about what’s involved in making the lights change their state, such as the utility company’s generation capability, transmission lines, substations, regulatory authorities, employees, union contracts and so on. You just want the lights to turn on or off, and you understand how to control the publically available interface for making them do so: the switch. You don’t have any of the direct costs and risks shouldered by the electric company. The lights just work.

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.