ITSM ambiguities: lifecycle vs. transaction; system vs. service

Apologies all for long absence. Someday I'll tell the tales. But not today.

Twitter is increasingly useful lately, for pointers to current IT Service Management (ITSM) discussion & many other topics. A couple lines of inquiry have me feeling contrarian, or at least desiring more clarity:

1. There is a basic distinction between the lifecycle of a service, and the end to end performance of that service. I still do not understand whether the concept of service "delivery" applies to either, or both. 

2. Despite all the inkbytes spilled on how "service" is different from "system" (or application) I continue to find the distinction problematic.

Service lifecycle versus performance

The lifecycle of an IT service extends from someone's bright idea ("Hey, maybe a computer can help me!") to retirement. It can run years. It goes through the systems development lifecycle into "production," "operations," or even "value exploitation" (depending on how trendy you are).

I equate that lifecycle to product development in industry. CMM notwithstanding, it is non-deterministic, risky, "Eureka"-driven, and right up there with sausage and laws as something you often don't want to see being made.

But when it is complete, like a product going into full manufacturing, the finalized service is a template for execution. Transactions - which can be viewed as discrete deliveries of value - start to flow across the infrastructure, often at high volume and across complex layers of technology, each with its own operational profile. *This* flow needs to be highly repeatable and deterministic.

The recognition that the value consumer cares little for the operational technology silos underpinning their value-add transaction is an essential ITSM theme. But this insight is no deeper than recognizing that the buyer of a car cares nothing for the problems of the sub-assembly line that delivered the engine.

In reading much ITSM discussion, I find myself confused about which perspective a given author is taking. The ITIL Service Lifecycle is clearly about the service as product, not as particular transactional instance. But much of the Business Service Management (BSM) discourse is about the individual transactions and attempting to better manage across the technology silos. And when I see a generic picture (as I did tonight on IT Skeptic, here) about "IT" coming out of "the pipe," I have no idea what is being discussed. The transaction? The service? Both?

The interesting thing is that either can have bottlenecks. In the service lifecycle, bottlenecks equate to failed projects or operational systems that are no longer fit for purpose (utility). In the operational realm, bottlenecks equate to availability & performance issues (warranty). For the first, you call in  high powered program managers, smoke jumping project crisis managers, or enterprise architects. For the second, you call in your application and systems engineers, and deploy your end to end transactional probes & BSM monitoring. 

So, let's just be clear about which we are talking please?

Service vs. system redux

"Don't confuse applications with systems! Don't confuse systems with services! Don't confuse applications with services!"

I've heard this message time and again for years now. From both the ITSM and Service Oriented Architecture (SOA) crowds, who are still not talking to each other about what exactly a "service" is. (The latest installment in IEEE Computer now talks of "commitment-based SOA," an interesting article, but one more in a long line of trying to reach "business"-relevant abstraction.)

Let me play devil's advocate. Is the difference between "service" and "system" any more profound than the old quote (Web attributions to Harvard's Ted Levitt) that people don't want a quarter inch drill, they want a quarter inch hole? The drill is the system, the delivered hole is the service.

A useful image, but well understood in this day and age, and since holes do not drill themselves, the drill is still pivotal. (So to speak.)

Joe: I see ya got yerself one of them new Makitas. How do ya like it?

Sam: My Friend, the Fact that it is a Makita 18 volt Lithium Ion Powered Cordless Electric Drill is only Incidental. I have deployed a Hole Creation Service. I may replace it tomorrow with a Portable Laser, or even Outsource the entire Possession and Operation of this Apparatus. Please don't Focus upon its Particulars, as they are Irrelevant.

Joe: Um, yah, whatever. See ya later. By the way, you know that thing is actually called a Driver, not a Drill, and is good for more than holes, right?

And there you have the basic What versus How discussion. And to take it further -- one person's What *is* the next person's How, as holes are simply "how" one then employs a fastener, and perhaps that is what the customer really wanted... neither a drill, nor a hole, but two things fastened together ... and perhaps not even that is the true service... the door needs to be attached to its hinges with a coat of paint and a newly keyed lock for "value' to be perceived by the homeowner.

(The subcontractor, on the other hand, was just happy with a professional quality drill.)

The point is not that the Service abstraction is useless. The point is that it depends on a frame of reference, and that Value is layered and subjective. What one person would perceive as a true Service, the next will dismiss as mere implementation on the path towards the broader value *they* are seeking. And so it goes.

For the enterprise IT consumer, the entire creation of the Service is in and of itself a service. (Perhaps the "meta-service.") The entire lifecycle of the system, *is* a performance. Depending on how you look at it...

And so, in this light, dogmatic attempts to fix boundaries between System and Service seem doomed.

Got something to say?