Naming IT Services

First of all a key benefit of the ITIL library is that it provides a neutral (non partisan) common vocabulary for IT Service Management. Lets face it, if you put 10 IT professionals in a room and ask them what a service is and you will get at least 12 answers. Don't get me wrong I value creative flexibility as much as the next guy but when it comes to language I would prefer to avoid the Tower of Babel experience where people cannot understand each other due to an issue of communication. So to help things along here are some key ITSM definitions and rules for establishing the names IT Services and Systems. IT Service:
  • One or more technical or professional IT capabilities which enable a business process. An IT Service exhibits the following characteristics:
    • Fulfills one or more needs of the customer
    • Supports the customer's business objectives
    • Is perceived by the customer as a coherent whole or consumable product
Note: By this definition a service is a capability, not a technology solution or vertical domain such as a server environment or a business application in isolation. IT System:
  • An integrated composite that consists of one or more of the processes, hardware, software, facilities and people, that provides a capability to satisfy a stated need or objective. An IT System:
    • Is a collection of resources and configuration items or assets that are necessary to deliver an IT Service
    • Is sometimes referred to as a Technology Solution.
Note: The technology system is the complete composite of IT components from various technology domains which when brought together in a relationship represent a value-added technology solution; for example, a Local Area Network or an application system such as business application solution. A system is not referring to the application as a stand-alone element but to all of the components which build the complete solution (application, databases, servers and middleware, etc). Based on these two definitions here are some key rules to bear in mind when developing a Service / System structure.
  1. A service always refers to a capability and not a specific technology
  2. A service does not make reference to an organizational function, department or structure. In other words it is organizationally agnostic!
  3. A service is supported by one or many systems. Eg: Messaging is supported by Backberry and Exchange
  4. There are three types of IT services (Business Application Services, Infrastructure Services and Professional Services)
  5. Any of the three types of services can either be customer facing or component/supporting services
  6. The moment you start publishing logical and sensible IT Services expect someone to ask you to tell them how much they cost
So you may be wondering why the insistence on the first two rules. Consider that while an IT Service like Email is relatively constant both its underlying technology system and the organization which delivers it are both transient. A few years ago you may have used CCmail and now your organization leverages Lotus Notes or Microsoft Exchange. Who knows what you will be using in the future. The point is that the service is constant and the technology changes. Likewise today you may manage Exchange internally but tomorrow you may use an ASP model or you might choose to outsource it completely. The point is that a service is constant but who delivers it will change. Troy's thoughts what are yours? The History of every major Galactic Civilization tends to pass through three distinct and recognizable phases, those of Survival, Inquiry and Sophistication, otherwise known as the How, Why and Where phases. For instance, the first phase is characterized by the question "How can we eat?" the second by the question "Why do we eat?" and the third by the question "Where shall we have lunch?" ~Douglas Adams. 1981. The Hitchhiker's Guide to the Galaxy.

Like this article? Like

View Comments (10)


Hello Troy!

I have just finished my first lecture of your post, so at this moment I don’t know if I agree or disagree with your definition for IT Service.

But there is something that has impacted me: you tell us that ITIL has provided us with a vocabulary, but I haven’t seen those definitions in the ITIL books. (May be I havent seen it, and then you are quite right!)

I have found several problems in meetings with customers interested in developing a service catalog, since they don’t differ between the 3 types of services that you menctioned, and it is really important. At least differencing between IT services and proffesional services.


Antonio Valle | March 4, 2007 at 5:53pm

Hello Antonio

Thank you for your comment. It is the nature of all things to evolve over time. The ITIL framework is no different in this and we look forward to the release of ITIL v3 in May of this year.

What we hope is that as it evolves we gain more clarity.

To understand the ITIL Definition of an IT Service you have to look at the following sources and bring the different definitions together as a single whole.

I will list three ITIL sources from the oldest to the newest for your consideration.

Source 1: Best Practices for Service Delivery (2001)

Service: One or more IT Systems that enable a business process (page 327)

System:   An Integrated composite that consists of one or more of the processes, hardware, software, facilities and people that provides a capability to satisfy a stated need or objective. (page 329) 

Source 2: Best Practices for Planning to Implement Service Management (2002)

IT Service: A described set of facilities, IT and non IT, supported by the IT service provider that fulfils one or more needs of the Customer and is perceived by the Customer as coherent whole (page 136)

Services: The deliverables of the IT Services organization as perceived by the Customers, the services do not consist merely of making computer resources available for the Customers to use.

Source 3: OGC Best Practices / IT Service Management Glossaries and Acronyms (Current)

IT Service: 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 Processes. An IT Service is made up from a combination of people, Processes and technology and should be defined in a Service Level Agreement.

As you can see from these three ITIL sources the definition I used in this post and the one you will find in the book we recently published is a summarized view of these three ITIL books.

As far as there being three types of Services this is a best practice that we have documented in our book which is an extension on the current ITIL literature based on logic, experience and good sense.

I trust this helps.

Troy’s thoughts

Troy DuMoulin, VP Research & Development | March 4, 2007 at 10:42pm

I’ve been skeptical of this distinction between business application and service. My reasons for skepticism can be seen at


I’d also note that the “sample” service catalog that can be seen in the appendix to the Service Delivery volume (Chapter 4 Annex 4B) looks more like an application portfolio than anything else, starting as it does with “Payroll System,” “Accounts System,” and “Invoicing.”

I think there is great risk in being too abstract for our business partners. For better or worse, most of them zero in on the major applications that IT supports for them. Ask a VP of HR what IT does for her, and she will say “They run PeopleSoft!” She will not say, “They provide me with Human Resource Management Application Services,” and she CERTAINLY will not say, “They provide me with a Hosting Service!”

I realize I am swimming against the mainstream, and perhaps channelling a bit of the IT Skeptic. But I know a lot of application managers. They are service managers in the ITIL sense, yet are a long ways from calling themselves that.



Charlie Betz | March 5, 2007 at 7:43pm

Hi Troy!

Learning is a continuous improvement process… grin I hadn’t took in consideration the new ITIL Glossary.


Antonio | March 6, 2007 at 9:21am

Hello Charlie

I have browsed your blog with interest and enjoyment over the past few months and I am aware of your views on the subject of Application Services.

I will have to respectfully disagree with you, but here are a couple of key reasons why.

First: If we consider that an IT service enables a business process (directly or indirectly) then the majority of IT Technology Services that do this wonderful thing would have to be based on collections. (Yes Portfolios) of like business application “Systems” that collectively perform a common function.

Please consider that when we refer to the Business Application Service I am referring typically to a grouping of Application Systems that support a specific business function.

Example Business Application Services: Deep Water Drilling, Online Trading, Power Generation

You have probably noticed that these look a lot like the names of business processes/functions. That is because it is a best practice to name the Application Service as close as possible to the business process it supports.

Under each of these Service Names would then fall the systems that support this capability. For example, in a major bank I recently worked with they had over 20 Application Systems all supporting the Service of Online Trading. They had names like Eagle and Imagine and there were middleware systems supporting these as well.

To your point the business knows and cares about the names of the Application Systems. They do talk about Eagle but they also know that Eagle supports Online Trading.

Also please consider that when we refer to the Application System such as Eagle the application instance is only one object that makes up the System. The Eagle system also refers to the hardware, databases, platform devices and documents from all technical domains that build it.

Second: As I mentioned in my post the Service “Deep Water Drilling” remains constant while the Application Systems that support it are transient. Deep Water Drilling remains regardless of what new technology, provider delivers it.

Even PeopleSoft will one day be history but the Service of HR Management will still be required.

Of course now the question becomes. What is the difference between the IT Service and the business process? (Perhaps there isn’t a difference at all)

What happens when the line between the business process and its underlying technology is no longer distinct?

When there is no separating Accounts Payable from SAP then SAP is Accounts Payable and IT is simply the Line.

Troy’s thoughts.

Troy DuMoulin, VP Research & Development | March 6, 2007 at 11:23pm

Hi Troy,

I also enjoy your work and do respect your background and opinions in this matter.

Like I said, I realize I am swimming upstream. But I want to cast a critical eye on what is too quickly becoming an un-examined “consensus” in the ITSM community. Much of this is definitional and depends on our assumptions, which I can quickly see are not the same. For example, let’s say that Amy is the application manager for your “Eagle” system. In my experience, Amy’s concern is *not*, repeat *not*, restricted to that application “instance” if by that you mean merely the binary code and its instantiated process on the computing platform. I have never met an application manager in enterprise IT who had such a limited scope - it is a straw man argument. The only person who gets to have such a limited scope is perhaps a very focused senior developer.

Amy, as an application manager, is concerned with everything you just named: the databases, the middleware, the batch jobs, the data extracts, the servers and network(perhaps in terms of the relationship with the hosting organization), the client software, the documentation, the releases, the major Incidents and Changes, and so forth. She takes pages in the middle of the night and is a full fledged Service Manager in the full ITIL sense. She just doesn’t call herself that, and in my estimation, is not about to.

I know many, many Amys, across multiple very large organizations. At a major retailer I know, Amy and her peers were called Product Capability Managers. In my current environment, they are simply Application Managers.

Now, the idea that the core “service” should align with a functional grouping of systems is an interesting one. I might be ultimately convinced of this, but there are some things to consider:

- Business sponsorship and technical contacts may still have to be maintained at a lower level of granularity
- SLAs may still have to be defined with reference to the more granular application service
- Changes and Incidents may still have to be tracked at the Application level - you wouldn’t want to say “The Human Resource Management Service has an Incident!” if that Service included PeopleSoft HRMS, PeopleSoft ESA, the training system, the employee satisfaction portal, and the call center staffing system. (I *really* have trouble with such a large grained Service concept, by the way…)

These are only the issues that emerge top of mind; I’m sure I could think of several more.

Re: relationship between Service and Process. Your implication seems to be that it would be desirable to have one Service for each major Process. I think that, no matter how large grained you make your Services, you will always find that Processes (e.g. at the value chain level) cross multiple Services. For example, the human resource management value chain (hire to retire) crosses core HRMSes, security systems, and provisioning systems that you would *never* want to lump under one logical Service. So rolling up Services will not get you what you are seeking. 

I know that we will probably have to agree to disagree, but my final question to you is, what is to be done with the discipline and theory of Application Portfolio Management? If Applications should be invisible to the business, why would we try to manage portfolios of them? Is ITSM fundamentally opposed to the work of Maizlish and Handler? Jeff Kaplan? Bob Benson? None of them have embraced the term IT Service, and all have contributed greatly to the IT profession.

I would be very interested in your views on this.



Charlie Betz | March 6, 2007 at 11:57pm

Hello Charlie

Each of your questions could be the basis for a full lengthy discussion but I will do my best to explain my thoughts in a brief fashion.

Ownership:In the model that you refer to on your blog you present a structure which I will expand upon.

Service (Capability)- Online Trading, Email, Hosting
System (Technology Solution)- Eagle, Exchange, SAP
Domain (Grouping of like technology components eg: Servers)
Physical IT Component (App, Server, DB,etc.)

Today most organizations have established ownership and accountability for the component and Domain but are struggling to go higher due to the fact that IT organizational design is based on vertical technology silos versus horizontal, Systems and Services.

Yes I have met your Amy’s and they are often called titles such as a Product Manager and do their best to influence and support the system they oversee. However, they struggle to exert true control and accountability over the components of their system that lie outside of the management silo they reside in. I completely validate the need for Amy to involve herself in the IT processes that support Eagle.

Notice that I have never referred to Eagle or PeopleSoft as a Service these are IT Systems and as such are technology solutions that are transient. Amy by this definition is a System and not a Service Owner. However, above this role is A Service Owner which is accountable for a grouping of like systems from both a Customer Engagement/delivery (Service Management) and IT Project/Application Lifecyle (Portfolio Management) set of processes.

Point of Supply & Consumption: Now to your point regarding Service Contracts / SLAs and Incidents.

These three elements will be associated at different levels of the structure based on the principle of Consumption and Supply.

For Example: If the Service is Messaging (capability) and the systems that fall under this category are Blackberry, IM and Exchange then the SLA will have to be at the System Level since these three systems likely do not share the same characteristics and attributes for delivery. However, if there are three systems that support the Service of Power Generation and they all share the same characteristics and are consumed as a group then the SLA can be at the Service Level.

The same principle applies to support contracts. If I have a vendor that provides my complete messaging service then the contract can be at that level. However, if I provide Exchange internally and blackberry externally then the Supplier Contract will be at the System Level.

An Incident or Change Record should by logic at a minimum be associated with the (Point of Consumption / Impact)eg: System and perhaps the physical CI that has failed as well.

Service Portfolio v.s. Service Catalog

I agree completely that a business customer will sign up for a dynamically changing collection of IT Services that comprise their bundled services and offerings. We refer to this as a Portfolio of Services chosen from a Service Catalog for which the business customer ultimately gets the privilege of paying. There is nothing that says there has to be a one to one relationship of Business Process and IT Service. Indeed it is typically the other way around.

Service Management and Portfolio Management: Both represent a set of processes, functions and IT roles. Both are complimentary and need to be understood in relationship with each other in a Service Lifecycle. It is my hope that the next version of ITIL will present an integrated view of these two principles in the Service Strategies and Service Design books which we know are coming soon.

Best Regards

Troy DuMoulin, VP Research & Development | March 7, 2007 at 1:16pm

I think the main disconnect is that the Amys I am talking about are already at the Service Owner level, practically speaking. They are doing “Customer Engagement/delivery (Service Management) and IT Project/Application Lifecyle (Portfolio Management) set of processes” as you state. (I did not mean to say that Amy gets all the Level 1 or Level 2 pages… she’s higher level than that.)

There are of course many ways to structure application support teams; my main point in all this is that while they are not in my view embracing the term “service management,” they are in fact performing its major functions.

It’s mostly about terminology and my core point is that we need to be cautious about assuming that using the terminology of “Service Management” is essential for performing its actual functions. Those can be performed under the terminology of Application Management, with no effective difference in ultimate outcome.

I spoke yesterday to an audience of 80 architects and data managers at Dama/Wilshire yesterday and had broad agreement on this topic. Representatives from many very large organizations indicated in general that they were primarily terming service management related to functional applications, as simply application management. (The term SLA has broad acceptance.)

(DAMA only attracts people from companies big enough to have big data challenges).



Charlie Betz | March 10, 2007 at 12:38pm

I agree with you Charlie

It is the process and activity that are important. I don’t get hung up on titles or whether it is Service Management or Application Management which is responsible for doing the right thing.


Troy DuMoulin, VP Research & Development | March 12, 2007 at 11:49am

There are of course many ways to structure application support teams; my main point in all this is that while they are not in my view embracing the term “service management,” they are in fact performing its major functions.

affordable web hosting | February 18, 2008 at 3:54am

Post a comment