ITSM ambiguities: lifecycle vs. transaction; system vs.
service<
http://www.erp4it. com/erp4it/ 2009/11/basic- itsm-ambiguities .html>
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<
http://www.itskepti c.org/changing- itil-will- be-metrication# comment-5884>)
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.
Having problems with message search?
Fill out this form to ensure your group is one of the first to be migrated to the new message search system.
Offline 
Send Email
