The content and structure of services

I find the term service here and there when reading about catalogs, delivery, frameworks etc. and i find it difficult to find good descriptions of what the content of a service is and how to structure it. Here are my thoughts.

To describe services seem almost intangible and very hard in practice considering so many is struggling with it. Although, i think it is still possible to apply som structure to the concept without making too hard on yourself. When applying a bit of structure it can be easier to move forward afterwards. I often hear examples of what an IT service might be and there is always references to a description that should clearly state what is included and not included in a service. What it should be and examples of it is harder to find.

If we want to define a service I would assume that it has more than one part. Among those parts there might be some that would be considered as mandatory versus some which could be optional. If we just for the fun of it called these parts service functions. Then we could start from this service function and ask ourself, one by one, what is it for? How is it used? what does it provide? If we have the ability too answer the question, i think that we have a pretty good idea of who the consumer is and how the consumers process looks like when the consumer is actually using our service function. An important point is that we need to understand what parts of the consumer process is our IT service enabling?

I could go even further and say that the service is nothing/empty until one or more service functions are defined. This would mean that we actually define the service through service functions in this case. If a corresponding service function does not exist the service does not cover it. This gives us our first structure.

In the picture we have one service and four service functions. Lets imagine that each of these service functions cover a specific part of a consumers process and all together they enable the consumer to achieve its process outcome. Of course the consumer is probably using other services as well to achieve the process outcome but lets stick to our service to make it easier. The naming of these service functions should correspond with what the consumer is doing. The service should be named corresponding to the outcome the consumer process is achieving. This way communication is easier.

Next we want to group the services. I would guess that there are more customers and consumers that can benefit from a service the more standard the service is. So we should try to group our service in service groups. Lets continue this example with an IT department and a business department/unit trying to define the services for this business unit. One way of grouping the services could be that the business unit is one service group and all services that are specific for and used by this business unit are grouped into one service group. If there are more units working with similar areas and consuming same services it could be beneficiary to add them all to the same group and choose a good name for the group that corresponds to the business the units are performing. This way it is easy to have a discussion about cost, delivery, availability etc. because everything or a majority is applicable for the business unit you are communicating with. The business unit is also consuming more standard services like messaging, communication and service desk. These can be grouped into a service group called shared services or corporate service. The result of this is that a customer will probably consume services from multiple service groups where one will be very close to their core business and the other tend to be more standard services.

That would give us the following picture:

Here you se two service groups with services and service functions. This way it is possible to structure the content of a service with service functions and to group the services in customer segments or service groups even if all consumers are internally in one enterprise or externally.

Create an IT-service in 90 minutes

The task of creating IT-services could be daunting and it seems as many companies and IT departments are struggling with it. I like to simplify things to the point it gets ridiculous and start from there. If this mindset is applied to service and service modeling a couple of questions come in my mind. I think they are fundamental when defineing a Service in its simplest form. One important thing with these questions is that the answers can not be IT guessing. The answers must come from the IT consumer. No interpretation is allowed and I will get back to why I think so.

- WHAT is the consumer doing (in its context and with what applications)?

- WHY is the consumer doing it (what is the end result of the task)?

- What would happen if the consumer COULDN'T do the task at that moment (is it critical or could it be done later or in batch)?

So the header said "in 90 minutes" and that would imply that there is a recipe for achieving an IT-service in 90 minutes. Could it be done? well as I said, I like to simplify things so if you only allow 90 minutes to achieve this that is what you will get. On the other hand if you allow 4 weeks for it I am not so convinced that your result will be a hundred times better so keep it ridiculously short. 

What you will get is a clear understanding of what Infrastructure components are in direct relation to what the business actually do and what the effect is when they are not available. As I see it, an IT-service in its simplest form enabling IT to communicate with the business about services they can identify with and the ability to understand how it is delivered and what IT is contributing to.

Plan the 90 minutes in 2 steps. The first step is to schedule a meeting with a IT consumer that works in the area where you want to start your service modeling. The second step is to schedule a meeting with the technical responsible, probably more than one, of the applications that the consumer is mentioning during the first meeting.

Step one, meeting 30 minutes with the business. The person or persons that are invited should be very familiar with the business process and it is important that they are executing a part of their process. Try to identify a critical step in their process and ask them the three questions. you could end it right here with the answers or continue to ask them the three questions for each step of the business process that they can cover. Keep it simple and scoped instead of trying to cover too much.

Answers from first question: The answers of the first question is what I like to call service functions. Each consumer step is a potential service function. Sometimes multiple answers might be good to add to the same service function depending on the answer related to the depth in the business process. The key here is that the consumer can fully identify herself with the name and description of all the service functions. This still has nothing to do with IT so do not change it in any way to correspond more or less to IT terms, even if the consumer uses a "system" name in it, do not change it. Additionally, every time the consumer mentions a system or application, take a note of it. This will be the base for your second meeting. From a IT perspective the naming of the service functions are completely irrelevant. It could be called anything as long as the business and consumer understands what It is when using it during a follow-up or saying that it is not available for any reason.

Answers from second question: The answer of the second question is used to name the service. The logic here is that all answers from question one that is related to the same answer from question two is same as multiple service functions related to a service. If you merge two services to one then you have to relate all service functions to the new service as well. Important here to keep the business language and the correlation to the business result.

Answers from third question: The answer from the third question is the criticality of each service function. Yes that is correct, the criticality in this case is specified on service function and not the Service. This way they can easily be aggregated to the service when needed. Make it easy and classify the service requests as critical or not. The point here is that critical is a process stop for the business. A service function or business step that can be performed at another point in time is not critical.

Summary of step one, first meeting. Visually now we should have something like this.

We have one (or multiple if you had the time for it) service and at least one service function, hopefully more, related to each service. The service should have a name that completely corresponds to a result that the business is dependent on and should be identifiable by anybody relevant in the businnes. The description of the service must cover all the service functions that are related to the service but no more. The service functions are the content of the service so the service does not enable more than specified through the service requests.

Step two, meeting 60 minutes with the technical responsible (systems and applications mentioned during meeting one). The persons that are invited should be technically responsible or technically involved to the degree that they are able to answer on the technical impact of a service function in their respectively systems. The questions for each service function to the system representatives are:

- Specify any infrastructural equipment related to perform a specific service function. If you need to keep this easy, concentrate on applications installed on servers and the server itself.
- Is the infrastructure equipment critical to perform the service function or not. Can the consumer carry out the service function when the infrastructural component is not available (it might have redundancy or a queuing functionality that does not require full availability) or not.

Summary of step two, second meeting. Now we should have something like this.

Each service function has critical or non critical infrastructure components related. The infrastructure criticality only shows if the equipment is critical for the service function to work. It does not say if the service function is critical to the business. The relationship from the service function to the service tells if the service function is critical to the business. 

If you would use this visual structure when ever planing a change or managing an incident it is really powerful in impact analysis. It tells us clearly what service function a infrastructure component will affect and the meaning of it for the business/consumer. The same goes when a new demand of functionality is requested. It is easy to define if it is an add to an existing service function or a additional service function that needs to be defined and if the existing infrastructures is reusable or need additions as well.

After this first simplified step it is just the rest left :)