IT Service Management
Showing results for 
Search instead for 
Do you mean 

The art of making IT Service Modeling simple

Gil_Tzad ‎12-18-2013 10:21 AM - edited ‎09-25-2015 09:16 PM

Post by Gil Tzadikevitch


IT organizations have transferred to being more of a service oriented organization in the past decade. As a result, their focus has shifted from simply ‘managing the IT assets’ into offering and supporting services for the organization. This shift is also forcing IT to redefine what constitutes “IT services”. By utilizing service modeling practices, IT is able to define, model and maintain services and theirdependencies and topologies.


Service modeling is perceived as a complex task—and it is. It involves:

  • Understanding what service modeling is
  • How your organization plans to use it
  • Researching what services your organization currently  has (or wants)
  • Putting it all together into your IT applications


One of the biggest gaps in current applications, that require Service Modeling, is that they do not define how to model your service. Most come with a nice and pretty best practice document that gives you a few starting points; but in the end allows you to link everything to everything (AKA: Free Graph Model). In the end you are left trying to figure which way to model your service from the 2^20 options you have.


The endless versatility that applications offer you with modeling allows each organization to model their service completely differently. If you look at the service modeling of five different organizations, you will hardly find any similarity in how they model the same service. Some companies will create an extremely complex service modeling graph that requires a very long time to define and implement. This format is extremely complicated to maintain over time. Other companies may simply give up entirely and have a plan somewhere in the long term future to model their services—but they don’t want to tackle it today and don’t currently have a plan.


With a goal in mind and a plan in place, anything is possible


I believe that service modeling can be made easier by defining a set of strict guideline rules. First the basic modeling unit should be based on a tree rather than a standard graph. Tree models are easier to read, create and understand (at least by humans).


A set of strict guidelines will also make it easier for the modeler to focus on the service rather than on what graph and connections to model it by. By saving time and the mistakes made by focusing the modeler on the service rather than how to graph it, the service modeling task will be made easier, faster and less “scary”. With the output of a well-defined tree model, it is also easier for end users to read and understand topology of the service and the way it’s used. It also allows automated mechanisms, like workflow engines, to easily define automated rules, because finding related entities is easier in a well-defined tree model (no recursive look-ups required). Using this modeling concept also allows easy impact analysis. The direction of impact calculations are also made easier and allow the user to easily receive the most important information of the impact analysis to better understand “which services may be affected by this change/incident?”


How to apply this knowledge into actual use


One option is to take the set of roles below as a best practice to follow when modeling your services on the HP UCMDB. Another option is to use the HP Service Anywhere for service modeling that applies these rules as part of its modeling standard.


Service modeling that is based on a Tree Concept displays the Service on top.

Components may belong to multiple trees if required.

Service may ‘use’ other services (Dependency between trees).

The tree hierarchy is well defined; each entity can only connect to entities above or below, not to the same level – to avoid and endless recursive graph.

Each entity is well defined

  • Device – the Server/Node/Network Equipment
  • System Element – the Server’s capability exposed to the Service (Application Server, Database Application, etc.)
  • Service Component – a meaningful component of the Service (Web Server, DB, etc.)
  • Actual Service – the service itself, either a Business Service (Exposed outside of IT) or Infrastructure Service (Exposed inside IT). Examples: Mail Service, SharePoint Service






Using a strict service modeling approach saves time on modeling, viewing and integrating with other products. I believe that the move to a well-defined tree model will lower costs and implementation time of UCMDB and ITSM products in the IT world.  I would love to know what you have done to remove the fear of service modeling, if by using the suggestion above or by introducing your own solution, feel free to reach out to me in the comments section below.

About the Author


Gil Tzadikevitch HP Software R&D Service Anywhere

27 Feb - 2 March 2017
Barcelona | Fira Gran Via
Mobile World Congress 2017
Hewlett Packard Enterprise at Mobile World Congress 2017, Barcelona | Fira Gran Via Location: Hall 3, Booth 3E11
Read more
Each Month in 2017
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all