In IT and business, few words are as overused and misunderstood as service. It is like a magic word and can be used to mean just about anything — which makes it almost meaningless.
To illustrate, let’s compare it to the most flexible language ever created: Smurf. The Smurfs are small, blue, humanoid characters who live in a magical forest in mushroom-shaped houses. The Smurfs are the characters of a Belgian comic series that gained world-wide popularity in the 1980s.
The Smurfs have a very distinctive way of speaking. They often replace nouns, verbs, or other parts of speech with the word ‘smurf’ or variations like ‘smurfy’ or ‘smurftastic’.
The smurfs could say silly stuff like this.
A smurf manages an application smurf and offers smurfs to customers. When a customer requests a smurf from the smurf, then the smurf provides a delivery as a smurf to the customer. The smurf then provides ongoing smurfs to the customer for the delivered smurf. The level of smurf a smurf provides is typically described in a smurf level agreement (SLA).
If the above example of smurfication seems familiar, then it is because within business we have our own smurf word. That word is ‘service’. Let’s restate the smurfing paragraph from above using service.
A service manages an application service and offers services to customers. When a customer requests a service from the service, then the service provides a delivery as a service to the customer. The service then provides ongoing services to the customer for the delivered service. The level of service a service provides is typically described in a service level agreement (SLA).
Granted I have for the sake of exaggeration combined as many different uses and meanings of the word service in an as condensed version as possible. However, I have come across all of these uses of the word service multiple times. And there are more. We have Web Smurfs, Smurf-Oriented-Architecture (SOA), Smurf Management and IT Smurf Management, Smurf Providers and Smurf Consumers. Let us not forget the IT Smurf, Software as a Smurf (SaaS), and all the other X as a Smurf (XaaS). Microsmurfs are also popular. We have Shared Smurfs, Background Smurfs, Customer Smurf, Professional Smurfs and the whole Smurf Industry. I almost forgot Smurf Strategy, Smurf Design, Smurf Transition, Smurf Operations, and Continual Smurf Improvement (CSI). I think I might be overly belaboring my point by now.
The word service is used in so many different ways that if often obfuscates rather than clarifies. Its meaning entirely depends on its context — just like ‘smurf’. This becomes a problem when the context is not clear. Too often we assume the context is obvious and few dare to ask the “dumb” question “what do you mean by service?”
I will use pictures to show different contexts where the word service is used. I will show you how the word service have different meanings in these contexts. At the end, I will show how you instead can use distinct and meaningful terms to make things clear and understandable.
Let’s start by breaking down the smurfing smurf paragraph into 5 separate parts.
- [A service manages an application service] and
- [offers services to customers.]
- [When a customer requests a service from the service, then the service provides a delivery as a service to the customer.]
- [The service then provides ongoing services to the customer for the delivered service.]
- [The level of service a service provides is typically described in a service level agreement (SLA).]
1 – A service manages an application service
In the situation where I came across the term application service it represented an actual deployed and running IT system. ITIL, several EA frameworks, and ITSM use the term Application to mean an IT system. Presumably, adding service to make it application service could have been done to differentiate it from software applications that users run on their individual computers. This makes sense, considering an IT system is up and running all the time and continually serves up value through its Graphical User Interface (GUI) or through its expose Application Programming Interface (API). Historically it also made sense because one used to run these applications as windows background services on a windows server.
I prefer the term IT system to represent a system that exists, is up and running, and happens to have been built using information technology. Using the PrimaryScape notation we can represent this using a single structural item. In the PrimaryScape notation blue shapes represent structures, green shapes information, and yellow shapes behavior.
An IT system stores information and does something.
IT systems are not perfect and they are not static. Problems with the IT system occur that have to be addressed. New demands require new changes to the IT system. To run an IT system on an ongoing basis we need people to handle these things.
In the above picture we show an operations team that handles operations and support of the main IT system, i.e. the production IT system. There is a development team that implements new changes. The test IT system is there so that changes can be tested. We have also included a leader that is in charge of this setup.
We can box in this setup to show they are all part of something larger.
This constellation of things is often called an IT service. It is within the IT service where the IT service management processes are realized, such as incident, problem, change, and support management (to mention only a few).
This is the use of the word service that ITIL introduced in the late 1990s and early 2000s. ITIL v2 established the 10 core ITSM processes split into two main categories.
Service Support
Service Delivery
- Incident Management
- Problem Management
- Change Management
- Release Management
- Configuration Management
- Service Desk (function)
- Service Level Management
- Capacity Management
- Availability Management
- IT Service Continuity Management
- Financial Management for IT Services
Even here you can interpret the word service to refer to the IT system or the whole box. The Service Support processes incident, problem, change, release, and configuration all have to do with the IT system but they are implemented “in the box”, by people and other technology. Are these support processes of the larger service box or for the IT system service, aka application service? The same question can be asked about the Service Delivery processes.
So here we have A service manages an application service in a visual context where we can clearly point to the different services we are talking about.
2 – A service … offers services to customers
“A service offers services to customers” can be rephrased as “A service provides service offerings to customers.” A real world example would be a car rental company that offers a car rental service to customers. What we are really talking about is an offering that is made available to potential customers. However, it is not unusual for this to be referred to as a service offering. Appending service seems to lend a sense of legitimacy or importance — regardless of clarity. Quite often people simplify even more and say “we make services available” or “we publish services” when they really are talking about service offerings.
Offerings describes to customers what is on offer and what can be provided if requested. This is typically published in some kind of catalog where users can view what is on offer. This catalog of offerings is for clarity often called a service catalog.
We can represent an offering like this. The green shape shows the offering is just information. It can be described in a document, published on a website, or in some catalog system.
Let’s clarify the different uses of the term service we have now.
We have added service offering to the variations of the word service.
3 – When a customer requests a service from the service, then the service provides a delivery as a service to the customer
Here we understand the customer is actually requesting the offering from the service.
A customer request for a service offering can be received and handled in any number of different ways, depending on different ways of working, different levels of technology and automation, and different levels of integration with shared services (see, I am doing it too).
In our example, let’s make what is offered something relatively tangible and easy to understand. Many IT systems out there use the concept of a project as something virtually tangible that is delivered upon request. Examples of IT system where a project is created for a customer include Jira, MS Project, Asana, Basecamp, GitLab, and OpenShift.
When using the IT system each customer gets its own project that runs in the IT system. We can represent it like this.
What is offered to the customer and the service that ends up being delivered to the customer is a project. These projects have their own independent life cycles and are created, used, and retired based on the customers.
We can represent this in a slightly different way. This will just make it easier to draw the pictures in an understandable way.
The projects only exist because of the IT system. You can think of the projects using the IT system as a runtime platform. This is represented using the functional access or used by relationship.
So let’s bring it back to the bigger picture and show how the project and the customer relate to the IT system and the Service.
Here we show that project X has been delivered to the customer’s location, conceptually speaking. This is just shown as another box for now. In this context it would not be surprising if someone used the term Project-as-a-Service to describe what is going on.
I am using qualifiers to specify the different service terms in this picture.
We are now half way through the smurfing smurf paragraph.
A service manages an application service and offers services to customers. When a customer requests a service from the service, then the service provides a delivery as a service to the customer. The service then provides ongoing services to the customer for the delivered service. The level of service a service provides is typically described in a service level agreement (SLA).
4 – The service provides ongoing services to the customer for the delivered service
After a delivery of a service has been made to a customer, then the customer can contact the service provider (aka the service) for support. The service can include ongoing support related to the delivered service. In our example, the customer received a project and if the customer experiences problems or needs help in doing something then they can contact the service customer service.
We now how yet another use of the term service. Not sure why support is not more commonly used instead of service.
5 – The level of service a service provides is typically described in a service level agreement (SLA)
Service Level Agreements (SLAs) tend to be written later, after the service and system has been set up and offerings publicized.
A service level agreement outlines the expected level of service, but which specific service are we talking about? It is because the term service is used in so many different ways that Service Level Agreements end up looking very different from one instance to another. It depends largely on what the creator of the SLA thinks is the service.
I have seen some SLAs only speak about the IT system and how available it will be (e.g. 99.9%), when it will be down for updates, and what its Recovery Time Objective (RTO), and Recovery Point Objective (RPO) are. Other SLAs focus on how quickly it will take to create and provide the delivery after a customer request of a service offering. Some SLAs focus on what has been delivered as a service, which in our example is the project. Such SLAs will describe what parts, or aspects, of the delivered project the service provider will handle and what the customer must handle themselves. An SLA with this focus typically also include information about when support is available and how quickly support will respond to questions. Some SLAs will describe several different aspect of service levels. What is covered often depends on how some SLA document template was structured.
In Conclusion
The term service has become so overloaded that its usefulness depends entirely on context — context which is too often assumed and rarely clarified. As professionals, we should be deliberate in using meaningful terms, not smurf our way through critical communication.
There are almost always more precise terms that can avoid obfuscation and confusion. One approach is to connect with what actually exists — to describe real structures, actions, and information instead of relying on abstract terms that float freely in jargon.
Through diagrams, we have shown how the many meanings of service can be visualized and made understandable. When we stop calling everything a service, we can start talking clearly about what is really there.
When we combine all the diagrams into one complete picture, one more insight emerges.
That large Service box? It is not a service. It is a collection of people, systems, processes, and information working together — a small operational unit. It is not abstract. It is real.
The word service is not a noun. It describes an action — work performed to benefit another party. That is why we distinguish between products and services. But when we label entire constructs of teams and systems as “services,” we blur the lines between actions and entities.
Let’s take a step back. The box contains a leader, operational teams, IT systems, and relevant information. This isn’t just a service — it is a small company. Or rather, an Operational Company.
This term better reflects the reality: the smallest grouping of tangible, interrelated operational components. An Operational Company cannot be decomposed further without losing its operational identity. Several Operational Companies can be combined into larger groupings, which could also be characterized as companies, but not operational companies.
We can now update our complete picture clearly showing the Operational Company.
Instead of a smurftastic service paragraph, we now have something more grounded:
An operational company (OC) runs an IT system and provides offerings to customers. When the customer request an offering, the operational company provides a delivery to the customer and provides ongoing support. The level of support is typically described in a support level agreement.
Each term in this version has a clear meaning. Each points to something real. And that clarity — more than anything — is what turns confusion into shared understanding.
Let’s be clear. Let’s stop smurfing around.