BMC Atrium Core 7.6.03 Concepts and Planning Guide

BMC Atrium Core 7.6.
03
Concepts and Planning Guide
August 2010
www.bmc.com
Contacting BMC Software

You can access the BMC Software website at http://www.bmc.com. From this website, you can obtain information
about the company, its products, corporate offices, special events, and career opportunities.
United States and Canada

Address
BMC SOFTWARE INC

2101 CITYWEST BLVD
HOUSTON TX 77042-2827
USA
Telephone
713 918 8800 or

800 841 2031
Fax
(01) 713 918 8000
Fax
713 918 8000
Outside United States and Canada

Telephone
(01) 713 918 8800
If you have comments or suggestions about this documentation, contact Information Development by email at
doc_feedback@bmc.com.
Copyright 2009-2010 BMC Software, Inc.

BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent
and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and
logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the
property of their respective owners.
DB2 and IBM are trademarks or registered trademarks of International Business Machines Corporation in the United States, other
countries, or both.
IT Infrastructure Library is a registered trademark of the Office of Government Commerce and is used here by BMC Software, Inc., under
license from and with the permission of OGC.
ITIL is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the
U.S. Patent and Trademark Office, and is used here by BMC Software, Inc., under license from and with the permission of OGC.
Oracle is a registered trademark of Oracle Corporation.
UNIX is a registered trademark of The Open Group.
Java, Javadoc, JDBC, and Sun are trademarks of Sun Microsystems, Inc., in the U.S. and other countries.
BMC Software considers information included in this documentation to be proprietary and confidential. Your use of this information is
subject to the terms and conditions of the applicable End User License Agreement for the product and the proprietary and restricted
rights notices included in this documentation.
Restricted Rights Legend

U.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF
THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject to
restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS 252.227-7014, DFARS 252.227-7015, and
DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is BMC Software, Inc., 2101 CityWest Blvd., Houston, TX
77042-2827, USA. Any contract notices should be sent to this address.
Customer Support
You can obtain technical support by using the Support page on the BMC Software website or by contacting Customer
Support by telephone or email. To expedite your inquiry, please see Before Contacting BMC Software.
Support website
You can obtain technical support from BMC Software 24 hours a day, 7 days a week at
http://www.bmc.com/support. From this website, you can:
Read overviews about support services and programs that BMC Software offers.
Find the most current information about BMC Software products.
Search a database for problems similar to yours and possible solutions.
Order or download product documentation.
Report a problem or ask a question.
Subscribe to receive email notices when new product versions are released.
Find worldwide BMC Software support center locations and contact information, including email addresses, fax
numbers, and telephone numbers.
Support by telephone or email

In the United States and Canada, if you need technical support and do not have access to the Web, call 800 537 1813 or
send an email message to customer_support@bmc.com. (In the Subject line, enter
SupID:yourSupportContractID, such as SupID:12345.) Outside the United States and Canada, contact your
local support center for assistance.
Before contacting BMC Software

Have the following information available so that Customer Support can begin working on your issue immediately:
Product information
Product name
Product version (release number)
License number and password (trial or permanent)
Operating system and environment information
Machine type
Operating system type, version, and service pack
System hardware configuration
Serial numbers
Related software (database, application, and communication) including type, version, and service pack or
maintenance level
Sequence of events leading to the problem
Commands and options that you used
Messages received (and the time and date that you received them)
Product error messages
Messages from the operating system, such as file system full
Messages from related software
License key and password information

If you have a question about your license key or password, contact Customer Support through one of the following
methods:
E-mail customer_support@bmc.com. (In the Subject line, enter SupID:yourSupportContractID, such

as SupID:12345.)
In the United States and Canada, call 800 537 1813. Outside the United States and Canada, contact your local support
center for assistance.
Submit a new issue at http://www.bmc.com/support.
Contents
About this book
11
How to use this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Prerequisite documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
BMC Atrium Core documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Chapter 1
About BMC Atrium Core
17
Overview of Business Service Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Value proposition of BMC Atrium Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The business challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BMC Atrium Core Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BMC Atrium Core components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The BMC Atrium CMDB component of BMC Atrium Core . . . . . . . . . . . . . . . . . .
The BMC Atrium Integration Engine component of BMC Atrium Core . . . . . . .
BMC Atrium Core architecture and features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BMC Atrium Core architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Open access to data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Web services and service oriented architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User access to BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overview of virtualization management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Architecture of the CMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The CMDB layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The CMS Data layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CMS Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BMC Remedy AR System foundation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BMC Remedy AR System architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Benefits of using BMC Remedy AR System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ITIL and SACM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Purpose of SACM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Goals of SACM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Benefits of SACM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data is the key to SACM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Control of the Configuration Management process. . . . . . . . . . . . . . . . . . . . . . . . .
Calbro Services user story. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Calbro Services company background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Implementation of BMC Atrium Core at Calbro Services. . . . . . . . . . . . . . . . . . . .
Contents
18
19
19
19
20
20
24
25
25
26
27
27
28
28
28
29
30
30
31
32
32
33
33
34
34
34
36
36
37
37
38
Chapter 2
Planning a CMDB
39
CMDB planning stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Stage 1: Assembling the project team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Stage 2: Defining requirements and creating IT service model blueprint . . . . . . . 40
Stage 3: Selecting CMDB solution and tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Stage 4: Constructing and maintaining your CMDB . . . . . . . . . . . . . . . . . . . . . . . . 41
Stage 5: Driving ongoing value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Phased implementation of a CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Challenges, critical success factors, and risks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Critical success factors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Chapter 3
Planning the data model
45
Data model overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Data model classes and attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Data model extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Attribute inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Relationships in the data model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
BMC Atrium CMDB data storage methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Synchronization of changes to classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Overview of the Common Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Configuration item classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Relationship classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Federated data classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Detailed relationship categorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Sample data models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Planning to extend the data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
How federation extends the data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
How the Category, Type, and Item attributes extend the data model. . . . . . . . . . 60
How additional attributes extend the data model . . . . . . . . . . . . . . . . . . . . . . . . . . 60
How additional subclasses extend the data model. . . . . . . . . . . . . . . . . . . . . . . . . . 61
How Calbro Services extended the data model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Naming and numbering rules for new classes and attributes. . . . . . . . . . . . . . . . . 64
Making data model changes visible to applications . . . . . . . . . . . . . . . . . . . . . . . . . 64
Documenting data model extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Chapter 4
Planning BMC Atrium CMDB data
67
What data goes into an ITIL CMDB? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Configuration items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Relationships among CIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Data related to CIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning to populate BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mapping CIs to the data model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mapping CIs to discovery data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assessing the configuration data source environment . . . . . . . . . . . . . . . . . . . . . .
Managing unqualified data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Grouping CIs into datasets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Identifying the discovery schedule sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Planning to use federated data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
When to use federated data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How Calbro Services uses federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Federation methods in BMC Atrium CMDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Controlling access to data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Overview of multitenancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BMC Atrium CMDB multitenancy permission model . . . . . . . . . . . . . . . . . . . . . .
Calbro Services access implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sizing considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Replicating BMC Atrium CMDB data to other servers . . . . . . . . . . . . . . . . . . . . . . . . .
68
68
70
71
72
72
72
75
75
77
81
82
83
84
84
89
89
90
90
92
92
Chapter 5
93
Planning data normalization and the Product Catalog
Overview of normalization and the Product Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Normalization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Product Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Entries in the Product Catalog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Components of the Product Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Categorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Multitenancy with the Product Catalog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
How Calbro Services planned normalization and Product Catalog implementation 98
Chapter 6
Planning data reconciliation
99
Identifying instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comparing datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Merging datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using a single Merge activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using independent Merge activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Other reconciliation activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Combining activities as a job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Qualification groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
100
101
101
102
103
105
105
106
Chapter 7
Planning a service model
107
Service model overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Relationships between service components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Adding CIs and relationships to service models using BMC Atrium CMDB . . 109
Designing a service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Defining business goals for the service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Decomposing a business service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Defining the service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Chapter 8
Implementing BMC Atrium Core
117
Overview of the process to implement BMC Atrium Core . . . . . . . . . . . . . . . . . . . . . 118

Configuring permissions and multitenancy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Configuring roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Configuring class and attribute permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Configuring instance permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Configuring multitenancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Configuring the Product Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Creating Product Catalog entries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Configuring best-practice categorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Approving products, versions, and patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Configuring the data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Creating datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Configuring BMC Atrium Integration Engine for data import . . . . . . . . . . . . . . . . . . 127
Populating database field menus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Creating data mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Creating data exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Configuring normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Configuring reconciliation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Creating the service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Using BMC Impact Solutions to create a service model. . . . . . . . . . . . . . . . . . . . . 133
Deciding on the structure of the service model. . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Maintain your service model dynamically. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Importing data to BMC Atrium CMDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Creating test cases to validate data population . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Bringing data into BMC Atrium CMDB using discovery tools. . . . . . . . . . . . . . . 136
Importing data using BMC Atrium Integration Engine. . . . . . . . . . . . . . . . . . . . . 137
Adding data manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Validating data import results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Removing failed-import data from BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . 138
Normalizing BMC Atrium CMDB data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
Reconciling BMC Atrium CMDB data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
How Calbro Services discovers their IT environment and imports data . . . . . . 139
Best practices for specific implementation scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Best practice for scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Best practices for bulk loads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Best practices for incremental loads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Best practices for Atrium Explorer edits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Best practices for BMC Remedy ITSM manual edits . . . . . . . . . . . . . . . . . . . . . . . 143
Chapter 9
Managing BMC Atrium Core
145
Tracking changes to CIs and relationships. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Auditing versus the Compare Dataset activity. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Types of auditing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Selecting which instances and attributes are included in an audit . . . . . . . . . . .
Receiving CI change events with Event Channels . . . . . . . . . . . . . . . . . . . . . . . . .
Deleting CIs that are no longer discovered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Custom workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Calbro Services custom workflow for viewing unreconciled CIs . . . . . . . . . . . .
Filter execution order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
146
146
147
150
152
155
155
155
156
Glossary
157
Index
167
Contents
10
About this book

The BMC Atrium Core 7.6.03 Concepts and Planning Guide describes the concepts
underlying BMC Atrium Core products, including the BMC Atrium Configuration
Management Database (CMDB), BMC Atrium Product Catalog, and the BMC
Atrium Integration Engine applications. This guide also provides planning and
best practices information for these applications. You can use this to establish a
Service Asset and Configuration Management process and to use BMC Atrium
CMDB to manage data about your IT environment.
How to use this guide

This guide is organized to help you implement BMC Atrium Core. Information
presented early in the guide helps you with the concepts and tasks that follow.
Type of information
Chapters
Overview of Business Service

Management (BSM) and the BMC
Atrium Core solution
Chapter 1, About BMC Atrium Core
Concepts and information necessary Chapter 2, Planning a CMDB

for planning to implement BMC
Chapter 3, Planning the data model
Atrium Core
Chapter 4, Planning BMC Atrium CMDB data
Chapter 5, Planning data normalization and the
Product Catalog
Chapter 6, Planning data reconciliation
Chapter 7, Planning a service model
The end-to-end tasks necessary to
implement and maintain BMC
Atrium Core
Chapter 8, Implementing BMC Atrium Core

Chapter 9, Managing BMC Atrium Core
About this book
11
BMC Atrium Core 7.6.03
Prerequisite documentation
Before planning your CMDB, read the Step-by-Step Guide to Building a CMDB,
published by BMC Software. Organized into stages, this guide provides practical
guidance for structuring a CMDB project and delivering a comprehensive and
useful CMDB. The stages are divided into steps, each with objectives that help you
meet the milestone for that stage. You can request this book from http://
www.bmc.com.
Also consider taking BMC Educational Services companion course ITIL V3:
Practical Steps to Building a CMDB, which shows how to build a CMDB based on
best practices from the IT Infrastructure Library (ITIL) Version 3.
BMC Atrium Core documentation

This section describes the complete set of BMC Atrium Core documentation,
including manuals, help systems, videos, and so on.
Unless otherwise noted, documentation is available on the BMC Atrium Core
documentation media (DVD or Electronic Product Download bundle) and on the
BMC Customer Support site, free of charge, at http://www.bmc.com/support.
To find this documentation on the BMC Customer Support site, choose Product
Documentation > Supported Product A-Z List > BMC Atrium CMDB Enterprise
Manager > 7.6.03.
Title
Description
Audience
BMC Atrium CMDB 7.6.03 Information about setting permissions, configuring Configuration managers,
Administrator's Guide
federation, modifying the data model, configuring application administrators,
an impact model, and other administrative tasks in and asset analysts.
BMC Atrium CMDB.
BMC Atrium CMDB 7.6.03 Hierarchical diagram of all classes in the Common Configuration managers,
Common Data Model
Data Model (CDM) including unique attributes and application administrators,
Diagram
applicable relationships.
and asset analysts.
BMC Atrium CMDB
7.6.03 Data Model Help
Description and details of superclasses, subclasses,

attributes, and relationship classes for each class.
Contains only information about the CDM at first,
but you can update it to include information about
data model extensions that you install.
Configuration managers,
application administrators,
and asset analysts.
Note: This Help is provided in HTML and is available
on the BMC Atrium Core media. It is not available

on the BMC Customer Support site.
BMC Atrium CMDB 7.6.03 Best practices for using the classes that BMC
Data Modeling Guide
provides for BMC Atrium CMDB (both the CDM
and extensions) to model complex business entities, and asset analysts.
focusing on the use of multiple related CIs to model
an entity rather than on general information about a
class or attribute.
12
Title
Description
Audience
BMC Atrium CMDB 7.6.03 Information about normalizing data in BMC Atrium Configuration managers,
Normalization and
CMDB and reconciling CIs from different data
providers into a single production dataset.
and asset analysts.
Reconciliation Guide
BMC Atrium CMDB
7.6.03 Online Help
Help for using and configuring BMC Atrium CMDB,

including BMC Atrium Product Catalog,
Reconciliation Engine, Normalization Engine, and
so on.
asset analysts, and users
that work with CIs and need
to understand the
relationships that exist
through the Help links in the BMC Atrium CMDB
within BMC Atrium CMDB.
user interface. It is not available on the BMC
Customer Support site.
BMC Atrium CMDB 7.6.03 Information about using BMC Atrium CMDB,
User's Guide
including searching for and comparing CIs and
relationships, relating CIs, viewing history, running
impact simulations, and viewing federated data.
Users that work with CIs

and need to understand the
relationships that exist
within BMC Atrium CMDB.

Compatibility Matrix
and asset analysts.
Information about the BMC Atrium Core

configurations that are expected to work properly
based on design, testing, or general understanding
of the interaction between products.
Note: Download the BMC Atrium Core 7.6.03
Compatibility Matrix from the BMC Customer

Support site at http://www.bmc.com/
support/reg/remedy-compatibilitytables.html?c=n.
Concepts and Planning
Guide
Information about CMDB concepts and high-level

steps for planning and implementing BMC Atrium
Core.
Anyone who wants to learn

about and understand BMC
Atrium Core products,
CMDBs in general, and the
functionality of BMC
Atrium CMDB in particular.
IT leaders, configuration
managers, application
administrators, and asset
analysts are some who will
benefit from this
information.

Information about creating API programs using C
Developers Reference Guide API functions and data structures.
Application administrators
and programmers.

Installation Guide
Information about installing, upgrading, and

uninstalling BMC Atrium Core features.
Application administrators.
BMC Atrium CMDB

7.6.03 Javadoc Help
Information about Sun Java classes, methods,

and variables that integrate with BMC Atrium
CMDB.
Application programmers.

About this book
13
Title
Description
Audience

Master Index
Combined index of all guides.
Everyone.

Product Catalog and DML
Guide
Information about configuring the Product Catalog System administrators, IT

and DML, adding products, and creating aliases for managers, network
products, manufacturers, and categorizations.
managers, and other
qualified personnel who are
familiar with their
computing and networking
environment.

Release Notes
Information about new features, known issues, and Everyone.

other late-breaking topics.
BMC Atrium Core 7.6.03:

Taking Your Data Into
Production End to End
End-to-end high-level steps for bringing data into

BMC Atrium CMDB from a third-party source and
making it available in your production dataset.
and asset analysts.
Note: This Flash video is available on the BMC
Atrium Core media. It is not available on the BMC

Customer Support site.
Troubleshooting Guide
Information about resolving issues with BMC

Application administrators,
Atrium Core components, including API, filter, and programmers, and BMC
console error messages and their solutions.
Support personnel.

Web Services Help
Application administrators
Information about using BMC Atrium Core Web
and programmers.
Services, including how to publish and find
interfaces in the Web Services Registry, set versions,
disambiguate web services, configure security
policies and encryption, and use BMC Atrium Core
Web Services data structures and operations.

BMC Atrium Integration
Engine 7.6.03 ADK
Developer's Guide
Information about how to build adapters that can

transfer information between an external data store
and either BMC Remedy AR System forms or BMC
Atrium CMDB.
BMC Atrium Integration Help for using and configuring BMC Atrium
Engine 7.6.03 Online Help Integration Engine.
Developers who have a

basic understanding of BMC
Atrium Integration Engine
and want to build adapters
that can exchange data
between two data sources.
Users who are responsible

for setting up data transfer
integrations between
external data stores and
through the Help links in the BMC Atrium
either BMC Atrium CMDB
Integration Engine user interface. It is not
or BMC Remedy
available on the BMC Customer Support site.
AR System.
14
Title
Description
Audience
BMC Atrium Integration

Information about creating data exchanges and data
Engine 7.6.03 User's Guide mappings, defining rules and queries, activating
event-driven data exchanges, defining connection
settings, and other BMC Atrium Integration Engine
concepts.
Users who are responsible

for setting up data transfer
integrations between
external data stores and
either BMC Atrium CMDB
or BMC Remedy
AR System.
Mapping Your Data to

Spreadsheet that maps common IT objects to the
BMC Atrium CMDB 7.6.03 appropriate class, whether part of the CDM or an
Classes
extension. This spreadsheet also includes
information about further categorizing instances
using key attributes, and best practices for creating
normalized relationships.
and asset analysts.
About this book
15
16
Chapter
About BMC Atrium Core
This section introduces and describes the components of BMC Atrium Core,
including BMC Atrium CMDB.
The following topics are provided:

Overview of Business Service Management (page 18)

Value proposition of BMC Atrium Core (page 19)
BMC Atrium Core components (page 20)
BMC Atrium Core architecture and features (page 25)
Architecture of the CMS (page 29)
BMC Remedy AR System foundation (page 32)
ITIL and SACM (page 33)
Calbro Services user story (page 37)
Chapter 1 About BMC Atrium Core
17
Overview of Business Service Management

Business Service Management (BSM) is a comprehensive approach and unified
platform for running IT. BSM offers a way to bring together many disparate
processes and tools to create quantifiable improvement in efficiency and the ability
to view technology as it applies to business process.
BSM enables your IT department to:
Operate by service rather than by individual configuration items or technology.

Prioritize your efforts, improving the service that you deliver to your business.
Understand and predict how technology impacts your business and how your
business impacts the IT infrastructure.
BMC Software delivers a BSM solution according to the key functions of an IT
organization, as shown in Figure 1-1:
Figure 1-1: BSM overview
18
Value proposition of BMC Atrium Core
Request and supportsimplify and automate processes for requesting,

changing, and supporting business services.
Provision and configuredeploy business services consistently for

applications, servers, networks, and clients.
Monitor and operateidentify and resolve IT issues for cloud, virtual,

distributed, and mainframe environments. Automate repetitive, manual tasks
to eliminate errors and get things done more quickly.
Plan and governmanage your IT supply, demand, and budget. Ensure

compliance with policies and regulations.
At the center of the BMC Software BSM solution is BMC Atrium Core, which
unifies data and processes from your IT management tools, improving the
efficiency of your IT organization.
Value proposition of BMC Atrium Core

BMC Atrium Core, with other BMC Atrium solutions, forms the platform for
realizing the BSM vision. As such, BMC Atrium Core facilitates the alignment of IT
with the business.
The business challenge

ITIL standardizes the processes that IT departments use to manage IT hardware
and software, such as Problem Management, Incident Management, and Change
Management. These standard processes ensure the availability of the critical IT
services that sustain a business, like banking systems, ordering systems, and
manufacturing systems. Additionally, ITIL Service Asset and Configuration
Management (SACM) needs reliable data about components in the IT environment
and needs to understand the impact to key business services when changes occur
in that environment. For a large company, maintaining and managing information
about thousands of pieces of hardware and software is difficult. Central to these
ITIL processes is the configuration management database (CMDB). The data in the
CMDB feeds the applications that perform ITIL processes.
BMC Atrium Core Solution

BMC Atrium Core provides a CMDB coupled with common user, programmatic,
and reporting interfaces to accelerate attainment of BSM. This set of enabling
technologies provides tighter integration across management tools used in your IT
environment, saving your IT organization time and money.
19
BMC Atrium Core components

This section provides an overview of the following components that compose
BMC Atrium Core:
BMC Atrium CMDB, including the following components:

Normalization Engine
Reconciliation Engine
Atrium Explorer
Atrium Impact Simulator
Common Data Model
Class Manager
Product Catalog and Definitive Media Library
Service Catalog
BMC Atrium Integration Engine
The BMC Atrium CMDB component of BMC Atrium Core

BMC Atrium CMDB stores information about the configuration items (CIs) in your
IT environment and the relationships between them. For a detailed definition of
configuration items, see Configuration items on page 68.
Data providers, such as discovery applications, put data into BMC Atrium CMDB,
where it is partitioned into separate datasets. This data is then brought together
into a consolidated production dataset that you use as the single source of
reference for your IT environment.
Consuming applications, such as BMC Remedy IT Service Management (BMC
Remedy ITSM), BMC Remedy Asset Management, BMC Remedy Service Level
Management, applications represented in Figure 1-1 on page 18, and more, use the
data in the production dataset.
The Normalization Engine component of BMC Atrium

CMDB
The Normalization Engine is a policy enforcement engine installed with BMC
Atrium CMDB. It enables you to centrally define data policies and automatically
enforce them throughout BMC Atrium CMDB. Data from any source is subject to
policy enforcement. This consistency in BMC Atrium CMDB data enables
consuming applications to make good decisions. For example, BMC Remedy Asset
Management can report on software license usage appropriately. In conjunction
with the Product Catalog, the Normalization Engine provides a centralized and
customizable means to normalize the following types of data:
20
Product categorizationsReplaces the values of Category, Type, and Item and

manufacturer data such as ManufacturerName, Model, and VersionNumber
with correct values from the Product Catalog.
ImpactSets the impact attributes on relationship instances based on rules.

Relation NameFor relationships, replaces the existing Name value with the
BMC-recommended name based on the CI classes in the relationship.
Row-level securitySets the row-level and attribute-level permissions on CIs as

you define them.
Version Rollup featureSets the MarketVersion attribute for instances to a

common value based on default or custom rules. This provides more accurate
information for managing licenses.
Suite Rollup featureAllows you to define suites and their products and to
identify instances as a suite, a suite component, or a standalone application. This
allows more accurate management of suite and individual licenses.
With the Normalization Engine, you can define what is normalized and when. You
can select the BMC Atrium CMDB classes to normalize and the attributes for each
class. You can also choose which datasets are normalized. For more information
about normalization, see the BMC Atrium CMDB 7.6.03 Normalization and
Reconciliation Guide.
The Reconciliation Engine component of BMC Atrium

CMDB
The Reconciliation Engine is installed with BMC Atrium CMDB. The main goal of
the Reconciliation Engine is the creation of a production dataset that contains
accurate data from all available sources. Data in the production dataset can be used
by consuming applications. The following Reconciliation Engine activities work in
direct support of this goal:
Identifying class instances that are the same entity in two or more datasets
Merging datasets
Additionally, the Reconciliation Engine has default reconciliation rules that
simplify the creation of reconciliation jobs and a continuous or near real-time
reconciliation mode to support dynamic changes in your environment. The
Reconciliation Engine provides other functionality with the following activities:
Comparing class instances in two or more datasets

Copying instances from one dataset to another
Deleting instances from one or more datasets
Purging instances that are marked as deleted from one or more datasets
Renaming datasets
For more information about reconciliation, see the BMC Atrium CMDB 7.6.03
Normalization and Reconciliation Guide.
21
The Atrium Explorer component of BMC Atrium CMDB

Atrium Explorer is the BMC Atrium CMDB data visualization tool that enables
you to create and edit service models graphically in BMC Atrium CMDB. It also
enables you to see and manage CIs and relationships. Atrium Explorer provides
the central launch point for federated and related CI information.
All instances visible in the display pane are represented in a view. You can have
several views open at once, though only one at a time is displayed.Atrium Explorer
can be embedded and launched in context from any application.
In the Atrium Explorer, each CI is represented by an icon that indicates the class of
that instance. You can quickly create a CI by dragging an icon into a view. When a
CI is related to other CIs, arrows connect its icon to theirs to represent the
relationships. When you right-click an icon, you can choose to either expand
(show) or collapse (hide) related CIs.
For more information about using Atrium Explorer, see the BMC Atrium CMDB
7.6.03 User's Guide.
The Atrium Impact Simulator component of BMC Atrium

CMDB
It is difficult to predict the potential impact of planned or unplanned changes to
business services or other critical resources. This process frequently relies on
manual research results to arrive at a best-guess impact assessment for
determining the risk that a change might have on business services. With this
manual method, testing the resiliency of service models or a single point of failure
for service models is difficult.
The Atrium Impact Simulator application can make this easier, enabling you to
determine the impact of a change to the availability of a CI on other CIs. The same
impact data is also used by the BMC Service Impact Manager (SIM) product to
perform real-time analysis of impact when events are received about real outages
in your environment.
For example, you could run a simulation in Atrium Impact Simulator to learn what
devices and applications in the network would be affected if you were to take a
server offline. You might also use Atrium Impact Simulator to plan for disaster
recovery. You can run simulations to determine where the network is weakest, and
plan accordingly. For more information about using Atrium Impact Simulator, see
the BMC Atrium CMDB 7.6.03 User's Guide.
The Common Data Model component of BMC Atrium

CMDB
You have many different types of CIs, from computer systems to network
hardware to software servers. Without a data model that accurately reflects these
types and the types of relationships that can exist between them, your CMDB
could store attributes that do not pertain to their CIs, leave out necessary
attributes, and make it harder to search for groups of CIs.
22
The BMC Atrium CMDB data model is object oriented, which means that it has a
hierarchical set of classes in which each class inherits attributes from its
superclassthe class above it in the hierarchyand then adds its own attributes to
create a more specific type of object, a subclass. The benefits of an object-oriented
data model include enforcement of common attributes among similar types of CIs
and the ability to search within not just a given class of CIs, but within any branch
of the hierarchy. From a base class from which all others are derived, you can
search for all CIs or all relationships.
The BMC Atrium CMDB data model is also extensible. Your infrastructure, and the
technology that comprises it, is constantly changing. That means the types of CIs
and relationships in your CMDB must also change, so you need a data model that
is extensible. You can add attributes to your classes, and even add classes.
Subclasses can have their own subclasses, extending the hierarchy to the level of
detail that you want to track.
The Common Data Model (CDM) is the set of CI and relationship classes that ships
with BMC Atrium CMDB. These classes are complete enough to model nearly
everything in your IT environments. All classes in the CDM reside in the BMC.CORE
namespace.
For consistency with industry standards developed to track and manage this type
of information, the CDM is based on the Common Information Model (CIM) from
the Distributed Management Task Force (DMTF) and Microsoft Windows
Management Instrumentation (WMI). The CDM adopted much of the basic design
of the CIM and WMI without detailing the internal workings of systems. For a
graphic of the CDM, see the BMC Atrium CMDB 7.6.03 Common Data Model
Diagram.
Best practices for modeling your environment in the CDM are available in the BMC
Atrium CMDB 7.6.03 Data Modeling Guide and BMC Atrium CMDB 7.6.03 Data
Model Help.
The Class Manager component of BMC Atrium CMDB

The Class Manager application enables you to manage the core of the data model.
You can view, modify, create, and delete CI and relationship classes and their
attributes. With the Class Manager, you can graphically extend and customize the
BMC Atrium CMDB data model. Also, it includes built-in best practices for using
the class data model. For more information about the Class Manager application,
see the BMC Atrium CMDB 7.6.03 Administrator's Guide.
The BMC Atrium Product Catalog and Definitive Media

Library components of BMC Atrium CMDB
The BMC Atrium Product Catalog provides a normalized reference of software,
hardware, and other types of products and their characteristics that enhance the
accuracy of BMC Discovery products by uniquely identifying a product regardless
of its installed name or location.
23
Any application (BMC or non-BMC) can use the Product Catalog to identify a
single name for a software application and its versions, which in turn supports
license compliance and provisioning. The Product Catalog is used to normalize
discovered data, both the name and categorization of software products.
You can also use the Product Catalog to manage the products in your environment,
specifying a product version as approved, unapproved, or blacklisted. The
Definitive Media Library (DML) is the set of software in the Product Catalog that
are approved for your organization to use.
The Product Catalog defines the files and suites associated with each software
product, and it enables you to specify the location of the master copies that are
used to install the products. For more information, see the BMC Atrium Core 7.6.03
Product Catalog and DML Guide and BMC Atrium Core 7.6.03 Web Services Help.
The Service Catalog component of BMC Atrium CMDB

The Service Catalog provides centralized management of business services across
BMC products. It enables you to define in BMC Atrium CMDB a common list of
services that IT provides to the business. You can use Atrium Explorer to
dynamically update the infrastructure CIs related to these services by using
queries and templates.
Relating services to infrastructure CIs in your CMDB enables an IT organization to:
Establish and set clear expectations for service delivery.

Rationalize data across IT processes based on a business context.
Provide a service-oriented approach to enable management reporting.
With the Service Catalog, you can access a list of all the business services and their
supporting technical services. For more information about the Service Catalog, see
the BMC Atrium CMDB 7.6.03 Administrator's Guide.
The BMC Atrium Integration Engine component of BMC Atrium Core

The BMC Atrium Integration Engine product enables you to transfer data between
an external datastore and BMC Atrium CMDB or the BMC Remedy Action
Request System (BMC Remedy AR System) product. The BMC Atrium Integration
Engine is ideal for complex transfers that require data transformation, for transfers
of large amounts of data, and in instances with multiple integration points. It is
also the method of choice for transferring existing data, either discovered by a
third-party discovery application or residing in flat files (CSV or XML), because
the field mapping feature enables you to map existing data to the BMC Atrium
CMDB data model.
The BMC Atrium Integration Engine is bidirectional and supports event-based or
scheduled information flow. The graphical interface displays both external data
sources and BMC Atrium CMDB data. For more information about BMC Atrium
Integration Engine, see the BMC Atrium Integration Engine 7.6.03 User's Guide.
24
BMC Atrium Core architecture and features

This section describes how the components in BMC Atrium Core integrate with
each other and other applications to form a solution. This architecture is shown in
Figure 1-2. Other features and applications such as federation, web services, and
the service oriented architecture are also described.
BMC Atrium Core architecture

Figure 1-2: BMC Atrium Core architecture
BMC Atrium Core
BMC Atrium
Integration Engine
Atrium Integrator
Other data providers
Import
datasets
Normalization
Engine
BMC BladeLogic Client Automation
Reconciliation
Engine
BMC Atrium
CMDB
Production
dataset
Other
Consumers
BMC Remedy
Asset Mgmt
Sandbox
dataset
Federated
data
BMC Atrium Discovery and

Dependency Mapping
BMC Atrium
Product Catalog
At the center of BMC Atrium Core is BMC Atrium CMDB. BMC Atrium CMDB
uses a federated data model, featuring a centralized database linked to other data
stores, to share configuration data without the high setup and maintenance costs
associated with a pure centralized approach.
The Normalization Engine makes sure that data from different data providers is
consistent in BMC Atrium CMDB. After data is normalized, it can be reconciled
and saved to the BMC Atrium CMDB production dataset.
NOTE
It is a best practice to normalize data prior to reconciliation.
25
The Reconciliation Engine merges data from multiple import datasets into the
BMC Asset dataset. This consolidated view of your data is the production dataset
that data consumers should use and on which you should base business decisions.
BMC Remedy Asset Management displays data from the BMC Asset dataset by
default. If you manually edit data using BMC Remedy Asset Management, you
should save those changes to the BMC.ASSET.SANDBOX dataset rather than writing
them directly to the BMC Asset dataset, thereby enabling the changes to be
reconciled with those from all active import datasets.
Open access to data

Even the most accurate data is useless if you cannot access it. A wide variety of
users and applications must be able to both read and write to the CMDB. Providers
create and modify data in bulk, whereas consumers view the data and can also
make modifications. Figure 1-3 shows some providers and consumers of BMC
Atrium CMDB data.
Figure 1-3: Data providers and consumers
26
Open access to data includes these features:
Programmatic accessBMC Atrium CMDB provides C, Java, and web services

application programming interfaces (APIs) to view and modify its data. This
includes both instance data and the data model. For more information, see the
BMC Atrium Core 7.6.03 Developers Reference Guide.
Bulk data loadBMC Atrium CMDB provides ways to import multiple

instances at once, so that discovery applications and others can rapidly populate
the database: the BMC Atrium CMDB APIs and BMC Atrium Integration
Engine. The latter maps and transfers data from multiple database and file
formats into BMC Atrium CMDB. For more information, see the BMC Atrium
Integration Engine 7.6.03 User's Guide.
Database and platform independenceBMC Atrium CMDB is compatible with

multiple operating systems and database vendors to provide flexibility in your
environment.
Data partitioning
Partitioning is dividing your configuration data into subsets, each representing a
logical group of CIs and relationships. In BMC Atrium Core, these partitions are
called datasets. The same real-world object or relationship can be represented by
instances in more than one dataset. For example, different discovery applications
can create CI and relationship instances in different datasets. You can later merge
those instances into a single production dataset.
This is important for the goal of verifying and correcting configuration records
against the infrastructure. You can create one dataset representing your intended
configuration, then use a discovery application to create another dataset
representing your actual configuration, and verify the former against the latter.
Federation
BMC Atrium CMDB uses a federated data model, which means that you can keep
some data in managed data repositories in lieu of populating BMC Atrium CMDB
with all your data. The most common types of federated data are related
information and detailed attributes. Related information is information about a CI
that does not itself qualify as a CI and therefore should not be stored in a CMDB.
Detailed attributes are attributes of CIs stored in BMC Atrium CMDB, but they are
attributes that are not important enough to track at the level of a CMDB.
NOTE
For information about what qualifies as a CI, see Configuration items on
page 68.
For related information, your CI records for software instances might link to the
URL of an intranet page where the software license is posted, or each CI record
might link to information necessary to search a problem database for all problems
concerning that CI.
27
For detailed attributes, the CMDB record for an employee might have a Skills
attribute that contains a list of the employees skills and a Department attribute
that contains the employees department name. It might also link to an HR
database where additional attributes, like Salary, that are not really important
from a configuration perspective are stored.
Federated data might be stored in a discovery database, a Capacity Management
system, an Availability Management system, or other external data stores. You can
retrieve federated data and view it with Atrium Explorer, as if it were stored in
BMC Atrium CMDB. The BMC federated data model enables you to connect to
JDBC compliant databases, CMDBf-compliant CMDBs, and BMC Remedy
AR System forms.
Web services and service oriented architecture

BMC Atrium CMDB web services APIs are modified based on the service oriented
architecture (SOA). SOA facilitates the loose coupling of product integrations,
minimizing the cost and difficulty of upgrading components.
Operations are grouped by related services. This grouping of operations enables
services to be versioned and extended independent of each other, which makes it
easier to add new services and operations.
With web services, integrations are more robust because services can be located
anywhere and can be started or stopped without breaking the integration. For
more information about web services and service oriented architecture, see BMC
Atrium Core 7.6.03 Web Services Help.
User access to BMC Atrium CMDB

To give someone access to BMC Atrium CMDB, you must create a BMC Remedy
AR System user on the server where BMC Atrium CMDB is installed. You can then
make that user a member of multiple groups and assign those groups to roles that
allow access to different parts of the application and its data. For detailed
information about user access, permissions, and roles, see the BMC Atrium CMDB
7.6.03 Administrator's Guide.
Overview of virtualization management

A benefit of virtualization is a dynamic IT environment in which changes can
happen rapidly and frequently. However, this can also cause service models to be
out of sync just as quickly.
These BMC Atrium Core features avert issues that arise in a virtual environment:
Continuous, real-time normalization and reconciliation to rapidly update data

in BMC Atrium CMDB
Dynamic service model updates based on queries and templates

Data models that represent virtual machine (VM) resource pools and settings
Rapid data loads
28
Architecture of the CMS

ITIL V3 introduced the Configuration Management System (CMS), which stores
all configuration records and can contain multiple CMDBs. The BMC
implementation divides the CMS and its infrastructure into the following layers:
The CMDB
The CMS DataRelated data and additional detail linked to or from the CMDB
The CMS EnvironmentApplications that interact with the other two layers
Figure 1-4 illustrates these layers.
Figure 1-4: CMS infrastructure
CMS Environment
Applications
Capacity
Management
SLA Management
Software Config.
Management
Change
Management
Application
Management
Discovery
Application 1
Service Impact
Management
Asset
Management
Identity
Management
Discovery
Application 2
Help Desk
Incident
Management
Provisioning
Problem
Management
Managed by
Requests
for
Configuration
Data
Requests
CMS Data
Additional
CI detail
Federated CI
Data
Information related to CIs

Change
Requests
Contracts
Definitive
Media Library
Help Desk
Tickets
Service Level
Agreements
Other Data
Related to CIs
Links between
records
CMDB
Configuration
items and their
relationships
29
The CMDB layer

A CMDB holds only instances that represent physical, logical, or conceptual things
(called CIs) throughout your organization that you have a business need to track
and the relationships between these items that are also important enough to track.
CIs and the relationships between them are called configuration data.
Some of the attributes of these CIs can be links to the CMS Data layer. Not all
available CI attributes must be stored in the CMDB: in fact, you should store only
the key attributes here and link to the less-important attributes in other CMS data
stores.
Even though a CMDB does not hold all attribute data or related data, it still serves
as the single source of reference for configuration data because it links to the CMS
Data layer. For example, you might have an instance in a CMDB representing a
printer, and a federated link to incident requests about the printer in another CMS
data store.
You can make all requests to a CMDB, and when the data that you need is not
stored there, you find reference links to where that data is stored and information
about how that data can be accessed. The data accessed through these links is
called federated data.
The CMS Data layer

The CMS Data layer can include several data stores. It includes related data and
any CI attributes that you judge as not appropriate to track in the CMDB.
For example, suppose that your discovery application discovers 100 attributes of
each computer system on your network, but only 20 of them are critical to your
business. You would import the 20 attributes from your discovery database into
the CMDB and leave the other 80 in the discovery database, which is part of your
CMS.
The two types of data in the CMS Data layer are linked to the CI data in the CMDB
in different ways. The extra CI attributes are linked from their instances in the
CMDB with federation, enabling requests made to the CMDB to reach these
attributes. Federated data can include information in another database, BMC
Remedy AR System forms, or even another CMDBf-compliant CMDB. For
example, you might use multiple CMDBs in a global company to comply with
government regulations, with a different CMDB in each country or geographical
region. One CMDB serves as your single source of reference about CIs and
relationships in your environment, while data in the other CMDBs is federated.
For CMS data that is simply related to CIs, the link can be in either or both
directions. For example, a change request record could link to instances of the CIs
it will change, and each CI instance could link via federation to the change requests
that affect it.
30
Separating this layer from the CMDB has several benefits:
The CMDB can focus its functionality on CIs and their relationships. This
functionality includes partitions for data from multiple sources, reconciliation
of that separate data, and federated data.
The overhead required to provide CMDB functionality is not wasted on data

that does not need it. For example, multiple snapshots of every change request
record are unnecessary, so making your change request records part of the
CMDB would be confusing and waste valuable storage space.
You do not have to modify the CMDB to hold related data. With the boundary
drawn at CIs and their relationships, the question of whether to store some new
type of data in the CMDB is already answered. You store it instead as part of the
CMS Data layer, and save the trouble of changing the data model in the CMDB
to accommodate the new type of data. You also avoid pitfalls inherent in
trimming the data model if you later decided to move data out of the CMDB.
Transactional data can be stored in databases specifically designed to handle a

high volume of real-time requests.
Data is provided more efficiently. Instead of getting all their data from the
CMDB, data consumers can get it from individual data stores that are optimized
to provide the specific type of data being requested.
You do not need to undertake several data migrations and application

integrations to move your change requests, incident tickets, and other CI-related
data into the CMDB. Applications that use this data can continue to access it
where you currently store it.
The CMDB does not become a bottleneck. With requests for related data on its
own being handled by other databases, the CMDB does not have to
accommodate all such traffic in addition to CI-related requests. You can spread
the load across multiple systems.
Though your CMS Data layer can be a single data store, you do not have to store
the data this way. The different types of data in the CMS Data layer are not
necessarily linked to or related to each other. The only thing they must have in
common is a link to or from the CMDB.
CMS Environment
Where the CMS Data layer contains data, the CMS Environment is devoted to the
applications that provide and consume that data. These applications can access the
CMDB, the CMS Data, or both. For example, an Asset Management application
that views and modifies CI instances in the CMDB is part of the CMDB
Environment as a consumer, and a discovery application that creates CI instances
in the CMDB is part of the CMDB Environment as a provider.
These applications sometimes store their information in their own databases, but
the two are still considered to be part of different layers of the CMS infrastructure.
An application is part of the CMS Environment, whereas its configuration-related
data is part of the CMS Data. Of course, applications in the CMS Environment can
also access data unrelated to CIs. This data is not part of the CMS Data.
31
BMC Remedy AR System foundation

BMC Atrium CMDB is built on the BMC Remedy AR System application. The
BMC Remedy AR System is a professional development environment for creating
business workflow applications.
BMC Remedy AR System architecture

BMC Atrium CMDB fits into the BMC Remedy AR System architecture as shown
in Figure 1-5 on page 32. To browse class instances or configure BMC Atrium
CMDB from the BMC Atrium Core Console, use a web client with the BMC
Remedy Mid Tier, just as you would to access any other BMC Remedy AR System
forms.
Figure 1-5: BMC Atrium CMDB and BMC Remedy AR System infrastructure
Web clients
BMC Remedy User

Windows clients
Other API
programs
BMC Remedy Mid Tier
AR System APIs
CMDB APIs
AR System server
CMDB forms
(Console and
classes) and
workflow
Other forms
and workflow
Database
AR System data,
including CMDB data
32
CMDB engine
ITIL and SACM
For more information about BMC Remedy AR System applications, forms, and
other concepts, see BMC Remedy Action Request System 7.6.03 Form and Application
Objects Guide.
Benefits of using BMC Remedy AR System

Running on the BMC Remedy AR System gives BMC Atrium CMDB several
benefits, including:
A proven, stable platform

Compatibility with a large number of databases and operating systems
A flexible permissions model with users and groups
Ability to add customized workflow without having to code
Easy replication with the Distributed Server Option
Scalability, using server groups to distribute load
Easy integration with CMS data stores, such as incident tickets and contracts
Built-in auditing and archiving mechanisms
No programming required to configure
For more information about BMC Remedy AR System concepts and architecture,
see BMC Remedy Action Request System 7.6.03 Concepts Guide.
ITIL and SACM

IT departments face numerous challenges in providing dependable services that
support a companys business goals. Solving most of them requires a good
Configuration Management strategy: without knowing what is in your
environment, you cannot hope to control it, maintain it, or improve it.
Due to a growing interest in adopting best practices across IT departments,
particularly according to standards such as the Information Technology
Infrastructure Library (ITIL), many organizations are now deciding to implement
a CMS. They realize there is a business value in having a single source of reference
for their organizations decision support that provides a logical model of the IT
infrastructure to identify, manage, and verify all configuration items (CIs) in the
environment.
In ITIL version 3, the process that supports data management of CIs and IT assets
for information and knowledge to enable service management decisions is referred
to as Service Asset and Configuration Management (SACM). SACM encompasses
the Asset Management and Configuration Management processes, managing
service assets to support the other Service Management processes.
33
Purpose of SACM
According to the ITIL Service Transition manual, the purpose of SACM is to:
Identify, control, record, report, audit, and verify service assets and
configuration items, including versions, baselines, constituent components,
their attributes, and relationships.
Account for, manage, and protect the integrity of service assets and
configuration items (and, where appropriate, those of its customers) through the
service lifecycle by ensuring that only authorized components are used and only
authorized changes are made.
Protect the integrity of service assets and configuration items (and, where
appropriate, those of its customers) through the service lifecycle.
Ensure the integrity of the assets and configurations required to control the
services and IT infrastructure by establishing and maintaining an accurate and
complete Configuration Management System (CMS).
Goals of SACM
According to the ITIL Service Transition manual, SACM pursues the following
goals:
Support the business and customer's control objectives and requirements.

Support efficient and effective Service Management processes by providing
accurate configuration information to enable people to make decisions at the
right time (for example, to authorize change and releases, resolve incidents and
problems faster).
Minimize the number of quality and compliance issues caused by improper

configuration of services and assets.
Optimize the service assets, IT configurations, capabilities and resources.
Benefits of SACM
Achieving the goals of SACM can benefit your organization in significant,
measurable ways related to control, integration, and decision support.
Control
Verifying and correcting configuration records gives you a greater degree of
control over your infrastructure. For example, by controlling the versions of
configuration items, you reduce the complexity of your environment, and in turn
your support costs. Items that disappear or that appear without being paid for are
noticed, helping you control assets and avoid legal issues. Exercising greater
control over your environment also means that you can increase overall security.
34
ITIL and SACM
Integration
When processes such as Incident Management, Problem Management, Change
Management, and Release and Deployment Management are based on a current
record of your configuration, they can be integrated, as shown in Figure 1-6 on
page 35. This reduces administrative costs and errors. For example, you might
integrate Incident Management and Change Management processes in the
following ways:
When resolving an incident requires a change, the Incident Management

application can automatically create that change request.
An Incident or Problem Management application can use a service model to

identify previous changes that might have caused a failure.
Integrating all configuration-related IT processes can reduce the number of staff
needed to administer your environment, saving you money.
Figure 1-6: Some of the ITIL processes integrated by the CMS
Service Level
Management
Release and
Deployment
Management
Change
Management
CMS
Service Asset
and
Configuration
Management
Capacity
and Demand
Management
Decision support
Your IT managers benefit from having accurate configuration information
mapped to your Service Management processes. Making decisions is easier when
you have complete and accurate data, resulting in better resource and performance
estimates. You can commit to service levels more confidently, and your risk
management improves, reducing unplanned downtime.
35
Data is the key to SACM

Whatever SACM processes you implement, their effectiveness depends on the
data that they use.
Configuration data must be accurate, which means it must be updated frequently.
Configurations are constantly changing, so last weeks correct data could be
obsolete this week. This could result in a purchase of ten servers when you need
only five, or, worse, the installation of a security patch that causes a system to fail.
Configuration data must also be available to all your IT processes, because even
the most accurate data is useless if you cannot access it. For example, if the network
topology data provided by your discovery application is not accessible to your
Change Management application, you cannot intelligently plan a network
redesign.
The solution that enables you to maintain accurate configuration data that is
shared by multiple IT processes is a CMDB, preferably one that is frequently
updated by an automated discovery tool.
Control of the Configuration Management process

According to ITIL, you should continually assess the efficiency and effectiveness
of your Configuration Management process by using Continual Service
Improvement, including regular management reports. You should also schedule a
review of the expected growth of Configuration Management activities on a
regular basis.
ITIL recommends generating the following reports, and making their results
available for interrogation and trend analysis by IT Service Management and other
groups within IT services:
Results of configuration audits

Information about the number of registered CIs, including growth and capacity
information
Details about any delays caused by Configuration Management activities

Details about hours worked by Configuration Management staff
36
Calbro Services user story
Calbro Services user story

In the BMC Atrium Core documentation set, a fictional company named Calbro
Services helps explain how BMC Atrium Core principles and procedures are used
in practice. Although Calbro Services is a fictional company, it is based on research
of actual BMC Software customers. Seeing how Calbro Services completes tasks
should prove useful as you implement BMC Atrium Core in your own
environment.
Calbro Services company background

Calbro Services, a large, global company, is headquartered in New York City and
publicly traded on the New York Stock Exchange. The company has 27,000
employees in 240 offices in 20 countries. The following table describes Calbro
Services key business services.
Table 1-1: Key business services
Service
Description
Online banking
500 ATMs in major cities
World wide web

(WWW) presence
Corporate site and online brokerage services
Discount equity
brokerage
Online and storefront services
Sales force
automation
Automated sales activities such as leads, orders, reports, and so on
Customer support
Support centers in the United States, Europe, and Asia
Mass Marketing
World-wide marketing campaigns aimed at making Calbro

Services a household name
Calbro Services revenues

Calbro Services has revenues in excess of $18.5 billion dollars, with over $308
billion in assets. Their online banking and discount equity brokerage services are
their key revenue generators.
Calbro Services business strategies

Already a leader in the discount equity market, Calbro Services has plans for
growth in the banking, brokerage, and financial services arena. They also want to
make sure that their investments in groundbreaking technology provide a good
return on investment as they offer more services and products globally. Calbro
Services expects to increase their operating revenue by increasing their gross
margin 4 percent over the current 44 percent.
37
Calbro Services business challenges

Calbro Services has several branch offices across the world. While they have a
common data center, the various IT departments have been operating as separate
entities. To pursue their ITIL goals and make sure that the IT services provided
maximize the business value and run like a business itself, Calbro Services plans
to consolidate their various IT departments.
BSM at Calbro Services

Calbro Services has established business services with defined service level
agreements. Their business services are modeled, monitored, and managed.
BMC Atrium Core roles at Calbro Services

Although Calbro Services has thousands of employees, those in IT Support would
be the personnel most likely to use BMC Atrium Core applications.
Implementation of BMC Atrium Core at Calbro Services

Calbro Services has chosen BMC Software solutions to manage their IT operations
from a business perspective.
Because Calbro Services has clearly defined business services, the consolidation of
the various IT departments is part of their overall business plan. As they go
through this process, they must plan how to populate BMC Atrium CMDB with
data from the different IT departments. That process entails such tasks as:
Discovering IT assets and components

Defining user access
Determining which data should be federated
Possibly extending the data model
Transferring existing data
Establishing guidelines for BMC Atrium CMDB updates
Populating the Product Catalog
Configuring normalization of the data
Configuring reconciliation of the data
The concepts and planning required for performing these tasks are described in
this manual.
38
Chapter
Planning a CMDB
This section provides best practices for planning with BMC Atrium Core products.
This involves planning the BMC Atrium CMDB population and normalizing and
reconciling data.
CMDB planning stages (page 40)

Phased implementation of a CMDB (page 42)
Challenges, critical success factors, and risks (page 42)
Chapter 2
Planning a CMDB
39
CMDB planning stages

This section provides an overview of the stages involved in structuring a CMDB
project and successfully delivering a comprehensive, effective, and useful CMDB.
These stages are set forth in the Step-by-Step Guide to Building a CMDB and are
summarized here. You can request this book from http://www.bmc.com.
The stages are further divided into discrete steps, each with specific goals and
objectives that help you meet the milestone for each stage. Some aspects of this
process are described in more detail in this document and in other BMC Software
documentation, as noted in this section.
Stage 1: Assembling the project team

The number of team members that you choose and how many roles each plays
depends on the size and structure of your organization, but you should employ
project management standards such as including stakeholders and representatives
from the user community.
The high-level steps associated with this stage are:
Step 1, Assemble project team

Step 2, Obtain CMDB knowledge
Step 3, Create and agree on CMDB goals and mission statement
Step 4, Review and define benefits
Step 5, Build a business case
Your Configuration Management team should collectively be knowledgeable in:
ITIL Service Support processes and guidelines

BMC Atrium CMDB administration, best practices, and integration methods
The BMC Atrium CMDB Common Data Model
BMC Remedy AR System development
Project management
Business management processes
Stage 2: Defining requirements and creating IT service model

blueprint
Step 6, Identify and review governance requirements

Step 7, Review and select supporting best practices
Step 8, Identify requirements to address potential problems
Step 9, Identify inventory and asset requirements
40
CMDB planning stages
Step 10, Define service catalog requirements

Step 11, Define CMDB requirements to support other processes
Step 12, Define CI level and IT service model
Step 13, Define CI relationships
Step 14, Define CI attributes
Step 15, Design IT service model blueprint
The result of these steps is a blueprint that models your configuration data
requirements.
Based on your configuration data requirements for BMC Remedy Asset
Management and other consumers, use the Mapping Your Data to BMC Atrium
CMDB 7.6.03 Classes document to identify the CI classes and attributes that you
need to populate and store in BMC Atrium CMDB.
For information about the complete structure and class details of the CDM, see the
BMC Atrium CMDB 7.6.03 Common Data Model Diagram and the BMC Atrium
CMDB 7.6.03 Data Model Help.
Stage 3: Selecting CMDB solution and tools

Step 16, Select CMDB solution

Step 17, Plan the CMDB population
For details about this step, see Planning to populate BMC Atrium CMDB on
page 72.
Step 18, Select tools to automate CMDB population

Step 19, Calculate project Return on Investment (ROI)
Stage 4: Constructing and maintaining your CMDB

Step 20, Construct your CMDB

Step 21, Create CI lifecycle management processes
Step 22, Build supporting processes
Step 23, Populate your CMDB
For details about this step, see Importing data to BMC Atrium CMDB on
page 135.
Step 24, Train the CMDB team and users
Chapter 2
Planning a CMDB
41
Stage 5: Driving ongoing value

Step 25, Implement measures and metrics

Step 26, Create a continual service improvement program
Phased implementation of a CMDB

Implementing a CMDB to manage your entire configuration at once is a daunting
task, so a phased approach to implementation is usually better. Consider the
following alternatives for breaking up the implementation:
By critical business services or critical business applications

By company department
By geographic region
By support group
By importance of CI
Regardless of which types of phases that you use, try to keep transition times short.
While in transition, you must maintain both your current and former processes,
which is difficult to do for long periods.
Your later phases will be less costly if you apply lessons learned in early phases.
Challenges, critical success factors, and risks

The ITIL Service Transition manual identifies the following challenges, critical
success factors, and risks with SACM.
Challenges
Challenges to SACM include:
Persuading technical support staff to adopt a checking in/out policy, which can
be perceived as a hindrance to a fast and responsive support service. If the
positives of such a system are not conveyed adequately then staff might be
inclined to try to circumvent it.
Attracting and justifying funding for SACM, since it is typically out of sight to
the customer units empowered with funding control. In practice it is typically
funded as an invisible element of Change Management and other ITSM
processes with more business visibility.
An attitude of just collecting data because it is possible to do. This leads

SACM into a data overload which is impossible, or at least disproportionately
expensive, to maintain.
42
Challenges, critical success factors, and risks
Lack of commitment and support from management who do not understand the
key role it must play supporting other processes.
Critical success factors

Critical success factors for SACM include:
Focusing on establishing valid justification for collecting and maintaining data

at the agreed level of detail.
Demonstrating a top-down approach that is focused on identifying service CIs

and subsequently the CIs that support those services, thereby allowing a rapid
and clear demonstration of potential points of failure for any given service.
Setting a justified level of accuracy, that is, the correlation between the logical
model within SACM and the real world.
Making use of enabling technology to automate the CMS practices and enforce
SACM policies.
Risks
Risks to successful SACM include:
The temptation to consider it technically focused, rather than service and bsiness
focused, since technical competence is essential to its successful delivery.
Degradation of the accuracy of configuration information over time that can

cause errors and be difficult and costly to correct.
The CMS becomes out of date due to the movement of hardware assets by nonauthorized staff. Half-yearly physical audits should be conducted with
discrepancies highlighted and investigated. Managers should be informed of
inconsistencies in their areas.
Chapter 2
Planning a CMDB
43
44
Chapter
Planning the data model
This section explains the purpose and structure of the BMC Atrium CMDB data
model. It defines the Common Data Model (CDM) and offers best practices for
extending the model.

Data model overview (page 46)

Synchronization of changes to classes (page 54)
Overview of the Common Data Model (page 54)
Planning to extend the data model (page 59)
Chapter 3 Planning the data model
45
Data model overview

The data model of BMC Atrium CMDB unifies the representation of configuration
data. It is designed to store data about the most common configuration items such
as hardware, software, and services and provide a mechanism for linking that
information to provide a complete view of all elements of an IT environment and
how they affect each other.
Data model classes and attributes

The BMC Atrium CMDB data model is object oriented and extensible. It consists
of classes, each representing a type of configuration item that can be stored in the
CMDB. Each class equates to a database table or a BMC Remedy AR System form.
For example, the data for the BMC_ComputerSystem class, which represents
computer system CIs, is accessible in the BMC.CORE:BMC_ComputerSystem join
form.
A class can be either a CI class, which defines a type of configuration item, or a
relationship class, which defines a type of relationship between CIs.
A class has one or more attributes, each of which specifies a property of the class.
For example, BMC_ComputerSystem has attributes such as HostName and Domain.
Each attribute equates to a column on a database table or a field on an BMC
Remedy AR System form.
Data model extensibility

A key aspect of BMC Atrium CMDB is a data model that is extensible.
Infrastructure, and the data that different companies want to track about that
infrastructure, is constantly changing. The data model is designed so that it can
easily be extended using the Class Manager or the BMC Atrium CMDB APIs. Some
BMC applications extend the data model to store data specific to their
functionality. To be extensible means that there is no usage distinction between the
system-defined and the user-defined data model.
Attribute inheritance
Because the data model is object oriented, a class can have subclasses that inherit
its attributes and the ability to participate in the same relationships. Subclasses are
used to further classify a type of CI and give specific attributes to the more
granular types.
For example, BMC_ComputerSystem has subclasses to represent mainframes,
printers, and storage subsystems. These subclasses inherit HostName and Domain,
and all the other attributes of BMC_ComputerSystem. Inheritance of attributes
continues to the end of the tree, so the subclasses also inherit from BMC_System, the
class above BMC_ComputerSystem, and from BMC_BaseElement, the base class
above BMC_System. Figure 3-1 on page 47 shows some of the attributes inherited
along this part of the tree.
46
Data model overview
Figure 3-1: Attribute inheritance

BMC_BaseElement
AccountID
ManufacturerName
BMC_System
AccountID
ManufacturerName
isVirtual
BMC_ComputerSystem
AccountID
ManufacturerName
isVirtual
HostName
Domain
BMC_Printer
AccountID
ManufacturerName
isVirtual
HostName
Domain
AveragePagesPerMinute
PaperSizesSupported
Relationships in the data model

A relationship class defines a type of relationship between two specific CI classes.
An instance of the relationship class relates an instance of the first, or source, CI
class to an instance of the second, or destination, CI class. The two CIs are
considered members of the relationship.
Relationship source and destination members

The placement of a CI class as the source or destination member of a relationship
is not arbitrary. The source or left class provides a group, location, hosting, or other
function, and the destination or right class is a member of, is located in, depends
on, or is hosted by it.
47
For example, the source member of BMC_HostedSystemComponents is

BMC_System, and the destination member is BMC_SystemComponent. For examples
of the meaning of source and destination in some relationship classes, see Table 31.
Table 3-1: Examples of source and destination relationship members
Class
Source acts as
Destination acts as
BMC_Dependency
Antecedent
Dependent. Depends on
antecedent.
BMC_HostedSystemComponents
Host
Component. Hosted by host.
Relationship cardinality
Every relationship class has a cardinality that defines how many instances of the
source class can be related to each instance of the destination class and vice versa.
BMC Atrium CMDB enforces this cardinality.
One to oneEach instance of the source class can have this relationship with
one instance of the destination class.
One to manyEach instance of the source class can have this relationship
with multiple instances of the destination class.
Many to oneMultiple instances of the source class can have this relationship
with each instance of the destination class.
Many to manyEach instance of the source class can have this relationship
with multiple instances of the destination class, and vice versa.
Fulfilling a many cardinality means that multiple instances of the relationship
exist.
Weak relationships
If a relationship is a weak relationship, its destination member, called the weak
member, cannot exist without its source member, called the strong member. A
weak relationship creates a logical composite object consisting of both member CIs.
You can extend this composite object by adding more weak relationships either
from the source to other destinations or from the destination, acting as a source this
time, to destinations a level below.
You can choose to act on these composite objects during certain reconciliation
activities. For example, BMC_HostedSystemComponents is a weak relationship
commonly used to relate a computer system to its components. If you copy
instances of BMC_ComputerSystem from one dataset to another, you can choose
whether instances of BMC_Monitor and other components related to those
computer systems are copied automatically to preserve the composite objects,
even though BMC_Monitor was not specified as a class to be copied by the activity.
48
Data model overview
You can also propagate attributes from the strong side to the weak side of a weak
relationship. This means that an attribute from the source CI is mapped to an
attribute from the destination CI so that for every instance of the relationship,
whenever the value changes in that attribute of the source, that value is also
written to the corresponding attribute on the destination. This enables you to
search for an instance of a destination member, such as a disk drive, and get
information about the computer system in which it is installed without having to
follow the relationship and read the computer system instance.
For instructions about propagating attributes for weak relationships, see the BMC
Atrium CMDB 7.6.03 Administrator's Guide.
Cascading delete option

Relationship classes with a cardinality of one-to-one or one-to-many have an
option called cascading delete. This causes a destination member of the
relationship, and all destinations of relationships below it, to be deleted when the
source member is deleted. Marking a CI as deleted is also cascaded down to
destination CIs when this option is enabled.
This option is particularly useful with composite objects. For example, you could
use it with the BMC_HostedSystemComponents relationship class so that when you
delete a computer system, all its components, such as disk drives and memory, are
also deleted.
NOTE
Cascading delete does not work in reverse. When you unmark a CI that was
previously marked as deleted, only the CI on which you set MarkAsDeleted to
NULL or No (BMC recommends NULL) is restored. For example, if you unmark a
computer system, it is restored, but its components, such as disk drives and
memory, remain deleted. To restore the components as well, you must unmark
each of them.
Use cascading delete carefully, because it can have far-reaching effects. Deletions
are cascaded all the way down to destination CIs at the end of a relationship chain,
and this happens for every instance of a relationship class that has cascading delete
enabled.
49
BMC Atrium CMDB data storage methods

BMC Atrium CMDB stores instance data by a method defined by the type of class
containing each instance. BMC Atrium CMDB provides the following types of
classes:
Regular
Categorization
Abstract
Abstract with data replication
Regular classes
A regular class stores the data for its attributes in its own BMC Remedy AR System
form. If it is a subclass, that form is a join form that joins the attributes of the
superclass with the attributes unique to the subclass.
Figure 3-2 shows the forms for a new regular class, with the lines representing a
join between the superclass and the form containing the uninherited attributes of
the new class.
Figure 3-2: Regular class
Superclass (SupC) form
SupC_Attribute1
SupC_Attribute2
SupC_Attribute3
SupC_Instance1
[value]
[value]
[value]
NC_Instance1
[value]
[value]
[value]
NC_Instance2
[value]
[value]
[value]
New Class (NC) form

NC_Attribute1
NC_Attribute2
NC_Instance1
[value]
[value]
NC_Instance2
[value]
[value]
New Class (NC) join form

SupC_Attribute1 SupC_Attribute2 SupC_Attribute3
NC_Attribute1 NC_Attribute2
NC_Instance1
[value]
[value]
[value]
[value]
[value]
NC_Instance2
[value]
[value]
[value]
[value]
[value]
By searching in the superclass form, you can find instances of both the superclass
and the subclass. This is a useful way to search when you do not know which class
an instance is stored in. However, you must then go to the subclass form to see all
attributes of the instance.
An example of a regular class in the CDM is BMC_ComputerSystem.
50
Data model overview
Categorization classes
A categorization class does not have its own BMC Remedy AR System regular
form. Its uninherited attributes are added to the form of its superclass. Instances of
the superclass leave these subclass attribute fields blank, whereas instances of the
subclass use them. Because of this, no attributes of a categorization class can be
required attributes.
A categorization class does have its own join form, though this is only for the
purpose of providing a form (and SQL view) that uses the actual class name. The
join form is a join of the superclass form and a stub form with no records, and is
not part of the inheritance tree. Any subclasses of the categorization class are
joined to the superclass form, not the join form.
Figure 3-3 shows the forms for a new categorization class. The superclass form has
one column containing an attribute from the categorization class. The instance of
the superclass does not have a value in this column, whereas the instances of the
new class do.
Figure 3-3: Categorization class
SupC_Attribute1
SupC_Attribute2
SupC_Attribute3
SupC_Instance1
[value]
[value]
[value]
NC_Attribute1
NC_Instance1
[value]
[value]
[value]
[value]
NC_Instance2
[value]
[value]
[value]
[value]
Stub form
New Class (NC) join form

SupC_Attribute1 SupC_Attribute2 SupC_Attribute3 NC_Attribute1
NC_Instance1
[value]
[value]
[value]
[value]
NC_Instance2
[value]
[value]
[value]
[value]
This data storage method avoids adding a database join to its subclasses. A join
form is still created for the purpose of giving the categorization class a form (and
therefore a database view) that uses its name, but that form is joined to a stub form
and is not used by any subclasses.
Because the superclass holds the instance data for a categorization class, that
superclass cannot be an abstract class.
As with a regular class, you can search in the superclass form of a categorization
class and find instances of both the superclass and the subclass. But with a
categorization class, you have access to all the attributes of that subclass.
An example of a categorization class in the CDM is BMC_Memory.
51
Abstract classes
An abstract class does not have its own BMC Remedy AR System form and cannot
hold any instances. It exists only to organize subclasses, enabling you to add a
layer of organization without a database join.
NOTE
Abstract classes are not commonly used. They are intended for special cases.
Figure 3-4 shows the forms for a new abstract class with two regular subclasses.
The lines represent the joins between the superclass and the forms containing the
new subclasses attributes.
Figure 3-4: Abstract class
SupC_Attribute1 SupC_Attribute2
SupC_Instance1
[value]
[value]
SubC1_Instance1 [value]
[value]
[value]
New Class (NC)

NC_Attribute1
NC_Attribute2
Subclass 1
(SubC1) form
[value]
SubC1_Attribute1
[value]
Subclass 1 (SubC1) join form

[value]
SubC1_Attribute1
[value]
[value]
[value]
Subclass 2
(SubC2) form
[value]
SubC2_Attribute1
[value]

[value]
SubC2_Attribute1
[value]
[value]
[value]
An example of an abstract class in the CDM is BMC_SystemComponent.
52
Data model overview
Abstract classes with data replication

An abstract class with data replication avoids a database join, thus improving
performance when searching its subclasses and retrieving their instances.
However, it results in slower performance when creating and modifying subclass
instances, so unless you really need to search the abstract class, you should create
it without data replication. Use abstract subclasses with data replication only when
you want the benefits of an abstract class and also need the ability to search all its
subclasses in one place.
Figure 3-5 shows the forms for a new abstract class with data replication and two
subclasses created from it. The lines without arrows represent the joins between
the superclass and the forms containing the new subclasses attributes, and the
lines with arrows represent data being replicated up to the level of the new class.
Figure 3-5: Abstract class with data replication
SupC_Instance1
[value]
[value]
[value]
[value]
New Class (NC)

NC_Attribute1
NC_Attribute2
New Class (NC) replication form

NC_Attribute1
NC_Attribute2
[value]
[value]
[value]
[value]
[value]
[value]
Subclass 1
(SubC1) form
[value]
SubC1_Attribute1
[value]

[value]
SubC1_Attribute1
[value]
[value]
[value]
Subclass 2
(SubC2) form
[value]
SubC2_Attribute1
[value]

[value]
NC_Attribute1
NC_Attribute2
SubC2_Attribute1
[value]
[value]
[value]
There are no examples of an abstract class with data replication in the CDM.
53
Synchronization of changes to classes

When you add or modify a class, it is not available to use immediately. The
changes that you made to the metadata must be translated into forms and
workflow on the BMC Remedy AR System server, a process called synchronization.
While synchronization is in progress, an icon appears on the class in the Class
Manager window to indicate that the class is in Change Pending state.
For information about synchronization error messages and instructions for
canceling a failed pending change, see the BMC Atrium Core 7.6.03 Troubleshooting
Guide.
Overview of the Common Data Model

The Common Data Model (CDM) is the set of CI and relationship classes that ship
with BMC Atrium CMDB. These classes are intended to represent the physical,
logical, and conceptual items that all IT environments would want to track in a
CMDB. Most of the classes in the CDM reside in the BMC.CORE namespace. The two
federation classes reside in the BMC.FED namespace.
For consistency with the industry standards that have been developed to track and
manage this type of information, the CDM is based on the Common Information
Model (CIM) from the Distributed Management Task Force (DMTF) and Microsoft
Windows Management Instrumentation (WMI). The CDM adopted much of the
basic design of the CIM and WMI without going into the same depth on the
internal workings of systems.
Classes and attributes needed only by a specific BMC product were removed from
the CDM in version 2.0, better reflecting the fact that not all installations of BMC
Atrium CMDB use them. These extensions, which are now installed by the product
that consumes data from them, reside in separate namespaces. For specific
information about what happens to CDM 1.1 classes when you upgrade to the
current version, see the BMC Atrium Core 7.6.03 Installation Guide.
For information about the complete structure and class details of the CDM, see the
BMC Atrium CMDB 7.6.03 Common Data Model Diagram and the BMC Atrium
CMDB 7.6.03 Data Model Help, both available in the Docs directory of the product
DVD.
To find out which class you should use to store a particular item from your
environment, see Mapping Your Data to BMC Atrium CMDB 7.6.03 Classes. This
document maps common items to classes both in the CDM and in BMC Software
extensions.
54
Configuration item classes

Table 3-2 describes the BMC_BaseElement configuration item class and its
subclasses in the CDM.
Table 3-2: CI classes in the Common Data Model
Class
Description
BMC_BaseElement
As the superclass for all other CI classes, BMC_BaseElement is key to the design
of the CDM. Though you are unlikely to create any instances of this class, you can
use its form as a single place to query for all configuration items. Attributes of this
class are inherited by all CI classes.
In addition to the attributes such as Name that you populate for all CIs,
BMC_BaseElement contains the core attributes such as InstanceId,
ReconciliationIdentity, and ClassId that are populated automatically by
BMC Atrium CMDB. It even includes several display-only attributes for which
values are set temporarily and then discarded.
BMC_AccessPoint
The BMC_AccessPoint class represents the ability to use or invoke a service. Its
subclasses include different types of endpoints, such as IP endpoints and LAN
endpoints.
BMC_Collection
The BMC_Collection class and its subclasses store information about physical
collections, such as subnets and LANs, and logical collections, such as roles and
user communities.
BMC_Document
The BMC_Document class stores information about documentation in your

environment, such as design and regulation-compliance requirements.
BMC_Equipment
The BMC_Equipment class stores information about physical equipment that is not
related to computing. This can include buildings, vehicles, and other facilities
items.
BMC_LogicalEntity
The BMC_LogicalEntity class tree provides mechanisms for grouping

configuration items together into logical elements. This includes business
processes, services, and physical locations.
BMC_Person
The BMC_Person class stores information about the people who manage and
depend on the other CIs in your environment.
BMC_Settings
The BMC_Settings class is an abstract class under which you can create
subclasses to provide detailed settings information about a managed element.
BMC_System
The BMC_System class is the superclass for systems such as computer systems,
mainframes, application systems, clusters, printers, virtual systems, and network
devices. These systems aggregate a set of managed components.
BMC_SystemComponent The BMC_SystemComponent class stores information about the components that
compose a system. This includes physical components like disk drives, monitors,
and so on; applications like MS Word; and other soft elements like network drivers
and file shares.
BMC_SystemService
The BMC_SystemService class contains the information necessary to represent

and manage the functionality provided by a device or software feature.
55
Relationship classes
Table 3-3 describes the BMC_BaseRelationship relationship class and its
subclasses in the CDM. Most relationship classes have subclasses that help further
define a relationship. These subclasses, which are all categorization classes, can
have additional attributes, but most often they further define a relationship only
by using different CI classes as their members.
Table 3-3: Relationship classes in the Common Data Model
Class
Description
BMC_BaseRelationship
As the superclass for all other relationship classes, BMC_BaseRelationship is

key to the design of the CDM. Though you are unlikely to create any instances of
this class, you can use its form as a single place to query for all relationships.
Attributes of this class are inherited by all relationship classes.
In addition to the attributes such as Name that you populate for all relationships,
BMC_BaseElement contains the core attributes such as InstanceId,
ReconciliationIdentity, and ClassId that are populated automatically
by BMC Atrium CMDB. It even includes several display-only attributes for
which values are set temporarily and then discarded.
BMC_Component
BMC_Component is used to define composite objects such as a computer system,

which is made up of a computer system instance, a disk drive instance, monitors,
software, network cards, and so on.
BMC_Dependency
BMC_Dependency describes configuration items that are dependent on each

other. This relationship can be used to define application dependencies, such as
a particular program that is dependent on an application server and database for
it to run.
BMC_ElementLocation
BMC_ElementLocation relates any configuration item to a physical location in

your environment.
BMC_MemberOfCollection BMC_MemberOfCollection is used to define groupings of instances in a

logical manner. This is used to define network topology, or to define the set of
configuration items that make up a business process or service.
BMC_Impact
BMC_Impact represents impact relationships between any CIs.

Note: In version 7.6.03, BMC_Impact is deprecated. To indicate an impact
relationship, instantiate any other relationship class and set the HasImpact
attribute to Yes. This strategy reflects the fact that members of any type of
relationship can impact each other.
BMC_Genealogy
56
BMC_Genealogy establishes relationships between a parent virtual machine

(VM) and its child VMs. For example, If you have a VM named win2k-vm1 and
a clone of that VM named win2k-vm2, the win2k-vm1 VM is the parent and the
win2k-vm2 VM is the child.
Federated data classes

This section describes the federated data classes in the CDM.
Table 3-4: Federated data classes in the Common Data Model
Class
Description
BMC_FederatedBaseElement
BMC_FederatedBaseElement is the base class for federated data. It is

an abstract class used to logically group federated data classes. This class
has no attributes.
BMC_FederatedBaseRelationship
BMC_FederatedBaseRelationship is the base class for relationships

between federated data and data stored in BMC Atrium CMDB. This class
is an abstract class used to logically group federated relationship classes.
A federated relationship class is not mapped to any data. Instead, it
contains a relationship qualification that acts as a join condition between
a data-model class and a federated data class. All federated data
relationship classes are derived from
BMC_FederatedBaseRelationship.
Detailed relationship categorization

When creating relationship instances, populate the Name attribute according to the
Relationship Normalization table in Mapping Your Data to BMC Atrium CMDB
7.6.03 Classes and use the source and destination CI classes specified in the table.
The number of relationship classes in the CDM is far fewer than the logical types
of relationships that you might want to use, so you can achieve a more granular
level of categorization by populating the Name attribute. For example, to specify
that a BMC_Component instance represents a product-to-patch relationship, enter
PRODUCTPATCH for the Name attribute.
By using only Name values that appear in the Relationship Normalization table,
you maintain consistency with relationships created by BMC Software products,
increasing the accuracy of reconciliation. Future releases of BMC Atrium CMDB
will require compliance with the values in this table for compatibility with BMC
Software products.
TIP
In version 7.6.03, the Normalization Engine now has the ability to set relationship
Name values according to the Relationship Normalization table. For more
information about this, see the BMC Atrium CMDB 7.6.03 Normalization and
57
Sample data models

This section describes scenarios that show how you can use the classes in the CDM
to model your data. In the figures, the boxes represent CI classes and the lines
represent relationship classes. The models shown here are simplified and do not
necessarily represent best practices. For more information, including best practices
for modeling data in BMC Atrium CMDB, see the BMC Atrium CMDB 7.6.03 Data
Modeling Guide.
Sample model for a computer system

This section illustrates a typical computer system data model. It has an operating
system, a BIOS, a word-processing application, a video card, and uses a network
printer.
Figure 3-6: Classes used for a computer system and components
Sample model for a computer system in a LAN

This section illustrates a data model in which a computer system participates in a
LAN. The computer system is in an IP subnet that is part of the LAN.
Figure 3-7: Classes used for a computer system in a LAN
58
Planning to extend the data model

The CDM includes classes that describe a wide variety of IT configuration items
and their relationships, and some BMC Software products install extensions that
add more classes and attributes to the data model. But some IT infrastructures still
do not completely map to this model. This section gives best practices for how to
extend the data model in such cases so that you can manage your entire IT
infrastructure with BMC Atrium CMDB.
Your first step in deciding whether to extend your data model should be
understanding the CDM and the extensions supplied by BMC products. Study the
BMC Atrium CMDB 7.6.03 Common Data Model Diagram and BMC Atrium CMDB
7.6.03 Data Model Help in the Docs directory of the product DVD, and the
documentation for BMC products that you own that integrate with BMC Atrium
CMDB. By reading about the classes that you have, you might find existing classes
that serve your needs or at least find the best classes to extend.
For a data model with the greatest simplicity and performance, your best choices
are ranked in this order:
1. Use federation to extend the data model.
2. Use the Category, Type, and Item attributes to extend the data model.
3. Install an extension from BMC Software to extend the data model.
4. Add attributes to extend the data model.
5. Add subclasses to extend the data model.
If you decide to add attributes or subclasses:
Perform the work using the Class Manager, an API program, or the cmdbdriver
program. Never make those changes directly on class forms using BMC Remedy
Developer Studio. Modifying the BMC Atrium CMDB data model requires
more than just editing a form, and you might break some functionality.
You can use BMC Remedy Developer Studio to modify field layout and labels.
Because a CMDB gets its value by sharing data among applications, make your
extensions as widely useful as possible, so that they can meet multiple needs.
Avoid extensions that narrowly cater to one application, even for high-volume
uses.
Do not create classes more than five database join levels deep. For information
about the classes that use joins, see BMC Atrium CMDB data storage methods
on page 50.
How federation extends the data model

Just as important as knowing how to extend the CDM is knowing when to extend it.
Some situations are better addressed by storing data somewhere other than your
CMDB or by using existing classes and attributes.
59
The CMDB should hold only common CIs and their relationships. Adding classes
and attributes for unimportant CIs taxes your CMDB. Also, creating too many
subclasses can leave you with classes so narrowly defined that they hold very few
instances. Balance the need for categorization with the need to store similar CIs
together.
How the Category, Type, and Item attributes extend the data model
To further categorize a CI class that has the specific attributes that you need,
consider using the existing Category, Type, and Item attributes instead of creating
attributes or subclasses. These attributes are part of the BMC_BaseElement class
and are thus inherited by all other CI classes. You can use them to provide levels
of categorization for instances of a class without the performance cost of a subclass.
For example, the class BMC_PointingDevice does not distinguish between a wired
mouse and a wireless mouse. To make this distinction in your data, you do not
need to create subclasses called YourModel_WiredPointingDevice and
YourModel_WirelessPointingDevice. Just populate the Item attribute with
Wired or Wireless when creating instances of BMC_PointingDevice.
NOTE
Because this categorization strategy uses a single class, the different categories,
types, and items cannot have relationships to different classes. To have different
relationships for each Category, Type, and Item, create subclasses for them
instead of using this strategy.
How additional attributes extend the data model

If an existing class describes your CI well but lacks a few pieces of information, add
attributes to the existing class to store that information and avoid the performance
cost of a subclass. To store some CIs that use these attributes and some that do not,
make the entry mode of the attributes Optional.
Adding attributes works well when you have only one variation on a class to
accommodate. If you have two or more variations, each with their own set of
attributes, consider creating subclasses for them instead.
If you decide to add attributes, follow the Field ID rule in Naming and numbering
rules for new classes and attributes on page 64.
NOTE
When you add attributes to your data model, the new attributes are not
automatically picked up by BMC Software products that use BMC Atrium CMDB,
such as BMC Impact Solutions or BMC Remedy Asset Management. To use the
new attributes with one of these applications, you must customize the application.
For more information, see Making data model changes visible to applications on
page 64.
60
How additional subclasses extend the data model

Before you add classes for CIs and relationships, consider the alternatives, such as
using federation, using the Category, Type, and Item attributes, installing an
extension, and adding attributes. When one of these alternatives can address your
problem, it is almost always better than adding subclasses to the CDM.
But there are situations in which none of those alternatives meets your needs, such
as when you need to:
Refine your classification.

Add new attributes that are not general enough for existing classes.
Further restrict the types of CI classes that can participate in a given relationship
or vice versa.
For example, BMC_HostedSystemComponent is a relationship class that relates a
system to a system component, but if you needed more specific relationship types,
you could create subclasses. You could create one subclass of
BMC_HostedSystemComponent that relates a computer system to a disk drive and
another that relates a computer system to a memory card.
You can create subclasses of both CI classes and relationship classes. When
creating new classes, consider using categorization and abstract classes instead of
regular classes because regular classes require more system resources, and an
abundance of regular classes in your data model can slow system performance.
If you decide to create subclasses, follow the class naming rule in Naming and
numbering rules for new classes and attributes on page 64.
NOTE
When you add classes to your data model, the new classes are not automatically
picked up by BMC Software products that use BMC Atrium CMDB, such as BMC
Impact Solutions or BMC Remedy Asset Management. To use the new classes with
one of these applications, you must customize the application. For more
information, see Making data model changes visible to applications on page 64.
Regular class extentions to the data model

Creating a regular class is the most straightforward way to create a subclass, but it
has the potential to affect database performance if you create too many levels of
joins. The best practice is to go no deeper than five join levels.
Use regular classes for CIs or relationships that have more than five uninherited
attributes or that have any uninherited attributes that must be populated in every
instance. Use a regular class for any class that you expect to contain at least as
many instances as its superclass. If you expect the class to contain at least 1,000
instances, regardless of how many its superclass will contain, you might want to
make it a regular class because that enables you to create indexes on it to improve
search performance.
61
Categorization class extentions to the data model

Use categorization classes for CIs that have five or fewer uninherited attributes
none of which are requiredand that have relationships to different classes. Use
them for most of your relationship subclasses, because those subclasses often have
no uninherited attributes. Use them also when you want to be able to access all
attributes of a subclass when searching it from the form of its superclass.
Abstract class extentions to the data model

Use abstract subclasses when you need a logical class at a particular organizational
level, but only to provide some common attributes that subclasses can inherit or to
provide a common relationship type for those subclasses. To work with any
instances of the class, use an abstract class with data replication.
The classes BMC_System and BMC_SystemComponent are examples of abstract
classes created to provide a common relationship type for their subclasses. You can
create a BMC_HostedSystemComponent relationship between instances of any
subclass of BMC_System and any subclass of BMC_SystemComponent, because these
two abstract CI classes were defined as the endpoints of that relationship class.
Abstract class with data replication extentions to the

data model
An abstract class with data replication avoids a database join, thus improving
performance when searching its subclasses and retrieving their instances.
However, it results in slower performance when creating and modifying subclass
instances, so unless you really need to search the abstract class, you should create
it without data replication.
Use abstract subclasses with data replication when you want the benefits of an
abstract class but also need the ability to search all its subclasses in one place.
The Final option

Use a final class when you want to prevent others from creating subclasses of a
class you create. For example, if you build a C API program that performs tasks
against a particular class, or use custom workflow with a particular class, you
might mark it as Final so that your program or workflow does not have to account
for subclass data stored with the class.
The Singleton option

Use a singleton class when you have a unique CI or relationship that you want to
store in BMC Atrium CMDB. For example, you might use a singleton class for your
companys CEO so that you can model the impact of particular IT resources on the
CEO.
62
How Calbro Services extended the data model

Calbro Services wants to track the model year of several of the devices on the
network, such as servers, workstations, routers, and so on. Because the model year
is a critical piece of information, the administrator wants to include it in the data
model.
Working through the preferred means of building the data model, the Calbro
Services administrator first considers federating the model year data. This data is
not information related to CIs, such as incident requests. Neither is it non-critical
detailed information about CIs, such as service records. The model year is a critical
piece of information about computer equipment used throughout the company, so
the administrator discards federation as an option.
Second, the administrator considers using the existing Category, Type, and Item
attributes to store the model year data. These attributes are used for classification,
and are insufficient for storing model year information.
Third, the administrator considers using an existing BMC Software extension to
the data model, but the model year is not included in extensions Calbro Services
intends to use.
Next, the administrator considers adding a new attribute to an existing class. The
model year is important to different consumers of BMC Atrium CMDB data. After
referring to BMC Atrium CMDB 7.6.03 Data Model Help, the administrator learns
that the new attribute could be added to the BMC_ComputerSystem class. Because
each subclass inherits attributes from its superclass, the BMC_Mainframe and
BMC_Printer classes could also use the new attribute. The administrator would like
the option of tracking the model year of mainframes and printers, and so decides
that the best approach is to extend the data model by adding a new attribute to the
existing BMC_ComputerSystem class.
63
Naming and numbering rules for new classes and attributes

If you create classes or attributes in your data model, use the following guidelines:
Name a new class with a prefix other than BMC_ to identify it as your own, and
make the name descriptive.
Give an attribute an Attribute Name that is unique across your entire data
model.
Give attributes a Field ID greater than 536870911 or leave this field blank to
automatically generate an ID. Specifying a value greater than 536870911 enables
you to create custom BMC Remedy AR System workflow on the field and share
the workflow between forms, because you can give the same ID to a field on
another form.
It is better to give attributes a Field ID that is unique across your entire data
model; therefore you should share workflow only between a BMC Atrium
CMDB form and a form that is not part of BMC Atrium CMDB. See the BMC
Remedy AR System documentation for information about sharing workflow
and other benefits of specifying a Field ID.
BMC Software reserves numbers 536870911 and lower.
Making data model changes visible to applications

When you add classes and attributes to your data model, they are not
automatically picked up by BMC Software products that use BMC Atrium CMDB,
such as BMC Impact Solutions or BMC Remedy Asset Management. To use the
new classes and attributes with one of these applications, you must customize the
application.
BMC Remedy AR System applications

Some BMC Remedy AR System applications, such as BMC Remedy Asset
Management, maintain their own set of join forms for viewing and modifying
BMC Atrium CMDB instance data. After you add a new class, BMC Atrium CMDB
can generate these join forms for such an application and arrange the fields
according to view templates specified by the application. For information about
controlling the layout of class forms, see the BMC Atrium CMDB 7.6.03
Administrator's Guide.
BMC Impact Solutions

To update BMC Impact Solutions to use new classes and attributes, you must
perform tasks in both BMC Atrium CMDB and BMC Impact Solutions. See the
documentation for BMC Impact Solutions for information about these tasks.
64
Documenting data model extensions

Just as you need to occasionally look up information about classes in the CDM, you
will need to look up information about classes and attributes that you create. Enter
descriptions for each in the Description fields available in the Class Manager.
You can generate an updated version of BMC Atrium CMDB 7.6.03 Data Model
Helpthe HTML Help system that provides information about the data model
to reflect your current data model and to include the descriptions for the classes
and attributes that you add.
For instructions on generating updated BMC Atrium CMDB 7.6.03 Data Model
Help with the cdm2html utility, see the BMC Atrium CMDB 7.6.03 Administrator's
Guide.
65
66
Chapter
Planning BMC Atrium CMDB

data
This section provides information about planning to bring data into your BMC
Atrium CMDB.

What data goes into an ITIL CMDB? (page 68)

Planning to populate BMC Atrium CMDB (page 72)
Planning to use federated data (page 82)
Controlling access to data (page 89)
Sizing considerations (page 92)
Replicating BMC Atrium CMDB data to other servers (page 92)
Chapter 4
67
What data goes into an ITIL CMDB?

ITIL recommends that you store several types of data in the CMDB. Its main
purpose is to hold configuration items (CIs) and the relationships between them,
which together form a configuration at a particular time or state. ITIL also suggests
that the CMDB can hold data related to CIs, such as incident tickets or SLA
definitions.
Remember that your CMDB deployment should be based on the needs of
consuming applications. Unless and until there is a defined use for a piece of data
in your CMDB, ideally that data should not be populated in your CMDB.
Configuration items
CIs are the focal point of a CMDB. Without a clear definition of what qualifies as a
CI, you will constantly struggle with deciding whether to put certain kinds of data
into the CMDB. Simply put, a CI is an instance of an entity that is part of your
environment and has configurable attributes specific to that instance. These
entities can be physical (such as a computer system), logical (such as an installed
instance of a software program), or conceptual (such as a business service). But
they must be a direct part of your environment, rather than information about such
a part. Table 4-1 gives some examples to illustrate this boundary:
Table 4-1: Example CIs and non-CIs
Configuration items
Not configuration items
A business service is part of your environment An incident ticket has configurable attributes but is
and has configurable attributes, such as criticality
not a direct part of your environment. It is
to the business and cost of interruption of service.
information about other entities (a computer system,
for example) that are part of your environment.
A computer system is part of your environment
and has configurable attributes, such as serial
A software package is not part of your
number, processor speed, and IP address.
environmentonly installed instances of it areand
is usually stored in the Definitive Media Library
A building is part of your environment and has
(DML).
configurable attributes, such as number of rooms,
climate control system, and alarm system.
An event does not have configurable attributes and is
not part of your environment.
An employee is part of your environment and has
configurable attributes, such as skills, hours, and
department.
A software instance installed on a computer
system is part of your environment and has
configurable attributes, such as license key, patch
level, and licenses available.
Of course, not everything that qualifies as a CI is worth tracking. For example, you
probably will not create records in the CMDB for all the office chairs in your
organization.
68
CI eligibility matrix
Consider creating a CI eligibility matrix to help you make decisions about which
items in your IT environment should be CIs. A CI eligibility matrix lists each CI
candidate, its CI type (such as infrastructure or service), and several eligibility
criteria to consider as part of your decision-making for CI candidates. Specific
eligibility criteria vary according to the needs of your business, but consider using
some of the following criteria:
Cost or valueDoes the CI candidate have an associated monetary cost or value

to your business?
Change considerationsWould the CI candidate be impacted by IT change

requests?
TraceabilityAre you required to track changes made to the CI candidate?

Governance and compliance requirementsIs the CI candidate crucial to
maintaining compliance with standards and other requirements?
Management of service commitmentsIs the CI candidate required to help you

meet your service commitments to the business?
MaintainabilityAre you required to maintain the CI candidate?

Delivery cost and qualityIs there a monetary cost associated with how the CI
is delivered and maintained?
Do you, and not a third party, manage the CI candidate?

Is the CI candidate unique?
Other factors specific to your business needs.
Use the individual eligibility criteria to set your overall acceptance criteria. For
example, you might determine that if a CI candidate meets a simple majority of
your eligibility criteria, it should be a CI. You might determine that a candidate
must meet each of a select few eligibility criteria to qualify as a CI. You might
determine that one eligibility criterion is more important than the rest. The final
decision is rooted in your business needs.
After you have set your overall acceptance criteria for determining how a
candidate will be evaluated, assess each CI candidate against each eligibility
criterion as yes/no or true/false, with yes or true indicating that the candidate
should be a CI. After you assess all criteria for a CI candidate, see your overall
acceptance criteria to reach a final decision for that candidate.
How Calbro Services used a CI eligibility matrix

This section shows an example of a CI eligibility matrix for Calbro Services. It
shows the eligibility criteria that the CMDB implementation team identified as
important for determining whether a CI candidate should be a CI. For each CI
candidate, the team reached a final decision based on the following requirements:
Chapter 4
69
The CI candidate must meet eligibility criteria D (identifiable) and E

(maintainable).
The CI candidate must also meet at least one of eligibility criteria A (under
change control), B (used for impact modeling), or C (used by the Support team).
After completing the CI eligibility matrix, the Calbro Services CMDB
implementation team decided to make CIs for all CI candidates except the Person
and Role candidates. Those candidates met the first requirement by meeting both
criteria D and E, but they failed the second requirement by not meeting any of
criteria A, B, or C.
Figure 4-1: Calbro Services example CI eligibility matrix
Relationships among CIs

CIs do not exist in a vacuum; they affect each other. For example, one CI could use,
depend on, be a component of, enable, be a member of, or be located in another CI.
Storing these relationships in the CMDB enables you to see how CIs interrelate and
affect one another.
70
NOTE
The use of relationships is a critical feature that makes a CMDB a powerful tool,
and is a significant difference between a CMDB and an asset store.
Relationships can be simple, such as a disk drive being a component of a computer
system, or more complex, like those shown in Figure 4-2:
Figure 4-2: Example relationships
Dependency
Online store
(service)
Server group
(collection)
Dependency
Dependency
Shopping cart
(software)
Dependency
Orders database
(software)
Member of
Web server
(computer system)
Dependency
Component
Dependency
Disk drive 1
Disk drive 2
Relationships exist not only between physical CIs, but also between logical and
conceptual CIs, such as the software instances and service instance in Figure 4-2.
Two CIs can have more than one relationship with each other: for example, an
employee might own a server and also operate it.
Relationship data makes the CMDB a powerful decision support tool.
Understanding the dependencies and other relationships among your CIs can tell
you how upgrading Processor A would improve Server Bs performance or which
services would be affected if Router C failed. Most downtime is caused by
problems stemming from configuration changes. Accurate relationship
information can help you prevent those problems.
Data related to CIs

You might have information related to CIs, such as incident tickets, change events,
contracts, service level agreements (SLAs), a Definitive Media Library (DML), and
so on. Though these things are not CIs themselves, they contain information about
your CIs and are an important part of your IT infrastructure.
NOTE
Some of these types of data are considered CIs by ITIL.
You can federate related data to make it available through BMC Atrium CMDB.
For more information about federating data, see Planning to use federated data
on page 82.
Chapter 4
71
Planning to populate BMC Atrium CMDB

If you plan to discover configuration data, you need BMC Software discovery
products or third-party discovery products. This document assumes the use of
BMC Software discovery products. If you have already discovered your
configuration data with other tools and that data resides in a database or flat files,
use BMC Atrium Integration Engine to transfer that data to BMC Atrium CMDB.
For details about how to transfer data, see the BMC Atrium Integration Engine 7.6.03
User's Guide.
Mapping CIs to the data model

CIs and relationships are represented in BMC Atrium CMDB as instances in the
data model. The data model is structured into classes that represent the types of
CIs in your IT environment, and the relationships between those CIs.
You must plan how your CIs and relationships will be populated in the data
model. See the following resources for planning and best practices:
BMC Atrium CMDB 7.6.03 Data Modeling Guide

BMC Atrium CMDB 7.6.03 Common Data Model Diagram
BMC Atrium CMDB 7.6.03 Data Model Help
Mapping CIs to discovery data sources

This section aligns with Stage 3, Step 17, Task 3. Map CIs to Data Sources, of the
Step-by-Step Guide to Building a CMDB. In this step, you select a discovery provider
to generate the CIs required by consuming applications.
If you are implementing discovery products for the first time, select either the BMC
Atrium Discovery and Dependency Mapping product, the BMC BladeLogic Client
Automation product, or a third-party discovery tool as your discovery provider. If
you want to use both BMC discovery products, use them to discover different
endpoints. In this situation, duplicate CIs are not collected and imported to the
production dataset.
To select the appropriate BMC discovery provider, consult the following topics:
Configuration data discovered by BMC BladeLogic Client Automation on

page 73
Configuration data discovered by BMC Atrium Discovery and Dependency

Mapping on page 74
If you identify multiple providers for a class or attribute, you must later identify
which providers data will be reconciled to the production dataset.
72
Best Practices
Consider these suggestions when working with discovery sources:
Do not load every discovered CI into the CMDB on every transfer. Transfer only
new CIs and CIs that have been modified since the previous transfer.
You do not have to populate each possible class with every one of your data
providers. Bring into the CMDB only the data that is used by a data consumer
to make key business decisions. If no application is consuming the data, there is
no value in maintaining and managing it in the CMDB.
If you are using more than one discovery source to populate an attribute and
those sources format the attributes value differentlyfor example, one uses
capital letters and the other does notthen you should not rely on those values
being formatted consistently in your production dataset. Though one discovery
dataset will take precedence over the other in reconciliation, there will be cases
where the production dataset receives its value from the lower-precedence
dataset. For example, a CI might not yet have been imported into the higherprecedence dataset or might have a NULL value for the attribute in that dataset.
Therefore, you should normalize the values of such attributes between datasets
before reconciliation. You can use the Normalization Engine to do this for
certain attributes. For others you would need to normalize before importing to
BMC Atrium CMDB.
When deciding how often to transfer data to the CMDB, ask yourself how often
the data changes and how important it is that you pick up those changes. You
might want to split your transfers into longer intervals for stable things like
facilities data and shorter intervals for volatile things like network data.
Network discovery applications are not the only type of discovery source that
you can use to update the CMDB. LDAP systems, Human Resources systems,
Facilities systems, third-party Asset Management databases, and others can
serve as discovery sources.
Configuration data discovered by BMC BladeLogic Client

Automation
The BMC BladeLogic Client Automation product collects hardware and software
inventory information about servers, desktops, laptops, and handheld devices
across major platforms within your company. The BMC BladeLogic Client
Automation Configuration Discovery Integration for CMDB program maps the
collected information and transfers those CIs and relationships to BMC Atrium
CMDB using BMC Atrium Integration Engine.
For a complete list of the CIs and relationships imported into BMC Atrium CMDB,
see the BMC BladeLogic Client Automation Configuration Discovery Integration for
CMDB Getting Started Guide.
Chapter 4
73
Configuration data discovered by BMC Atrium Discovery

and Dependency Mapping
The BMC Atrium Discovery and Dependency Mapping product builds a complete
topology of your applications and infrastructure including switches, servers,
operating systems, software, configuration files and logs, business applications
and dependencies. Its discovery is agentless and uses standard management
protocols such as SSH, WMI and SNMP.
Transfer existing configuration data with BMC Atrium

Integration Engine
BMC Atrium Integration Engine enables you to transfer data between an external
data store and BMC Remedy AR System forms or BMC Atrium CMDB classes. For
example, if you have existing data that has already been discovered with a nonBMC discovery tool, you can use BMC Atrium Integration Engine to transfer that
data to BMC Atrium CMDB.
BMC Atrium Integration Engine can transfer data between Microsoft SQL Server,
Oracle, IBM DB2 Universal Database, XML files, flat files such as commaseparated value (CSV) files, BMC Atrium CMDB, and BMC Remedy AR System.
For more information, see the BMC Atrium Integration Engine 7.6.03 User's Guide.
You can also use the BMC Atrium Integration Engine Adapter Development Kit to
build your own adapters to meet your organizations specific needs. For more
information, see the BMC Atrium Integration Engine 7.6.03 ADK Developer's Guide.
How Calbro Services discovers CIs

Calbro Services uses the BMC BladeLogic Client Automation product to discover
the desktop and laptop computer systems (including hardware and software),
used by Calbro Services employees.
Calbro Services also uses BMC Atrium Discovery and Dependency Mapping to
discover information about the servers, software, and other devices used to deliver
banking information to Calbro Services customers.
Lastly, Calbro Services uses a third-party discovery tool to collect information
about the equipment that supports the corporate payroll services. Calbro Services
uses BMC Atrium Integration Engine to bring relevant data from the payroll
database into BMC Atrium CMDB.
74
Assessing the configuration data source environment

This section aligns with Stage 3, Step 17, Task 4. Assess Data Source
Environment, of the Step-by-Step Guide to Building a CMDB. Based on your
configuration data requirements, identify the systems (endpoints) from which you
will gather the configuration data, how you will access those systems (based on
agentless or agent-based discovery), and the impact of the data collection process
on production activities and the network. Following are some questions to
consider:
Which endpoints contain the data that you need to discover?

How many endpoints need to be discovered?
Should the endpoints be discovered using agentless discovery or agent-based
discovery and will that discovery methodology be allowed in the IT
environment?
What type of endpoints need to be accessed: servers, desktops, laptops, handheld devices, mainframes, or network devices?
Which ports are opened on the firewall?

What credentials are required to access the endpoints?
Will discovery impact production systems or the network?
For more information about planning discovery with BMC BladeLogic Client
Automation, see the BMC BladeLogic Client Automation Configuration Discovery
Integration for CMDB Getting Started Guide.
Managing unqualified data

Your discovery tools might not be able to identify a device at an endpoint they
discover. The unknown device might be a laptop computer, printer, router, server,
or some other piece of hardware. For example, your discovery application might
discover an IP address, but lack the proper credentials to access and identify the
device at that IP address. Information about unknown devices at known IP
addresses is called unqualified data.
Consuming applications can use unqualified data can just as they use qualified
data. For example, BMC ProactiveNet Performance Management can establish
performance monitors at known IP addresses for unqualified data. If the
unqualified data becomes qualified, BMC ProactiveNet Performance Management
does not need to establish new monitors.
To configure unqualified data, create BMC_ComputerSystem CIs in BMC Atrium
CMDB, with the IsUnqualified attribute set to Yes. Connect these CIs to
discovered BMC_IPEndpoint CIs by BMC_HostedAccessPoint relationships.
For example, Calbro Services discovers three IP addresses, but cannot identify the
devices at those IP addresses. The administrator creates BMC_ComputerSystem,
BMC_IPEndpoint, and BMC_HostedAccessPoint instances as shown in Figure 4-3.
Chapter 4
75
Figure 4-3: Unidentified devices at known IP addresses
If Calbro Services later learns the identity of a device at an IP address, the

administrator updates BMC Atrium CMDB by completing the following tasks:
Create a new BMC_IPEndpoint CI, a new CI for the identified device, and the
appropriate relationship instance between those CIs. Set the IsUnqualified
attribute to NULL.
Mark the original BMC_IPEndpoint, unqualified BMC_ComputerSystem, and

BMC_HostedAccessPoint instances for deletion.
Create a BMC_BaseRelationship instance between the unqualified

BMC_ComputerSystem CI (the source CI) and the new CI that represents the
identified device at that IP address (the destination CI). Set the Name attribute of
the relationship to CorrespondsTo. This enables you to know which qualified

CIs correspond to previously unqualified CIs. When the unqualified
BMC_ComputerSystem CI is deleted, the orphaned BMC_BaseRelationship
instance is also deleted.
Extending the example started in Figure 4-3, Calbro Services gains credentials to
access to the unknown devices, and learns that all three IP addresses are used for
a single computer system. The administrator creates new CIs and relationships for
the computer system and its IP addresses, marks the original CIs and relationships
for deletion, and creates new relationships between the old and new
BMC_ComputerSystem CIs to indicate that the unqualified CIs have been qualified
as a single computer system. Figure 4-4 shows the qualified data associated with
the unqualified computer systems marked for deletion.
76
Figure 4-4: Qualified data associated with unqualified data
Grouping CIs into datasets

This section aligns with Stage 3, Step 17, Task 5. Group CIs into datasets, of the
Step-by-Step Guide to Building a CMDB. A dataset is a collection of CIs and
relationships for a given purpose. Together they form a picture of some state, time,
or configuration.
The primary purpose of datasets is to partition data according to the providers of
that data. Each discovery application that you use should store the data that it
discovers in a separate dataset. Data in a separate database that you import to BMC
Atrium CMDB through BMC Atrium Integration Engine should be stored in a
separate dataset.
You can also use datasets for other methods of partitioning data. For example, you
could use datasets to represent production data or obsolete data. Your datasets do
not all need to contain different versions of the same CIs and relationships. For
example, you could use datasets to hold:
Subsets of your overall data, such as departments or regions

Data from different companies for multitenancy
Test data
Chapter 4
77
A dataset can contain only one instance of a given CI. An instance of that CI might
also exist in other datasets to represent the CI in the contexts of those datasets.
Instances representing the same CI or relationship across datasets share the same
reconciliation identity, or reconciliation ID.
Each CI and relationship in BMC Atrium CMDB must reside in a dataset, meaning
that they have a DatasetId attribute that must contain a value.
BMC Software datasets

This section describes the default datasets provided by BMC Atrium CMDB, BMC
Remedy Asset Management, and BMC discovery products. If you use a non-BMC
discovery product, use BMC Atrium Integration Engine to import its data.
Table 4-2: Default BMC Atrium CMDB datasets used by BMC discovery products
Data created by
Dataset name
Dataset ID
Purpose
BMC Atrium CMDB
BMC Asset
BMC.ASSET
Production dataset, which is

the dataset that you treat as
your single source of
reference and that you use to
make business decisions.
BMC Atrium CMDB
BMC Sample
BMC.SAMPLE
A safe place to do testing.
BMC Remedy Asset

Management
BMC.ASSET.SANDBOX
BMC.ASSET.SANDBOX
If BMC Remedy Asset

Management is configured
with a sandbox dataset, CIs
that you manually create or
modify flow through the
sandbox dataset; otherwise,
CIs go directly into the
production dataset.
BMC BladeLogic
Client Automation
BMC Configuration Import BMC.IMPORT.CONFIG
BMC Atrium
Discovery and
Dependency
Mapping
(User-defined)
BMC.ADDM
Import CIs and relationships

from the BMC BladeLogic
Client Automation database
for reconciliation.
Import CIs and relationships
from the BMC Atrium
Discovery and Dependency
Mapping data store for
reconciliation.
How Calbro Services partitions data into datasets

Calbro Services uses the BMC BladeLogic Client Automation product to discover
the desktop and laptop computer systems, (including hardware and software)
used by Calbro Services employees. This information is stored in the BMC
Configuration Import dataset of BMC Atrium CMDB.
78
Calbro Services also uses BMC Atrium Discovery and Dependency Mapping to
discover information about the servers, software, and other devices used to deliver
banking information to Calbro Services customers. This data is stored in the
BMC.ADDM dataset.
Lastly, Calbro Services uses a third-party discovery tool to collect information
about the equipment that supports the corporate payroll services. Calbro Services
uses BMC Atrium Integration Engine to bring relevant data from the payroll
database into BMC Atrium CMDB. The administrator creates a new dataset named
Calbro Payroll specifically for this information.
Because some of the instances in these different datasets might represent the same
real-world CIs, the administrator configures BMC Atrium CMDB reconciliation
jobs to compare those datasets against each other and put the preferred pieces of
information in the production BMC Asset dataset.
Overlay datasets
BMC Atrium CMDB offers overlay datasets, which enable you to:
Make changes in a separate partition without overwriting your production data.

See your changes in context with the unchanged portions of your data.
Avoid duplicating your entire production dataset.
Create multiple overlay datasets that reuse one set of reconciliation definitions
for merging each into the production dataset.
WARNING
Overlay dataset functionality applies only to BMC Atrium CMDB API clients. If
you use the BMC Atrium Core Console or the class forms to view or modify
instances in an overlay dataset, you receive unpredictable results and can
compromise data integrity.
How overlays work

When you create an overlay dataset, you must specify an existing regular dataset
for it to overlay. Although an overlay dataset starts out empty like any other
dataset, any request for an instance in the overlay dataset passes through the
overlay dataset and returns that instance from the underlying dataset.
When you modify an instance in the overlay dataset the first time, it is copied there
from the underlying dataset with your modifications. You can also create instances
in the overlay dataset. The underlying dataset still holds the unmodified versions
of its original instances, but it does not hold the newly created instances. A request
to the overlay dataset for a new or modified instance returns that instance from the
overlay dataset, and a request to the overlay dataset for an unmodified instance
returns it from the underlying dataset.
NOTE
Requests made to the underlying dataset always return instances from that
dataset, never from an overlay dataset.
Chapter 4
79
Figure 4-5 illustrates queries against an overlay dataset, one for a modified
instance and one for an unmodified instance. Notice that the modified instance
shares the same reconciliation ID with its unmodified counterpart, but not the
same instance ID.
Figure 4-5: Query to an overlay dataset
API Query
DatasetId: Sandbox
Qualification: 'Name' = "Computer A"
API Query
DatasetId: Sandbox
Qualification: 'Name' = "Computer B"
Results
System Type: Desktop
NumberOfSlots: 4
Results
System Type: Desktop
NumberOfSlots: 5
BMC_ComputerSystem
InstanceId: 3
ReconciliationIdentity: 8
Name: Computer B
SystemType: Desktop
NumberOfSlots: 5
Overlay dataset "Sandbox"
BMC_ComputerSystem
BMC_ComputerSystem
InstanceId: 1
Name: Computer A
SystemType: Desktop
NumberOfSlots: 4
InstanceId: 2
Name: Computer B
SystemType: Laptop
NumberOfSlots: 2
Regular dataset "Production"
TIP
Use an overlay dataset to make changes during a day, and then reconcile it into
your production dataset at the end of the day when the change requests for them
are approved.
Result of deleting instances from an overlay dataset

If you attempt to delete from an overlay dataset an instance that actually exists
there, the instance is deleted only from the overlay dataset and remains in the
underlying dataset. If you attempt to delete from an overlay dataset an instance
that exists only in the underlying dataset, the instance is deleted from the
underlying dataset.
You can mark an instance as deleted regardless of whether it already exists in the
overlay dataset. In either case, this results in an instance in the overlay dataset that
is marked as deleted.
Instance ID and identity in overlay datasets

When an instance is first created in an overlay dataset as the result of a
modification, it retains the reconciliation identity of the instance in the underlying
dataset, but is assigned a new instance ID.
80
If the underlying instance has not yet been identified when it is modified in the
overlay dataset, the instance has no reconciliation identity in either dataset. This is
not a problem. When you eventually identify and merge the two datasets, your
Identify rules should be able to match these instances so that they receive the same
identity.
WARNING
For each modification that you make to an instance before it is identified, an
instance is created in the overlay dataset. You should identify instances before
modifying them a second time in the overlay dataset.
If you decide to keep the changes that you modeled in an overlay dataset, you can
merge them into the underlying regular dataset.
Controlling client write access to datasets

By default, all BMC Atrium CMDB clients can create, modify, and delete instances
in a dataset. However, you can choose to restrict this write access to one or more
specific clients: BMC Impact Solutions Publishing Server, BMC Impact Solutions
Service Model Editor, and the Reconciliation Engine. When you do this, BMC
Atrium CMDB users cannot write to the dataset with a browser or BMC Remedy
User client. You can also set a dataset to have no write access whatsoever.
Consider restricting write access to your production dataset. By allowing only the
Reconciliation Engine to write to your production dataset, you prevent
unauthorized changes to your single source of reference. Changes then must be
made to other datasets and then reconciled to the production dataset.
Identifying the discovery schedule sequence

This section aligns with Stage 3, Step 17, Task 6. Identify Sequence for Entry, of
the Step-by-Step Guide to Building a CMDB. The initial and ongoing population of
BMC Atrium CMDB should be based on the following criteria:
The requirements of the consuming application

The amount of data to be collected
The availability of the data
The demand on the production environment and other performance factors
How often the data changes and needs to be updated in the CMDB
After the initial discovery and population of BMC Atrium CMDB, the Discovery
Manager and Configuration Manager need to set a schedule for discovering
changes (new, modified, or removed CIs), importing the changed CIs to BMC
Atrium CMDB, and merging the changed CIs with the production configuration
data. If you use non-BMC discovery solutions, you must determine how best to
schedule an ongoing discovery process.
Chapter 4
81
Guidelines for scheduling and running BMC Atrium

Discovery and Dependency Mapping scans
In BMC Atrium Discovery, you must first select one of the following scanning
levels to use:
Sweep ScanConfirms only that there is an IP device at each endpoint in the

scan range
Full DiscoveryRetrieves all the default information for hosts and complete
full inference
In the Configuration Settings, you can set the number of concurrent discovery
requests. As this number gets larger, performance could be negatively impacted,
especially in environments where the network is slow to respond. The default
value varies for each appliance, and is calculated to achieve maximum
performance. However, if you experience a situation where many discovery
commands are timing out, you can adjust the default value to between 30 and 150
(in increments of 30). Generally, the more discovery requests you enable to process
concurrently, the more you increase network traffic and the absolute time to
discover a single host. However, you can use different settings as part of an overall
approach to improve discovery processing throughput.
For more information about configuring discovery settings and recommended
performance factors, see the BMC Atrium Discovery 8.1 Deployment Guide at
http://www.tideway.com/confluence/display/81/Deployment+Guide.
From that page there is also a link that enables you to download a PDF version of
the guide.
Guidelines for scheduling and running BMC BladeLogic

Client Automation tasks
You can schedule the transfer of data from the BMC BladeLogic Client Automation
database to BMC Atrium CMDB by creating one or more BMC Atrium Integration
Engine data exchanges. After each discovery task completes, run a data exchange
on a scheduled day and time, at a timed interval, or when triggered by an event
(such as the firing of an active link or filter). For more information, see the BMC
Atrium Integration Engine 7.6.03 User's Guide.
Planning to use federated data

Federated data is data stored outside BMC Atrium CMDB but linked to CIs so that
it is accessible through BMC Atrium CMDB. The most common types of federated
data are related information and detailed attributes.
Related information is information about a CI that does not itself qualify as a CI
and therefore should not be stored in a CMDB. Detailed attributes are attributes of
CIs stored in BMC Atrium CMDB, but they are attributes that are not important
enough to track at the level of a CMDB.
82
In BMC Atrium CMDB, not only can you view federated data, you can retrieve that
data for use by a consuming application as if it were part of BMC Atrium CMDB.
This feature enables you to access outside data from central CMDB repository and
lets you use your existing data store infrastructure.
Figure 4-6 illustrates both types for a BMC_ComputerSystem instance named
Computer A. The instance can be linked to incident records about Computer A,
which are related information, and also linked to discovered attributes of
Computer A that were not imported into BMC Atrium CMDB.
Figure 4-6: Federated data
Incident DB
Incident
ID: 0001
Category: Performance
Machine: Computer A
BMC Atrium CMDB
BMC_ComputerSystem
Name: Computer A
SystemType: Desktop
NumberOfSlots: 4
Discovery DB
Computer System
Name: Computer A
Registry settings: XYZ
NOTE
Federated data is not bidirectional. BMC Atrium CMDB can establish links only
from its own data to an external source, not from the external source to itself.
When to use federated data

Though a CMDB is intended as the single source of reference about your
environment, it should not be the single repository of reference. Consumers should
be able to use the CMDB to find all of your configuration data, but it should
federate much of that data to other data stores.
In general, you should have more federated data than you do data stored in the
CMDB. The CMDB should be the card catalog that gives you basic information
about what is in your library and tells you where to find the rest. It should not be
the library. It is better to start small with the data stored in your CMDB, and
federate the rest. You can add data directly to the CMDB later if necessary. For
example, you might store computer system CIs in the CMDB, and federate data
about computer components. Given this general strategy, here are a few more
considerations and recommendations when deciding which data to federate:
Chapter 4
83
Linking to federated data from the CMDB does not mean that you must go
through the CMDB to access that data. You can still access the data directly from
its own application when you do not need the context provided by a CI.
Federating avoids rewriting applications to get their data from the CMDB
instead of their current data stores.
Federating avoids extending the CMDB data model.

You can federate data that exists on databases, CMDBf-compliant CMDBs, and
BMC Remedy AR System forms.
You might use multiple CMDBs in your company. For example, you might use
a different CMDB for each of several geographical regions. Use one CMDB as
the single source of truth about your IT environment, and federate the data on
your other CMDBs.
Federate attributes that rarely ever change, or that change more than once a day.
The former are not important enough to track in your CMDB, and the latter
(such as the current load on a server) are likely to be out of date in a CMDB.
Federate attributes that will not be used to make business decisions.

Federate data such as change requests or incident records that are not CIs but
are information about CIs.
Federate definitional data such as a Definitive Media Library.
How Calbro Services uses federation

Calbro Services stores service and maintenance records for their printers in a
Microsoft SQL database. Allen Allbrook, a BMC Atrium CMDB administrator at
Calbro Services, knows that only core data for a CI should be stored in BMC
Atrium CMDB. Detailed and related data for those CIs should be federated to help
organize CIs and make BMC Atrium CMDB more efficient.
Allen determines that the service and maintenance database stores information
that is related to CIs in the CMDB, and makes that data available using the retrieval
method of federation. The federated data is then available for viewing from within
BMC Atrium CMDB through Atrium Explorer.
Federation methods in BMC Atrium CMDB

BMC Atrium CMDB enables you to configure federation through retrieval and
launch methods. The retrieval method enables you to view federated data as if it
were stored in BMC Atrium CMDB. The launch method enables you to view
federated data through another application, such as a BMC Remedy AR System
form.
These methods enable you to retrieve data in the context of a CI. That is, you want
data that is relevant to a particular CI, not every piece of data an external source
has to offer.
84
Retrieval method of federation

With the retrieval method of federation, you create BMC Atrium CMDB classes to
represent data that is stored outside of BMC Atrium CMDB. You also create
federated relationship classes that join classes that are already part of the BMC
Atrium CMDB data model to the new federated data classes. This enables you to
view the relationships between federated data and BMC Atrium CMDB data
through such tools as Atrium Explorer and Atrium Impact Simulator.
Figure 4-7: Federation objects for the retrieval method
CMDB
Federated relationship
Federated data class
External
source of
data
CI class
Federated data store
The federated data class represents a set of information on the external source of
data (such as a table on a database), so that data can be viewed within the context
of the data model. As part of the process of creating a federated data class, BMC
Atrium CMDB creates attributes to represent the fields from the external
repository. Federated data classes that you create are subclasses of the
BMC_FederatedBaseElement class.
The federated relationship class establishes a relationship between CIs stored in
BMC Atrium CMDB and external data. Federated relationship classes that you
create are added to the data model as subclasses of the
BMC_FederatedBaseRelationship class. The source class of the relationship must be
in the BMC_BaseElement hierarchy of classes, and the destination class of the
relationship must be a federated data class.
Launch method of federation

With the launch method of federation, you define the method of viewing the data
(such as opening the data on a BMC Remedy AR System form), and create a link
between that data and CIs in BMC Atrium CMDB. For example, you could use the
URL method to access any database to which you allow browser access, and you
could use the BMC Remedy AR System query method to access data from a BMC
Remedy AR System form.
BMC Atrium CMDB uses several types of objects to implement federation.
Figure 4-8 illustrates these objects, each of which is represented by a class in the
BMC Atrium CMDB metadata.
Chapter 4
85
Figure 4-8: Federation objects for the launch method
CMDB
CI class
Launch link
Launch link
CI instance
Federated key link

Key value
Launch interface
External
source of
data
Federated
product link
Federated data store
A CI class or instance has a launch link relationship to a launch interface, which

defines the information necessary to access a particular piece of federated data.
The launch interface has a federated product link relationship from a federated
data store, which names an external source of data. Because an external source of
data might offer several types of federated data, each federated data store can be
linked to multiple launch interfaces.
If foreign key substitution is used, the federated data store also has one or more
federated key link relationships to CIs. This relationship carries the key value that
identifies the federated data for the CI.
BMC Atrium CMDB offers attribute substitution and foreign key substitution as
ways to implement the launch method of federation.
Attribute substitution
Attribute substitution is the more straightforward method of federating data in
context. The information in a launch interface can include placeholders
representing attributes from the linked class. The values for those attributes are
substituted when a user or application launches the link, which enables it to access
a different set of federated data for each instance of the class.
Figure 4-9 shows an example of this. The value of the Name attribute is substituted
in the launch interface, so that the access string for Computer A queries for
incident records where Machine = Computer A and the access string for
Computer B queries for incident records where Machine = Computer B.
86
Figure 4-9: Attribute substitution
CMDB
BMC_ComputerSystem
BMC_ComputerSystem
Name: Computer A
SystemType: Desktop
NumberOfSlots: 4
Name: Computer B
SystemType: Laptop
NumberOfSlots: 2
Launch Interface
Federated Data Store
Show records where

'Machine' = $Name$
Incident DB
Incident DB
Incident
Incident
ID: 0001
Machine: Computer A
ID: 0002
Category: Connectivity
Machine: Computer B
Foreign key substitution

Some external sources of data do not have data that also exists as attributes of CIs
in BMC Atrium CMDB, which means that you cannot use attribute substitution to
match a CI to pieces of federated data. You can still federate this data in context by
using a foreign key, a unique identifier in the data store that maps to a specific CI.
For example, you might have maintenance contracts for your office equipment,
where the contracts do not see individual pieces of equipment. If you have no
single piece of data to link the contract to a CI, you can create a foreign key link that
enables you to identify the contract that is associated with a particular CI.
In addition to the relationship between the CI (or its class) and a launch interface
that is required for any federation, using a foreign key also requires a relationship
between the CI and the external source of data, containing the key. This
relationship enables the key to be substituted in to the information in a launch
interface whenever a link to that interface is launched from that CI.
Figure 4-10 shows an example of this. The Incident DB does not store the name,
system type, or number of slots of the computers related to an incident, so foreign
key substitution is necessary. The value of the key from each federated key link
relationship is substituted in to the launch interface, so that the access string for
Computer A queries for an incident ID of 0001 and the access string for Computer
B queries for an incident ID of 0002.
Chapter 4
87
You create the key as an instance of the FederatedKeyLink form. An instance of

FederatedKeyLink is required for every CI that keys a foreign key link to federated
data.
Figure 4-10: Foreign key substitution
CMDB
BMC_ComputerSystem
BMC_ComputerSystem
Name: Computer A
SystemType: Desktop
NumberOfSlots: 4
Name: Computer B
SystemType: Laptop
NumberOfSlots: 2
Key = 0002
Key = 0001
Launch Interface
Federated Data Store
Show records where 'ID' =

$#Key#$
Incident DB
Incident DB
Incident
Incident
ID: 0001
ID: 0002
Category: Connectivity
NOTE
You can get the same functionality by adding an attribute to classes in the
Common Data Model and storing the key there, or by adding an attribute in your
federated data store and storing the instance ID or reconciliation ID of CIs there,
which enables you to use attribute substitution instead. This provides faster
performance when accessing federated data and eliminates the management of
federated key relationships. Add an attribute in BMC Atrium CMDB only if the
attribute will be populated for most instances of the class.
88
Controlling access to data

BMC Atrium CMDB offers a flexible permissions model that lets you grant rolebased permission to areas of BMC Atrium CMDB functionality and grant rowlevel read and write permission to instance data.
This row-level security enables BMC Atrium CMDB to support multitenancy.
Multitenancy means that one CMDB holds data about multiple parties IT
environments, usually in the case of an IT service provider, and each party can
access only their own data. Each party whose data is represented in the CMDB is
considered an account.
Overview of multitenancy
Multitenancy has long been a feature in the BMC Remedy IT Service Management
(BMC Remedy ITSM) product suite that enables you to control which records and
configuration data are exposed to a user, based on the users membership in a
company, business unit, or other group.
Although multitenancy is primarily used by consuming applications such as BMC
Remedy ITSM and Service Impact Manager, BMC Atrium CMDB provides the
mechanisms for a multitenancy permission model. BMC Atrium CMDB also
defines a base implementation for a multitenancy permission model. You can
extend this base implementation or develop a new implementation that is
consistent with the base implementation. The Product Catalog component also
leverages multitenancy. If you have not installed BMC Remedy ITSM, you can set
up multitenancy by using the Product Catalog and the AccountID default instance
permissions in BMC Atrium CMDB. If you do this, make sure that the AccountID
values match the company values in the Company form. AccountID is used to
control BMC Atrium CMDB multitenancy, while the company field is used to
control multitenancy in the Product Catalog and BMC Remedy ITSM applications.
You can use multitenancy to control access in a hosted environment. For example,
in a service provider environment, a single BMC Atrium CMDB application might
be used by multiple companies, with the data for each company hidden from the
other companies using the application. You can also use multitenancy to control
access in a single company, with the data for each business unit hidden from other
business units.
Multitenancy is used to segregate data and restrict access by the Company field, in
BMC Remedy ITSM, or the Company form in BMC Remedy AR System. Access
restrictions can be created so that a user with access to only one company cannot
see data for another company. To segregate data by business unit, you must record
each business unit as a separate company. In this scenario, a user with access to
only one business unit cannot see incidents for another business unit.
Chapter 4
89
NOTE
You can use BMC Remedy ITSM to set up multitenancy. However, if you have not
installed BMC Remedy ITSM, you can set up multitenancy by using the Product
Catalog component of BMC Atrium Core. For more information, see BMC Atrium
Core 7.6.03 Product Catalog and DML Guide.
BMC Atrium CMDB multitenancy permission model

The DefaultAccountPermissions class enables you to define default
permissions based on AccountID. From the account ID, you can assign default
permissions when you create CIs. Default instance permissions enable you to
specify CMDBRowLevelSecurity and CMDBWriteSecurity values for an entire
class instead of specifying them every time you create an instance of the class. You
can give these permissions to a different group for each account ID, which
supports multitenancy by enabling you to grant users access to only the instances
for their account. For more information about default instance permissions, as well
as roles and other permissions, see the BMC Atrium CMDB 7.6.03 Administrator's
Guide.
The Product Catalog supports defining approved products for different
organizations. Multitenancy enables you to have a single Product Catalog shared
among multiple organizations and track the approved products for each
organization.
You can define the approved items for the version and patch levels, not just the
product name. All the other options in the Product Catalog are separated for each
products by organization as well. For more information, see BMC Atrium Core
7.6.03 Product Catalog and DML Guide.
Calbro Services access implementation

Calbro Services has several different business units. Although each business unit
is part of the overall company, the various business units need access to different
applications and data. For example, all employees of Calbro Services can install
Microsoft Word, but only certain members of Finance should install and work with
the payroll application. HR has a similar restriction on the job posting and
recruitment application used by that business unit. Members of IT should have
access to all applications.
Calbro Services must set up product access and restrictions in the Product Catalog
for Finance and HR. IT will have access to all possible products. Figure 4-11
illustrates the access in this scenario, in which some people have access to Finance
products, some people have access to HR products, and others have unrestricted
access to all products.
90
Figure 4-11: Access to applications in business units
This scenario includes the following groups:
FinancePeople in this group can access products used only by Finance.

HRPeople in this group can access products used only by HR.
ITPeople in this group can access all products, including those used by HR
and Finance.
Allen Allbrook, the Calbro Services administrator, creates Operating Company
entries for Finance, HR, and IT in the Product Catalog. This automatically creates
BMC Remedy AR System regular groups for these Operating Companies.
Next, Allen assigns individual employees to these BMC Remedy AR System
groups. For example, Allen adds Patrick Paycheck to the Finance group, Betty
Benefits to the HR group, and himself to the IT group.
Allen can then configure the Product Catalog entries for application access
according to the Operating Company. Allen allows the Global company (everyone
at Calbro Services) access to Microsoft Word, the Finance company access to the
payroll application, the HR company access to the job posting and recruitment
application, and the IT company access to all applications.
NOTE
Membership in a business unit is not the same as access to a business unit.
Product Catalog entries do not restrict employee access to applications, but Allen
can run discovery reports about the applications installed on employee computers,
and then uninstall applications that are not approved for use according to the
Product Catalog.
Chapter 4
91
Additionally, people in Finance need to see employee information stored in the

BMC_Person form, while people in HR need access to change information on that
form. To accomplish this, Allen establishes instance permissions to data on the
BMC_Person form. He first makes sure that the Finance and HR groups have access
to the CMDB Data View role. Next, Allen adds the Finance and HR groups to the
CMDBRowLevelSecurity attribute value for BMC_Person entries those employees
should see. Allen then adds the HR group to the CMDBWriteSecurity attribute
value for entries that HR employees should have access to modify.
For more information about how permissions and multitenancy are related to
products used by a company, see the BMC Atrium Core 7.6.03 Product Catalog and
DML Guide. For information about setting permissions, see the BMC Atrium CMDB
Sizing considerations
When planning for BMC Atrium CMDB population, you should consider sizing
factors, scalability, and hardware recommendations for the BMC Remedy
AR System environment. This includes the BMC Remedy AR System server,
server tier components such as Approval Server and the Assignment Engine, BMC
Atrium CMDB components, and the BMC Remedy Mid Tier. The same
consideration should be given to the discovery applications that you choose. For
detailed information about sizing, see the white paper titled Reference Architecture
for BMC Service Support Solutions.
Replicating BMC Atrium CMDB data to other

servers
You might want to replicate all or part of your CMDB to other servers for a number
of reasons, including disaster recovery, accessibility, or regional or departmental
use. This is perfectly acceptable, and can be accomplished with the Distributed
Server Option of BMC Remedy AR System or with database replication.
However, do not split your primary CMDB. Turning a CMDB into a distributed
database defeats its purpose of being a single shared access point for all the
configuration data about an organization.
If performance is a concern, you can use a server group for the BMC Remedy
AR System server where your BMC Atrium CMDB is installed. BMC Atrium
CMDB supports server groups with and without load balancers.
92
Chapter
Planning data normalization

and the Product Catalog
This section explains the purpose of data normalization and describes the Product
Catalog component of BMC Atrium CMDB.

Overview of normalization and the Product Catalog (page 94)

Normalization (page 95)
Product Catalog (page 96)
How Calbro Services planned normalization and Product Catalog
implementation (page 98)
Chapter 5
93
Overview of normalization and the Product

Catalog
The Normalization Engine and the Product Catalog are separate components but
are described together because of their close interaction. In the context of BMC
Atrium Core, normalization refers to modifying CIs and relationships to conform to
consistent standards. Primarily, this involves ensuring that product names and
categorizations are consistent across different datasets and from different data
providers. Data of the same type follows the same formatting conventions. In that
role, the Normalization Engine typically relies on the Product Catalog.
For example, a product that might have different names representing the same
product is Microsoft Office Word. Different discovery tools might record this
products name as Microsoft Office Word, MS Word, Word 2003, and so on. Each
of these names might seem to represent a different product. The Normalization
Engine can determine that these different names represent the same product, and
alters each instance to use the approved name.
The benefit of normalization is that you get accurate results when searching or
running reports for your data. For example, you can use the License Engine
component of BMC Remedy Asset Management determine whether your
environment has more installed copies of something than your license allows.
Figure 5-1 shows a simplified flow of data from either discovery or transfer of
existing data with BMC Atrium Integration Engine. Data from each source or
discovery tool is organized into datasets, which are then reconciled so that one
production dataset represents your environment. You can also create datasets to
group data; however, the datasets represented in Figure 5-1 depict the initial
datasets that are part of the discovery or transfer process.
94
Normalization
Figure 5-1: Data flow

BMC Atrium Core
BMC Atrium
Integration Engine
Atrium Integrator
Other data providers
Import
datasets
Normalization
Engine
Reconciliation
Engine
BMC Atrium
CMDB
Production
dataset
Other
Consumers
BMC Remedy
Asset Mgmt
Sandbox
dataset
Federated
data
BMC Atrium Discovery and

Dependency Mapping
BMC Atrium
Product Catalog
Normalization
You can choose to normalize data before or after it is written to a dataset in BMC
Atrium CMDB.
Normalization batch (scheduled) mode, enabled by default, can be scheduled or

started manually from the Normalization Console.
Inline normalization mode normalizes CIs before they are written to BMC
Atrium CMDB datasets.
Continuous normalization mode allows CIs to be written to a dataset before

they are normalized.
Best practice
When you initially load CIs from your data providers into BMC Atrium CMDB,
BMC recommends that you use the batch mode rather than inline or continuous
normalization. Batch mode runs a Normalization Engine job on un-normalized
data on demand or on schedule that meets your needs. If you are implementing
BMC Atrium CMDB for the first time, your current data will not be normalized.
After the initial loading of CIs, you can use the inline or continuous mode to
update CIs that exist in BMC Atrium CMDB but are not normalized.
To make sure that data is normalized initially and kept normalized, use
continuous mode to make sure that your dataset remains normalized.
Chapter 5
95
Inline mode is used mainly for integrations when a data source is writing to BMC
Atrium CMDB, and you might need to take action during the data population
process if an error occurs.
For more information about normalization, see the BMC Atrium CMDB 7.6.03
Product Catalog
The Product Catalog is a BMC Remedy AR System application that includes
several components to manage products for companies and organizations. It is a
library of all the products available to an organization, defining each product and
its attributes, such as name, manufacturer, version, and so on. The Product Catalog
contains characteristics of products that enhance the accuracy of BMC Discovery
products by uniquely identifying a package regardless of installed name or
location.
The main purpose of the Product Catalog is to enable you to manage the products
in your organization:
By providing identifying characteristics of products

By providing a single name for each product and its versions
By providing data for normalization and discovery, including storage of
product signatures
By recording whether a product is approved for use in your organization

By tracking and managing products by categorization, life cycle, development
status, approval status, and other attributes
By managing products by companies and organizations (multitenancy)

By providing data for license management, compliance, and usage tracking
For more information about the Product Catalog, see the BMC Atrium Core 7.6.03
Product Catalog and DML Guide.
Entries in the Product Catalog

A Product Catalog entry is not a CI but specifies the normalized attributes for CIs
by product, version, and patch. Thus, a CI is an instance of a product defined in the
Product Catalog. For example, a dataset includes a BMC_Product CI named
Microsoft Office 2007. The Product Catalog has a product entry named Microsoft
Office 2007.
96
Product Catalog
Components of the Product Catalog

The Definitive Media Library (DML) is a subset, or filter, of the Product Catalog
that represents software products that are marked as approved for use in an
organization. In previous releases of ITIL, the DML was called the Definitive
Software Library.
The Definitive Hardware Library (DHL) is a subset, or filter, of the Product
Catalog that represents hardware products that are marked as approved for use in
an organization.
Categorizations
Product categorization divides CIs into groups. Using the tiered structure of
product categorization, you can create successively smaller, more tightly defined
groups. You can create groups of CIs in Tier 1. In Tier 2, you can define smaller
groups of each of those groups. In Tier 3, you can create even smaller groups
within these groups.
For example, you might use Tier 1 to divide CIs into hardware and software
groups. Within the hardware group, you might define Tier 2 groups for disk
device, peripheral, processing unit, and virtual system. Within the processing unit
group, you might define Tier 3 groups for desktop, laptop, mainframe, personal
digital assistant, and server.
CIs in BMC Atrium CMDB store Product Catalog categorizations in the Category
(Tier 1), Type (Tier 2), and Item (Tier 3) attributes of the BMC_BaseElement CDM
class.
Multitenancy with the Product Catalog

The Product Catalog supports defining approved products for different
organizations. Multitenancy enables you to share a single Product Catalog among
multiple organizations but track the approved products for each organization
from the same Product Catalog data.
Chapter 5
97
How Calbro Services planned normalization

and Product Catalog implementation
Because Calbro Services is populating BMC Atrium CMDB for the first time, the
administrator uses the default batch mode to normalize data. This makes sure that
all of the existing CIs are normalized by a single Normalization Engine run. After
the initial normalization, the administrator sets up the continuous normalization
mode to make sure that the data remains normalized.
The Normalization Engine evaluates CIs with information it retrieves from the
Product Catalog and normalizes the following attributes for Calbro Services
hardware and software products:
Name
Product categorization attributes: Category, Type, and Item
ManufacturerName
Model (applicable to hardware)
VersionNumber (applicable to software)
PatchNumber (applicable to software)
Other attributes as defined by each class
For example, software CIs named Microsoft Visio and Visio 2007 are normalized
to the approved name Microsoft Office Visio 2007. Printer CIs are normalized to
the approved Category, Type, and Item values of Hardware, Printer/
Multifunction, and SystemPrinter, respectively.
98
Chapter
This section describes how to plan for the reconciliation of data from source
datasets to a production dataset. With multiple data providers loading data into
multiple datasets of BMC Atrium CMDB, you need a reconciliation process to
compare expected data against discovered data and create one complete and
correct production dataset. The BMC Atrium CMDB Reconciliation Engine
performs the main reconciliation tasks of identifying, merging, and comparing
datasets and also gives you other tools for working with datasets.

Identifying instances (page 100)

Comparing datasets (page 101)
Merging datasets (page 101)
Other reconciliation activities (page 105)
Combining activities as a job (page 105)
Qualification groups (page 106)
Chapter 6
99
Identifying instances
Before you can compare or merge different versions of an entity, you must
determine that they indeed represent the same entity. You must identify each
instance.
The Identify activity accomplishes this matching by applying rules that you
specify against instances of the same class in different datasets. For example, a rule
to identify computer system instances might specify that the IP addresses of the
instances be equal.
When the rules find a match, both instances are tagged with the same
reconciliation identity, an extra attribute that shows that they each represent the
same item in their respective datasets.
You can also manually identify instances that were not identified by rules in an
Identify activity.
To identify instances, you must create an Identify group for each participating
dataset. In this group you must create Identify rules that attempt to match
instances of a particular class in that dataset against instances in all other
participating datasets. For example, to compare datasets A, B, and C you need the
following groups: one each to match A against B and C, B against A and C, and C
against A and B.
To identify data in different classes based on different criteria, you must create
more Identify groups. Because the subclasses of the specified class inherit the
groups, if your data is sufficiently normalized, you could specify groups only for
the base class BMC_BaseElement.
You then create an Identify activity and associate the Identify groups to it.
Designate one of the participating datasets as the master dataset, meaning that the
reconciliation identity of its instances is applied to matching instances in the other
datasets, which are known as auto-identify datasets. If the instance in the master
dataset does not have an identity, one is automatically generated.
TIP
If you identify a class between datasets that are poorly normalized and you cannot
find attributes of the class itself on which to match, you can match on an attribute
of a source CI if a weak relationship exists and has any propagated attributes. For
example, if you always give a disk drive a BMC_HostedSystemComponent
relationship to the computer system where it is installed, you can match two disk
drives because their source computer systems have the same name, because
BMC_HostedSystemComponent propagates the Name attribute from system to
component.
For more information about identifying, see the BMC Atrium CMDB 7.6.03
100
Comparing datasets
Comparing datasets
The Compare activity operates against instances in two datasets and either
produces a report or executes workflow based on the Compare results. The report
shows those instances that appear in only one of the datasets and details the
differences between instances that appear in both.
Compare lets you compare an expected configuration against an actual one, which
you could use for more than one purpose. You might use Compare to alert you that
something has changed in a configuration that you expected to remain static.
Alternatively, if you have a change request in progress, you might use Compare to
verify that the configuration reaches its expected new state.
Only instances that have been given a reconciliation identity can be compared, and
they are compared only against other instances with the same identity. If you
choose to execute workflow as a result of the comparison instead of creating a
report, that workflow can execute against instances from either dataset but not
both.
To compare instances, you must create a Compare activity and specify the two
datasets that you want to compare. From that activity you can choose to exclude
particular attributes from the comparison by creating Exclusion rules for them.
To execute workflow as a result of the comparison, you must also create a
Workflow Execution group to associate with the Compare activity and from that
group, create a Workflow Execution rule for each qualification that, if true, causes
workflow to execute. The qualification can evaluate attributes from both datasets.
You also must create one or more BMC Remedy AR System filters to perform the
workflow for each Workflow Execution rule.
For more information about comparing, see the BMC Atrium CMDB 7.6.03
Merging datasets
Merging takes data from multiple source datasets and creates a composite by
copying that data to a single target dataset according to precedence values that you
specify.
Merging is essential to produce a single, valid configuration when different
discovery applications provide overlapping data about the same items, or when
you need to commit changes that were made in an overlay dataset. Only instances
that have been given an identity can participate in a Merge. To take advantage of
the areas of strength in each dataset, you create precedence values that favor those
strengths. Merging the highest-precedence attribute values gives you one CI
instance with the best of all discovered data.
Chapter 6 Planning data reconciliation
101
An overall precedence value is given to each dataset, with the ability to override it
for particular classes and attributes in each dataset. Whichever dataset has the
highest precedence value for a given attribute has its value for that attribute placed
in the target dataset. A precedence value specified for a class also applies to its
subclasses unless they override it with precedence values of their own.
You can merge data from multiple source datasets either by creating one Merge
activity that includes all the source datasets or by creating independent Merge
activities that each merge only the data from one source dataset.
TIP
No matter which of these strategies you choose, you can shorten the run time of a
Merge activity by setting Force Attribute Merge to No. This causes the activity to
perform an incremental merge, processing only the attribute values that have been
modified since the activity was last run. If an attribute value has not changed, there
is no need to merge it again.
Using a single Merge activity

When you use one Merge activity, the precedence values of all source datasets are
compared to each other at once, and the data from the dataset with the highest
precedence value is written to the target dataset. Figure 6-1 provides an example
of precedence values being applied when two datasets are merged with a single
Merge activity.
102
Merging datasets
Figure 6-1: Single Merge activity with two source datasets
1
Dataset C (100)
Computer System
IPAddress: 10.20.30.40
SystemType: Desktop
Application System
Monitor
Dataset A (500)
Computer System
IPAddress (200): 10.20.30.50
SystemType: Laptop
2
Application System (200)
Monitor
Dataset C (100)
Computer System
IPAddress (300): 10.20.30.60
SystemType (500): Laptop
Dataset B (300)
Computer System
Monitor (500)
SystemType: Desktop
Application System
Monitor
In this example, source Datasets A and B are merged into target Dataset C. Though
Dataset A has a higher precedence value (500) than Dataset B (300), Dataset A has
class and attribute precedence values for Application System and the
IPAddress attribute of Computer System (both 200) that are lower than Dataset B.
Dataset C has a precedence value (100) lower than either source, and as a result,
none of the data it contained in step 1 survives the merge.
In the Merge activity represented by step 2, Dataset C receives the Monitor and the
SystemType attribute of the Computer System from Dataset A, with a precedence
value that trumps Dataset Bs. But because the Application System and the
IPAddress attribute of the Computer System have lower precedence values in
Dataset A, Dataset C receives these from Dataset B.
Using independent Merge activities

Using independent Merge activities is the recommended method of merging
datasets, using only one source dataset per Merge activity. After each Merge
activity runs, the target dataset retainsfor each attribute that was mergedthe
precedence value of the dataset that supplied the data for that attribute. When you
use independent Merge activities, each activity compares the precedence values of
its source dataset to the precedence values of those last victorious datasets.
103
Because the source dataset in any merge is always compared against the highest
precedence value from previous merges, it is as though precedence values from all
source datasets are compared in each merge. This frees you from having to design
a Merge activity for every combination of source datasets that might be merged
together, and enables you to add new source datasets in the future without
reworking all your Merge activities. Figure 6-2 on page 104 provides an example
of precedence values being applied when two datasets are merged with
independent Merge activities.
Figure 6-2: Independent Merge activities, each with one source dataset
1
Dataset C (100)
Computer System
SystemType: Desktop
Application System
Monitor
2
Dataset A (500)
Dataset C (100)
Computer System
Computer System
IPAddress (200): 10.20.30.50
IPAddress (200): 10.20.30.50

SystemType: Laptop
Monitor
Monitor (500)
Dataset B (300)
Computer System
SystemType: Desktop
Dataset C (100)
Computer System
IPAddress (300): 10.20.30.60
Application System
Monitor
Monitor (500)
This example uses the same source and target datasets as the example in Figure 61 on page 103, and achieves the same end result. Step 1 again shows the data in the
target dataset before the merge.
In the Merge activity represented by step 2, Dataset A is merged into Dataset C.
Dataset As precedence values at every level are higher than Dataset Cs, so after
this step Dataset C contains all the data from Dataset A. You can also see that
though Dataset Cs precedence value is still 100, the precedence values of the data
in it have been adopted from Dataset A.
104
Other reconciliation activities
In the Merge activity represented by step 3, Dataset B is merged into Dataset C.

Dataset Bs precedence value of 300 is enough to beat the precedence values stored
for all attributes of the Application System and the IPAddress attribute of the
Computer System, so its data replaces the data written from Dataset A in step 1.
But Dataset Bs data for all attributes of the Monitor and the SystemType attribute
of the Computer System is not written to the target because the data placed there
from Dataset A has higher precedence values.
For more information about merging, see the BMC Atrium CMDB 7.6.03
Other reconciliation activities

The Reconciliation Engine offers the following additional activities:
Rename Datasetrenames a dataset. It does not change the DatasetId, so all

reconciliation definitions that include the dataset still work with the new name.
Copy Datasetcopies instances from one dataset to another. You can set
options to determine which relationships and related CIs are copied along with
the selected instances.
Delete Datasetdeletes instances from one or more datasets. It does not delete
the dataset itself.
Purge Datasetdeletes instances that have been marked as deleted from one or
more datasets. You can opt to have it verify that each instance has also been
marked as deleted in another dataset before deleting it. This option is useful
when you are purging data from a discovery dataset but want to purge only
instances that are marked as deleted in your production dataset.
Execute Jobexecutes a reconciliation job.
Combining activities as a job

You can create and execute reconciliation activities only as part of a job, which can
contain multiple activities and performs them in the sequence that you specify.
When you remove an activity from a job, it is deleted and cannot be used in other
jobs. You can run a job:
With schedules defined for the job

Manually
From another job
From a BMC Atrium CMDB API program
From BMC Remedy AR System workflow
105
When you use BMC Remedy AR System workflow or a BMC Atrium CMDB API
program to execute a job, you can dynamically specify datasets and qualifications
for the job to operate against, replacing those defined for the job. This enables you
to reuse reconciliation definitions with multiple overlay datasets and with subsets
of data.
Qualification groups
Most reconciliation activities enable you to specify a Qualification group to restrict
the instances that participate in an activity. Qualification groups, which are
reusable between activities, are sets of qualification rules that each select certain
attribute values. Any instance that matches at least one Qualification in a group
can participate in an activity that specifies the group.
For example, if your company just opened a Frankfurt office and you are
reconciling its discovered CIs for the first time, you might create a Qualification
group that selects instances that were discovered within the last 24 hours and have
the domain Frankfurt.
106
Chapter
Planning a service model
This section provides information about designing, developing, and maintaining

service models that enable you to manage your IT resources from the perspective
of the business services that they provide.
Service model overview (page 108)

Designing a service model (page 109)
Chapter 7 Planning a service model
107
Service model overview

A service model defines the various resources that deliver business services,
models their behaviors and functional relationships, and manages the delivery of
the resulting services. Designing and building a robust service model enables you
to view and change the relationships between the different components in the
model, as well as add new components to the model.
Relationships between service components

A physical or logical resource represented in the model is known as a service
component instance or component instance. The functional relationship between
two resources (component instances) is called a service component relationship or
a relationship. These concepts are illustrated in Figure 7-1.
Figure 7-1: Service model objects
For example, Calbro Services uses an online banking application that supports its
customers ability to access accounts and complete transactions. The relationship
between these two itemsthe online banking application and the actual banking
serviceis part of the service model.
108
Designing a service model
A service model that relates business services to IT enables IT to pinpoint root

causes and prioritize business-critical problems. Understanding what a service is
and how it delivers value to the business is the foundation for Service Transition,
an ITIL process. In ITIL version 3, IT processes are part of the service lifecycle and
IT services are viewed as business assets. The online store depicted in Figure 7-1
illustrates that IT is a business asset because the online checkout is only as good as
the physical server on which the checkout software resides, or the software itself.
If either the hardware or software fails, the user cannot complete his purchase.
Adding CIs and relationships to service models using BMC Atrium

CMDB
BMC Atrium CMDB is a possible source for service model objects that are used by
BMC Service Impact Manager (BMC SIM) and other BSM applications.
Understanding service models in general can help you as you plan, populate, and
work in BMC Atrium CMDB. Typically, objects used by BMC SIM are discovered
using discovery tools. They are reconciled by the BMC Atrium CMDB
Reconciliation Engine, and then automatically published to the BMC Impact
Manager by using BMC Impact Publishing Server.
You can also use Atrium Explorer to create relationships between CIs for special
cases, such as when you have two CIs that were created manually through Atrium
Explorer. You can use this method for creating business assets like business service
objects and organization objects.
You can use Atrium Impact Simulator whether you use BMC SIM in your
environment or not. The Atrium Impact Simulator predicts the impact on CIs by
using the impact relationships that you configure within BMC Atrium CMDB.
Atrium Impact Simulator can also use the impact relationships configured with
BMC Service Impact Manager.
For more information about service models as used in BMC Service Impact
Manager, see the BMC Impact Solutions: Service Model Administrators Guide. For
more information about Atrium Impact Simulator, see the BMC Atrium CMDB

Building a service model can be a daunting task. When you begin the process, it
might be helpful to select one critical business process or service, decompose it to
identify all aspects of the service, and build a complete service model for that part
of your enterprise.
Understanding how the various components of one business service interact helps
you construct other pieces of your service model, and helps you understand how
services themselves affect each other. For example, you might discover that your
payroll service depends on a technical service that provides access to information
through the corporate intranet.
109
Figure 7-2 on page 110 shows an example of a service model with business users,
services, and IT structure layers. The lines between the component instances
represent impact relationships.
Figure 7-2: Example of a service model
Consider the following factors in determining how to design a service model:
The diversity of IT resources and how they are monitored

The location of resources and how the management responsibilities for them are
distributed within and among IT groups
The relative importance of various resources in the delivery of business services

The need for Change Management
The maintainability of the service model over time
110
The service modeling process involves:
Defining business goals

Decomposing a business service
Defining the service model
This overall process is graphically represented in the following diagram.

1 Define business goals
2 Decompose a business service
3 Define the service model
Best practices
When designing a service model, consider the following best practices:
Agree on a model blueprint that will apply to all service models. The model
blueprint acts as a template to the construction of the different service models,
and should define a hierarchical organization and the types of CIs that relate to
each other. The blueprint should allow some flexibility.
Define terms and concepts beforehand. To your organization, what is a business

process or an IT component? What are your severity and priority levels and
what is the meaning of each? You dont necessarily have to use the ITIL
definitions for all these things, but you should have definitions that can guide
you and help settle disputes while you design service models.
Defining business goals for the service model

The most basic step involved in defining a service model is defining the specific
business goals that you hope to achieve with the model.
To do so, the IT group must engage the business managers in defining short-term,
mid-term, and long-term goals for the enterprise. These goals guide the design and
development of deliverables for all service model development phases and define
the amount of time and effort required for development and implementation.
111
Some possible goals are:
Business continuity and service availabilityThis type of implementation is

driven from the top and makes sure that IT is delivering their services as agreed.
It consists of a business-centric model in which business processes, services, and
service level agreements (SLAs) rely on a small number of vital IT components
that measure the pulse of the underlying environment.
Business-focused operational efficiencyThis type of implementation is likely

to involve various populations and centers of management in the enterprise. It
consists of a balanced representation of the operational environment,
encompassing the IT components, such as systems and applications, and the
logical components, such as services, and other business objects.
Operational efficiencyThis type of implementation is run by and for the IT

group. It consists of a thin layer of logical groups on top of a large number of IT
resources, ranging from applications and systems to hard disks and other
hardware components. Services are logical groupings that provide a convenient
way of classifying the technical resources. For example, you might use an email
service to classify all of the servers and software required to enable people to
send and receive email.
Decomposing a business service

The purpose of decomposing a business service is to identify and document

business processes, identify the IT services that support them, and identify IT
components and assets that provide the IT services. Business processes are
determined at a high level and can include other processes, such as Marketing and
Sales. This document focuses on how business services are impacted and
supported by IT.
For example, the online banking division of Calbro Services might identify a
business service as the ability of customers to transfer funds, a common service for
an online banking company. An IT service that supports this service is the
maintenance of the network on which the servers that facilitate the fund transfer
communicate. The supporting IT assets are the servers, databases, and related
hardware and software systems that facilitate the fund-transfer service.
Figure 7-3 depicts a scenario in which the application server resides on a virtual
machine (VM), which, in turn is running on a server capable of hosting several
VMs. The system is set up so that, if one VM fails, another VM resumes the process
without interruption. The fund-transfer business service depends on everything in
the gray box, which IT provides and supports.
112
Figure 7-3: Example of a business service and the supporting IT assets
Fund
transfers
VM
Host
Business
Service
VM
VM
IT
application
on VM
The fund-transfer service is only one business service provided by Calbro Services.
The service model created by Calbro Services is a collection of service components,
each of which represents a business service. Each component can contain several
functional applications, each of which can have multiple IT components. A service
model shows how the components are interconnected and shows how component
failures can impact other services. See Figure 7-2 on page 110.
Best practices
When decomposing a business service, consider the following best practices:
To find IT services and the components that support them, look at service level
agreements and operational level agreements.
Determine the entry point to each service model, the highest object in the model.
The entry point depends on who is consuming the model. Working from here
down to the bottom of a service model makes sure that you operate from the
perspective of the business.
Identifying business services

To identify business services, start by gathering information from such sources as
business unit managers, business process managers, and staff personnel
knowledgeable about the business services. Company organization charts might
be helpful in identifying the relevant people.
The process involves interviewing the managers and identifying the following
information:
Business processesIdentify key business processes such as Market Research,

Product Planning, Response Management, or Case Management. There can be
multiple levels of business processes, starting with higher level core
competencies and business functions, to specific sub-business processes.
Functional applicationsIdentify the business applications that support the

business processes. Map the business processes to the functional applications.
Map functional applications to service components to create the business service
models. See Figure 7-3 for an example of functional applications mapped to a
business service.
113
Identifying IT services
To identify IT services, consult IT managers and staff. Disaster recovery plans, help
desk documents, and purchase orders might be useful in identifying IT
components and the business processes that they support.
The process involves identifying the list of IT assets (components). Interview the
IT management and staff, or use an asset database or CMDB as resources:
Create a list of IT services and discover what IT services are offered to business
units through use of IT assets. Examples of IT services include customer support
and customer call monitoring.
NOTE
The Service Catalog component of the BMC Atrium Core Console depicts IT
services as Technical Services.
For each IT service, identify the IT components that support the service.
Identify the interdependencies among IT components and formulate a topology
map. Consider the relationships and dependencies between IT components.
As you build your model, use whatever tools you have to depict the dependencies
between business services and IT services. Use graphical and spreadsheet software
if you do not have a solution such as BMC Impact Solutions. Table 7-1 shows a
portion of a spreadsheet depicting a few business services and their relationships.
Table 7-1: Portion of a sample business service model spreadsheet
Business service
Business functions Business processes IT services
IT component
24/7 online
banking
Transfer funds
Software applications,
application servers, virtual
machines, databases
Pay bills
Discount equity
services
Execute trades
Manage
customer
relations
Front office sales
Operational
efficiency
Administrative
software and
hardware
Response
management
Incident tracking Application server

software
Customer support Support service

requests
FTP
Server: FTP
Sprint
Server: Walrus
Sales Logix
Database: SALLOG
Applications: Sales Logix
User group: Tech Support dept
Servers: Antelope
114
Defining the service model

Defining the service model involves establishing a list of all the IT resources that
should be represented in the service model. This information should include:
Each resources name or component identification pattern

Its location or site
Use this information later in the design phase and when creating service model
components.
The first step in developing a service model is to design its logical architecture. To
do this, you must analyze the IT environment to:
Identify the resources that make up the service model.

Determine the functional relationships and dependencies between various
resources that can affect services.
For information about using the Service Catalog in the BMC Atrium Core Console,
see the BMC Atrium CMDB 7.6.03 Administrator's Guide. For information about
how to create CIs, see the BMC Atrium CMDB 7.6.03 User's Guide.
115
116
Chapter
Implementing BMC Atrium

Core
This section describes the tasks necessary to implement your BMC Atrium Core
solution end-to-end, including configuring permissions, bringing data into to
BMC Atrium CMDB, and reconciling that data into the production dataset for
consuming applications.
NOTE
For a video demonstration of the core pieces of this process, see BMC Atrium Core
7.6.03: Taking Your Data Into Production End to End, available on your
documentation media.

Overview of the process to implement BMC Atrium Core (page 118)

Configuring permissions and multitenancy (page 119)
Configuring the Product Catalog (page 123)
Configuring the data model (page 125)
Creating datasets (page 126)
Configuring BMC Atrium Integration Engine for data import (page 127)
Configuring normalization (page 130)
Configuring reconciliation (page 131)
Creating the service model (page 133)
Importing data to BMC Atrium CMDB (page 135)
Best practices for specific implementation scenarios (page 140)
Chapter 8 Implementing BMC Atrium Core
117
Overview of the process to implement BMC

Atrium Core
To implement BMC Atrium Core, complete this ordered series of procedures. Each
procedure is explained in its own section, which also describes best practices.
However, the purpose of this section is not to provide the detailed steps for each
procedure, which are given in the referenced documents. Instead, this section lays
out the order of the procedures and reveals important points for the overall
process. In doing so, it uses the following diagram to focus attention on the
particular point in the context of the whole process.

1 Configure permissions
and multitenancy
6 Configure
reconciliation
2 Configure the
Product Catalog
7 Create the
service model
3 Configure the
data model
4 Create
datasets
8 Configure BMC Atrium

Integration Engine
5 Configure
normalization
9 Import data to
BMC Atrium CMDB
Some of these steps might not be relevant to your situation, and you can perform
some in a different order from that shown in this process.
Step 1 Configure permissions and multitenancy for access to BMC Atrium Core
components, to classes and attributes, and to instances.

Step 2 Configure the BMC Atrium Product Catalog and the approved software and
hardware.
Step 3 Configure the data model as needed for imported data.
Step 4 Create datasets as needed for imported data.
Step 5 Configure BMC Atrium Integration Engine for importing data.
Step 6 Configure normalization for system defaults and individual datasets.
Step 7 Configure reconciliation.
Step 8 Create the service model that contains the services IT offers the business, and the
IT infrastructure CIs necessary to deliver services.

Step 9 Use discovery tools, BMC Atrium Integration Engine, and manual tasks to import
data into BMC Atrium CMDB.
118
Configuring permissions and multitenancy

and multitenancy
6 Configure
reconciliation
2 Configure the
Product Catalog
7 Create the
service model
3 Configure the
data model
4 Create
datasets

Integration Engine
5 Configure
normalization
9 Import data to
BMC Atrium CMDB
To start the end-to-end process, set up permissions for users who need access to
BMC Atrium Core applications. After completing the configuration tasks, verify
that the roles and permissions have access to the data as planned.
For more information about configuring permissions, see the BMC Atrium CMDB
Configuring roles
To give people access to components of the BMC Atrium Core solution, you must
complete the following steps:
Step 1 Open the Group form and create a BMC Remedy AR System regular group for
each level of access that you need defined. For example, create a regular group
(CMDBAdmin) to use for all your BMC Atrium Core administrators. You can also
reuse regular groups that you have previously created.
For general information about working with groups, see the BMC Remedy Action
Request System 7.6.03 Form and Application Objects Guide.
For detailed information about groups in the BMC Atrium Core solution, see the
BMC Atrium CMDB 7.6.03 Administrator's Guide.
Step 2 Append your regular group to a computed group (for example, CMDB Console
Admin Group).
For example, your Group Definition would now read:
"Administrator" OR "CMDBAdmin"
Step 3 (optional) Open the Roles form and map a group that you created in step 1 to the
Production state of the BMC Atrium Core roles that you want associated with that
group.
Many roles already have groups mapped to them. For example, the CMDB
Console Admin role is mapped out-of-the-box to the CMDB Console Admin
Group in the Production state.
NOTE
If a group is already mapped to the role, add your group to that computed group
instead of modifying the mapping.
119
For general information about working with roles, see the BMC Remedy Action
Request System 7.6.03 Form and Application Objects Guide.
For detailed information about roles in the BMC Atrium Core solution, see the
BMC Atrium CMDB 7.6.03 Administrator's Guide.
Step 4 Open the Users form and create BMC Remedy AR System users. In the Group List
field, select the regular groups associated with the access permissions needed by
each user.
NOTE
You cannot choose a computed group from the Group List field when creating a
user. This is why you had to create a regular group and then add it to the group
definition of the computed group.
For information about the BMC Remedy AR System license types to grant users of
BMC Atrium Core, see the BMC Atrium CMDB 7.6.03 Administrator's Guide. For
information about creating users, see the BMC Remedy Action Request System 7.6.03
Configuration Guide.
Configuring class and attribute permissions

Assign groups and roles with the following permissions on each class or attribute.
WARNING
Do not use BMC Remedy Developer Studio to change permissions on the class
forms and attribute fields. These permissions are overwritten the next time a
change is made to the class with the Class Manager.
Specify the following class permissions from the Permissions tab when viewing a
class (in the Class dialog box) from the Class Manager:
HiddenMembers of these groups and roles can access the class through
workflow, but cannot see its instances in the Atrium Explorer or open its form.
VisibleMembers of these groups and roles can see and access the class in all
ways: instances in the Atrium Explorer, the class form, and through workflow.
Specify the following attribute permissions from the Permissions tab when
viewing an attribute (in the Attributes dialog box) from the Class Manager:
ViewMembers of these groups and roles can view the attribute in the class
form, but cannot modify its value.
ChangeMembers of these groups and roles can view and modify the attribute
value.
You can also specify that a user without Change permissions can set the attributes
value when creating an instance. To do so, select the Allow Any User to Submit
option.
For more information about class and attribute permissions, see the BMC Atrium
CMDB 7.6.03 Administrator's Guide.
120
In version 7.6.03, the Normalization Engine can now normalize attribute

permissions. For instructions on configuring this, see the BMC Atrium CMDB
7.6.03 Normalization and Reconciliation Guide.
Configuring instance permissions

In addition to the CMDB Data View and CMDB Data Change roles, you can control
access to contents of instances with the following attributes:
CMDBRowLevelSecurityUsers
CMDBWriteSecurityUsers who are members of a group with write access have
who are members of a group with row-level

access have permission to view the instance if they also have the BMC Atrium
Core CMDB Data View or BMC Atrium CoreCMDB Data Change role.
permission to modify the instance if they also have row-level access and the
BMC Atrium Core CMDB Data Viewer role. This permission is useful for giving
someone write access to a specific instance without giving write access to all
instances with one of the BMC Atrium CoreCMDB Data Change roles.
To set permissions for an instance, when creating or modifying an instance, set the
value of the CMDBRowLevelSecurity or CMDBWriteSecurity attribute to a group name
or list of group names.
With default instance permissions, you can also define the BMC Atrium
CoreCMDBRowLevelSecurity and BMC Atrium CoreCMDBWriteSecurity values for an
entire class instead of specifying them every time you create an instance of the
class. To set default permissions for a class, use the
BMC.CORE.CONFIG:BMC_DefaultAccountPermissions form to assign groups to
the ASSIGNRowLevelSecurity and the ASSIGNWriteSecurity fields.
For more information about configuring instance permissions and examples, see
the BMC Atrium CMDB 7.6.03 Administrator's Guide.
In version 7.6.03, the Normalization Engine can now normalize instance
permissions. For instructions on configuring this, see the BMC Atrium CMDB
Configuring multitenancy
This section describes the high-level steps to configure multitenancy. You can
apply these steps to configure multitenancy in multiple ways, including:
Using BMC Remedy ITSM, as described in the BMC Remedy IT Service

Management 7.5 Guide to Multi-Tenancy.
Using the Product Catalog, as described in the BMC Atrium Core 7.6.03 Product
Catalog and DML Guide.
To configure multitenancy, complete the following high-level steps. For detailed
information about configuring multitenancy, see the BMC Atrium CMDB 7.6.03
121
Step 1 Select the tenancy mode.

Step 2 Configure companies to represent the business units of your organization.
Step 3 Configure access for people.
Selecting the tenancy mode

The value that you select in the Tenancy Mode field on the System Settings form
determines whether the Company field on various forms defaults to a single
company or whether users must always select the appropriate company for the
field. BMC Remedy ITSM is installed with the Tenancy Mode field set to
Multitenancy. If you have changed this field to single-tenancy mode, you must
change the value back to Multitenancy. For information about changing this
setting, see BMC Remedy IT Service Management 7.5 Guide to Multi-Tenancy.
NOTE
In BMC Atrium CMDB, the multitenancy feature is always available. Regardless
of the Tenancy Mode setting, data is segregated by company and access to data is
controlled by a users access to a company.
Configuring companies to represent business units

To segregate products by business unit, create companies to represent the business
units. For example, in the Company form, Calbro Services enters Finance in the
Company field for the finance department. Similarly, separate companies are
created for HR and IT.
Configuring access for people

Use the People form to grant people access to business units. Calbro Services uses
the People form to grant access as follows:
Patrick Paycheck is granted access to Finance.

Betty Benefits is granted access to HR.
Steve Server is granted access to all applications, including those used by
Finance and HR.
122
Configuring the Product Catalog
Configuring the Product Catalog

and multitenancy
6 Configure
reconciliation
2 Configure the
Product Catalog
7 Create the
service model
3 Configure the
data model
4 Create
datasets

Integration Engine
5 Configure
normalization
9 Import data to
BMC Atrium CMDB
To set up the Product Catalog, complete the following procedures. For more
information about Product Catalog concepts, see Product Catalog on page 96.
Step 1 Create Product Catalog entries.
To normalize CIs, you must have product entries in the Product Catalog. Import
or create these products as needed.
Step 2 (optional) Configure the best-practice categorizations.
Step 3 Approve products, versions, and patches for your organization.
You must approve products so that the Normalization Engine can normalize CIs.
Creating Product Catalog entries

You can add products to the Product Catalog in the following ways:
Import data from external filesYou can import data from an external file or
from staging forms by using a browser. For more information, see the BMC
Atrium Core 7.6.03 Product Catalog and DML Guide.
Create entries manually from the Product Catalog Console. For more
information, see the BMC Atrium Core 7.6.03 Product Catalog and DML Guide.
Use the Normalization Engine to create entriesIf you have a dataset that is
trusted and contains CIs that were normalized before being imported, you can
configure the Normalization Engine to create Product Catalog entries from the
dataset. You must configure this option before normalizing the dataset. For
detailed instructions about creating Product Catalog entries, see the BMC
Atrium CMDB 7.6.03 Normalization and Reconciliation Guide.
TIP
The Normalization Engine is mainly for normalizing CIs, not populating the
Product Catalog with product entries. Because this option is set for a dataset, all
CIs in that dataset must be previously normalized by some other method before
you run a Normalization Engine job with this option enabled. Otherwise, you
could create non-normalized Product Catalog entries and result in duplicate
entries for the same product.
123
If you acquire duplicates in the Product Catalog, you must manually remove them.
A clue that indicates you have duplicates is that not all CIs for a specific product
have the same Name, ManufacturerName, Model, PatchNumber, VersionNumber,
Category, Type, and Item values.
Configuring best-practice categorizations

Product categorization is defined in the BMC Atrium Product Catalog and with
BMC Atrium Discovery and Dependency Mapping. If you already use BMC
Atrium Discovery and Dependency Mappingwhich applies some of the bestpractice categorizations and some othersor you already use the default, or
legacy, categorizations with BMC BladeLogic Client Automation Configuration
Discovery Integration for CMDB, continue to use those categorizations. Otherwise,
you should implement the best-practice categorizations.
Best practice
Implement the best-practice categorizations using the following methods:
Use the BMC Remedy ITSM Data Wizard

Select categorizations during the installation of BMC BladeLogic Client
Automation Configuration Discovery Integration for CMDB
Changing categorizations with the BMC Remedy ITSM

Data Wizard
To configure the Product Catalog and BMC Remedy ITSM to use the best-practice
categorizations, use the BMC Remedy ITSM Data Wizard, which is installed when
at least one BMC Remedy IT Service Management application is installed.
WARNING
Before using the data wizard, back up your database.
To maintain data integrity while modifying the categorizations, disable
escalations, reconciliation jobs, discovery products, and the Distributed Server
Option (DSO) of BMC Remedy AR System. When you have completed modifying
the product categorizations, you can restart these components.
From the BMC Remedy ITSM Data Wizard, select to modify the product
categorization and map the current categorization values in the target fields and
the best-practice categorizations in the new value fields.
For more information about using the ITSM Data Wizard, see the BMC Remedy IT
Service Management 7.5.00 Data Management Administratorss Guide.
124
Configuring the data model
Selecting categorizations during installation of BMC

BladeLogic Client Automation Configuration Discovery
Integration for CMDB
When you install BMC BladeLogic Client Automation Configuration Discovery
Integration for CMDB, select either the default categorization or the best-practice
categorization. The selected categorization is stored in a local XML file.
When BMC BladeLogic Client Automation discovers a CI, it tries to find a match
in the BMC Atrium Product Catalog. If it finds a match, it applies the Product
Catalog values of the Model, ManufacturerName, Model, Category, and Item
attributes. If it does not find a match in the Product Catalog, it tries to find a match
in the XML file selected at installation, and applies those categorization values to
the CI.
Approving products, versions, and patches

As a part of managing your products, approving products in the Product Catalog
is important for normalizing products. By default, the Normalization Engine does
not update or allow the creation of unapproved CIs, and all products in the
Product Catalog are unapproved by default. If you allow normalization of
unapproved CIs, the Normalization Engine sets the NormalizationStatus
attribute for such CIs to Normalized Not Approved.
For information about approving products versions and patches, see the BMC
Atrium Core 7.6.03 Product Catalog and DML Guide.
Configuring the data model

and multitenancy
6 Configure
reconciliation
2 Configure the
Product Catalog
7 Create the
service model
3 Configure the
data model
4 Create
datasets

Integration Engine
5 Configure
normalization
9 Import data to
BMC Atrium CMDB
This section aligns with Stage 4, Step 23, Task 2. Configure the CMDB, of the
Step-by-Step Guide to Building a CMDB.
The BMC Atrium CMDB data model unifies the representation of configuration
data. It is designed to store data about the most common CIs such as hardware,
software, and services, to provide a complete view of all elements of an IT
environment and how they affect each other.
125
The Common Data Model includes classes that describe a wide variety of IT
configuration items and their relationships, and some BMC Software products
install extensions that add more classes and attributes to the data model. But there
are still some IT infrastructures that do not completely map to this model.
If the classes and attributes that you require are not defined by the BMC Atrium
CMDB data model or the extensions, modify the data model.
For detailed information about what to consider before modifying the data model,
see Planning to extend the data model on page 59.
Creating datasets
and multitenancy
6 Configure
reconciliation
2 Configure the
Product Catalog
7 Create the
service model
3 Configure the
data model
4 Create
datasets

Integration Engine
5 Configure
normalization
9 Import data to
BMC Atrium CMDB
Creating datasets in BMC Atrium CMDB to store data provided by different data
providers is the first step when importing data. A dataset is a logical grouping of
data. It can represent data from a particular source, a snapshot from a particular
date, or other purpose.
Make sure that each data provider has its own import dataset.
Also, note which dataset is your production, or golden, dataset so that you can
plan your normalization and reconciliation jobs. By default, the BMC.ASSET dataset
is the production dataset. In reconciliation, the production dataset is used first to
identify duplicate CIs, matching attributes for the CI in the production dataset
with the CIs in the imported datasets. Second, it can be the target dataset in a
Merge activity so that the CIs are updated to keep the production dataset current
and accurate. Also, do not normalize the production dataset because you should
normalize CIs before identifying and merging them.
When you need to merge more than one dataset at time, you might want to create
an intermediate dataset for merging. For better performance and to minimize the
impact on users of the production dataset, BMC recommends that you merge one
import or discovered dataset at a time with the production dataset. You might
want to merge multiple source datasets in separate jobs to an intermediate dataset
and then merge the intermediate dataset with the production dataset.
For more information about planning your datasets, see Grouping CIs into
datasets on page 77.
For detailed instructions about creating a dataset, see the BMC Atrium CMDB
126
Configuring BMC Atrium Integration Engine for data import
Configuring BMC Atrium Integration Engine

for data import
and multitenancy
6 Configure
reconciliation
2 Configure the
Product Catalog
7 Create the
service model
3 Configure the
data model
4 Create
datasets

Integration Engine
5 Configure
normalization
9 Import data to
BMC Atrium CMDB
Using BMC Atrium Integration Engine to import data into BMC Atrium CMDB
from a third-party source consists of the following tasks:
Step 1 Populate database field menus.
Step 2 Create data mappings.
Step 3 Create data exchanges.
TIP
To help you create exchanges, use the sample exchanges and data mappings that
are installed with the BMC Atrium Integration Engine.
Best practices
When configuring BMC Atrium Integration Engine, consider the following best
practices:
Transform your data on the way in so that all sources (BMC and third-party) are
normalized for commonly used attributes like Domain and those related to
memory and disk size.
For example, DriveSize for BMC_Media should be specified in GB. For more
information about attributes, see BMC Atrium CMDB 7.6.03 Data Model Help
and Class Manager.
Provide data to help reconciliation by ensuring that CI attributes used for

identification have unique values and are populated consistently.
Familiarize yourself with the Common Data Model prior to creating data
mappings so that you can select the appropriate classes and attributes. You can
also verify that data types match for the data mappings and plan unique
identifying fields.
Consider bringing in data by chunks and designating separate BMC Atrium

Integration Engine instances for such activity so that, if you have a large amount
of data to import, you can spread the import work across multiple instances.
127
Do not run more than one BMC Atrium Integration Engine, Normalization
Engine, or Reconciliation Engine job at the same time because they might query
or update the same data.
Map the attributes that the Normalization Engine uses to normalize CIs: Name,
ManufacturerName, Model, PatchNumber, and VersionNumber.
If you do not map

these attributes, then the Normalization Engine cannot normalize the CIs.
Populating database field menus

BMC Atrium Integration Engine uses the Database Field Menus Console to
populate field menus that you use when creating data mappings. The field menus
enable you to choose the fields from your external data store from a list instead of
typing them manually.
NOTE
Populating database field menus is necessary only if your external data store is a
database.
For detailed instructions about populating database field menus, see the BMC
Creating data mappings

A data mapping defines how data in the source data store corresponds to data in
BMC Atrium CMDB and which actions to take when transferring data between
them. That is, data mappings explicitly define the mapping between columns in
the source data store and the attributes of a BMC Atrium CMDB CI or relationship
class.
For more information about the BMC Atrium CMDB classes and attributes that
you can use to create data mappings, see the BMC Atrium CMDB 7.6.03 Data
Modeling Guide, BMC Atrium CMDB 7.6.03 Data Model Help, and BMC Atrium
CMDB 7.6.03 Common Data Model Diagram.
Creating data mappings for CI classes

You must create a data mapping to a CI class in BMC Atrium CMDB for each table
or view in the external data store that contains CIs you want to transfer.
For detailed instructions about creating data mappings for CI classes, see the BMC
Creating data mappings for relationship classes

Much of the value of using BMC Atrium products comes from their ability to store
information about the relationships between CIs, not just information about the
CIs themselves. A data mapping to a relationship class in BMC Atrium CMDB
must be created for each type of relationship that exists between the CIs that you
want to transfer.
128
Configuring BMC Atrium Integration Engine for data import
You can create the data mapping for a relationship class based on attributes in the
CI classes or based on relationship data stored in an external data store. The
decision to use attributes in CI classes or relationship data in an external data store
is based on the structure of your source data.
For detailed instructions about creating data mappings for relationship classes, see
the BMC Atrium Integration Engine 7.6.03 User's Guide.
Creating data exchanges

A data exchange is a set of rules that define how data is transferred between an
external data store and BMC Atrium CMDB. When transferring data into BMC
Atrium CMDB, you normally populate multiple CI classes and the relationship
classes that connect them.
Best practices
Create one data exchange for a CI class that acts as the source member of several
relationships, such as BMC_ComputerSystem. Run this exchange on a schedule.
Create a secondary data exchange for each CI class that is related to the first CI
class, such as BMC_DiskDrive. Trigger each of these secondary data exchanges
to run simultaneously, using a different BMC Atrium Integration Engine
instance after the first data exchange finishes.
For each secondary data exchange, create another data exchange that transfers
relationships between the source and destination CI classes. Trigger the
relationship data exchange to run when the secondary data exchange finishes.
This approach transfers data in order so that each piece that is needed on the target
side by another exists at the correct time.
For detailed instructions about creating data exchanges, see the BMC Atrium
Integration Engine 7.6.03 User's Guide.
129
Configuring normalization
and multitenancy
6 Configure
reconciliation
2 Configure the
Product Catalog
7 Create the
service model
3 Configure the
data model
4 Create
datasets

Integration Engine
5 Configure
normalization
9 Import data to
BMC Atrium CMDB
To configure normalization, complete the following procedures. For more

information about normalization, see Normalization on page 95. For detailed
instructions about these procedures, see the BMC Atrium CMDB 7.6.03
Step 1 Configure the normalization settings for datasets, including disabling any
Normalization Features (enabled by default) that should not run.

Define custom rules where needed, such as for Version Rollup or permissions. You
might need to configure other dataset parameters according to best practices. See
Best practices for specific implementation scenarios on page 140.
Step 2 If you have created custom classes, you must add and configure them for
normalization.
Normalization is not supported for classes that are not derived from
BMC_BaseElement.
Step 3 If you know that the product or manufacturer names for CIs in your dataset do not
match those in the Product Catalog, map the incorrect names to the correct ones
with the Product Name Alias form.
Step 4 Create categorization aliases with Catalog Mapping for the following conditions:
If the combination of the values of the Name, ManufacturerName, Model, Category,

Type,
and Item attributes is not in the Product Catalog data.
If the combination of values is in the Product Catalog but is not related to the
company for whom the CI is being submitted.
Step 5 Create a job, and specify when the job runs (continuous or batch).
WARNING
Do not run more than one BMC Atrium Integration Engine, Normalization Engine,
or Reconciliation Engine job at the same time. This could cause problems such as
multiple jobs querying or updating the same data.
130
Configuring reconciliation
Configuring reconciliation
and multitenancy
6 Configure
reconciliation
2 Configure the
Product Catalog
7 Create the
service model
3 Configure the
data model
4 Create
datasets

Integration Engine
5 Configure
normalization
9 Import data to
BMC Atrium CMDB
This section aligns with Stage 4, Step 23, Task 4. Code data import scripts and
reconciliation rules, of the Step-by-Step Guide to Building a CMDB. To configure
reconciliation, complete the following procedures. For detailed instructions, see
the BMC Atrium CMDB 7.6.03 Normalization and Reconciliation Guide.
Step 1 Verify standard Identify rules.
Check that the attributes used for identification have unique and consistent
values in the dataset to be reconciled.
If you created custom classes, add them to the standard Identify rules.
Step 2 Verify standard Merge rules.
Check that the dataset has the needed precedence value. By default, new
datasets have a precedence of 100.
If you created custom classes and attributes, add them to standard Merge rules.
Step 3 Create a standard identification and merge job.
If needed, you can customize a Standard Identification & Merge job:
Include a qualification.
Change Continue on Error and Sequence for the activity.
Change identification settings for Production Dataset, Generate IDs, and
Exclude Subclasses.
Change merge settings for the Source Dataset, Target Dataset, Precedence
Association Set, Include Unchanged CIs, and Merge Order.
To customize the Identify and Merge rules, see if you can modify the standard
rules. If modifying the standard rules is not possible, you can create a custom
reconciliation job with custom rules as needed.
Step 4 Specify when the job runs, either with a schedule or by using continuous mode.
131
WARNING
Do not run more than one BMC Atrium Integration Engine, Normalization Engine,
or Reconciliation Engine job at the same time. This could cause problems such as
multiple jobs querying or updating the same data.
Best practices
When you configure reconciliation, consider the following best practices:
Use a Standard Identification & Merge Job if possible.

Test with a small amount of representative data by using a qualification.
Do not run during prime (heavy use) hours.
Consider indexing attributes used in Identify rules. Consult your database
administrator to determine what indexes would help you.
Create all your reconciliation definitions at the highest class level possible to
take advantage of inheritance.
After the initial data load into BMC Atrium CMDB, perform an Identify activity
on the data, selecting the option to auto-identify the master dataset. This makes
sure that your production data has an identity the first time it is identified
against another dataset.
Take advantage of Reconciliation Engine multithreading by breaking up large

jobs into smaller ones and running them concurrently, but limit your number of
concurrent threads to twice the number of CPUs in the server.
To avoid redundant processing, make all Merge activities incremental by setting

Force Attribute Merge to No.
To improve performance, define a private queue on the BMC Remedy

AR System server for use only by the Reconciliation Engine. Make sure you use
RPC socket 390698 or 390699.
Reconcile discovered data into your production dataset immediately after your
discovery application loads data into BMC Atrium CMDB.
Do not create multiple jobs that merge data into the same target dataset, because
this creates the potential for one job to overwrite data that you want to keep. To
split a merge into multiple jobs, do it by classes so that the two jobs do not touch
the same parts of your data.
Regularly review your Identify rules to make sure that they are still appropriate
for your environment, and spot-check instances to confirm that they are being
identified properly.
Instead of merging multiple discovery sources directly into your production

dataset, merge them into a consolidated discovery dataset first. You can
compare this against your production dataset and use the results to generate
change requests or exception reports for any discrepancies.
132
Creating the service model
Creating the service model

and multitenancy
6 Configure
reconciliation
2 Configure the
Product Catalog
7 Create the
service model
3 Configure the
data model
4 Create
datasets

Integration Engine
5 Configure
normalization
9 Import data to
BMC Atrium CMDB
The service modeling process helps you identify your business services and how
those services are delivered and supported by your IT framework. While the
process of creating your service model enables you to view your business services
in the context of all your business processes, the service model is more useful if you
use it to manage the impacts of events on your business services. For example, you
can use the Atrium Impact Simulator to determine how business services would
be impacted by taking a server offline to upgrade software.
Using BMC Impact Solutions to create a service model

The applications that make up BMC Impact Solutions help you build and use a
service model. Those tools also enable you to manage impacts of events on your
business services. For example, the Service Catalog represents the service model as
individual resources represented by component instances. A component instance
is created through BMC Impact Service Model Editor as a single instance of a class
that is defined in BMC Atrium CMDB. Classes can identify such physical
components as servers or databases, and such logical components as user groups.
Whether you have implemented BMC Impact Solutions in your environment or
not, Atrium Impact Simulator and the Service Catalog offer additional ways to use
your service model.
133
Deciding on the structure of the service model

How you organize service model components depends on the goals that your
organization wants to attain through Service Impact Management, so determine
those goals first. You can organize your service model components by using one of
these basic organizational strategies:
The business continuity and service availability strategy implements a businesscentric model in which business processes and services rely on a small number
of vital IT components to give a status overview of the underlying environment.
This type of implementation is driven from the top, ensuring that IT is
delivering their services as agreed. The driving force is business continuity and
availability. This strategy is similar to the BMC Software BSM strategy that is
called a Business Service Impact Model.
The business-focused operational efficiency strategy creates a balanced

representation of the operational environment, encompassing the IT
components, such as systems and applications, and the logical components,
such as services, user groups, and other business objects. This type of
implementation is likely to involve various populations and loci of management
in the enterprise. The driving force is operational efficiency, but with a balanced
business perspective.
The IT resource management strategy creates a thin layer of logical groupings

on top of a large number of IT resources, ranging from applications and systems
to hard disks and other hardware components. This type of implementation is
run by and for the IT group. Services are just logical groupings that provide a
convenient way of classifying the technical resources. The driving force behind
this model is operational efficiency.
Although these strategies are only briefly outlined here, they are helpful in
understanding that each implementation probably has a different focus, favoring
some types of components and having more or less granularity in some branches
of the component hierarchy. The strategy that you choose also affects the amount
of time and effort required for its development and implementation.
For more information about service models as used in BMC Service Impact
Manager, see the BMC Impact Solutions: Service Model Administrators Guide. For
more information about Atrium Impact Simulator, see the BMC Atrium CMDB
7.6.03 User's Guide. For more information about the Service Catalog, see the BMC
Atrium CMDB 7.6.03 Administrator's Guide.
Maintain your service model dynamically

BMC Atrium CMDB has a dynamic service modeling feature that can
automatically relate technical services in your Service Catalog to infrastructure
CIs, such as computer systems, that support them. BMC recommends that you take
advantage of this feature to enable you to better manage your services.
For instructions on configuring dynamic service modeling, see the BMC Atrium
CMDB 7.6.03 Administrator's Guide.
134
Importing data to BMC Atrium CMDB

and multitenancy
6 Configure
reconciliation
2 Configure the
Product Catalog
7 Create the
service model
3 Configure the
data model
4 Create
datasets

Integration Engine
5 Configure
normalization
9 Import data to
BMC Atrium CMDB
Populating BMC Atrium CMDB includes activities such as importing and filtering
data and verifying that each data import is successful. To import data into BMC
Atrium CMDB, complete the following procedures:
Step 1 Create tests to validate your data population.
Step 2 Bring data into BMC Atrium CMDB using BMC Software discovery products.
Step 3 Import data using BMC Atrium Integration Engine.
Step 4 Add data manually.
Step 5 Validate the results of your data imports.
Step 6 Remove failed-import data from BMC Atrium CMDB.
Step 7 Normalize BMC Atrium CMDB data.
Step 8 Reconcile BMC Atrium CMDB data.
Best practices
As you prepare to migrate data from existing sources to BMC Atrium CMDB,
consider these best-practice recommendations:
Examine your data to make sure that data exists in each category of your current
classification scheme that is being mapped to a class in BMC Atrium CMDB. Do
not waste resources attempting to migrate something that does not exist.
Freeze your current classification scheme a few weeks prior to the migration.
Test the migration with a representative subset of all the classes you plan to use.
For example, import 1,000 computer systems and 1,000 application systems.
When testing, verify both that the contents of several CIs were migrated
correctly and that the correct number of CIs were migrated for each class.
For better performance, take advantage of the multithreaded nature of the BMC
Remedy AR System server when loading your initial data into BMC Atrium
CMDB. Either use a multithreaded process on your loading application or split
the data into pieces that can be loaded by separate instances of your application.
If your loading application will do any searching, create indexes on the fields it
searches.
135
An easy way to load data from many sources is to create BMC Remedy
AR System view forms or vendor forms that point to those sources. You can
then use workflow, such as an escalation, to transfer the data from those forms
to the BMC Atrium CMDB forms.
When importing data from a source such as a spreadsheet or comma-separated

value file, you can use a regular BMC Remedy AR System form as an
intermediate storage location. This enables you to use qualifications and
workflow to verify that the data made it into the BMC Remedy AR System,
normalize the text in your data, and route it to the appropriate BMC Atrium
CMDB class.
If your source data does not include relationships or includes them only as
foreign keys on CI records, your loading application should analyze the data
and create relationships between appropriate CIs in BMC Atrium CMDB.
Your loading application is responsible for normalizing text in the data you
bring into BMC Atrium CMDB, such as enforcing capitalization and delimiting
rules. Data that has not been normalized is much harder to reconcile.
Creating test cases to validate data population

This section aligns with Stage 4, Step 23, Task 1. Create use cases to validate data
population, of the Step-by-Step Guide to Building a CMDB.
As you prepare to import data into BMC Atrium CMDB, create test cases to verify
that the data is being imported successfully. Specifically, test unidirectional and
bidirectional data transfers to make sure that the synchronization and import
processes between the external data store and BMC Atrium CMDB are working
correctly.
You should also test the end-to-end run time of import, normalization, and
reconciliation using a small amount of representative data. This enables you to
plan your time windows so that these activities dont overlap in either your initial
bulk load or subsequent updates.
Examples of test cases that you can use include the following scenarios:
Creation of new CIs with related attributes and relationships

Creation of relationships for existing CIs
Modification of CI attributes and relationships
Data reconciliation and merging
Deletion of any combination of CI attributes and relationships
Bringing data into BMC Atrium CMDB using discovery tools

BMC Software discovery products, such as BMC Atrium Discovery and
Dependency Mapping and BMC BladeLogic Client Automation automatically
discover the CIs in your IT environment and populate that data into BMC Atrium
CMDB datasets. If you are using these products, begin using them to bring data
into BMC Atrium CMDB.
136
Importing data using BMC Atrium Integration Engine

This section aligns with Stage 4, Step 23, Task 5. Perform data import, of the
You have already configured your data mappings and data exchanges as
described in Configuring BMC Atrium Integration Engine for data import on
page 127. At this point in the end-to-end process, run your data exchanges and
bring the associated data into BMC Atrium CMDB.
For detailed instructions about running jobs, see the BMC Atrium Integration Engine
Adding data manually

This section aligns with Stage 4, Step 23, Task 9, Input additional data manually,
of the Step-by-Step Guide to Building a CMDB. Although you are discovering CIs
and their attributes automatically through discovery, you might need to manually
enter additional data in the following situations:
You want to add CIs that are not discovered. Some functions of BMC Remedy
Asset Management, such as creating a purchase requisition, create a CI, even if
the CI might later be discovered.
You want to update CIs with attributes that are not discovered.
You must manually add business services that are used in the Service Catalog.
You want to create relationships that are not discovered.
You want to enter additional Asset Management information.
Do not edit CIs directly in the BMC.ASSET dataset. Instead, use Atrium Explorer
and the sandbox dataset to add and modify CIs and relationships. This makes sure
that edits are reconciled and the production dataset accurately represents your
environment. These changes are ultimately used by consumers such as BMC
Remedy Asset Management.
Adding CIs to BMC Atrium CMDB manually

Some CIs are not discovered, so plan to enter some CIs manually. Without
planning, ad hoc entry of CIs can lead to inconsistency in your CMDB. If the CIs
are not discovered, reconciliation with discovered CIs is not an issue.
For instructions about manually entering CIs, see the BMC Atrium CMDB 7.6.03
User's Guide.
137
Updating CIs with attributes

To maintain CI attributes that are not discovered, such as asset lifecycle dates or
cost, you can also enter them manually. You can also manually update attributes
that are populated by discovery. For example, if a video card is being repaired, you
might want to change the status from Deployed to In Repair.
If you manually update attributes that are populated by discovery, these attributes
might get reset during reconciliation, based on precedence rules. Because the BMC
Asset dataset is the production dataset, changes made to this dataset take
precedence over attributes that are discovered.
For instructions about manually updating attributes on CIs, see the BMC Atrium
CMDB 7.6.03 User's Guide.
Adding relationship information that is not discovered

You might want to create relationships that are not discovered, such as people and
support groups responsible for an asset or relationships of business services.
For instructions about manually entering relationship information, see the BMC
Atrium CMDB 7.6.03 User's Guide.
Validating data import results

This section aligns with Stage 4, Step 23, Task 6. Validating import results, of the
Follow the test cases that you created in Creating test cases to validate data
population on page 136 to verify that your data has been imported correctly.
Use the BMC Atrium Integration Engine job monitoring console to confirm
whether a data transfer between the BMC BladeLogic Client Automation database
and BMC Atrium CMDB has finished successfully. You can also check log files. By
default, the generation of debug logs for BMC Atrium Integration Engine data
transfers is enabled. On Windows, the log files are stored in the
installationDirectory\BMC Atrium Integration Engine\ service\log\
directory.
For more information about logging, debugging, and job monitoring, see the BMC
Removing failed-import data from BMC Atrium CMDB

This section aligns with Stage 4, Step 23, Task 7. Removing failed import data
from the CMDB, of the Step-by-Step Guide to Building a CMDB.
If your test cases detected a problem with a data transfer, remove the erroneous
data from the BMC.IMPORT.CONFIG dataset or the BMC.ADDM dataset.
138
Normalizing BMC Atrium CMDB data

Normalize your data to resolve the differences in naming and typing ahead of
reconciliation. For more information about the Normalization Engine, see
Normalization on page 95 and the BMC Atrium CMDB 7.6.03 Normalization and
Reconciling BMC Atrium CMDB data

Reconcile your BMC Atrium CMDB data to compare expected data against
discovered data, and to create one complete and correct production dataset.
Reconciliation must begin by identifying the matching instances in all datasets.
After they have been identified, you can perform several activities on the matching
instances, but the most common are:
Comparing them and either creating a report on the differences or executing

workflow against them
Merging them into a new dataset based on precedence values that you have
defined for each source dataset
For details about reconciliation activities, see the BMC Atrium CMDB 7.6.03
How Calbro Services discovers their IT environment and imports data

In the process of consolidating their IT departments, Calbro Services plans to
populate BMC Atrium CMDB with the data from the various IT departments.
Some IT data resides in spreadsheets or in databases. In some cases, data must be
discovered. This disparate data from various IT departments must be moved to
BMC Atrium CMDB so that Calbro Services has a complete picture of the
components in its IT department.
Calbro Services has some existing data in flat files in CSV format. The data in these
files will be transferred to BMC Atrium CMDB with BMC Atrium Integration
Engine.
The remaining data will be discovered with BMC discovery tools.
Calbro Services will use BMC BladeLogic Client Automation to discover

hardware and software inventory information about servers, desktops, laptops,
and handheld devices. Calbro Services will then use BMC BladeLogic Client
Automation Configuration Discovery Integration for CMDB to map the
collected information and transfer the CIs and their relationships to BMC
Atrium CMDB.
Calbro Services will use BMC Atrium Discovery and Dependency Mapping to
build a topology of applications and infrastructure including switches, servers,
operating systems, software, configuration files and logs, business applications
and dependencies. Calbro Services will then use the CMDB Sync function of
BMC Atrium Discovery and Dependency Mapping to map the collected
information and transfer the CIs and their relationships to BMC Atrium CMDB.
139
Best practices for specific implementation

scenarios
For specific scenarios, BMC recommends particular settings for BMC Atrium
Integration Engine, Product Catalog, Normalization Engine, and Reconciliation
Engine.
Best practice for scheduling

Importing your data into BMC Atrium CMDB, normalizing it, and reconciling it
must happen separately, so do not schedule any overlap in these processes. For
example, reconciliation will result in errors for a group of related CIs such as a
computer system and its components if not all of the CIs and relationships in the
group have yet been imported.
Best practices for bulk loads

When you are loading a large amount of data, such as an initial load, into BMC
Atrium CMDB, use the following guidelines. The objective is to provide a starting
point with normalized and reconciled data, using batch jobs. After a bulk load, you
can decide how to normalize changes to the data (batch, inline, or continuous
normalization).
Table 8-1: Best practices for bulk loads
140
Component
Tasks
BMC Atrium
Integration Engine
When transferring a large amount of data, use parallel

processing with a different BMC Atrium Integration Engine
instance per exchange.
For an attribute that is used as a primary key or as a
relationship key, create a separate index in
BMC_BaseElement.
Database/External Data Store can have an index on the
column that is the Primary Key.
Check the log files and confirm that there are no errors,
especially data errors.
Product Catalog
Verify that Product Catalog data is current and accurate.
Best practices for specific implementation scenarios
Table 8-1: Best practices for bulk loads

Component
Tasks
Turn on normalization across all datasets into which you are

loading bulk data.
Create a batch normalization job.
Use the batch job after the data is loaded into the import
dataset. Then, use the reconciliation batch job to merge the
normalized data to a different dataset.
Do not modify the default dataset configurations.
Note: Do not enable the Allow new Product Catalog entry
parameter because it could result in duplicate entries for the

same product.
Do not allow an installer to start normalization jobs because

the standard reconciliation Identify and Merge rules are not
sufficient to reconcile only normalized CIs.
Create a batch reconciliation job.

After the import dataset has been normalized, use the batch
reconciliation job to merge the normalized data to a different
dataset.
Best practices for incremental loads

After you have loaded initial data, use the following guidelines to normalize and
reconcile changes to the data.
Table 8-2: Best practices for incremental loads
Component
Tasks
BMC Atrium
Integration Engine
Check the log files and confirm that there are no errors,
especially data errors.
Product Catalog
Turn on normalization across all datasets into which you are

loading bulk data.
Create a continuous normalization job to normalize changes
and additions to the import dataset.
Do not modify the default dataset configurations.
Note: Do not enable the Allow new Product Catalog entry
parameter because it could result in duplicate entries for the

same product.
Create a continuous reconciliation job.

After the initial reconciliation, the continuous job identifies and
merges new and changed CIs in the import dataset.
141
Best practices for Atrium Explorer edits

When modifying CIs in Atrium Explorer, use the following guidelines. When you
promote a CI, it is reconciled using a standard Identify and Merge job.
Table 8-3: Best practices for Atrium Explorer edits
142
Component
Tasks
BMC Atrium
Integration Engine
Not applicable
Product Catalog
Verify that Catalog Mapping aliases are current and accurate.

If normalization is turned off across all datasets, do not turn
on normalization.
Configure the normalization settings for the dataset where the
manual edits are made:
Normalization Type: Name & CTI lookup
Inline Normalization: Enabled
Allow Unapproved CI: Disabled
Allow new Product Catalog entry: Disabled
In the edit form that appears in a failed normalization, you
must know which attributes are required and what values are
valid.
If the Product Catalog has no entries for hardware or other
classes, disable normalization for those classes by deleting
them from the Class Configuration tab in the Configuration
Editor. You can add the class later, if needed.
Create a reconciliation job for the specific user sandbox to start

manually; do not create a schedule or select Continuous for the
job.
Best practices for specific implementation scenarios
Best practices for BMC Remedy ITSM manual edits

When modifying CIs from the BMC Remedy IT Service Management suite, use the
following guidelines.
Table 8-4: Best practices for BMC Remedy ITSM manual edits
Component
Tasks
BMC Atrium
Integration Engine
Not applicable
Product Catalog
Configure the normalization settings for the specific user

sandbox where the manual edits are made:

Normalization Type: Name & CTI lookup

Inline Normalization: Enabled
Allow Unapproved CI: Disabled
Allow new Product Catalog entry: Disabled
You can use the existing reconciliation job for the BMC Remedy
ITSM sandbox.
143
144
Chapter
Managing BMC Atrium Core
This section describes the administrative tasks that help you manage your
implemented BMC Atrium Core solution.
Tracking changes to CIs and relationships (page 146)

Deleting CIs that are no longer discovered (page 155)
Custom workflow (page 155)
Chapter 9 Managing BMC Atrium Core
145
Tracking changes to CIs and relationships

BMC Atrium CMDB takes advantage of the auditing feature of BMC Remedy
AR System to track changes to instance data. You enable BMC Atrium CMDB
auditing on a per-class basis, and you select which attributes trigger an audit and
which are written as a result.
An audit is triggered when an instance is created or deleted or when the value of
one or more selected attributes changes as the result of an instance being modified.
You can view audit results from the View History link on the BMC Atrium Core
Console. For instructions about viewing instance history, see the BMC Atrium
CMDB 7.6.03 User's Guide.
Auditing versus the Compare Dataset activity

Auditing is not the only way to track changes to CIs and relationships. If you use
BMC Remedy Asset Management with your CMDB, you could instead track
changes with the Compare Dataset reconciliation activity.
You must have the Sandbox dataset (BMC.ASSET.SANDBOX) enabled in BMC
Remedy Asset Management, so that user edits to a CI are saved to the Sandbox
dataset. Then you can create a reconciliation job with a Compare Dataset activity
that compares the Sandbox to BMC Asset, looking for the particular differences
that you want to catch. You could then perform custom workflow against
instances found by the comparison.
Best practices
Keep these considerations in mind when deciding which method to use for
tracking the changes to your CIs and relationships:
Audits give you access to information about changes to your data as soon as
they happen, whereas comparisons are usually run daily.
Audits take a small amount of processor and disk time at the moment a change
occurs, slightly slowing down real-time performance for users, whereas
comparisons concentrate that performance hit during a non-peak window.
If you have auditing enabled on your production dataset, it can increase the time
required for reconciliation because Merge activities that write to the dataset
trigger audits.
Audits provide a better long-term view of the history of a CI than do

comparisons.
Comparisons are better when you need to track changes to multiple attributes
because this has a larger performance cost, and the cost can be absorbed during
a non-peak window.
Comparisons provide flexibility in executing workflow when a change occurs.

Given these considerations, audits are usually better for keeping a history, and
comparisons are better for alerting you to changes that require investigation.
146
Types of auditing
You can audit by creating a copy of the instance that was created, modified, or
deleted, or by writing the changes to a log.
You cannot use Log auditing above Copy auditing in the inheritance tree. This
means that if you already have Copy auditing enabled for a class you cannot
enable Log auditing for any of its superclasses, and if you already have Log
auditing enabled for a class you cannot enable Copy auditing for any of its
subclasses. This is due to the structure of audit forms.
Best practices
Keep these considerations in mind when deciding whether to use Copy or Log
auditing:
Copy audits degrade performance more than Log audits because their structure
matches that of the actual BMC Atrium CMDB class forms, which use database
joins. Also, because those join forms must be created when Copy auditing is
enabled, there is a bigger performance cost at that time and possibly more
disruption related to your change control procedure.
Copy audits provide a more powerful search capability than Log audits because
you can search on each attribute in a separate field.
Copy auditing
Copy auditing creates a copy of each audited instance. When you enable Copy
auditing for a class, each form pertaining to that class is duplicated to create audit
forms that hold audited instances. This includes forms from superclasses, because
they hold data for instances of their subclasses. The audit forms are automatically
named with the suffix :AUDIT. For example, if you enable auditing for the
BMC_Person class, which is a subclass of the BMC_BaseElement class, three audit
forms are created:
Table 9-1: Audit forms created for BMC_Person
Form type
Class form
Audit form
Regular
BMC.CORE:BMC_BaseElement BMC.CORE:BMC_BaseElement:AUDIT
Regular
BMC.CORE:BMC_Person_
BMC.CORE:BMC_Person_:AUDIT
Join
BMC.CORE:BMC_Person
BMC.CORE:BMC_Person:AUDIT
The audit forms have the same BMC Remedy AR System permissions as the class
itself. If you make a change to a class after these forms have been created, they are
automatically updated to match. When you delete a class, its associated audit
forms are also deleted.
Each audit of each instance results in an entry in the audit form, so multiple entries
can be related to a given instance.
The audit form mirrors the class form, containing a field for each attribute in the
class. When an audit occurs, values for the selected attributes are written to their
respective fields, creating a new copy of the instance.
147
In addition to the class attribute fields, each audit form also includes the following
fields:
Audit Join KeyA GUID representing the specific audit entry.

Fields Changed (multiple)A field is created for each Audit attribute and Audit
and Copy attribute to specify whether that attribute value changed in the
audited instance. If such an attribute changed value, its corresponding Fields
Changed field in the audit form contains a 1. If not, the field is empty. The name
of each Fields Changed field is F_fieldId_C, using the field ID of the attribute on
its class form.
Copy attributes and None attributes do not have Fields Changed fields in the
audit form because they cannot trigger an audit.
Audit DateThe timestamp of the audit.

UserThe user who performed the action that triggered the audit
ActionAn integer representing the action that triggered the audit. Table 9-2
lists the possible values and their meanings:
Table 9-2: Audit actions
Action field value Instance action
2
Modify
Create
Delete
16
Merge
When an audit is triggered, the audited instance is copied from each class form to
the corresponding audit form.
NOTE
When auditing is enabled for a class, audits can be triggered by instances of either
the class or its subclasses, even if auditing is not enabled for the subclasses. This is
due to the hierarchical structure of class forms. When an audit is triggered by an
instance of a subclass, only the attributes of the audit-enabled superclass are
written to the audit form. You can avoid subclass instances triggering an audit by
using an audit qualification that matches the class ID of the superclass.
Copy auditing in BMC Atrium CMDB is implemented using BMC Remedy
AR System form-style auditing. For more information about form-style auditing,
see the BMC Remedy Action Request System 7.6.03 Form and Application Objects Guide.
Log auditing
Log auditing creates an entry in a log form that stores all attribute values from the
audited instance in one field. When you enable Log auditing for a class, you
specify the name of the log form to use. If this form does not already exist, it is
created automatically. You can use the same log form with multiple classes.
148
Each Log audit form includes these fields:
GUIDThe InstanceId of the audited instance.

Log Key1The ClassId of the audited instance.
Log Key2The DatasetId of the audited instance.
Fields ChangedA list of the attributes with values that changed in the action
that triggered the audit, in the format name1;name2[;name3]. This field is not
populated when the Action is Delete.
LogA list of the attribute values written for the audit, in the following format:
name1:value1
name2:value2
[name3:value3]
Audit DateThe timestamp of the audit.

UserThe user who performed the action that triggered the audit.
ActionAn integer representing the action that triggered the audit. Table 9-2 on
page 148 lists the possible values and their meanings.
When an audit is triggered, an entry is created in the log form. For information
about selecting attributes to write to the Log field, see Setting the Audit option for
attributes on page 150.
Log auditing in BMC Atrium CMDB is implemented using BMC Remedy
AR System log-style auditing. For more information about log-style auditing, see
the BMC Remedy Action Request System 7.6.03 Form and Application Objects Guide.
How Calbro Services uses auditing

The Calbro Services administrator knows that changes to the service model can be
disruptive to the customers using those services. To help identify all of the changes
to business services and the supporting technical services, the administrator
decides to audit the BMC_BusinessService class.
Copy auditing this class should not affect overall system performance because
changes to the BMC_BusinessService class should be few in number. Copy
auditing also enables greater ability to search for changes to the class. For these
reasons, the administrator configures copy auditing instead of log auditing.
149
Selecting which instances and attributes are included in an audit

You can restrict which instances of a given class are audited and determine which
attributes can trigger an audit and are written in an audit.
Restricting audited instances with a qualification

You restrict which instances are audited by specifying an audit qualification for
each class that has auditing enabled. If an instance does not match the
qualification, an audit cannot be triggered for it.
However, a superclass with auditing enabled can alter the effect of an audit
qualification. If an instance of an auditing-enabled class fails the audit qualification
for that class but matches the audit qualification of an auditing-enabled superclass,
the attributes of the instance that are inherited from the superclass are audited.
For example, if auditing is enabled for both BMC_System and
BMC_ComputerSystem, and an instance of BMC_ComputerSystem fails its own audit
qualification but matches that of BMC_System, the attributes of BMC_System are
audited for the instance. If BMC_System did not have auditing enabled, no part of
the instance would be audited.
Setting the Audit option for attributes

For each attribute in a class, you can choose one of the following Audit options:
NoneChanges to this attribute do not trigger an audit. NULL is written to the

attribute in the audit form in a Copy audit, and nothing is written to the Log field
in a Log audit. This option is the default.
AuditChanges to this attribute trigger an audit, and the attribute value is

written to the audit form or log form. When another attribute triggers an audit,
this attribute is not written.
CopyChanges to this attribute do not trigger an audit, but the attribute value
is written to the audit form or log form when another attribute triggers an audit.
Audit and CopyChanges to this attribute trigger an audit. This attribute value
is written to the audit form or log form in any audit, regardless of whether its
value changed.
NOTE
As long as a class has at least one attribute with the Audit, Copy, or Audit and
Copy option specified, a Create or Delete operation triggers an audit regardless of
the values of the attributes. Audit, Copy, and Audit and Copy attributes are all
written during such an audit.
150
Table 9-3 shows whether certain operations to a sample instance, taken in

chronological order, trigger an audit. It assumes an instance that matches the audit
qualification for its class.
Table 9-3: Audit life cycle of a sample instance
Operation
order
Operation
Attribute1
(Audit)
Attribute2
(Copy)
Attribute3
(Audit and
Copy)
Attribute4
(None)
Audit
triggered?
Attributes
written to
audit form
Create
NULL
Chicago
NULL
Compact
disc
Yes
Attribute1
Attribute2
Attribute3
Modify
Green
Chicago
NULL
Cassette
tape
Yes
Attribute1
Attribute2
Attribute3
Modify
Green
Dallas
NULL
8-track tape No
None
Modify
Green
Dallas
Bicycle
8-track tape Yes
Attribute2
Attribute3
Delete
N/A
N/A
N/A
N/A
Attribute1
Attribute2
Attribute3
Yes
In this example, Audit attribute Attribute1 and Audit and Copy attribute
Attribute3 are the only attributes that can trigger an audit. However, when the
instance is created, an audit is triggered regardless of the fact that they are both
NULL.
When the instance is modified in Operation 2, the value of Attribute1 changes,
triggering an audit that writes that attribute. Attribute2 and Attribute3 are also
written, as they are in any audit. Both Attribute2 and Attribute4 change value
in Operation 3, but no audit is triggered.
In Operation 4, Attribute3 changes value and another audit is triggered. This
time Attribute1 is not written because its value did not change. And when the
instance is deleted in Operation 5, a final audit is triggered.
Best practices
This section gives you several best practices for working with auditing.
Enable auditing for only up to five classes, as high on the inheritance tree as
possible and preferably no more than five join levels deep. For each of those, use
only up to five Audit attributes.
Do not audit system attributes like LastModifiedBy or ModifiedDate if you

use Log auditing. BMC Remedy AR System keeps a history of these already.
Rather than auditing a lower-level class in your data model inheritance tree,
audit the highest-level class with attributes you want to keep and then use a
qualification on the ClassId attribute to control which classes instances are
audited. This improves performance by preventing join forms from being
involved.
151
For example, imagine that you want to audit instances of BMC_ComputerSystem,

BMC_OperatingSystem, and BMC_ApplicationSystem; you want to trigger an
audit only if the value of the OwnerName attribute changes; and you want to
write OwnerName and Name to the audit form or log form. Because OwnerName
and Name are both inherited from BMC_BaseElement, you would enable
auditing for that class and use a qualification on ClassId to select only the
subclasses that you want.
Use a qualification on the DatasetId attribute to restrict auditing to your

production dataset. You rarely need to audit other datasets, so you will save
processor time and disk space.
When a component such as a disk drive disappears from the display of its parent
CI such as a computer system in BMC Remedy Asset Management, it is usually
caused by the connecting relationship being unintentionally soft-deleted while
the component CI still exists. To track this behavior, enable auditing on
BMC_BaseRelationship (with a qualification on source and destination class
IDs if you want), use MarkAsDeleted as an Audit attribute, and use the source
and destination instance IDs as Copy attributes.
Not every Copy attribute must also be an Audit attribute.
Receiving CI change events with Event Channels

Applications that rely on CI and relationship data stored in BMC Atrium CMDB
sometimes need to know whether CIs and relationships have been created,
updated, or deleted. For example, you might provide an email service using
multiple servers. Your email service monitoring application might have the logic
to identify the potential impact to the service of changes to the servers, but to apply
this logic it must be notified of such changes.
The BMC Atrium Event Channels component enables applications to subscribe to
and receive events using the BMC Atrium CMDB Java API. Events are generated
when CIs and relationships are created, updated, or deleted in your production
dataset, which defaults to BMC Asset. This means your application is notified of
changes to your CMDB in near real time instead of it having to poll for changes
periodically.
Enabling and disabling Event Channels

The Event Channels feature is disabled by default. To enable it, find the following
line to your ar.cfg (Windows) or ar.conf (UNIX) configuration file and change
the setting from F to T.
Event-Channel-Enabled:F
You must restart your BMC Remedy AR System server for the change to take
effect.
For more information about this file, see the BMC Remedy Action Request System
7.6.03 Configuration Guide.
152
WARNING
The Event Channels feature uses the Filter API plug-in of BMC Remedy
AR System, and occasionally this use can interfere with Reconciliation Engine
processing. To avoid reconciliation jobs hanging, if you use Event Channels then
set your BMC Remedy AR System servers Filter API RPC Timeout to 240 seconds.
To make this setting, from the Home page choose AR System Administration >
AR System Administration Console > System > General > Server Information >
Timeouts.
Class configurations
You must configure a class for events before a subscription will deliver events for
the class. The following classes are preconfigured for events:

BMC_ComputerSystem
BMC_BusinessService
BMC_Application
BMC_SoftwareServer
BMC_IPEndPoint
These class configurations cannot be deleted. You can configure other classes for
events. For instructions, see the BMC Atrium CMDB 7.6.03 Javadoc Help.
Event subscriptions
When subscribed, your application receives events in near real time whenever an
instance of a CI or relationship class configured for events is created, updated, or
deleted.
If an instance is deleted, events indicate that the instance was deleted. If the
instance is marked for deletion (by setting the MarkAsDeleted attribute to Yes),
events indicate that the instance was modified.
Instructions for subscribing to events are in the BMC Atrium CMDB 7.6.03 Javadoc
Help. Events include the following information about the instance in question:
Class ID and namespace

Instance ID
Dataset ID
Event typeCreate, Update, or Delete
153
BMC Atrium Event Channels applies the following security checks before sending
events:
Row-level check to make sure that the subscriber has the permission to view the
relevant CI class
Multitenancy check to make sure that the event is being delivered to a subscriber
with the authority to view the relevant CI class
If a subscriber application disconnects, events are queued for delivery when it
reconnects. Events that are undelivered for a day are removed, and you would
then need to re-sync with BMC Atrium CMDB using the CMDB API.
NOTE
Each subscribed application must have a unique BMC Remedy AR System user ID
for the Event Channels feature to work correctly. In a case where multiple
instances of an application subscribe to events, each instance must use a different
user ID to receive events independently of the other instances.
Performance considerations
The event generation rate is limited by the combined throughput of the
Normalization Engine, Reconciliation Engine, and BMC Atrium CMDB engine.
When the BMC Atrium CMDB server is heavily loaded, change events might be
generated faster than the rate at which the server can send them. In such a case, the
events are queued. At times of intermittent load conditions (say for a few minutes),
the queue might provide sufficient buffering, but for a longer load period it might
not. When performing a bulk load of BMC Atrium CMDB, consider turning off
event generation or event delivery to avoid overflowing the queue.
You can improve the speed at which the server delivers events by increasing the
number of Alert threads on your BMC Remedy AR System server. To set the
number of threads, from the Home page choose AR System Administration >
AR System Administration Console > System > General > Server Information >
Ports and Queues. In the table row for the Alert queue, set Min Threads to 5 and
Max Threads to 10.
Interfaces to BMC Atrium Event Channels

You can configure classes, subscribe to BMC Atrium Event Channels, and turn off
event generation or event delivery through the BMC Atrium CMDB Java API. For
information, see the BMC Atrium CMDB 7.6.03 Javadoc Help. You configure
classes for events with the ECUtil.java class and subscribe to events with the
CMDBEventSubscription.java class.
Permission roles
To subscribe to events, you must have the CMDB Console User role. To configure
classes for events, you must have the CMDB Console Admin role.
154
Deleting CIs that are no longer discovered
Deleting CIs that are no longer discovered

Occasionally, your discovery application will not discover a CI or that it regularly
discovered before. Though you might be tempted to delete the CI from BMC
Atrium CMDB, do not do so right away. Usually such a missing CI is only
temporarily removed or unavailable, such as when a computer system is shut
down while its owner is on vacation.
Instead of deleting the instance from BMC Atrium CMDB, known as hard deleting,
mark it as deleted. This is known as soft deleting, and you perform it by setting the
MarkAsDeleted attribute to Yes. Soft deleting has two benefits:
When instances have been soft deleted, you can exclude them from searches,
reconciliation, and other activities by using the MarkAsDeleted attribute in your
qualifications.
Soft deleting preserves relationships and reconciliation identity in case a CI is

later discovered again.
Establish a policy that specifies how long a CI can remain soft deleted. If it is
rediscovered before reaching the end of that interval, you can reset the
MarkAsDeleted attribute to NULL. If not, you can hard delete the CI.
The Reconciliation Engine offers a Purge activity that deletes soft-deleted
instances. For more information about this feature, see Other reconciliation
activities on page 105.
Custom workflow
Because BMC Atrium CMDB is built on the BMC Remedy AR System, you can
easily add custom workflow to the class forms to accomplish various tasks. For
information about creating BMC Remedy AR System workflow, see the BMC
Remedy Action Request System 7.6.03 Workflow Objects Guide.
Calbro Services custom workflow for viewing unreconciled CIs

Calbro Services has a process that involves creating computer system CIs
manually in the production dataset. These new CIs have no reconciliation identity,
and the administrator wants a visual cue when viewing a CI that it has not yet been
reconciled with CIs imported by using BMC Atrium Integration Engine, or with
data discovered by BMC BladeLogic Client Automation or BMC Atrium Discovery
and Dependency Mapping.
To satisfy this requirement, the administrator creates custom workflow that
changes the label color of the Name attribute to red when an unreconciled CI is
displayed.
155
Filter execution order

BMC Atrium CMDB uses two BMC Remedy AR System filters that act on all class
forms. Each filter triggers processing by the BMC Atrium CMDB engine on the
instance that is created, modified, or deleted. One filter is at execution order 100,
and one at execution order 600.
Execution order 100Performs validation, sets the instance ID and class ID for
new instances, and for relationship instances also sets the reconciliation ID,
dataset ID, and class ID.
Execution order 600Performs hard and soft deletes, pushes attribute values to
subclass forms, handles weak relationship functionality, and for new instances
adds default instance permissions.
To create a filter on a class form, choose its execution order based on these filters.
In most cases, you should choose an execution order from 101 to 599. This enables
your filter to work with the class ID and instance ID that are created at execution
order 100 and to modify attribute values before they are pushed to subclass forms.
WARNING
If your workflow modifies attribute values after execution order 600, it can
compromise your data integrity.
You might choose an execution order of 99 or less to create your own instance ID
instead of letting the system create it automatically.
Best practices
When planning to add custom workflow to BMC Atrium CMDB, follow these
guidelines:
First, identify the scope of your customization. Should it apply to all subclasses,
all datasets, all data inputs, or a subset of these?
Do not modify any of the existing filters attached to the class forms. They are
typically attached to many forms, and your changes could ripple to unwanted
locations.
Add active links to an application that consumes BMC Atrium CMDB data
instead of to BMC Atrium CMDB itself. For example, if you have BMC Remedy
Asset Management, add your active links to the AST: forms. Add filters and
escalations to the BMC Atrium CMDB class forms.
Consider the subclasses of any class you touch. For example, workflow defined
on the BMC.CORE:BMC_BaseElement form applies to all CIs unless you restrict
it to particular subclasses with a Run If qualification.
Remember the scope you identified for the customization.

Document all customizations.
156
Glossary
abstract class
A class that has attributes but of which no

instances can be created. An abstract class
exists for the purpose of creating an
organizational layer without a database join.
See also data replication.
account
An entity or party whose data is represented

in BMC Atrium Core, and to whom specific
levels of permission can be granted.
Specifying instance permission by account
enables BMC Atrium Core to support
multitenancy.
activity
An individual reconciliation task that can be

grouped together in a defined sequence to
form a reconciliation job. You can run an
activity only as part of a job, never by itself.
See also Comparison activity, Copy Dataset
activity, Delete Dataset activity, Execute Job
activity, Identification activity, Merge activity,
Purge Dataset activity, Rename Dataset activity.
Adapter Development Kit
The Adapter Development Kit is a software

development kit that lets you build your own
adapters to interact with BMC Atrium
Integration Engine. The Adapter Development
Kit interface defines a set of C++ objects that
are used by the AIE service to manage data
exchanges that use these adapters.
AIE Definitions Admin
A BMC Atrium Integration Engine application

role. Members can view, create, and modify
data mappings and data exchanges, and manage
the configuration and connection settings. See
also AIE User.
AIE service
The AIE service obtains the defined data

exchange from the Data Exchange application
and completes the transfer of data by
communicating with the adapter specified in
the data exchange definition. The AIE service
can connect to a BMC Remedy AR System
server. It runs as a client to the BMC Remedy
AR System server using the BMC Remedy
AR System application programming
interface (API).
AIE User
A BMC Atrium Integration Engine application

role. Members can view data mappings, data
exchanges, and configuration and connection
settings. See also AIE Definitions Admin.
Atrium Explorer
A component of BMC Atrium CMDB that

graphically displays the relationships
between CIs. It can also be embedded in other
BMC Remedy AR System-based applications.
attribute
A property or characteristic of a class, such as

the IP address of a computer system. An
attribute equates to a column on a database
table or a field on a BMC Remedy AR System
form.
attribute permission
Permission to view or change the value in the

attribute for any instance, assuming valid
instance permissions.
attribute substitution
A method of data federation in context that

uses placeholders to represent attributes from
a linked class. Launching the link triggers the
respective attribute values to be substituted for
the placeholders.
Glossary
157
audit
Categories, Types, and Items (CTI)
A logging of attribute values and other

information for purposes of tracking the
history of changes to instance data. An audit is
triggered when the value of one or more
specified attributes changes or when the
instance is created or deleted.
A method formerly used for categorizing

assets in BMC Remedy Asset Management.
Category, Type, and Item are each an attribute
on the BMC_BaseElement class, so you can use
CTIs in BMC Atrium CMDB.
categorization class
A class that does not have its own BMC

Remedy AR System form, but stores its
instance data in the form of its superclass,
preventing the need for a database join.
base class
A class that has no superclass.

BMC Atrium Core Console
The main user interface of BMC Atrium

CMDB, accessible from both web and BMC
Remedy User clients. The BMC Atrium Core
Console replaced the CMDB Console.
CDM
See Common Data Model (CDM).

child
See destination.
A product that enables you to transfer large

amounts of data between third-party data
sources and both the BMC Remedy
AR System and BMC Atrium CMDB.
BMC Atrium Product Catalog
A BMC Remedy AR System application that is

part of the BMC Atrium Core solution and
provides data for normalization and
discovery, including storage of product
signatures, and tracks and manages products
by categorization, life cycle, development
status, approval status, and other attributes.
bulk functions
A set of functions you can use to create,

update, and delete multiple instances in a
single call. These functions can manipulate
instances of different classes in a single
operation.
Business Service Management (BSM)
The concept of prioritizing IT efforts to

support the overall goals of the business.
cardinality
The number of members a relationship class can

have on each side. Cardinality can be one to
one, one to many, many to one, or many to
many.
cascading delete
To automatically delete, or mark as deleted

the destination member of a relationship
when the source member is deleted or
marked.
158
CI
See configuration item (CI).

CI class
A class that defines a type of configuration item

(CI), such as a computer system or software
application.
CIM
See Common Information Model (CIM).

class
Metadata in BMC Atrium CMDB that defines

a type of object, usually a configuration item
(CI) or relationship. Either of these types of
class can store data as a regular class,
categorization class, abstract class, or abstract
class with data replication. You can apply the
final class and singleton class options to it as
well.
Class Manager
A component of BMC Atrium CMDB where

you can view, create, modify, and delete the
classes and attributes that make up the data
model, as well as view a list of subclasses for
each class.
class permissions
Permission to view instances of a class in the

BMC Atrium CMDB interface or access them
with BMC Remedy AR System workflow.
CMDB
See Configuration Management Database

(CMDB).
Glossary
CMDB Console
See BMC Atrium Core Console.

CMDB Console Admin
An application role. Members can perform

searches from the BMC Atrium Core Console,
view, create, and modify federation definitions,
and perform BMC Atrium Core Console
administrative tasks.
CMDB Console User
An application role. Members can perform

searches from the BMC Atrium Core Console
and view federation definitions.
CMDB Data Change
An application role. Members can view, create,

and modify instances if they have row-level
security.
CMDB Data Change All

and modify instances independent of row-level
security.
CMDB Data View
An application role. Members can view

instances if they have row-level security.
CMDB Definitions Admin

modify, and delete classes.
CMDB Definitions Viewer
An application role. Members can view class

definitions.
CMDB Extended Data
Related data or CI attributes linked to or from

BMC Atrium CMDB.
CMDB RE Definitions Admin

modify, and delete reconciliation definitions
and can start and cancel jobs.
CMDB RE Manual Identification
An application role. Members can identify

instances manually.
CMDB RE User
An application role. Members can view

reconciliation definitions and can start and
cancel jobs.
cmdbdriver
A utility that executes BMC Atrium CMDB

C API functions from a command line,
prompting for parameters.
Common Data Model (CDM)
The object-oriented, hierarchical set of classes

in BMC Atrium CMDB used to represent
types of CIs and relationships. The CDM is
based on industry standards such as the
Common Information Model (CIM) and
Microsoft Windows Management
Instrumentation.
Common Information Model (CIM)
A definition of management information

developed by the Distributed Management Task
Force (DMTF) that facilitates the exchange of
management information between systems.
Comparison activity
A Reconciliation Engine activity that compares

identified instances between two datasets,
either producing a report that shows the
differences or executing workflow.
configuration data
Data about your IT environment, consisting of

CIs and relationships.
configuration item (CI)
A physical, logical, or conceptual entity that is

part of your IT environment and has
configurable attributes. Examples include
computer systems, buildings, employees,
software, and business services. One of the
two types of classes in BMC Atrium CMDB.
See also relationship.
Configuration Management Database (CMDB)
A database that stores information about your

IT configuration, including both CIs and
relationships.
consumer
An application that works with data in BMC

Atrium CMDB. It might view the data or
modify it. See also provider.
Copy Dataset activity
A Reconciliation Engine activity that copies

instances from one dataset to another.
Glossary
159
CTI
Definitive Hardware Library (DHL)
See Categories, Types, and Items (CTI).

data exchange
A BMC Atrium Integration Engine integration

object that you execute to transfer data. A data
exchange specifies the source and destination
in a data transfer, the adapter to be used for
the transfer, and the connection parameters to
connect to the external data store. A data
mapping is associated with a data exchange to
transfer data.
data mapping
A BMC Atrium Integration Engine integration

object that defines the data to be transferred. A
data mapping defines the source and
destination of a data transfer, the primary key,
and other fields and attributes. You can use a
data mapping by associating it with a data
exchange.
data replication
An option for abstract classes. With this option,

the instances of all subclasses are replicated to
a single form to allow you to search the
abstract class as though it had data. Only the
attributes inherited from the abstract class are
replicated.
dataset
A logical group of data in BMC Atrium

CMDB. A dataset can represent data from a
particular source, a snapshot from a particular
date, or other purpose. The dataset used by
BMC Software products for reconciled
production data is named BMC Asset. See also
overlay dataset.
Dataset Merge Precedence
A pairing of a dataset with a Precedence group.

Each Merge activity references a collection of
these, called a Dataset Merge Precedence set.
defined dataset
One of a pair of dataset IDs that is specified

when executing a job with dynamic dataset
substitution. The job is executed with the
working dataset in place of the defined dataset.
The Definitive Hardware Library (DHL) is a

subset, or filter, of the Product Catalog that
represents hardware products that are
marked as approved for use in an
organization.
Definitive Media Library (DML)
A repository where approved software

configurations are stored. Installed instances
of the software can be checked against the
DML for compliance with licenses and
policies. From the 7.5.00 release of BMC
Atrium Core, Definitive Software Library
(DSL) has been renamed to Definitive Media
Library.
Definitive Software Library (DSL)
See Definitive Media Library (DML).

Delete Dataset activity
A Reconciliation Engine activity that deletes

instances from one or more datasets without
removing the dataset itself. See also cascading
delete, hard delete, soft delete.
destination
The CI class defined as Class 2 in a relationship

class, or an instance of that CI class as a
member of such a relationship. Also known as
the child member. In a weak relationship, the
destination is the weak member.
discovery
The act of scanning your environment for

configuration data.
discovery application
An application that scans your environment

for configuration data and can act as a provider
to BMC Atrium CMDB.
Distributed Management Task Force (DMTF)
An organization appointed to facilitate the

exchange of management information by
promoting the initiation of industry standards
and interoperability.
DHL
See Definitive Hardware Library (DHL).

DML
160
Glossary
DMTF
See Distributed Management Task Force

(DMTF).
DSL

Enterprise Integration Engine
See BMC Atrium Integration Engine.

event
A particular type of change to the instances of

specified classes. You can publish an event so
that any instance of it is written to the
CMDB:Events form. You can receive
notification each time an instance of the event
occurs by polling the form.
Exclusion rule
A rule that specifies an attribute to be excluded

from participation in a Comparison activity.
Execute Job activity
A Reconciliation Engine activity that executes a

job.
extension
A logical set of classes and attributes, usually in

its own namespace, that is not part of the
Common Data Model (CDM).
extension loader
The cmdbExtLoader program, which is used
for installing data model extensions and

importing other BMC Atrium CMDB data and
metadata.
federated data
Data linked from CIs in BMC Atrium CMDB

but stored externally. Federated data might
represent more attributes of the CIs or related
information such as change requests on the
CIs.
federated interface
An instance of the BMC_FederatedInterface

class that specifies how to access a particular
type of federated data. See also federated link.
federated link
The connection between a class or CI and a

federated interface.
federation
The act of linking CIs in BMC Atrium CMDB

to external data.
Federation Manager
A component of BMC Atrium CMDB that you

can use to manage federated data. From the
Federation Manager, you can view, create,
and modify federated products, federated
interfaces, and federated links.
filter
A set of criteria for restricting the information

displayed by the Atrium Explorer. This is
different from a BMC Remedy AR System
filter.
final class
A class that cannot have subclasses.

foreign key substitution
A method of federation that assigns a key

from the federated product to each linked CI.
Foreign key substitution is useful when no
attributes that also exist in BMC Atrium
CMDB are stored in the federated product.
graph walk
The act of searching for CIs and relationships

in BMC Atrium CMDB.
graph walk functions
A set of specific functions that are used to

search for CIs and relationships in BMC
Atrium CMDB. Use these functions when you
want to search for CIs regardless of their class
or relationship.
group
A set of a particular type of reconciliation

definition that is referenced by an activity. See
also Identification group, Precedence group,
Qualification group, Workflow Execution group.
GUID
A globally unique identifier, automatically

generated by the BMC Remedy AR System
server. GUIDs are used for instance IDs,
reconciliation IDs, and other cases where a
unique value must be generated without
human interaction.
federated product
A product that holds federated data. It can be

linked to more than one federated interface.
Glossary
161
hard delete
The act of removing an instance from BMC

Atrium CMDB. See also soft delete.
Identification activity
A Reconciliation Engine activity that matches

instances from two or more datasets and
assigns them the same identity, meaning that
they represent the same real-life object.
Identification group
A set of Identification rules that collectively

identify instances from a particular dataset
against other datasets. Each dataset that
participates in an Identification activity is
paired with one Identification group.
Identification rule
A rule used when identifying instances

between datasets. When two instances match
the qualification for the rule, they are assigned
the same reconciliation ID.
identity
See reconciliation ID.

incident
Defined by ITIL as any event that is not part

of the standard operation of a service and that
causes, or might cause, an interruption to, or a
reduction in, the quality of that service.
incremental merge
A Merge activity that only processes instances

created or modified since the activity was last
run, saving otherwise useless processing time.
Setting Force Attribute Merge to No makes a
Merge activity incremental.
instance
An actual incarnation of a particular class,

represented as a record in BMC Atrium
CMDB. Both CIs and relationships are
instances of their respective classes.
instance ID
A GUID that BMC Atrium CMDB applies to

each instance to uniquely identify it.
instance permissions
The right to view or modify a specific

instance. These permissions are called rowlevel security and write security, respectively.
162
instantiate
To create an instance of a class.

ITIL
The IT Infrastructure Library (ITIL) is an

internationally accepted set of best practices
developed by the British government for
management of IT services.
job
A group of one or more reconciliation activities

executed in sequence. You cannot run an
activity by itself; only as part of a job. You can
start a job manually, with a schedule, with an
Execute Job activity, with workflow, or with an
API program.
key query
Limits the records transferred in a data

transfer in the BMC Atrium Integration
Engine. See also row-level query.
Merge activity
A Reconciliation Engine activity that merges

two or more datasets into a single complete
and correct dataset based on precedence values
that favor the strengths of each dataset.
metadata
Definitions that describe the data stored in

BMC Atrium CMDB. Metadata includes
classes in the data model and special classes to
define things such as datasets and federation
objects.
multitenancy
The separation of data and access so that a

single BMC Atrium CMDB can contain the
data of multiple parties, but each party can
access only their own data. See also account,
role.
namespace
A logical set of classes and attributes in the data

model, usually related to a specific consumer
or provider. The Common Data Model (CDM)
uses the BMC.CORE namespace.
Glossary
normalize
To ensure that data of the same type follows

the same text formatting conventions. This
helps reconciliation by making it more likely
for instances to match in an Identification
activity.
A BMC Atrium CMDB application that

provides a centralized, customizable, and
uniform way to overcome consistency
problems by normalizing attributes for
software and hardware products.
orphan
An instance that has been physically deleted

from source datasets but still exists in the
target dataset into which they merge.
overlay dataset
A dataset that provides a layer in which to

make changes that are pending approval. API
queries to the dataset seamlessly return its
modified instances along with unmodified
instances from the underlying regular dataset.
parent
See source.
Precedence group
The definition of an overall precedence value for

a dataset. It can optionally contain precedence
values for specific classes and attributes
within the dataset.
precedence value
A method of assigning weight to specific

datasets, classes, and attributes in a Merge
activity. Attribute precedence values override
class precedence values, which override
dataset precedence values.
primary key
A primary key uniquely identifies a row of

data. In BMC Atrium Integration Engine you
must specify the attributes of a CI class and
the corresponding fields in the external data
store to create the primary key. After a data
transfer, the primary key is the link that
matches a record in the external data store
with its counterpart in BMC Atrium CMDB.
Product Catalog
The BMC Atrium Core component that

provides normalized manufacturer names,
model names, categorization values, and
other information about hardware and
software products.
product categorization
Divides CIs into groups. Using the three-tier

structure of product categorization, you can
create successively smaller, more tightly
defined groups. You can create groups of CIs
in Tier 1 followed by smaller groups in Tier 2
and Tier 3.
production dataset
The dataset that serves as the single source of

reference for your organization and from
which you make business decisions. It acts as
the target dataset in most Merge activities.
provider
An application, often a discovery application,

that loads bulk data into BMC Atrium CMDB.
See also consumer.
provisioning
The process of providing access to resources,

such as printers, telephones, and so on, and to
information, such as permissions, databases,
and so on.
publish
To make an event available so that instances of

it can be written to the CMDB:Events form.
Purge Dataset activity
A Reconciliation Engine activity that removes

instances that have been marked as deleted
from one or more datasets.
Qualification
A Boolean statement that is evaluated to

determine whether an instance should be
included in an activity.
Qualification group
A set of Qualifications that can be used in

various types of activity. An instance that
meets one or more Qualifications in the group
is included in the activity.
Glossary
163
reconciliation
The process of managing data in multiple

datasets using the Reconciliation Engine. The
main activities of reconciliation are
identifying, comparing, and merging
datasets, though the Reconciliation Engine
performs other activities as well.
reconciliation definition
An entity defined in the Reconciliation Manager

such as a job, activity, or group.
The component of BMC Atrium CMDB that

reconciles data from different datasets.
reconciliation ID
A GUID that the Reconciliation Engine assigns

to instances in different datasets that represent
the same real-life object.
Reconciliation Manager
The component of BMC Atrium CMDB that

you can use to manage reconciliation
definitions.
regular class
A class that stores its instance data in its own

BMC Remedy AR System form. See also
abstract class, categorization class.
related information
Information about a CI that does not qualify as

attributes of the CI, and should therefore not
be stored in a Configuration Management
Database (CMDB).
relationship
A connection between two CIs such as a

dependency or membership. It is an instance
of a relationship class. See also configuration item
(CI).
relationship class
A class that defines a type of relationship

between CIs, such as a dependency or
membership.
relationship filter
See filter.
relationship key
A relationship key uniquely identifies a row

of data in a relationship mapping. In BMC
Atrium Integration Engine you must specify
the attributes of a primary CI class and a
secondary CI class to create the relationship
key. After a data transfer, the relationship key
is the link that matches a record in the external
data store with its counterpart in BMC Atrium
CMDB.
Rename Dataset activity
A reconciliation activity that renames a dataset

without changing its ID, preserving references
to the dataset from any reconciliation
definitions.
role
A designation that grants permissions to more

than one BMC Remedy AR System group.
row-level query
Limits the transfer of data on a row-by-row

basis in the BMC Atrium Integration Engine.
See also key query.
row-level security
The permission required to view a specific

instance. See also write security.
rule
One or more criteria that, when met, cause an

action. The types of rules used in BMC Atrium
Core are Exclusion rule, Identification rule, and
Workflow Execution rule.
ruleset
A group of rules.
service level agreement
A contract between a service provider and a

purchaser that defines the level of service.
service model
The CIs and relationships that define business

services and the resources that deliver and
support them, enabling you to see
infrastructure items in a business context.
singleton class
An optional class characteristic that restricts

the class to holding only one instance.
164
Glossary
snapshot
A set of data that represents a configuration at

a certain point in time, usually stored in its
own dataset. There can be multiple snapshots
of a given configuration.
soft delete
The act of marking an instance as deleted from

BMC Atrium CMDB by setting the
MarkAsDeleted attribute to Yes. See also hard
delete.
source
The CI class defined as Class 1 in a relationship

class, or an instance of that CI class as a
member of such a relationship. Also known as
the parent member. In a weak relationship, the
source is the strong member.
subclass
A class that is derived from another class,

which is called its superclass. The subclass
inherits all the attributes of its superclass and
any superclasses above it in the hierarchy, and
can also participate in relationships defined
for all superclasses.
superclass
A class from which other classes, called

subclasses, are derived.
synchronization
The automatic process of creating BMC

Remedy AR System forms and workflow to
represent a class that has just been created or
modified. The class is not available until
synchronization completes.
text normalization
See normalize.
unqualified data
Information about an unknown device at a

known IP endpoint. If you discover an IP
address, but lack the credentials to identify
the device at that endpoint, data for that
device is unqualified. For example, the device
might be a laptop computer, printer, router, or
some other type of device. BMC Atrium
CMDB stores unqualified data as
BMC_ComputerSystem instances.
weak relationship
An optional characteristic for relationship

classes, signifying that the members of a
relationship form a composite object that can
be reconciled as one. The destination member
is considered the weak member of a weak
relationship, existing as part of the source
member (also known as the strong member).
Windows Management Instrumentation (WMI)
The Microsoft application of the Web-Based

Enterprise Management initiative for an
industry standard for accessing management
information.
WMI
See Windows Management Instrumentation

(WMI).
workflow
BMC Remedy AR System objects such as

active links, escalations, and filters that
perform actions against data.
Workflow Execution group
A set of Workflow Execution rules. Each

Comparison activity can optionally reference
one Workflow Execution group.
Workflow Execution rule
A rule used when comparing instances

between datasets. When a compared instance
matches the qualification for the rule,
specified BMC Remedy AR System workflow
is executed against the instance or the instance
against which it is compared.
working dataset
One of a pair of dataset IDs that is specified

when executing a job with dynamic dataset
substitution. The job is executed with the
working dataset in place of the defined dataset.
write security
The permission required along with row-level

security to modify or delete a specific instance.
See also row-level security.
weak reference
See weak relationship.

Glossary
165
166
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Index
A
about BMC Atrium CMDB 25
abstract classes
about 52
data replication 53, 62
extending 62
accessing
BMC Atrium CMDB 89
CMDB data 26
adding
attributes to existing classes 60
data manually 137
subclasses to the Common Data Model 61
workflow to BMC Atrium CMDB 155
application layer infrastructure 31
applications, using with extended data models 64
approving products 125
AR System
See BMC Remedy Action Request System (BMC
Remedy AR System)
architecture
AR System 32
BMC Atrium CMDB 29
BMC Atrium Core 25
assessing configuration data source environments 75
Atrium Explorer
about 22
relating CIs 109
Atrium Impact Simulator 22
attributes
about 46
adding to existing classes 60
Category 60
extending the Common Data Model 60
generating fields for AR System 64
Item 60
naming and numbering rules 64
substitution of 86
Type 60
updating manually 138
audit forms 147
auditing, best practices 151

audits
attribute options 150
Calbro Services example 149
copy option 147
life cycle 151
log option 148
restricting 150
specifying qualifications 150
tracking changes to instance data 146
types 147
B
benefits
BMC Remedy AR System 33
decision-making support 35
federated data 30
integration 35
Service Asset and Configuration
Management 34
best practices
adding workflow 156
auditing 151
categorizations 124
data exchanges 129
importing data to BMC Atrium CMDB 135
bidirectional data transfers, testing 136
BMC Asset dataset 78
BMC Atrium CMDB
See BMC Atrium Configuration Management
Database (BMC Atrium CMDB)
BMC Atrium Configuration Management Database
(BMC Atrium CMDB)
about 20
architecture 29
data model 46
production dataset 78
Index
167
BMC Atrium Core
architecture 25
implementing 117
managing 145
BMC Atrium Discovery and Dependency Mapping
configuration data discovered 74
dataset 78
discovering data 74
running and scheduling tasks 82
about 24
configuring 127
transferring data 74
BMC Atrium Product Catalog
about 23, 96
best-practice categorizations 124
relation to Normalization Engine 94
running and scheduling tasks 82
BMC Configuration Import dataset 78
BMC Configuration Management
configuration data discovered 73
dataset 78
BMC Impact Solutions, using new classes 64
BMC Remedy Action Request System (BMC Remedy
AR System)
architecture 32
benefits 33
BMC Atrium CMDB and 32
using with extended data models 64
BMC Remedy AR System
See BMC Remedy Action Request System (BMC
Remedy AR System)
BMC Remedy Asset Management, dataset 78
BMC Sample dataset 78
BMC Software, contacting 2
BMC.ADDM dataset 78
BMC.ASSET.SANDBOX dataset 78
BMC_AccessPoint class 55
BMC_BaseElement class 55
BMC_BaseRelationship class 56
BMC_Collection class 55
BMC_Component class 56
BMC_Dependency class 56
BMC_Document class 55
BMC_ElementLocation class 56
BMC_Equipment class 55
BMC_FederatedBaseElement class 57
BMC_FederatedBaseRelationship class 57
BMC_Genealogy class 56
BMC_Impact class 56
168
BMC_LogicalEntity class 55
BMC_MemberOfCollection class 56
BMC_Person class 55
BMC_Settings class 55
BMC_System class 55
BMC_SystemComponent class 55
BMC_SystemService class 55
building CMDBs
phased implementation 42
Stage 1 40
Stage 2 40
Stage 3 41
Stage 4 41
Stage 5 42
bulk data, loading 27
business services
described 109
C
Calbro Services
about 37
adding custom workflow 155
auditing 149
business service 112
CI eligibility matrix 69
extending the data model 63
federating data 84
mapping CIs to data sources 74
multitenancy 90
normalizing data 98
populating BMC Atrium CMDB 139
reconciling datasets 78
service model 108
cardinality 48
cascading delete 49
categorization classes
about 51
extending 62
Category attributes 60
CDM
See Common Data Model (CDM)
challenges to SACM 42
changes, tracking instance data 146
changing attribute permissions 120
CI change events 152
CI eligibility matrix 69
CIM
See Common Information Model
CIs
See configuration items
Class Manager, about 23
classes
about 46
abstract 52
abstract with data replication 53
adding attributes to existing 60
BMC Atrium CMDB 54
categorization 51
configuration item 46
data model 54
data storage methods 50
deleting instances of 49
extending 61
regular 50
relationship 47
replicating subclasses 53
CM
See configuration management
CMDB Environment layer 31
CMDBRowLevelSecurity permission 121
CMDBs
BMC Atrium infrastructure layer 29
configuration items and 68
data types 68
implementing 42
integrating ITIL processes 35
CMDBWriteSecurity permission 121
CMS architecture 29
CMS Data layer 30
combining reconciliation activities 105
Common Data Model (CDM)
about 23, 46, 54
abstract classes 62
abstract classes with data replication 62
adding attributes 60
adding subclasses 61
BMC applications and 64
BMC Impact Solutions and 64
BMC products and 59
categorization classes 62
classes 61
configuration item classes 55
diagram 59
documenting 65
existing attributes 60
extending 59
final classes 62
regular classes 61
relationship classes 56, 61
sample models 58
Common Data Model (CDM) (continued)

singleton classes 62
Common Information Model 23, 54
Compare Dataset activity, tracking changes with 146
comparing datasets 101
computer systems, sample data models 58
configuration data
assessing source environments 75
datasets and 77
discovered by BMC Atrium Discovery and
Dependency Mapping 74
discovered by BMC Configuration
Management 73
unified representation 46
configuration items (CIs)
about 68
BMC_AccessPoint 55
BMC_BaseElement 55
BMC_Collection 55
BMC_Document 55
BMC_Equipment 55
BMC_LogicalEntity 55
BMC_Person 55
BMC_Settings 55
BMC_System 55
BMC_SystemComponent 55
BMC_SystemService 55
classes 46
CMDBs and 68
Common Data Model classes 55
datasets and 77, 94
defined 68
deleting 155
examples 68
extending 61
mapping to discovery data sources 72
missing 155
related data 71
relationships 70
undiscovered 155
Configuration Management
controlling 36
teams, establishing 40
configuration management databases
See CMDBs
configuring
BMC Atrium Integration Engine 127
multitenancy 121
permissions 119
controlling
access 89
Configuration Management 36
Index
169
copying dataset instances 105
custom workflow, adding 155
customer support 3
D
data
access 26
auditing 146
BMC Atrium CMDB model 46
bulk loading 27
configuration 46
federated 82
importing to BMC Atrium CMDB 135
migrating to BMC Atrium CMDB 135
open access 26
partitioning 27
programmatic access to 27
reconciling 99, 139
related to configuration items 71
replicating abstract class 53
replicating BMC Atrium CMDB 92
tracking changes 146
types stored in ITIL CMDBs 68
data exchanges, creating 129
data mappings, creating 128
data models
See also Common Data Model
about 22, 46
abstract 52
abstract with data replication 53
attributes 46
categorization 51
classes 46
extensibility 23, 46
industry standards 23, 54
inheritance 46
object-oriented 23
regular 50
synchronizing changes 54
datasets
about 77, 94
BMC Asset 78
BMC Configuration Import 78
BMC Sample 78
BMC.ADDM 78
comparing 101
copying instances 105
170
datasets (continued)
deleting instances 105
identifying 80
merging 101
production 78
purging instances 105
reconciling 99
renaming 105
Definitive Hardware Library (DHL), approving
products 125
Definitive Media Library (DML)
about 24
defined 97
See Also BMC Atrium Product Catalog
deleting
cascading 49
configuration items 155
dataset instances 105
instances 49
relationships 49
destination classes 47
DHL
See Definitive Hardware Library
diagram of the Common Data Model 59
discovery
BMC Atrium Discovery and Dependency
Mapping 74
data sources 75
deleting undiscovered CIs 155
tasks 74
Distributed Management Task Force 23, 54
DML
See Definitive Media Library
DMTF
See Distributed Management Task Force
documenting extensions 65
E
eligibility matrix 69
Event Channels
configuring classes for 153
interfaces to 154
overview 152
performance considerations 154
permission roles for 154
subscribing to 153
examples
relationship 71
test cases for validation 136
Extended Data layer 30
extending the Common Data Model
about 59
abstract classes 62
abstract classes with data replication 62
adding attributes 60
adding subclasses 61
BMC applications and 64
BMC Impact Solutions and 64
BMC products and 59
categorization classes 62
classes 61
diagram 59
documenting 65
existing attributes 60
final classes 62
regular classes 61
relationship classes 61
singleton classes 62
extensible data models 23
F
federated classes 57
federated data
about 27, 82
as part of a CMS 29
attribute substitution 86
benefits 30
foreign key substitution 87
model 25, 27
using 83
federated data model, about 27
federated infrastructure 29
federation methods 84
final classes
extending 62
foreign key substitution 87
forms
audit 147
log 148
G
goals of SACM 34
groups 91
H
hidden class permissions 120
I
identifying
datasets 80
instances 100
implementing
BMC Atrium Core 117
CMDBs 42
import management module, purpose 73
importing data to BMC Atrium CMDB 135
incremental merge jobs 102, 132
industry standards, data model 23, 54
infrastructure
about 29
application layer 31
BMC Atrium CMDB 29
CMDB Environment layer 31
CMDB layer 29
CMS Data layer 30
federated 29
related data 30
inheritance 46
instances
audited 147
CMDBRowLevelSecurity permissions 121
CMDBWriteSecurity permissions 121
copying dataset 105
deleting dataset 105
deleting from overlay datasets 80
deleting relationship class 49
identifying in datasets 80, 100
purging dataset 105
replicating 53
sample audit 151
integrating IT processes 35
integration benefits 35
IT Infrastructure Library (ITIL)
about 33
data types 68
SACM 33
Item attributes 60
ITIL
See IT Infrastructure Library
J
jobs, combining reconciliation activities 105
Index
171
launch method of federation 85

left-side classes 47
loading bulk data 27
log forms 148
parent classes 47
partitioning
about 27
data 27
datasets and 77
pending changes 54
permissions
about 89
BMC Atrium CMDB 89
change attribute 120
configuring 119
groups 91
hidden class 120
roles 92
view attribute 120
visible class 120
phases of CMDB implementations 42
planning
bringing data into BMC Atrium CMDB 67
building CMDBs 41
CMDB requirements 40
data model 45
driving value 42
establishing management teams 40
normalization 93
reconciliation 99
service model 107
solutions and tools 41
processes, integrating IT 35
Product Catalog
See BMC Atrium Product Catalog
product support 3
production datasets, defined 78
programmatic access to data 27
purging dataset instances 105
M
managing BMC Atrium Core 145
manually updating attributes 138
mapping configuration items to discovery data
sources 72
members, relationship 47
merging datasets
about 101
incrementally 102, 132
independent activities 103
one activity 102
Microsoft Windows Management
Instrumentation 23, 54
migrating data to BMC Atrium CMDB 135
multitenancy
configuring 121
defined 89
N
naming rules for extensions 64
normalization
modes 95
about 20
example 94
relationship to Product Catalog 94
numbering rules for extensions 64
O
object-oriented data models 23
open access to data 26
overlay datasets
about 79
deleting instances 80
instance IDs 80
queries to 80
172
Q
qualifications, audit 150
queries, overlay dataset 80
R
reconciliation
about 139
combining activities 105
comparing datasets 101
copying dataset instances 105
data 99
deleting dataset instances 105
executing jobs 105
identifying instances 100
jobs 105
merging datasets 101
purging datasets 105
renaming datasets 105
about 21, 99
executing jobs 105
regular classes
about 50
extending 61
related data 30
relating CIs using Atrium Explorer 109
relationships
about 47
BMC_BaseRelationship 56
BMC_Component 56
BMC_Dependency 56
BMC_ElementLocation 56
BMC_Genealogy 56
BMC_Impact 56
BMC_MemberOfCollection 56
cardinality 48
cascading delete 49
Common Data Model 56
datasets and 77, 94
deleting 49
deleting instances of 49
destination 47
examples 71
extending 61
extending classes 61
left-side 47
members 47
placement 47
right-side 47
source 47
weak 48
renaming datasets 105
replicating data 92
restricting audits 150
retrieval method of federation 85

right-side classes 47
risks to successful SACM 42
roles 92
S
SACM
See Service Asset and Configuration
Management
samples
Common Data Model 58
instance audits 151
LAN computer system data models 58
typical computer system data models 58
Service Asset and Configuration Management
(SACM) 19, 33
benefits 34
challenges, success factors, and risks 42
data accuracy 36
data availability 36
goals 34
ITIL and 33
Service Catalog, about 24
service models
defined 108
structure 134
service oriented architecture (SOA) 28
singleton classes
extending 62
SOA
See service oriented architecture
source classes 47
subclasses
adding to the Common Data Model 61
creating 61
federated data 57
substitution
attribute 86
foreign key 87
success factors with SACM 42
support, customer 3
synchronizing data model changes 54
Index
173
T
teams, Configuration Management 40
technical support 3
test cases for validation 136
testing unidirectional and bidirectional data
transfers 136
tracking instance data changes 146
Type attributes 60
U
undiscovered relationship information, adding
manually 138
unidirectional data transfers, testing 136
V
validating data import using BMC Atrium
Integration Engine 138
virtual machines 56
virtualization management 28
visible class permissions 120
W
weak relationships 48
web services 28
WMI
See Microsoft Windows Management
Instrumentation
workflow
best practices for adding 156
174
*160635*
*160635*
*160635*
*160635*
*160635*

BMC Atrium Core 7.6.03 Concepts and Planning Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BMC Atrium Core 7.6.03 Concepts and Planning Guide

Uploaded by

Copyright:

Available Formats

BMC Atrium Core 7.6.

Concepts and Planning Guide

Contacting BMC Software

United States and Canada

BMC SOFTWARE INC

713 918 8800 or

(01) 713 918 8000

713 918 8000

Outside United States and Canada

(01) 713 918 8800

Copyright 2009-2010 BMC Software, Inc.

Restricted Rights Legend

Support by telephone or email

Before contacting BMC Software

Operating system and environment information

Sequence of events leading to the problem

Commands and options that you used

License key and password information

E-mail customer_support@bmc.com. (In the Subject line, enter SupID:yourSupportContractID, such

Submit a new issue at http://www.bmc.com/support.

How to use this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

About BMC Atrium Core

Overview of Business Service Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CMDB planning stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Planning the data model

Data model overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Concepts and Planning Guide

Planning BMC Atrium CMDB data

What data goes into an ITIL CMDB? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Planning data normalization and the Product Catalog

Overview of normalization and the Product Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Planning data reconciliation

Planning a service model

Service model overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Implementing BMC Atrium Core

Overview of the process to implement BMC Atrium Core . . . . . . . . . . . . . . . . . . . . . 118

Concepts and Planning Guide

Managing BMC Atrium Core

Tracking changes to CIs and relationships. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Concepts and Planning Guide

About this book

How to use this guide

Overview of Business Service

Chapter 1, About BMC Atrium Core

Concepts and information necessary Chapter 2, Planning a CMDB

Chapter 8, Implementing BMC Atrium Core

About this book

BMC Atrium Core 7.6.03

BMC Atrium Core documentation

Description and details of superclasses, subclasses,

Note: This Help is provided in HTML and is available

on the BMC Atrium Core media. It is not available

Concepts and Planning Guide

BMC Atrium Core documentation

Help for using and configuring BMC Atrium CMDB,

Users that work with CIs

BMC Atrium Core 7.6.03

Information about the BMC Atrium Core

Compatibility Matrix from the BMC Customer

Information about CMDB concepts and high-level

Anyone who wants to learn

BMC Atrium Core 7.6.03

BMC Atrium Core 7.6.03

Information about installing, upgrading, and