Concepts and Best Practices

BMC Atrium CMDB 2.1.
00
Concepts and Best Practices Guide
August 2007
www.bmc.com
Contacting BMC Software

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

Address BMC SOFTWARE INC 2101 CITYWEST BLVD HOUSTON TX 77042-2827 USA Telephone 713 918 8800 or 800 841 2031 Fax 713 918 8000
Outside United States and Canada

Telephone (01) 713 918 8800 Fax (01) 713 918 8000
If you have comments or suggestions about this documentation, contact Information Development by email at doc_feedback@bmc.com. Copyright 20062007 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.
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:
s s s s s s s
Read overviews about support services and programs that BMC Software offers. Find the most current information about BMC Software products. Search a database for problems similar to yours and possible solutions. Order or download product documentation. Report a problem or ask a question. Subscribe to receive email notices when new product versions are released. Find worldwide BMC Software support center locations and contact information, including email addresses, fax numbers, and telephone numbers.
Support by telephone or email

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

Have the following information available so that Customer Support can begin working on your issue immediately:
s
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
s s s
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
Contents
Preface 9
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Best Practice and New icons. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 BMC Atrium CMDB documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Related documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Chapter 1 What is BMC Atrium CMDB? 13 14 14 14 16 16 16 19 22 22 23 23 24 25 29 30 30 31 31 32 32 33 33 34 35 35 36 36 36 38
5
ITIL and Configuration Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data is the key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architecture of BMC Atrium CMDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Which data goes into an ITIL CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Federated data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flexible data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data reconciliation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Open access to data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AR System foundation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 2 Planning your CMDB
Establish a Configuration Management team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Define your purpose, goal, and objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analyze your existing environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ITIL guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identify consumers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Define your CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CI scope and detail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CI naming conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Relationships between CIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Define your Configuration Management process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Provider segment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reconciliation segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CMDB segment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Roles and process owners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents
Identify and justify costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Avoid potential pitfalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Chapter 3 Implementing your CMDB 41
Phased implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Migration considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Controlling the Configuration Management process . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Potential pitfalls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Chapter 4 The data model 45
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Classes and attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Inheritance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Relationships. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Data storage methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Optional class characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Synchronization of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 The Common Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Configuration items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Relationships. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Further categorizing relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Sample models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Extending the data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Use the CDM with only BMC extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 Use the Category, Type, and Item attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Install an extension from BMC Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Add attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Add subclasses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 Naming and numbering rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Making your changes visible to applications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Document your extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Chapter 5 Federated data 67
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 When to use federated data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Federating by instance or class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 By instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 By class. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Federation architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Federating data in context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Storing and viewing federated data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Chapter 6
Datasets and reconciliation
75 76 76 76 77 77 78 79 79 80 80 81 82 85 86 86 87 89
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What are datasets for?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BMC Software datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overlay datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How overlays work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Working with data in overlay datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Controlling client write access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reconciling data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Namespaces and reconciliation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identifying instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Comparing datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Merging datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Other reconciliation activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Combining activities as a job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Qualification groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Chapter 7 Administrative functionality
Controlling access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 BMC Atrium CMDB application roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Instance permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Specifying default instance permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Class and attribute permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Tracking changes to CIs and relationships. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Auditing versus the Compare Dataset activity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Types of auditing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Selecting which instances and attributes are included . . . . . . . . . . . . . . . . . . . . . . 99 Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Deleting CIs that are no longer discovered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Working with discovery sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Replicating BMC Atrium CMDB data to other servers . . . . . . . . . . . . . . . . . . . . . . . . 102 Adding custom workflow. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Sample use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Filter execution order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 Best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Glossary Index 105 113
Contents
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.
Audience
This 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 icons

Documentation 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 2.1.00
BMC Atrium CMDB documentation

The 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 Common Data Model Diagram Concepts and Best Practices Guide Data Model Help Document provides Audience Format
Hierarchical diagram of all classes in the Common Administrators Print and PDF Data Model (CDM) including unique attributes and applicable relationships Information about CMDB concepts and best practices for planning your BMC Atrium CMDB implementation IT leaders and administrators Print and PDF
Description and details of superclasses, subclasses, Administrators HTML (product DVD attributes, and relationship classes for each class. only) Contains only information about the Common Data Model at first, but can be updated to include information about data model extensions you install. Information about creating API programs, using C Administrators Print and PDF and web services API functions and data structures, and and a list of error messages programmers Information about installing and configuring BMC Atrium CMDB, including permissions, class definitions, reconciliation, and federation Information about Java classes, methods, and variables that integrate with BMC Atrium CMDB Administrators Print and PDF
Developers Reference Guide Installation and Configuration Guide Javadoc API Help
Programmers
HTML (product DVD only)
Mapping Your Data to Mappings of common IT objects to the appropriate Administrators Spreadsheet, print and PDF class in which to store them, whether part of the BMC Atrium CMDB Classes Common Data Model or an extension. Also includes information about further categorizing instances using key attributes. Master Index Online Help Combined index of all guides Help for using and configuring BMC Atrium CMDB, available by clicking Help in the product interface Information about new features, open issues, and resolved issues Everyone Users and administrators Print and PDF Product Help (available from Help links after installed) Print and PDF
Release Notes
Everyone
10
Related documentation
Title Troubleshooting Guide
Document provides Information about resolving issues with BMC Atrium CMDB components, including API, filter, and console error messages and their solutions.
Audience
Format
Administrators, Print and PDF programmers, and BMC Support personnel Users Print and PDF
Users Guide
Information about using BMC Atrium CMDB, including searching for and comparing CIs and relationships, relating CIs, viewing history, and launching federated data
Related documentation
The 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.
Title BMC Atrium Integration Engine 7.1.00 Users Guide BMC Configuration Management Configuration Discovery Integration for CMDB 7.1 Implementation Guide BMC Foundation Discovery and BMC Topology Discovery Installation and Configuration Guide BMC Foundation Discovery and BMC Topology Discovery User Guide Document provides Information about how to establish a data transfer between third-party databases and BMC Atrium CMDB. 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. Audience Format
Administrators Print and PDF and developers Administrators Print and PDF and developers
Information about the configuration of a connection Administrators Print and PDF and developers between BMC Atrium CMDB and the discovery data store from BMC Foundation Discovery and BMC Topology Discovery. Information about the synchronization of the topology datastore with BMC Atrium CMDB. Administrators Print and PDF and developers
BMC Remedy Action Information about AR System data structures, C Request System 7.1.00: API function calls, and OLE support. C API Reference BMC Remedy Action Information about configuring AR System servers Request System 7.1.00: and clients, localizing, importing and exporting Configuring data, and archiving data. Information about components necessary to build BMC Remedy Action Request System 7.1.00: applications in AR System, including applications, Form and Application fields, forms, and views. Objects
Administrators Print and PDF and programmers Administrators Print and PDF
Developers
Print and PDF
Preface 11
Title
Document provides
Audience
Format
BMC Remedy Action Procedures for installing AR System Request System 7.1.00: Installing Information about the mid tier, including mid tier BMC Remedy Action Request System 7.1.00: installation and configuration, and web server configuration. Installing and Administering BMC Remedy Mid Tier
Administrators Print and PDF
Administrators Print and PDF
Information about integrating AR System with Administrators Print and PDF BMC Remedy Action Request System 7.1.00: external systems using plug-ins and other products, and developers Integrating with Plug- including LDAP, OLE, and ARDBC. ins and Third-Party Products Definitive Software Library 7.1 Administrators Guide Information about installing and configuring DSL, Administrators Print and PDF updating vendor data, and connecting DSL to BMC Configuration Management and AR System databases
12
Chapter
What is BMC Atrium CMDB?
This chapter includes the following topics: ITIL and Configuration Management (page 14) Architecture of BMC Atrium CMDB (page 16)
Chapter 1
13
ITIL and Configuration Management

IT departments face numerous challenges in providing dependable services that support a companys business goals. Solving most of them requires a good Configuration Management strategy: without knowing whats 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.
Goals
According 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
Benefits
Achieving these goals can benefit your organization in significant, measurable ways related to control, integration, and decision support.
Control
Verifying and correcting configuration records gives you a greater degree of control over your infrastructure. For example, by controlling the versions of configuration items, you reduce the complexity of your environment, 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.
Office of Government Commerce, Best Practice for Service Support (London: The Stationery Office, 2000). 14 Concepts and Best Practices Guide
ITIL and Configuration Management
Integration
When 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
Asset Management
Change Management
CMDB
Release Management
Configuration Management
Capacity Management
Decision Support
Your IT managers benefit from having accurate configuration information mapped to your service management processes. Making decisions is easier when you have complete and accurate data, resulting in better resource and performance estimates. You can commit to service levels more confidently, and your risk management improves, reducing unplanned downtime.
Chapter 1
15
Data is the key

You 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 weeks 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 CMDB

BMC Atrium CMDB uses a federated data model, featuring a centralized database linked to other data stores, to share configuration data without the high setup and maintenance costs associated with a pure centralized approach. 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 CMDB

ITIL recommends that you store several types of data in the CMDB. Its main purpose is to hold configuration items (CIs) and the relationships between them, which together form a configuration at a particular time or state. ITIL also suggests that the CMDB can hold data related to CIs, such as incident tickets or SLA definitions.
16
Configuration items
CIs are the focal point of a CMDB. Without a clear definition of what qualifies as a CI, you will constantly struggle with deciding whether to put certain kinds of data into the CMDB. Simply put, a CI is an instance of an entity that is part of your environment and has configurable attributes specific to that instance. These entities can be physical (such as a computer system), logical (such as an installed instance of a software program), or conceptual (such as a business service). But they must be a direct part of your environment, rather than information about such a part. Table 1-1 gives some examples to illustrate this boundary:
Table 1-1: Example CIs and non-CIs 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. Not configuration items 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 environmentonly installed instances of it areand 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.
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 CIs

CIs dont 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.
Chapter 1
17
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
Dependency
Online Store (Service)
Dependency
Server group (Collection)
Dependency
Member of
Shopping Cart (Software)
Dependency
Orders Database (Software)
Dependency
Web Server (Computer system)

Component
Dependency
Disk Drive 1
Disk Drive 2
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 Bs performance or which services would be affected if Router C failed. Most downtime is caused by problems stemming from configuration changes. Accurate relationship information can help you prevent those problems.
Related data
There 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.
18
BMC Atrium CMDB

BMCs 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
CMDB Environment
SLA Management
Applications
Change Management Asset Management Incident Management Application Management Identity Management
Capacity Management Discovery Application 1 Discovery Application 2 Problem Management Requests
Requests for Configuration Data
Software Config. Management Service Impact Management
Help Desk Requests
Provisioning
CMDB Extended Data

Information related to CIs
Change Requests Federated CI Data Help Desk Tickets Contracts Definitive Software Library
Service Level Agreements
Other Data Related to CIs
Extended CMDB
Links Between Records CMDB Configuration Items and their Relationships
The CMDB and CMDB Extended Data layers together make up what ITIL refers to as a CMDB.
The CMDB
The 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.
Chapter 1 What is BMC Atrium CMDB? 19
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 doesnt 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 Data

The 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 doesnt 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.
20
You dont 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 dont 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 doesnt 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 dont 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 CMDB

Together, the CMDB and CMDB Extended Data form the Extended CMDB. This is equivalent to the term CMDB as used by ITIL.
The CMDB Environment

Where 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.
Chapter 1
21
Federated data
As 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 CIs 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 employees skills and a Department attribute that contains the employees 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 model

You have many different types of CIs, from computer systems to network hardware to software servers. Without a data model that accurately reflects these types and the types of relationships that can exist between them, your CMDB could store attributes that dont 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.
22
Object-oriented
An object-oriented data model has a hierarchical set of classes where each class inherits attributes from its superclassthe class above it in the hierarchyand then adds its own attributes to create a more specific type of object, a subclass. The benefits of an object-oriented data model include enforcement of common attributes among similar types of CIs and the ability to search within not just a given class of CIs, but within any branch of the hierarchy. From a base class from which all others are derived, you can search for all CIs or all relationships.
Extensible
Your infrastructure, and the technology that comprises it, is constantly changing. That means the types of CIs and relationships in your CMDB must also change, so you need a data model that is extensible. You can add attributes to your classes, and even add classes. Subclasses can have their own subclasses, extending the hierarchy to whatever level of detail you want to track.
The Common Data Model

BMC 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 partitioning
Partitioning 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 reconciliation
You 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.
Chapter 1
23
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 data

As mentioned earlier, even the most accurate data is useless if you cant 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
Data providers
BMC Configuration Discovery BMC Foundation Discovery and BMC Topology Discovery BMC Atrium Integration Engine
Data consumers
BMC Remedy Asset Management
BMC Atrium CMDB
BMC Remedy Service Desk
Microsoft SMS
Open API
Reconciliation Engine
BMC Remedy Change Management BMC Remedy Service Level Management
3rd Party Discovery & Asset Management
BMC Impact Solutions
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 Developers Reference Guide.
24
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 foundation
BMC 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.
Architecture
Figure 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.
Chapter 1
25
Figure 1-5: BMC Atrium CMDB and AR System infrastructure
Web clients
BMC Remedy User Windows clients
Other API programs
BMC Remedy Mid Tier
CMDB APIs
AR System APIs
AR System server CMDB forms (Console and classes) and workflow
Other forms and workflow
CMDB engine
Database
AR System data, including CMDB data
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.
26
Benefits
Running 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 1
27
28
Chapter
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)
Chapter 2
Planning your CMDB
29
Establish a Configuration Management team

When 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 objectives

Your 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:
30
Analyze your existing environment
Purpose
To implement consistent Configuration Management, Change Management, and Release Management processes for operational environments, packaged applications and business systems. 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. 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
Goal
Objectives
Analyze your existing environment

You should analyze your existing environment before defining a new environment.
ITIL guidelines
ITIL 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
Chapter 2
Planning your CMDB
31
BMC Checklist
This 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.
ITIL process In production In planning Planned for future No plans
Configuration Management Change and Release Remedy Change Management Management 6.0 Service Level Management Incident and Problem Management Service Impact and Event Management Asset Management and Discovery
BMC Atrium CMDB 2.1.00 BMC Remedy Change Management 7.0.02
Remedy Service Level BMC Service Level Agreements 6.0 Management 7.0.02 Remedy Help Desk 6.0 BMC Incident Management 7.0.02, BMC Problem Management 7.0.02 Yes BMC Remedy Asset Management 7.0.02, BMC Configuration Discovery 7.0.02
2 What are the results for your organization of the Personalized Routes to Value
Assessment Tool at http://www.bmc.com/bsm/rtvassessment?
Identify consumers
When 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? Whats the business purpose for tracking it? Make sure to document all consumers. If you dont 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.
32
Define your CMDB
Define your CMDB

Your 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 detail

The 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 guidelines
ITIL 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 guidelines
BMC 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 dont 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.
Chapter 2
Planning your CMDB
33
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 conventions
You need conventions for populating the Name attribute of different types of CIs to keep the text in your data normalized.
ITIL guidelines
ITIL 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.
34
Define your Configuration Management process
BMC guidelines
Also consider these guidelines: Place a layer of abstraction between logical and physical names. If you use an items 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 CIs 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 CIs

As 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.
Chapter 2
Planning your CMDB
35
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 segment
You 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 segment
To 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 segment
You 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.
36
CI control
According 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 accounting
According 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 procedures

According 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 procedures

ITIL 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.
Chapter 2
Planning your CMDB
37
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 dont 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 owners

To make sure processes are followed, you must define the roles and process owners for each segment of your Configuration Management process.
ITIL guidelines
ITIL 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.
38
Identify and justify costs
BMC guidelines
These 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 costs

As 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.
Identify
According 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.
Justify
ITIL 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.
Chapter 2
Planning your CMDB
39
Avoid potential pitfalls

ITIL 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 users 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.
40
Chapter
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)
Chapter 3
41
Phased implementation
Implementing a CMDB to manage your entire configuration at once is a daunting task, so its 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 considerations
As 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 dont want to waste resources attempting to migrate something that doesnt 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.
42
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
Chapter 3
43
Potential pitfalls
ITIL 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.
44
Chapter
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)
Chapter 4 The data model
45
Overview
The data model of BMC Atrium CMDB unifies the representation of configuration data. It is designed to store data about the most common configuration items such as hardware, software, and services and provide a mechanism for linking that information to provide a complete view of all elements of an IT environment and how they affect each other.
Classes and attributes

The BMC Atrium CMDB data model is object oriented and extensible. It consists of classes, each representing a type of configuration item that can be stored in the CMDB. Each class equates to a database table or 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.
Extensibility
A key aspect of BMC Atrium CMDB is a data model that is extensible. Infrastructure, and the data that different companies want to track about that infrastructure, is constantly changing. The data model is designed so that it can easily be extended using the Class Manager or the BMC Atrium CMDB APIs. Some BMC applications extend the data model to store data specific to their functionality. To be extensible means that there is no usage distinction between the system-defined and the user-defined data model.
Inheritance
Because the data model is object oriented, a class can have subclasses that inherit its attributes and the ability to participate in the same relationships. Subclasses are used to further classify a type of CI and give specific attributes to the more granular types. For example, BMC_ComputerSystem has subclasses to represent mainframes, printers, and 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.
46 Concepts and Best Practices Guide
Overview
Figure 4-1: Attribute inheritance

BMC_BaseElement AccountID ManufacturerName
BMC_System AccountID ManufacturerName (No unique attributes)
BMC_ComputerSystem AccountID ManufacturerName HostName Domain
BMC_Printer AccountID ManufacturerName HostName Domain AveragePagesPerMinute PaperSizesSupported
Relationships
A 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.
47
Source and destination members

The placement of a CI class as the source or destination member of a relationship is not arbitrary. The source or left class provides a group, location, hosting, or other function, and the destination or right class is a member of, is located in, depends on, or is hosted by it. 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.
Table 4-1: Examples of source and destination relationship members Class
BMC_Dependency
Source acts as Antecedent
Destination acts as Dependent. Depends on antecedent. Component. Hosted by host.
BMC_HostedSystemComponents Host
Cardinality
Every relationship class has a cardinality that defines how many instances of the source class can be related to each instance of the destination class and vice versa. BMC Atrium CMDB enforces this cardinality. One to oneEach instance of the source class can have this relationship with one instance of the destination class. One to manyEach instance of the source class can have this relationship with multiple instances of the destination class. Many to oneMultiple instances of the source class can have this relationship with each instance of the destination class. Many to manyEach instance of the source class can have this relationship with multiple instances of the destination class, and vice versa. Fulfilling a many cardinality means that multiple instances of the relationship exist.
Weak relationships
If 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.
48
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 wasnt 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 delete
Relationship 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.
49
Data storage methods

There are four methods a class can use to store its instance data, each of which is intended for a different purpose.
Regular class
A 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
Superclass (SupC) form
SupC_Attribute1 SupC_Instance1 NC_Instance1 NC_Instance2 [value] [value] [value] SupC_Attribute2 [value] [value] [value] SupC_Attribute3 [value] [value] [value]
New Class (NC) form

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

SupC_Attribute1 SupC_Attribute2 SupC_Attribute3 NC_Instance1 NC_Instance2 [value] [value] [value] [value] [value] [value] NC_Attribute1 NC_Attribute2 [value] [value] [value] [value]
By searching in the superclass form, you can find instances of both the superclass and the subclass. This is a useful way to search when you dont know which class an instance is stored in. However, you must then go to the subclass form to see all attributes of the instance. An example of a regular class in the CDM is BMC_ComputerSystem.
50
Overview
Categorization class
A categorization class does not have its own AR System regular form. Its noninherited 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
SupC_Attribute1 SupC_Instance1 NC_Instance1 NC_Instance2 [value] [value] [value] SupC_Attribute2 [value] [value] [value] SupC_Attribute3 [value] [value] [value] [value] [value] NC_Attribute1
Stub form
New Class (NC) join form

SupC_Attribute1 SupC_Attribute2 SupC_Attribute3 NC_Attribute1 NC_Instance1 NC_Instance2 [value] [value] [value] [value] [value] [value] [value] [value]
This data storage method avoids adding a database join to its subclasses. A join form is still created for the purpose of giving the categorization class a form (and therefore a database view) that uses its name, but that form is joined to a stub form and is not used by any subclasses. Because the superclass holds the instance data for a categorization class, that superclass cannot be an abstract class. As with a regular class, you can search in the superclass form of a categorization class and find instances of both the superclass and the subclass. But with a categorization class, you have access to all the attributes of that subclass. An example of a categorization class in the CDM is BMC_Memory.
51
Abstract class
An 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
SupC_Attribute1 SupC_Attribute2 SupC_Instance1 [value] [value] [value] [value] SubC1_Instance1 [value] SubC2_Instance1 [value]
New Class (NC)

NC_Attribute1 NC_Attribute2
Subclass 1 (SubC1) form

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

SupC_Attribute1 SupC_Attribute2 SubC1_Instance1 [value] [value] NC_Attribute1 NC_Attribute2 [value] [value] SubC1_Attribute1 [value]


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.
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
SupC_Attribute1 SupC_Attribute2 SupC_Instance1 [value] [value] [value] [value] SubC1_Instance1 [value] SubC2_Instance1 [value]
New Class (NC)

NC_Attribute1 NC_Attribute2
New Class (NC) replication form

SupC_Attribute1 SupC_Attribute2 SubC1_Instance1 [value] SubC2_Instance1 [value] [value] [value] NC_Attribute1 [value] [value] NC_Attribute2 [value] [value]




SupC_Attribute1 SupC_Attribute2 SubC2_Instance1 [value] [value] NC_Attribute1 [value] NC_Attribute2 [value] SubC2_Attribute1 [value]
There are no examples of an abstract class with data replication in the CDM.
53
Optional class characteristics

There 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.
Namespaces
You 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.
54
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 changes
When 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 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.
55
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_BaseElement
As the superclass for all other CI classes, BMC_BaseElement is key to the design of the CDM. Though you are unlikely to create any instances of this class, you can use its form as a single place to query for all configuration items. Attributes of this class are inherited by all CI classes. In addition to the attributes such as Name that you 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_AccessPoint
The 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_Collection
BMC_Collection and its subclasses store information about physical collections, such as subnets and LANs, and logical collections, such as roles and user communities.
BMC_Document
BMC_Document
stores information about documentation in your environment.
BMC_Equipment
The BMC_Equipment class stores information about physical equipment that is not related to computing. This can include buildings, vehicles, and other facilities items.
BMC_LogicalEntity
The BMC_LogicalEntity class tree provides mechanisms for grouping configuration items together into logical elements. This includes business processes, services, and physical locations.
56
BMC_Person
The BMC_Person class stores information about the people who manage and depend on the other CIs in your environment.
BMC_Settings
The BMC_Settings class, 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_System
The BMC_System class is the superclass for systems such as computer systems, mainframes, application systems, clusters, printers, virtual systems, and network devices. These systems aggregate a set of managed components.
BMC_SystemComponent
The BMC_SystemComponent class stores information about the components that 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_SystemService
The BMC_SystemService class contains the information necessary to represent and manage the functionality provided by a device or software feature.
Relationships
BMC_BaseRelationship
As the superclass for all other relationship classes, BMC_BaseRelationship is key to the design of the CDM. Though you are unlikely to create any instances of this class, you can use its form as a single place to query for all relationships. Attributes of this class are inherited by all relationship classes. In addition to the attributes such as Name that you 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.
57
BMC_Component
BMC_Component is used to define composite objects such as a computer system, which is made up of a computer system instance, a disk drive instance, monitors, software, network cards, and so on.
BMC_Dependency
BMC_Dependency describes configuration items that are dependent on each other. This relationship can be used to define application dependencies, such as a particular program that is dependent on an application server and database for it to run.
BMC_ElementLocation
BMC_ElementLocation relates any configuration
item to a physical location in your
environment.
BMC_MemberOfCollection
BMC_MemberOfCollection
is used to define groupings of instances in a logical manner. This is used to define network topology, or to define the set of configuration items that make up a business process or service.
Relationship subclasses
Most 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 relationships

When 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.
58
Sample models
These 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 system
Here 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 LAN

Here are the classes to use for a computer systems 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
59
Extending the data model

The CDM includes classes that describe a wide variety of IT configuration items and their relationships, and some BMC Software products install extensions that add more classes and attributes to the data model. But 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. Dont 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 extensions

Just as important as knowing how to extend the CDM is knowing when to extend it. Some situations are better addressed by storing data somewhere other than your CMDB or by using existing classes and attributes. 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.
60
Learn the classes and their attributes

Your first step in deciding whether to extend your data model should be understanding the CDM and the extensions supplied by BMC products. Study the 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 CMDB

BMC 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 arent 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 attributes

If 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.
61
Install an extension from BMC Software

BMC 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 attributes
If 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 dont, 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 subclasses
Before 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.
62
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 class
This 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 class
Use categorization classes for CIs that have five or fewer non-inherited attributesnone of which are requiredand 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 class
Use abstract subclasses when you need a logical class at a particular organizational level, but only to provide some common attributes that subclasses can inherit or to 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.
63
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 replication

An abstract class with data replication avoids a database join, thus improving performance when searching its subclasses and retrieving their instances. However, it results in slower performance when creating and modifying subclass instances, so unless you really need to search the abstract class, you should create it without data replication. Use abstract subclasses with data replication when you want the benefits of an abstract class but also need the ability to search all its subclasses in one place.
Final option
Use a final class when you want to prevent others from creating subclasses of a class you create. For example, if you build a C API program that performs tasks against a particular class, or use custom workflow with a particular class, you might mark it as Final so that your program or workflow dont have to account for subclass data that is stored with the class.
Singleton option
Use 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 companys CEO so that you can model the impact of particular IT resources on the CEO.
64
Naming and numbering rules

If 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 applications

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

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

Just as you need to occasionally look up information about classes in the CDM, you will need to look up information about classes and attributes 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 modelto 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.
66
Chapter
Federated data
This chapter includes the following topics: 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)
Chapter 5 Federated data
67
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
Incident DB
Incident ID: 0001 Category: Performance Machine: Computer A

BMC Atrium CMDB
BMC_ComputerSystem Name: Computer A SystemType: Desktop NumberOfSlots: 4

Discovery DB
Computer System Name: Computer A Registry settings: XYZ
NOTE
Federated data is not bidirectional. BMC Atrium CMDB can only establish links from its own data to an external source, not from the external source to itself.
68
When to use federated data
When to use federated data

Though a CMDB is intended as the single source of reference about your environment, it should not be the single repository of reference. Consumers should be able to use the CMDB to find all of your configuration data, but it should federate much of that data to other data stores. In general, you should have more federated data than you do data stored in the CMDB. The CMDB should be the card catalog that gives you basic information about what is in your library and tells you where to find the rest. It should not be the library. 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 dont 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.
69
Federating by instance or class

Linking to federated data can be done either at the instance level or the class level.
By instance
Linking 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 class
Linking 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.
70
Federation architecture
Federation architecture
BMC 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
CI class
CMDB
Federated link
Federated interface
Federated data store
Federated link
Federated product link
CI instance
Federated key link Key value
Federated product
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 context

The 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 youre 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.
71
Attribute substitution
This 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
CMDB
BMC_ComputerSystem Name: Computer B SystemType: Laptop NumberOfSlots: 2
Federated Interface Show records where 'Machine' = $Name$
Federated Product Incident DB
Incident DB
Incident ID: 0001 Category: Performance Machine: Computer A
Incident ID: 0002 Category: Connectivity Machine: Computer B
Foreign key substitution

Some 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.
72
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
CMDB
BMC_ComputerSystem Name: Computer B SystemType: Laptop NumberOfSlots: 2
Key = 0002 Key = 0001
Federated Interface Show records where 'ID' = $#Key#$
Federated Product Incident DB
Incident DB
Incident ID: 0001 Category: Performance
Incident ID: 0002 Category: Connectivity
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.
73
Storing and viewing federated data

A 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 Users Guide. You can also use an API program to return the access string for a federated interface and optionally also launch it.
74
Chapter
Datasets and reconciliation
This chapter includes the following topics: Overview (page 76) Overlay datasets (page 77) Controlling client write access (page 79) Reconciling data (page 79)
Chapter 6 Datasets and reconciliation
75
Overview
A 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 dont 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 datasets

BMC 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.
76
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 datasets
BMC 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 work

When you create an overlay dataset, you must specify an existing regular dataset for it to overlay. Although an overlay dataset starts out empty like any other dataset, any request for an instance in the overlay dataset passes through the overlay dataset and returns that instance from the underlying dataset. When you modify an instance in the overlay dataset 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.
77
Figure 6-1: Query to an overlay dataset

API Query DatasetId: Sandbox Qualification: 'Name' = "Computer A" Results System Type: Desktop NumberOfSlots: 4 API Query DatasetId: Sandbox Qualification: 'Name' = "Computer B" Results System Type: Desktop NumberOfSlots: 5
BMC_ComputerSystem InstanceId: 3 ReconciliationIdentity: 8 Name: Computer B SystemType: Desktop NumberOfSlots: 5 Overlay dataset "Sandbox"
BMC_ComputerSystem InstanceId: 1 ReconciliationIdentity: 7 Name: Computer A SystemType: Desktop NumberOfSlots: 4
BMC_ComputerSystem InstanceId: 2 ReconciliationIdentity: 8 Name: Computer B SystemType: Laptop NumberOfSlots: 2
Regular dataset "Production"
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 datasets

When 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 instances
If 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.
78
Controlling client write access
Instance ID and identity

When an instance is first created in an overlay dataset as the result of a modification, it retains the reconciliation identity of the instance in the underlying dataset, but is assigned a new instance ID. 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 access

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

Almost 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 instances
Before you can compare or merge different versions of something, you must determine that they indeed represent the same entity.
Overview
Identification 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 identification

To 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.
80
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 doesnt 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 its 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 datasets
Comparison 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.
Overview
Comparison 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.
81
Working with comparison

To 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 datasets
Merging takes two or more datasets and creates a composite dataset according to precedence values you specify.
Overview
Merging is essential to produce a single valid configuration when different discovery applications provide overlapping data about the same items, or when you need to commit changes that were made in an overlay dataset 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 merge

You can merge data from multiple source datasets either by creating one Merge activity that includes all the source datasets or by creating independent Merge activities that each merge only the data from one source dataset.
TIP
No matter which of these 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 hasnt changed, there is no need to merge it again.
82
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
1
Dataset C (100)
Computer System IPAddress: 10.20.30.40 SystemType: Desktop Application System Monitor
Dataset A (500)
Computer System IPAddress (200): 10.20.30.50 SystemType: Laptop
2
Application System (200) Monitor
Dataset C (100)
Computer System IPAddress (300): 10.20.30.60 SystemType (500): Laptop
Dataset B (300)
Application System (300) Monitor (500)
In this example, source Datasets A and B are merged into target Dataset C. Though Dataset A has a higher precedence value (500) than Dataset B (300), Dataset A has class and attribute precedence values for Application System and the IPAddress attribute of Computer System (both 200) that are lower than Dataset B. Dataset C has a precedence value (100) lower than either source, and as a result none of the data it contained in step 1 survives the merge. In the Merge activity represented by step 2, Dataset C receives the Monitor and the SystemType attribute of the Computer System from Dataset A, with a precedence value that trumps Dataset Bs. But because the Application System and the IPAddress attribute of the Computer System have lower precedence values in Dataset A, Dataset C receives these from Dataset B.
83
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 retainsfor each attribute that was mergedthe precedence value of the dataset that supplied the data for that attribute. When you use independent Merge activities, each activity compares the precedence values of its source dataset to the precedence values of those last victorious datasets. 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
1
Dataset C (100)
2
Dataset A (500)
Computer System IPAddress (200): 10.20.30.50 SystemType: Laptop Application System (200) Monitor
Dataset C (100)
Computer System IPAddress (200): 10.20.30.50 SystemType (500): Laptop Application System (200) Monitor (500)
Dataset B (300)
Dataset C (100)
Computer System IPAddress (300): 10.20.30.60 SystemType (500): Laptop Application System (300) Monitor (500)
This example uses the same source and target datasets as the example in Figure 62 on page 83, and achieves the same end result. Step 1 again shows the data in the target dataset before the merge.
84
Reconciling data
In the Merge activity represented by step 2, Dataset A is merged into Dataset C. Dataset As precedence values at every level are higher than Dataset Cs, so after this step Dataset C contains all the data from Dataset A. You can also see that though Dataset Cs precedence value is still 100, the precedence values of the data in it have been adopted from Dataset A. In the Merge activity represented by step 3, Dataset B is merged into Dataset C. Dataset Bs precedence value of 300 is enough to beat the precedence values stored for all attributes of the Application System and the IPAddress attribute of the Computer System, so its data replaces the data written from Dataset A in step 1. But Dataset Bs data for all attributes of the Monitor and the SystemType attribute of the Computer System is not written to the target because the data placed there from Dataset A has higher precedence values. For more information about merging, see the Installation and Configuration Guide.
Other reconciliation activities

The Reconciliation Engine offers several other activities besides Identification, Compare, and Merge.
Rename Dataset
The 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 Dataset
The 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 Dataset
The Delete Dataset activity deletes instances from one or more datasets. It does not delete the dataset itself.
Purge Dataset
The 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 Job
The Execute Job activity executes a reconciliation job.
Chapter 6 Datasets and reconciliation 85
Combining activities as a job

You 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 groups
Most 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.
86
Reconciling data
Best practices
This 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. Dont 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 dont touch the same parts of your data. Regularly review your Identification rules to make sure theyre 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.
87
88
Chapter
Administrative functionality
This chapter includes the following topics: 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)
Chapter 7
89
Controlling access
BMC Atrium CMDB offers a flexible permissions model that lets you grant rolebased permission to areas of BMC Atrium CMDB functionality and grant rowlevel read and write permission to instance data. This row-level security enables BMC Atrium CMDB to support multitenancy. Multitenancy means that one CMDB holds data about multiple parties IT environments, usually in the case of an IT service provider, and each party 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 dont have specific permissions defined. These default permissions can be overwritten by permissions specified for a particular instance.
BMC Atrium CMDB application roles

The 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 CMDB Data View Application Users with this role can
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.
90
Controlling access
Table 7-1: BMC Atrium CMDB permissions roles Name CMDB Console User Application
AtriumCMDBConso le
Users with this role can 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 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 View class definitions This role also enables class menus in the CMDB Console windows for searching, creating, and comparing instances. View, create, modify, and delete class definitions This role also enables class menus in the CMDB Console windows for searching, creating, and comparing instances. 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
CMDB Console Admin
AtriumCMDBConso le
CMDB Definitions Viewer
AtriumCMDBConso le
CMDB Definitions Admin
AtriumCMDBConso le
CMDB RE User
REApplicationDe ployable
Chapter 7
91
Table 7-1: BMC Atrium CMDB permissions roles Name Application Users with this role can 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 Definitions REApplicationDe ployable Admin
CMDB RE Manual Identification
REApplicationDe Manually identify instances ployable
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 applications 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 permissions
The 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.
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.
Table 7-2: Example instance permissions using roles and security attributes1 InstanceId 1 2 3 4 5 6 7
1.
CMDBRowLevelSecurity attribute
NULL NULL
CMDBWriteSecurity attribute
NULL
Joe can read
Joe can write
Jane can read
Jane can write
Service Desk
NULL
Service Desk Service Desk Change Team All Hands All Hands
Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Service Desk
NULL NULL
Service Desk
Joe is a member of both Service Desk and All Hands, and has the CMDB Data View role. Jane is a member of both Change Team and All Hands, and has the CMDB Data Change role.
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 permissions

Default 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.
Chapter 7
93
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.
Table 7-3: BMC_DefaultAccountPermissions matching precedence Precedence Account matching 1 2 3 4
MATCHAccountID matches AccountId on instance MATCHAccountID matches AccountId on instance MATCHAccountID is default MATCHAccountID is default
Class matching
MATCHAppliedToClassId
matches ClassId on instance

MATCHAppliedToClassId is default MATCHAppliedToClassId
matches ClassId on instance

MATCHAppliedToClassId is default
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-4: Example instances of BMC_DefaultAccountPermissions AccountId default United Industries United Industries default AppliedToClassId ASSIGNRowLevelSecurity ASSIGNWriteSecurity
BMC_COMPUTERSYST All Hands EM default BMC_MONITOR default
Service Desk Service Desk Change Team Change Team
Service Desk Service Desk Change Team
94
Tracking changes to CIs and relationships
Class and attribute permissions

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

BMC 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 Users Guide.
Auditing versus the Compare Dataset activity

Auditing is not the only way to track changes to CIs and relationships. If you use BMC Remedy Asset Management with your CMDB, you could instead track changes with the Compare Dataset reconciliation activity. You must have the Sandbox dataset (BMC.ASSET.SANDBOX) enabled in BMC Remedy Asset Management, so that user edits to a CI are saved to the Sandbox dataset. Then you can create a reconciliation job with a Compare Dataset activity that compares 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.
Chapter 7
95
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 auditing
You can audit by creating a copy of the instance that was created, modified, or deleted, or by writing the changes to a log.
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.
Copy
Copy auditing creates a copy of each audited instance. When you enable Copy auditing for a class, each form pertaining to that class is duplicated to create audit forms that hold audited instances. This includes forms from superclasses, because they hold data for instances of their subclasses. The audit forms are automatically named with the suffix :AUDIT. For example, if you enable auditing for the BMC_Person class, a subclass of the base class BMC_BaseElement, three audit forms are created:
Table 7-5: Audit forms created for BMC_Person Form type Regular Regular Join Class form BMC.CORE:BMC_BaseElement BMC.CORE:BMC_Person_ BMC.CORE:BMC_Person Audit form BMC.CORE:BMC_BaseElement:AUDIT BMC.CORE:BMC_Person_:AUDIT BMC.CORE:BMC_Person:AUDIT
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.
96
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.
Table 7-6: Audit actions Action field value Instance action 2 4 8 16 Modify Create Delete Merge
When an audit is triggered, the audited instance is copied from each class form to the corresponding audit form.
NOTE
When auditing is enabled for a class, audits can be triggered by instances of either the class or its subclasses, even if auditing is not enabled for the subclasses. This is due to the hierarchical structure of class forms. When an audit is triggered by an instance of a subclass, only the attributes of the audit-enabled superclass are written to the audit form. You can avoid subclass instances triggering an audit by using an audit qualification that matches the class ID of the superclass. Copy auditing in BMC Atrium CMDB is implemented using 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.
Chapter 7
97
Log
Log auditing creates an entry in a log form that stores all attribute values from the audited instance in one field. When you enable Log auditing for a class, you specify the name of the log form to use. If this form does not already exist, it is created automatically. You can use the same log form with multiple classes. 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 use

Keep these considerations in mind when deciding whether to use Copy or Log auditing: Copy audits degrade performance more than Log audits because their structure matches that of the actual BMC Atrium CMDB class forms, which use database joins. Also, because those join forms must be created when Copy auditing is enabled, there is a bigger performance cost at that time and possibly more disruption related to your change control procedure. Copy audits provide a more powerful search capability than Log audits because you can search on each attribute in a separate field.
98
Selecting which instances and attributes are included

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

You restrict which instances are audited by specifying an audit qualification for each class that has 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 option

For 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.
Chapter 7
99
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.
Table 7-7: Audit lifecycle of a sample instance Operation order 1 Operation Attribute1 (Audit)
NULL
Attribute2 (Copy) Chicago
Attribute3 (Audit and Copy)

NULL
Attribute4 (None) Compact disc Cassette tape
Audit triggered? Yes
Attributes written to audit form

Attribute1, Attribute2, Attribute3 Attribute1, Attribute2, Attribute3
Create
Modify
Green
Chicago
NULL
Yes
3 4 5
Modify Modify Delete
Green Green N/A
Dallas Dallas N/A
NULL
8-track tape No 8-track tape Yes N/A Yes
None
Attribute2, Attribute3 Attribute1, Attribute2, Attribute3
Bicycle N/A
In this example, Audit attribute Attribute1 and Audit and Copy attribute Attribute3 are the only attributes that can trigger an audit. However, when the instance is created an audit is triggered regardless of the fact that they are both NULL. When the instance is modified in Operation 2 the value of Attribute1 changes, triggering an audit that writes that attribute. Attribute2 and Attribute3 are also written, as they are in any audit. Both Attribute2 and Attribute4 change value in Operation 3, but no audit is triggered. In Operation 4, Attribute3 changes value and another audit is triggered. This time Attribute1 is not written because its value did not change. And when the instance is deleted in Operation 5 a final audit is triggered.
Best practices
This section gives you several best practices for working with auditing. 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. Dont audit System attributes like LastModifiedBy or ModifiedDate if you use Log auditing. AR System keeps a history of these already.
100
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 youll 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 discovered

There will be occasions when your discovery application doesnt 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 shouldnt 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.
Chapter 7 Administrative functionality 101
Working with discovery sources

Automated 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: Dont 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.
102
Adding custom workflow
Adding custom workflow

Because 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 case

A 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 hasnt 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 order

BMC 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.
Chapter 7
103
Best practices
When 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.
104
Glossary
abstract class audit
A class that has attributes but of which no instances can be created. An abstract class exists for the purpose of creating an organizational layer without a database join. See also data replication.
account
A logging of attribute values and other information for purposes of tracking the history of changes to instance data. An audit is triggered when the value of one or more specified attributes changes or when the instance is created or deleted.
base class
An 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.
activity
A class that has no superclass.

BMC Atrium Integration Engine
A 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)
An 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.
attribute
The concept of prioritizing IT efforts to support the overall goals of the business.
cardinality
The number of members a relationship class can have on each side. Cardinality can be one to one, one to many, many to one, or many to many.
cascading delete
A property or characteristic of a class, such as the IP address of a computer system. An attribute equates to a column on a database table or a field on an AR System form.
attribute permission
To 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)
Permission to view or change the value in the attribute for any instance, assuming valid instance permissions.
attribute substitution
A method of data federation in context that uses placeholders to represent attributes from a linked class. Launching the link triggers the respective attribute values to be substituted for the placeholders.
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 class
class permissions
A 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.
CDM
Permission to view instances of a class in the BMC Atrium CMDB interface or access them with AR System workflow.
CMDB
See Common Data Model (CDM).

child
See Configuration Management Database (CMDB).

CMDB Console
See destination.
CI
See configuration item (CI).

CI class
The main user interface of BMC Atrium CMDB, accessible from both web and BMC Remedy User clients.
CMDB Console User
A class that defines a type of configuration item (CI), such as a computer system or software application.
CI Relationship Viewer
An application role. Members can perform searches from the CMDB Console and view federation definitions.
CMDB Console Admin
A 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 event
An application role. Members can perform searches from the CMDB Console, view, create, and modify federation definitions, and perform CMDB Console administrative tasks.
CMDB Data Change
A 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.
CIM
An application role. Members can view, create, and modify instances if they have row-level security.
CMDB Data Change All
See Common Information Model (CIM).

class
An application role. Members can view, create, and modify instances independent of row-level security.
CMDB Data View
Metadata in BMC Atrium CMDB that defines a type of object, usually a configuration item (CI) or relationship. Either of these types of class can store data as a regular class, categorization class, abstract class, or abstract class with data replication. You can apply the final class and singleton class options to it as well.
Class Manager
An application role. Members can view instances if they have row-level security.
CMDB Definitions Admin
An application role. Members can view, create, modify, and delete classes.
CMDB Definitions Viewer
An application role. Members can view class definitions.

CMDB Extended Data
A component of BMC Atrium CMDB where you can view, create, modify, and delete the classes and attributes that make up the data model, as well as view a list of subclasses for each class.
Related data or CI attributes linked to or from BMC Atrium CMDB.

CMDB RE Definitions Admin
An application role. Members can view, create, modify, and delete reconciliation definitions and can start and cancel jobs.
106
Glossary
CMDB RE Manual Identification
consumer
An application role. Members can identify instances manually.

CMDB RE User
An application that works with data in BMC Atrium CMDB. It might view the data or modify it. See also provider.
Copy Dataset activity
An application role. Members can view reconciliation definitions and can start and cancel jobs.
cmdbdriver
A Reconciliation Engine activity that copies instances from one dataset to another.
CTI
A utility that executes BMC Atrium CMDB C API functions from a command line, prompting for parameters.
Common Data Model (CDM)
See Categories, Types, and Items (CTI).

data replication
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 Microsofts Windows Management Instrumentation.
Common Information Model (CIM)
An option for abstract classes. With this option, the instances of all subclasses are replicated to a single form to allow you to search the abstract class as though it had data. Only the attributes inherited from the abstract class are replicated.
dataset
A definition of management information developed by the Distributed Management Task Force (DMTF) that facilitates the exchange of management information between systems.
Comparison activity
A logical group of data in BMC Atrium CMDB. A dataset can represent data from a particular source, a snapshot from a particular date, or other purpose. The dataset used by BMC Software products for reconciled production data is named BMC Asset. See also overlay dataset.
Dataset Merge Precedence
A Reconciliation Engine activity that compares identified instances between two datasets, either producing a report that shows the differences or executing workflow.
configuration data
A pairing of a dataset with a Precedence group. Each Merge activity references a collection of these, called a Dataset Merge Precedence set.
defined dataset
Data about your IT environment, consisting of CIs and relationships.

configuration item (CI)
One of a pair of dataset IDs that is specified when executing a job with dynamic dataset substitution. The job is executed with the working dataset in place of the defined dataset.
Definitive Software Library (DSL)
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 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 activity
A database that stores information about your IT configuration, including both CIs and relationships.
A 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
destination
extension loader
The CI class defined as Class 2 in a relationship class, or an instance of that CI class as a member of such a relationship. Also known as the child member or weak member.
discovery
The cmdbExtLoader program, which is used for installing data model extensions and importing other BMC Atrium CMDB data and metadata.
federated data
The act of scanning your environment for configuration data.

discovery application
An application that scans your environment for configuration data and can act as a provider to BMC Atrium CMDB.
Distributed Management Task Force (DMTF)
Data linked from CIs in BMC Atrium CMDB but stored externally. Federated data might represent more attributes of the CIs or related information such as change requests on the CIs.
federated interface
An organization appointed to facilitate the exchange of management information by promoting the initiation of industry standards and interoperability.
DMTF
An instance of the BMC_FederatedInterface class that specifies how to access a particular type of federated data. See also federated link.
federated link
The connection between a class or CI and a federated interface.

federated product
See Distributed Management Task Force (DMTF).

DSL
A product that holds federated data. It can be linked to more than one federated interface.
federation
See Definitive Software Library (DSL).

Enterprise Integration Engine
See BMC Atrium Integration Engine.

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

Federation Manager
A particular type of change to the instances of specified classes. You can publish an event so that any instance of it is written to the CMDB:Events form. You can receive notification each time an instance of the event occurs by polling the form. See also CI Relationship Viewer event.
Exclusion rule
A component of BMC Atrium CMDB that you can use to manage federated data. From the Federation Manager, you can view, create, and modify federated products, federated interfaces, and federated links.
filter
A rule that specifies an attribute to be excluded from participation in a Comparison activity.

Execute Job activity
A set of criteria for restricting the information displayed by the CI Relationship Viewer. This is different from an AR System filter.
final class
A class that cannot have subclasses.

foreign key substitution
A Reconciliation Engine activity that executes a job.

extension
A logical set of classes and attributes, usually in its own namespace, that is not part of the Common Data Model (CDM).
A method of federation that assigns a key from the federated product to each linked CI. Foreign key substitution is useful when no attributes that also exist in BMC Atrium CMDB are stored in the federated product.
108
Glossary
group
instance
A set of a particular type of reconciliation definition that is referenced by an activity. See also Identification group, Precedence group, Qualification group, Workflow Execution group.
GUID
An actual incarnation of a particular class, represented as a record in BMC Atrium CMDB. Both CIs and relationships are instances of their respective classes.
instance ID
A 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
A GUID that BMC Atrium CMDB applies to each instance to uniquely identify it.
instance permissions
The right to view or modify a specific instance. These permissions are called rowlevel security and write security, respectively.
instantiate
The act of removing an instance from BMC Atrium CMDB.

Identification activity
To create an instance of a class.

ITIL
A Reconciliation Engine activity that matches instances from two or more datasets and assigns them the same identity, meaning that they represent the same real-life object.
Identification group
The Information Technology Infrastructure Library (ITIL) is an internationally accepted set of best practices for management of IT services developed by the British government
job
A set of Identification rules that collectively identify instances from a particular dataset against other datasets. Each dataset that participates in an Identification activity is paired with one Identification group.
Identification rule
A 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 activity
A rule used when identifying instances between datasets. When two instances match the qualification for the rule, they are assigned the same reconciliation ID.
identity
A Reconciliation Engine activity that merges two or more datasets into a single complete and correct dataset based on precedence values that favor the strengths of each dataset.
metadata
See reconciliation ID.

incident
Defined 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 merge
Definitions that describe the data stored in BMC Atrium CMDB. Metadata includes classes in the data model and special classes to define things such as datasets and federation objects.
multitenancy
A 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.
The separation of data and access so that a single BMC Atrium CMDB can contain the data of multiple parties, but each party can access only their own data. See also account and role.
Glossary
109
namespace
provisioning
A logical set of classes and attributes in the data model, usually related to a specific consumer or provider. The Common Data Model (CDM) uses the BMC.CORE namespace.
normalize
The process of providing access to resources, such as printers, telephones, and such, and to information, such as permissions, databases, and so on.
publish
To 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.
orphan
To make an event available so that instances of it can be written to the CMDB:Events form.
Purge Dataset activity
A Reconciliation Engine activity that removes instances that have been marked as deleted from one or more datasets.
Qualification
An instance that has been physically deleted from source datasets but still exists in the target dataset into which they merge.
overlay dataset
A Boolean statement that is evaluated to determine whether an instance should be included in an activity.
Qualification group
A dataset that provides a layer in which to make changes that are pending approval. API queries to the dataset seamlessly return its modified instances along with unmodified instances from the underlying regular dataset.
parent
A set of Qualifications that can be used in various types of activity. An instance that meets one or more Qualifications in the group is included in the activity.
reconciliation
See source.
Precedence group
The definition of an overall precedence value for a dataset. It can optionally contain precedence values for specific classes and attributes within the dataset.
precedence value
The process of managing data in multiple datasets using the Reconciliation Engine. The main activities of reconciliation are identifying, comparing, and merging datasets, though the Reconciliation Engine performs other activities as well.
reconciliation definition
A method of assigning weight to specific datasets, classes, and attributes in a Merge activity. Attribute precedence values override class precedence values, which override dataset precedence values.
production dataset
An entity defined in the Reconciliation Manager such as a job, activity, or group.

Reconciliation Engine
The component of BMC Atrium CMDB that reconciles data from different datasets.
reconciliation ID
The dataset that serves as the single source of reference for your organization and from which you make business decisions. It acts as the target dataset in most Merge activities.
provider
A GUID that the Reconciliation Engine assigns to instances in different datasets that represent the same real-life object.
Reconciliation Manager
An application, often a discovery application, that loads bulk data into BMC Atrium CMDB. See also consumer.
The component of BMC Atrium CMDB that you can use to manage reconciliation definitions.
110
Glossary
regular class
snapshot
A class that stores its instance data in its own AR System form. See also abstract class, categorization class.
related information
A set of data that represents a configuration at a certain point in time, usually stored in its own dataset. There can be multiple snapshots of a given configuration.
soft delete
Information about a CI that does not qualify as attributes of the CI, and should therefore not be stored in a Configuration Management Database (CMDB).
relationship
The act of marking an instance as deleted from BMC Atrium CMDB by setting the MarkAsDeleted attribute to Yes.
source
A connection between two CIs such as a dependency or membership. It is an instance of a relationship class. See also configuration item (CI).
relationship class
The CI class defined as Class 1 in a relationship class, or an instance of that CI class as a member of such a relationship. Also known as the parent member or strong member.
subclass
A class that defines a type of relationship between CIs, such as a dependency or membership.
relationship filter
See filter.
Rename Dataset activity
A class that is derived from another class, which is called its superclass. The subclass inherits all the attributes of its superclass and any superclasses above it in the hierarchy, and can also participate in relationships defined for all superclasses.
superclass
A reconciliation activity that renames a dataset without changing its ID, preserving references to the dataset from any reconciliation definitions.
role
A class from which other classes, called subclasses, are derived.

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

row-level security
The 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 normalization
The permission required to view a specific instance. See also write security.
rule
See normalize.
weak reference
One 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.
ruleset
See weak relationship.

weak relationship
A group of rules.
service level agreement
A contract between a service provider and a purchaser that defines the level of service.
singleton class
An optional characteristic for relationship classes, signifying that the members of a relationship form a composite object that can be reconciled as one. The destination member is considered the weak member of a weak relationship, existing as part of the source member.
An optional class characteristic that restricts the class to holding only one instance.
Glossary
111
Windows Management Instrumentation (WMI)
Microsoft's application of the Web-Based Enterprise Management initiative for an industry standard for accessing management information.
WMI
See Windows Management Instrumentation (WMI).

workflow
AR System objects such as active links, escalations, and filters that perform actions against data.
Workflow Execution group
A set of Workflow Execution rules. Each Comparison activity can optionally reference one Workflow Execution group.
Workflow Execution rule
A rule used when comparing instances between datasets. When a compared instance matches the qualification for the rule, specified AR System workflow is executed against the instance or the instance against which it is compared.
working dataset
One of a pair of dataset IDs that is specified when executing a job with dynamic dataset substitution. The job is executed with the working dataset in place of the defined dataset.
write security
The permission required along with row-level security to modify or delete a specific instance.
112
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Index
A
abstract classes about 52 extending 63 with data replication 52, 64 accessing BMC Atrium CMDB 90 CMDB data 24 federated data 74 adding attributes to existing classes 62 subclasses to Common Data Model 62 workflows to BMC Atrium CMDB 103 application roles CMDB Console Admin 91 CMDB Console User 91 CMDB Data Change 90 CMDB Data Change All 90 CMDB Data View 90 CMDB Data View All 90 CMDB Definitions Admin 91 CMDB Definitions Viewer 91 CMDB RE Definitions Admin 92 CMDB RE Manual Identification 92 CMDB RE User 91 applications, using with extended data models 65 AR System architecture 25 BMC Atrium CMDB and 25 using with extended data models 65 architecture AR System 25 BMC Atrium CMDB 16, 19 federation 71 Atrium CMDB. See BMC Atrium CMDB attributes about 46 adding to existing classes 62 Category 61 extending Common Data Model 61 attributes (continued) generating fields for AR System 65 Item 61 namespaces for 54 naming and numbering rules 65 substitution of 72 Type 61 audience for this guide 9 Audit feature 38 audit forms 96 auditing, best practices 100 audits attribute options 99 copy option 96 life cycle 100 log option 98 restricting 99 specifying qualifications 99 tracking changes to instance data 95 types 96
B
backing up CMDB data 37 benefits AR System 27 configuration management 14 decision-making support 15 federated data 22 integration 15 Best Practice icon 9 BMC Asset dataset 76 BMC Atrium CMDB See also CMDBs about 16 adding custom workflows 103 AR System and 25 architecture 16, 19 Audit feature 38 classes 55
Index
113
BMC Atrium CMDB (continued) Common Data Model 33, 46, 55 controlling access 90 datasets 76 documentation 10, 11 Extended Data 20 infrastructure about 19 application layer 21 CMDB Environment layer 21 CMDB Extended Data layer 20 CMDB layer 19 Extended CMDB 21 federated 19 related data 20 permissions about 90 attribute 95 class 95 default instance 93 instance 92 roles 90 Reconciliation Engine 79 related data 20 replicating data 102 BMC Atrium CMDB data model. See data models BMC Impact Solutions, using new classes 65 BMC Software, contacting 2 BMC_AccessPoint class 56 BMC_BaseElement class 56 BMC_BaseRelationship class 57 BMC_Collection class 56 BMC_Component class 58 BMC_Dependency class 58 BMC_Document class 56 BMC_ElementLocation class 58 BMC_Equipment class 56 BMC_LogicalEntity class 56 BMC_MemberOfCollection class 58 BMC_Person class 57 BMC_Settings class 57 BMC_System class 57 BMC_SystemComponent class 57 BMC_SystemService class 57 bulk data, loading 25
C
cardinality 48 cascading delete 49 categorization classes about 51 extending 63 Category attributes 61 CDM. See Common Data Model changes, tracking instance data 95 checklists for analyzing environments 32 CI control 37 CIM. See Common Information Model CIs. See configuration items classes about 46 abstract 52 abstract with data replication 52 adding attributes to existing 62 BMC Atrium CMDB 55 categorization 51 configuration item 46 BMC_AccessPoint 56 BMC_BaseElement 56 BMC_Collection 56 BMC_Document 56 BMC_Equipment 56 BMC_LogicalEntity 56 BMC_Person 57 BMC_Settings 57 BMC_System 57 BMC_SystemComponent 57 BMC_SystemService 57 extending 62 in Common Data Model 56 data storage methods 50 deleting instances of 49 extending 62 final 54 linking to federated data 70 naming and numbering rules 65 options 54 regular 50 relationship 47 BMC_BaseRelationship 57 BMC_Component 58 BMC_Dependency 58 BMC_ElementLocation 58 BMC_MemberOfCollection 58 extending 63 in Common Data Model 57
114
classes (continued) relationship (continued) subclasses 58 replicating subclasses 52 singleton 54 CM. See configuration management CMDB Console Admin role 91 CMDB Console User role 91 CMDB Data Change All role 90 CMDB Data Change role 90 CMDB Data View All role 90 CMDB Data View role 90 CMDB Definitions Admin role 91 CMDB Definitions Viewer role 91 CMDB Environment layer 21 CMDB process segments audits 37 backing up 37 CI control 37 configuration management process 35 data cleaning 37 defining 36 status accounting 37 verifications 37 CMDB RE Definitions Admin role 92 CMDB RE Manual Identification role 92 CMDB RE User role 91 CMDB segments. See CMDB process segments CMDBs See also BMC Atrium CMDB BMC Atrium infrastructure layer 19 configuration items and 17 data types 16 defining 33 discovery and 102 implementing controlling CM process 43 migrating data 42 phases 42 pitfalls 44 integrating ITIL processes 15 ITIL meaning 21 planning analyzing environment 31 avoiding pitfalls 40 costs 39 defining CM process 35 defining CMDBs 33 establishing management teams 30 identifying consumers 32 purposes, goals, and objectives 30 working with discovery sources 102 Common Data Model about 46, 55 configuration item classes 56 configuration items and 33 diagram 61 extending 60 relationship classes 57 sample models 59 Common Information Model 55 Compare Dataset activity, tracking drift with 95 comparing datasets 81 computer systems, sample data models 59 configuration data datasets and 76 unified representation 46 configuration items about 17 BMC guidelines for defining 33 classes 46 CMDBs and 17 Common Data Model classes 56 datasets and 76 defined 17 deleting 101 detail, defining 33 examples 17 ITIL guidelines for defining 33 missing 101 naming conventions 34 related data 18 relationships 17, 35 scope, defining 33 undiscovered 101 configuration management benefits 14 CMDB segments, defining 36 costs 39 data accuracy 16 data availability 16 goals 14 ITIL and 14 process controlling 43 defining 35 defining process owners 38 defining roles 38 Provider segment, defining 36 Reconciliation segment, defining 36 teams, establishing 30 configuration management databases. See CMDBs consumers, identifying 32 copying dataset instances 85
Index
115
costs identifying configuration management 39 justifying configuration management 39 creating subclasses 62 customer support 3 datasets about 76 BMC Asset 76 comparing 81 copying instances 85 deleting instances 85 identifying 79 merging 82 overlay about 77 deleting instances 78 instance IDs 79 queries to 77 working with 78 production 76 purging instances 85 reconciling 79 renaming 85 defining CMDBs 33 configuration management process 35 deleting cascading 49 configuration items 101 dataset instances 85 instances 49 relationships 49 destination classes 48 diagram of Common Data Model 61 discovery CMDBs and 102 deleting undiscovered CIs 101 working with sources 102 Distributed Management Task Force 55 DMTF. See Distributed Management Task Force documentation for BMC Atrium CMDB 10, 11 documenting extensions 66 drift tracking 95
D
data See also federated data access 24 auditing 95 backing up 37 BMC Atrium CMDB model 46 bulk loading 25 cleaning 37 configuration 46 federated 68 flexible model 22 migrating to the BMC Atrium CMDB 42 open access 24 overlay dataset 78 partitioning 23 programmatic access to 24 reconciling 23, 79 related to configuration items 18 replicating abstract class 52 replicating BMC Atrium CMDB 102 tracking changes 95 types stored in ITIL CMDBs 16 data models See also Common Data Model about 22, 46 attributes 46 classes 46 abstract 52 abstract with data replication 52 categorization 51 data storage methods 50 final 54 options 54 regular 50 singleton 54 extensibility 23, 46 industry standards 55 inheritance 46 namespaces 54 object-oriented 23 synchronizing changes 55
E
Environment, CMDB layer 21 environments, analyzing about 31 BMC checklist 32 ITIL guidelines 31 examples configuration item 17 relationship 18 Extended CMDB 21 Extended Data layer 20
116
extending Common Data Model about 60 abstract classes 63 abstract classes with data replication 64 adding attributes 62 adding subclasses 62 BMC applications and 65 BMC Impact Solutions and 65 BMC products and 60 categorization classes 63 diagram 61 documenting 66 final classes 64 naming and numbering rules 65 regular classes 63 relationship classes 63 singleton classes 64 with existing attributes 61 guidelines for (continued) defining roles, ITIL 38 naming configuration items, BMC 35 naming configuration items, ITIL 34
I
icons Best Practice 9 New 9 identifying datasets 79 instances 80 implementing CMDBs 4144 incremental merge 82, 87 industry standards, data model 55 Information Technology Infrastructure Library. See ITIL infrastructure, BMC Atrium CMDB 19 inheritance 46 instances audited 96 copying dataset 85 default permissions 93 deleting dataset 85 deleting from overlay datasets 78 deleting relationship class 49 identifying in datasets 79, 80 linking to federated data 70 permissions 92 purging dataset 85 replicating 52 sample audit 100 integrating IT processes 15 Item attributes 61 ITIL about 14 CI naming guidelines 34 CMDB, defined per 21 configuration management and 14 data types 16 defining configuration items 33 Extended CMDB and 21 guidelines for analyzing environments 31 defining configuration items 33 defining process owners 38 defining roles 38 naming configuration items 34
F
federated data about 22, 68 accessing 74 architecture 71 attribute substitution 72 benefits 22 BMC Atrium CMDB infrastructure 19 class-level links 70 foreign key substitution 72 instance-level links 70 linking 70 model 16 retrieving data in context 71 using 69 final classes about 54 extending 64 foreign key substitution 72 forms, audit 96 forms, log 98
G
guidelines for analyzing environments 31 defining configuration items, BMC 33 defining configuration items, ITIL 33 defining process owners, BMC 39 defining process owners, ITIL 38 defining roles, BMC 39
Index
117
J
jobs, combining reconciliation activities 86
L
left-side classes 48 linking to federated data 70 log forms 98
M
members, relationship 47 merging datasets incrementally 82, 87 overview 82 with independent activities 84 with one activity 83 Microsoft Windows Management Instrumentation 55 migrating data to the BMC Atrium CMDB 42 multitenancy, defined 90
N
namespaces attribute 54 data model 54 reconciliation and 54, 80 naming configuration items 34 rules for extensions 65 New icon 9 numbering rules for extensions 65
permissions attribute 95 BMC Atrium CMDB 90 class 95 CMDB Console Admin 91 CMDB Console User 91 CMDB Data Change 90 CMDB Data Change All 90 CMDB Data View 90 CMDB Data View All 90 CMDB Definitions Admin 91 CMDB Definitions Viewer 91 CMDB RE Definitions Admin 92 CMDB RE Manual Identification 92 CMDB RE User 91 default instance 93 instance 92 roles 90 phases of CMDB implementation 42 pitfalls CMDB implementation 44 CMDB planning 40 planning CMDBs 2940 process owners BMC guidelines for defining 39 defining for segments 38 ITIL guidelines for defining 38 process segments. See CMDB process segments processes, integrating IT 15 product support 3 production datasets, defined 76 programmatic access to data 24 Provider process segments, defining 36 purging dataset instances 85
O
object-oriented data models 23 open access to data 24 options, class 54 overlay datasets 77
Q
qualifications, audit 99 queries, overlay dataset 77
R
reconciliation about 23 best practices 87 combining activities 86 comparing datasets 81 copying dataset instances 85 data 79 deleting dataset instances 85 executing jobs 85
P
parent classes 48 partitioning about 23 datasets and 76 namespaces and 54 pending changes 55
118
reconciliation (continued) identifying datasets 80 jobs 86 merging datasets 82 namespaces and 54, 80 purging datasets 85 renaming datasets 85 Reconciliation Engine about 79 executing jobs 85 Reconciliation process segments, defining 36 regular classes about 50 extending 63 relationships cardinality 48 cascading delete 49 classes about 47 deleting instances of 49 destination 48 left-side 48 placement 48 right-side 48 source 48 Common Data Model classes 57 configuration item 17, 35 datasets and 76 deleting 49 examples 18 extending classes 63 members 47 weak 48 renaming datasets 85 replicating BMC Atrium CMDB data 102 restricting audits 99 right-side classes 48 roles BMC Atrium CMDB permissions 90 BMC guidelines for defining 39 defining for segments 38 ITIL guidelines for defining 38 segments. See CMDB process segments singleton classes about 54 extending 64 source classes 48 status accounting, defined 37 subclasses adding to Common Data Model 62 creating 62 relationship 58 substitution attribute 72 foreign key 72 support, customer 3 synchronizing data model changes 55 pending changes 55
T
teams, configuration management 30 technical support 3 tracking instance data changes 95 Type attributes 61
U
use cases, adding custom workflows 103
W
weak relationships 48 WMI. See Microsoft Windows Management Instrumentation workflows adding custom to BMC Atrium CMDB 103 best practices for adding 104 sample use cases 103
S
samples Common Data Model 59 custom workflows 103 instance audits 100 LAN computer system data models 59 typical computer system data models 59 scope, configuration item 33 Index 119
120
*78007* *78007* *78007* *78007*
*70087*

Concepts and Best Practices

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Concepts and Best Practices

Încărcat de

Drepturi de autor:

Formate disponibile

BMC Atrium CMDB 2.1.

Concepts and Best Practices Guide

Contacting BMC Software

United States and Canada

Outside United States and Canada

Restricted Rights Legend

Support by telephone or email

Before Contacting BMC Software

Concepts and Best Practices Guide

Datasets and reconciliation

Concepts and Best Practices Guide

Best Practice and New icons

BMC Atrium CMDB 2.1.00

BMC Atrium CMDB documentation

HTML (product DVD only)

Concepts and Best Practices Guide

Title Troubleshooting Guide

Print and PDF

BMC Atrium CMDB 2.1.00

Administrators Print and PDF

Administrators Print and PDF

Concepts and Best Practices Guide

What is BMC Atrium CMDB?

What is BMC Atrium CMDB?

BMC Atrium CMDB 2.1.00

ITIL and Configuration Management

ITIL and Configuration Management

What is BMC Atrium CMDB?

BMC Atrium CMDB 2.1.00

Data is the key

Architecture of BMC Atrium CMDB

Which data goes into an ITIL CMDB

Concepts and Best Practices Guide

Architecture of BMC Atrium CMDB

Relationships among CIs

What is BMC Atrium CMDB?

BMC Atrium CMDB 2.1.00

Online Store (Service)

Server group (Collection)

Shopping Cart (Software)

Orders Database (Software)

Web Server (Computer system)

Concepts and Best Practices Guide

Architecture of BMC Atrium CMDB

BMC Atrium CMDB

Capacity Management Discovery Application 1 Discovery Application 2 Problem Management Requests

Requests for Configuration Data

Software Config. Management Service Impact Management

Help Desk Requests

CMDB Extended Data

Service Level Agreements

Other Data Related to CIs

BMC Atrium CMDB 2.1.00

The CMDB Extended Data

Concepts and Best Practices Guide

Architecture of BMC Atrium CMDB

The Extended CMDB

The CMDB Environment

What is BMC Atrium CMDB?

BMC Atrium CMDB 2.1.00

Flexible data model

Concepts and Best Practices Guide

Architecture of BMC Atrium CMDB