HGC Servicenow Cmdb101

HICHEM GUEMIRI NOEL NATHAN MAXIME CARRIER
PATRICK LAROCHE ALAIN LAPOINTE XOLANI NGWENYA
SER VICENOW
CMDB 101
AWAKEN YOUR SERVICE
MANAGEMENT FROM WITHIN
HGC TECHNOLOGIES INC.
All rights reserved @HGCNOW
info@hgcnow.com
WWW.HGCNOW.COM
C ONTENT S
WHO WE ARE? ............................................................................................... 5
WHY WE WROTE THIS BOOK? ..................................................................... 6
1. HOW TO PLAN YOUR CMDB ............................................................................ 7

1.1 Set your CMDB now! ................................................................................ 8
1.2 How to get you started? ...................................................................... 9
1.3 How to get there? ........................................................................................ 11
1.4 How to prepare?.......................................................................................... 18
2. DESIGN YOUR CMDB ..................................................................................... 29

2.1 CMDB design policies ............................................................................ 30
2.2 CMDB design workshops ..................................................................... 30
2.3 CMDB design delivrables ........................................................................... 31
2.4 CMDB design approach ....................................................................... 33
2.5 CMDB design automation ..................................................................... 55
3. CONFIGURE YOUR CMDB ............................................................................. 57

3.1 CMDB table classifications .................................................................... 57
3.2 CI ownership ......................................................................................... 60
3.3 CI status ............................................................................................... 60
3.4 CI service mapping ............................................................................... 63
3.5 CI relationships ..................................................................................... 65
4. CONSTRUCT YOUR CMDB ............................................................................ 72

4.1 CMDB implementation best-practices ................................................... 73
4.2 CMDB data loading .............................................................................. 76
4.3 Implementation tips .......................................................................... 77
4.4 CMDB ServiceNow adaptation ............................................................ 78
4.5 CMDB ServiceNow plugins ................................................................. 78
4.6 CMDB implementation plan .................................................................. 79
4.7 Data loading activities ................................................................................. 81
CMDB DEFINITIONS ..................................................................................... 84
THE AUTHOR ...................................................................................................... 86
THE COLLABORATORS .......................................................................................... 87
TABLE OF DIAGRAMS ................................................................................. 90

Youve been asked to implement a CMDB in ServiceNow . Or, you will soon have to
improve the information that is found in your current CMDB.
Theres no surprise there! Statistically, most CMDB projects fail for many reasons, but
the main reason being, lacking a practical approach to implementing a sustainable
CMDB. With this book, you will start with the right approach one that is logical and
practical. So, stop chasing the unicorn and finally get on the right track to awaken
your operational service management from within, by implementing your trusted
CMDB in ServiceNow !
To help you succeed where others have failed, we have put together this book based
on vast experiences in helping many customers achieve their objectives and goals
in implementing a sound CMDB.
In addition to this book, we have consolidated and made available, all the original
diagrams found in this book. All documents are available on our website as a com-
plementary download. Go to our website WWW.HGCNOW.COM or send us an email
at CMDB@HGCNOW.COM to get the link to download the diagrams.
Regards,
HICHEM GUEMIRI
HICHEM @HGCNOW.COM
SER VICENO W CMDB 10 1
WHO WE ARE?
We are a modern-day consulting firm focused entirely on providing advisory, admin-
istration, and development services exclusive ly on the ServiceNow SaaS platform.
Allowing clients to augment, improve, and evolve their IT and Business Service
Management.
As a reputable ServiceNow Partner based in Montreal, Quebec, we have over 15 years

of experience in designing and building innovative solutions to ensure clients obtain
the value they seek. Our services are tailored to each clients unique requirements.
We can do so through lessons learned, keeping abreast at industry best practices
and by being extremely active in the ITSM, ITOM, and ITBM community.
Our technical expertise and capabilities cover the following aspects of all services
delivered: project lifecycle, strategic planning, enterprise architecture, process inte-
grations, application development, program governance and ServiceNow mainte-
nance and support all supported by our recognized IT management and governance
practices.
Our service offerings provide the following benefits to our clients:
PROVEN: experienced and highly trained team.
AGILE: adapt the solution and services offered to suit any organizations unique
business needs and outcomes desired. This may include a full turn-key support
solution, or integrating with existing IT service providers, or specialist applica-
tions support teams.
INNOVATIVE: committed to continually develop and improve the services offered

to ensure clients are kept in step with the latest developments in ServiceNow .
Leveraging our unique implementation approach, clients can have a clear under-
standing of all the essentials for a successful project delivery. Our mantra and meth-
odology helps lower organizations implementation and maintenance costs as well
as associated risks.
Our CMDB implementation approach, which can be adapted as your own CMDB
Mantra, was developed using the following principles and guidelines:
MINIMIZE manual data entries and maintenance -- promote automation when-

ever and wherever possible.
ACCOMODATE the right adaptations and customizations based on lessons

learned as well as industry best practices.
MAXIMIZE design simplicity in ServiceNow , establish data ownerships, and

responsibilities in ServiceNow
ALLOW for an easy path to upgrades by documenting all configuration, devel-

opment work, incidents, and enhancement requests, all within the same space
in ServiceNow - the single source of record.
HGCNOW.COM 5
WHY WE WRO TE THIS BOOK?
The purpose of this practical CMDB design book is to provide you with a consistent
approach to develop and design a CMDB in ServiceNow . This book will provide
step-by-step instructions for creating an effective CMDB blueprint model to be
used and awaken your service management from within by empowering you to
make better decisions.
Service Asset Management and Configuration Management, collectively referred

to as SACM, are the foundational processes that seek to provide an accurate and
logical model of the IT infrastructure and the relationships that exist between com-
ponents, systems, and provided services. They are one of the components of a larger
IT Service Management vision that seeks to ensure Business Services are aligned
with business needs. It also provides the core data used in other related processes
such as Incident resolution, Problem analysis, Change Management risk analysis,
Release Management development and design, to mention a few.
We have worked on this practical CMDB book with a single mindset! Keep it sim-
ple. Each chapter is divided into simplified practical steps that we use with many
customers. Our approach has improved and amplified in our breadth of knowledge
with each engagement.
The simple key to a successful CMDB implementation is to bring together people,

process, and product. We hope this methodology will help you write you own CMDB
mantra, re-imagine your current CMDB and help you implement ServiceNow on
the right foot.
In this book, you will learn how to build and group Configuration Items (CIs) into a
collection of CI Families and define CI Types - which can be used to further classify
your CIs into sets of standards, common, and mandatory attributes based on the
types of CIs involved.
This book was designed for anyone interested in implementing a sound CMDB but
primarily for those with the following roles inside your organization:
IT Executives
Enterprise Architects
ServiceNow System Administrators
ServiceNow Implementation specialists
Process Managers
CMDB Process Owners
CMDB Librarians
CMDB CI Managers
CMDB CI Analysts
6 HGCNOW.COM
HO W T O PLAN Y OUR CMDB

Your ServiceNow CMDB must allow you to identify, control, record, track, report,
audit, and verify the value and ownership of all service assets throughout their
lifecycle, including Business Services and all supporting services of your business.
There are so many guides and information available about the steps needed to take
for effectively building a CMDB, but none that spell out (step-by-step) an exact
practical methodology to design and implement a CMDB in ServiceNow .
FIGURE 1 SERVICENOW SHARED CMDB ARCHITECTURE
Your CMDB must also provide a single logical view of all Asset Service CI compo-
nents and relationships needed to effectively deliver Your Business Services to your
customers via a single Portal. It also controls the revisions to all components of the
infrastructure.
To make your IT service delivery effective and bring value to your users and customers
you must bring together the following three elements: people, process and products.
HGCNOW.COM 7
S E R V I C E N O W CM D B 10 1
1. 1 SET YO U R CMD B NO W !
Configuration Management Database (CMDB) is a system, a database schema that

holds all the information, inventories and documentation of both logical and physical
components glued together allowing you to represent and manage your business
services and service offerings.
The primary use of a CMDB is to help all the other processes become more effective
and efficient by providing a consistent set of managed information regarding all
service delivery components within your organization, including both your internal
and external environments including cloud services.
When information regarding the elements is provided by multiple sources, a feder-

ated CMDB provides a clear context on all and any services offered which enables
greater coordination across your organization.
It is important to note that this book is not intended as a replacement to any existing
ServiceNow documentation and official ServiceNow Wiki pages. It is intended
to be a supplemental source of information provided by our experienced crew
gathered over the last decade.
FIGURE 2 SERVICENOW APPLICATION CAPABILITIES
The reasons for implementing a CMDB are far greater than just aiding the Change
Advisory Board (CAB) in understanding the impact of a pending change. It is
intended to provide a comprehensive view on which Configuration Items (CI) are
linked to a Business Service, allowing you to understand the true impact of an out-
age, an event or any organizational changes at large. Therefore, a truly federated
CMDB should and must provide a solid foundation for enabling your organization
to improve your day to day operations and the delivery of IT business services by
understanding all the layers involved in the delivery of your IT services.
8 HGCNOW.COM
1.2 HO W T O GET Y OU S T A R T E D ?
A well thought out plan is the key to achieving any objective in life. This also holds
true for deploying a federated CMDB in ServiceNow . This means that, prior to
deploying Service Asset & Configuration Management process or any other process,
you need to identify what business services you must support, which CIs are needed
to provide those business services and where/how are they to be implemented and
maintained in a federated, single source of truth, CMDB.
You will also need to identify and implement the appropriate go ernance regarding how
each CI type and attribute is added, kept current, controlled, and used by each pro-
cess that has been implemented. The Service Asset and Configuration Management
(SACM) processes enhance the links between the Service Management processes
by providing standard data and historical information for all configuration items.
FIGURE 3 SERVICENOW CMDB ARCHITECTURE MODEL
The ServiceNow platform features a powerful single source of truth, a CMDB sys-
tem and foundation to accelerate incident resolution, problem analysis and impact
of changes. Your first and foremost goal of implementing a CMDB is to automate to
the maximum all IT processes and leverage that information to assess and prevent
impact to the critical business services; truly enabling the phrase a happy customer,
is a returning customer.
Establishing and agreeing on mission statement for your CMDB is by far one of
the most important steps. Going through this process will ensure all contributors
HGCNOW.COM 9
and stakeholders are on the same page as to what you plan on achieving, why, and
how you plan on getting there. Once you implement your CMDB, you will be able
to achieve the following:
Reduce risks, contribute to contingency planning and improve the ability of

your organization to perform impact and risk analysis for Changes.
Enable effective scheduling of changes through improved awareness of service

windows and improved security through control of CI versions.
Provide problem management with data on problem trends and increase the
ability to deliver on SLAs.
Improve the effectiveness of all Service Management processes.
Support and improve release management, help with financial and expenditure
planning.
Track, manage and control valuable CI information.
Facilitate adherence to legal obligations.
Facilitate Demand and Capacity management.
Your future ServiceNow CMDB provides the mechanism for controlling the IT infra-
structure and services, which provides the basis for satisfying the following business
needs and drivers:
FIGURE 4 CMDB BUSINESS DRIVERS
10 HGCNOW.COM
1.3 HO W T O GET T H E R E ?
As we mentioned previously, you should not jump into implementing a CMDB without
a clear vision supported by a strong mission statement. Controlling the IT infrastruc-
ture and business services across distributed systems and support groups requires
careful planning. You should aim to have your CMDB include Inventory management
and IT Asset Management. The Change & Release Management processes should
work together and share the many interdependencies on a single CMDB.
FIGURE 5 CMDB BUSINESS DRIVERS
To move forward with implementing a CMDB you will need to obtain the stakehold-
ers requirements and combine those with business drivers, which you can then
develop into a plan.
Our recommended approach involves practical steps and a phased implementation

approach. We will discuss in more details the various implementation possibilities.
This phased approach will ensure the resulting design and plans are aligned with
your vision, mission statement, and goals. It will also help deliver early benefits
required to establish the need to provide funding and resources for expanding the
role and scope of your CMDB.
The four essential steps, will be addressed as part of our methodology in more detail
as you move in adapting our mantra. With this book in hand you will be able to
reduce many of the frustrations experienced by other organization that have failed
in their attempt to implement a federated CMDB on the ServiceNow platform.
1.3. 1 ES T A B L I S H Y O U R V I S I O N & GO A L S
Most often the primary use of a CMDB is to facilitate incident management by

linking the incident record against the faulty CI. The use also extends into Change
Management by making it easier to assess impact and risk. Other usages can include
visualizing and displaying business service representations, and identifying applica-
tions infrastructure component dependencies.
HGCNOW.COM 11
As stated earlier, reviewing and agreeing on the vision, mission statement, and goals
for your CMDB implementation is the most important step. Executing and going
through this initial step will ensure all contributors and stakeholders expectations
are aligned in so far as the road to take to achieve your federated CMDB.
To create a federated CMDB that effectively aids the goals of all other ITSM and
ITOM processes:
Incident Management enable quick Incident resolution by providing information

on on-going incidents related to a Business Services CI.
Change Management assist in risk management by displaying the connected

components of a Business Service.
Based on your mission statement, an implementation roadmap should be devel-

oped that spells out how these capabilities will be obtained in an orderly, phased
fashion. Be sure to recognize the key benefits and value propositions for each usage
identified. The implementation of the CMDB enhances the links between the service
management processes by providing standard data and historical information for
all CIs. And in defining a vision for managing your IT department, you will be able
to reduce the cost of managing your IT.
Your project goals and desired capabilities might include, but are not limited to,
the following:
Develop and populate a CMDB to support the implementation of a future ITSM

tool set.
Provide a complete list of infrastructure CIs that support a business service,

aiding in understanding the true cost of delivering said service.
Provide a sound basis for incident management to improve the first-call resolution
rate on the help desk.
Improve the rate of successful changes by offering necessary information to

support the change management process.
Discover all infrastructure CIs and their relationships, verify the configuration
records against the infrastructure and correct any exceptions.
Provide data that enables IT organizations to write and meet comprehensive

SLAs in the future.
Provide a central repository for asset data to optimize controls for software licenses,
leases, warranties, retirement, depreciation and total cost of ownership (TCO).
Enable low-risk infrastructure upgrades and changes, increase security and

reduce service outages.
For your organization to fulfill its common mission and communicated goals during
the initial phase of implementing the SACM process, there are several activities and
control mechanisms that must work effectively and in unison.
12 HGCNOW.COM
1.3.2 SET Y OUR P R O C E S S GO V E R N A N C E
In most cases, it is common for organizations to begin with Inventory Management

process, develop the Asset Management process, and finally the SACM process.
Each process builds on the core data provided and managed by the previous, but
it is important to note that these processes are not synonymous. Inventory Man-
agement, Asset Management, and SACM do share some of the same activities and
core data elements, but these three processes have different goals and objectives.
INVENTORY MANAGEMENT - deals with the physical inventory.
ASSET MANGEMENT - extends inventory management to include financial

management of the physical assets.
CONFIGURATION MANAGEMENT - further extends the two above to include

the relational management of components, physical and non-physical, to provide
a logical model and control over systems, business services, and supporting
infrastructure.
Start by assigning a SACM process owner who will be responsible for owning the
CMDB strategy, structure, and process. Working with your organizations stake-
holders, one of the first tasks that the process owner should undertake is creating
and ratifying a common mission. In general, The SACM vision should define scope,
span, roles and responsibilities, naming conventions, guiding principles, references
to other related processes and standard operating procedures.
Its crucial that your stakeholders and all participants in the SACM process must
understand their roles and responsibilities, as well as the common roles and related
responsibilities.
As presented previously, for a SACM process to fulfill its mission and goals, there are
several activities and control mechanisms that must work effectively and in unison:
PLAN and define your purpose, scope, objectives, policies and procedures, and
technical context for implementing SACM process in your organization.
IDENTIFY the configuration structures for all the infrastructure configuration

items (CIs), including their owner, their interrelationships and configuration
documentation. This includes allocating identifiers and version numbers for
CIs, labeling each item, and entering it into the Configuration Management
database (CMDB).
CONTROL that only authorized and identifiable CIs are accepted and recorded,
from receipt to disposal. It ensures that no CI is added, modified, replaced or
removed without appropriate controlling documentation (approved change
requests, and updated specifications).
VALIDATE the reporting of all current and historical data concerned with each
CI throughout its lifecycle.
HGCNOW.COM 13
1.3.3 DESIGN Y OUR CMDB MODEL
The CMDB blueprint model provides a representation of all the CI information within
the scope and span of your configuration process effort. Based upon the outcomes
of the previous step, determine what types of records and data can enable you to
achieve your vision and goals. The diagram below depicts a practical approach to
document your CMDB blueprint. We will address in detail; the steps required to
reach and deliver the model below.
A CMDB integrates information from many sources including:
Incident, problem, change and release records
Known error and knowledge management records
Application and infrastructure records
Assignment groups, service level agreements (SLAs), operating level agreements

(OLAs) and underpinning contracts (UCs)
Corporate data about employees, suppliers, business units, and customers
Measurement and reporting metrics
We recommend you design a blueprint structure in a manner where its a balance

between the following elements:
FIGURE 6 CMDB DESIGN BLUEPRINT STRUCTURE
To build a CMDB, first design it by starting to determine how CIs will be categorized.
Many organizations find groupings, types, CI family and classes to be an acceptable
starting point. Then, decide on a naming convention and document where and how
the data should be integrated into your CMDB.
14 HGCNOW.COM
A naming convention is essential for your organization, utilizing a standard naming

convention helps to ensure the integrity of other IT service management processes.
After categorization and naming conventions are in place, design your structure and
align it with your mission and goals, considering your business priorities.
A good rule of thumb when designing your CMDB is to lean on the side of collecting
less. Not all available data provides value and collecting excessive data can lead to
an expensive system that is difficult to build and challenging to maintain. We will
address this in more detail below.
You CMDB design is mainly based on inputs gathered from each design workshops
participants and might include the following questions:
Which raw data is currently managed and tracked by each team?
How are services being delivered to customers?
How do clients view your IT department?
Identify what can be discovered, manually entered, controlled and maintained.
What information and data to consider, present, link, maintain, and control for
managing your business services?
Construct the CMDB service model blueprint using the requirements identified for
the Service catalog, the IT business processes, and the IT service model design, by
assessing the data required. Then, present your model for approval by the stake-
holders before proceeding with the CMDB implementation in ServiceNow .
FIGURE 7 CMDB DESIGN STEPS
1.3.4 C ONS TRUCT Y OUR CMDB
Once your CMDB structure is defined, you should determine how your organization
populates CI information (this can include using a phased and/or waved approach).
Additionally, the order of execution is important to identify as well are ownerships
and support groups for all CIs.
Investigate what current tools are available for collecting, storing, managing and
updating the data. Identify which tools meet the defined requirements and which
requirements have yet to be met by existing tools. Knowing your solution inventory
by product area will have a huge effect on the creation of your CMDB data model in
ServiceNow . Also, deciding to use ServiceNow Discovery and/or Service Mapping
capabilities might impact your scope and planning.
HGCNOW.COM 15
Use tools to automate data collection and help mitigate the risk of errors that can
be introduced by manual data entry. An effort should be made to identify any addi-
tional tools that could help in the automation process and determine if a business
case can be made to support their purchase.
The most important decision in adapting the CMDB in ServiceNow is to understand

the ServiceNow data model, which tables to use and when to extend a table or a
field. The model will cover the METHODS and PRODUCT definitions, as well as the
data population strategy. Begin by taking an inventory of your organizations existing
data repositories that are internal and external to IT, this will facilitate in establishing
priorities for each usage.
FIGURE 8 CMDB DESIGN SCOPE + SPAN = ROADMAP
Once these repositories are identified, it is equally important to discover the following
information for each:
Primary purpose of the data

Location
Owner
Users of the data
Accuracy of the data
Completeness of the data
Level of detail
How is the data supported and maintained?
Is the data integrated with change management?
What is the single trusted source for the data?
Is the data federated or is it replicated?
Next, assess and plan the level of work associated with scrubbing the data and
gathering new data in support of the requirements. In some instances, you may even
find it more effective and efficient to discard existing data and start from scratch.
16 HGCNOW.COM
FIGURE 9 CMDB DESIGN FEDERATION
It is extremely important to plan for improvements and automation where oppor-

tunities exist. One of the most widely used improvement process is the infamous
Deming Cycle (plan, do, check and act). To ensure your CMDB is providing the
expected value, this requires a measurement and reporting strategy combined with
a continual improvement process.
Before populating the CMDB manually, you must identify what can be discovered
and what must be manually entered as well as maintained. Ideally, you are better
off investing in automation by federating the information in the CMDB.
You should establish your ServiceNow CMDB as the reliable and centralized authori-
tative reference which houses the description of the CIs youve identified and seeking
to manage by their approved-for-service Configuration attributes. This requires the
data to be managed across a full lifecycle, from originating, to maintaining it for utiliza-
tion, and then sustaining its verifiability to determine whether it is current or obsolete.
The representation of authorized CIs must be modeled first and foremost. The type
of a CI determines the criteria by which it may be uniquely recognized in manage-
ment processes such as discovery, classification and registration. All of which aim
to detect and assure that a CI is recorded, deployed, and accountable in compliance
with approved specifications.
The ServiceNow platform is based on service-oriented architecture (SOA), in which

all data objects can use web services to access bi-directional data-level integration.
The interface is also direct and dynamic because all modifications to existing objects
and all new objects are automatically published as a Direct Web Service. A more indirect
web service creation and usage can be achieved through Mapped Web Service where
a transform map is used to gather incoming web service data into the final target.
HGCNOW.COM 17
1.4 HO W T O P R E P A R E ?
Our recommendations are to undertake the following activities before you proceed
with your CMDB initiative:
Identifying a process owner and the relevant key stakeholders [users / customers
/ service owners, etc.]
Appointment of a Configuration Management & CMDB Team
Documenting and keep current your CMDB blueprint data model
Analyzing existing systems
Documenting and establishing a roadmap strategy
Developing a configuration plan and high level system design
Plann strategically and implement tactically
This activity is not likely to be as resource intensive as subsequent phases, but will
require clear senior management support to be successful. The goal is to define
and agree to the conceptual process definitions, mission, goals, objective and
scope), perform a high-level analysis of current systems, processes and related
initiatives, determine requirements and create a high level conceptual design most
appropriate for.
FIGURE 10 CMDB PREPARATION STEPS
1.4. 1 BUILD Y OUR PRO JECT TEAM
Since a tight relationship exists between Change, Release and Configuration Man-
agement, it is advisable that all be considered together holistically. A single ini-
tiative may be required if a central function is to be set up to support these three
processes.
A central function may be responsible for managing changes to hardware, software,

communication equipment, documentation and procedures that are relevant to
support and maintain your business services.
The management of these changes, and the rigor with which they are enforced, is a
key element for a successful Configuration Management process. The SACM process
requires staff who will adopt a disciplined and painstaking approach, all the while
paying due attention to detail.
18 HGCNOW.COM
FIGURE 11 PROJECT TEAM
A project team that is required to deliver any CMDB initiative, needs to determine
the number of resources required. The following must be considered:
Whether the Configuration Management team can be assigned as part of other

responsibilities
Whether the Configuration Management team is to be responsible for projects
as well as the infrastructure
Whether the group is to be part of a joint Change, Configuration Management
and Release Management team
The size of the IT infrastructure and the level at which control is to be maintained
(number of CIs to be controlled)
Number of staff who will be performing control activities in other groups and
projects
1.4.2 B U IL D A S A CM PRO JE C T C O M M I T T E E
The degree to which a CMDB can be effectively implemented is based upon several
systemic variables and factors. These domains of control reside (at least during
critical provisioning and deployment processes) within your organization.
As part of a foundational CMDB process, entry points of control are critical to foun-
dational data. The control processes & systems which provide these entry points of
controls and governance must be controlled and tightened. Ownership and stew-
ardship of data must be formalized.
HGCNOW.COM 19
This phase begins after you have successfully identified the process owner and
respective key stakeholders. Once you have done that, your next step is to bring
the two together for formal meetings aiming to define and agree on the process
definition, goals, objectives and scope using the ITIL process documentation as the
starting point and comparison. The objectives of this phase are to:
Define the processes purpose and high level objective based on your IT business
drivers
Derive a list of detailed objectives (measurable process deliverables)
FIGURE 12 SACM TEAM
To ensure stakeholder, input and consensus, a review committee/working group of

key stakeholders should be established to promote ongoing process development
and improvement. Initial key stakeholders would likely include Change, Release,
Inventory/Asset, and Continuity process owners to start. Service Level Management,
Financial Management and Security Management would be phased in as appropriate.
A key to a successful CMDB implementation is to enforce Change Management

Process by:
Always attaching a Change to an existing and valid CI in the infrastructure

Open a service request for any non-existing CIs, which can then be investigated
and added to the CMDB accordingly, helping future change records from being
easily created.
20 HGCNOW.COM
Update the CMDB with the CIs version, once the change has been executed
successfully.
Identify which CIs are not controlled by Change Management by adding an
attribute. For example, end-user computing CIs are not usually controlled by
Change Management.
Facilitation of formal discussions between the process owner and the committee of
key stakeholders will better position the successful implementation of the process
by clarifying business requirements, identifying tactical changes (i.e. quick wins),
and developing a longer-term strategy for positioning people, processes and tools.
1.4.3 P E R F O R M A N A LY S I S O F E X I S T I N G S Y S T E M S
To introduce a common CMDB with consistent processes, the following must be

identified and analyzed:
Determine or establish owners of high level CIs (Services, systems, platforms,

application, etc.)
Current scope and resources (people and tools).
Current Asset Management, Configuration Management and Change Manage-
ment practices, processes and procedures.
High-level Configuration data held in current inventories, hard copies, local
spreadsheets and databases.
Roles, responsibilities and capabilities of staff involved in current Configuration
Management activities.
Determine organizational context, both technical and managerial, within which
Configuration Management activities are to be implemented.
Analysis of interfaces (projects, suppliers, application and support teams).
Assessment of relevant processes, procedures, guidelines, support tools, roles
and responsibilities for each of the Configuration Management activities.
Identify location of storage areas and libraries for hardware, software and doc-
umentation.
1.4.4 D E V E L OP A D E T A I L E D C M D B D E S I G N BL U E P R I N T
Controlling the IT infrastructure and business services across distributed systems,

multiple locations and support groups, requires careful planning. The planning stage
uses the process definition and current state analysis as a basis and involves coop-
erative work with Release and Change Management processes, as there are many
interdependencies among them.
Depending on available resources, the organization, and the IT infrastructure, Con-

figuration Management may be a completely centralized solution or it may be dis-
tributed, based on technology or platform. It is vital that an agreement be reached
on the high-level design plan before any detailed work begins.
HGCNOW.COM 21
FIGURE 13 IT INFRASTRUCTURE MAP
Once the fundamental decisions on scope have been made and the planning activi-
ties have been completed, a detailed plan for implementation must be created. This
will involve either creating or revamping procedures and records.
The key activities during this stage might include the following activities:
Develop and obtain agreement on roles, responsibilities and training plans,

documented in the previous stage.
Analysis of existing Configuration Management activities in more detail, including
interfaces to other processes, procurement and development.
Analysis of the capability of existing functions and staff involved in Configura-
tion, Change and Release Management.
Review of Asset & Configuration data held in hard-copy, local spreadsheets or
databases, and develop a conversion/loading strategy with each team.
Gather, refine, and gain agreements on functional requirements and specifications.
Develop criteria for any additional automation.
Design the Configuration Management system in detail, including interfaces
to Change Management, and other Service Management processes in scope.
Set up CI types, attributes, types of relationships, high-level CIs.
Review SACM business processes and procedures that are integrated with the
discovery/monitoring tools.
Test the CMDB and other support tool(s) allowing sufficient time to rectify any
problems with future implementation.
Communicate and train staff in both the importance and use of Asset Manage-
ment, Change Management and Configuration Management.
22 HGCNOW.COM
FIGURE 14 CMDB BLUEPRINT MODEL
1.4.5 R E V IE W YOUR S A CM P R O C E S GO V E R N A N C E & R O LE S
Turn IT process touch points with other IT functions into specific requirements. The
requirements must reflect how other groups will interact with the CMDB and any
special needs these groups have. A detailed SACM process must be designed with
the following in mind:
Maintain accurate IT infrastructure data by utilizing audits of what should be

deployed against what is discovered.
Learn how configuration items are changing over time through capturing the
configuration of each CI, tracking changes to it, and providing analytics to
report on the history of these configuration changes over time.
Decrease IT system management costs by providing visibility on up-to-date IT
resource data directly to the incident and problem management process.
Increase IT system availability by providing change coordinators visibility to
application relationships, helping drive detailed impact analysis and deci-
sion support and reducing unintended upstream and downstream impacts,
of changes.
HGCNOW.COM 23
FIGURE 15 SACM PROCESS ROLES
SACM ensures that selected components of a complete service, system, or product

(the configuration) are identified, baselined, and maintained, confirming changes
to these CIs are controlled.
These objectives are achieved using the following sub processes:
Identify configuration items: defines the types of CIs and attributes that will be
placed under control of Configuration Mgmt.
Control configuration items: [add/update/delete] ensures that all additions,
updates, and deletions have the appropriate controlling documentation.
Report configuration status: ensure information for all configuration items is
available to any authorized requester.
Verify and audit configuration items: Verify that the CMDB accurately reflects the
environment and established standards by performing periodic audits followed
by remediation process to rectify any discrepancies identified.
1.4.5. 1 CI S e r v i c e O w n e r
The CI Service Owner is a person or a team that is responsible for data accuracy
and relationship mapping between CIs for their own services.
The application service CI ownership of an application is defined by the Portfolio

Director.
The CI ownership of technology components is defined by technology and
infrastructure team.
24 HGCNOW.COM
This service owner role is represented by a subject matter expert for specific business
service, and a supporting service model in the CMDB. Specific responsibilities may
include:
Business process manager or delegated business analyst

Provide subject matter expertise to develop and maintain the processes and
technology
Identify new service to be included in CMDB
Create detailed data model for new service
Ensure that all theirs CIs are recorded and the associate attribute and relationship
information is accurate
Perform in CMDB audits as requested by the SACM Manager
Provide input to the SACM manager into what attributes and relationships need
to be tracked within the CMDB
1.4.5.2 C o n f i g u r a t io n Pr oc es s M a n a g e r
This role is responsible for the Configuration Management process, which is focused
on identifying, documenting, tracking, and maintaining information about the Con-
figuration Items (CI) in the CMDB.
The SACM Process Manager is responsible for populating the CMDB for all parties
that are interested. His/her role also encompasses verifying that the data within the
CDMB is fit for purpose. As the business and technology change, this role ensures
that the CMDB content will change in a lock step manner.
The SACM manager role is responsible for the ongoing maintenance and accuracy
of the CMDB repository which is used for impact analysis, technical diagnosis, and
in service entitlement as a potential later as the process matures. Specific respon-
sibilities may include:
Own, maintain, and continuously improve the Service Asset & Configuration
process.
Sponsor improvement initiatives and drive the requirements for the CMDB
application.
Report on Configuration Management activities, e.g. number of CIs populated,
number of CIs associated with changes, etc.
Trigger the CMDB audit process and define the scope of the audit based on
the input from CI owners and IT management.
Work with CI managers to prepare for any requested CMDB reports and queries.
Document and maintain the Configuration Management process.
Develop, announce, and maintain Configuration Management feedback process
as well as suggest areas for improvement.
Improve the SACM process continually as required.
Define what CIs to track and what kind of data attributes for each CI as well as
how the data is captured and maintained.
HGCNOW.COM 25
1.4.5.3 C M D B A d m i n i s tr a t or
This position is responsible for overseeing the CMDB data management, focusing on
information security, training, backup and recovery, and long-term planning. Some
of the key responsibilities are:
Work with the SACM Process Manager to audit the CMDB to ensure accurate
and appropriate use of all the data found in the CMDB.
Develop and implement data administration policy, standards, and models.
Develop policies and procedures for data access and usage.
Establish data security programs and policies.
Establish long range data capacity plans and extend the CMDB data model
only when needed.
Determine what new data is needed to meet the identified business needs.
Define what data is used by each department within your organization.
Define the process for maintaining data throughout its lifecycle.
Determine when data can be purged either due to business requirements or if
the data adds no value.
Populates the CI data and creates new CI classes as needed.
Establishes baseline for managing the services.
1.4.5.4 C o n f i g u r a t i o n A u d i t or
The Configuration Auditor plans and executes the verification and audit of configura-
tion data as well as validating the accuracy of the CMDB content. This is conducted
based on a pre-agreed timeframe. Specific responsibilities may include:
Planning the CMDB auditing.

Performing the audit and collecting of audit information.
Identify unauthorized CIs.
Communicate audit findings.
Accept, verify, and initiate work relating to configuration audit requests.
Use tools for reporting and information collection regarding the CMDB.
1.4.5.5 CI A n a l y s ts
The configuration analysts are responsible for coordinating all Configuration Man-
agement activities at the business unit level and/or per specialized infrastructure.
Ex: Network Analyst, Server Analyst, Data Center Analyst, etc.
The Configuration Analysts coordinates all their respective department/group activ-

ities involving the CMDB. Some specific responsibilities may include:
Identify and add physical and logical CIs.

Establish and construct CI relationships.
Identify current data repositories, data sources, and work with the administrators
to import the data into your CMDB.
Responsible for the day to day updates to the CIs.
26 HGCNOW.COM
Update the CMDB with new configuration items and relationships.

After the change is implemented, update the appropriate CI attributes and
relationships accordingly.
1.4.5.6 C o n f i g u r a t i o n C o n t r ol B o a r d
The Configuration Control Board is required to ensure that the overarching intention
and policies of Configuration Management are employed throughout the Service
Management lifecycle and with specific consideration for every aspect of the com-
plete service. The Board has the following responsibilities:
Defines and controls the service configuration baselines in terms of core and
support services, applications, information, service, technical, infrastructure
ensure that they meet the requirements established in the Service Design.
Reviews changes in the service configuration for compliance with standards,
contractual and internal requirements.
Originates requirement changes for service configuration to comply with con-
tract change requests.
In some organizations, the Configuration Control Board will be combined with

change, thereby providing a holistic view of the current and proposed services and
service models, enabling better control, change evaluation, impact assessment and
understanding.
1.4. ALIGN Y OUR REPOR TING R E Q U IR E M E N T S
As with all processes, the performance of SACM should be monitored, reported on,
and improved upon. To optimize the cost and performance of the configuration
items, the following measures can be applied:
Percentage improvement in maintenance scheduling over the life of an asset.

Degree of alignment between provided maintenance and business support.
Improved speed for incident management to identify faulty CIs and restore
service.
Impact of incidents and errors affecting CI types, e.g. from suppliers or devel-
opment groups, for use in improving the IT services, etc.
Percentage of re-use and redistribution of under-utilized resources and assets.
Degree of alignment of insurance premiums with business needs.
Achieved accuracy in budgets and charges for the assets utilized by each
customer or business unit.
Percentage reduction in adverse business impact due to outages and incidents
caused by poor asset and configuration management.
Improved audit compliance.
Increased quality and accuracy of asset and configuration information.
Fewer errors caused by people working with out-of-date information.
Shorter audits as quality asset and configuration information is easily accessible.
HGCNOW.COM 27
Reduction in the use of unauthorized hardware and software, non-standard, and
variant builds that increase complexity, support costs, and risk to the business
services.
Reduction in the average time and cost of diagnosing and resolving incidents
as well as problems.
Changes that were not completed successfully or caused errors due to poor
impact assessment, incorrect data in the CMDB, or poor version control.
Reduction in risks due to early identification of unauthorized changes.
28 HGCNOW.COM
2. DESIGN Y OUR CMDB

SACM process is a requirement for an effective IT Service Management, and IT
operations management. The SACM process relies on a solid inventory databases,
as well as discovery and monitoring toolsets, which must be examined as part of
your CMDB implementation initiative.
FIGURE 16 CMDB SCOPE & SPAN
Configuration Management is responsible for tracking configuration information

associated with hardware and software assets that are necessary to deliver opera-
tional services. During the first stage of the CMDB implementation, a project team
must be formed, and the inputs should be gathered from various participants during
the working sessions.
The CMDB model is needed to identify all the working data that will ensure that the
SACM process will be able to meet its objectives. To help uncover your underlying
CMDB and design it on paper you will need to seek answers to the following ques-
tions for all CIs that are in scope:
Which raw data is currently managed and tracked by each team/unit.

How are services being delivered to clients (internal/external).
Identify what can be discovered, manually entered, controlled and maintained
What information and data needs to be considered, presented, federated, main-
tained, and controlled for managing your business.
Set standards and establish naming conventions for both CIs and relationships.
Manage movements into and out of secure libraries.
Support configuration item audits and identify interdependencies.
Link configuration item changes to specific Requests for Change (RFC).
Which KPIs to track and which reports to create.
HGCNOW.COM 29
2. 1 CMDB DESIGN POLICIES
The most important key for a successful CMDB implementation is to establish your
common CMDB design policies. As a general guideline and recommendation, the
following policies can serve as a starting point:
Align with enterprise architecture.

Minimize manual data entries and maintenance (promote automation where
applicable).
Accommodate the right CI types that central IT might use (determine the value
vs. complexity).
Establish data ownerships and responsibilities.
Maximize design simplicity so it can be applied to any IT unit.
Support exploding business services into detailed CIs that make up and sup-
port those services.
CMDB design principles are rules for managing configurations, ranging from iden-
tifying governance requirements to handling specific states of the configuration
lifecycle, including procurement, retirement, and disposal of assets, as well as the
detail and control required to maintain a desired level of traceability and auditability.
2.2 CMDB DESIGN W ORK SHOPS
During the execution of the CMDB design workshops with the key stakeholders, you
need to communicate your vision and goals as discussed in the previous chapters.
Your objectives must be aligned and communicated up-front with the workshop
participants. As a general guideline and recommendation, the following can serve
as a list of CMDB objectives to adapt and use:
Develop current state observations, target states, and design principles.

Enhance the future (to-be) configuration management process by improving
current policies, processes, procedures and establishing clear defined roles and
responsibilities for managing CIs.
Define and establish key performance indicators (KPIs) and associated critical
success factors (CSFs) to effectively measure, report, and improve the config-
uration management process and CMDB (performance and accuracy).
Develop the CMDB framework, which comprises of the conceptual CMDB data
model and data sources.
Develop a design document with supporting technical requirements in align-
ment with the enhanced configuration management process and approved
conceptual CMDB data model.
Identify key stakeholders and their business requirements through individual
assessment meetings.
Utilize inputs to identify and document the current state.
Utilize inputs and ITIL CMDB best practices process activities to develop a
desired or target state.
Identify and assess gaps and issues that exist between the two identified states.
30 HGCNOW.COM
Identify any gaps and issues for supporting processes.

Prepare a summary of the findings and recommend a strategy for developing
a formal CMDB implementation plan and design blueprint.
FIGURE 17 CMDB WORKSHOP TYPES
2.3 CMDB DESIGN DELIVRABLES
The CMDB blueprint model (conceptual picture) is needed to identify the working
data that will ensure that the SACM process meets its objectives with respect to the
future requirements by other ITSM processes. Your expected workshop outputs can
be summarized as below. But, your desired outcomes are not limited to list below.
Establish common standards.

Review CI types and sub-types list.
Establish generic CIs (logical grouping).
Determine what goes in the CMDB by order of importance and effort required.
Establish common CI attributes.
Establish CI attributes and relationships by type of CIs.
Establish and consolidate discovery sources for each CI type, attributes, and
relationships
Establish data sources and feeds for non-discovered CI types, attributes, and
relationships
During the design workshop, you can provide your participants with a template
workbook to fill any information they might have to help you to get started on
mapping your services. Be forewarned it is a rigorous exercise, but it will help you
understand your services.
Our recommendation for documenting the workshop outputs is to document the

information into separate Excel spreadsheets for each CI grouping (category). You
can name your configuration workbooks as:
CMDB- workbook-00-Reference Data

CMDB- workbook-01-Service
CMDB- workbook-02-Application
HGCNOW.COM 31
CMDB- workbook-03-Database
CMDB- workbook-04-Servers
CMDB- workbook-05-Data Center
CMDB- workbook-06-Network
CMDB- workbook-07-Telecom
CMDB- workbook-08-Storage
CMDB- workbook-09-Backup
CMDB- workbook-10-End-User Computing
CMDB- workbook-11-Hardware
CMDB- workbook-12-Other
FIGURE 18 CMDB WORKSHOP DELIVRABLES
NOTE: You can email us at cmdb@hgcnow.com to get free copies of our con-
figuration template workbooks including attributes by CI types, and proposed
CI relationships.
32 HGCNOW.COM
2.4 C M D B D E S I G N A P P R O A CH
The Practical steps and guidelines to follow when documenting the CMDB blue-
print can vary between each organization, depending on the goals you are trying
to achieve or the issues you are aiming to resolve. But one constant element of this
equation remains that you must obtain the right value versus the complexity of
building and managing your future CMDB in ServiceNow .
One way to define the CI attributes that you will maintain in the CMDB versus those
that will reside in federated data stores is to establish a guideline based on Value
vs. Complexity to maintain, as seen in the image below:
In the following sections, we will dive further into understanding the components
of a CMDB blueprint, which can be simplified as:
Business Services structure

Related processes requirements
CI types to include
CI attributes to manage
CI relationships to control
2.4. 1 IDENTIFY Y OUR BUSINES S SER VICES

& MAPPING LAYERS
Services are defined in various places, and not all business services are defined and
available in the current service catalog. Also, services are often referred to with
applications name.
Definition of a service, per ITIL: A means of delivering value to customers by

facilitating outcomes customers want to achieve.
Definition of a service, per us: Any IT technology service made available to
constituents in the context of their role(s), whether provided by central IT units
or by some other supplier.
Identify requirements that specify how the service catalog will leverage the relation-
ships between services and the underlying CIs. Understanding which CIs relate to a
service enables you to better meet SLAs and allows you to conduct service-based
costing during the design workshops. The analysis of the following questions will
enable you to determine the types of attributes required to include in the CMDB design.
A good understanding of the types of services your organization offers helps

establish the CI structuring and relationships.
Knowing the customers for the services you provide helps define CI relation-
ships or attributes, or both.
Understanding the services and infrastructure each service offerings relies on
helps determine the CI structuring and relationships.
Understanding service commitments helps define the CI attributes.
Reporting requirements for effective delivery management helps define the
CI Attributes.
HGCNOW.COM 33
The enterprise architecture approach is a layered view providing a natural way to
look at the service-oriented models. The main objectives of EA are:
Includes a formal description of a system, or a detailed plan of the system at

component level to guide its implementation
Document the structure of components, their inter-relationships, and the prin-
ciples and guidelines governing their design and evolution
The business service depends on a network service, an application service, and so

forth. By defining the business services as a CI in the CMDB and relating them to the
technology services and the application services, will aid in identifying the impact
of incidents and problems that are recorded against the infrastructure CIs or the
application CIs to the business service.
FIGURE 19 SERVICE ARCHITECTURE LAYERS
The service catalog includes specific business services to be available for use by the
customer. These services are offerings that are bundled and consumed as requests
on the portal or the regular application view of a Service Catalog.
The CMDB is a very effective tool, allowing viewing of information from both the
service and infrastructure perspective. The following relationships were established
to ensure that the CMDB will support an effective delivery of business services.
The CMDB designs often overlook important service management attributes. Sam-
ple service management attributes must include the following, as discussed during
the workshops:
Service level targets and priority

Service entitlement information (hours of service, required approvals, etc.)
Service notifications, communication information, etc.
Service owners (by their job titles, for example)
Service maintainers
Service managers (by their job titles, for example)
34 HGCNOW.COM
FIGURE 20 SERVICE MAP VS. SERVICE OFFERINGS
2.4.2 IDENTIFY REQUIREMENT S B Y PROCES S
SACM is the foundation process that endeavors to provide an accurate and logical
model of the IT infrastructure as well as the relationships that exist between com-
ponents, systems and provided services.
It is one component of the larger IT Service Management vision that seeks to ensure
Business Services are aligned to business needs. It also provides the core data used
in Incident resolution, Problem analysis, Change Management, Release Management
development and design. It is important to understand that the processes are inter-
related because the IT infrastructure being managed is also interrelated.
2.4.2. 1 Change Management
Change requests to implement a new component (used for impact and risk
assessments of a proposed change).
Inbound and outbound CMDB controls and governance.
The CMDB breaks down the barriers between IT and the business. The infor-
mation removes silos and helps people, processes, and technologies work more
efficiently together.
As the complexity of the IT infrastructure increases, the CMDB containing infor-
mation about all the CIs and how they work together will help avoid downtime,
by more efficiently planning and better appreciating how those changes affect
the business services.
HGCNOW.COM 35
The CMDB will aid in better risk assessments and improve security. Use the CMDB
data to assess the risks to the business associated with known vulnerabilities
on servers and installed applications, which will assist in prioritizing changes
on business services.
Helps keep track of any changes in software. The data from the CMDB aids in
determining if there are any unauthorized or illegal software being used.
The CMDB uses the concept of versioning. This allows the CMDB to track
the historical states of a CI over time and to determine recommendations for
improvements to the business services.
The various states of CIs can be compared to see what changes were recorded
as of their evolution.
2.4.2.2 Incident Management
Helps to determine customer impact and assists with determining priority and
severity of a failing component.
Provides client and service criteria, as well as severity and priority information
for configuration components based on service level objectives.
Usually, the lack of information found in the CMDB and the multiple operational
toolsets used for monitoring, results in the following:
Longer time to consolidate and detect issues.

Multiple configurations to maintain in various places.
Events at the Service Desk are not opened automatically.
Notifications and escalations not automated.
No correlations between events and no automation to repair known issues.
FIGURE 21 INCIDENT MANAGEMENT WITHOUT CMDB
36 HGCNOW.COM
FIGURE 22 INCIDENT MANAGEMENT WITHOUT CMDB
2.4.2.3 Av a i l a b i l i t y M a n a g e m e n t
Provides core data such as relationships between components to enable design

of reporting and subsequent measurement of business services.
Provides a central information repository that links availability, reliability and
maintainability of services to the underlying IT components.
2.4.2.4 S e r v i c e L e v el M a n a g e m e n t
Identifies the IT infrastructure components that are required for the delivery
of services to the customer, further allowing for accurate establishment and
measurement of the objectives in a Service Level Agreement (SLA).
Provides CI relationship data that links SLAs to customers and to all related CIs
that are required to provide the service the Customer pays for.
2.4.2.5 S e r v i c e Ca t a l o g
Inventory of services (Services as CIs) including business service, applications

and technology services
Presents configuration information about the services the clients are entitled to.
Provides configuration information about the components used to deliver ser-
vices to clients.
HGCNOW.COM 37
2.4.2.6 Pr o b l e m M a n a g e m e n t
Enables determination of components affected because of another failing com-

ponent.
Provides the IT infrastructure data required to identify root cause and course
of action for problems.
Asset and inventory tracking.
Utilizes the same core data and are likely to interface for supporting license
management efforts.
Enables Operating Level Agreements (OLAs - with internal IT groups and exter-
nal service providers) and Underpinning Contracts (UCs - with external service
providers) showing customer ownership.
2.4.2. 7 Busines s Continuity
Provides the baseline snapshot of the IT infrastructure which could assist in the
recreation of an environment in the event of a disaster or major interruption
to service delivery.
Stores information about the IT infrastructure components, their configurations,
and their dependencies to each other and key business processes.
Identifies the priority and the agreed-upon minimum level of business operation
following a major service disruption.
Tune and/or upgrade various components to provide a higher confidence in
high availability.
Reduced cost of redundant systems by capacity planning at the group or orga-
nization level instead of the individual system level.
Reduced time to resolve capacity-related incidents and problems.
2.4.3 U N D E R S TAND Y OUR CI C A T E G O R I E S
A CI is any component or service asset that needs to be managed to effectively

deliver an IT service. Information about each configuration item is recorded in a
configuration record within the configuration management system and, is maintained
throughout its life cycle by the SACM process.
Define the optimum level for CIs, both service CIs and infrastructure CIs, in your
CMDB. This step helps determine the overall breadth and depth of the structure of
your CMDB data model, based on the discovered information, inventory tools, and
manually added data.
Construct the CMDB blueprint model using the requirements identified for the Service
Catalog, the IT business processes, and the IT service model design, by assessing
the data required. Then, present it for approval by your organization.
To better organize the workshops, process documentation, and configuration we

recommend splitting your work into the following categories.
38 HGCNOW.COM
FIGURE 23 CI CATEGORIES
2.4.3. 1 REFERENCE D ATA
FIGURE 24 REFERENCE DATA
HGCNOW.COM 39
Does the IT component represent a specific type of system, user, location, or orga-
nizational data that, when represented in a structured format, represents various
types of information utilized inside the CMDB.
FIGURE 25 SERVICENOW REFERENCE DATA ARCHITECTURE
2.4.3.2 B u s i n e s s S e r v i c eS
FIGURE 26 CI CATEGORY BUSINESS SERVICES
40 HGCNOW.COM
A business service is composed of both physical and logical components. When

building the CMDB its important to map your services manually but preferably
automatically using both discovery tools and the operations solutions at your
disposal.
Service Portfolio: This object represents the top level of the service catalogue
and represents a grouping of similar services.
Service: A service is a combination of IT and non-IT systems that supports a
business objective and is perceived by the customer as a coherent whole.
Sub-service: A sub-service is a discreet component of a service or services.
This level object is only used to provide clarity for complex services.
System: An integrated composite that consists of one or more of the processes,
hardware, software, facilities and people, that provides a capability to satisfy a
stated need or objective.
Sub-system: A discreet component of a system that is usually representative
of a single function or purpose. This level object is only used to provide clarity
for complex systems.
- Service availability & support
- Service Cost
- Service metrics and SLA
2.4.3.3 Applica tions
FIGURE 27 CI CATEGORY APPLICATIONS
HGCNOW.COM 41
Applications, residing on application servers, are a group of primarily software
components that accomplish one or more tasks. This group is also viewed to be
considered as a unit. Applications can be as simple as one executable file running
on a single computer (such as Microsoft Word) or as complicated as a distributed
multi-tier J2EE application, load-balanced across multiple web application servers.
Managing software applications in the CMDB is not an easy task, but it starts with
understanding what an application is. To maintain and manage applications inside
your CMDB, use the following guidelines.
Applications: A program designed to perform a specific function directly

for the user or, in some cases, for another application program. Applications
use the services of the computers operating system and other supporting
applications.
Middleware: Software that sits between two or more types of software and
translates information between them. Middleware can cover a broad spectrum
of software and generally sits between an application and an operating system
or a network operating system.
Application Management: Software that observes, supervises, controls, protects
or verifies operations of a system.
Software Logical Disk: A division of a disk or storage area that is treated by
the operating system as a discrete physical disk.
Network Protocol: Set of rules defining the syntax and semantics of commands
and possible responses exchanged between two or more computers on a
network, including the order in which the commands can be specified.
Operating System: Collection of software programs that supervises the exe-
cution of other programs and the management of computer resources. An
operating system provides an orderly input/output environment between the
computer and its peripheral devices. It enables user-written programs to execute
safely. An operating system standardizes the use of computer resources for the
programs running under it.
Business Applications: The IT component of a piece of software; either pur-
chased, developed, or composed (reuse of other software components) that
provides business functionality of a given service element or system?
- Developed or
- Service-specific commercial off-the-shelf (COTS) application
Support Software: Is the IT component of a piece of software that indirectly
supports a system function, but does not provide the core functionality of a
given system?
- Operating system
- Backup software
- Antivirus software
- Monitoring software
42 HGCNOW.COM
FIGURE 28 EXAMPLE APPLICATION CI TYPE
2.4.3.4 Da t a b a s e s
FIGURE 29 CI CATEGORY - DATABASES
HGCNOW.COM 43
When you start adapting ServiceNow , you will notice that the CMDB includes the
following tables by default:
Database: is a relational database management system (RDBMS) such as SQL

Server, Oracle, mySQL, etc.
Database instances: Are the instances of a database. (SQL: one instance can
host several DBs; Oracle: you can have two instances connecting to the same
DB when using RAC)
Database catalogs: Metadata information - dependent on the technology.
2.4.3.4 S e r v er C o m p u t i n g
FIGURE 30 CI CATEGORY SERVER COMPUTING
The Type of systems containing Computing Devices information are divided into
the following,
Hardware server: An electronic device designed to accept data (input), perform

prescribed mathematical and logical operations at high speed (processing),
and supply the results of these operations (output). A digital computer pro-
cesses data as numbers and includes mainframe computers, minicomputers,
and microcomputers.
Hardware processor: The logic circuitry that responds to and processes the
basic instructions that drive a computer or server.
44 HGCNOW.COM
Hardware memory: The electronic holding place for instructions and data that
the processor can reach quickly.
Hardware network interface: The device that connects the computer with other
computers using some type of a communication medium. A network interface
may be an Ethernet card, Token ring card, modem etc.
2.4.3.6 I n f r as t r u c t u r e C o m p u t i n g
Data Center Is the IT component a physical location that supports some form of IT
operations or houses other IT components
FIGURE 31 CI CATEGORY INFRASTRUCTURE COMPUTING
Infrastructure CIs have a unique property they can be layered in relation to the
other CI types they support, particularly servers and applications. Infrastructure
computing can be comprised of other infrastructure elements. Consider a business
process which utilized a server/client application. The infrastructure elements can
be identified in terms of (and in relation to the person executing the process):
Client computer system, application interface.

Network routers, bridges, firewalls, access points, protocols, etc.
Data Center Power, UPS, Rack, Locations, etc.
Facilities power, water, cooling, space, etc.
HGCNOW.COM 45
2.4.3. 7 S t or a g e
FIGURE 32 CI CATEGORY STORAGE
Most of the complex CIs to map are related to storage; in the following section, we
will illustrate how you can define the CI attributes and data model for storage, fiber
and storage arrays systems.
Hardware Network Attached Storage (NAS): Storage that is set up with its
own network address rather than being attached to the department computer
that is serving applications to a networks workstation users.
Hardware Storage Attached Network (SAN): A high-speed special-purpose
network (or sub-network) that interconnects different kinds of data storage
devices with associated data servers on behalf of a larger network of users.
Hardware Storage: The holding of data in an electromagnetic, optical, or elec-
tronic form for access by a computer processor.
Physical Disk: A storage medium consisting of a spinning disk coated with
magnetic material for recording digital information.
Disk Array: A enterprise storage system that contains multiple disk drives. It is
differentiated from a disk enclosure in that an array has cache and intelligence
so can perform functions like RAID and virtualization.
46 HGCNOW.COM
Components of a typical disk array include:

- Disk array controller
- Cache
- Disk enclosures
- Power supply
Hardware Disk Enclosure: A computer storage device designed to contain
physical disk drives. The term is normally used to differentiate such a device
from a more advanced disk array. Therefore, a disk enclosure is a simple con-
tainer, sometimes with a power supply, but very little intelligence.
2.4.3.8 B a c k up
The attributes are categorized mainly as CI type, CI status, common hardware attri-
butes, software attributes, backup system attributes, and other attributes. A domain
consists of a master server with one or more media servers and storage units. A media
server may be on the same machine as master or on a different one. Storage units
are owned and monitored by the master server, while the media server is responsible
for doing the backup of data from the client to the storage unit. All servers which are
backed up by the master server are called clients. A storage unit is represented by:
A storage unit CI is used as target for backup image by media server CI
A storage unit CI communicates with media server CI
A storage unit CI is controlled by media server CI
FIGURE 33 CI CATEGORY BACKUP
HGCNOW.COM 47
2.4.3.9 End-user C omputing
FIGURE 34 CI CATEGORY END-USER COMPUTING
Your CMDB must be designed to enable the centralized management of the finan-
cial, contractual and demographic data relating to hardware Assets and end-user
computing related CIs such as Mobile phones, Workstations, monitors, etc.
The same data used by Assets will then be found in the CMDB tables, this will enable
you to make informed decisions regarding how assets can be used more effectively,
when to retire or cascade and help in budget exercises to determine future needs
of the Business based on the existing baseline.
Its recommended to integrate with discovery tools or use ServiceNow discovery to

discover your Hardware assets, populate the CMDB and then run hardware recon-
ciliation to identify any disparities in the baseline to verify you have control over the
environment and reduce the likelihood of rogue systems from being introduced or
existing on the network and to also identify any missing hardware such as mobiles,
laptops, etc.
2.4.4 I D E N T I F Y A T T R I B U T E S B Y CI T Y P E / T A B L E CLA S S
The configuration management database (CMDB) employs the following tables:
The core Configuration Item [cmdb / cmdb_ci] tables, which stores the basic
attributes of all the CIs.
The CI Relationship [cmdb_rel_ci] table, which defines all relationships between
CIs.
48 HGCNOW.COM
When you design your CMDB, there are 3 types of CI Attributes to consider:
ATTRIBUTE
DEFINITION EXAMPLE
TYPE
ID
Name
Owner
Mandatory attributes that apply to every Description
CORE
CI Type in the CMDB. Version
Status
Creation date
Update Date
Server
Make
Supporting attributes that are unique to Model
a type/class of CIs. Manufacturer
CLASS Categories are a special class of CI that Serial number
pass on attributes based on inheritance, Document
through parent-child relationships.
Version
Author
Editor
Server ABC123
Complementary attributes unique to a
CUSTOM specific CI to provide detailed informa- Last security audit date/time
[OPTIONAL] tion not expressed in core or class based Operator minimum security
attributes.
clearance level
Attributes are data elements that describe CIs, much like adjectives that describe
nouns. Attributes help to identify and detail the important characteristics of what
is in use, the status of the items, and the items location. Samples of hardware CI
attributes could include make, model, serial number, location, version, license number,
and so forth. For each CI attribute to be considered, the following topics should be
addressed during the design workshops:
What are the data sources that will populate your federated data model?
Where and how will the CMDB data be used in other systems?
How will you populate the CMDB with CI attribute information?
How can you simplify management of attributes through inheritance?
Some examples of attributes per CI Types might include the following:
Application Software: code version, code language, build, compiler version,

operating system version, image version.
Hardware: Manufacturer, make, model, serial number, MAC address, primary IP
address (fixed), firmware version.
Documentation: version number, author, editor, review process
HGCNOW.COM 49
CI CATEGORY TYPE CI ATTRIBUTE
Code version
Code language
APPLICATION
Build
SOFTWARE
Compiler version
DSL ID (could be a relationship) -> Future
Operating system version
SUPPORT
Build
SOFTWARE
Image version
Manufacturer
Make
Model
HARDWARE Serial number
MAC address
Primary IP address (Fixed)
Firmware version
Client ID
Location ID
REFERENCE DATA Address
Postal/ZIP code
Organizational identifier
Version number
Author
DOCUMENTATION
Editor
Review process
2.4.4. 1 M a n d a t o ry a t t r i b u t es
Before determining which attributes are to be managed by CI class, you must estab-
lish common attributes, which ones are mandatory and which ones are optional/
custom (unique to your organizational needs).
The list below is a good start-up for determining your common mandatory attributes
for all CIs in your CMDB.
FIGURE 35 COMMON MANDATORY ATTRIBUTES
50 HGCNOW.COM
2.4.4.2 O p t i o n a l a t t r i b u t es
Before determining which attributes are to be managed by CI class, you must estab-
lish common attributes and which ones are optional.
The list below is a good start-up for determining your optional common attributes
for all CI in your CMDB.
FIGURE 36 COMMON OPTIONAL ATTRIBUTES
Attributes are dependent on the CI classification in ServiceNow -- Reclassify a CI

by modifying its Class attribute. You can upgrade, downgrade or switch a CIs class.
When downgrading or switching a CIs class, attributes that are unique to the current
class, and are not defined in the newly reclassified class - are lost.
Each class in the class hierarchy is defined with a unique set of attributes. This set
consists of attributes that were inherited from the parent class, and additional attri-
butes specifically defined for the class. When you reclassify a class:
The set of attributes is adjusted to match the set of attributes of the newly assigned
class. Attributes are added or removed as needed.
A new record, with the CIs sys_id, is inserted to the table of the new class, with the
appropriate set of attributes for the class.
2.4.5 I D E N T I F Y R E L A T I O N S H I P S B Y CI T Y P E / CLA S S
One of the most significant benefits of ITIL Configuration Management is the

identification of how configuration Items relate to one other in various relationship
types. This information is used to facilitate component impact analysis and end-
to-end service modeling. To this end, physical and logical relationships between
configuration items and service structures must be identified and registered within
the CMDB.
HGCNOW.COM 51
Since automated administration of relationships is limited with the current avail-
able monitoring tools, balance of need and cost should be found when defining
relationships, as too many relation types will complicate maintenance and control
of the CMDB.
Identifying the specific CI relationship data that you will initially start with in the
CMDB, will be the key to a successful implementation of your CMDB. For each entity
in the CMDB, the data model specifies:
The unique identifier (primary key).

The suggested attributes.
The bi-directional links to other entities (reference data, drop-down values)
expressed as foreign keys.
These links (or relationships) are illustrated in the entity relationship diagram and
further explained in architecture data model section. They are of three types:
Parent/child relationships between CIs.

Internal relationships between the CMDB entities (e.g. hardware - location)
Links between CMDB entities and external entities (e.g. hardware - change
management data)
Our recommendation is to implement only a generic relationship (depending on the

situation) at first and then introduce more as needed. The key is to have the right
number of relationship types. Too many, and it may become unmanageable and not
easily understood by users. Too few, and it may not give you the detailed view you
need to interrogate the CMDB and analyze the information.
Relationships should not be determined in isolation. You must consider relationships

along with attributes, infrastructure and service configuration structures, and levels
when you create the CMDB service model blueprint.
2.4.5. 1 H ar dw ar e
Hardware-> Network
RELATIONSHIP Hardware-> Storage
Hardware-> Server
NAME depends on, runs on, connects to, is based on

DESCRIPTION The unique identifier of a Hardware CI related to this one
Hardware-> Software
RELATIONSHIP
Hardware-> Database
NAME Hosts
DESCRIPTION The unique identifier of the Hardware CI that hosts this Software CI
52 HGCNOW.COM
2.4.5.2 S o f t w ar e
Software-> Application
RELATIONSHIP
Software-> Database
NAME depends on, runs on, is based on, Exchanges data with, provides access to
DESCRIPTION The unique identifier of a Software CI related to this one
2.4.5.3 P erson
Person-> Hardware
RELATIONSHIP Person-> Software
Person-> Document
NAME Owns / Uses

The unique identifier of a Hardware CI that this person/Organization
DESCRIPTION
owns/uses
RELATIONSHIP Person-> Business Service

NAME Uses
DESCRIPTION Each person / Organization may use an IT Service
2.4.5.4 Or g a n i z a tio n
RELATIONSHIP Organization-> SLA

NAME Has
DESCRIPTION An Organization Unit may have SLAs for one or more services
Organization-> Hardware
RELATIONSHIP Organization-> Software
Organization-> Business Service
NAME Provides
DESCRIPTION Unique Id of the Provider (external Organization) of the CI
2.4.5.5 L oca tion
RELATIONSHIP Location-> Hardware

NAME Houses / Accommodates
DESCRIPTION Hardware CIs are to be found at a Location
HGCNOW.COM 53
Location-> Person
RELATIONSHIP
Location-> Organization

DESCRIPTION Persons/Organizations are to be found at a Location
RELATIONSHIP Location-> Document

DESCRIPTION Documents are to be found at a Location
2.4.5.6 Document
Document- > Hardware / Network / Data Center / Telecom / Storage

RELATIONSHIP
/ Virtualization
NAME Documents
Each Hardware CI may be documented by documents
DESCRIPTION (For example, this link is to be used to link Hardware CIs to contracts
(e.g. maintenance))
RELATIONSHIP Document-> Software / Database / Applications

NAME Documents
Each Software CI may be documented by documents
DESCRIPTION (For example, this link is to be used to link Software CIs to contracts
(e.g. license))
RELATIONSHIP Document-> Business Service

NAME Documents
DESCRIPTION An IT Service may be documented by documents (e.g. SLA)
54 HGCNOW.COM
2.5 CMDB D E S I G N A UT O M A T I O N
To properly manage and maintain your CMDB, you must implement automation
to monitor and control the technology services and their underlying infrastruc-
ture. For each CI Attribute by CI Class, you need to establish which CI Data will be
populated, federated and/or modified. Once those decisions are taken during the
design workshops, you should take full advantage of ServiceNow capabilities to
automate the CMDB.
Begin by taking an inventory of your organizations existing data repositories that

are internal and external to IT, in accordance with your organizations data require-
ments identified in step four. This will facilitate establishing priorities for each usage.
This information may appear in the form of a list or spreadsheet, or reside in formal
databases.
Once these data repositories are identified, it is equally important to discover the
following information for each:
Primary purpose of the data

Location
Owner
Users of the data
Accuracy of the data
Completeness of the data
Level of data detail (too little or too much)
How is the data supported and maintained?
Is the data integrated with change management?
What is the single trusted source for the data?
Is the data federated or is it replicated?
Next, assess and plan the level of work associated with scrubbing the data and
gathering new data in support of the requirements. In some instances, you may
even find it more effective and efficient to discard existing data and start anew.
Investigate what current tools are available within your organization for collecting,
storing, managing and updating the CMS data. Identify which tools meet the defined
requirements, and which requirements have yet to be met by existing tools. Knowing
your tool inventory will have a huge effect on the creation of your organizations
eventual data model and CMS structure.
Use tools to automate data collection and help mitigate the risk of errors that can
be introduced by manual data entry and maintenance. An effort should be made to
identify any additional tools that could help in the automation process and deter-
mine if a business case can be made to support their purchase. While developing a
business case may be difficult, aligning it back to the planning activities conducted
in steps three and five will help justify their purchase.
ServiceNow Discovery product gives the means to create an accurate, up-to-date

single system of record for the infrastructure.
HGCNOW.COM 55
It identifies IP-enabled configuration items (CIs), maps their interdependencies,
and populates and maintains them in the ServiceNow Configuration Manage-
ment Database (CMDB).
Discovery is scheduled on a regular basis to help ensure the accuracy of the CI
data underpinning ServiceNow applications across the enterprise.
Using ServiceNow Service Mapping in combination with Discovery, you can
discover both infrastructure and services, making the ServiceNow CMDB and
all applications service-aware.
Rapidly configure and launch secure, agentless discovery of hardware, software,
virtual and cloud resources, and their relationships.
Integrated discovery facilitates quicker service restoration from incidents, more
effective root cause analysis, proactive problem resolution, lower-risk change
execution, and better-informed business decisions.
Create custom patterns for any discoverable resource; identify custom applica-
tions and their dependencies; customize CMDB fields, tables, and relationship
descriptions; and federate with other data sources through integrations.
Without a discovery tool:
CMDBs struggle to remain current, do not contain the right type of information
to drive processes effectively.
IT staff cannot determine which business services are affected by changes,
failures, or performance issues. They cant easily determine root causes of ser-
vice problems.
56 HGCNOW.COM
3. C ONFIGURE Y OUR CMDB

The CMDB data model defines a certain number of categories and sub-categories
of CIs. These categories do not represent the individual CI types contained in the
CMDB but instead logical groupings of various CI types. The number of CIs in a
typical category and the level of details describing the CIs and their components
define the granularity of the CI structure. The diagram below details this structure
for each category.
The key factor in determining what to treat as a CI and what not to is dependent on
whether it should (and can be) managed. CIs are typically grouped into categories
such as hardware, software, and network, and then into classes, such as server,
router, application, etc.
The data model complies with the ITIL specification of baselines definition. Baselines
will be particularly useful for the definition and management of standard CIs (stan-
dard models) to support activities such as procurement, software distribution, etc.
Hardware standard configuration - > hardware baseline

Software standard configuration -> software baseline
Hardware and software standard configuration - > hardware baseline + links
to software baselines
For each type of CI, managing it properly requires maintaining a CI record that
keeps track of specific characteristics about that CI, including system names, con-
figuration settings, capacity, versions, operating system, and so forth. ServiceNow
provides a very large number of fields that are specific to certain categories and
classes of CIs.
As seen in the next section, the Configuration Item table is extended to other tables
such as Database [cmdb_ci_database] and Computer [cmdb_ci_computer].
The Computer table is extended to the Server [cmdb_ci_server] table, which is

extended to the UNIX Server [cmdb_ci_unix_server] table, and so on.
3. 1 CMDB TABLE CLA S S IFIC A TIO N S
The CIs are defined down to the lowest level at which a component can be inde-
pendently installed, replaced or modified. It should be considered that the chosen
level represents the level at which future changes will be managed (change man-
agement). The appropriate level must be defined so that a balance can be achieved
between information availability and the effort needed to support it.
During the CMDB conceptual model workshops, you should determine which CIs
sub-types will be managed as CI attributes, CI Relationships or a distinct sub-type.
To help decide between these two options the following criterion is suggested:
a component should be identified as a CI if one of these four aspects is to be
managed:
HGCNOW.COM 57
Its change history
Its incident / problem history
Its location
Its cost
3. 1. 1 BUSINES S SER VICES
FIGURE 37 CMDB TABLES BUSINESS SERVICE
3. 1 . 2 SER VER C OMPUTING
FIGURE 38 CMDB TABLES SERVER COMPUTING
58 HGCNOW.COM
3. 1.3 NETW ORK
FIGURE 39 CMDB TABLES - NETWORK
3. 1 . 4 D A TA C E N T E R
FIGURE 40 CMDB TABLES DATA CENTER
HGCNOW.COM 59
3.2 CI O W N E R S H I P
Through the CMDB, it should be possible to identify who is responsible for various
aspects of each CI, including approving changes and support. Within ServiceNow ,
you can assign an approval and a support group, as well as designating specific
users as owner and manager of a CI.
For any CIs or groups of CIs listed above, be prepared to identify who needs to be
assigned to which CI. Determining the assignments and ownership level required
is not an easy task. You should always ask the questions below to help determine
which CI attributes to track and control.
Owner
- Who bought the hardware?
- Who bought the software?
- Who bought the licenses for the software product?
Management owner
- Who managed the CI in the environment?
- Who provides sys admin duties for the CI?
- Who accepts changes on the CI?
Service owner
- What services are provided by the CI?
- Who owns the services?
- Who provides that service?
- Who defines the service?
Users
- Who uses the CI?
- Who physically has the CI under their control?
Governance
- Who audits the CI?
3.3 C I ST A T U S
The CMDB is also used to track the status of a CI from several perspectives. The
following tables show the default values for several of these fields. Please make a
note of any values that you or your team feel should be modified or added, and
be prepared to identify the value of these parameters for any CIs you manage or
support. The following figure indicates a common life cycle over a period.
There are many fields/attributes that can be used by default in ServiceNow .
Install status
Hardware status
Operations status
Business criticality
Classification
Used for
60 HGCNOW.COM
3.3. 1 BUSINES S CRITICALITY FIELD
Business Criticality can be used to automatically set priorities, and to guide support
teams in addressing issues or assessing the impact of a change, thereby using the
information to set the appropriate risk. This information can also be used as an input
to your Business Continuity Plan (BCP).
Most Critical
Somewhat critical
Less critical
3.3.2 INS TALL S TATUS F IE LD
The lifecycle of a configuration item (CI) is the span of time that begins when the
CI is created, and ends when it is no longer available for use. During its lifecycle, a
CI takes on different states, which should be reflected in its status. The following
table indicates possible status that may be used within the CMDB.
Absent
In Maintenance
In Stock
Installed
On Order
Pending Install
Pending repair
Retired
Stolen
3.3.3 HARD WARE S TATUS FIELD
Optional status mainly used for Asset Management, our recommendation is to

combine the default values with the Status field.
In Maintenance
In Stock
Installed
On Order
Pending Install
Pending repair
Retired
Stolen
Out of stock
In Transit
Defective
In Disposition
Pending Transfer
HGCNOW.COM 61
3.3.4 USED F OR F IE L D
The field Used for (environment) in ServiceNow defines the deployment environ-
ment of a specific CI, and can also be used to guide priority and risk analysis, as well
as mapping to outage or blackout windows. If a CI supports multiple environments,
it should therefore be assigned to the one with the most rigorous requirements.
Production
Staging
QA
Test
Development
Demonstration
Training
Disaster Recovery
3.3.5 OPERATIONAL S TATUS FIELD
The Operational Status field in ServiceNow can be used to track the current ability
of the CI to function in its intended role. It assists in preventing changes that might
otherwise be dependent on deploying a non-operative component.
Operational
Non-Operational
Repair in Progress
DR Standby
3.3.6 CLA S SIFICATIO N FIELD
The Classification field can be used to automatically set the criticality of a hard-
ware CI, and to guide support teams in addressing issues and/or assessing risks
and impacts of changes.
Production
Development
UAT
Disaster Recovery
Critical Infrastructure
Development Test
62 HGCNOW.COM
3.4 CI SER V I C E M A P P I N G
Business Services are another category of CIs that are key for achieving a true service
oriented organization and identify capabilities. These represent the services that
customers request that the organization deliver to fulfill their business functions.
Examples of business services and service offerings might include patient medical
records, radiology services, accounts payable, etc. Certain IT-specific business ser-
vices provide general technology support, including desktop computing, messaging,
or network access to the Internet, or they may be specific components underlying
both business services and IT services, such as databases, server computers, storage,
or backup.
FIGURE 41 SERVICE MAPPING
A Business Service Map (BSM) is a representation of the relationships between

Configuration Items, including other Business Services. Recording where CIs are
installed, what they are connected to, where data is stored or exchanged, and so on,
makes it possible to identify the dependencies between CIs. This simplifies trouble
isolation, impact and risk analysis, identification of change conflicts and capacity
limitations, and much more.
HGCNOW.COM 63
FIGURE 42 MANUAL SERVICE MAPPING ON PAPER
64 HGCNOW.COM
3.5 CI R E L A T I O N S H I P S
Understanding relationships between CIs is what differentiates a CMDB from an

asset database. One of the most significant benefits of implementing a CMDB is the
identification of how Configuration Items relate to each other in various relationship
types. This information is used to facilitate component impact analysis and end-to-
end service modeling.
To this end, physical and logical relationships between configuration items and
service structures must be identified and registered within CMDB. Since automated
administration of relationships is limited with the current available monitoring tools,
balance of need and cost should be found when defining relationships as too many
relation types will complicate maintenance and control of the CMDB.
FIGURE 43 CI RELATIONSHIPS
Any time you create a new classification (extend a table), you must create new
relationship rules.
ServiceNow relationship rules use separate tables to define the relationships

between specific CI base classes and dependent classes. When you extend a table
HGCNOW.COM 65
in the CMDB, you must create a new relationship rule in Configuration > Suggested
Relationships.
You must define your CI Types and relationships on paper first; then proceed to
align in the design in ServiceNow .
3.5. 1 REFERENCE D ATA
FIGURE 44 CI RELATIONSHIPS REFERENCE DATA
3.5.2 BUSINES S SER VICES
PROVIDER DEPENDANT RELATIONSHIP

Business Service Business Service Composed of
Business Service Process CI Realizes
Process CI Application Service Uses
Application Service Application Service Composed of
Application Service Application CI Realizes
Application CI Application Service Uses
Application CI Infrastructure Service Uses
Infrastructure Service Infrastructure CI Realized by
Infrastructure CI Infrastructure CI Composed of
66 HGCNOW.COM
3.5.3 APPLICATIONS
FIGURE 45 CMDB MODEL CI APPLICATION RELATIONS
HGCNOW.COM 67
3.5.4 DATABA SES
FIGURE 46 CMDB MODEL CI DATABASE RELATIONS
68 HGCNOW.COM
3.5.5 SER VER COMPUTING
FIGURE 47 CMDB MODEL CI SERVER RELATIONS
3.5.6 D A TA C E N T E R
FIGURE 48 CMDB MODEL CI DATA CENTER RELATIONS
HGCNOW.COM 69
3.5. 7 NETW ORK
FIGURE 49 CMDB MODEL CI NETWORK RELATIONS
3.5.8 S T ORA GE
FIGURE 50 CMDB MODEL CI STORAGE RELATIONS
70 HGCNOW.COM
3.5.8. 1 NA S
One NAS CI can host many tenants (EVS)

One tenant (EVS) space can host many files systems
One NAS CI can connect to one or many Ethernet switch ports
One NAS CI can connect to one or many UPS CIs
One NAS CI can connect to one or many Anti-Virus servers
3.5.8.2 S AN S w it ch
One host physically connects to one physical SAN switch

One physical host port (either host or storage array) connects to one physical
SAN switch port
One logical host port may connect to one or many logical storage array ports
A SAN switch IP will be part of a VLAN
Many physical SAN switches are connected to create one logical fabric
One physical SAN switch is connected to one or more physical UPS
One physical SAN switch is (assumed) connected to one physical Ethernet switch
3.5.8.3 S t or a g e A rr a y
One physical SAN switch port connects to one physical Storage Array port
Many logical host ports (WWNs) can connect to one logical Storage Array port
A Storage Array IP will be part of a VLAN
One physical Storage Array is connected to one or more physical UPS
One physical Storage Array is (assumed) connected to one physical Ethernet
switch
One Storage Array can contain one or many storage pools CI
3.5.8.4 S t or a g e P o o l
One Storage Pool can contain many Parity Groups

Many hosts/servers can subscript to one Storage Pool
One host/server can subscribe to may Storage Pools
3.5.8.5 H o s t gr o u p
Many host/server ports can be logically connected to one Storage Port; i.e. One
Storage Port can service many WWNs (organized by host groups)
One Storage Array can have many Storage Ports
One Host Group can exist in many storage Ports
Many WWNs can exist in one Host Group
One Host Group can only have one set Host Mode
HGCNOW.COM 71
4. C ONS TRUCT Y OUR CMDB
The conceptual target state, which must align with your business requirements,
should be implemented in a phased approach. With each phase, you will be posi-
tioned to capitalize on the benefits of implementing your IT Service Management
on an evolved and trusted CMDB.
The formula for implementing SACM includes PEOPLE, PROCESS and PRODUCTS.
People must be sufficiently trained.

Policies must be enacted to reduce the complexity and politics of environments
(i.e. multiple desktop models, multiple LAN standards, and complicated support
management and maintenance efforts).
Robust processes must be in place, and automation must be considered to add
efficiencies to manual and repetitive tasks.
The target state goal of implementing Your CMDB, is to support the Service Man-
agement objectives, by efficiently providing required data to supporting processes.
As such, access to the extended CMDB would allow you to:
Reduce incident duration and impact objectives of Incident Management.

Reduce recurrence of Incidents through identification of errors an objective
of Problem Management.
Reduce impact, risk, and cost associated with making Changes objectives of
Release and Change Management.
Provision of objective availability data for supporting Service Level Agreements
and Service Management review meetings objectives of Service Level Man-
agement.
The concept of maturity model was popularized by the Capability Maturity Model
(CMM) that defines the stages of sophistication for software development. This has
now been replaced by CMMi (CMM integration), which focuses on process improve-
ment. In both models, the five stages of maturity are defined. They are numbered
from 1 (low maturity) to 5 (high maturity) and there is also an implicit stage, zero,
that indicates a state of no formal process culture.
In most organizations, we were involved with, their initial overall Configuration Man-
agement Maturity Level was around 2.5 on a scale of 1 to 5 and it is usually due to
the following:
Non-standardized discovery tools.

The Change Management Process in place was not linked to Configuration
Management.
A CMDB tool was already deployed but it was not fully trusted and not main-
tained.
Asset Management deployed, but usually only for managing hardware assets.
No formal integration with procurement or having a sound financial management
solution.
72 HGCNOW.COM
4. 1 CMDB IMPLEMENTATION BES T-PRA CTICES
Our implementation recommendation is based on the information gathered and

analyzed to date, that you must formally recognize SACM, as being vital to your IT
organization and then adopt an organized approach for gaining process control.
To do this, a co-operative effort, including a senior management process owner and

stakeholders, must be undertaken to formulate a plan for moving forward. This plan
includes developing and documenting the conceptual, logical, and physical design
as it relates to process, people, and tools.
It is the underlying process of SACM that positions an organization to identify, track,

record, and report on infrastructure data as it is related to the management, costing,
and delivery of services.
The strategy recommended consists of stages, phases and data load by CI waves,
emphasizing pre-requisites, identification of stakeholder requirements, and validation
against business drivers for each step.
Our recommended best practice provides the starting point, and high level guidance,
for a well-defined process (organizational structure, tools, business requirements, CI
data, etc.). Adopting a phased approach for cutover allows the initiative to demon-
strate benefits early, as well as fine-tune the implementation activities to improve
their effectiveness. The Configuration Manager has the responsibility of creating
and maintaining this information in a formal Configuration Management Plan and
drafting a CMDB blueprint model on paper before embarking on bringing data into
ServiceNow and/or automating any data sources.
The CMDB, when catered to your environment, functions as a decision-making

tool, impact and root cause analyzer. But, by populating a large amount of data,
your CMDB may turn complex, causing a loss in structure and information, thereby
making its analysis less effective.
To set up a less complicated CMDB design, strategize on your CI List and their sup-
ported attributes and relationships. Given below are 3 easy steps through which we
can effectively populate CIs in the CMDB.
HGCNOW.COM 73
4. 1. 1 IDENTIFY BUSINES S CRITICAL CI
The first step is to identify the business-critical CIs as per the environment. Next,
group them in appropriate CI Types. Each CI Type holds its own attributes and
relationships that are defined with key stakeholders from the Service Catalog Man-
agement, and Change Management. Some of the entities that can contribute to
your CI list are:
Business services including:

Application services
Technology services including Hardware (IT and Non-IT assets, components)
Software (which are installed in the server/workstation like applications, oper-
ating systems, database)
Departments
Documents (license agreement, contract, lease agreement)
Users and supporting groups
Not all software CIs are considered as CIs. The softwares which are installed on
servers and workstations, and grouped under a CI Type are alone considered as
Configuration Items (CIs).
FIGURE 51 DATA LOADING APPROACH BY CI TYPE
74 HGCNOW.COM
4. 1 . 2 POPULATE C I D A TA I N W A V E S
After the CI List is strategized and confirmed, you need to populate the Configu-
ration Items (CIs). Various ways exist through which you can effectively populate
CIs into your CMDB.
Populate Workstation/Devices
- Auto-Discovery
- Manual Notify
Populate Users/Analysts
-Importing from Active Directory
- Importing from Locations
- Importing from Organizations
- Importing Groups
Populate other CIs such as IT services, Business Services, Departments, CI lists
- Automating Data sources and recurring integrations

- Importing CIs from CSV file
- Manual Addition of CIs
FIGURE 52 DATA LOADING APPROACH BY PROCESS WAVE
HGCNOW.COM 75
4. 1.3 C ONTINUOUS LY AD APT THE INF ORMATION MODEL
The overall information model is complete only when the relationships between the
CIs are defined. While populating Configuration Items using any of the methods.
the inter-dependencies between the CIs are identified and established. The rela-
tionships can be viewed from the Relationship Map which helps in impact and root
cause analysis.
4.2 C M D B D ATA L O A D I N G
It is recommended that Service Asset & Configuration Management process be

implemented gradually, in phases, beginning with the types of CIs or parts of the IT
infrastructure where control is perceived to be the most important, or in the greatest
of improvement, and then expanded to encompass other areas. The diagrams below
depict a view to build and construct the CMDB in a waved and progressive approach.
Since implementation refers to cutover to the new processes, rather than imple-
mentation of the tool, there is an additional planning associated with cutover. These
plans may be developed, as they will happen (and likely be improved) with each
repetition of process implementation, they are included here:
Determine what area (system or platform) will see most benefit from imple-
menting SACM.
Train your staff just prior to cutover to the new procedures and tools.
Define/develop Service Asset & Configuration Management plans for each
group and create local procedures.
Analyze and build modules for the Service Asset & Configuration Management
system to support processes & interfaces.
Assess and establish updated staff roles and responsibilities.
Develop and plan registration procedures for new or existing CIs.
Populate CMDB - Load Initial Configuration and related records into CMDB.
Cutover to new process - go live and support the implementation.
Continue taking on IT infrastructure CIs (CI inventory, populate CMDB, populate
DSL, etc.).
Monitor progress to ensure the new procedures and tools are being used effec-
tively and efficiently.
Approval to proceed with subsequent stages will require each time a formal char-
ter and an updated project plan. The plan would be expanded and further detailed
by the process owner, key stakeholders and Configuration Manager (who would
also be responsible for managing the project and maintaining the Configuration
Management plan and related documentation as each CI wave is automated and/
or imported in ServiceNow ).
A long-term program utilizing a multi-phased deployment approach is intended to

deploy several individual phases of any ITSM project in ServiceNow . The recom-
mended approach, based on current state and foundation guidance provided by
ITIL, is to perform the required work in stages.
76 HGCNOW.COM
The next phases will position for subsequent phases; which are longer term. Agree-
ment to the process definition, and high level plans in the initial Phase is required
before proceeding.
These high-level details will help to clarify what is and what is not in scope for each
stage. As well, it helps clarify how ITIL logically divides the activities associated with
Detailed Planning versus Implementation Roadmap.
4.3 IMPLEMENTATION TIPS
4.3. 1 DESIGN
You might be implementing a CMDB for a large enterprise that boast of hundreds
of business services and thousands of configuration items (CI), relationships and CI
attributes; or an organization with a handful of services, in any case, Do Not start
with a big bang approach.
Pick up a major business service as a pilot, spend the maximum time planning for
this service, implementing it, and noting down the lessons learned. Also, you must
map the chosen service on paper and include all relevant CI information to your
processes in scope.
4.3.2 PLAN
How deep you go into each CI is a major decision you need to make; this decision
will guide your vision for the foundation of the CMDB and related IT service Man-
agement processes in scope. Spend time analyzing how, where and when you would
need to dig out information on CIs that would potentially be helpful.
4.3.3 A UT O M A TE
Building a CMDB involves a big data collection exercise, consolidating, and review-
ing several documents from multiple sources. You should never assume the data to
be accurate, instead, plan to verify every bit of data you receive and identify other
sources who can verify the data for you. The only way to succeed in this task, is to
review all the solutions within your operations at your disposal, also if you have the
budget; consider investing in using discovery and service mapping toolsets.
HGCNOW.COM 77
4.4 C M D B SER V I C E N O W AD A P T A T I O N
One of the most important decisions you must take early on when building your
CMDB on ServiceNow is to decide whether to extend the CMDB and which data-
bases to use.
The configuration steps for enhancing the CMDB consists, but are not limited to the
following activities to be executed during this initiative:
Review and adapt ACL rules, Roles and groups assignments

Enable ServiceNow discovery
Adapt and consolidate forms, and lists
Adapt Data certification and auditing
Enable the appropriate plugins
Conduct knowledge transfer sessions and mentoring
Review and adapt the ServiceNow data model and structure
Review the business services CIs
Review implementation of CI Business Services
Review and adapt structure for CI Business Application
Document and adapt relationships between Security data & Business Application
Review relationships for Technology Dependencies associated to Business
Applications and existing business Services
Document a migration plan for current Business Services/Software records to
be used as Business Applications.
4.5 C M D B SER V I C E N O W PL U G I N S
Before you start configuring anything in ServiceNow , you will need to enable the
following plugins:
Architecture Compliance
Assessment Components
Change Management - Core
Change Management - Standard Change Catalog
Data Certification,
Desired State
Extended CMDB
Field Normalization
Integration - JDBC
Integration - Multiple Provider Single Sign-On Installer
Process Flow Formatter
78 HGCNOW.COM
4.6 CMDB IMPLEMENTATION PLAN
The work from the prior Stage will form the basis of the work for the next Stage. If
work from a prior Stage is revisited at a later Stage, this will result in a change to
the Project fee and schedule.
4.6. 1 S TA GE 1: P L A N I N G
During this Stage, the Client and project managers will:
Develop a Project management plan (the Project Management Plan) that

establishes the procedures to be employed for the ongoing management of
the Project and the communication plan to address the protocol for generating
and submitting status reports and conducting status meetings.
Assign tasks and develop the Project schedule using an agreed upon project tool.
Validate that prerequisites as identified in the Assumptions and Client Respon-
sibilities sections are accurate and complete.
Schedule kick-off meeting to introduce the team and Client team members
(collectively, the Project Team) and stakeholders, communicate the Project
scope and review the Project Management Plan and Project schedule.
Conduct technical kickoff meeting scheduled, and verify the Solution requirements
Defines the business drivers for the Solution and the high-level requirements;
and identifies in-scope versus out-of-scope requirements of the planned Solution
Defines the current as is state of the in-scope business processes; provides an
overview of the proposed Solution to be state; describes client (the actors) who
will play a role in the Solutiontheir responsibilities and interactions; and identi-
fies Solution use cases and maps them to the Solutions functional requirements
4.6.2 STAGE 2: DESIGN
During this Stage, we will work with the Client to establish the Solution design,
plus the high-level Solution test and integration plans and phasing for the imple-
mentation. The Project Team will:
Review current environments and integration components

Conduct workshop to define Solution architecture specifications, high-level test
plan for functional and non-functional requirements defined, and recommended
phasing for the implementation
Review integration requirements
Produce the Solution design document that contains the CMDB Blueprint model,
and includes the desired architecture
HGCNOW.COM 79
Summarize the Solution requirements and Solution design in an executive pre-
sentation in Microsoft PowerPoint format, and present this summary to Client
4.6.3 S TA G E 3 : A D A P T A T I O N
In this Stage, the Project Team will complete the Solution integration document and
configure the selected Solution components in a DEV environment as defined in the
Solution design and integration instructions.
Simultaneously, you will compile the Solution test plan with systematic instructions
to test each documented use case and non-functional requirement, and will review
the test plan with the Client.
Complete the Solution integration instructions containing a task-level implemen-

tation plan with installation and configuration instructions mapped to Solution
phases as described in the Solution design document
Configure selected components in dev environment and perform installation
and configuration testing
Compile the Solution test plan
Define validation plan
Validation of use cases & validation of quality attributes
4.6.4 S TA G E 4 : V A L I D A T I O N
During this stage, in the dev environment the Project Team, plus administrators,
operators and end users as agreed upon, will perform quality assurance by execut-
ing the tests defined and documented in the Solution test plan, and will document
the test results.
Finalize Solution test plan & Document test results

Perform use case tests and other testing defined in the Solution test plan and
review results
Refine component configurations for test results which do not materially reflect
the agreed upon outcome and re-execute the test
4.6.5 S TA G E 5 : D E P L O Y M E N T
In this Stage, the Project Team will implement an initial limited and controlled imple-
mentation within the production environment as defined in the Solution design &
integration instructions.
Prepare and verify the production environment

Upgrade and configure selected components in production environment and
perform adaptation and configuration testing
Configure selected integrations and perform integration testing
Execute use case tests defined in Solution test plan.
Update Project documentation as required with results of production deployment
Provide final Project documentation (the Solution Documents) to Client
80 HGCNOW.COM
4 . 7 D ATA L O A D I N G A C T I V I T I E S
The following are the detailed activities to execute per CI Grouping for each CI
Class in scope; this is a sample list of activities and must be adapted to your
organization.
4. 7 . 1 P R E P A R E D ATA
Identify CI Owners
Map each CI Class to Data Source(s)
Identify Integration Method
Assess Data Source(s)
Document Data Source solution(s) plugins
Create CSV/XLS/XML Data extraction(s)
Grant JDBC Read-Only access to current databases
Build SQL Statement(s) for Data Extraction
Create SOAP/Web Service script(s)
Provide and review Raw Data
Create Reconciliation Rules
Merge and Normalize Test Data
Document Technology/Process Gaps
Integrate with Automation Tool(s)
Update Template(s) and Mapping document(s)
4. 7 . 2 U P D A T E D A TA D I C T I O N A R Y
Map CI Tables
Map CI Attributes/Fields
Map CI Relationships
Identify Common attributes
Identify Mandatory attributes
Identify Data source for each attribute
Identify Data Ownership for each attribute
Provide Cleaned/Normalized Ready Data for Load
4. 7 . 3 L O A D D ATA
Create Import Map and Transform Map

Adapt Import scripts / Rules
Perform and validate Data Import
Remove Failed Data Import if applies
Input any additional data manually
HGCNOW.COM 81
4. 7 . 4 AD APT SO L U T I O N
Extend the CMDB tables

Adapt CI attributes and CI Relationship
Configure Choice List
Configure Fields and forms
Configure Lists and views
Create Roles
Create/Assign ACLs
Create UI Actions
Create Business Rules
Create Client Script and Workflows
4. 7 . 5 AD APT P R O C E S S
Identify CMDB Support Processes

Design Process Flow
Identify Actions for Key Process Steps
Identify Control Points for Each Process Step
Document CMDB integrations and configurations
4. 7 . 6 V A L I D A T E D ATA
Build VAT scenarios

Validate accuracy of the CMDB
Validate Security
82 HGCNOW.COM
CMDB DEFINITIONS
A significant goal of ITIL is to promote the use of a common language and termi-
nology to improve communication and understanding, for this reason the following
definitions are provided:
ASSET: Component of a business process. Assets can include people, accommoda-

tion, computer systems, networks, paper records, fax machines, etc.
AVAILABILITY: The ability of an IT service or component to perform its required

function at a stated instant or over a stated period. {Up or Down Time}
SERVICES: The deliverables of the IT Services organization as perceived by the

Customer; the services do not consist merely of making computer resources avail-
able for Customers to use.
STAKEHOLDERS: Any individual or group who has an interest or stake, in the IT

service organization.
CHANGE: The addition, modification or removal of approved, supported or hard-

ware baseline, network, software, application, environment, system, desktop build
or associated documentation.
CLASSIFICATION: Process of formally grouping Configuration Items by type, e.g.

software, hardware, documentation, environment, application. Process of formally
identifying Changes by type. Process of formally identifying incidents, problems
and known errors by origin, symptoms and cause.
CUSTOMER: Recipient of a service. Generally, the Customer has a responsibility for

the cost of a service, either directly, through charging, or indirectly through demon-
strable business need. In this context, a Customer could be a person on the street
banking customer or an internal business unit to which an IT service is provided.
CLIENT: Internal business client using an IT service.
CONFIGURATION BASELINE: Configuration of a product or system established at a

specific point in time, which captures both the structure and details of the product
or system, and enables that product or system to be rebuilt later.
CONFIGURATION CONTROL: Activities comprising the control of Changes to Con-

figuration Items after formally establishing its configuration documents. It includes
the evaluation, coordination, approval or rejection of Changes. The implementation of
Changes includes changes, deviations and waivers that impact on the configuration.
CONFIGURATION DOCUMENT: Documents that define requirements, system design,

build, production, and verification for a configuration item.
CONFIGURATION IDENTIFICATION: Activities that determine the product structure,

the selection of Configuration Items, and the documentation of the Configuration
Items physical and functional characteristics, including interfaces and subsequent
Changes. It includes the allocation of identification characters or numbers to the
HGCNOW.COM 83
Configuration Items and their documents. It also includes the unique number of
configuration control forms associated with Change and Problems.
CONFIGURATION ITEM (CI): Component of an IT infrastructure or an item, such

as a Request for Change, associated with an IT infrastructure which is (or is to be)
under the control of CFM. CIs may vary widely in complexity, size and type from
an entire system (including all hardware, software and documentation) to a single
module or a minor hardware component.
CMDB: A database that contains all relevant details of each CI and details of the
important relationships between CIs.
PLAN: Document setting out the organizational and procedures of a specific product,
project, system, support group or service.
CONFIGURATION STRUCTURE: A hierarchy of all the CIs that comprise a config-

uration.
ENVIRONMENT: A collection of hardware, software, network communications and

procedures that work together to provide a discrete type of computer service. There
may be one or more environments on a physical platform e.g. test, production.
An environment has unique features and characteristics that dictate how they are
administered in similar, yet diverse manners.
IMPACT ANALYSIS: the identification of critical business processes, and the potential
damage or loss that may be caused to the organization resulting from disruption
to those processes.
INVENTORY: Automated identification of the components of a device in a network

IT infrastructure. Inventory or auto discovery identifies what it is, where it is located,
who is using it, and how it has changed over time. Value is generally not known and
relationship information is restricted to containment hierarchies.
IT INFRASTRUCTURE: The sum of an organizations IT related hardware, software,

data telecommunication facilities, procedures and documentation.
IT SERVICE: A described set of facilities, IT and non-IT, supported by the IT service

provider that fulfils one or more needs of the Customer and that is perceived by
the Customer as a coherent whole.
LIFECYCLE: A series of states, connected by allowable transitions. The lifecycle rep-

resents an approval process for Configuration Items, Problem Reports and Change
documents.
84 HGCNOW.COM
T H E AU T H O R
HICHEM GUEMIRI
Hichem is a ServiceNow Certified Administrator, Implementation Specialist and

ServiceNow Certified Application Developer with over 15 years or experience imple-
menting IT Service Management and Operations Management solutions across
industries, especially the banking and insurance industry.
His technical expertise and capabilities cover a multitude of services: project life-
cycle, strategic planning, enterprise architectures, process integrations, applica-
tion development, and ServiceNow maintenance and support all supported by
@HGCNOW recognized IT management and governance practices. Built over the
years by delivering large scale enterprise engagements across North America, in
both private and public sector.
Hichem is the CEO at HGC Technologies Inc. @HGCNOW is a consulting firm special-
izing in the development of custom applications, integrations on the ServiceNow
platform, and delivering tailored business services; from the onset process and
architecture assessments to a practical drafted desired vision.

CEO CHIEF EXECUTIVE OFFICER
HICHEM@HGCNOW.COM
WWW.HGCNOW.COM
HGCNOW.COM 85
T H E C O L L A B O R AT O R S
NOEL NATHAN
Noels #1 brand is quality and his #1 skill is execution. A highly skilled, talented, driven
individual who thrives in bringing order to chaos!
Noel started his career in ITSM in 2005 after graduating from Torontos Humber
Institute of Technology and Advanced Learning where he obtained a Diploma with
Honors in Computer Engineering. Starting at the IT Service Desk, Noel has progressed
throughout his career specializing solely in ITSM from implementation (in several
countries across the world), to ISO20000 certification, all the way up to Program
Governance. He has over 10years in setting up ITSM programs for some of the most
reputable global companies in the world including start-ups.
His approach has transformed the IT departments of companies he has worked and
consulted for by providing advisory, strategies, and vision establishment, helping
senior management obtain the value they seek from an ITSM/ITBM program.
Noel also hold several ITIL credentials, is a certified ServiceNow system administrator,
and a graduate in Business Administration (BSc.) with a specialization in International
Business, from the prestigious University of London Royal Halloway College.

CXO CHIEF EXPERIENCE OFFICER
NOEL@HGCNOW.COM
WWW.HGCNOW.COM
P ATRICK LAROCHE
Patrick is a ServiceNow Certified Administrator. He has been designing and man-

aging ServiceNow for the past 2 years at a major Canadian retailer. He has previous
experiences in network management, database management and SAP, combined
with a high customer service delivery mindset. Patrick has joined HGC Technologies
as the COO, and helps manage and oversee all ServiceNow implementations and
project deliveries.
Patrick is the COO at HGC Technologies Inc., He is responsible for the day to day
operations including service delivery.

COO CHIEF OPERATIONS OFFICER
PATRICK@HGCNOW.COM
WWW.HGCNOW.COM
86 HGCNOW.COM
MA XIME CARRIER
Maxime is a ServiceNow Certified Administrator and a Certified ServiceNow Imple-

mentation Specialist with over 10 years as a Consultant implementing ITSM products.
He has been implementing, designing, scoping and delivering ServiceNow projects
for the past 5 years around North-America.
Maxime is the CIO at HGC Technologies Inc. He oversees both the development
teams and remote ServiceNow administrators. He is always optimistic but also
realistic towards new challenges and situations.
At HGC Inc. Maxime is responsible for:
Assessing current situations and architecting operational road-maps
Documenting CMDB designs and strategies
Implementing ServiceNow Discovery and service mapping
Architecting ServiceNow orchestrations
Implementing Event Management and correlation intelligence
Integrating operational monitoring products
Designing business and supporting services
Designing processes and automations capabilities

CIO CHIEF INFORMATION OFFICER
MAXIME@HGCNOW.COM
WWW.HGCNOW.COM
ALAIN LAPOINTE
Alain is a ServiceNow Certified System Administrator & Certified Implementation

Specialist. Alain has worked with different ITSM tools in the past until he feels in
love with the ServiceNow platform. He has a deep passion for technology, hiking
and traveling. The need to always be challenged pushes him every day to find new
ways to provide a better use of technology in managing business services.
HGCNOW.COM 87
X O L A N I N G W E N YA
Xolani, an IT process and governance aficionado, has extensive training and practical
experience in IT Service Management implementation and holds ITIL Expert and
TIPA Assessor Certifications.
Xolani has many years of experience in developing, implementing, assessing and

improving IT service management processes; with a focus on ensuring IT processes
reflect lean and agile principles, designed with just enough controls to effectively
and efficiently deliver services and value, but not constricting flow of work.
As a trainer, Xolani delivers some of the most energetic and engaging sessions with
compelling practical examples, and analogies to bring to life concepts that help
learners easily grasp new information .
He loves travelling, is an an avid book reader and soccer fan.
88 HGCNOW.COM
TABLE OF DIA GRAMS

FIGURE 1 SERVICENOW SHARED CMDB ARCHITECTURE ............................. 7
FIGURE 2 SERVICENOW APPLICATION CAPABILITIES ............................... 8
FIGURE 3 SERVICENOW CMDB ARCHITECTURE MODEL ........................... 9
FIGURE 4 CMDB BUSINESS DRIVERS................................................................ 10
FIGURE 5 CMDB BUSINESS DRIVERS ................................................................ 11
FIGURE 6 CMDB DESIGN BLUEPRINT STRUCTURE ........................................ 14
FIGURE 7 CMDB DESIGN STEPS ........................................................................ 15
FIGURE 8 CMDB DESIGN SCOPE + SPAN = ROADMAP .............................. 16
FIGURE 9 CMDB DESIGN FEDERATION ............................................................. 17
FIGURE 10 CMDB PREPARATION STEPS ........................................................... 18
FIGURE 11 PROJECT TEAM ................................................................................. 19
FIGURE 12 SACM TEAM ....................................................................................... 20
FIGURE 13 IT INFRASTRUCTURE MAP .............................................................. 22
FIGURE 14 CMDB BLUEPRINT MODEL .......................................................... 23
FIGURE 15 SACM PROCESS ROLES ...................................................................24
FIGURE 16 CMDB SCOPE & SPAN ............................................................................. 29
FIGURE 17 CMDB WORKSHOP TYPES ............................................................... 31
FIGURE 18 CMDB WORKSHOP DELIVRABLES.................................................. 32
FIGURE 19 SERVICE ARCHITECTURE LAYERS...................................................... 34
FIGURE 20 SERVICE MAP VS. SERVICE OFFERINGS ................................. 35
FIGURE 21 INCIDENT MANAGEMENT WITHOUT CMDB .................................. 36
FIGURE 22 INCIDENT MANAGEMENT WITHOUT CMDB .............................. 37
FIGURE 23 CI CATEGORIES ........................................................................... 39
FIGURE 24 REFERENCE DATA .......................................................................................... 39
FIGURE 25 SERVICENOW REFERENCE DATA ARCHITECTURE .......... 40
FIGURE 26 CI CATEGORY BUSINESS SERVICES ...................................... 40
HGCNOW.COM 89
FIGURE 27 CI CATEGORY APPLICATIONS ................................................. 41
FIGURE 28 EXAMPLE APPLICATION CI TYPE ............................................. 43
FIGURE 29 CI CATEGORY - DATABASES ......................................................... 43
FIGURE 30 CI CATEGORY SERVER COMPUTING ..................................... 44
FIGURE 31 CI CATEGORY INFRASTRUCTURE COMPUTING .................... 45
FIGURE 32 CI CATEGORY STORAGE ............................................................ 46
FIGURE 33 CI CATEGORY BACKUP ............................................................. 47
FIGURE 34 CI CATEGORY END-USER COMPUTING ................................. 48
FIGURE 35 COMMON MANDATORY ATTRIBUTES ...................................... 50
FIGURE 36 COMMON OPTIONAL ATTRIBUTES ............................................... 51
FIGURE 37 CMDB TABLES BUSINESS SERVICE ........................................... 58
FIGURE 38 CMDB TABLES SERVER COMPUTING .................................... 58
FIGURE 39 CMDB TABLES - NETWORK ..................................................... 59
FIGURE 40 CMDB TABLES DATA CENTER ................................................ 59
FIGURE 41 SERVICE MAPPING ........................................................................... 63
FIGURE 42 MANUAL SERVICE MAPPING ON PAPER ................................... 64
FIGURE 43 CI RELATIONSHIPS ..................................................................... 65
FIGURE 44 CI RELATIONSHIPS REFERENCE DATA ...........................................66
FIGURE 45 CMDB MODEL CI APPLICATION RELATIONS ......................... 67
FIGURE 46 CMDB MODEL CI DATABASE RELATIONS ............................. 68
FIGURE 47 CMDB MODEL CI SERVER RELATIONS .................................. 69
FIGURE 48 CMDB MODEL CI DATA CENTER RELATIONS ....................... 69
FIGURE 49 CMDB MODEL CI NETWORK RELATIONS ............................. 70
FIGURE 50 CMDB MODEL CI STORAGE RELATIONS ............................... 70
FIGURE 51 DATA LOADING APPROACH BY CI TYPE .................................... 74
FIGURE 52 DATA LOADING APPROACH BY PROCESS WAVE.........................75
90 HGCNOW.COM
Register on our site, or email us to get
your complimentary download: all diagrams found
in this book + get this book in pdf format
Email us at
CMDB@HGCNOW.COM
Hichem Guemiri
HGCNOW.COM 91
NO TES
Visit our website
WWW.HGCNOW.COM

HGC Servicenow Cmdb101

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

HGC Servicenow Cmdb101

Transféré par

Droits d'auteur :

Formats disponibles

HICHEM GUEMIRI NOEL NATHAN MAXIME CARRIER

PATRICK LAROCHE ALAIN LAPOINTE XOLANI NGWENYA

HGC TECHNOLOGIES INC.

All rights reserved @HGCNOW

WHY WE WROTE THIS BOOK? ..................................................................... 6

1. HOW TO PLAN YOUR CMDB ............................................................................ 7

2. DESIGN YOUR CMDB ..................................................................................... 29

3. CONFIGURE YOUR CMDB ............................................................................. 57

4. CONSTRUCT YOUR CMDB ............................................................................ 72

CMDB DEFINITIONS ..................................................................................... 84

THE AUTHOR ...................................................................................................... 86

THE COLLABORATORS .......................................................................................... 87

TABLE OF DIAGRAMS ................................................................................. 90

As a reputable ServiceNow Partner based in Montreal, Quebec, we have over 15 years

Our service offerings provide the following benefits to our clients:

PROVEN: experienced and highly trained team.

INNOVATIVE: committed to continually develop and improve the services offered

MINIMIZE manual data entries and maintenance -- promote automation when-

ACCOMODATE the right adaptations and customizations based on lessons

MAXIMIZE design simplicity in ServiceNow , establish data ownerships, and

ALLOW for an easy path to upgrades by documenting all configuration, devel-

Service Asset Management and Configuration Management, collectively referred

The simple key to a successful CMDB implementation is to bring together people,

ServiceNow System Administrators

ServiceNow Implementation specialists

CMDB Process Owners

HO W T O PLAN Y OUR CMDB

FIGURE 1 SERVICENOW SHARED CMDB ARCHITECTURE

Configuration Management Database (CMDB) is a system, a database schema that

When information regarding the elements is provided by multiple sources, a feder-

FIGURE 2 SERVICENOW APPLICATION CAPABILITIES

FIGURE 3 SERVICENOW CMDB ARCHITECTURE MODEL

Reduce risks, contribute to contingency planning and improve the ability of

Enable effective scheduling of changes through improved awareness of service

Improve the effectiveness of all Service Management processes.

Track, manage and control valuable CI information.

Facilitate adherence to legal obligations.

Facilitate Demand and Capacity management.

FIGURE 4 CMDB BUSINESS DRIVERS

FIGURE 5 CMDB BUSINESS DRIVERS

Our recommended approach involves practical steps and a phased implementation

Most often the primary use of a CMDB is to facilitate incident management by

Incident Management enable quick Incident resolution by providing information

Change Management assist in risk management by displaying the connected

Based on your mission statement, an implementation roadmap should be devel-

Develop and populate a CMDB to support the implementation of a future ITSM

Provide a complete list of infrastructure CIs that support a business service,

Improve the rate of successful changes by offering necessary information to

Provide data that enables IT organizations to write and meet comprehensive

Enable low-risk infrastructure upgrades and changes, increase security and

1.3.2 SET Y OUR P R O C E S S GO V E R N A N C E

In most cases, it is common for organizations to begin with Inventory Management

INVENTORY MANAGEMENT - deals with the physical inventory.

ASSET MANGEMENT - extends inventory management to include financial

CONFIGURATION MANAGEMENT - further extends the two above to include

IDENTIFY the configuration structures for all the infrastructure configuration

A CMDB integrates information from many sources including:

Incident, problem, change and release records

Known error and knowledge management records

Application and infrastructure records

Assignment groups, service level agreements (SLAs), operating level agreements

Corporate data about employees, suppliers, business units, and customers

Measurement and reporting metrics