This is the third in a series of articles forming an unofficial introduction to ITIL. In the first article of this series we looked at an unauthorised history of ITIL. In the second article we discussed service management. Now it's time to consider just what is a service anyway?

The word “service” certainly gets some exercise. ITIL v3 says “A service is a means of delivering value to customers by facilitating outcomes customers want to achieve, but without the ownership of specific costs and risks.”

This impenetrable bit of consultant-babble does not help those who are trying to grasp the fundamental concept.

The itSMF repeats the same waffle in their introduction, but they then take pity on us by providing a practical example, where the outcome of sales people getting more customer face-time is delivered by a service which provides remote access to systems. (In reality, we all know that sales people spending less time in the office does not translate to more time with customers).

This is an advance from the ITIL v2 pocket book from itSMF which avoids the whole question of defining a service, though it does in passing say that a service is about “ICT infrastructure and management processes that deliver the information and solutions required by the business." ITIL v2 was centred on the process not the service, and in fact that other excellent itSMF pocket book for ITIL v2, IT Service Management, talks about “service” as a verb rather than noun in all parts of the book except the Serve Level Management section.

The ITIL V3 Glossary naturally repeats the party line quoted above, so we are no further ahead. Even the ever dependable Wikipedia omits a definition. This might be because defining a service is hard. It is one of those words where people know one when they see one but struggle to create a crisp, clear definition that covers all instances.

I prefer to follow the “Hitchhiker’s Guide to the Galaxy” approach: it is okay if something is “relaxed” and “contains much that is apocryphal, or at least wildly inaccurate” so long as it is ultimately practical and useful.

Users regard IT as a utility delivering “stuff” in the same way as other utilities deliver water or power. IT is a pipe and what comes out the end are IT services. Users don’t give a toss about the ponds, pumps, purifications and pipes needed to deliver out of the pipe—they just care about the consumables delivered to the screen in front of them.

Customers and users care about all that infrastructure only so much as they care about the cost and standard of the delivered consumables. [Note: ITIL makes a good distinction between users and customers: the user uses; the customer pays.] So, services are what come out of the pipe not what happens to get them there.

What do users consume from IT (or if you prefer, ICT)? They consume transactions running on technology. They add, update, find, view and report data. They execute a process. They communicate with someone. The value and quality of those services is measured by whether they are the transactions that the users need, whether they do what is required, and how well they do it. All those things are defined from the user/customer point of view, i.e. looking at what came out the end of the pipe.

Okay, so this, then, gives us a nice, crisp definition, right?: IT Services are transactions on technology.

This is the third in a series of articles forming an unofficial introduction to ITIL. In the first article of this series we looked at an unauthorised history of ITIL. In the second article we discussed service management. Now it's time to consider just what is a service anyway?

The word “service” certainly gets some exercise. ITIL v3 says “A service is a means of delivering value to customers by facilitating outcomes customers want to achieve, but without the ownership of specific costs and risks.”

This impenetrable bit of consultant-babble does not help those who are trying to grasp the fundamental concept.

The itSMF repeats the same waffle in their introduction, but they then take pity on us by providing a practical example, where the outcome of sales people getting more customer face-time is delivered by a service which provides remote access to systems. (In reality, we all know that sales people spending less time in the office does not translate to more time with customers).

This is an advance from the ITIL v2 pocket book from itSMF which avoids the whole question of defining a service, though it does in passing say that a service is about “ICT infrastructure and management processes that deliver the information and solutions required by the business." ITIL v2 was centred on the process not the service, and in fact that other excellent itSMF pocket book for ITIL v2, IT Service Management, talks about “service” as a verb rather than noun in all parts of the book except the Serve Level Management section.

The ITIL V3 Glossary naturally repeats the party line quoted above, so we are no further ahead. Even the ever dependable Wikipedia omits a definition. This might be because defining a service is hard. It is one of those words where people know one when they see one but struggle to create a crisp, clear definition that covers all instances.

I prefer to follow the “Hitchhiker’s Guide to the Galaxy” approach: it is okay if something is “relaxed” and “contains much that is apocryphal, or at least wildly inaccurate” so long as it is ultimately practical and useful.

Users regard IT as a utility delivering “stuff” in the same way as other utilities deliver water or power. IT is a pipe and what comes out the end are IT services. Users don’t give a toss about the ponds, pumps, purifications and pipes needed to deliver out of the pipe—they just care about the consumables delivered to the screen in front of them.

Customers and users care about all that infrastructure only so much as they care about the cost and standard of the delivered consumables. [Note: ITIL makes a good distinction between users and customers: the user uses; the customer pays.] So, services are what come out of the pipe not what happens to get them there.

What do users consume from IT (or if you prefer, ICT)? They consume transactions running on technology. They add, update, find, view and report data. They execute a process. They communicate with someone. The value and quality of those services is measured by whether they are the transactions that the users need, whether they do what is required, and how well they do it. All those things are defined from the user/customer point of view, i.e. looking at what came out the end of the pipe.

Okay, so this, then, gives us a nice, crisp definition, right?: IT Services are transactions on technology.

This is the third in a series of articles forming an unofficial introduction to ITIL. In the first article of this series we looked at an unauthorised history of ITIL. In the second article we discussed service management. Now it's time to consider just what is a service anyway?

The word “service” certainly gets some exercise. ITIL v3 says “A service is a means of delivering value to customers by facilitating outcomes customers want to achieve, but without the ownership of specific costs and risks.”

This impenetrable bit of consultant-babble does not help those who are trying to grasp the fundamental concept.

The itSMF repeats the same waffle in their introduction, but they then take pity on us by providing a practical example, where the outcome of sales people getting more customer face-time is delivered by a service which provides remote access to systems. (In reality, we all know that sales people spending less time in the office does not translate to more time with customers).

This is an advance from the ITIL v2 pocket book from itSMF which avoids the whole question of defining a service, though it does in passing say that a service is about “ICT infrastructure and management processes that deliver the information and solutions required by the business." ITIL v2 was centred on the process not the service, and in fact that other excellent itSMF pocket book for ITIL v2, IT Service Management, talks about “service” as a verb rather than noun in all parts of the book except the Serve Level Management section.

The ITIL V3 Glossary naturally repeats the party line quoted above, so we are no further ahead. Even the ever dependable Wikipedia omits a definition. This might be because defining a service is hard. It is one of those words where people know one when they see one but struggle to create a crisp, clear definition that covers all instances.

I prefer to follow the “Hitchhiker’s Guide to the Galaxy” approach: it is okay if something is “relaxed” and “contains much that is apocryphal, or at least wildly inaccurate” so long as it is ultimately practical and useful.

Users regard IT as a utility delivering “stuff” in the same way as other utilities deliver water or power. IT is a pipe and what comes out the end are IT services. Users don’t give a toss about the ponds, pumps, purifications and pipes needed to deliver out of the pipe—they just care about the consumables delivered to the screen in front of them.

Customers and users care about all that infrastructure only so much as they care about the cost and standard of the delivered consumables. [Note: ITIL makes a good distinction between users and customers: the user uses; the customer pays.] So, services are what come out of the pipe not what happens to get them there.

What do users consume from IT (or if you prefer, ICT)? They consume transactions running on technology. They add, update, find, view and report data. They execute a process. They communicate with someone. The value and quality of those services is measured by whether they are the transactions that the users need, whether they do what is required, and how well they do it. All those things are defined from the user/customer point of view, i.e. looking at what came out the end of the pipe.

Okay, so this, then, gives us a nice, crisp definition, right?: IT Services are transactions on technology.

Well yes, and no (of course). Now we will mess it up by exploring a grey area.

Not all customers want to trust IT as a total service provider (for good historical reasons). They are not willing to “black box” the services, to use the application service provider (ASP) model (now software as a service (SaaS) but still the same model). They are not willing to look only at what comes out of the pipe.

They either (a) want to know about the ponds, pumps, purifications and pipes and define the consumable in those terms or (b) they want to provide some of those themselves. In that case, they are treating IT as an infrastructure service provider (ISP) (and you thought it meant “Internet”).

The customer wants to take some responsibility for their applications, and looks to IT for platform (servers, operating systems, desktops, databases, network, etc.), storage, bandwidth, and/or management (security, availability, backup and recovery, etc.). This is common in geeky departments like engineering but it can crop up anywhere.

Neither ASP nor ISP is “correct”. Whether one or the other model is preferred (or prohibited) should be defined in the IT part of the business' strategic plan, and each service definition should make clear where it fits. What is important is for all parties to be clear on what the model is. Confusion and disagreement vanish the moment people realised they are talking on different levels.

If we can ignore that real-world intrusion into the idealised total service provider model we can come up with a slightly more precise definition that still does not become too waffly: An IT service is the availability and/or consumption of a type of transaction running on technology.

“Availability and/or consumption”? Every service provider sells the services they provide, even internal corporate service providers. There can be services that someone is already consuming, and there can be services that are there but nobody is taking them yet.

There, we can’t make it any easier than that.

Rob England is a self-employed IT consultant, commentator and entrepreneur living in New Zealand. He is well known as the IT Skeptic at www.itskeptic.org.