The art of making IT Service Modeling simple

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?”

 

service modeling linear graph.pngHow 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

 

 

 service modeling graph.png

 

 

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.

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.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Gil Tzadikevitch HP Software R&D Service Anywhere
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.