Service Modeling Best Practices
White Paper
September 2005
Service Modeling Best Practices
BMC Software7/13/2017
Table of contents
1
2
3
4
5
6
7
8
9
Document owner & history ....................................................................................... 3
Acknowledgements .................................................................................................. 3
References ............................................................................................................... 3
Introduction .............................................................................................................. 4
Disclaimers .............................................................................................................. 4
Concepts review....................................................................................................... 5
Benefits of Service Impact Management .................................................................. 7
Process overview ..................................................................................................... 9
Before you begin .................................................................................................... 10
9.1
Different focuses ............................................................................................. 10
9.2
Bringing business value .................................................................................. 10
9.3
Bringing operational benefits........................................................................... 11
9.4
Bringing business and operational value ........................................................ 11
10
Preparing for the design ..................................................................................... 14
10.1 Scope and terminology ................................................................................... 14
10.2 Agreeing on a model blueprint ........................................................................ 16
10.3 Class and name conventions .......................................................................... 19
11
Service decomposition and modeling ................................................................. 22
11.1 Sources of information .................................................................................... 22
11.2 Selecting a first service ................................................................................... 25
11.3 Entry points to the model ................................................................................ 26
11.4 Decomposition ................................................................................................ 28
11.5 Service impact ................................................................................................ 29
11.6 The main shapers of the service model .......................................................... 31
12
Use cases ........................................................................................................... 41
12.1 Modeling a stand-alone application server ...................................................... 41
12.2 Modeling a database-based application server ............................................... 41
12.3 Modeling a central application used in different places ................................... 42
12.4 Taking into account end-to-end monitoring and SLA/O’s ................................ 43
13
Annex A: sample interview form. ........................................................................ 45
Page 2 of 46
7/13/2017
Service Modeling Best Practices
1
2
BMC Software7/13/2017
Document owner & history
Date
Name
Organisation
Phone
Email
September 28,
2005
Philippe Plomteux
BMC Software
(+32) 2 712 57 80
[email protected]
Date
Version
Description
Editor
Septermber 28,
2005
V 1.0
initial release
N/A
Acknowledgements
Many people contributed directly to the contents of this white paper. Among others :
Zohreh Hosseini, Olivier Pignault, Michael George, Dave Schofield, Jean-Marc Molina,
Jan Merivirta, Markus Dillmann, Karl-Anders Falk, Chris Warwicker, Charlie Tan and
Henrik Erikssonn have provided many of the ideas included in this document.
3
References
The ITIL Service Delivery and ITIL Service Support guides are regularly referenced
in the document. Particular pointers are provided when needed. Wherever possible, ITIL
standards have been applied.
The “Common Data Model” [CDM] used by the BMC Atrium CMDB is very important to
get familiar with as it underlies many design considerations. A good starting point for its
description is the “BMC CMDB Common Data Model white paper”.
The BMC Service Impact Manager product documentation includes valuable
information on the principles of service modeling and service impact management, in
particular chapters 3 to 7 of the “BMC Impact Manager Service Model Development,
Maintenance, and Administration Guide”.
Finally, it is worth looking at the BMC Discovery suite product documentation to gain
knowledge on what type of information is discovered by the Discovery suite and how
this information is instantiated.
Page 3 of 46
7/13/2017
Service Modeling Best Practices
4
BMC Software7/13/2017
Introduction
While BSM is about a lot more than service and service impact management, the
design of service models epitomizes the value BSM brings to any organization: it finally
allows business users, service line managers, the service desk and the IT operations to
have a common understanding of the relationships between the technology (ICT) layers
and the services these deliver.
Therefore, service model design is more than often a highly-visible, highly-impacting
activity that is meant to provide a lot of value in many BSM projects. In other words,
we’d better do it right.
However, even though the general concepts are relatively straightforward and the
purpose quite clear for everyone, the whole discipline is still relatively new and clear
guidelines do not abound in the area.
This white paper proposes a pragmatic, generic and repeatable approach to service
model design. There are virtually no mention of the underlying technology and products
needed to actually implement the service model, only guidelines on how to do it right.
There are not (yet?) rules carved in marble in terms of what is right or wrong in the area,
but the objective of the document is to raise the good questions and identify the main
traps to avoid when doing the exercise of building service models.
5
Disclaimers
The topics covered in this document are pretty much “product-agnostic” and this white
paper is not a “how-to” document addressing implementation considerations.
Only when necessary will references to BMC Service Impact Manager and the BMC
Atrium CMDB be made.
“Service modeling” is a vast discipline in itself. In the context of the present document,
the design considerations are geared towards building service impact models.
Relationships between service impact management and other processes such as
incident, problem, change and asset management will not be addressed directly, even
though service impact management has numerous interfaces with these processes.
Finally, examples and scenarios will in general be taken from the distributed world. The
specifics of mainframe environments are not covered here, but all the described
principles should apply indifferently to any technology.
Page 4 of 46
7/13/2017
Service Modeling Best Practices
6
BMC Software7/13/2017
Concepts review
Service impact management (SIM) consists of the identification, definition, and
management of critical services, their supporting IT resources, and the relationships
between these entities. SIM has the ultimate goal of identifying and analyzing the
impact of IT problems on the critical business processes to ensure continued delivery of
these.
SIM depends on the development and maintenance of the service model. The service
model is a representation of the IT assets (physical and logical components) that
operate together to deliver services and of the critical relationships and dependencies
between the components. It provides a dynamic, business-oriented view of business
services. The service model is used by IT operations staff and business managers to
manage IT and service information from an easily interpreted, graphical view
quickly discover the underlying IT assets that are causing business service
slowdowns or outages.
define and manage the critical relationships between IT assets and business
processes.
quickly determine the impact that an IT problem has on various business processes
and user groups.
integrate real-time IT and service information with the help desk for improved enduser responsiveness and value.
A service model is essentially made up of two broad types of objects:
Components, or Configuration Items (CI), represent the various logical and
physical assets.
Relationships relate the CI together. A relationship describes the impact that a CI
called provider has on another one named consumer. Relationships therefore have
a direction (from provider to consumer) that makes straightforward the construction
of hierarchical models.
From an implementation perspective, other data will be needed to make the actual
service model “work”, but this is beyond the scope of this paper.
A Service Impact Management solution should help answering the following questions:
What is the impact of a technical failure on the business?
What is impacted?
Who is impacted?
What is the priority of a problem compared to others?
Page 5 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
When is the problem going to be fixed?
Who is responsible?
The relative importance of these questions within an organization will give a shape and
focus to the service models, and will also help determine the model “entry points”, as
will be covered in sections 9.1 and 11.3.
Other concepts and terminology will be introduced or reviewed in other parts of the
document, such as paragraph 10.1.1.
Page 6 of 46
7/13/2017
Service Modeling Best Practices
7
BMC Software7/13/2017
Benefits of Service Impact Management
There are numerous benefits in modeling services and using these models as the base
for service impact management. Among others:
Focus on end-users and business functions/processes
The availability and performance of a service could only be measured from the end user
point of view. Availability of all servers is not a guarantee or indication of service
availability. The Service Impact Management approach focuses on the monitoring
requirements of business processes within a company and meeting end-users’
expectations.
Facilitate Configuration and Change Management Processes
Configuration Management is the process of identifying, controlling, maintaining and
verifying the versions of the Configuration Items (CI) and the relationships that link them
together.
Change Management is the process of controlling changes to the infrastructure or any
aspect of services, in a controlled manner, enabling approved changes with minimum
disruption.
From these definitions, it is easy to see how the Service Impact Management process
would help the achievement of these other processes.
Reduce Cost of Managing Services
According to ITIL, managers need to ensure that there is a proper balance between the
quality of service on one side and expenditure on the other. Any investment that
increases the costs of providing IT services should always result in enhancement to
service quality or quantity. The process of identifying services and their relationships to
business processes is the first step to become more efficient in the usage of resources
and quality of service provided by IT.
Identify Gaps in Monitoring
Through Service Impact Management and by building a list of all assets that support the
services, the monitoring gaps would be identified. The relationships that exist among all
components and the business processes they support are a guiding light to evaluation
of monitoring requirements.
Increase Value of IT to Business
By gearing the IT management of services toward the needs and wants of the endusers and support of business processes, IT managers would be able to show the value
that IT brings to the business. That also helps to improve relationships with satisfied
customers through improvement of services provided. A model of business services
supports decision making on IT investments, and priorities are better managed because
IT investments are now more easily related to the business value of the services they
support.
Page 7 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
Service Level Management & SLA
For the purpose of creating a Service Level Agreement (SLA), IT is required to identify
company’s business functions and processes and the services it provides to support
them. Service Impact Management effort provides IT with means to evaluate its own
capabilities and the level of service it could offer to its customers.
Service Desk Management (End-user communication)
Service Impact Management considers proactive capabilities that IT Service Desk can
gain by having knowledge of interdependencies of business functions and processes
with IT Services and their components. As an example, in case of server or application
breakdowns, from information within a Service Model, Service Desk could find who is
affected by the service degradation and provide that information to end users through
web, phone messages or e-mail and reduce number of calls to the Service Desk.
Business Continuity Management / Business Impact Analysis
A key driver in determining IT Service Continuity Management requirements is how
much the organization stands to lose as a result of a disaster or other service disruption
and the speed of escalation of these losses. The purpose of a Business Impact Analysis
is to assess this through identifying critical business processes and the potential
damage or loss that may be caused to the organization as a result of a disruption to
critical business processes. Due to its nature, a Service Management effort to identify
services and their interdependencies (i.e. in the form of a Service Model) would help the
organization in these Business Continuity Management and Business Impact Analysis
efforts.
Availability Management / Component Failure Impact Analysis
From the ITIL definition of Availability Management1: “The goal of the Availability
Management process is to optimize the capability of the IT Infrastructure, services and
supporting organization to deliver a cost effective and sustained level of Availability that
enables the business to satisfy its business objectives.
This is achieved by determining the Availability requirements of the business and
matching these to the capability of the IT Infrastructure and supporting organization...
Availability Management should ensure the required level of Availability is provided. The
measurement and monitoring of IT Availability is a key activity to ensure Availability
levels are being met consistently. Availability Management should look continuously to
optimize the Availability of the IT Infrastructure, services and supporting organization, in
order to provide cost effective Availability improvements that can deliver evidenced
business and User benefits.
The capability of the Availability Management process is positively influenced by the
range and quality of methods and techniques that are available for deployment and
execution within the process.”
1
See the ITIL Service Delivery Guide, chapter 8, Availability Management
Page 8 of 46
7/13/2017
Service Modeling Best Practices
8
BMC Software7/13/2017
Process overview
The remainder of the document will detail the different steps of the service modeling
process. This section outlines the main phases, which will be covered in detail in the
rest of the document.
Before you begin
This is part 9 of the present document.
Identify the primary focus (operational benefits and/or business value) of the
service models. The shape of the model will be influenced by the chosen focus. This
is discussed in section 9.1.
Identify the main stakeholders and users of the service model/service impact
management solution. Both focus and stakeholders will determine the “entry points”
to the service model [section 9.4].
Preparing for the design
This is part 10 of the present document.
Nail down terminology and concepts before they are used. Refer to ITIL for terms
and definitions [section 10.1]
Agree on a model blueprint that will apply to all service models. The model
blueprint acts as a template to the construction of the different service models
[section 10.2].
Adopt class and naming conventions [section 10.3].
Service decomposition and modeling
This is part 11 of the present document.
Inventory and use all sources of information available [section 11.1]
Prioritize the different to-be-modeled services. Priority will mainly depend on impact
and urgency of the failed service/process [section 11.2].
Identify the entry points to the service model(s). These determine the top-level
objects within the model [section 11.3].
Proceed to business process walkthrough and start decomposition, keeping in
mind granularity, hierarchy and modularity benefits in the construction of the model
[sections 11.4 through 11.6].
Page 9 of 46
7/13/2017
Service Modeling Best Practices
9
BMC Software7/13/2017
Before you begin
9.1 Different focuses
The first factors that will ultimately scope and shape the future service models are to be
found in the overall objectives and added value that the organization wants to achieve
when these service models are designed and implemented.
Typically overall objectives could be filtered out of a Business Plan, a Balanced
Scorecard, the existing Corporate/IT Governance characteristics and structures and/or
an IT strategy plan.
The service model provides vital information in continuously aligning IS with the
business to achieve the overall business goals in an organization. The most important
step involved in organizing a service model is balancing the weight of IT resource
availability against the weight of business needs from the service impact solution.
To do this, the IT or IS group must engage the business managers to define short term,
mid-term, and long-term goals for service impact management in the enterprise. These
goals should determine the design and development of all deliverables for all other
service model development phases.
Business value and operational benefits of the project are the obvious targeted goals,
but their relative importance can differ from one organization to the other.
9.2 Bringing business value
Bringing Business value in the context of Service Impact Management is about:
better end-user productivity
minimizing the business and financial impact of service disruptions
knowing when technical problems impacting the business/service will have a
resolution
better communication between the IT and the business, with pro-active notifications
from the IT in case of service disruptions.
Customers primarily looking for “business value” will usually have Line-Of-Business
(LOB) Managers as the principal stakeholders and sponsors of such projects.
The primary users of service model and service impact information will be business
users and LOB managers.
In this situation service models are likely to be more “business-focused”, in the sense
that particular attention and detail will be paid to the definition of the business layers, i.e.
business function and process decomposition.
Page 10 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
9.3 Bringing operational benefits
Increasing operational benefits in the context of Service Impact Management is about:
understanding the interrelationships between the ICT layers and the services they
provide
prioritizing top issues and assigning the right resources to these issues.
proactively informing users of service impacts
integrating service impacts in all IT management processes, such as incident,
problem, change and asset management.
providing vital information to ensure availability and recovery design criteria.
IT operations and service desk will be the principal stakeholders and sponsors when the
primary objective is to increase the IT operational efficiency of the organization.
In that case, the service models will usually include a fine-grained decomposition of the
ICT layers, with a strong focus on the different IT elements and their dependencies.
9.4 Bringing business and operational value
Obviously, most organizations will try and maximize both values – increasing at the
same moment both operational and business efficiency through the exercise.
It is in conclusion worth raising the following questions before going further:
Who are the sponsors and stakeholders?
Are roles and responsibilities identified?
Who will use the service model/service impact information?
What will the model be used for?
Figure 1 below may help identifying the different needs and focuses of the potential
stakeholders. On the vertical axis the main levels of focus are presented (for a definition
of the terms Business Domain, etc, please refer to paragraph 10.1.1), while on the
horizontal axis we find the main possible user groups of the Service Impact
Management solution. A square ticked in green circle is a clear entry-point, while a
simple tick shows a potential match.
.
Page 11 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
Customers
Service Managers
IT Operations
IT Support
√
√
√
Business
Function
√
√
√
√
Business Process
√
√
√
√
√
√
√
√
√
√
IT Service
IT component
Service Desk
Business users
Business Domain
Figure 1
According to the final “balance” achieved between business and IT focus, the service
models fall into 3 broad categories, as illustrated in the figure 2 below. The first diagram
on the left side illustrates a “IT-focused” model, where the ICT layer predominate, while
the diagram on the right presents a model where the focus is on business. Finally, the
central diagram shows a model where business and ICT resources are balanced.
Page 12 of 46
7/13/2017
Service Modeling Best Practices
Business
Resources
IT Services
BMC Software7/13/2017
Business
Resources
IT Services
IT
Resources
IT
Resources
Business
Resources
IT Services
IT
Resources
Figure 2
Note that there is no “preferred” type of model among these three broad categories. The
objectives, audience and constraints of the organization will ultimately dictate which
option or mix of options to follow.
Best practices
Identify the primary focus of the organization in doing service impact management
Identify the main users of the service impact management solution
Determine the different “entry-points” [see section 11.3] for the service model
Define your model blueprint [see section 11.2] according to this focus
Page 13 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
10 Preparing for the design
This section describes some important preparatory work to go through before any of the
model design starts.
First, we need to nail down terminology and concepts, so that all stakeholders are sure
to speak the same language.
Second, the organization should agree on a model blueprint, which will act as a
blueprint for the service models and will ensure consistency and repeatability of the
process.
Finally, name and class conventions should be considered.
10.1 Scope and terminology
The considerations from the previous section on the focus of the service model (see
figure 2) should already help outline the scope and focus of the service model.
Another capital, pre-required step before moving on is to nail down the definitions of the
main concepts and terms used throughout the exercise. The list below may help
clarifying over-used terms.
While most of the following explanations are accepted and used industry-wide, the
important point to take home is not so much these definitions than the fact that
definitions must exist.
10.1.1
General definitions
The following list, mostly taken from the ITIL library2, can help the organization agree on
the main concepts and terms.
Business Domain
This is an entire business area where the organization is active. It is also known as its
core competencies and represents the highest level of business process decomposition,
e.g. Plan and Develop Products and or Services to do X.
Business Function
This is a group of business processes that constitute a specific function such as
customer support or sales. This represents the second level of business process
decomposition.
Business Process
Business Process is a group of business activities undertaken in pursuit of a common
goal. A Business Process may have dependencies on several Business Functions and
also other Business Processes.
This represents the third level of business process decomposition.
2
See e.g. the ITIL Service Support guide, appendix C: glossary.
Page 14 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
Service
The ITIL definition for Service is ‘one or more IT systems that support or enable a
business process. In other words, Service could be defined as ‘all IT resources required
for the functionality of a business process’.
The service can be composed of multiple applications, databases and infrastructure
components.
A Service is the end-to-end technology infrastructure that enables one or many
business processes to be performed.
Typically an IT Service will have a Service Level Agreement (SLA) to specify its agreed
serviceability.
IT System
IT System is a group of software/hardware components to provide specific functionality
in support of one or more Business Processes and included as parts of IT Services.
They are the logical building blocks of an IT Service.
Typically an IT System will have an internal (to IT) Operating Level Agreement (OLA) to
specify its serviceability.
IT Component
A component is a physical or logical asset required to support one or more Systems,
e.g. an Application, a Server, a Database, a Network Router. Components can be
‘contained’ within other Components to the required depth to cater for asset
management needs, e.g. a Server contains a Disk Caddy which contains a removable
Disk.
10.1.2
Defining IT Components
Physical components themselves must also have a clear definition. It is quite often
assumed that the concept of “application”, “system” or “network” (to name just a few) is
understood and clear, while it has a very different meaning from one organization to the
other.
An “application”, for example, can be seen as an entity including many different
components, or simply a process running on a single computer system.
The way to follow remains similar: all IT components must be clearly defined to avoid
confusions in the model construction.
Tip: A good starting point for the definition of the different types of components is the
“CMDB Common Data Model reference” (in HTML format) which ships as part of the
document of the BMC Impact solutions.
Page 15 of 46
7/13/2017
Service Modeling Best Practices
10.1.3
BMC Software7/13/2017
Defining other concepts
Any other frequently referenced concept must also have a clear definition. In particular,
and looking towards the implementation, severity levels should have a clear definition. A
good starting base would be the “severity level index” reproduced below, which would
describe the different severities that the state of an IT or Business process can have.
Severity Level Index
Severity Levels
UNAVAILABLE
IMPACTED
MINOR
WARNING
INFO/OK
Definitions
Permanently Disabling
Critical End User Dissatisfaction
Causes Degradation of Service
Causes Inconvenience/Annoyance to End User
Not Noticeable by End User
Best practices on terminology
Use ITIL definitions whenever applicable.
Define all concepts and clearly communicate on them.
Come back to these definitions in case of conflict or debate.
Enrich these definitions to avoid any ambiguity.
Align the definitions of IT components with the definitions of the BMC Common Data
Model.
Define a severity level index.
10.2 Agreeing on a model blueprint
Based on the agreed focus and terminology, entry points and scope, a general
structure, or model blueprint, of the future service models should be derived.
For consistency, repeatability and clarity purposes, the designed models should share a
common layout.
Agreeing and complying with a pre-defined model blueprint will greatly help in that area,
at the same time simplifying and speeding up the process by making it highly-reusable.
A model blueprint applied in the service impact management context will typically
impose:
a strict hierarchical organization of the CI in the model (see also paragraph 11.6.2 on
that topic).
that CI of a same type or class should be grouped (as much as possible) at the
same level within the model.
that certain types of CI cannot be related to others, and that a model includes a
fixed, well-defined number of ordered layers.
Page 16 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
the allowed CI types that can be defined at the different levels of the service model.
The following diagram presents on the left side a model blueprint that organizes the
different type of objects as defined in paragraph 10.1.1.
On the right side, what could be corresponding CI instances in the example of a home
banking environment.
Figure 3
Depending on the focus and the level of detail required [or not], the organization may
choose to use a model blueprint that does not necessarily cover all layers upfront (even
though the blueprint and the models could be enriched as the solution grows), but rather
introduces other types of objects to meet specific viewing requirements [see
business/technical views in paragraph 11.3.3].
The following illustration shows an example model blueprint where user communities
as well as sites and SLA are also represented in dashed boxes. The text in the boxes
shows the name of the CDM classes that should be used for instantiation [see class
conventions in paragraph 10.3.1].
Page 17 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
Figure 4
Best practices on the model blueprint
The model blueprint should have the following characteristics :
it imposes a strict hierarchical organization of the CI relationships
it defines that CI of a same type (class) should be as much as possible be at the
same level.
it defines the layout of the different levels of the service model.
it defines the possible CI types [classes] that can be defined at the different
levels of the service model.
Use the design of a first service model to refine and validate the model blueprint.
Make sure that the blueprint allows the different stakeholders to access the model
according to their own standpoint [in figure 4, the model can be accessed from a
Business Process/User Community, a geographical an SLA standpoint]
Use subsequent designs of service models to validate the “universality” of the model
blueprint. This possibly will lead to amendments to the initial model blueprint.
Allow for some flexibility in the model blueprint, not all models may exactly fit a
model blueprint which imposes a fixed number of layers.
Page 18 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
For the modeling of an IT service, between 4 and 6 layers of CI are generally
sufficient.
The IT layers (IT System/IT components) may be automatically instantiated using
e.g. BMC Discovery suit. Make sure that the model blueprint an d class conventions
[paragraph 10.3.1] comply with the integrity constraints introduced by the Discovery
suite3.
10.3 Class and name conventions
Although these considerations mostly apply to the implementation phase, it is worth
thinking of a consistent way of classifying the different components of the model and of
naming these same components.
10.3.1
Class conventions
The BMC Atrium CMDB relies on a Common Data Model (CDM) which defines a certain
number of component (asset) classes available to classify the CI instances. The CDM is
itself based on the industry-standard CIM model, which has been produced by the
Desktop Management Task Force (http://www.dmtf.org).
Familiarity with the available classes and associated attributes on one side and with the
adopted terminology on the other side will greatly help setting up a “mapping table”
where the different CI to instantiate have a corresponding CDM class.
An important note towards implementation: Many of the classes of the CDM can be
instantiated using the BMC Discovery solutions. As the discovery solutions introduce
constraints on the classes of objects that can be linked together, it is not recommended
to manually instantiate these classes. Check the BMC Atrium CMDB and Discovery
Solutions product documentation to verify which CDM classes can be automatically
instantiated.
Examples
The following table gives examples of possible mappings between the adopted
terminology and the classes available in the CDM.
Type of component
Business Process
3
4
CDM class
BMC_BusinessProcess
Icon4
Check the BMC Discovery suite product documentation for more information.
Default icon in BMC Atrium CMDB 1.1
Page 19 of 46
7/13/2017
Service Modeling Best Practices
Type of component
Service
CDM class
BMC_Service
IT System
BMC_Group
application server
BMC_ApplicationServer
physical server
BMC_ComputerSystem
other infrastructure
components
(various)
BMC Software7/13/2017
Icon4
(various)
While the product allows for bespoke extensions of the CDM, they should in any case
be kept to a strict minimum to avoid maintenance issues during product migrations or
upgrades.
Best practices on class conventions
Identify the different CI types that the model will contain and make sure there is a
corresponding CDM class associated to each CI type.
Even if they are irrelevant to a given environment, do not delete classes and
attributes defined in the CDM. Leverage on previously defined terminology and
concepts.
For CI that will be manually created (typically, the logical objects of the model), use
classes that are not instantiated by the Discovery solutions.
Double-check that a class/attribute does not exist yet before deciding to create it in
the CDM. Keep changes to the CMDB data model to the minimum.
10.3.2
Naming conventions
In a similar fashion, a naming convention should be defined for the names and aliases
of the created CI. All CI types should have a well-defined naming convention attached.
Typical examples are:
1. “A CI of class BMC_ComputerSystem has a name made out of the lowercased
fully qualified domain name of the system”
Page 20 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
2. “A CI of class Service has a name made out of the “svc_” prefix, followed by the
CamelCase notation of the service name as defined in the service catalog”.
Some good questions to ask in that area are:
What existing naming convention, e.g. coming from an existing asset management
application, is in place and how can it be used/extended in the context of Service
Impact Management.
What is the name structure for a given CI type? For example, the name could be
built on the template :
<customer name> / <service> / <item>
Should the name reflect the type of the CI? (This may look as redundant information
but may help for sorts, lists, searches, etc.)
Should manually created (as opposed to automatically discovered) CI wear a
specific prefix/suffix indicating their manual origin?
What is the separator between words? It is supported but not recommended to use
space characters in names.
Is there a convention on casing (lower case, upper case, CamelCase, etc)?
Best practices on naming conventions
Have one.
Assess existing naming conventions and try to use them.
Use a naming convention that is consistent across all CI types.
Keep names humanly readable, that is their only purpose. Use “aliases” instead to
hide the “ugliness” of event association.
Page 21 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
11 Service decomposition and modeling
With the preparation work described in the previous section done, we can move on to a
more detailed discovery and decomposition of the services down to the underlying
infrastructure.
The main points covered within this section include:
assessing the different sources of information within the organization
considerations on how a first service is selected within the organization.
making sure that the “entry points” of the service model are identified.
reviewing the main steps of service decomposition.
11.1 Sources of information
One of the main challenges of the service modeling process is certainly to gather,
confirm and make the synthesis of disparate, and sometimes unstructured, sources of
information within a given organization.
This should be seen as another added value to the process. Translating information that
is often “within the heads” of a few people into structured service models highly
contributes to the consistency and durability of the knowledge and its diffusion across
the enterprise.
11.1.1
Interviews
The data on business processes and IT Services are collected by interviewing the
proper resources.
Depending on the service identified for monitoring and management, the list of people
to interview might differ. As an example, if the monitored service is email and the
application used is MS Exchange, then anyone who is responsible for any components
within the MS Exchange environment would be a candidate for interview. The purpose
of interviews would be to identify critical services within the environment and based on
that to identify the service components and their functionalities, availability and
performance parameters, failure points, cause and effects of failures, prevention and
detection options.
Annex A at the end of the document contains a simple list of typical questions to ask
when it comes to identifying and gathering information on business or IT services.
Page 22 of 46
7/13/2017
Service Modeling Best Practices
11.1.2
BMC Software7/13/2017
Documents
The Service catalog should be the authoritative document where the different services
are defined and related to others in the organization.
Service Level Agreements are other reliable sources of information as to find the list of
IT Services and their components.
A SLA is a written agreement between an IT Service provider and the IT customers
defining the key service targets and responsibilities of both parties.
Operational Level Agreements (OLA) are internal agreements covering the delivery of
services which supports the IS organization in their delivery of services. OLA should set
out specific back-to-back targets for support groups that underpin the targets included in
SLA. For example, if the SLA includes overall time to respond and fix targets for
Incidents (varying on the priority levels), then the OLA should include targets for each
of the elements in the support chain (target for the Service Desk to answer calls,
escalate etc, targets for Network Support to start to investigate and to resolve network
related errors assigned to them). OLA therefore describe the required availability of an
IT Service or component to perform its required function.
Business process models usually come under the form of diagrams and show the
decomposition of a business process into different steps, complete with their
interdependencies and branch statements, if any. Business process models convey
invaluable information when it comes to building service models.
Figure 5 gives an example of a typical way business processes can be represented.
This particular Business Process describes the different steps for a Customer Sales
Representative (CSR) to handle customer requests over the phone in a retail
organization.
CSR lookup
order
CSR create
order
CSR update
order
yes
Automatic pickup
phonecall
customer
Automatic lookup
customer
information
CSR takes
phonecall
customer
CSR close
order
no
Next action
CSR ends
phonecall
customer
CSR lookup
customer
CSR update
customer
CSR lookup
product
Figure 5
Page 23 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
Application topology diagrams are a quite usual source of information when it comes
to analyzing the ICT layers of the model. A topology diagram will usually show the
interconnection of the main IT components (servers, applications, databases, etc) of the
important enterprise applications. Figure 8 gives an example of a (very simple)
application topology diagram.
Organizational Charts are very important in the sense of identifying the right contacts
and sources of information. The approach should be to initially contact top managers to
receive buy-in and enforcement needed to get time with key personnel. The chart also
represents the organizational structure of the company that is helpful for identifying
Business Functions within the company.
Disaster Recovery Plans are also important source of information when trying to
identify the service components within IT environment. A disaster recovery plan should
include a list of IT assets, owners, and locations at a minimum and maybe user groups
or dependencies and relations to business processes. These data could be transferred
over to an asset management tool or database and used for the Service Modeling.
Help Desk / Support Databases & Documents could be used as sources of
information on IT assets. By reviewing these records, the more critical areas could also
be identified through number of high severity cases opened. The relation between IT
Components and Business Processes could also be identified within support calls by
correlation and filtration of events or cause and effect analyses.
Purchase Orders are basically a list of all IT assets purchased by the company and the
purpose of the purchase might also be included in these records as in what service they
were intended for. This would be last resort if data were not available through other
sources.
11.1.3
Other sources of information
An existing asset management application or CMDB will obviously be a good starting
base, not only in terms of data population, but also to help to determine naming
conventions and such.
Page 24 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
11.2 Selecting a first service
At the start of a service modeling engagement, or during a Proof-of-Concept, it is
important to carefully choose which service or business process will be modeled.
There are two main aspects to consider what the most critical processes in the
organization are: their respective impact and urgency. First of all, the nature of the
process will usually give it an inherent impact:
Impact
Usually, the processes directly related to cash-flow generation (customer-oriented
processes) are considered as the most important, as their unavailability has a direct,
immediate impact on company revenues and image.
Processes related to the generation of “tomorrow’s cash flow”, such as development,
marketing, R&D and the like will come in second place, followed by all other internal
processes of people, technology and planning management.
Urgency
Other factors come into play to determine the priority of a given service or process. To
name a few, the internal and external visibility (e.g. a highly visible customer service),
the competitive position and political awareness of the service, identified pain-points in
the current delivery of the service, operational needs and funding possibility will have an
impact on the final priority ranking of the different services.
The following figure gives an example of how impact and urgency can be combined to
determine service priority.
medium
low
Urgency
high
Business Services
Importance Rating
1.Metering
2.Invoicing
low
medium
Impact
high
3.Output-Services
4.Distribution
5.Call Centre
6.Payments
Figure 6
Page 25 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
Other factors
Other factors such as the complexity of the service (starting with a “simple” service will
ensure a smoother learning curve), the completeness of ITSM capabilities for this
service (e.g., is it well monitored from an ICT availability perspective) should ideally be
taken into account at this stage.
A careful weighting of these different aspects combined with the overall Corporate/IT
Governance information and IT strategy plan should be a solid basis for a discussion
with the key stakeholders to finally identify which services to pick up.
11.3 Entry points to the model
An “entry point” of a service model is a point selected to start the service decomposition.
Identifying the entry point(s) of the future model is a pre-requisite to the decomposition
exercise.
Different factors once again will affect the decision.
11.3.1
Business versus Technical focus
The focus of service impact management within the organization as discussed in part 9
of the document will usually dictate the “level of entry” of the service model.
If the primary focus is on the business, the entry points will most likely be the different
business processes and the different user communities or customers who actually use
these business processes. The need to take into account Service Level Agreements
may also dictate that models be constructed from the point-of-view of these SLA: In
many cases there will be a need to combine both business and technical views. A
service may for example not be impacted by a technical failure because this failure
occurs outside service hours, but there will still be a need to visualize the technical
failure so that it can be detected and fixed before the service is expected to be available
again.
In the case of a more technical focus, IT services, applications and geographical entry
points will commonly be elected.
11.3.2
Target audience
The different user groups of the final solution will also influence the different entry points
to select when constructing the model. EG, Service support staff will have different
needs from operations and business users.
It is important to remember that the underlying technology (BMC SIM and the BMC
Atrium CMDB) will allow for a mix-and-match of these different entry points according to
the exact needs of the organization. There is no exclusive choice to make in that
respect.
Also, do not forget to align the selection of entry-points to the model blueprint discussed
in section 10.2.
Page 26 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
Refer to figure 1 in section 9.4 for more details on the correspondence between target
audience and entry points.
11.3.3
Deriving business and technical views
In many cases, especially if the target audience is diverse and includes stakeholders
from the business and technical sides, the organization will desire different viewpoints
on the same set of components: LOB managers and business users will want a view on
the business processes, while IT operations will want a view organized around sites
[datacenters, etc] or IT services [network services, middleware services, etc].
The model blueprint should allow for different grouping of the CI [and therefore
visualization], as in the example of figure 4 where the whole model blueprint has been
reproduced in the box at the top.
Box 1 presents a typical “business” entry point. The entry point is the Business Process
level, drilling down towards the technology layers.
Box 2 presents the geographical standpoint: the entry point is the region, drilling down
towards the sites and the different services that are available there.
Box 3 presents the technological standpoint, where the different technology
components are grouped according to their type [servers, databases, etc.]
Figure 7
Page 27 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
11.4 Decomposition
Knowing which services to model and what the various entry points to the service model
are, we can proceed to the service decomposition itself. This section covers the global
methodology to adopt, while the following section on the shapers of the service model
will give more detailed information on how to design the model itself.
11.4.1
Business Process Walkthrough
Considering that business processes are identified as entry points of the model, the key
objective of the business process walkthrough is to trace the sequence of activities
necessary to the execution of the end-to-end process. With the help of the end-users or
business owners, the different activities (process steps) of the process or service are
identified and described.
In a recursive fashion, each process step can be decomposed further in its
dependencies towards IT services.
The top-down approach
It is essential that the iterations of the walkthrough follow a strict “top-down” approach,
i.e. that we start at “the top” of the model, i.e. the identified entry points, and walk our
way down to the ICT layers.
Proceeding so will ensure:
that we work from the view point of the business
that all elements making up a business process or service are accurately covered
that the decomposition, especially down to the ICT layers, is truly cross-domain and
not silo-oriented
that, having in mind the implementation phase, gaps in the monitoring solution can
be identified
Starting in the middle
The top-down should be favored in any case, however in more complex situations this
task can be daunting and the overall learning curve quite steep, so a good compromise
will consist in “starting in the middle”, i.e. start the decomposition and analysis at the
application or IT service level, build their model, and only afterwards start modeling the
services and processes that depend on these applications.
This technique will usually yield quicker results and value (as the model of the
applications and services can be done and used quicker), and help the organization to
refine its service modeling process before moving on to more ambitious tasks.
Page 28 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
Best practices on the business process decomposition
adopt different view points (end user, service manager, service desk) to identify the
visible and invisible parts of a business process
achieve understanding of the business process by following its real execution by the
end users.
assess whether or not a given process step is IT or non-IT related.
always adopt a top-down approach : from the business or IT services down to the
ICT layers
start in the middle for complex cases
keep your decomposition steps and terminology aligned with the model blueprint
use hierarchy, granularity and modularity to give shape to the model
11.5 Service impact
After the services and business processes have been decomposed down to the
technology layer, it is important to assess if, how and when the technical components
actually impact the services or business processes.
The purpose of this assessment is to determine (looking towards implementation) the
intensity of the impact relationships, and whether status computation should include
cluster or weighted logic5.
Input from Incident/Problem Management Database is usually very helpful to relate
service impact to component impact. The ITIL documentation for Availability
Management also contains very useful techniques that help identify the causes of
service and business impact.
For example :
Component Failure Impact Analisys [CFIA]
The purpose here is to predict and evaluate the impact of component failure on service
availability.
From the ITIL Service Delivery guide, Availability Management, paragraph 8.9.1 :
“CFIA achieves this by providing and indicating:
the impact of component failure on the business operation and Users
component and people dependencies
component recovery timings
the need to identify and document recovery options
5
For more information on this, check the BMC Service Impact Manager product documentation
Page 29 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
the need to identify and implement Risk reduction measures.
single points of failure that can impact IT Availability
The above can also provide the stimulus for input to IT Service Continuity Management
to consider the balance between recovery options and risk reduction measures, i.e.
where the potential business impact is high there is a need to concentrate on high
Availability risk reduction measures, i.e. increased resilience or standby systems.”
For more details, check the ITIL Service Delivery Guide.
Best practices on business impact analysis
use a systematic approach such as CFIA or BIAT to relate component unavailability
to service impact.
use the incident/problem management database as a source of information
familiarize with the status computation capabilities of BMC Service Impact Manager
continuously refine and improve the service impact model. It is likely that not all
possible impacts are taken into account in the first version of the service impact
model.
Page 30 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
11.6 The main shapers of the service model
In this section many important considerations that ultimately give shape to the service
model will be covered. Once again there are no absolute answers or guidelines that can
fit all contexts and all organizations. However we hope to help raising the right
questions and avoiding the main traps in the process.
11.6.1
Overview
Identifying the stakeholders and users of the solution will determine the main entry
points and granularity of the service model. Technical users will want a model where the
different ICT layers are presented and detailed, while business users will want a model
where the different business processes and services are represented.
The previously defined model blueprint will dictate the instantiation of a strict
hierarchical model, built following a top-down decomposition, where modularity brings
several benefits.
11.6.2
A hierarchical model
The case is quite clear: there is no other way than thinking your model from a pure
dependency standpoint, rather than from a topology one.
The confusion can especially arise in the technical layers of the model, where people
are more inclined to think in a “what is connected to what” mode, rather than “what
depends on what”. Many sources of information that are available when modeling the
ICT layers, e.g. “application architecture diagrams” and the like, will show a pure
topological layout, and a translation work must be done to switch to a hierarchical
representation.
Example
Let us consider the following naïve example, where a online banking application, must
be modeled to determine the availability of the functions the application proposes, e.g.
money transfer over the internet – see figure 8 below.
Page 31 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
Web Server
Internet
Firewall 1
Firewall 2
Database Server
Application Server
Figure 8
A dumb translation of the above architecture diagram would yield a topology-based
service model, where the different elements are chained exactly as in the architecture
diagram, as in figure 9:
Figure 9
While the impact of the failure of any of the technical CI on the “Money Transfer”
Business Process CI would correctly be computed, the other impacts along the chain
would be plain wrong:
Does a failure on the database really impact the firewall? Er. No.
Rather, the availability of the application of the Money Transdfer is the addition of the
respective availability of each technical component, so a hierarchical representation is
therefore needed. Figure 10 shows a hierarchical representation of one business
process sitting on top of the application infrastructure shown above. In this diagram the
availability of the services and processes is the sum of the separate availability of each
technical component. Note also that the model has been aligned to the blueprint
example of figure 4, as presented in the blue boxes next to the model.
Page 32 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
Figure 10
A note on model simplification
Sometimes the temptation to simplify the model arises, for would-be clarity and
representation purposes. This is typically the case when many CI depend on a common
other CI. For example, a given IT service could be decomposed into different IT
systems, each of them depending on a basic IT system such as the naming service
(DNS), as in figure 11 below, which presents the accurate impact dependencies : the
unavailability of the DNS system impacts all other systems, and ultimately the
depending service.
Figure 11
Page 33 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
A common temptation in such a case is to simplify the model by placing the DNS
system as direct provider for the IT service, as in figure 12. Doing so reduces the
number of relationships to create and maintain.
This approach is not recommended: the dependency model is not correct any more and
will, once instantiated, give incorrect results when looking at the availability of the
different systems.
Figure 12
Best practices for building a hierarchical model
Use topological diagrams with caution. Do not translate topological relationships
literally. “connected to” does not mean “depends on”.
Simulate how impacts propagate in the model you build. Ask yourself if a propagated
impact makes sense by questioning the model: “Is it really the case that if A is down,
then B is also down?”
Do not simplify the model, especially if OLA/SLA are attached anywhere in the
model
Page 34 of 46
7/13/2017
Service Modeling Best Practices
11.6.3
BMC Software7/13/2017
What granularity?
By granularity, we mean the level of details which we want to reach when constructing a
service model. A low granularity means that we do not go in deep details and that the CI
used in the model could potentially be decomposed further. A high granularity means
the opposite, i.e. CI can potentially represent very detailed objects.
The considerations of this section mostly apply to the technical layers of the model, but
can nevertheless be considered as generic.
Discovery tools are especially good at finding fine-grained information on the different
components making up, for example, a computer system. CMDB entries will be created
for the motherboard, the network interfaces, the hard drives and so on.
This information is useful in the context of asset, change and configuration
management, but is usually of little interest in the context of service modeling, so a
balance must be achieved to make sure that the right level of details is obtained.
Here are a few arguments in favor of a low granularity:
The purpose of the service modeling exercise is usually to model IT services and
business processes, not the detailed interactions of the underlying technical “wiring”.
The hierarchical paradigm described above is likely to show its limits when it comes
to representing low-level technical relationships.
When service models are finally instantiated using BMC SIM, other tools such as the
PATROL console will be in place to allow for a deep drill-down in the technical
layers. In many organizations, the majority of the SIM users will not need such a
level of details.
A lower granularity will mean a smaller number of CI and relationships to maintain.
The maintenance of the service models will therefore be easier.
On the other hand, a high granularity model has its advantages:
First and foremost, it is often not a choice but an obligation to use detailed CI to
address the complexity of the model and the fact that when it comes to instrument
the model (i.e., associating monitoring events to the instantiated service model), a
technical event can be attached to only one component of the model. 6
For example, imagine we need to model two databases DBOne and DBTwo.
These two databases are hosted on the same computer named system1. In a
first approach, we could imagine modeling these two databases without using a
specific CI for system1. However, if system1 is unavailable, the two hosted
databases are unavailable as well – so the CI must be created and be set as a
provider of the two databases, as in figure 13 below.
6
BMC SIM offers technical alternatives to this paradigm, but they are not recommended.
Page 35 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
Figure 13
Root-cause drill-down will offer more fine-grained results if the CI are detailed. A
“Computer System” CI identified as the root-cause of a given impact offers less
detail than if we can narrow down on the specific component (disk, memory, etc) that
is the originating root-cause.
Another benefit of a reasonably fine-grained model is that, when instantiated in BMC
SIM, it offers better ways to control how impacts propagate along the dependency
chain, hence allowing us to avoid the “red or green” syndrome, where service
impacts are of an “all-or-nothing” type.
Best practices on granularity
Adopt a low granularity whenever possible.
Increase the granularity of the model only when necessary
When modeling applications running on distributed systems, stop the decomposition
at “Computer System” level, and do not represent its different components
Leverage on the flexibility of event association to avoid the creation of multiple
components
11.6.4
Leveraging on modularity
One of the advantages of hierarchical service models is that parts thereof can be reused as needed, in a modular fashion.
Models should be built so that each of its parts (the “sub-models”) is self-contained and
can be re-used independently.
For example, consider the model of an application “Application 1”, complete with all
dependencies towards the ICT layers, as in the next figure.
Page 36 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
Figure 14
If Application1 is a provider for a first IT System (IT System 1 below), the model of
Application 1 will be directly integrated to the model of this service, as in the following
screenshot.
Figure 15
Finally, if Application 1 is also the provider for another IT System (IT System 2), the
same model can once again be re-used. The next figure illustrates this.
Figure 16
Page 37 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
Making sure models are self-contained
This however requires, even though we seem to be stating the obvious, that services 1
and 2 use the same application “Application 1”. But is it really the case in real life? In
fact, cases where services 1 and 2 actually use different parts of A1, rely on different
network elements and a slightly different infrastructure are the vast majority.
We must therefore be careful to make sure that the model of Application 1 is selfcontained and has only dependencies towards its own components, and not to
components whose usage vary according to the different services that depend on the
application.
The following example illustrates the importance of the modularity, but also of carefully
choosing the entry points to the model. The model below is the representation of a
service “IT Service”, with its dependencies towards database and application systems.
This service is accessed from two remote sites A and B, and the network connectivity to
these remote sites has been included in the service model of “IT Service”. If “IT Service”
is the top-most layer in the model, this could be acceptable
Figure 17
However if the decision is made to model the two remote sites A and B as well, the
model of the service 1 is not good enough : From the picture below, we can see that a
loss of the “Network to B” will yield an impact on both sites, which is incorrect.
Figure 18
Page 38 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
To make sure that Service 1 remains self-contained and can be re-used by a future site
C, all network dependencies are externalized from the model of the service, to give the
following model:
Figure 19
Once again, it is really important to question the model and check if the construction
makes sense from an impact propagation perspective : to come back to the above
example, if a problem in application A1 has an impact on S1 but not on S2, then the
model must be reviewed and the model of A1 be made more modular.
Solving the spaghetti syndrome
Another very useful application of service modularity will help us solve the “spaghetti
syndrome”. This frequently encountered problem occurs when a list of consumer
objects C1…Cn depends on a same list of provider objects P1…Pm.
Without simplification, the model looks as follows:
Figure 20
Page 39 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
It is therefore a good idea to create (within the limits of the model blueprint) a container
object which will be used to regroup all the different providers, hence simplifying the
maintenance and increasing the clarity of the service model.
Figure 21
Best practices on modularity
always try to separate the elements common to a given service in a separate subtree
use container objects to simplify the model and minimize the number of relationships
in the model.
question your model and verify if impact propagation makes sense
align your model with the model blueprint
design your model to the last level of detail to avoid unpleasant surprises during the
implementation
if there are more than valid alternative to build a given model, multiply the number of
objects by 10 to check which alternative offers the best maintainability.
Page 40 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
12 Use cases
The following section describes commonly encountered use cases. It is impossible to
cover all scenarios, but these simple examples may help to familiarize with the concepts
and way of thinking.
12.1 Modeling a stand-alone application server
Application servers (mail, web, etc.) are nearly always part of a service model. It is
always a good idea to separate the application layer from the system layer, as a same
system may host multiple applications and as the application and the system may be
monitored differently.
Therefore it is common to model as follows:
A first CI of type BMC_ApplicationServer describes the application itself. Events
related to that application will be attached there.
A second CI of type BMC_ComputerSystem describes the physical system on which
the server is running. This second CI is set as a direct provider of the
BMC_ApplicationServer CI.
Figure 22
12.2 Modeling a database-based application server
In the case an application requires an application server and a database to run, a
common way to build the service model for that application is as follows:
A CI of type BMC_ApplicationServer describes the application itself. Events related
to that application will be attached there.
A CI of type BMC_ComputerSystem describes the physical system on which the
application is running. This second CI is set as a direct provider of the
BMC_ApplicationServer CI.
A CI of type BMC_DataBase describes the database instance
A CI of type BMC_DataBaseServer describes the database server.
Page 41 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
A CI of type BMC_ComputerSystem describes the physical system hosting the
database. It may be same CI as the first BMC_ComputerSystem described above if
both application and database run on the same system.
(Optionally) a CI describing the Application to Database connectivity can be added,
usually of class BMC_ApplicationConnectivity
Finally, a CI of type BMC_Application has as direct providers the application server,
the database and the connectivity CI.
A sample model is illustrated below.
Figure 23
12.3 Modeling a central application used in different places
When a same application running in a data center needs to be accessed from different
sites and the availability of the application across different sites needs to be monitored,
an obvious way to proceed is to build a model as follows:
Create one CI for each “remote site”, e.g. of class BMC_PhysicalLocation. These CI
will have as direct providers the following :
one CI that represents the central application, using for example the ideas of the
previous use cases
One BMC_ApplicationConnectivity CI for each remote-site connection.
The model then looks as follows:
Page 42 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
Figure 24
12.4 Taking into account end-to-end monitoring and SLA/O’s
It is often the case that end-to-end monitoring tools (e.g. based on Patrol End-To-End
Response Timer) are used in conjunction with element monitoring to check the
availability of a given application or IT service.
Also, it is often required that SLA’s or SLO’s be represented within the service model.
End-to-end performance monitoring information can be added as a separate branch in
the service model, adding to the classical service model built out of the separate
elements.
SLA agreements are usually set as consumers of the service CI’s.
The following picture gives a simple illustration of the case. On the left side, the
traditional service model of a web-based service is created as the “infrastructure”
model. On the right side of the model, the different end-to-end monitoring probes are
the providers of the “end-to-end” monitoring branch.
Above the service CI, two SLO CI’s have been added to illustrate that an impact on the
service may directly translate as an impact on the SLO(s).
The correspondence with the example model blueprint of figure 4 has been added for
reference.
Page 43 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
Figure 25
Page 44 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
13 Annex A: sample interview form.
The question form below contains a short list of typical questions to ask when it comes
to gathering information on a given service or application.
1. What is your role in the organization?
2. What is your role regarding this business/IT service?
3. Describe the business/IT service architecture. What are the technical
components supporting the business/IT service.
Inventory of hardware and software (OS version, Application version).
Logical architecture of business/IT service.
Physical architecture of business/IT service.
4. Describe the business/IT service from a customer’s perspective.
Which are the different supported business processes?
What is the criticality of the different business processes?
How is a degradation or outage of a process quantified?
How is the customer informed in case of degradation/outage?
Describe the relation IT services – business processes.
5. Describe the IT organization in relation to business/IT service:
Which teams are involved
Describe the relations between the different teams
Roles & responsibilities of the different teams.
6. What group of people, functions, do you see as the recipients of information from
the business/IT service monitoring solution? (Roles & responsibilities) Also
describe what information the different groups should receive.
7. Do you know where a problem resides when a user failure has happened?
8. How is the perceived and actual availability from a customer perspective, taken
from the last month?
9. Which issues with the current monitoring solution do you want to overcome for
business/IT service?
10. Do you have Service Level Agreements (SLA) with your customers?
If not, do you have plans to close SLA with you customers in the near future?
What kind of SLA do you have with your customers? (some examples)
How are the SLA measured?
Page 45 of 46
7/13/2017
Service Modeling Best Practices
BMC Software7/13/2017
11. Do you have Service Level Objectives (SLO)?
If not, do you have plans to have SLO in the near future?
What kind of SLO do you have today? (some examples)
How are the SLO measured?
12. What is the goal of the business/IT service monitoring solution?
13. What are the success criteria of a good business/IT service monitoring solution?
14. How will you measure the success of the business/IT service-POC
15. What are your biggest concerns on the implementation of a new monitoring
solution?
16. What are the success criteria for this project?
Page 46 of 46
7/13/2017