How to define a service

How to define a service in a good way is like asking for how long a string is. It depends is the usual answer.

An example is if we should have one service for warm water and one service for cold water, or have one service that provides both hot and warm waters.

IT solutions often have two different taps. 

The first question we have to answer is what kind of service we are talking about.  Lets take two examples with business services and IT-services. I will not talk about web-services in this article and this is by purpose. 

Business services

Business services offers a value to a customer, either external or internal customers. The question is the level of detail and how to split them. I wrote about different organisation models in an architecture about Architecture governance, and this is a factor to take into account. Should we split business services depending on P&L or use a functional approach instead. 

If we look from a more functional perspective, one good example is from TM Forum and the eTOM process model. Here we have a large number of predefined process entities that could be a business service. The question here is which level of detail we should use.

The picture above show level 1 Customer Relationship Management and some of the level 2 processes within this process. Should we have a business service for all Customer Relationship Management or should we split it into smaller parts.

Example of level 1 and level 2 processes from eTOM

Example of level 1 and level 2 processes from eTOM

For an external customer is it probably easier to have one person responsible for all Customer Relationship Management regardless of channel, product category or what kind of help you need. The crux is if you have different organizations and/or IT-systems for the different parts. 

My recommendation is to have one, and only one person responsible for Customer Relationship Management and define sub business services based on level 2 to better handle issues with organizational responsibility and IT.

Should we go even more into detail? This depends on the purpose with the business services. If they are used as requirements for transformation programs, we have to look at a more detailed level. An example would be Credit Check that is part of Order Handling.

Source: TM Forum, GB921 D release 13 (Process Decompositions and Descriptions)

Source: TM Forum, GB921 D release 13 (Process Decompositions and Descriptions)

If an external party is responsible for authorization of credit, based on a set of rules, then we have to go down to this level. If it should be possible to override an external credit authorization, then we have to go even deeper in the descriptions. But if we have to many business services defined and they are to small, then we will have problem with the governance.

I would not recommend using end-to-end process flows that spans over several process entities. You often have processes entities, e.g.  Customer Interface Management on level 2 that supports several end-to-end processes for fulfillment, assurance and billing.

IT services

To define IT-services in a good way is quite a challenge. The easy path is to define each system as an IT-service. The problem you then have is that you loose flexibility when you want to do changes and you will be cemented in the past.

This is why I would prefer to have a more application neutral definition of IT-services. Either using business services or a model like TAM, also from TM Forum.

Telecom Application Map on the highest level.

Telecom Application Map on the highest level.

These IT-services should neither be to granular in size due to the same reason as business services. 

But what about if your not are in telecom. Try to find another suitable framework and see this as good examples how to do.

Finally, how long is a string? A cable length is my answer.