Concepts and Best Practices

www.bmc.com

BMC Atrium CMDB 2.1.00

Concepts and Best Practices Guide

August 2007

If you have comments or suggestions about this documentation, contact Information Development by email at [email protected].

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 INC2101 CITYWEST BLVDHOUSTON TX 77042-2827 USA

Telephone 713 918 8800 or800 841 2031

Fax 713 918 8000

Outside United States and Canada

Telephone (01) 713 918 8800 Fax (01) 713 918 8000

© Copyright 2006–2007 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 is a registered trademark of International Business Machines Corporation.

IBM is a registered trademark of International Business Machines Corporation.

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.

Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX is a registered trademark of The Open Group.

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.

http://www.bmc.com

mailto:[email protected]

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_home. 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 [email protected]. (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

http://www.bmc.com/support_home

mailto:[email protected]

Contents

Preface 9

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Best Practice and New icons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9BMC Atrium CMDB documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Related documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Chapter 1 What is BMC Atrium CMDB? 13

ITIL and Configuration Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Data is the key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Architecture of BMC Atrium CMDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Which data goes into an ITIL CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Federated data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Flexible data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Data partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Data reconciliation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Open access to data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24AR System foundation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Chapter 2 Planning your CMDB 29

Establish a Configuration Management team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Define your purpose, goal, and objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Analyze your existing environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

ITIL guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31BMC Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Identify consumers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Define your CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

CI scope and detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33CI naming conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Relationships between CIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Define your Configuration Management process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Provider segment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Reconciliation segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36CMDB segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Roles and process owners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Contents 5

Identify and justify costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Avoid potential pitfalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Chapter 3 Implementing your CMDB 41

Phased implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Migration considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Controlling the Configuration Management process . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Potential pitfalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Chapter 4 The data model 45

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Classes and attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Inheritance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Relationships. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Data storage methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Optional class characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Synchronization of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55The Common Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Configuration items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Relationships. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Further categorizing relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Sample models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Extending the data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Use the CDM with only BMC extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Use the Category, Type, and Item attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Install an extension from BMC Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Add attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Add subclasses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Naming and numbering rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Making your changes visible to applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Document your extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Chapter 5 Federated data 67

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68When to use federated data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Federating by instance or class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

By instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70By class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Federation architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Federating data in context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Storing and viewing federated data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6 Concepts and Best Practices Guide

Chapter 6 Datasets and reconciliation 75

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76What are datasets for?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76BMC Software datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Overlay datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77How overlays work. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Working with data in overlay datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Controlling client write access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Reconciling data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Namespaces and reconciliation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Identifying instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Comparing datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Merging datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Other reconciliation activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Combining activities as a job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Qualification groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Chapter 7 Administrative functionality 89

Controlling access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90BMC Atrium CMDB application roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Instance permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Specifying default instance permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93Class and attribute permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Tracking changes to CIs and relationships. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Auditing versus the Compare Dataset activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95Types of auditing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Selecting which instances and attributes are included . . . . . . . . . . . . . . . . . . . . . . 99Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Deleting CIs that are no longer discovered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101Working with discovery sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Replicating BMC Atrium CMDB data to other servers . . . . . . . . . . . . . . . . . . . . . . . . 102Adding custom workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Sample use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Filter execution order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Glossary 105

Index 113

Contents 7


Preface

The BMC Atrium CMDB 2.1.00 Concepts and Best Practices Guide describes the concepts underlying the BMC Atrium Configuration Management Database (CMDB) application, and gives best practices for establishing a Configuration Management process and using BMC Atrium CMDB to manage data about your IT environment.

AudienceThis guide is intended for anyone who wants to learn about and understand 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.

Best Practice and New iconsDocumentation for BMC Atrium CMDB contains two icons:

Icon Description

The New icon identifies features or products that are new or enhanced with version 2.1.00.

The Best Practice icon highlights processes or approaches that BMC has identified as the most effective way to leverage certain features in the application.

Preface 9


BMC Atrium CMDB documentationThe following table lists the documentation available for BMC Atrium CMDB.

Unless otherwise noted, softcopy documentation is available in the Docs directory of the product DVD and the Support site at http://www.bmc.com/support_home.

Title Document provides Audience Format

Common Data Model Diagram

Hierarchical diagram of all classes in the Common Data Model (CDM) including unique attributes and applicable relationships

Administrators Print and PDF

Concepts and Best Practices Guide

Information about CMDB concepts and best practices for planning your BMC Atrium CMDB implementation

IT leaders and administrators

Print and PDF

Data Model Help Description and details of superclasses, subclasses, attributes, and relationship classes for each class. Contains only information about the Common Data Model at first, but can be updated to include information about data model extensions you install.

Administrators HTML (product DVD only)

Developer’s Reference Guide

Information about creating API programs, using C and web services API functions and data structures, and a list of error messages

Administrators and programmers

Print and PDF

Installation and Configuration Guide

Information about installing and configuring BMC Atrium CMDB, including permissions, class definitions, reconciliation, and federation


Javadoc API Help Information about Java classes, methods, and variables that integrate with BMC Atrium CMDB

Programmers HTML (product DVD only)

Mapping Your Data to BMC Atrium CMDB Classes

Mappings of common IT objects to the appropriate class in which to store them, whether part of the Common Data Model or an extension. Also includes information about further categorizing instances using key attributes.

Administrators Spreadsheet, print and PDF

Master Index Combined index of all guides Everyone Print and PDF

Online Help Help for using and configuring BMC Atrium CMDB, available by clicking Help in the product interface

Users and administrators

Product Help (available from Help links after installed)

Release Notes Information about new features, open issues, and resolved issues

Everyone Print and PDF



Related documentation

Related documentationThe following table lists some documentation for related BMC products that might be of interest to BMC Atrium CMDB users. This documentation is available from the Support site at http://www.bmc.com/support_home.

Troubleshooting Guide Information about resolving issues with BMC Atrium CMDB components, including API, filter, and console error messages and their solutions.

Administrators, programmers, and BMC Support personnel

Print and PDF

User’s Guide Information about using BMC Atrium CMDB, including searching for and comparing CIs and relationships, relating CIs, viewing history, and launching federated data

Users Print and PDF



BMC Atrium Integration Engine 7.1.00 User’s Guide

Information about how to establish a data transfer between third-party databases and BMC Atrium CMDB.

Administrators and developers

Print and PDF

BMC Configuration Management Configuration Discovery Integration for CMDB 7.1 Implementation Guide

Information about the following:� Transferring configuration data from BMC

Configuration Management to BMC Atrium CMDB

� Normalizing discovered software configuration data with the BMC Definitive Software Library before transferring it to BMC Atrium CMDB.


Print and PDF

BMC Foundation Discovery and BMC Topology Discovery Installation and Configuration Guide

Information about the configuration of a connection between BMC Atrium CMDB and the discovery data store from BMC Foundation Discovery and BMC Topology Discovery.


Print and PDF

BMC Foundation Discovery and BMC Topology Discovery User Guide

Information about the synchronization of the topology datastore with BMC Atrium CMDB.


Print and PDF

BMC Remedy Action Request System 7.1.00: C API Reference

Information about AR System data structures, C API function calls, and OLE support.

Administrators and programmers

Print and PDF

BMC Remedy Action Request System 7.1.00: Configuring

Information about configuring AR System servers and clients, localizing, importing and exporting data, and archiving data.


BMC Remedy Action Request System 7.1.00: Form and Application Objects

Information about components necessary to build applications in AR System, including applications, fields, forms, and views.

Developers Print and PDF

Preface 11



BMC Remedy Action Request System 7.1.00: Installing

Procedures for installing AR System Administrators Print and PDF

BMC Remedy Action Request System 7.1.00: Installing and Administering BMC Remedy Mid Tier

Information about the mid tier, including mid tier installation and configuration, and web server configuration.


BMC Remedy Action Request System 7.1.00: Integrating with Plug-ins and Third-Party Products

Information about integrating AR System with external systems using plug-ins and other products, including LDAP, OLE, and ARDBC.


Print and PDF

Definitive Software Library 7.1 Administrator’s Guide

Information about installing and configuring DSL, updating vendor data, and connecting DSL to BMC Configuration Management and AR System databases




Chapter

1
What is BMC Atrium CMDB?
This chapter includes the following topics:

� ITIL and Configuration Management (page 14)� Architecture of BMC Atrium CMDB (page 16)



ITIL and Configuration ManagementIT departments face numerous challenges in providing dependable services that support a company’s business goals. Solving most of them requires a good Configuration Management strategy: without knowing what’s 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 CMDB. They realize there is a business value in having a single source of reference for their organization that provides a logical model of the IT infrastructure to identify, manage, and verify all configuration items (CIs) in the environment.

GoalsAccording to the ITIL Service Support manual1, Configuration Management should pursue these goals:

� Account for all the IT assets and configurations within the organization and its services

� Provide accurate information about configurations and their documentation to support all the other Service Management processes

� Provide a sound basis for Incident Management, Problem Management, Change Management and Release Management

� Verify the configuration records against the infrastructure and correct any exceptions

BenefitsAchieving these goals can benefit your organization in significant, measurable ways related to control, integration, and decision support.

ControlVerifying 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, reducing desktop 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 you can increase overall security.

1Office of Government Commerce, Best Practice for Service Support (London: The StationeryOffice, 2000).


ITIL and Configuration Management

IntegrationWhen processes such as Incident Management, Problem Management, Change Management, and Release Management are based on a current record of your configuration, they can be integrated, as shown in Figure 1-1. This reduces administrative costs and errors. For example, you might integrate Incident Management and Change Management processes in two 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-1: Some of the ITIL processes integrated by the CMDB

Decision SupportYour 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.

AssetManagement

ChangeManagement

CapacityManagement

ReleaseManagement

ConfigurationManagement

CMDB



Data is the keyYou can choose to begin your Configuration Management efforts with any of the processes mentioned in “Integration” on page 15 or several others. But no matter which Configuration Management processes you implement, the thing that makes them effective is the data they use.

Your configuration data must be accurate, which means it must be updated frequently. Configurations are constantly changing, so last week’s correct data could be obsolete this week. This could result in a purchase of ten servers when you only needed five, or worse, the installation of a security patch that causes a system to fail.

Your configuration data must also be available to all your IT processes, because even the most accurate data is useless if you cannot get to 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 allows you to maintain accurate configuration data that is shared by multiple IT processes is a CMDB, preferably one whose data is frequently updated by an automated discovery tool.

Architecture of BMC Atrium CMDBBMC 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. This section describes the types of data involved, the details of how the federated model separates data, and other features of BMC Atrium CMDB.

Which data goes into an ITIL CMDBITIL 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.


Architecture of BMC Atrium CMDB

Configuration itemsCIs 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 1-1 gives some examples to illustrate this boundary:

Of course, not everything that qualifies as a CI is worth tracking, so you probably will not create records in the CMDB for all the office chairs in your organization.

Relationships among CIsCIs don’t 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 allows you to see how CIs interrelate and affect one another.

Table 1-1: Example CIs and non-CIs

Configuration items Not configuration items

� A computer system is part of your environment and has configurable attributes, such as serial number, processor speed, and IP address.

� A building is part of your environment and has configurable attributes, such as number of rooms, climate control system, and alarm system.

� 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.

� A business service is part of your environment and has configurable attributes, such as criticality to the business and cost of interruption of service.

� An incident ticket has configurable attributes, but is not a direct part of your environment. It is information about other entities (a computer system, for example) that are part of your environment.

� A software package is not part of your environment—only installed instances of it are—and is usually stored in the Definitive Software Library (DSL).

� A service level agreement has configurable attributes, but is not a direct part of your environment. It is information about other entities (a Web server, for example) that are part of your environment.

� A contract has configurable attributes, but is not a direct part of your environment. It is information about other entities (a photocopier, for example) that are part of your environment.

� An event does not have configurable attributes and is not part of your environment.



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 1-2.

Figure 1-2: Example relationships

Relationships not only exist between physical CIs, but also between logical and conceptual CIs, such as the software instances and service instance in Figure 1-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 B’s 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.

Related dataThere is also a lot of information related to CIs, such as incident tickets, change events, contracts, Service Level Agreements (SLAs), a Definitive Software Library (DSL), and much more. Though these things are not CIs themselves, they contain information about your CIs and form an important part of your IT infrastructure.

NOTE Some of these types of data are considered CIs by ITIL.

Dependency

Dependency Dependency

Orders Database(Software)

Online Store(Service)

Shopping Cart(Software)

Web Server(Computer system)

Disk Drive 1 Disk Drive 2

Dependency Dependency

DependencyComponent

Server group(Collection)

Member of



BMC Atrium CMDBBMC’s implementation divides the CMDB and its infrastructure into three layers:

� The CMDB itself

� Related data linked to or from the CMDB, called the CMDB Extended Data

� Applications that interact with these two layers, called the CMDB Environment

Figure 1-3 on page 19 illustrates these three layers.

Figure 1-3: Federated CMDB infrastructure

The CMDB and CMDB Extended Data layers together make up what ITIL refers to as a CMDB.

The CMDBThe CMDB holds only instances that represent physical, logical, or conceptual 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.

SLA Management

Software Config.Management

Service ImpactManagement

Help Desk

ChangeManagement

AssetManagement

IncidentManagement

ChangeRequests

Help DeskTickets

Federated CIData

Service LevelAgreements

Contracts

Other DataRelated to CIs

DefinitiveSoftware Library

CMDB

Applications

Information related to CIs

Links BetweenRecords

Requests

ApplicationManagement

IdentityManagement

Provisioning

CapacityManagement

DiscoveryApplication 1

DiscoveryApplication 2

ProblemManagement

Requests

Requestsfor

ConfigurationData

ConfigurationItems and theirRelationships

CMDB Environment

CMDB Extended Data

ExtendedCMDB



Some of the attributes of these CIs can be links to the CMDB Extended Data. 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 the CMDB Extended Data.

Even though the CMDB doesn’t hold all attribute data or related data, it still serves as the source of record for configuration data because it links to the CMDB Extended Data. For example, you might have an instance in the CMDB representing a building, and a link to its blueprint in the CMDB Extended Data.

You can make all requests to the CMDB, and when the data 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, and is described in more detail in Chapter 5, “Federated data.”

The CMDB Extended DataThe CMDB Extended Data layer can include several data stores, as shown in Figure 1-3 on page 19. It includes the types of data specified in “Related data” on page 18 and also includes any CI attributes you judge as not important enough to track in the CMDB.

An example of the latter would be a situation where your discovery application discovers 100 attributes of each computer system on your network, but only 60 of them are critical to your business. You would import the 60 attributes from your discovery database into the CMDB and leave the other 40 in the discovery database, which is now part of your CMDB Extended Data.

The two types of data in the CMDB Extended 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 as described in Chapter 5, “Federated data,” allowing requests made to the CMDB to reach these attributes.

But for extended data that is simply related to CIs, the link can be in either or both directions. For example, a change request record could have a link through which you can access the instances of the CIs it will change, and each CI instance could have a federated link through which you can access the change requests that affect it.

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 multiple “snapshots” of configurations at particular times or states, reconciliation of data from multiple sources, and federated data.

� The overhead required to provide CMDB functionality is not wasted on data that doesn’t need it. For example, multiple snapshots of every incident ticket are unnecessary, so making your incident tickets part of the CMDB would be confusing and waste valuable storage space.



� You don’t 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 CMDB Extended Data, 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 down 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 don’t 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 doesn’t 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 you could store your CMDB Extended Data in one place, you don’t have to. The different types of data in the CMDB Extended Data layer are not necessarily linked to or related to each other. The only thing they need to have in common is a link to or from the CMDB.

The Extended CMDBTogether, the CMDB and CMDB Extended Data form the Extended CMDB. This is equivalent to the term “CMDB” as used by ITIL.

The CMDB EnvironmentWhere the Extended CMDB contains data, the CMDB Environment is devoted to the applications that provide and consume that data. These applications can access the CMDB, the CMDB Extended 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 those components are still considered to be part of different layers of the CMDB infrastructure. An application is part of the CMDB Environment, whereas its configuration-related data is part of the Extended CMDB. Of course, applications in the CMDB Environment can also access data unrelated to CIs. This data is not part of the Extended CMDB.



Federated dataAs mentioned earlier, federation refers to a central repository holding some data directly while linking to other data in other sources. You might choose to federate some attributes if you want to track them, but not as often or as vigorously as a CI’s key attributes.

These less-important attributes are the first of two types of data you can federate. This means that, for example, the CMDB record for an employee might have a Skills attribute that contains a list of the employee’s skills and a Department attribute that contains the employee’s department name. It might also have a federated link to an HR database where additional attributes, like Salary, that are not really important from a configuration perspective are stored.

The other type of data to federate is data that is related to CIs but does not consist of attributes of a CI: that is, data that refers to or is referenced by a CI to provide additional content on extended functionality to the CI but is not part of the CI itself.

For example, your CI records for software instances might have a federated link to the URL of an intranet page where the software license is posted, or each CI record might have a federated link that contains the information necessary to search a problem database for all problems concerning that CI.

The benefits of federated data include:

� You save the overhead of importing, tracking, and reconciling the data in the CMDB.

� You have a standard way to cross-reference related data.

� The federated data can be in multiple locations.

� You retain your investment in other data stores and the products and solutions using them.

For more information about federated data, see Chapter 5, “Federated data.”

Flexible data modelYou 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 don’t pertain to their CIs, leave out necessary attributes, and make it harder to search for groups of CIs.

The data model of BMC Atrium CMDB is both object-oriented and extensible, and includes a Common Data Model with classes tailored for most common types of CIs and relationships. For more information about the data model, see Chapter 4, “The data model.”



Object-orientedAn object-oriented data model has a hierarchical set of classes where each class inherits attributes from its superclass—the class above it in the hierarchy—and 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.

ExtensibleYour 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 whatever level of detail you want to track.

The Common Data ModelBMC Atrium CMDB comes with a set of CI and relationship classes called the Common Data Model (CDM). These classes represent the types of data most organizations want to store in a CMDB. The CDM is based on the Common Information Model (CIM) from the Distributed Management Task Force (DMTF) and Microsoft Windows Management Instrumentation (WMI).

Data partitioningPartitioning is the ability to divide your configuration data into subsets called datasets, each representing a logical group of CIs and relationships. This allows the same CI or relationship instances to exist in more than one 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.

For more information about datasets, see Chapter 6, “Datasets and reconciliation.”

Data reconciliationYou can have more than one dataset containing instances that represent the same real-life CIs and relationships. The reconciliation process enables you to take these instances, often obtained from different sources, and combine them into a unified view of your configuration data that you can use to make business decisions.



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 two 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 you have defined for each source dataset

For more information about datasets or reconciliation, see Chapter 6, “Datasets and reconciliation.”

Open access to dataAs mentioned earlier, even the most accurate data is useless if you can’t get to it. It is important that a wide variety of users and applications 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-4 shows some providers and consumers of BMC Atrium CMDB data.

Figure 1-4: Data providers and consumers

Open access to data includes these features:

� Programmatic access: BMC 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 Developer’s Reference Guide.

BMC RemedyAsset Management

BMC RemedyService Desk

BMC RemedyChange

Management

BMC RemedyService LevelManagement

BMC ImpactSolutions

ReconciliationEngine

BMC Atrium CMDB

OpenAPI

BMC ConfigurationDiscovery

Data providers Data consumers

Microsoft SMS

3rd Party Discovery& Asset Management

BMC AtriumIntegration Engine

BMC FoundationDiscovery andBMC Topology

Discovery



� Bulk data load: BMC Atrium CMDB provides two ways to import multiple instances at once, so that discovery applications and others can rapidly populate the database. One is the BMC Atrium CMDB APIs, and the other is the BMC Atrium Integration Engine product. This product maps and transfers data from multiple database and file formats into BMC Atrium CMDB. For more information, see the BMC Atrium Integration Engine documentation.

� Database and platform independence: BMC Atrium CMDB is compatible with multiple operating systems and database vendors to allow you flexibility with your environment. For more information about this topic, see the next section, “AR System foundation.”

AR System foundationBMC Atrium CMDB is built on the BMC Remedy® Action Request System® (AR System®) application. The AR System is a professional development environment for creating business workflow applications.

ArchitectureFigure 1-5 on page 26 shows how BMC Atrium CMDB fits into the AR System architecture. To browse class instances or configure BMC Atrium CMDB from the CMDB Console, you use a web client via the Mid Tier or the BMC Remedy User client on Windows, just as you would to access any other AR System forms.

BMC Atrium CMDB API functions are wrappers around the corresponding AR System API, which carries out the lower-level tasks that make up a BMC Atrium CMDB request.



Figure 1-5: BMC Atrium CMDB and AR System infrastructure

BMC Atrium CMDB is made up of three AR System deployable applications, one each for:

� The class forms

� The Reconciliation Engine

� The rest of the CMDB Console

For more information about AR System applications, forms, and other concepts, see BMC Remedy Action Request System 7.1.00: Form and Application Objects.

AR System server

CMDB APIs

AR System APIs

Web clients

BMC Remedy Mid Tier

Other APIprograms

BMC Remedy UserWindows clients

Database

AR System data,including CMDB data

CMDB forms(Console and classes) and

workflow

Other formsand workflow CMDB engine



BenefitsRunning on the 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 CMDB Extended Data stores, such as incident tickets and contracts.

� Built-in auditing and archiving mechanisms

� No programming required to configure

For more information about AR System concepts and architecture, see BMC Remedy Action Request System 7.1.00: Concepts.




Chapter

2
Planning your CMDB
This chapter provides best practices for planning a CMDB project. It includes the following steps, which you should perform in order:

� Establish a Configuration Management team (page 30)� Define your purpose, goal, and objectives (page 30)� Analyze your existing environment (page 31)� Identify consumers (page 32)� Define your CMDB (page 33)� Define your Configuration Management process (page 35)� Identify and justify costs (page 39)� Avoid potential pitfalls (page 40)



Establish a Configuration Management teamWhen you have decided you need a Configuration Management process that includes a CMDB, your first step should be to establish a Configuration Management team that will perform the planning tasks in this chapter and implement the CMDB.

The number of team members you choose and how many roles each plays will depend 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.

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

� AR System development

� Project management

� Business management processes

Define your purpose, goal, and objectivesYour first task should be to define the purpose, goal, and measurable objectives of your Configuration Management process.

ITIL provides these samples. They are generic, and you should be able to produce more a meaningful purpose, goal, and objectives:


Analyze your existing environment

Analyze your existing environmentYou should analyze your existing environment before defining a new environment.

ITIL guidelinesITIL recommends that you analyze:

� Owners of high-level CIs

� Current scope and resources, both people and tools

� Current Change Management and Configuration Management practices, processes, and procedures

� Current inventories of configuration data

� Roles, responsibilities and capabilities of staff involved in Configuration Management

Purpose To implement consistent Configuration Management, Change Management, and Release Management processes for operational environments, packaged applications and business systems.

Goal To bring all IT services and infrastructure components, with their associated documentation, under control and to provide an information service to facilitate the effective and efficient planning, release and implementation of Changes to the IT services.

Objectives � Provide everyone working in Service Management and Support with accurate information about present configurations

� Report the current status and history of all CIs� Report metrics on CIs, Changes, and Releases� Track and reconcile the actual state of the IT infrastructure

against authorized configuration data, and report exceptions



BMC ChecklistThis two-part checklist blends the ITIL guidelines in the previous section with BMC Software guidelines.

1 In your organization, what is the status of these processes? The table shows sample answers.

2 What are the results for your organization of the Personalized Routes to Value Assessment Tool at http://www.bmc.com/bsm/rtvassessment?

Identify consumersWhen you understand the data that CMDB consumer applications require and the tasks that they need to perform with it, you can make better decisions about which data to store in the CMDB and how to provide it. Ask these questions:

� Who is going to use the data?

� What will they do with it?

� What’s the business purpose for tracking it?

Make sure to document all consumers. If you don’t already have people on your Configuration Management team who understand the functionality of each consumer and the existing processes and procedures surrounding each consumer, add those people to your team.

ITIL process In production In planning Planned for future

No plans

Configuration Management


Change and Release Management

Remedy Change Management 6.0

BMC Remedy Change Management 7.0.02

Service Level Management

Remedy Service Level Agreements 6.0

BMC Service Level Management 7.0.02

Incident and Problem Management

Remedy Help Desk 6.0

BMC Incident Management 7.0.02, BMC Problem Management 7.0.02

Service Impact and Event Management

Yes

Asset Management and Discovery

BMC Remedy Asset Management 7.0.02, BMC Configuration Discovery 7.0.02


http://www.bmc.com/bsm/rtvassessment

Define your CMDB

Define your CMDBYour next step is to define a CMDB consistent with your Configuration Management objectives and your consumer needs. This includes the scope and detail of your CIs, naming convention for CIs, and relationships between CIs.

CI scope and detailThe scope of your CIs is the various types of data you plan to track, and their detail is the level of granularity with which you will classify them.

ITIL guidelinesITIL makes these recommendations:

� Define scope and detail to enable effective control, recording, and reporting of CIs.

� Do each of these to the level that the business requires.

� Define CI subclasses roughly to the lowest level of independent change.

BMC guidelinesBMC Atrium CMDB comes with a Common Data Model (CDM) that has a scope and detail patterned after industry standards. Use it as a starting point for defining your own scope and detail. The CDM is described in “The Common Data Model” on page 55.

Other recommendations to consider during this process are:

� Reserve the CMDB for data that:

� Is important to your business

� You want to track

� You want to perform changes against

You can store the important attributes of a CI in the CMDB and federate the others to reduce overhead.

� You don’t need to use every class in the CDM, or every attribute of the classes you do use.

� Model your data based on the needs of your consumers, not your providers. It is the providers’ job to adapt to that structure.

� If nobody will consume a particular type of data, there is no need to track it with the CMDB.

� A CMDB is for sharing data between applications. If only one application will consume a particular type of data, store the data with that application instead of in the CMDB.



� When modeling business services, be as granular as possible. You can still include higher-level services, but they will be consolidations of lower-level services that will give you better understanding of the importance of individual CIs.

� A business process is not the same thing as a business service, but rather can be a part of a service.

� Dynamic data such as an up-or-down state or current load on a server does not belong in the CMDB because it will always be out of date. Instead, store it as federated data in a source that can be updated more frequently.

� Definitional data such as a Definitive Software Library should be federated rather than stored in the CMDB. Only installed instances of an item belong in the CMDB.

� Consider future needs as well as present ones. It is easier to start tracking something later if it is already in your data model than to adjust the model at that time. Balance this against the need to manage scope.

� If you have current data stored in a legacy Remedy product and organized by Categories, Types, and Items (CTIs), document the class in the CDM that each CTI combination maps to. You will need this information when migrating your data.

CI naming conventionsYou need conventions for populating the Name attribute of different types of CIs to keep the text in your data normalized.

ITIL guidelinesITIL offers these guidelines for defining CI naming conventions:

� Reuse any existing conventions

� Make sure the conventions allow for future growth

� Use identifiers that are short but meaningful

� If the naming convention for hardware CIs is not based on suppliers’ device names and serial numbers, you need some other way to relate CIs to their suppliers.

ITIL also specifies that physical CIs should be labeled with their name as stored in the CMDB so that they can easily be identified. Recommendations:

� Use non-removable labels.

� Label all cables and lines at each end.

� Use a consistent format and color convention on the labels.


Define your Configuration Management process

BMC guidelinesAlso consider these guidelines:

� Place a layer of abstraction between logical and physical names. If you use an item’s network name as the name for the physical CI, those names will be in conflict if the CI is ever replaced.

� In the name, include an indicator of the CI’s function, such as “Computer” or “Monitor”

� Also include an identifier that ensures uniqueness, such as a numeric code. For example, “Computer1000” and “Computer1001” are unique.

� Choose a convention that allows names to be generated automatically.

� Document your naming conventions and any formulas on which they are based.

Relationships between CIsAs important as determining which CIs to store in your CMDB is determining the kinds of relationships they can have. ITIL simply recommends that all relationships be stored in the CMDB, but relationships are extremely important. They are what gives a CMDB its power by showing what effect each CI has on your business. The use of relationships is a significant difference between a CMDB and an asset database.

When creating relationships between CIs in your environment, we recommend that you use instances of BMC_Component, BMC_Dependency, and BMC_MemberOfCollection instead of their subclasses wherever possible, and use the Name attribute to categorize your relationships as described in “Further categorizing relationships” on page 58.

You should use lower-level relationship classes only in cases where the Relationship Normalization Table does not provide an applicable Name value for one of three previously mentioned classes, or where you want to use the Cascading Delete feature only for that lower-level class.

For more information about the Cascading Delete feature, see “Cascading delete” on page 49.


When you have defined your CMDB, you must define the policies, procedures, and tools that comprise your Configuration Management process. Your process should have a Provider segment, a Reconciliation segment, and a CMDB segment, with roles and owners defined for each.



Remember to consider any existing policies you gathered during the analysis phase, and to document your new process flow and policies. This is a good time to identify any areas that will require AR System customizations.

Provider segmentYou have already defined the CIs and relationships that you will track. Use those to help answer these questions when defining your Provider process segment:

� How frequently will you transfer discovered data to the CMDB?

� What data, if any, must be entered manually?

� What are the procedures for manually entering data?

� Which discovery tools will you use to collect the data you need?

� Which existing sources of data will you use?

� How frequently does your environment change?

� Which role is responsible for the discovery process?

� Which datasets will you use for discovered data?

Reconciliation segmentTo define your Reconciliation process segment, answer these questions:

� Who owns the reconciliation process?

� How frequently will you reconcile data?

� Which reconciliation jobs will you need?

Document this process segment so that you can later see it when diagnosing a problem with data reconciliation.

For more information about reconciliation, see Chapter 6, “Datasets and reconciliation.”

CMDB segmentYou should define a policy on future changes to your data model, including an approval process and a naming convention for extensions.

In addition, ITIL identifies that your CMDB process segment should provide for: CI control, status accounting, verification and audit procedures, and data cleaning and backup procedures.



CI controlAccording to ITIL, the objective of CI control is to make sure that only authorized and identifiable CIs are recorded in the CMDB. The following tasks are specified to meet this objective:

� Register all new CIs and versions

� Update CI records with regard to:

� Status and ownership changes

� Changes to other attributes

� New versions of documentation arising from changes, builds, and releases

� License control

� Related incident, problem, change, and release records

� Update and archive CIs and their associated records when CIs are decommissioned

� Protect the integrity of configurations. To make sure accurate information is available, update the CMDB after periodically checking the existence of physical items against the CMDB.

Status accountingAccording to ITIL, status accounting is the reporting of all current and historical data concerned with each CI throughout its life cycle. This enables changes to CIs to be traceable.

Verification and audit proceduresAccording to ITIL, verifications and audits are a series of reviews that verify the physical existence of CIs and make sure that they are correctly recorded in the CMDB.

Data cleaning and backup proceduresITIL recommends that the CMDB hold several snapshots of an environment allowing you to compare past, present, and planned configurations. The amount of historical information to be retained depends on its usefulness to the organization. Review your data retention policy regularly and change it if necessary. ITIL offers these guidelines:

� If the cost of retaining CI information is greater than the current or potential value, do not retain it.

� When Configuration Management has been operating for a period of time, perform regular housekeeping to make sure redundant records are deleted.

� Make backup copies of the CMDB regularly, and store them securely. It is best to keep a copy at a remote location in case of a disaster.



BMC also recommends that when cleaning your data, you:

� Archive your relationships along with CIs. When a CI is deleted, all its relationships are deleted too.

� Be aware of any cascading deletes you have enabled in your relationship classes so that you don’t accidentally delete CIs that should not be deleted. For more information about cascading deletes, see “Cascading delete” on page 49.

BMC Atrium CMDB includes an Audit feature that can keep CI and relationship history for you. For conceptual information about this feature, see “Tracking changes to CIs and relationships” on page 95. For instructions on configuring auditing, see the Installation and Configuration Guide.

Roles and process ownersTo make sure processes are followed, you must define the roles and process owners for each segment of your Configuration Management process.

ITIL guidelinesITIL offers these guidelines:

� Whether Configuration Management can be assigned with other responsibilities or requires the undivided attention of specific individuals

� Whether the Configuration Management team is to be responsible for projects as well as the IT infrastructure and services

� Whether the team is to be part of a joint Change, Configuration, and Release Management team

� The number of CIs to be controlled and the level at which control is to be maintained

� The number of staff who will be performing control activities in other groups and projects

� The extent to which support tools will be available

� The size, frequency, and complexity of Changes and Releases.

Typical roles on the Configuration Management team include the Configuration Manager and Configuration Librarian. Assign the Configuration Manager role and other key roles as early as possible so that assignees can be involved in the implementation.


Identify and justify costs

BMC guidelinesThese guidelines apply when choosing roles around BMC Atrium CMDB:

� The CMDB Administrator is responsible for defining access control and creating and maintaining CMDB classes and attributes. The administrator also monitors CMDB data by making sure the CMDB is populated, archived, and backed up according to the defined procedures.

� The Reconciliation Administrator is responsible for creating and scheduling reconciliation jobs and overseeing manual reconciliations.

Identify and justify costsAs with any project, it is important to identify all the costs involved in your Configuration Management process and make sure that the benefits justify them.

IdentifyAccording to ITIL, you should account for these costs:

� The time associated with defining your CIs and CMDB process

� Hardware and software for the CMDB environment, including licenses and maintenance

� Professional services help with implementing and customizing the CMDB and with integrating it with other Service Management tools

� Staff training

The sum of these costs is your Total Cost of Ownership (TCO). According to ITIL, 60%-90% of your TCO should be the ongoing cost of managing and supporting the Configuration Management process, so make sure you consider those along with the startup costs.

JustifyITIL offers these justifications for the costs of Configuration Management:

� Many organizations cannot function satisfactorily unless they can handle a high volume of Changes

� Without adequate control, organizations are at risk of such things as software viruses and computer theft, which carry significant costs.

� Organizations without Configuration Management typically have larger staffing requirements, both to correct problems caused by lack of control and to address planned changes and reported problems.



Avoid potential pitfallsITIL identifies these potential pitfalls for you to avoid when planning your Configuration Management process:

� Implementing without adequate design. Attempting to implement the process without having adequately analyzed and designed it will usually yield a result that is not what is required.

� No firm commitment. Proceeding without a firm commitment to the process from managers makes it difficult to introduce the controls that some staff would prefer to avoid. Get managers to commit to the process during the planning, not implementation, phase.

� Too difficult. If individuals or groups perceive the process as too bureaucratic or rigorous, they can use this as an excuse for not following the process.

� Easy to avoid. If a user’s intended result can be achieved without following the process, some users will circumvent Configuration Management for the sake of speed or with malicious intent. Restrict alternatives to the process.

� Inefficient or error-prone. Automate as much of the process as possible. Manual processes are more often inefficient and prone to error.

� Unrealistic expectations. The Configuration Management process should not be expected to make up for poor project management or poor acceptance testing. Poorly controlled installations and test environments will affect the quality of Releases, resulting in additional Incidents, Problems, and Changes. This will require additional resources.

� Improperly defining CIs. Defining classes with too much detail will create unnecessary work. Too little detail will result in inadequate control. It is also important to place your data in the correct classes of the CDM.


Chapter

3
Implementing your CMDB
This chapter discusses best practices for implementing a CMDB installation. It includes the following topics:

� Phased implementation (page 42)� Migration considerations (page 42)� Controlling the Configuration Management process (page 43)� Potential pitfalls (page 44)



Phased implementationImplementing a CMDB to manage your entire configuration at once is a daunting task, so it’s usually better to implement in phases. ITIL suggests these alternatives for breaking up the implementation:

� By company department

� By geographic region

� By support group

� By importance of CI

These alternatives are fine if you intend to use your CMDB primarily to store physical CIs. However, if you intend to also store service models, consider breaking up your implementation by critical business service.

Regardless of which types of phases you use, try to keep transition times short. While in transition, you will have to maintain both your current and former processes, which is difficult to do for long periods.

Migration considerationsAs you prepare to migrate data from existing sources to BMC Atrium CMDB, consider these 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. You don’t want to waste resources attempting to migrate something that doesn’t 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 1000 computer systems and 1000 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 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.

� An easy way to load data from many sources is to create 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.


Controlling the Configuration Management process

� When importing data from a source such as a spreadsheet or comma-separated file, you can use a regular AR System form as an intermediate storage location. This enables you to use qualifications and workflow to validate that the data made it into the 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.

Controlling the Configuration Management process

According to ITIL, you should continually assess the efficiency and effectiveness of your Configuration Management process using regular management reports. You should also schedule a review of the expected growth of Configuration Management activities on a regular basis.

ITIL recommends generating these 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 on any delays caused by Configuration Management activities

� Details on hours worked by Configuration Management staff



Potential pitfallsITIL identifies these potential pitfalls for you to avoid when implementing your Configuration Management process:

� Configuration Management in isolation. If Configuration Management is implemented without a Change Management or Release Management process, it is much less effective and the intended benefits might not be realized.

� Unrealistic expectations of supporting tool functionality. If staff and managers expect a Configuration Management tool to deliver a total solution, they might end up blaming the tool for processes or people that appear insufficient for the task.

� Tools lack flexibility. If supporting tools lack flexibility, problems can occur when they do not allow for new requirements or do not support all CI categories.

� No control. If proper configuration control is not in place, Configuration Management cannot function.


Chapter

4
The data model
This chapter explains the purpose and structure of the BMC Atrium CMDB data model. It defines the Common Data Model (CDM), offering best practices for extending the model. This chapter includes the following topics:

� Overview (page 46)� Namespaces (page 54)� Synchronization of changes (page 55)� The Common Data Model (page 55)� Extending the data model (page 60)



OverviewThe 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.

Classes and attributesThe 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 an 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. For more information about how data is stored for different types of classes, see “Data storage methods” on page 50.

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.

A class can have 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 AR System form.

ExtensibilityA 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.

InheritanceBecause 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 virtual systems. 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 4-1 on page 47 shows some of the attributes inherited along this part of the tree.


Overview

Figure 4-1: Attribute inheritance

RelationshipsA relationship class defines a type of relationship between two specific CI classes. An instance of the relationship class will therefore relate 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.

BMC_BaseElement

AccountIDManufacturerName

BMC_System

AccountIDManufacturerName(No unique attributes)

BMC_ComputerSystem

AccountIDManufacturerNameHostNameDomain

BMC_Printer

AccountIDManufacturerNameHostNameDomainAveragePagesPerMinutePaperSizesSupported



Source and destination membersThe 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. 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 4-1.

CardinalityEvery 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 one—Each instance of the source class can have this relationship with one instance of the destination class.

� One to many—Each instance of the source class can have this relationship with multiple instances of the destination class.

� Many to one—Multiple instances of the source class can have this relationship with each instance of the destination class.

� Many to many—Each 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 relationshipsIf the 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.

Table 4-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.


Overview

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 that instances of BMC_Monitor and other components related to those computer systems will be copied automatically to preserve the composite objects, even though BMC_Monitor wasn’t specified as a class to be copied by the activity.

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 allows 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 on propagating attributes for weak relationships, see the Installation and Configuration Guide.

Cascading deleteRelationship classes with a cardinality of one to one or one to many have an optional characteristic 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 feature 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 apply when you unmark a CI as deleted. Only the CI on which you set MarkAsDeleted to NULL or No (NULL is recommended) is restored.

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.



Data storage methodsThere are four methods a class can use to store its instance data, each of which is intended for a different purpose.

Regular classA regular class stores the data for its attributes in its own 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 4-2 shows the forms for a new regular class, with the lines representing a join between the superclass and the form containing the non-inherited attributes of the new class.

Figure 4-2: Regular class

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 don’t 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.

New Class (NC) form

Superclass (SupC) 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]

New Class (NC) join form

NC_Attribute1 NC_Attribute2

NC_Instance1 [value] [value]

NC_Instance2 [value] [value]

SupC_Attribute1 SupC_Attribute2 SupC_Attribute3

SupC_Instance1 [value] [value] [value]

NC_Instance1 [value] [value] [value]

NC_Instance2 [value] [value] [value]


Overview

Categorization classA categorization class does not have its own AR System regular form. Its non-inherited 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 4-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 4-3: Categorization class

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.

Stub form

SupC_Attribute1 SupC_Attribute2 SupC_Attribute3 NC_Attribute1

SupC_Instance1 [value] [value] [value]

NC_Instance1 [value] [value] [value] [value]



SupC_Attribute1 SupC_Attribute2 SupC_Attribute3 NC_Attribute1



New Class (NC) join form



Abstract classAn abstract class does not have its own AR System form and cannot hold any instances. It exists only to organize subclasses, allowing 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 4-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 4-4: Abstract class

An example of an abstract class in the CDM is BMC_SystemComponent.

Abstract class with data replication

NOTE Abstract classes with data replication are not commonly used. They are intended for special cases.

Subclass 2(SubC2) form


SupC_Attribute1 SupC_Attribute2

SupC_Instance1 [value] [value]

SubC1_Instance1 [value] [value]


SupC_Attribute1 SupC_Attribute2 NC_Attribute1 NC_Attribute2 SubC1_Attribute1

SubC1_Instance1 [value] [value] [value] [value] [value]

Subclass 1 (SubC1) join form




NC_Attribute1 NC_Attribute2 SubC2_Attribute1

SubC2_Instance1 [value] [value] [value]



New Class (NC)




Overview

An abstract class with data replication is like an abstract class, except that instances of its subclasses are replicated to a form that holds only the attributes of the abstract class. This means that although you cannot create instances of the class, you can search on it as you could with any regular class that had subclasses. Searching on an abstract class with data replication finds all instances of its subclasses that match the search qualification, but only retrieves the attributes of the abstract class.

Figure 4-5 shows the forms for a new abstract class with data replication and two subclasses created from it. The green lines represent the joins between the superclass and the forms containing the new subclasses’ attributes, and the blue lines represent data being replicated up to the level of the new class.

Figure 4-5: Abstract class with data replication

There are no examples of an abstract class with data replication in the CDM.







SupC_Attribute1 SupC_Attribute2

SupC_Instance1 [value] [value]




SupC_Attribute1 SupC_Attribute2 NC_Attribute1 NC_Attribute2

SubC1_Instance1 [value] [value] [value] [value]

SubC2_Instance1 [value] [value] [value] [value]

New Class (NC)


New Class (NC) replication form









Optional class characteristicsThere are two optional characteristics that can be set for a class. These characteristics limit what you can do with the class. Although they can be set for a class of any type or data storage method, there is no benefit to using them with either kind of abstract class.

Final

A final class cannot have subclasses, which allows you to control your data model.

Singleton

A singleton class can have only one instance.

NamespacesYou can partition your data model by using namespaces. Unlike datasets, which partition instance data, namespaces partition classes and attributes in the data model. This allows you to specify the provider or consumer of a certain type of data, or to make other arbitrary groupings. For instance, all classes in the Common Data Model are in the BMC.CORE namespace, and other classes provided by BMC Atrium CMDB that hold information such as federated data definitions are in the BMC.CORE.CONFIG namespace. In versions 1.0 and 1.1 of BMC Atrium CMDB, both of these types of classes were in the BMC namespace.

Other BMC Software products that extend the data model, such as BMC Impact Solutions or BMC Foundation Discovery and BMC Topology Discovery, create their own namespaces to hold the new classes and attributes. Likewise, BMC extensions that are distributed independently of BMC products use their own namespaces.

Namespaces can be applied at the attribute level as well as the class level. This means that some, or even all, of the attributes of a class can reside in a different namespace from the class itself. This is useful when you have a class that is used for more than one purpose, but one of those purposes requires an extra attribute.

A namespace serves as a label to identify classes that serve different purposes and serves also to create unique names. A namespace is prepended to the names of its class forms, though not its attribute fields. Therefore a class you create in one namespace can have the same name as an existing class in another namespace. However, attributes of the same class in different namespaces cannot share the same name.

Namespaces do more than just serve as a logical categorization system for your data model. Because many reconciliation definitions allow you to specify namespaces, you can easily target a reconciliation activity to only include data that is being stored for a particular purpose. Instead of creating a lengthy qualification to select or omit several specific classes, you can include or omit them from an activity by specifying their namespace.


Synchronization of changes

Whenever you extend the data model, you should use your own namespace instead of BMC.CORE. This prevents your extensions from being overwritten by new BMC classes when you upgrade to a future version of the CDM. When creating namespaces, use the naming convention COMPANYNAME.PURPOSE. For example, if the Acme Company created a set of classes for storing data about buildings and other facilities-related CIs, they might store them in the namespace ACME.FACILITIES.

Synchronization of changesWhen you add or modify a class, it is not available to use immediately. The changes you made to the metadata must be translated into forms and workflow on the AR System server, a process called synchronization.

While synchronization is in progress, a new entry appears in the table in the Class Manager Console with a status of Change Pending. If you are modifying an existing class, its original entry with Active status remains in the table.

For information about synchronization error messages and instructions for canceling a failed pending change, see the Installation and Configuration Guide.

The Common Data ModelThe 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. All classes in the CDM reside in the BMC.CORE 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 version 2.1.00, see Appendix A of the Installation and Configuration Guide.

The following sections list the base classes in the CDM and their direct subclasses, and explain their intended uses. For information about the complete structure and class details of the CDM, see the Common Data Model Diagram and the 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 Classes. This document, new in version 2.1.00, maps common items to classes both in the CDM and in BMC Software extensions.

Configuration items

BMC_BaseElementAs 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 will 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_AccessPointThe BMC_AccessPoint class represents the ability to utilize or invoke a service. Its subclasses include different types of endpoints such as IP endpoints and LAN endpoints.

BMC_CollectionBMC_Collection and its subclasses store information about physical collections, such as subnets and LANs, and logical collections, such as roles and user communities.

BMC_DocumentBMC_Document stores information about documentation in your environment.

BMC_EquipmentThe BMC_Equipment class stores information about physical equipment that is not related to computing. This can include buildings, vehicles, and other facilities items.

BMC_LogicalEntityThe BMC_LogicalEntity class tree provides mechanisms for grouping configuration items together into logical elements. This includes business processes, services, and physical locations.


The Common Data Model

BMC_PersonThe BMC_Person class stores information about the people who manage and depend on the other CIs in your environment.

BMC_SettingsThe BMC_Settings class, new in version 2.1.00, is an abstract class under which you can create subclasses to provide additional settings information about a managed element.

BMC_SystemThe 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_SystemComponentThe BMC_SystemComponent class stores information about the components that comprise 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_SystemServiceThe BMC_SystemService class contains the information necessary to represent and manage the functionality provided by a device or software feature.

Relationships

BMC_BaseRelationshipAs 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 will 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_ComponentBMC_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_DependencyBMC_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_ElementLocationBMC_ElementLocation relates any configuration item to a physical location in your environment.

BMC_MemberOfCollectionBMC_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.

Relationship subclassesMost of the classes listed in this section have subclasses that help further define a relationship. These subclasses, which are all categorization classes, can have additional attributes, but most often further define a relationship only by using different CI classes as their members.

Further categorizing relationshipsWhen creating relationship instances, you should populate the Name attribute according to the Relationship Normalization Table in Mapping Your Data to BMC Atrium CMDB Classes and also 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 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 in the Name attribute.

By using only the Name values from the Relationship Normalization Table you maintain consistency with relationships created by BMC Software products, increasing the accuracy of reconciliation. In future releases, compliance with the values in this table will be required for compatibility with BMC Software products.


The Common Data Model

Sample modelsThese two scenarios show ways that you can use the classes in the CDM to model your data. In the figures, the boxes hold CI classes and the lines hold relationship classes.

Computer systemHere are the classes to use for a typical computer system. It has Windows 2000, a BIOS, Microsoft Word, a video card, and uses a network printer.

Figure 4-6: Classes used for a computer system and components

Computer system in a LANHere are the classes to use for a computer system’s participation in a LAN. The computer system is in an IP subnet that is part of the LAN.

Figure 4-7: Classes used for a computer system in a LAN



Extending the data modelThe 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 there are still some IT infrastructures that 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.

For a data model with the greatest simplicity and performance, your best choices are ranked in this order:

1 Use the CDM with only BMC extensions

2 Use the Category, Type, and Item attributes (page 61)

3 Install an extension from BMC Software (page 62)

4 Add attributes (page 62)

5 Add subclasses (page 62)

If you decide to add attributes or subclasses:

� Perform the work using the Class Manager, an API program, or the cmdbdriver program. Never make changes directly on class forms using BMC Remedy Administrator. 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 Administrator to modify field layout and labels.

� Because a CMDB gets its value by sharing data between 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.

� Don’t create classes more than five database join levels deep. For information about which types of classes involve joins, see “Data storage methods” on page 50.

Use the CDM with only BMC extensionsJust 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.

The CMDB should hold only common CIs and their relationships. Adding classes and attributes for unimportant CIs needlessly 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.


Extending the data model

Learn the classes and their attributesYour first step in deciding whether to extend your data model should be understanding the CDM and the extensions supplied by BMC products. Study the Common Data Model Diagram and Data Model Help in the Docs directory of the product DVD, and the documentation for BMC products you own that integrate with BMC Atrium CMDB.

By reading about the classes you have, you will hopefully find existing classes that can serve your needs, or if not, at least find the best class or classes to extend.

Decide which data belongs in the CMDBBMC Atrium CMDB is designed to hold data about CIs, which are physical, logical, or conceptual entities in your IT infrastructure. For example, computer systems, buildings, employees, installed software, and business services are all examples of CIs. Change requests, incidents, and problems are not part of your infrastructure, and should not be stored in your CMDB. Instead, they should be linked to from related CI instances in the CMDB.

Also, not every type of CI should be stored in your CMDB. There are many items in your infrastructure that qualify as CIs but that aren’t important enough to warrant the overhead necessary to store them in the CMDB. For more information, see “CI scope and detail” on page 33.

Use the Category, Type, and Item attributesIf you need to further categorize a CI class that has the specific attributes you need, consider using the existing Category, Type, and Item attributes instead of creating attributes or subclasses. These three attributes are part of the BMC_BaseElement class and are thus inherited by all other CI classes. You can use them to provide three 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. If you want 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. If you need to have different relationships for each category, type, and item, you should create subclasses for them instead of using this strategy.



Install an extension from BMC SoftwareBMC Software provides extensions that address common needs for extending the data model. Each extension provides extra classes and attributes for a specific type of configuration data, such as J2EE or SAP objects. These extensions are available with products such as BMC Foundation Discovery and BMC Topology Discovery and BMC Remedy Asset Management.

Add attributesIf an existing class describes your CI well but lacks a few pieces of information, there is no need to create a subclass to hold those extra attributes. Add attributes to the existing class to store that information while avoiding the performance cost of a subclass. If you will need to store some CIs that use these attributes and some that don’t, 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” on page 65.

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 your changes visible to applications” on page 65.

Add subclassesBefore you decide to add classes for CIs and relationships, consider the alternatives described in the previous sections. When one of them 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.



As an example of the third scenario, take BMC_HostedSystemComponent, a relationship class that relates a system to a system component. If you needed more specific relationship types, 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. The following sections recommend situations in which to use each data storage method and the Final and Singleton options.

If you decide to create subclasses, follow the class naming rule in “Naming and numbering rules” on page 65.

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 your changes visible to applications” on page 65.

Regular classThis is the most straightforward way to create a subclass, but 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 non-inherited attributes or that have any non-inherited 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 1000 instances, regardless of how many its superclass will contain, you might want to make it a regular class because that allows you to create indexes on it to improve search performance.

Categorization classUse categorization classes for CIs that have five or fewer non-inherited attributes—none of which are required—and that have relationships to different classes. Use them for most of your relationship subclasses, because those subclasses often have no non-inherited 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 classUse 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 allow a common relationship type for those subclasses. If you need to work with any instances of the class, instead use an abstract class with data replication, which is described in the next section.



The classes BMC_System and BMC_SystemComponent are examples of abstract classes created to allow 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 replicationAn 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.

Final optionUse 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 don’t have to account for subclass data that is stored with the class.

Singleton optionUse singleton classes 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 company’s CEO so that you can model the impact of particular IT resources on the CEO.



Naming and numbering rulesIf you create new classes or attributes, you should:

� Name new classes with a prefix other than BMC_ to identify them as your own, and make the body of the name descriptive.

� Give attributes 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 above 536870911 allows you to create custom 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, so therefore you should only share workflow between a BMC Atrium CMDB form and a form that is not part of BMC Atrium CMDB. See the AR System documentation for information about sharing workflow and other benefits of specifying a field ID.

BMC Software reserves numbers 536870911 and lower.

Making your changes visible to applicationsWhen 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.

AR System applicationsSome 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. BMC Atrium CMDB has the ability to generate these join forms for such an application and arrange the fields according to view templates specified by the application. For information about using this feature, see the Installation and Configuration Guide.

BMC Impact SolutionsTo 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.



Document your extensionsJust as you need to occasionally look up information about classes in the CDM, you will need to look up information about classes and attributes you create. You should enter descriptions for each in the Description fields available in the Class Manager.

In version 2.1.00 you can generate an updated version of the Data Model Help—the HTML help system that provides information about the data model—to reflect your current data model. You should generate new Data Model Help after you enter descriptions for the classes and attributes you add. Those descriptions are included in the help.

For instructions on generating updated Data Model Help with the cdm2html utility, see the Installation and Configuration Guide.


Chapter

5
Federated data

� Overview (page 68)� When to use federated data (page 69)� Federating by instance or class (page 70)� Federation architecture (page 71)� Federating data in context (page 71)� Storing and viewing federated data (page 74)



Overview 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.

Figure 5-1 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 5-1: Federated data

NOTE Federated data is not bidirectional. BMC Atrium CMDB can only establish links from its own data to an external source, not from the external source to itself.

BMC Atrium CMDB

Incident ID: 0001Category: PerformanceMachine: Computer A

Computer System Name: Computer ARegistry settings: XYZ

Discovery DB

Incident DB

BMC_ComputerSystem

Name: Computer ASystemType: DesktopNumberOfSlots: 4


When to use federated data

When to use federated dataThough 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. Given this general strategy, here are a few more considerations and recommendations when deciding which data to federate:

� Creating federated links to your existing 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 don’t 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.

� Choose to 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.

� Choose to federate attributes that will not be used to make business decisions.

� Choose to federate data such as change requests or incident records that are not CIs, but information about CIs.

� Choose to federate definitional data such as a Definitive Software Library.



Federating by instance or classLinking to federated data can be done either at the instance level or the class level.

By instanceLinking at the instance level creates a relationship between one instance in BMC Atrium CMDB and an interface to a particular piece of federated data. You must create a separate link for each instance from which you want to access federated data. This type of federated link is useful when you want to restrict access to the federated data. For example, if your CEO has a very expensive monitor and it is the only monitor in your environment for which an extended warranty was purchased, you might create a link from that monitor instance in BMC Atrium CMDB to information about the extended warranty.

By classLinking at the class level allows you to specify one link that connects, for example, all computer systems in your environment to the incident records that pertain to them. You can optionally specify that the link applies to only a subset of computer systems by adding a qualification.

Linking at the class level creates a relationship between one BMC Atrium CMDB class and an interface to a particular piece of federated data. This method is the best practice in most cases.


Federation architecture

Federation architectureBMC Atrium CMDB uses several types of objects to implement federation. Figure 5-2 illustrates these objects, each of which is represented by a class in the BMC Atrium CMDB metadata.

Figure 5-2: Federation objects

A CI class or instance has a federated link relationship to a federated interface, which defines the information necessary to access a particular piece of federated data. This information might be a URL or a query against an AR System form.

The federated interface has a federated product link relationship from a federated product, which names a product that acts as a federated data store. Because a product might offer several types of federated data, each federated product can be linked to multiple federated interfaces.

If foreign key substitution is used, the federated product 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. For more information about foreign key substitution, see “Foreign key substitution” on page 72.

Federating data in contextThe value in federated data comes from being able to retrieve data in context. That is, you want data that is relevant to the CI from which you’re accessing a link, not every piece of data an external source has to offer. BMC Atrium CMDB offers two ways to do this: attribute substitution and foreign key substitution.

Federated link

Federated link

Federated key linkKey value

Federatedproduct link

Federated productCI instance

CI class

Federated interface

Federateddata store

CMDB



Attribute substitutionThis is the more straightforward method of federating data in context. The information in a federated 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 allows it to access a different set of federated data for each instance of the class.

Figure 5-3 shows an example of this. The value of the Name attribute is substituted in to the federated 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.”

Figure 5-3: Attribute substitution

Foreign key substitutionSome federated products do not store any data that also exists as attributes of CIs in BMC Atrium CMDB, which means 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 federated product that maps to a specific CI.

Incident ID: 0001Category: PerformanceMachine: Computer A

Incident

ID: 0002Category: ConnectivityMachine: Computer B

Incident DB

BMC_ComputerSystem


BMC_ComputerSystem

Name: Computer BSystemType: LaptopNumberOfSlots: 2

CMDB

Federated Product

Incident DB

Federated Interface

Show records where'Machine' = $Name$


Federating data in context

In addition to the relationship between the CI (or its class) and a federated interface that is required for any federation, using a foreign key also requires a relationship between the CI and the federated product, containing the key. This relationship allows the key to be substituted in to the information in a federated interface whenever a link to that interface is launched from that CI.

Figure 5-4 on page 73 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 federated 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.

Figure 5-4: Foreign key substitution

NOTE You can get the same functionality by adding an attribute to classes in the CDM 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 allows you to instead use attribute substitution.

This provides faster performance when accessing federated data and eliminates the management of federated key relationships. You should only add an attribute in BMC Atrium CMDB if the attribute will be populated for most instances of the class.

Incident DB

CMDB

Federated Product

Incident DB

Key = 0002

Key = 0001

Federated Interface

Show records where 'ID' =$#Key#$

Incident ID: 0001Category: Performance

Incident

ID: 0002Category: Connectivity

BMC_ComputerSystem


BMC_ComputerSystem

Name: Computer BSystemType: LaptopNumberOfSlots: 2



Storing and viewing federated dataA federated interface can use one of four methods to access federated data:

� A query against an AR System form

� A URL

� An executable process on the BMC Atrium CMDB machine

� Text specifying how to manually access the data

NOTE Though there is no direct method of accessing federated data in an external database, you can store federated data in such a database and use one of the methods listed here to access it indirectly. For example, you could use the URL method to access any database to which you allow browser access, and you could use the AR System query method to access data through a vendor form and AR System database connectivity (ARDBC).

For more information about vendor forms and ARDBC, see BMC Remedy Action Request System 7.1.00: Integrating with Plug-ins and Third-Party Products.

You can launch a federated interface in context from a selected CI in the CI Relationship Viewer. Launching opens the specified application and passes it the access string specified in the federated interface. For instructions, see the User’s Guide.

You can also use an API program to return the access string for a federated interface and optionally also launch it.


Chapter

6
Datasets and reconciliation

� Overview (page 76)� Overlay datasets (page 77)� Controlling client write access (page 79)� Reconciling data (page 79)



OverviewA dataset is a collection of CIs and relationships for a given purpose. Together they form a picture of some state or time or configuration. Within a dataset, there can be only one instance of a given CI. An instance might also exist for that CI 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.

All CIs and relationships in BMC Atrium CMDB reside “in” a particular dataset, meaning they have a DatasetId attribute that must contain a value. You cannot have an instance that is not in a dataset.

What are datasets for?Datasets are arbitrary partitions of your configuration data. Partitioning is a powerful tool that you can use for many purposes. For example, datasets could represent:

� Production data

� Obsolete data

� A future state

� Data provided by different discovery applications

Your datasets don’t all have to contain different versions of the same set of CIs and relationship. You could also have datasets to hold:

� Subsets of your overall data such as departments or regions

� Data from different companies for multitenancy

� Test data

� Other ideas you can invent

BMC Software datasetsBMC Atrium CMDB comes with two datasets already created. One, BMC Sample Dataset, is intended as a safe place for you to do testing. The other is named BMC Asset, and BMC applications use it as the production dataset. The production dataset is the dataset that you treat as your “single source of reference” and that you use to make business decisions. BMC Remedy IT Service Management applications also use a dataset named BMC.ASSET.SANDBOX as a staging area for changes before reconciling them to BMC Asset.


Overlay datasets

BMC discovery applications load their data into other datasets they create. For example, BMC Foundation Discovery and BMC Topology Discovery puts data into the BMC Topology Import dataset and BMC Configuration Discovery puts data into the BMC Configuration Import dataset. These applications also install reconciliation definitions so that you can reconcile data from their datasets into BMC Asset.

Overlay datasetsBMC Atrium CMDB offers overlay datasets, which allow 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 only applies to BMC Atrium CMDB API clients. If you use the CMDB 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 workWhen 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 for 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 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 an overlay dataset.

Figure 6-1 illustrates two 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 6-1: Query to an overlay dataset

TIP Use an overlay dataset to make changes during a day, then reconcile it into your production dataset at the end of the day when the change requests for them are approved.

Working with data in overlay datasetsWhen working with data in overlay datasets, it is important to understand how deleting works and how instance ID and identity relate between overlay dataset and underlying dataset.

Deleting instancesIf you attempt to delete an instance from an overlay dataset that actually exists there, the instance is deleted only from the overlay dataset and remains in the underlying dataset. If you attempt to delete an instance from an overlay dataset that only exists 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.

BMC_ComputerSystem

InstanceId: 3ReconciliationIdentity: 8Name: Computer BSystemType: DesktopNumberOfSlots: 5

BMC_ComputerSystem

InstanceId: 2ReconciliationIdentity: 8Name: Computer BSystemType: LaptopNumberOfSlots: 2

BMC_ComputerSystem

InstanceId: 1ReconciliationIdentity: 7Name: Computer ASystemType: DesktopNumberOfSlots: 4

API QueryDatasetId: SandboxQualification: 'Name' = "Computer A"

ResultsSystem Type: DesktopNumberOfSlots: 4

Overlay dataset "Sandbox"

Regular dataset "Production"

API QueryDatasetId: SandboxQualification: 'Name' = "Computer B"

ResultsSystem Type: DesktopNumberOfSlots: 5


Controlling client write access

Instance ID and identityWhen 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.

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 Identification rules should be able to match these instances so that they receive the same identity.

WARNING For each modification 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 accessBy 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.

Reconciling dataWith multiple data providers loading data into multiple datasets of BMC Atrium CMDB, you need a reconciliation process to enable you to compare expected data against discovered data and create one complete and correct production dataset. BMC Atrium CMDB has a component called the Reconciliation Engine that performs the three main reconciliation tasks of identifying, merging, and comparing datasets and also gives you other tools for working with datasets.



Namespaces and reconciliationAlmost all reconciliation definitions operate only on classes within a particular namespace. Even if an instance matches the qualifications you specify (see “Qualification groups” on page 86), if its class is not in the specified namespace it cannot participate in reconciliation.

You can specify multiple namespaces or even choose an option that lets a definition operate in all namespaces. This gives you maximum flexibility when working in a CMDB that has several data model extensions installed, each using its own namespace. You can reconcile only CDM classes, only the classes from a particular extension, or any combination thereof.

Identifying instancesBefore you can compare or merge different versions of something, you must determine that they indeed represent the same entity.

OverviewIdentification accomplishes this matching by applying rules you specify against instances of the same class in two or more different datasets.

For example, a rule intended to identify computer system instances might specify that the IP addresses of both instances be equal. When the rules find a match, both instances are tagged with the same reconciliation identity, an extra attribute showing that they each represent the same item in their respective datasets.

You can also manually identify instances that failed to be identified by the rules in an Identification activity.

NOTE An instance must be identified before it can be compared or merged.

Working with identificationTo identify instances, you must create an Identification group for each participating dataset. This group contains Identification rules that attempt to match instances of a particular class in that dataset against instances in all other participating datasets. For example, if you want to identify datasets A, B, and C you need three groups: one each to match A against B and C, B against A and C, and C against A and B.

If you need to identify data in different classes based on different criteria, you must create more Identification groups. But the groups are inherited by subclasses of the class specified, so if the text in your data is sufficiently normalized you could specify groups only for the base class BMC_BaseElement.


Reconciling data

You then create an Identification activity and associate the Identification groups to it. One of the participating datasets is designated 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 doesn’t already have an identity, one is automatically generated.

TIP If you are identifying a class between two datasets that are poorly normalized and you cannot find any 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’s installed, you can match two disk drives based on the fact that their source computer systems have the same name, because BMC_HostedSystemComponent propagates the Name attribute from system to component.

For more information about propagating attributes, see “Weak relationships” on page 48.

For more information about identifying, see the Installation and Configuration Guide.

Comparing datasetsComparison operates against instances in two datasets and either produces a report or executes workflow based on the comparison results. The report shows those instances that appear in only one of the datasets and details the differences between instances that appear in both.

OverviewComparison lets you compare an expected configuration against an actual one, which you could use for more than one purpose. You might use comparison 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 comparison to verify that the configuration reaches its expected new state.

Only instances that have been given an identity can be compared, and 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.



Working with comparisonTo compare instances, you must create a Comparison activity and specify the two datasets you want to compare. From that activity you can choose to exclude particular attributes from the comparison by creating Exclusion rules for them.

If you want to execute workflow as a result of the comparison, you must also create a Workflow Execution group to associate with the Comparison 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 AR System filters to perform the needed workflow for each Workflow Execution rule.

For more information about comparing, see the Installation and Configuration Guide.

Merging datasetsMerging takes two or more datasets and creates a composite dataset according to precedence values you specify.

OverviewMerging 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 as a test. To take advantage of the areas of strength in each dataset, you create precedence values that favor those strengths. This gives you one CI instance with the best of all discovered data.

Only instances that have been given an identity can participate in a merge. 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.

Working with mergeYou 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 two 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, only processing the attribute values that have been modified since the activity was last run. If an attribute value hasn’t changed, there is no need to merge it again.


Reconciling data

One Merge activity

In previous versions, this was the only available method of merging datasets. 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-2 on page 83 provides an example of precedence values being applied when two datasets are merged with a single Merge activity.

Figure 6-2: Single Merge activity with two source datasets

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 B’s. 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.

2

1

Dataset A (500)

Computer System

IPAddress (200): 10.20.30.50SystemType: Laptop

Application System (200)

Monitor

Dataset B (300)

Computer System

IPAddress: 10.20.30.60SystemType: Desktop

Application System

Monitor

Dataset C (100)

Computer System


Application System

Monitor

Dataset C (100)

Computer System

IPAddress (300): 10.20.30.60SystemType (500): Laptop


Monitor (500)



Independent Merge activities

This is the recommended method of merging datasets, and it uses only one source dataset per Merge activity. After each Merge activity runs, the target dataset retains—for each attribute that was merged—the 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.

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 allows you to add new source datasets in the future without redoing all your Merge activities. Figure 6-3 on page 84 provides an example of precedence values being applied when two datasets are merged with independent Merge activities.

Figure 6-3: Independent Merge activities, each with one source dataset

This example uses the same source and target datasets as the example in Figure 6-2 on page 83, and achieves the same end result. Step 1 again shows the data in the target dataset before the merge.

2

1

3

Dataset A (500)

Computer System

IPAddress (200): 10.20.30.50SystemType: Laptop


Monitor

Dataset B (300)

Computer System


Application System

Monitor

Dataset C (100)

Computer System


Application System

Monitor

Dataset C (100)

Computer System


Monitor (500)

Dataset C (100)

Computer System



Monitor (500)



Reconciling data

In the Merge activity represented by step 2, Dataset A is merged into Dataset C. Dataset A’s precedence values at every level are higher than Dataset C’s, so after this step Dataset C contains all the data from Dataset A. You can also see that though Dataset C’s precedence value is still 100, the precedence values of the data in it have been adopted from Dataset A.

In the Merge activity represented by step 3, Dataset B is merged into Dataset C. Dataset B’s 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 B’s 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 Installation and Configuration Guide.

Other reconciliation activitiesThe Reconciliation Engine offers several other activities besides Identification, Compare, and Merge.

Rename DatasetThe Rename Dataset activity renames a dataset. It does not change the DatasetId, so all reconciliation definitions that include the dataset still work with the new name.

Copy DatasetThe Copy Dataset activity copies 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 DatasetThe Delete Dataset activity deletes instances from one or more datasets. It does not delete the dataset itself.

Purge DatasetThe Purge Dataset activity deletes 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 only want to purge instances that are marked as deleted in your production dataset.

Execute JobThe Execute Job activity executes a reconciliation job.



Combining activities as a jobYou can only create and execute reconciliation activities as part of a job, which can contain multiple activities and performs them in the sequence 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 AR System workflow

When you use 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 allows you to reuse reconciliation definitions with multiple overlay datasets and with subsets of data. For more information about dynamic dataset and qualification substitution, see the Installation and Configuration Guide.

Qualification groupsMost reconciliation activities allow you to specify a Qualification group for the purpose of restricting 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, you might create a Qualification group that selects instances that were discovered within the last 24 hours and have the domain “Frankfurt” if your company just opened a Frankfurt office and you are reconciling its discovered CIs for the first time.


Reconciling data

Best practicesThis section gives you several best practices for working with reconciliation.

� Create all your reconciliation definitions at the highest class level possible to take advantage of inheritance.

� After your initial data load into BMC Atrium CMDB, perform an Identification 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 AR System server for use only by the Reconciliation Engine.

� To get the most use out of discovered data, reconcile it into your production dataset immediately after your discovery application loads data into BMC Atrium CMDB.

� Don’t create multiple jobs that merge data into the same target dataset, because this creates the potential for one job to overwrite data you wanted to keep from the other job. If you want to split a merge into multiple jobs, do it by classes so that the two jobs don’t touch the same parts of your data.

� Regularly review your Identification rules to make sure they’re 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.




Chapter

7
Administrative functionality

� Controlling access (page 90)� Tracking changes to CIs and relationships (page 95)� Deleting CIs that are no longer discovered (page 101)� Working with discovery sources (page 102)� Replicating BMC Atrium CMDB data to other servers (page 102)� Adding custom workflow (page 103)



Controlling accessBMC Atrium CMDB offers a flexible permissions model that lets you grant role-based permission to areas of BMC Atrium CMDB functionality and grant row-level 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 is able to access only their own data. Each party whose data is represented in the CMDB is considered an account.

For each class, you can specify default read and write permissions for separate accounts, which are applied to newly created instances. You can also specify default permissions for all classes that don’t have specific permissions defined. These default permissions can be overwritten by permissions specified for a particular instance.

BMC Atrium CMDB application rolesThe BMC Atrium CMDB class forms are encompassed by an AR System deployable application named BMC:Atrium CMDB. When new classes are created, they are automatically added to the application. This deployable application allows users to manage permissions with AR System roles. The CMDB Console and Reconciliation Engine also use application objects named AtriumCMDBConsole and REApplicationDeployable, respectively.

Several permissions roles are available for these deployable applications to allow you to give your people the appropriate permissions they need to do their jobs. Table 7-1 lists the permissions roles:

Table 7-1: BMC Atrium CMDB permissions roles

Name Application Users with this role can

CMDB Data View BMC:Atrium CMDB View class instances. Works in conjunction with the CMDBRowLevelSecurity and CMDBWriteSecurity attributes. See “Instance permissions” on page 92.

CMDB Data Change BMC:Atrium CMDB View, create, and modify class instances. Works in conjunction with the CMDBRowLevelSecurity attribute. See “Instance permissions” on page 92.

CMDB Data View All BMC:Atrium CMDB View all class instances. Not dependent on the CMDBRowLevelSecurity attribute for row-level security.

CMDB Data Change All

BMC:Atrium CMDB View, create, and modify all class instances. Not dependent on the CMDBRowLevelSecurity attribute for row-level security.


Controlling access

CMDB Console User AtriumCMDBConsole

� Access the CMDB Console, but cannot see the Administration menu or Job Summary on the CMDB Home tab

� Perform searches from the CMDB Console if they also have one of the two CMDB Definitions roles

� View federation definitions� Launch applications in context� View instance history from the CMDB

Console if they also have one of the two CMDB Definitions roles, row-level security on the audited instances, and permissions on the audit or log form

CMDB Console Admin

AtriumCMDBConsole

� Access the CMDB Console, including the Administration menu on the CMDB Home tab and, if they also have the CMDB RE User or CMDB RE Definitions Admin role, including the Job Summary

� Perform searches from the CMDB Console if they also have one of the two CMDB Definitions roles

� View, create, modify, and delete public searches

� View, create, modify, and delete federation definitions

� Launch applications in context� View instance history from the CMDB

Console if they also have one of the two CMDB Definitions roles, row-level security on the audited instances, and permissions on the audit or log form

CMDB Definitions Viewer

AtriumCMDBConsole

� View class definitions� This role also enables class menus in the

CMDB Console windows for searching, creating, and comparing instances.

CMDB Definitions Admin

AtriumCMDBConsole

� View, create, modify, and delete class definitions

� This role also enables class menus in the CMDB Console windows for searching, creating, and comparing instances.

CMDB RE User REApplicationDeployable

� View jobs, activities, and groups� Start and cancel jobs� View the Job Summary on the CMDB

Home tab if they also have the CMDB Console Admin role





NOTE Users with the CMDB Data View and CMDB Data View All roles can create instances, but only for classes where all required attributes have either a default value or the Allow Any User to Submit option enabled. By default, this is not true for the classes in the Common Data Model.

For the application’s Production state, the CMDB Data View and CMDB Data Change roles are each mapped by default to a computed group. This allows you to assign the roles, which are likely the most widespread in your organization, to more than one AR System group. For more information about AR System application roles and computed groups, see BMC Remedy Action Request System 7.1.00: Form and Application Objects.

Instance permissionsThe CMDB Data View and CMDB Data Change roles described in “BMC Atrium CMDB application roles” on page 90 do not completely control access to instances in BMC Atrium CMDB. They control access to the contents of instances in general. But to view or modify a specific instance, a user must also have row-level security to that instance. Row-level security is controlled by an attribute that exists on every class. There is also an attribute that controls write security.

CMDBRowLevelSecurity: A user who is a member of a group listed here has permission to view the instance, if they also have the CMDB Data View or CMDB Data Change role.

CMDBWriteSecurity: A user who is a member of a group listed here has permission to modify the instance, if they also have row-level security and the CMDB Data View role. This is useful for giving someone write security to a specific instance rather than all instances.

These attributes and the CMDB Data View and CMDB Data Change roles work together. If you have row-level security on an instance but not the CMDB Data View role, you cannot view the instance. If you have the CMDB Data Change role but not row-level security on an instance, you cannot view or modify the instance. The CMDB Data View All and CMDB Data Change All roles have row-level security on all instances, and do not depend on the CMDBRowLevelSecurity attribute.

CMDB RE Definitions Admin

REApplicationDeployable

� View, create, modify, and delete jobs, activities, and groups

� Start and cancel jobs� View the Job Summary on the CMDB

Home tab if they also have the CMDB Console Admin role

CMDB RE Manual Identification

REApplicationDeployable

Manually identify instances




Controlling access

Table 7-2 shows an example using two users. Joe is a member of the Service Desk group and has the CMDB Data View role, and Jane is a member of the Change Team group and has the CMDB Data Change role. They are both members of the All Hands group.

Neither user can read or write to instances 1 and 2, which have no group specified for row-level security. Neither write security nor the CMDB Data View and CMDB Data Change permissions roles have any effect without row-level security.

Use the CMDB Data View All and CMDB Data Change All roles for your users if your BMC Atrium CMDB represents just one organization; use the CMDB Data View and CMDB Data Change roles with CMDBRowLevelSecurity and CMDBWriteSecurity if you are using BMC Atrium CMDB for a multitenancy environment.

Specifying default instance permissionsDefault instance permissions allow you to specify CMDBRowLevelSecurity and CMDBWriteSecurity values for an entire class instead of specifying them every time you create an instance of the class. These permissions can be given to a different group for each account ID, supporting multitenancy by enabling you to grant users access to only the instances for their account.

You specify default permissions with the BMC_DefaultAccountPermissions class, a special class in the BMC.CORE.CONFIG namespace. Each BMC_DefaultAccountPermissions instance can grant both row-level and write security. You can specify the class and account it applies to, or allow it to apply more broadly by using the keyword default.

Table 7-2: Example instance permissions using roles and security attributes1

1. Joe is a member of both Service Desk and All Hands, and has the CMDB Data View role. Jane is amember of both Change Team and All Hands, and has the CMDB Data Change role.

InstanceId CMDBRowLevelSecurity attribute

CMDBWriteSecurity attribute

Joe canread

Joe canwrite

Jane canread

Jane canwrite

1 NULL NULL

2 NULL Service Desk3 Service Desk NULL Yes

4 Service Desk Service Desk Yes Yes

5 Change Team NULL Yes Yes

6 All Hands NULL Yes Yes Yes

7 All Hands Service Desk Yes Yes Yes Yes



The AccountId and ClassId attributes of every new BMC Atrium CMDB instance are compared against the MATCHAccountID and MATCHAppliedToClassId attributes in BMC_DefaultAccountPermissions, respectively, and the BMC_DefaultAccountPermissions instance with the lowest precedence number as shown in Table 7-3 supplies permissions for the new instance. If no instance matches, and you do not supply values for the CMDBRowLevelSecurity or CMDBWriteSecurity attribute of the instance, no user has that level of security for the instance.

Default permissions are only applied to an instance when it is created. If you later change the permissions mappings in BMC_DefaultAccountPermissions, the permissions on existing instances are not updated.

NOTE If you supply values for CMDBRowLevelSecurity and CMDBWriteSecurity when creating an instance, those values are appended to these default permissions. Both values are saved at instance creation.

For example, given the BMC_DefaultAccountPermissions instances in Table 7-4, a new instance of BMC_ComputerSystem with an AccountId of “United Industries” would have the Service Desk group placed in both its CMDBRowLevelSecurity and CMDBWriteSecurity attributes. An instance of BMC_Monitor with an AccountId of “United Industries” would have the Service Desk group placed in its CMDBRowLevelSecurity attribute and the Change Team group placed in its CMDBWriteSecurity attribute.

Table 7-3: BMC_DefaultAccountPermissions matching precedence

Precedence Account matching Class matching

1 MATCHAccountID matches AccountId on instance

MATCHAppliedToClassId matches ClassId on instance

2 MATCHAccountID matches AccountId on instance

MATCHAppliedToClassId is default

3 MATCHAccountID is default MATCHAppliedToClassId matches ClassId on instance

4 MATCHAccountID is default MATCHAppliedToClassId is default

Table 7-4: Example instances of BMC_DefaultAccountPermissions

AccountId AppliedToClassId ASSIGNRowLevelSecurity ASSIGNWriteSecurity

default BMC_COMPUTERSYSTEM

All Hands Service Desk

United Industries

default Service Desk Service Desk

United Industries

BMC_MONITOR Service Desk Change Team

default default Change Team Change Team


Tracking changes to CIs and relationships

Class and attribute permissionsYou can set permissions on classes and attributes that parallel those you can set on AR System forms and fields. For more information, see the Installation and Configuration Guide.

Tracking changes to CIs and relationshipsBMC Atrium CMDB takes advantage of the auditing feature of AR System to track changes to instance data, also known as drift tracking. 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 CMDB Console. For instructions on viewing instance history, see the User’s Guide.

Auditing versus the Compare Dataset activityAuditing 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 BMC.ASSET.SANDBOX to BMC Asset looking for the particular differences you want to catch. You could then perform custom workflow against instances found by the comparison.

For information about the Compare Dataset activity, see “Comparing datasets” on page 81.

Keep these considerations in mind when deciding which method to use for drift tracking:

� 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 will 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 more flexibility in executing workflow when a change occurs.

Given these considerations, in most cases audits are the better choice for keeping a history and comparisons are better for alerting you to changes in your data that require investigation.

Types of auditingYou can audit by creating a copy of the instance that was created, modified, or deleted, or by writing the changes to a log.

NOTE 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. For more information about audit forms, see the next section, “Copy.”

CopyCopy 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, a subclass of the base class BMC_BaseElement, three audit forms are created:

The audit forms have the same 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. The forms and their data are retained if you later disable logging for the class or delete the class.

Each audit of each instance results in an entry in the audit form, so there can be multiple entries related to a given instance.

Table 7-5: 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 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. For information about selecting attributes to write in an audit, see “Setting the attribute Audit option” on page 99.

In addition to the class attribute fields, each audit form also includes these fields:

� Audit Join Key: A 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_<field_ID>_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 Date: The timestamp of the audit

� User: The user who performed the action that triggered the audit

� Action: An integer representing the action that triggered the audit. Table 7-6 lists the possible values and their meanings.

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 AR System form-style auditing. For more information about form-style auditing, see BMC Remedy Action Request System 7.1.00: Form and Application Objects.

Table 7-6: Audit actions

Action field value Instance action

2 Modify

4 Create

8 Delete

16 Merge



LogLog 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.

Each Log audit form includes these fields:

� GUID: The InstanceId of the audited instance

� Log Key1: The ClassId of the audited instance

� Log Key2: The DatasetId of the audited instance

� Fields Changed: A 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.

� Log: A list of the attribute values written for the audit, in the format<name1>:<value1><name2>:<value2>[<name3>:<value3>]

� Audit Date: The timestamp of the audit

� User: The user who performed the action that triggered the audit

� Action: An integer representing the action that triggered the audit. Table 7-6 on page 97 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 attribute Audit option” on page 99.

Log auditing in BMC Atrium CMDB is implemented using AR System log-style auditing. For more information about log-style auditing, see BMC Remedy Action Request System 7.1.00: Form and Application Objects.

Choosing which type to useKeep 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.



Selecting which instances and attributes are includedYou 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 qualificationYou restrict which instances are audited by specifying an audit qualification for each class that has audit enabled. If an instance does not match the qualification, an audit cannot be triggered for it.

However, a superclass with audit enabled can alter the effect of an audit qualification. If an instance of an audit-enabled class fails the audit qualification for that class but matches the audit qualification of an audit-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 attribute Audit optionFor each attribute in a class, you can choose one of four Audit options:

� None: Changes to this attribute do not trigger an audit. NULL is written to this field 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.

� Audit: When the value of this attribute changes, an audit is triggered and the attribute value is written to the audit form or log form. When another attribute triggers an audit, this attribute is not written.

� Copy: Changes 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 Copy: When the value of this attribute changes, an audit is triggered. 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 there is at least one Audit, Copy, or Audit and Copy attribute for a class, a Create or Delete operation triggers an audit regardless of the values of such attributes. Audit, Copy, and Audit and Copy attributes are all written during such an audit.



Table 7-7 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.

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 practicesThis section gives you several best practices for working with auditing.

� Only enable auditing for up to four or 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 four or five Audit attributes.

� Don’t audit System attributes like LastModifiedBy or ModifiedDate if you use Log auditing. AR System keeps a history of these already.

Table 7-7: Audit lifecycle of a sample instance

Operation order

Operation Attribute1 (Audit)

Attribute2 (Copy)

Attribute3 (Audit and Copy)

Attribute4 (None)

Audit triggered?

Attributes written to audit form

1 Create NULL Chicago NULL Compact disc

Yes Attribute1, Attribute2, Attribute3

2 Modify Green Chicago NULL Cassette tape

Yes Attribute1, Attribute2, Attribute3

3 Modify Green Dallas NULL 8-track tape No None

4 Modify Green Dallas Bicycle 8-track tape Yes Attribute2, Attribute3

5 Delete N/A N/A N/A N/A Yes Attribute1, Attribute2, Attribute3


Deleting CIs that are no longer discovered

� Rather than auditing a lower-level class in your data model inheritance tree, audit the highest-level class whose 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.

For example, imagine 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 changed; 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 should enable auditing for that class and use a qualification on ClassId to select only the subclasses you want.

� Use a qualification on the DatasetId attribute to restrict auditing to your production dataset. There is rarely a need to audit other datasets, so you’ll 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, this is usually caused by the connecting relationship being unintentionally soft deleted while the component CI still exists. To track this, enable auditing on BMC_BaseRelationship (with a qualification on source and destination class IDs if desired), 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.

Deleting CIs that are no longer discoveredThere will be occasions when your discovery application doesn’t discover a CI or composite CI that it had regularly discovered before. Though you might be tempted to delete the CI from BMC Atrium CMDB, you shouldn’t do so right away. Usually such a “missing” CI is only temporarily removed or unavailable, such as a computer system that has been shut down while its owner is on vacation.

Instead of deleting the instance from BMC Atrium CMDB, known as hard deleting, you should 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.

You should establish a policy that specifies how long a CI can remain soft deleted. If it is rediscovered before reaching that interval, you can reset the MarkAsDeleted attribute to NULL. If not, you can hard delete it.

The Reconciliation Engine offers a Purge activity that deletes soft-deleted instances. For more information about this feature, see “Purge Dataset” on page 85.



Working with discovery sourcesAutomated discovery is critical to the accuracy of a CMDB. Without it your CMDB will become out of sync with your actual environment in some minor way within minutes. It will be out of sync in a major way within days, and completely useless within weeks or months.

Consider these suggestions when working with discovery sources:

� Don’t load every discovered CI into the CMDB on every transfer. Transfer only new CIs and CIs that have been modified since the previous transfer.

� 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 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.

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 the AR System or with database replication.

However, it is a bad idea to 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 AR System server where your BMC Atrium CMDB is installed. BMC Atrium CMDB supports server groups with and without load balancers.


Adding custom workflow

Adding custom workflowBecause BMC Atrium CMDB is built on the AR System, you can easily add custom workflow to the class forms to accomplish various tasks. For information about creating AR System workflow, see BMC Remedy Action Request System 7.1.00: Workflow Objects.

Sample use caseA company has a process that involves manually creating CIs in their production dataset. Unlike the other instances in this dataset, these have no reconciliation identity, and the company wants to have a visual cue when viewing a CI that lets them know it hasn’t been reconciled.

To satisfy this requirement, they might create custom workflow that changes the label color of the Name attribute to red when a non-reconciled CI is displayed.

Filter execution orderBMC Atrium CMDB uses two 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 100: Performs 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 600: Performs hard and soft deletes, pushes attribute values to subclass forms, handles weak relationship functionality, and for new instances adds default instance permissions.

If you need to create a filter on a class form, choose its execution order based on these two filters. In most cases you should choose an execution order from 101 to 599, inclusive. This allows your filter to work with the class ID and instance ID that are created at execution order 100 and also allow it 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 if you want to create your own instance ID instead of letting the system create it automatically.



Best practicesWhen planning to add custom workflow to BMC Atrium CMDB, follow these guidelines:

� As a first step, 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 undesired 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.


Glossary

abstract classA 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.

accountAn entity or party whose data is represented in BMC Atrium CMDB, and to whom specific levels of permission can be granted. Specifying instance permission by account enables BMC Atrium CMDB to support multitenancy.

activityAn individual reconciliation task that can be grouped together in a defined sequence to form a reconciliation job. You cannot run an activity by itself; only as part of a job. See also Comparison activity, Copy Dataset activity, Delete Dataset activity, Execute Job activity, Identification activity, Merge activity, Purge Dataset activity, Rename Dataset activity.

attributeA 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 an AR System form.

attribute permissionPermission to view or change the value in the attribute for any instance, assuming valid instance permissions.

attribute substitutionA 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.

auditA 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.

base classA class that has no superclass.

BMC Atrium Integration EngineA product that enables you to transfer large amounts of data between third-party data sources and both the AR System and BMC Atrium CMDB.

Business Service Management (BSM)The concept of prioritizing IT efforts to support the overall goals of the business.

cardinalityThe 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 deleteTo automatically delete, or mark as deleted, the destination member of a relationship when the source member is deleted or marked.

Categories, Types, and Items (CTI)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.

Glossary 105


categorization classA class that does not have its own AR System form, but stores its instance data in the form of its superclass, preventing the need for a database join.

CDMSee Common Data Model (CDM).

childSee destination.

CISee configuration item (CI).

CI classA class that defines a type of configuration item (CI), such as a computer system or software application.

CI Relationship ViewerA component of BMC Atrium CMDB that graphically displays the relationships between CIs. It can also be embedded in other AR System-based applications.

CI Relationship Viewer eventA message sent to the CI Relationship Viewer from AR System workflow to change its settings. The CI Relationship Viewer can also send AR System events.

CIMSee Common Information Model (CIM).

classMetadata 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 ManagerA 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 permissionsPermission to view instances of a class in the BMC Atrium CMDB interface or access them with AR System workflow.

CMDBSee Configuration Management Database (CMDB).

CMDB ConsoleThe main user interface of BMC Atrium CMDB, accessible from both web and BMC Remedy User clients.

CMDB Console UserAn application role. Members can perform searches from the CMDB Console and view federation definitions.

CMDB Console AdminAn application role. Members can perform searches from the CMDB Console, view, create, and modify federation definitions, and perform CMDB Console administrative tasks.

CMDB Data ChangeAn application role. Members can view, create, and modify instances if they have row-level security.

CMDB Data Change AllAn application role. Members can view, create, and modify instances independent of row-level security.

CMDB Data ViewAn application role. Members can view instances if they have row-level security.

CMDB Definitions AdminAn application role. Members can view, create, modify, and delete classes.

CMDB Definitions ViewerAn application role. Members can view class definitions.

CMDB Extended DataRelated data or CI attributes linked to or from BMC Atrium CMDB.

CMDB RE Definitions AdminAn application role. Members can view, create, modify, and delete reconciliation definitions and can start and cancel jobs.


Glossary

CMDB RE Manual IdentificationAn application role. Members can identify instances manually.

CMDB RE UserAn application role. Members can view reconciliation definitions and can start and cancel jobs.

cmdbdriverA 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’s 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 activityA Reconciliation Engine activity that compares identified instances between two datasets, either producing a report that shows the differences or executing workflow.

configuration dataData 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.

consumerAn application that works with data in BMC Atrium CMDB. It might view the data or modify it. See also provider.

Copy Dataset activityA Reconciliation Engine activity that copies instances from one dataset to another.

CTISee Categories, Types, and Items (CTI).

data replicationAn 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.

datasetA 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 PrecedenceA pairing of a dataset with a Precedence group. Each Merge activity references a collection of these, called a Dataset Merge Precedence set.

defined datasetOne 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.

Definitive Software Library (DSL)A repository where approved software configurations are stored. Installed instances of the software can be checked against the DSL for compliance with licenses and policies.

Delete Dataset activityA Reconciliation Engine activity that deletes instances from one or more datasets without removing the dataset itself. See also cascading delete, hard delete, and soft delete.

Glossary 107


destinationThe 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 or weak member.

discoveryThe act of scanning your environment for configuration data.

discovery applicationAn 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.

DMTFSee Distributed Management Task Force (DMTF).

DSLSee Definitive Software Library (DSL).

Enterprise Integration EngineSee BMC Atrium Integration Engine.

eventA 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. See also CI Relationship Viewer event.

Exclusion ruleA rule that specifies an attribute to be excluded from participation in a Comparison activity.

Execute Job activityA Reconciliation Engine activity that executes a job.

extensionA logical set of classes and attributes, usually in its own namespace, that is not part of the Common Data Model (CDM).

extension loaderThe cmdbExtLoader program, which is used for installing data model extensions and importing other BMC Atrium CMDB data and metadata.

federated dataData 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 interfaceAn instance of the BMC_FederatedInterface class that specifies how to access a particular type of federated data. See also federated link.

federated linkThe connection between a class or CI and a federated interface.

federated productA product that holds federated data. It can be linked to more than one federated interface.

federationThe act of linking CIs in BMC Atrium CMDB to external data.

Federation ManagerA 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.

filterA set of criteria for restricting the information displayed by the CI Relationship Viewer. This is different from an AR System filter.

final classA class that cannot have subclasses.

foreign key substitutionA 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.


Glossary

groupA 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.

GUIDA globally unique identifier, automatically generated by the AR System server. GUIDs are used for instance IDs, reconciliation IDs, and other cases where a unique value is needed without human interaction.

hard delete The act of removing an instance from BMC Atrium CMDB.

Identification activityA 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 groupA 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 ruleA rule used when identifying instances between datasets. When two instances match the qualification for the rule, they are assigned the same reconciliation ID.

identitySee reconciliation ID.

incidentDefined by ITIL as any event that is not part of the standard operation of a service and which causes, or might cause, an interruption to, or a reduction in, the quality of that service.

incremental mergeA Merge activity that only processes instances that were 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.

instanceAn 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 IDA GUID that BMC Atrium CMDB applies to each instance to uniquely identify it.

instance permissionsThe right to view or modify a specific instance. These permissions are called row-level security and write security, respectively.

instantiateTo create an instance of a class.

ITILThe Information Technology Infrastructure Library (ITIL) is an internationally accepted set of best practices for management of IT services developed by the British government

jobA 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.

Merge activityA 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.

metadataDefinitions 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.

multitenancyThe 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 and role.

Glossary 109


namespaceA 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.

normalizeTo make sure 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.

orphanAn instance that has been physically deleted from source datasets but still exists in the target dataset into which they merge.

overlay datasetA 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.

parentSee source.

Precedence groupThe definition of an overall precedence value for a dataset. It can optionally contain precedence values for specific classes and attributes within the dataset.

precedence valueA 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.

production datasetThe 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.

providerAn application, often a discovery application, that loads bulk data into BMC Atrium CMDB. See also consumer.

provisioningThe process of providing access to resources, such as printers, telephones, and such, and to information, such as permissions, databases, and so on.

publishTo make an event available so that instances of it can be written to the CMDB:Events form.

Purge Dataset activityA Reconciliation Engine activity that removes instances that have been marked as deleted from one or more datasets.

QualificationA Boolean statement that is evaluated to determine whether an instance should be included in an activity.

Qualification groupA 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.

reconciliationThe 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 definitionAn entity defined in the Reconciliation Manager such as a job, activity, or group.

Reconciliation EngineThe component of BMC Atrium CMDB that reconciles data from different datasets.

reconciliation IDA GUID that the Reconciliation Engine assigns to instances in different datasets that represent the same real-life object.

Reconciliation ManagerThe component of BMC Atrium CMDB that you can use to manage reconciliation definitions.


Glossary

regular classA class that stores its instance data in its own AR System form. See also abstract class, categorization class.

related informationInformation about a CI that does not qualify as attributes of the CI, and should therefore not be stored in a Configuration Management Database (CMDB).

relationshipA connection between two CIs such as a dependency or membership. It is an instance of a relationship class. See also configuration item (CI).

relationship classA class that defines a type of relationship between CIs, such as a dependency or membership.

relationship filterSee filter.

Rename Dataset activityA reconciliation activity that renames a dataset without changing its ID, preserving references to the dataset from any reconciliation definitions.

roleA designation that grants permissions to more than one AR System group.

row-level securityThe permission required to view a specific instance. See also write security.

ruleOne or more criteria that, when met, cause an action. The types of rules used in BMC Atrium CMDB are Exclusion rule, Identification rule, and Workflow Execution rule.

rulesetA group of rules.

service level agreementA contract between a service provider and a purchaser that defines the level of service.

singleton classAn optional class characteristic that restricts the class to holding only one instance.

snapshotA 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 deleteThe act of marking an instance as deleted from BMC Atrium CMDB by setting the MarkAsDeleted attribute to Yes.

sourceThe 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 or strong member.

subclassA 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.

superclassA class from which other classes, called subclasses, are derived.

synchronizationThe automatic process of creating 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 normalizationSee normalize.

weak referenceSee weak relationship.

weak relationshipAn 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.

Glossary 111


Windows Management Instrumentation (WMI)Microsoft's application of the Web-Based Enterprise Management initiative for an industry standard for accessing management information.

WMISee Windows Management Instrumentation (WMI).

workflowAR System objects such as active links, escalations, and filters that perform actions against data.

Workflow Execution groupA set of Workflow Execution rules. Each Comparison activity can optionally reference one Workflow Execution group.

Workflow Execution ruleA rule used when comparing instances between datasets. When a compared instance matches the qualification for the rule, specified AR System workflow is executed against the instance or the instance against which it is compared.

working datasetOne 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 securityThe permission required along with row-level security to modify or delete a specific instance.


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

Aabstract classes

about 52extending 63with data replication 52, 64

accessingBMC Atrium CMDB 90CMDB data 24federated data 74

addingattributes to existing classes 62subclasses to Common Data Model 62workflows to BMC Atrium CMDB 103

application rolesCMDB Console Admin 91CMDB Console User 91CMDB Data Change 90CMDB Data Change All 90CMDB Data View 90CMDB Data View All 90CMDB Definitions Admin 91CMDB Definitions Viewer 91CMDB RE Definitions Admin 92CMDB RE Manual Identification 92CMDB RE User 91

applications, using with extended data models 65AR System

architecture 25BMC Atrium CMDB and 25using with extended data models 65

architectureAR System 25BMC Atrium CMDB 16, 19federation 71

Atrium CMDB. See BMC Atrium CMDBattributes

about 46adding to existing classes 62Category 61extending Common Data Model 61

attributes (continued)generating fields for AR System 65Item 61namespaces for 54naming and numbering rules 65substitution of 72Type 61

audience for this guide 9Audit feature 38audit forms 96auditing, best practices 100audits

attribute options 99copy option 96life cycle 100log option 98restricting 99specifying qualifications 99tracking changes to instance data 95types 96

Bbacking up CMDB data 37benefits

AR System 27configuration management 14decision-making support 15federated data 22integration 15

Best Practice icon 9BMC Asset dataset 76BMC Atrium CMDB

See also CMDBsabout 16adding custom workflows 103AR System and 25architecture 16, 19Audit feature 38classes 55

Index 113


BMC Atrium CMDB (continued)Common Data Model 33, 46, 55controlling access 90datasets 76documentation 10, 11Extended Data 20infrastructure

about 19application layer 21CMDB Environment layer 21CMDB Extended Data layer 20CMDB layer 19Extended CMDB 21federated 19related data 20

permissionsabout 90attribute 95class 95default instance 93instance 92roles 90

Reconciliation Engine 79related data 20replicating data 102

BMC Atrium CMDB data model. See data modelsBMC Impact Solutions, using new classes 65BMC Software, contacting 2BMC_AccessPoint class 56BMC_BaseElement class 56BMC_BaseRelationship class 57BMC_Collection class 56BMC_Component class 58BMC_Dependency class 58BMC_Document class 56BMC_ElementLocation class 58BMC_Equipment class 56BMC_LogicalEntity class 56BMC_MemberOfCollection class 58BMC_Person class 57BMC_Settings class 57BMC_System class 57BMC_SystemComponent class 57BMC_SystemService class 57bulk data, loading 25

Ccardinality 48cascading delete 49categorization classes

about 51extending 63

Category attributes 61CDM. See Common Data Modelchanges, tracking instance data 95checklists for analyzing environments 32CI control 37CIM. See Common Information ModelCIs. See configuration itemsclasses

about 46abstract 52abstract with data replication 52adding attributes to existing 62BMC Atrium CMDB 55categorization 51configuration item 46

BMC_AccessPoint 56BMC_BaseElement 56BMC_Collection 56BMC_Document 56BMC_Equipment 56BMC_LogicalEntity 56BMC_Person 57BMC_Settings 57BMC_System 57BMC_SystemComponent 57BMC_SystemService 57extending 62in Common Data Model 56

data storage methods 50deleting instances of 49extending 62final 54linking to federated data 70naming and numbering rules 65options 54regular 50relationship 47

BMC_BaseRelationship 57BMC_Component 58BMC_Dependency 58BMC_ElementLocation 58BMC_MemberOfCollection 58extending 63in Common Data Model 57



classes (continued)relationship (continued)

subclasses 58replicating subclasses 52singleton 54

CM. See configuration managementCMDB Console Admin role 91CMDB Console User role 91CMDB Data Change All role 90CMDB Data Change role 90CMDB Data View All role 90CMDB Data View role 90CMDB Definitions Admin role 91CMDB Definitions Viewer role 91CMDB Environment layer 21CMDB process segments

audits 37backing up 37CI control 37configuration management process 35data cleaning 37defining 36status accounting 37verifications 37

CMDB RE Definitions Admin role 92CMDB RE Manual Identification role 92CMDB RE User role 91CMDB segments. See CMDB process segmentsCMDBs

See also BMC Atrium CMDBBMC Atrium infrastructure layer 19configuration items and 17data types 16defining 33discovery and 102implementing

controlling CM process 43migrating data 42phases 42pitfalls 44

integrating ITIL processes 15ITIL meaning 21planning

analyzing environment 31avoiding pitfalls 40costs 39defining CM process 35defining CMDBs 33establishing management teams 30identifying consumers 32purposes, goals, and objectives 30

working with discovery sources 102

Common Data Modelabout 46, 55configuration item classes 56configuration items and 33diagram 61extending 60relationship classes 57sample models 59

Common Information Model 55Compare Dataset activity, tracking drift with 95comparing datasets 81computer systems, sample data models 59configuration data

datasets and 76unified representation 46

configuration itemsabout 17BMC guidelines for defining 33classes 46CMDBs and 17Common Data Model classes 56datasets and 76defined 17deleting 101detail, defining 33examples 17ITIL guidelines for defining 33missing 101naming conventions 34related data 18relationships 17, 35scope, defining 33undiscovered 101

configuration managementbenefits 14CMDB segments, defining 36costs 39data accuracy 16data availability 16goals 14ITIL and 14process

controlling 43defining 35defining process owners 38defining roles 38

Provider segment, defining 36Reconciliation segment, defining 36teams, establishing 30

configuration management databases. See CMDBsconsumers, identifying 32copying dataset instances 85

Index 115


costsidentifying configuration management 39justifying configuration management 39

creating subclasses 62customer support 3

Ddata

See also federated dataaccess 24auditing 95backing up 37BMC Atrium CMDB model 46bulk loading 25cleaning 37configuration 46federated 68flexible model 22migrating to the BMC Atrium CMDB 42open access 24overlay dataset 78partitioning 23programmatic access to 24reconciling 23, 79related to configuration items 18replicating abstract class 52replicating BMC Atrium CMDB 102tracking changes 95types stored in ITIL CMDBs 16

data modelsSee also Common Data Modelabout 22, 46attributes 46classes 46

abstract 52abstract with data replication 52categorization 51data storage methods 50final 54options 54regular 50singleton 54

extensibility 23, 46industry standards 55inheritance 46namespaces 54object-oriented 23synchronizing changes 55

datasetsabout 76BMC Asset 76comparing 81copying instances 85deleting instances 85identifying 79merging 82overlay

about 77deleting instances 78instance IDs 79queries to 77working with 78

production 76purging instances 85reconciling 79renaming 85

definingCMDBs 33configuration management process 35

deletingcascading 49configuration items 101dataset instances 85instances 49relationships 49

destination classes 48diagram of Common Data Model 61discovery

CMDBs and 102deleting undiscovered CIs 101working with sources 102

Distributed Management Task Force 55DMTF. See Distributed Management Task Forcedocumentation for BMC Atrium CMDB 10, 11documenting extensions 66drift tracking 95

EEnvironment, CMDB layer 21environments, analyzing

about 31BMC checklist 32ITIL guidelines 31

examplesconfiguration item 17relationship 18

Extended CMDB 21Extended Data layer 20



extending Common Data Modelabout 60abstract classes 63abstract classes with data replication 64adding attributes 62adding subclasses 62BMC applications and 65BMC Impact Solutions and 65BMC products and 60categorization classes 63diagram 61documenting 66final classes 64naming and numbering rules 65regular classes 63relationship classes 63singleton classes 64with existing attributes 61

Ffederated data

about 22, 68accessing 74architecture 71attribute substitution 72benefits 22BMC Atrium CMDB infrastructure 19class-level links 70foreign key substitution 72instance-level links 70linking 70model 16retrieving data in context 71using 69

final classesabout 54extending 64

foreign key substitution 72forms, audit 96forms, log 98

Gguidelines for

analyzing environments 31defining configuration items, BMC 33defining configuration items, ITIL 33defining process owners, BMC 39defining process owners, ITIL 38defining roles, BMC 39

guidelines for (continued)defining roles, ITIL 38naming configuration items, BMC 35naming configuration items, ITIL 34

Iicons

Best Practice 9New 9

identifyingdatasets 79instances 80

implementing CMDBs 41–44incremental merge 82, 87industry standards, data model 55Information Technology Infrastructure Library. See

ITILinfrastructure, BMC Atrium CMDB 19inheritance 46instances

audited 96copying dataset 85default permissions 93deleting dataset 85deleting from overlay datasets 78deleting relationship class 49identifying in datasets 79, 80linking to federated data 70permissions 92purging dataset 85replicating 52sample audit 100

integrating IT processes 15Item attributes 61ITIL

about 14CI naming guidelines 34CMDB, defined per 21configuration management and 14data types 16defining configuration items 33Extended CMDB and 21guidelines for

analyzing environments 31defining configuration items 33defining process owners 38defining roles 38naming configuration items 34

Index 117


Jjobs, combining reconciliation activities 86

Lleft-side classes 48linking to federated data 70log forms 98

Mmembers, relationship 47merging datasets

incrementally 82, 87overview 82with independent activities 84with one activity 83

Microsoft Windows Management Instrumentation 55

migrating data to the BMC Atrium CMDB 42multitenancy, defined 90

Nnamespaces

attribute 54data model 54reconciliation and 54, 80

namingconfiguration items 34rules for extensions 65

New icon 9numbering rules for extensions 65

Oobject-oriented data models 23open access to data 24options, class 54overlay datasets 77

Pparent classes 48partitioning

about 23datasets and 76namespaces and 54

pending changes 55

permissionsattribute 95BMC Atrium CMDB 90class 95CMDB Console Admin 91CMDB Console User 91CMDB Data Change 90CMDB Data Change All 90CMDB Data View 90CMDB Data View All 90CMDB Definitions Admin 91CMDB Definitions Viewer 91CMDB RE Definitions Admin 92CMDB RE Manual Identification 92CMDB RE User 91default instance 93instance 92roles 90

phases of CMDB implementation 42pitfalls

CMDB implementation 44CMDB planning 40

planning CMDBs 29–40process owners

BMC guidelines for defining 39defining for segments 38ITIL guidelines for defining 38

process segments. See CMDB process segmentsprocesses, integrating IT 15product support 3production datasets, defined 76programmatic access to data 24Provider process segments, defining 36purging dataset instances 85

Qqualifications, audit 99queries, overlay dataset 77

Rreconciliation

about 23best practices 87combining activities 86comparing datasets 81copying dataset instances 85data 79deleting dataset instances 85executing jobs 85



reconciliation (continued)identifying datasets 80jobs 86merging datasets 82namespaces and 54, 80purging datasets 85renaming datasets 85

Reconciliation Engineabout 79executing jobs 85

Reconciliation process segments, defining 36regular classes


relationshipscardinality 48cascading delete 49classes

about 47deleting instances of 49destination 48left-side 48placement 48right-side 48source 48

Common Data Model classes 57configuration item 17, 35datasets and 76deleting 49examples 18extending classes 63members 47weak 48

renaming datasets 85replicating BMC Atrium CMDB data 102restricting audits 99right-side classes 48roles

BMC Atrium CMDB permissions 90BMC guidelines for defining 39defining for segments 38ITIL guidelines for defining 38

Ssamples

Common Data Model 59custom workflows 103instance audits 100LAN computer system data models 59typical computer system data models 59

scope, configuration item 33

segments. See CMDB process segmentssingleton classes


source classes 48status accounting, defined 37subclasses

adding to Common Data Model 62creating 62relationship 58

substitutionattribute 72foreign key 72

support, customer 3synchronizing

data model changes 55pending changes 55

Tteams, configuration management 30technical support 3tracking instance data changes 95Type attributes 61

Uuse cases, adding custom workflows 103

Wweak relationships 48WMI. See Microsoft Windows Management

Instrumentationworkflows

adding custom to BMC Atrium CMDB 103best practices for adding 104sample use cases 103

Index 119



*70087**70087**70087**70087*

*70087*

Documents

Concepts and Best Practices