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

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Jun 7-9
Las Vegas
Discover 2016 Las Vegas
Discover 2016 in Las Vegas, the ultimate showcase technology event for business and IT professionals to learn, connect, and grow.
Read more
Sep 13-16
National Harbor, MD
HPE Protect 2016
Protect 2016 is our annual conference and is the place to meet the world’s top information security talent, discuss new products and share information...
Read more
View all