Take the 'service' out of SOA, and what do you get?

The term "service" is certainly getting a good workout these days. It used to apply to work performed by humans under some kind of contract, but in recent years, the definition has expanded to include work performed by software. Microsoft kicked off the non-human trend by branding many of its applications as services. Now we also have service oriented architecture, Web service, and Software as a Service.

But that's where the similarities end. In a recent post, Harry Pierson looked at the SOA and SaaS trend, and wonders if "we've done the industry a disservice by overloading the term 'service.'"

Not all services performed by software are the same. SOA and SaaS are two distinctly different forms of services, he points out. 

Earlier this month, I put forth the idea of looking at SOA as an form of SaaS delivered inside the walls of the corporation. Harry correctly asserts that "service" means two different things within the two approaches.

SaaS "is software that traditionally you might have bought, installed and run yourself but instead now can access over the network where someone else is responsible for installing and running it."

Whereas, Harry defines SOA as "a way of implementing IT systems as a Web of interconnected yet independent loosely coupled subsystems (typically called services)." He even suggests that the "S" is SOA should stand for "subsystems," rather than "service."

"Service, in the SOA sense, describes the approach to factoring parts of an software solution. Service, in the SaaS sense, describes a software delivery mechanism. Certainly, you can use both together and take an SOA approach to building a SaaS product. But you don't have to. So having the same term "service" used in both is very confusing."

Hmmm. Is it entirely appropriate, then, to use 'service' in service-oriented architecture? We're dealing with subsystems, components, and pieces of applications. How about just "SOA oriented architecture"?