GoldMine Datasheet Title

8dc[^\jgVi^dc
Subtitle: Reinvent your Sales, Marketing and Support Proceses

BVcV\ZbZci
9ViVWVhZ8B97
HjXXZhh@^i
Configuration Management Database (CMBD) 1

SUCCESS KIT

Table of Contents
Chapter I:
A Prescriptive Path for Implementing the Service Catalog and CMDB Together . . . . . . . . . . . . . . . . . . . . 2

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Roles and Interrelationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

The Service Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
The CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Service Level Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

A Prescriptive Path for Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Service Catalog: Begin with the Business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

CMDB: Federated Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Service Level Management: Business-centric Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Service Example: Tying it Together . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Chapter II:
Common CMDB Pitfalls and How to Avoid Them . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Emphasizing Physical Instead of Logical . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Focus on Relevant Logical Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Automate Logical Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Lack of Business Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Start with the Service Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Add Service Level Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Overly Complex Dependency Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Only Capture Critical Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Reactive Change Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Proactively Verify CI Baselines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Use Service Maps to Visualize Probable Business Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

About FrontRange Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2 Configuration Management Database (CMBD)

SUCCESS KIT

Chapter I: A Prescriptive Path for Implementing the Service Catalog and CMDB
Together
Introduction
The expectation of your CEO is clear: IT must align with the business and deliver strategic value to the company. But
what’s your best course of action? The release of IT Infrastructure Library version 3 (ITIL v3) promises to ease business and
technology integration with its increased focus on service strategy. Yet meeting business value expectations can be elusive
without a pragmatic, customer-focused approach to IT, using a best practices process framework such as ITIL.

Once an organization embraces an IT service improvement mentality, they can get lost in the misguided pursuit of the per-
fect ITIL implementation. Many ITIL-mature organizations have invested significant time and money chasing “ITIL-topia”
but have failed to implement a workable solution that delivers real-world business value.

Your quest for achieving integration and increasing value requires a steadfast focus on the needs of the business. When IT
aligns with the business during the service catalog strategy and design phases, they can reach consensus on the definition
of services and the associated level of service, quality, and cost. Consensus prior to implementation will ensure that your
project execution will deliver against business expectations.

Volume VI of this executive briefing series is dedicated to helping you understand the roles and interdepencies of the
service catalog, the configuration management database (CMDB), and service level management (SLM). Through the use
of real-world service examples you will learn how these IT process areas become the three-legged stool that establishes IT
as a successful strategic business partner.

Roles and Interrelationships

You may be asking yourself, what makes the most sense to tackle first: the service catalog and service level management
or the CMDB? A solid CMDB is the key to any successful ITIL initiative. However, the service catalog is the key to initiating
IT-business alignment. While both of these efforts are complex, they are tightly interrelated. Therefore, you will need to
approach the service catalog and CMDB in a building-block fashion to keep momentum going.

The Service Catalog

Service Catalog Management received an increased focus in the ITIL v3 family of processes and plays a critical role in de-
fining the business needs of IT–in business terms. The service catalog is a published repository of all core IT service offer-
ings, which can include the business, technical, and professional services offered to both internal and external customers.
Services in the catalog are grouped logically by business customer, resulting in a clearly defined set of services offered to
the business. Creating a service catalog can involve iterative negotiations to develop service names, define service level
agreements, and identify the organizations that subscribe to services. Because services are designed and packaged from a
business customer point of view, they are aligned with each business process to meet the specific needs of the business.

Service descriptions are comprised of four major parts–Offer, Request, Activities, and Resources–each with many sub parts
and attributes:

• Offer contains service levels, pricing, terms and conditions among other attributes.

• Request contains ordering, configuration, governance and agreement sub-components and attributes.

• Activities include all major IT processes such as request, change, problem, availability, financial and relationship man-
agement. Vendor management and provisioning might also be included.
Configuration Management Database (CMBD) 3

SUCCESS KIT

• Resources include elements such as vendors, skills and labor, and of course all major IT systems that pertain to the
business service.

The service catalog becomes the shared vision of business and IT, transforming business goals into IT goals.

The CMDB

The Configuration Management System and the CMDB are fundamental components of the ITIL framework. The role of
the CMDB is to provide a centralized information repository of core configurable IT components and relationships to the
associated business service hierarchy.

All information recorded in the CMDB exists to support the information technology service management (ITSM) processes
described by ITIL. Because its content is guided by ITIL, building a CMDB typically starts with mapping core IT manage-
ment processes to the configuration items (CIs), the CI attributes, and its relationships to other CIs. A CMDB will track a CI’s
configuration attributes (e.g. those parameters that help manage the CI within the IT service provider function). Attributes
could be characterized as physical, logical, organizational, or financial. Since the CMDB is primarily a support tool that
enables other ITIL processes, logical attributes that define the business purpose of the CI are required alongside the physi-
cal attributes to annotate the service. Because the CMDB is typically built to control and manage the CIs that are subject
to the IT change control process, the CMDB provides an accurate baseline for planning and compliance management.
This design approach will limit the type of CIs and attributes that are tracked to a manageable subset. Consequently, the
inventory data repository is very different than the CMDB. The inventory database tracks the current state of all discover-
able IT infrastructure items and configuration information, Alternatively, a well-designed CMDB represents the desired
state (or baseline) of the service map–the business-relevant representation of the IT infrastructure.

Therefore, the structure and relationships in your CMDB must make sense from the perspective of a service and should be
defined from the point of view of a business consumer. Establishing the service map using a bottom-up approach, starting
with individual configuration items, is typically an exercise in futility. A top-down approach in which you define services,
create your service catalog, then use the catalog to drive the structure of meaningful data and relationships in the service
map will result in a CMDB strategy that is manageable and achievable within a reasonable implementation timeframe.

Starting with the service catalog will narrow the scope of the CMDB driving your focus on high impact services that affect
your most important business consumers. Rather than trying to reconcile thousands of CIs and attributes, you can start
with the business service view and focus on just those aspects that are relevant.

Implementing a catalog first will also reduce your project risk. There are many examples of multi-year enterprise CMDB
projects that have evolved into an IT-centric technical project. By the time the CMDB project is completed, the CMDB does
not align to the services the business cares about. Furthermore, the personnel required to maintain the enormous quantity
of detailed data being tracked in the CMDB becomes an IT resource nightmare. Starting with the service catalog ensures
that the CMDB project remains aligned with the business and sets the project up for success.

Service Level Management

Service Level Management (SLM) ensures that ongoing requirements, communications, timeframes and expectations
between business and IT are established and proactively managed. SLM is also responsible for ensuring that internal IT
expectations are being met. While the service catalog defines the services, service level agreements (SLAs) and operating
level agreements (OLAs) establish the service delivery benchmarks. Proactive SLM manages and measures actual service
delivery quality against the established benchmarks. Therefore, SLM provides the standards against which expectations,
improvements, and performance metrics are measured. SLAs, OLAs and underpinning contracts (UCs) ensure that docu-
mented agreements are in place to support the offerings within the service catalog.
4 Configuration Management Database (CMBD)

SUCCESS KIT

• Service level agreements, and the processes associated with them, provide a methodology for introducing and imple-
menting reasonable expectations between IT and the business consumer. They establish a two-way accountability for
service, which is negotiated and mutually agreed upon. The service catalog provides context for conversations with
your customers regarding SLAs.

• Operational level agreements establish specific technical, informational, and timeframe requirements needed for each
IT group to provide the services that will be delivered to the customer. Logically, OLAs must be in place before negoti-
ating SLAs with the business consumer representative.

• Underpinning contracts include documented delivery requirements and expectations for any third party vendor that
is part of the extended IT service delivery team. UCs complete the chain of accountability and control for seamless
service delivery. IT’s ability to achieve established service levels will be only as good as the weakest link. IT must hold
both internal and external delivery partners accountable for their part of the delivery cycle.

In addition to the service catalog, SLM is tightly integrated with the CMDB. When you define service agreements, there are
two steps:

• Break the service into discrete components, and define acceptable performance levels for each component. The com-
ponent information in the CMDB becomes the integration point with SLM.

• Define the overall service level for the full service by adding up the sum of the parts. Each component’s established
performance becomes a contributing factor to the overall service SLA.

A Prescriptive Path for Implementation

Service Catalog: Begin with the Business

Nothing works better than collaborating with your business consumer representatives (“the customer”) to agree on the
initial core set of services that will be contained in the catalog. Quite often, the best approach is for IT to create the first
draft of the catalog by documenting the services they believe they provide. Once this step is complete, the catalog can
then be validated with the customers.

This approach gives you a springboard for discussion and an opportunity to obtain buy-in from your customer. Attempting
to start collaboratively from a blank slate tends to give the customer the (mistaken) impression that you do not know what
services you provide.

Consider creating an external catalog view for your customers and an internal catalog view for IT. The external catalog
is simply the “menu” that stipulates the services that are provided to the customers with an appropriate description. The
internal catalog contains all the necessary components and relationships that are needed to deliver that service to the
customer.

IT professionals need to know the components that make up the services but should not rely on the service catalog to
document every detail; instead it should be accompanied by a CMDB. There should be a record in the CMDB for each
service, and a relationship record that creates logical service groupings to represent the service hierarchy. Relationship
attributes are also created to represent the association of a business service with the set of technical and application com-
ponents that are required to keep the business service running. The CMDB is also a mechanism used to associate services to
the users of each service. The combined set of logical and physical CIs and relationship between business services, business
support systems, and business users is referred to as the service map.
Configuration Management Database (CMBD) 5

SUCCESS KIT

CMDB: Federated Approach

When the CMDB is designed as a logical representation of the service map, drill-through access to the detailed physical
configuration is a best practices design approach. The IT resources in the CMDB are the logical (business purpose) represen-
tation of the physical (discoverable) asset information (e.g. physical inventory, such as servers, routers, switches, or storage
devices) and of relationships between CIs. These logical elements can be automatically linked to the IT infrastructure items
(IIs), providing a business view of how IT infrastructure elements support higher-level business processes.

The best way to support drill-through data access in your CMDB architecture is with a federated approach. Construct dif-
ferent views of the data for different purposes, while at the same time storing and updating the data in local data stores.
A critical success factor for your project is to keep the CMDB data easily maintainable and manageable. Federation is the
enabler of this strategy.

Service Level Management: Business-centric Metrics

As the IT organization becomes more experienced in managing services, the perception of IT resources evolves from an
enabling infrastructure to a strategic service asset. Services and the resources for delivering them are optimized around
business objectives, and real-time economics drive decision making.

Customers care about the end result and not about the components required to deliver the service. For example, a cus-
tomer order entry system may be comprised of network access, Windows® systems, an Oracle® database and third-party
fulfillment services. A problem in any of those elements can affect the entire order entry system. The customer is not
concerned with which element impacted their order entry system, but only that the system–as advertised–is not working
according to expectations.

Therefore, truly useful SLM goes beyond component/network metrics and includes service and business metrics, such as
defining the time it takes to provision a new service (mean time to provision, or MTTP), repairing an existing one (mean
time to repair, or MTTR), or responding to a trouble-ticket call.

Service Example: Tying it Together

The IT department has a service offering of web hosting at three different levels: bronze, silver, and gold. The catalog
describes the service, what is included, the price, how the service is charged, and associated service level agreements. Also
documented are the component services including support, provisioning, maintenance, backup, and availability. Resources
“to-be provided” describes the hardware, software, and the configuration necessary to create the web hosting infrastruc-
ture based on the bronze, silver or gold service level. The associated configurations for each level will be quite different.
To provide a web hosting service designed to meet gold availability and performance requirements, IT will likely need a
hot standby environment, which will require a redundant set production servers.

Let’s see how the service catalog facilitates the service ordering process. The marketing department needs a new website
for an upcoming promotion. The marketing manager accesses the service catalog from the self service portal and views
the recommendation: Web hosting, silver level, includes Linux, one rack, 1 gigabyte per month, at $200.00 per month
plus $100.00 per gigabyte of storage. The marketing manager agrees with the recommendation and enters into a hosting
agreement with IT.

This agreement now allows requests for provisioning and configuration to be carried out such as ordering servers, de-
ploying licenses, and granting access to users, which are part of the bundled service offering “Web Hosting: Silver.”  The
ordering-specifying-provisioning process is also part of the service catalog system. The service catalog integrates with the
inventory management system to confirm that the required systems and settings defined by the CMDB service map are
6 Configuration Management Database (CMBD)

SUCCESS KIT

provisioned and discovered in the inventory management system. The catalog also integrates with an SLM system that
manages the vendors that provide underpinning services.

When the service fulfillment process is automated, the web hosting system provisioning steps are supported using a fulfill-
ment workflow system and a change management system, where appropriate. The associated infrastructure items are
being added, discovered, and reconciled to the CMDB service map. The CMDB now has a new IT system that it will track,
and will report the main elements back to the catalog system. With integrated asset management tools, IT can also track
the actual consumption of storage and report back as a subscription service being used by the specific business unit.

Once the web hosting service is operational, the service catalog plays a different role: managing against established service
levels. Initially the service catalog is linked to the CMDB to document “resources to be provided.” Now it links to the CMDB
to identify “resources impacting service.” Service impact may be indicated by an influx of user incidents associated to a
server that is down. Or, it might be indicated by an SLA alert, proactively notifying IT that a server is precariously close to
breaching a performance SLA.

Meanwhile, the marketing executive can access the service catalog portal, which provides complete transparency to the
various services acquired, the cost drivers, the service level agreements, the history of requests, and the consumption that
service has undergone. When service levels are impacted, proactive broadcast notifications can be sent to affected busi-
ness users. The CMDB integrated with the service catalog enables this type of proactive mass communication and service
transparency.

Conclusion
The service catalog, CMDB and service level management comprise the three-legged stool that establishes IT as a strategic
business partner. Yet a prescriptive path for implementation is vital to your success.  Begin by establishing a documented
service catalog, developed in coordination with the business. This serves as a catalyst for business-IT alignment and
empowers business and IT managers to make decisions on IT activities based on risk, priority, and value, rather than cost
alone.

Next, implement your CMDB, ensuring the structure and relationships make sense from the perspective of a service. Imple-
menting the service catalog as part of an IT self service portal, integrated with the CMDB establishes IT as a business service
provider. When service descriptions include CMDB content and context, the service catalog becomes the shared vision of
business and IT, transforming business goals into IT goals.

Finally, use service level management to ensure that ongoing requirements, communications, timeframes, and expecta-
tions between business and IT are established and proactively managed. While the service catalog defines the services, ser-
vice level agreements, operating level agreements, and under pinning contracts establish the service delivery benchmarks.
Remember, truly useful SLM goes beyond component/network metrics and includes service and business metrics that are
meaningful to the business.

With this pragmatic, customer-focused approach to implementing the service catalog, CMDB, and service level manage-
ment, IT is sure to meet the expectation of the CEO: delivering strategic value to the company.
Configuration Management Database (CMBD) 7

SUCCESS KIT

Chapter II: Common CMDB Pitfalls and How to Avoid Them

Introduction
The expectation of your CEO is clear: IT must align with the business and deliver strategic value to the company. This
requires proactively managing IT infrastructure as a business, thus embracing IT service management (ITSM). A crucial com-
ponent of your service management strategy is implementing a configuration management database (CMDB).

Although the implementation of a complete CMDB system can be a multi-year project, by focusing on the business re-
quirements that are most important, a pragmatic CMDB implementation should show results within 90 days. So why have
countless CMDB projects failed to deliver business value or a reasonable return on investment?

Volume VII of this executive briefing series answers this question by discussing the most common CMDB implementation
pitfalls and how to avoid them. Included is practical advice from industry experts regarding the amount and type of data
that should reside in your CMDB. You will also gain insights into the FrontRange CMDB and discover why it can deliver
rapid time to value.

Emphasizing Physical Instead of Logical

The misconception that the CMDB should represent as close to 100 percent of the actual physical IT infrastructure as pos-
sible was a common pitfall of many early projects. Years were invested in designing the superset data model that could
track every individual IT component on the network, every possible relationship between inventory items, every discover-
able attribute, and every status change.

This approach typically results in a multi-year CMDB endeavor, reminiscent of enterprise data warehousing projects of the
1990’s. Multiple auto discovery tools are required to discover the complete IT infrastructure and application topology.
Complicated reconciliation rules must be coded to resolve duplicate data collected by multiple discovery tools. Manual
reconciliation processes must be established for records that fall through the cracks from nightly reconciliation processing.
Manual entry has to be performed to set up the complete logical configuration hierarchy. Many CMDB projects attempting
this level of completeness and accuracy can require two or more full-time IT personnel to establish and manage ongoing
data maintenance tasks. In addition, without strong IT change control processes, it is only a matter of time before un-
planned changes result in a baseline CMDB that is out of synch with the current state IT infrastructure. Many CMDBs that
were designed around strong ITIL principles and initially populated using robust discovery tools failed because IT could not
justify the resources required to keep up with ongoing data management.

Focus on Relevant Logical Data

These early CMDB projects could have delivered comparable business value–but at a dramatically lower total cost of
ownership–if IT had conducted more up front planning with their business constituents. Instead of an “all-or-nothing”
strategy, orienting the CMDB around business services allows IT to design an infrastructure model scaled to support only
the infrastructure information needed to maintain control and stabilize critical business services–the true benefit of a
CMDB. This logical infrastructure, with physical relationships where appropriate, results in a much more manageable set
of data than the full physical view of every aspect of the hardware, software, and network topology. This discussion of
logical versus physical views highlights the difference between inventory management and configuration management.

Don’t confuse inventory management with configuration management

Simply stated, the goal of the CMDB is to provide an accurate, up-to-date representation of the business support systems
that keep your business running and employees working, and is easily accessible from the service desk.
8 Configuration Management Database (CMBD)

SUCCESS KIT

Inventory management is concerned with having the most comprehensive and up-to-date view of the entire IT infrastruc-
ture. Configuration management is focused on creating a specific filtered view of service assets, representing only those
assets that are critical to delivering IT services that ultimately support the company’s core business services. Configuration
management assists us in understanding the business function of the asset rather than what the asset is.

For example, a configuration manager needs to know that a computer server is used as a database for a set of critical busi-
ness functions. Yet many of the data elements related to the computer server that are identified by a discovery tool are
not relevant to the configuration management function. Scaling back the CMDB to track only relevant data about critical
business service resources is a critical success factor for your CMDB project.

With this in mind, determining the granularity of your physical CI hierarchy is dependent on the level of detail that can be
tracked from your Service Management records (e.g. incidents, problems, changes, releases, etc.). To illustrate, consider this
sample business service. In this example, you support the finance department, which delivers the Financial Management
Service. Financial Management is provided by the SAP System. The SAP System includes the SAP Accounts Receivable,
Accounts Payable, Business Intelligence, and Project Management sub systems. The SAP Accounts Receivable sub system is
supported by the following physical IT systems:

• SAP web server

• SAP application server

• SAP database server

• SAP backup database server

• Knowledgebase sub system

• SAP application software

• Oracle 11i database software

• Network device-LAN

The SAP Accounts Receivable sub system is supported by the following logical IT systems:

• SAP Support Agreement

• Sun Server Hardware Lease Agreement

This business service, related sub systems, associated physical IT systems, logical CIs, and relationships between each node
in the hierarchy can be modeled in the CMDB to create a service map.

If you are only able to associate an incident to the SAP sub system, and track Requests for Change to the SAP network
device, it doesn’t make sense to maintain CI records for each network circuit, router, and switch that are “lower” in the
service hierarchy.

When you deploy integrated FrontRange discovery tools in conjunction with ITSM Inventory Management and Configura-
tion Management modules, you can maintain both physical and logical views. Each view becomes a separate and distinct
tool to support different ITSM processes. Identifying the physical configuration information of a server with performance
issues is important when conducting root cause analysis. On the other hand, logical business service impact information is
vital when prioritizing break/fix incident resolution.
Configuration Management Database (CMBD) 9

SUCCESS KIT

Automate Logical Definitions

With the FrontRange Foundation database extensibility features, you can choose between creating a CMDB that models a
detailed physical representation of the network and its connections or a logical application-dependent view. Based upon
set criteria you define, FrontRange business rules and workflow automate the process of identifying which assets are criti-
cal, and which are not, to create a logical view of the asset, highlighting the applications that define the role of the asset.

IT will make better business decisions when it is easy to identify the purpose of core business system assets. Based on IT
best practices, the CMDB becomes the IT reference tool to quickly research and pinpoint business services and business
users that are impacted by an unplanned system failure or a planned system outage. With FrontRange Configuration
Management, each core business and IT service can be defined as a logical CI. Relationships can be created from the logi-
cal service to the set of IT services. If you plan to manage your IT prioritization by business service impact, you may want
to put the extra effort into modeling the full logical hierarchy of the business service. With FrontRange Visualization, you
can use the visual map to view the logical business service hierarchy and perform business impact analysis.

Lack of Business Focus

The most common pitfall of current CMDB projects is the lack of business focus. Your project will become overly complex
and unnecessarily complicated unless you focus on the business processes that are most important to your customers.

An enterprise CMDB project can easily devolve into a very IT-centric technical project. By the time it’s complete, the CMDB
may not align to the services your customers care about. That’s why we recommend defining a baseline service catalog
before implementing your CMDB to ensure the project remains aligned with the business.

Start with the Service Catalog

Creating a service catalog involves defining the set of primary services IT offers and supports, developing agreed upon and
common names, defining service level agreements, and then connecting them to the infrastructure and organization.

First, identify your key business stakeholders by department, business function, or business service and rank their relative
importance, often driven by their financial value/impact to the business. You may support departments such as sales, mar-
keting, human resources, finance, procurement, and customer support. Or you may model your support around business
services like online banking, loan funding, and insurance claims.

Next, identify the core business processes by stakeholder and create a service definition based on the enabling set of tech-
nical or professional IT capabilities. For example, if human resources is one of your key business stakeholders, corporate
communication may be one of its core business processes. Clearly, an IT service required to support corporate communica-
tion is email. The IT systems that map to the Email IT Service include Microsoft Exchange, IBM Lotus Notes, and Blackberry.

Be pragmatic when modeling services and systems in the CMDB. Keep your CMDB to a manageable size by limiting the
CIs and CI attributes to just those aspects that are relevant to your business processes. Additionally, it is not necessary to
include the entire set of business services, IT support services, and IT systems in the CMDB. Leave IT systems to the CMDB
and business and IT support services to the service catalog and service level management.

Add Service Level Management

Service Level Management (SLM) ensures that ongoing requirements, communications, and expectations between business
and IT are proactively managed. The service catalog sets the standards against which expectations, improvements, and
performance metrics are measured. Service level agreements (SLAs), operating level agreements (OLAs) and underpinning
10 Configuration Management Database (CMBD)

SUCCESS KIT

contracts (UCs) ensure that agreements are in place to support the offerings within the service catalog.

Ideally, SLAs can be created in two steps: first, breaking the business service into discrete sub services and supporting
components, and second, defining acceptable performance levels for each component. The component information in the
CMDB becomes the linkage point with the SLA. Separate SLAs can be defined for each aspect of the overall service. For
example, a service request in the service catalog will have an acceptable resolution threshold. The related CI components
may also have their own system availability and response thresholds. Incidents associated with a problematic system will
have an incident response time and resolution time SLA.

FrontRange Service Level Management allows easy association between each SLA and its corresponding IT support system
CI in the CMDB. The FrontRange management dashboard provides a valuable tool for managing each aspect of the overall
business service SLA based on individual component SLAs.

Overly Complex Dependency Mapping

Many CMDB projects fail because the many-to-many relationships between CIs result in a service model that is extremely
complex, impossible to view, and impractical to use for managing the business.

One of the most difficult things to model in the CMDB is the relationship between two CIs, which is called dependency
mapping. For example, an end-to-end supply chain process is comprised of manufacturing control system A, warehousing
system B, order fulfillment system C, and general ledger system D tied together through file transfers, bulk database loads,
distributed object calls, and message-oriented middleware. Because discovery tools cannot comprehensively analyze the
different dependency types, manual intervention is required to generate a map depicting the flow dependencies from A
to B to C to D.

Only Capture Critical Dependencies

To avoid complexity and achieve usability, we recommend that during the first phase of the CMDB project you only cap-
ture the most critical dependency between two IT assets such as:

• Comprised of

• Depends on

• Runs on

• Supports

By modeling a single, critical relationship between CIs, your service model becomes much easier to view and can be effec-
tively used to make important business decisions. Multiple relationships between two CIs are common in the real world.
However, modeling each relationship in the CMDB will likely compromise the business value of the visual service map. Ad-
ditionally, unless your IT infrastructure is relatively static, maintaining an accurate view of the ever-changing relationships
between CIs will quickly become an overwhelming task. Even with sophisticated automated dependency mapping tools,
most organizations are challenged to maintain true, accurate relationships in the CMDB. There is simply too much logic
that must be defined and maintained to keep the dependency-mapping tool in synch with the evolving purpose of today’s
business systems, especially with the advent of virtual data centers.
Configuration Management Database (CMBD) 11

SUCCESS KIT

Reactive Change Management

The inability to quickly identify changes to an individual CI or a group of CIs that comprise a service has been the down-
fall of numerous CMDB implementations. Change management should not be an afterthought, and must be managed
proactively. The design of the Change and Configuration Management processes should be considered in concert with the
planned use of the ITSM toolset.

Proactively Verify CI Baselines

FrontRange Foundation enables you to set a baseline for CIs so you can instantly verify the consistency of all CIs in a ser-
vice. If a change occurs, a flag is raised and a more detailed investigation automatically determines which components are
out of compliance with the baseline.

Two actions can be taken. If the change is in response to an approved Request for Change, then the change can be ac-
cepted, which creates a new baseline. However, if the change is unauthorized, a new incident can immediately be created,
ensuring IT can get the underlying asset back into compliance. Without integrated change management, the CMDB will
quickly become an outdated representation of the infrastructure baseline.

Use Service Maps to Visualize Probable Business Impact

Service maps can be used to improve service availability through proactive analysis of change and more rapid response to
service interruption.

A service map, at its most elementary level, is a visual model of a set of interrelated CIs in the CMDB, for example, a com-
puter network. A more robust service model will include the business services supported by that network. The service
model allows you to visualize the impact of change to components of a service. With a service map you can proactively:

• Apply a “what-if scenario” to understand the impact of an outage to services, users, and other CIs

• Automatically detect CI changes and updates including expected vs. actual and versioning

• View and identify unauthorized changes to critical CI components of services

When an interruption to a critical business service occurs, IT must quickly identify the priority of an incident to ensure
resources are efficiently mobilized to address the highest impact issues first. By viewing a map of the service, IT can more
easily identify the root cause, analyze the relationship between CIs and business service, and rapidly assess the impact and
the urgency of the outage and the potential change that may have caused it to occur.

Conclusion
Implementing a CMDB doesn’t need to be a death march nor a science project with limited business benefit. With the right
tools, and a pragmatic, customer-focused approach you can accelerate the project and avoid common pitfalls to ensure
your CMDB is actionable and delivers business value. When you scale down your CMDB project to focus on core business
services and primary support systems, you will deliver a more immediate return on investment at a lower total cost of
ownership.
12 Configuration Management Database (CMBD)

SUCCESS KIT

About FrontRange Solutions

FrontRange Solutions develops software and services that growing mid-size firms and distributed enterprises rely on
every day to build great customer relationships and deliver high-quality customer service. The company applies a unique
combination of innovation and automation with a standards-based approach to simplify core business processes, includ-
ing: IT service management; customer relationship and sales force management; and PC lifecycle management. More than
150,000 of the world’s best-known brands use FrontRange offerings to quickly improve their interactions with external and
internal clients and achieve better business results. For more information, call 800.776.7889 or visit www.frontrange.com.

All Rights Reserved.

GoldMine, HEAT, Enteo, Centennial Discovery, DeviceWall and other FrontRange Solutions products, brands and trademarks are
property of FrontRange Solutions USA Inc. and/or its affiliates in the United States and/or other countries. Other products, brands
and trademarks are property of their respective owners/companies.

USE OF THE SOFTWARE DESCRIBED IN THIS PAPER AND ITS RELATED USER DOCUMENTATION IS SUBJECT TO THE TERMS AND CON-
DITIONS OF THE APPLICABLE END-USER LICENSE AGREEMENT (EULA).

The information contained in this document is provided “as is” without warranty of any kind. To the maximum extent permitted by
applicable law, FrontRange disclaims all warranties, either express or implied, including warranties for quality, accuracy, merchant
ability, fitness for a particular purpose, title and non-infringement; and in no event shall FrontRange or its suppliers be liable for any
damages whatsoever including direct, indirect, incidental, consequential, loss of profits or data or special damages, even if advised
of the possibility of such damages.