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.