Early Indications is published twice monthly by the eBusiness Research Center at Penn State University. The author holds no direct financial stake in any of the companies mentioned.
If one ventures into the enterprise software world, the sheer volume of verbiage devoted to variations on the words "service" and "services" is bewildering, especially because a server, which confusingly can be either hardware or software, is unrelated to services. Web services are related to but not synonymous with service oriented architectures (SOAs), some of which can be implemented using an enterprise services bus (ESB). Public examples of SOA-like behavior can be found in the much-better named category called mashups, examples of which can be found below.
At the macroeconomic level, meanwhile, the services sector (which is really several sectors, as UCLA's Uday Karmarkar has noted) is crowding out products companies as the dominant force in gross domestic product. In the middle between code and Alan Greenspan, marketers worry about satisfaction ratings for customer service (including self-service) in the transaction process, while aftermarket repair and maintenance is yet another kind of service. Finally, there are transactions in which activities are performed in conjunction with a product purchase: software implementation is one such service.
According to the Oxford English Dictionary, "service" has at least five different meanings that could apply to the current confusion:
-the action or process of performing duties for
-an act of assistance
-the process of attending to a customer in a shop
-a system supplying a public need such as transport, or utilities such as electricity and water
-a periodic routine inspection and maintenance of a vehicle or other machine
(The root word, servus, means "slave.")
IBM has launched a research initiative into what is now being called Services Science, Management, and Engineering (SSME). According to the initiative's website, "A service is a provider/client interaction that creates and captures value." Elsewhere, an IBM Software page answers the question "What is an SOA?" this way:
"SOA is the blueprint for IT infrastructure of the future. SOA extends the Web services value proposition by providing guidance on how enterprise IT infrastructure should be architected using services."
But it's clear that the software folks do not intend that such architectures should use "provider/client interactions that create and capture value." Given this wide semantic variation, it will not come as a surprise that measuring services is problematic. At the economic level, what is the productivity of a teacher or programmer? The input-output metric used for mechanical efficiency breaks down, but no model readily presents itself as an alternative. There is substantial promise in the area of supply chain research however, insofar as networks of people in various roles perform tasks to accomplish a process. At a sufficient level of abstraction, treating some kinds of medical patients, building software, and delivering fresh strawberries do share metrics, constructs, and success factors.
Measurement of services is important for many areas, particularly where money is concerned. Thus a network provider might have a service level agreement (SLA) with a customer, that throughput will never fall below a given threshold and downtime is expected to be 30 minutes a month, never falling between 8 am and 6 pm, etc. Confusingly, because a services-oriented architecture runs across a network or set of networks, it requires a service level agreement from the provider of the network. The "S" is SOA has nothing to do with the one in SLA.
One further thought. Does customer satisfaction measure what was delivered by the provider, or what was experienced by the customer? For this discussion, "service" can be understood as retail or hospitality, professional services like law or consulting, and possibly more. Major corporate effort is expended in the area of increasing customer satisfaction, usually in operational improvements. It may not be the best place to apply effort, however. If satisfaction is understood as the congruence between expectation and experience, some of that spending on operations could be redirected into negotiation, getting customers to reset expectations rather than trying to meet unrealistic ones.
A cab ride is a service. Going from midtown Manhattan to LaGuardia at 1 pm on a weekday can take 25-45 minutes, while doing so at 5:15 is a very different proposition. Weather makes matters worse. If, however, a driver takes an hour in the middle of a sunny day because of inexperience or other driver-related factors, the rider is right to be irritated. The point here is that much effort is expended in trying to define service levels for a wide range of contingencies. Alternatively, it may make more sense to educate customers into the factors, both in and out of the provider's control, that influence service performance.
The broader issue of confusion over service, service levels, and service economics will get worse before things improve. That the language is insufficient probably relates to the relative newness of the swings from products to services, and from applications that run on processors to services that run over networks. I can only hope that just as "horseless carriage," a lame extension of a soon-to-be outdated name, gave rise to a rich vocabulary of automobile language, so too can we get more words like "mashup" and fewer bureaucratic three-letter acronyms that usually define reality neither vividly nor accurately.