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

The art of making IT Service Modeling simple – part 2

Gil_Tzad on ‎05-07-2014 11:38 AM

A post by Gil Tzadikevitch


Modeling IT Services as Trees


As I discussed in my earlier post, I believe that we can simplify the task of modeling services by defining a well-defined set of rules for service modeling. This allows the person in charge to concentrate on the “what”, rather than the “how”. Thus, making the modeling an easier task by saving time and pain.


Today I am zooming out and focusing on the modeling of your services as trees and the relationship between these service trees.


Services modeled as trees are easier to read, create and understand (by us mere mortals), because the human brain can easily detect and understand the UI tree. Once we start modeling the services in our organization, using the well-defined model, and trying (as much as possible) to model these services in a tree concept, we start running into a few questions.


#1—How do I model my cross service dependencies?


Basically the well-defined model allows to model usage links between the different service trees (between actual services), and it also allows to model a usage link between a service component to the actual service. Then the question arises: why can’t we model a dependency between a device to another service or service component? (For example, a server that connects to a mail server REST interface). The simple answer is that it’s complicated. Literally, it makes our viewable model extremely complicated, as well as making it very tough for us to maintain these links correctly over time.


By limiting the cross service dependency model, we allow a sane, manageable, high-level model. Because this model is  easily understood by end users (and admins), we decrease the amount of time spent on maintaining the model (server changes, application changes, code changes, etc.) and we have enough knowledge to calculate the risk and priority of ITSM tickets (Incident, Change and Problem).


#2—How do we model large, complicated or multi-zoned services?


When we start modeling large, complicated or multi-zoned services, that may have different SLA’s for different part of the services and also have very different roles or even service zones, we may consider breaking it up into smaller services. We have a few options for these breakups. We can also naturally mix it between the different breakup solutions.

  • The ‘Infrastructure Services’ and the ‘Business Services’. Distinguishing from the low level or internal services (internal REST APIs, databases) to the external ones exposed to our customers (Internal or external). This allows us to easily manage the SLA only on the actual services that require it; yet allows us to easily see and trace impact where required. It also creates a very intuitive hierarchy between the services. This solution is good for complex services, especially ones managed by a large set of people/teams.
  • Splitting to multiple services. For example: Mail Service – New York and Mail Service – London. This breakup allows us to easily set different SLAs to different zones, as well as different service/application owners. This is a very good solution for cases where different teams manage similar services (That might be mistaken to one large service).
  • Two-Level Hierarchy. Defining a top-level business service, that has only ‘Usage’ links to a few low-level business services (This further extends the two-level hierarchy, and allows ‘managing’ only one service.). It’s important to keep this to only two levels, to avoid abusing the strict modeling rules. This solution is good for a service managed by one team, or small set of people, because it avoids duplicating SLAs and process where not required.

Here is an example of a simple bottom up impact analysis view as it would appear in HP Service Anywhere:



I hope you found this post helpful. Don’t forget to try out HP Service Anywhere where you can find many of the discussed modeling concepts built into the application, for easier modeling and viewing of the services. 

Please feel free to share your ideas and experience by commenting on this post.




About the Author


Gil Tzadikevitch HP Software R&D Service Anywhere

on ‎05-08-2014 04:16 PM



Thanks for the interesting post. I understand the traditional uses of service models in change impact analysis and then causality during incident and problem management. I am curious if/how this comes into play with some of Service Anywhere's new capabilities such as hot topic analysis.



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