Search BMC.com
Search

Share: |


From Wiley Vasquez, Director, Proactive Operations Consulting Services

 

Have you already embarked on a service modeling effort?  Are you researching or planning for them?

Most people responsible for IT Service Management have heard or read about services models and the great benefits that are possible.  However, I’ve found that many aren’t fully aware that there are different types of service models for different uses.  One result of this is delayed value realization in their BSM efforts.  So, I’ll cover some ground work on this topic here and I hope you’ll engage in an interactive dialog on this topic.

 

First let us define what a service model is and we’ll add-on from there.  The most simplistic definition is that a service model is a digital representation or grouping of things you have to manage.  We’ll get a little more elaborate as we go, but let’s start there.  By ‘things’ it can be things such as server operating systems, databases, middleware, hardware, storage devices, network devices, etc.  However, a service model can also include non-IT things like business processes, names of software applications, or even building names, department names, etc.  All of these things are typically related.  For example, in a credit card company has a business process for approving or declining credit card applications.  Supporting that credit card application business process there is a lot of software, databases, servers, etc.   So “supporting” or “using” are key to what is meant by relationships. 

 

So to restate, a service model can contain all of the IT things and how they are inter-related as well as the non-IT things such as business process and how they are related to the IT things.  Additional information can be added to this digital representation of the service to enhance its capability and value.  For example, if a server crashes and is not available, how much does that cost?  Or if a server crashes but is part of a cluster is the service it supports really unavailable or is it just impaired?  BTW, this additional impact information is called just that, ‘impact information’.

 

Okay, we now have a basis to now get into the next part of our conversation.

Service Models are useful for many different functions from Change Management and Disaster Recovery, to Business Continuity Planning and Event and Incident Management.  It is the latter Event and Incident Management that we will be focusing on here.  So let’s continue – the types of service models.

 

There are 3 primary types of service models, as follows:

 

FLAT MODELS

Description:  Think of a flat model as a folder that simply contains all of the things you care about without any detailed relationships defined.  If anything fails, the folder goes RED.  The folder could be named for an application, an infrastructure group or a business process, etc.

When to use it:  Flat Models employ basic intelligence for probable cause analysis based on what devices are sending alerts.  So this is useful for organizations just starting out with an event management strategy, or for IT elements that need to be managed but may not be critical to their business.  Flat models are also useful for helping to the determine simple related priority of an incident since it is possible to differentiate between an IT device that is part of a high-priority service and one that is part of a low-priority service.

                Effort to Adopt: Easiest

DEPENDENCY MODELS

Description:  In a dependency model there are detailed hierarchical relationships between the IT components.  This additional detail provides an added layer of intelligence for probable cause analysis so that the offending IT component is identified.   Like the flat model, if anything fails in the model, the consumers of that failed component above it will also go RED.  That is to say if a business process of ‘Credit Card Application’ is defined and something defined under it fails, the Credit Card Application will light up RED.  It is important to note that that trying to manually maintain dependency-only models could be very labor intensive so it should not be attempted without automated discovery technology and a CMDB.

When to use it:  Dependency-only models are used when isolating the specific IT component that is causing the problem.  This is helpful for assigning incident tickets to the right group.

Effort to Adopt:  Medium

IMPACT MODELS

Description:  Impact Models build on Dependency Models but adds the things that can’t be discovered such as:  Impact relationships, Weighting and external event relationships such as transactions, and other passive architecture elements.  Many of these are often the most powerful in reducing MTTR and getting the right person working on the right issue. 

When to use: It is recommended that Impact Models be used for critical services.  The details of impact definitions and details are captured via a workshop.  In these models only relevant and calculated Impacts are reflected up the model.  For example let’s talk about an impact service model that contains a particular server that is part of a cluster of several servers performing the same task for the service.  In this case the fire alarm would most likely not sound for the supported service if there is still availability from the other servers to support the service.  In this case the big benefit is that the proper level of priority and urgency will be assigned to address the issue at the top service.  There will still be an alarmed raised for the individual server but not for the overall supported service.

Effort to Adopt:  Most

BTW, it’s also worth noting that integration to a service desk product is common for each model.  The difference of course, is simply the level of intelligence treatment that goes into forming the ticket.

 

Hopefully you now understand that there are different types of service models and when to employ each to your particular situation.

 

Next time, we’ll delve into Service Models and Cloud environments.

Filter Blog

By date:
By tag:
It's amazing what I.T. was meant to be.