What is an IT Service?

Every time we host training, I pose this question to the class on day one.  It seems like such a basic question, one whose answer should be as obvious as ‘what is 2+2?’.  Yet, the responses I  get lack a consistency that is indicative of a major problem for organizations moving to a service-based approach to IT management.  After all, if we can’t settle on a single definition of this fundamental term, how can we achieve it?

ITIL itself doesn’t really help, as all three versions have their own definitions with significant differences:

IT Service (ITILv3):    A Service provided to one or more Customers, by an IT Service Provider. An IT Service is based on the use of Information Technology and supports the Customer’s Business Process. An IT Service is made up from a combination of people, Processes and technology and should be defined in a Service Level Agreement.

IT Service (ITILv2):    A set of related components provided in support of one or more business processes. The service will comprise a range of Configuration Item (CI) types but will be perceived by Customers and Users as a self-contained, single, coherent entity.

IT Service (ITILv1):    A set of related functions provided by IT systems in support of one or more business areas, which in turn may be made up of software, hardware and communications facilities, perceived by the customer as a coherent and self-contained entity. An IT service may range from access to a single application, such as a general ledger system, to a complex set of facilities including many applications, as well as office automation, that might be spread across a number of hardware and software platforms.

My biggest problem with all three of these definitions is their ambiguity.  For an organization just getting started on the road to service-based management, these definitions offer little in the way of practical guidance, especially where to begin.  Furthermore, these definitions are virtually useless outside of IT, even though one of the biggest goals of ITSM is delivering greater transparency to the business.

Therefore, we’ve developed our own definition of this most basic of terms, which has been resonating well with our customers on both sides of the IT/Business fence.

IT Service (FireScope): The discreet points of interaction between your technology and your customers, both internal and external.

Not only is this a simpler definition, but it also provides clear guidance on where to begin as well as what is most important – the customer.  As technology has become more and more complex and discussions fall down the rabbit hole of technical jargon, it’s easy to lose site of the reason it exists; enabling people to conduct business.  By focusing your definition of services to how they impact customers, we can more easily focus on the metrics and measurements that matter most and ignore the thousands of metrics that simply have no affect.

Furthermore, when describing IT Services in this way, business leaders have a clear vision of what’s at stake from their perspective, which in turn leads to more meaningful conversations.

But perhaps more interesting is how this shapes how we model the services themselves.  If we take a customer interaction approach, we model the downstream dependencies based on how each element delivers a user experience.  Often, we find that what we previously defined as a single service is actually more like 3 or 4.

Take email for example.  If we look at the points of interaction we find that we have some users who consume email through fat clients such as Microsoft Outlook.  Others use a web-based interface like Outlook Web Access (OWA).  Another group uses their mobile device.  If we back track through the technology in terms of how they deliver on each of these user experiences, we find that the fat client experience never touches the web servers, and some email platforms require a separate application that is only involved in pushing to mobile devices. In this scenario, if the web servers fail, do we consider the entire service to be in a failed state?  If we say no, we’re ignoring a large segment of users;  if we say yes, then we’re definitely not getting bonuses this year.

By separating these discreet user experiences as separate services, we can more accurately communicate which users are impacted by an issue in a way that the rest of the business can understand.  Furthermore, from an incident troubleshooting perspective, this approach helps me isolate the problem faster.  Knowing that mobile and fat clients are operational, yet web-based users cannot get mail tells me I can ignore most of the platform and focus my efforts on the web servers.

There are lots of other possibilities that this approach to service definition opens up, and we will discuss them in future posts.  But I am curious, how does this resonate with you?  As with anything, the concept evolves and we look forward to feedback as we refine how we deliver more value for our customers.