The art of making IT Service Modeling simple – part 2

A post by Gil Tzadikevitch

 

Modeling IT Services as Trees

 

IT Services as trees.pngAs 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:

 

 Service Anywhere trees.png

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.

 

 

 

Comments
chuck_darst | ‎05-08-2014 04:16 PM

Gil,

 

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.

 

 

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.