BMCAtriumCore7604ConceptsPlanningGuide

www.bmc.com

BMC Atrium Core 7.6.04

Concepts and Planning Guide

January 2011

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

Contacting BMC Software

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

United States and Canada

Address BMC SOFTWARE INC2101 CITYWEST BLVDHOUSTON TX 77042-2827 USA

Telephone 713 918 8800 or800 841 2031

Fax 713 918 8000

Outside United States and Canada

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

© Copyright 2009-2011 BMC Software, Inc.

BMC, BMC Software, and the BMC Software logo are the exclusive properties of BMC Software, Inc., are registered with the U.S. Patent and Trademark Office, and may be registered or pending registration in other countries. All other BMC trademarks, service marks, and logos may be registered or pending registration in the U.S. or in other countries. All other trademarks or registered trademarks are the property of their respective owners.

DB2 and IBM are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both.

IT Infrastructure Library is a registered trademark of the Office of Government Commerce and is used here by BMC Software, Inc., under license from and with the permission of OGC.

ITIL® is a registered trademark, and a registered community trademark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office, and is used here by BMC Software, Inc., under license from and with the permission of OGC.

Oracle is a registered trademark of Oracle Corporation.

UNIX is a registered trademark of The Open Group.

Oracle and Java are trademarks of Oracle and/or its affiliates. Other names may be trademarked of their respective owners.

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 LegendU.S. Government Restricted Rights to Computer Software. UNPUBLISHED -- RIGHTS RESERVED UNDER THE COPYRIGHT LAWS OF THE UNITED STATES. Use, duplication, or disclosure of any data and computer software by the U.S. Government is subject to restrictions, as applicable, set forth in FAR Section 52.227-14, DFARS 252.227-7013, DFARS 252.227-7014, DFARS 252.227-7015, and DFARS 252.227-7025, as amended from time to time. Contractor/Manufacturer is BMC Software, Inc., 2101 CityWest Blvd., Houston, TX 77042-2827, USA. Any contract notices should be sent to this address.

http://www.bmc.com

mailto:[email protected]

Customer Support

You can obtain technical support by using the Support page on the BMC Software website or by contacting Customer Support by telephone or email. To expedite your inquiry, please see “Before Contacting BMC Software.”

Support website

You can obtain technical support from BMC Software 24 hours a day, 7 days a week at http://www.bmc.com/support. From this website, you can:

■ Read overviews about support services and programs that BMC Software offers.■ Find the most current information about BMC Software products.■ Search a database for problems similar to yours and possible solutions.■ Order or download product documentation.■ Report a problem or ask a question.■ Subscribe to receive email notices when new product versions are released.■ Find worldwide BMC Software support center locations and contact information, including email addresses, fax

numbers, and telephone numbers.

Support by telephone or email

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

Before contacting BMC Software

Have the following information available so that Customer Support can begin working on your issue immediately:

■ Product information

— Product name— Product version (release number)— License number and password (trial or permanent)

■ Operating system and environment information

— Machine type— Operating system type, version, and service pack— System hardware configuration— Serial numbers— Related software (database, application, and communication) including type, version, and service pack or

maintenance level

■ Sequence of events leading to the problem

■ Commands and options that you used

■ Messages received (and the time and date that you received them)

— Product error messages— Messages from the operating system, such as file system full— Messages from related software

http://www.bmc.com/support


License key and password information

If you have a question about your license key or password, contact Customer Support through one of the following methods:

■ E-mail [email protected]. (In the Subject line, enter SupID:yourSupportContractID, such as SupID:12345.)

■ In the United States and Canada, call 800 537 1813. Outside the United States and Canada, contact your local support center for assistance.

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



Contents

About this book 11

How to use this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Prerequisite documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12BMC Atrium Core documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Chapter 1 About BMC Atrium Core 17

Overview of Business Service Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Value proposition of BMC Atrium Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

The business challenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19BMC Atrium Core Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

BMC Atrium Core components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20The BMC Atrium CMDB component of BMC Atrium Core. . . . . . . . . . . . . . . . . . 20The Atrium Integrator component of BMC Atrium Core . . . . . . . . . . . . . . . . . . . . 25

BMC Atrium Core architecture and features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26BMC Atrium Core architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Open access to data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Data partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Web services and service oriented architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29User access to BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Overview of virtualization management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Architecture of the CMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30The CMDB layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31The CMS Data layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31CMS Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

BMC Remedy AR System foundation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33BMC Remedy AR System architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Benefits of using BMC Remedy AR System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

ITIL and SACM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Purpose of SACM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Goals of SACM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Benefits of SACM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Data is the key to SACM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Control of the Configuration Management process. . . . . . . . . . . . . . . . . . . . . . . . . 37

Calbro Services user story. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Calbro Services company background. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Implementation of BMC Atrium Core at Calbro Services. . . . . . . . . . . . . . . . . . . . 39

Contents 5

Chapter 2 Planning a CMDB 41

CMDB planning stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Stage 1: Assembling the project team . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Stage 2: Defining requirements and creating IT service model blueprint . . . . . . . 42Stage 3: Selecting CMDB solution and tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Stage 4: Constructing and maintaining your CMDB . . . . . . . . . . . . . . . . . . . . . . . . 43Stage 5: Driving ongoing value . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Phased implementation of a CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Challenges, critical success factors, and risks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Critical success factors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Chapter 3 Planning the data model 47

Data model overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Data model classes and attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Data model extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Attribute inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Relationships in the data model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49BMC Atrium CMDB data storage methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Synchronization of changes to classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Overview of the Common Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Configuration item classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Relationship classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Federated data classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Detailed relationship categorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Sample data models. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Planning to extend the data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61How federation extends the data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61How the Category, Type, and Item attributes extend the data model. . . . . . . . . . 62How additional attributes extend the data model . . . . . . . . . . . . . . . . . . . . . . . . . . 62How additional subclasses extend the data model. . . . . . . . . . . . . . . . . . . . . . . . . . 63How Calbro Services extended the data model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Naming and numbering rules for new classes and attributes. . . . . . . . . . . . . . . . . 66Making data model changes visible to applications . . . . . . . . . . . . . . . . . . . . . . . . . 66Documenting data model extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Chapter 4 Planning BMC Atrium CMDB data 69

What data goes into an ITIL CMDB?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Configuration items . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70Relationships among CIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Data related to CIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6 Concepts and Planning Guide

Planning to populate BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Mapping CIs to the data model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Mapping CIs to discovery data sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Assessing the configuration data source environment . . . . . . . . . . . . . . . . . . . . . . 76Managing unqualified data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Grouping CIs into datasets. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Identifying the discovery schedule sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Planning to use federated data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84When to use federated data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85How Calbro Services uses federation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Federation methods in BMC Atrium CMDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Controlling access to data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Overview of multitenancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91BMC Atrium CMDB multitenancy permission model . . . . . . . . . . . . . . . . . . . . . . 92Calbro Services’ access implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Sizing considerations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Replicating BMC Atrium CMDB data to other servers . . . . . . . . . . . . . . . . . . . . . . . . . 94

Chapter 5 Planning data normalization and the Product Catalog 95

Overview of normalization and the Product Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . 96Normalization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Product Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Entries in the Product Catalog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Components of the Product Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Categorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Multitenancy with the Product Catalog. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

How Calbro Services planned normalization and Product Catalog implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Chapter 6 Planning data reconciliation 101

Identifying instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Comparing datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103Merging datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Using a single Merge activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Using independent Merge activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Other reconciliation activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Combining activities as a job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Qualification groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Chapter 7 Planning a service model 109

Service model overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Relationships between service components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Adding CIs and relationships to service models using BMC Atrium CMDB . . 111Service model components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Designing a service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113Defining business goals for the service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115Decomposing a business service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116Defining the service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Contents 7

Chapter 8 Implementing BMC Atrium Core 121

Overview of the process to implement BMC Atrium Core . . . . . . . . . . . . . . . . . . . . . 122Configuring permissions and multitenancy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Configuring roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123Configuring class and attribute permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124Configuring instance permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125Configuring multitenancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Configuring the Product Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Creating Product Catalog entries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127Configuring best-practice categorizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128Approving products, versions, and patches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

Configuring the data model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129Creating datasets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Configuring Atrium Integrator for data import. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

Configuring source and target connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Creating jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132Editing transformations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Configuring normalization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133Configuring reconciliation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134Creating the service model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Using BMC Impact Solutions to create a service model. . . . . . . . . . . . . . . . . . . . . 136Deciding on the structure of the service model. . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Maintain your service model dynamically. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Importing data to BMC Atrium CMDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Creating test cases to validate data population . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Bringing data into BMC Atrium CMDB using discovery tools. . . . . . . . . . . . . . . 139Importing data using Atrium Integrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Adding data manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140Validating data import results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Removing failed-import data from BMC Atrium CMDB . . . . . . . . . . . . . . . . . . . 141Normalizing BMC Atrium CMDB data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Reconciling BMC Atrium CMDB data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142How Calbro Services discovers their IT environment and imports data . . . . . . 142

Best practices for specific implementation scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 143Best practice for scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Best practices for bulk loads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143Best practices for incremental loads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Best practices for Atrium Explorer edits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145Best practices for BMC Remedy ITSM manual edits . . . . . . . . . . . . . . . . . . . . . . . 146

Chapter 9 Managing BMC Atrium Core 147

Tracking changes to CIs and relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Auditing versus the Compare Dataset activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148Types of auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149Selecting which instances and attributes are included in an audit. . . . . . . . . . . . 152Receiving CI change events with Event Channels . . . . . . . . . . . . . . . . . . . . . . . . . 154

Deleting CIs that are no longer discovered . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157


Custom workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157Calbro Services’ custom workflow for viewing unreconciled CIs . . . . . . . . . . . . 157Filter execution order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Glossary 159

Index 169

Contents 9


About this book

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

How to use this guideThis guide is organized to help you implement BMC Atrium Core. Information presented early in the guide helps you with the concepts and tasks that follow.

Type of information Chapters

Overview of Business Service Management (BSM) and the BMC Atrium Core solution

Chapter 1, “About BMC Atrium Core”

Concepts and information necessary for planning to implement BMC Atrium Core

Chapter 2, “Planning a CMDB”Chapter 3, “Planning the data model”Chapter 4, “Planning BMC Atrium CMDB data”Chapter 5, “Planning data normalization and the Product Catalog”Chapter 6, “Planning data reconciliation”Chapter 7, “Planning a service model”

The end-to-end tasks necessary to implement and maintain BMC Atrium Core

Chapter 8, “Implementing BMC Atrium Core”Chapter 9, “Managing BMC Atrium Core”

About this book 11


Prerequisite documentationBefore planning your CMDB, read the Step-by-Step Guide to Building a CMDB, published by BMC Software. Organized into stages, this guide provides practical guidance for structuring a CMDB project and delivering a comprehensive and useful CMDB. The stages are divided into steps, each with objectives that help you meet the milestone for that stage. You can request this book from http://www.bmc.com.

Also consider taking BMC Educational Services’ companion course ITIL V3: Practical Steps to Building a CMDB, which shows how to build a CMDB based on best practices from the IT Infrastructure Library® (ITIL®) Version 3.

BMC Atrium Core documentationThis section describes the complete set of BMC Atrium Core documentation, including manuals, help systems, videos, and so on.

Unless otherwise noted, documentation is available on the BMC Atrium Core documentation media (DVD or Electronic Product Download bundle) and on the BMC Customer Support site, free of charge, at http://www.bmc.com/support.

To find this documentation on the BMC Customer Support site, choose Product Documentation > Supported Product A-Z List > BMC Atrium CMDB Enterprise Manager > 7.6.03.

Title Description Audience

BMC Atrium CMDB 7.6.04 Administrator's Guide

Information about setting permissions, configuring federation, modifying the data model, configuring an impact model, and other administrative tasks in BMC Atrium CMDB.

Configuration managers, application administrators, and asset analysts.

BMC Atrium CMDB 7.6.04 Common Data Model Diagram

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


BMC Atrium CMDB 7.6.04 Data Model Help

Description and details of superclasses, subclasses, attributes, and relationship classes for each class. Contains only information about the CDM at first, but you can update it to include information about data model extensions that you install.

Note: This Help is provided in HTML and is available on the BMC Atrium Core media. It is not available on the BMC Customer Support site.


BMC Atrium CMDB 7.6.04 Data Modeling Guide

Best practices for using the classes that BMC provides for BMC Atrium CMDB (both the CDM and extensions) to model complex business entities, focusing on the use of multiple related CIs to model an entity rather than on general information about a class or attribute.



http://www.bmc.com

http://www.bmc.com


BMC Atrium Core documentation

BMC Atrium CMDB 7.6.04 Normalization and Reconciliation Guide

Information about normalizing data in BMC Atrium CMDB and reconciling CIs from different data providers into a single production dataset.


BMC Atrium CMDB 7.6.04 Online Help

Help for using and configuring BMC Atrium CMDB, including BMC Atrium Product Catalog, Reconciliation Engine, Normalization Engine, and so on.

Note: This Help is provided in HTML and is available through the Help links in the BMC Atrium CMDB user interface. It is not available on the BMC Customer Support site.

Configuration managers, application administrators, asset analysts, and users that work with CIs and need to understand the relationships that exist within BMC Atrium CMDB.

BMC Atrium CMDB 7.6.04 User's Guide

Information about using BMC Atrium CMDB, including searching for and comparing CIs and relationships, relating CIs, viewing history, running impact simulations, and viewing federated data.

Users that work with CIs and need to understand the relationships that exist within BMC Atrium CMDB.

BMC Atrium Core 7.6.04 Compatibility Matrix

Information about the BMC Atrium Core configurations that are expected to work properly based on design, testing, or general understanding of the interaction between products.

Note: Download the BMC Atrium Core 7.6.04 Compatibility Matrix from the BMC Customer Support site at http://www.bmc.com/support/reg/remedy-compatibility-tables.html?c=n.


BMC Atrium Core 7.6.04 Concepts and Planning Guide

Information about CMDB concepts and high-level steps for planning and implementing BMC Atrium Core.

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

BMC Atrium Core 7.6.04 Developer’s Reference Guide

Information about creating API programs using C API functions and data structures.

Application administrators and programmers.

BMC Atrium Core 7.6.04 Installation Guide

Information about installing, upgrading, and uninstalling BMC Atrium Core features.

Application administrators.

BMC Atrium CMDB 7.6.04 Javadoc Help

Information about Sun™ Java™ classes, methods, and variables that integrate with BMC Atrium CMDB.


Application programmers.


About this book 13

http://www.bmc.com/support/reg/remedy-compatibility-tables.html?c=n




BMC Atrium Core 7.6.04 Master Index

Combined index of all guides. Everyone.

BMC Atrium Core 7.6.04 Product Catalog and DML Guide

Information about configuring the Product Catalog and DML, adding products, and creating aliases for products, manufacturers, and categorizations.

System administrators, IT managers, network managers, and other qualified personnel who are familiar with their computing and networking environment.

BMC Atrium Core 7.6.04 Release Notes

Information about new features, known issues, and other late-breaking topics.

Everyone.

BMC Atrium Core: Taking Your Data Into Production End to End

End-to-end high-level steps for bringing data into BMC Atrium CMDB from a third-party source and making it available in your production dataset.

Note: This Flash video is available on the BMC Atrium Core media. It is not available on the BMC Customer Support site.


BMC Atrium Core 7.6.04 Troubleshooting Guide

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

Application administrators, programmers, and BMC Support personnel.

BMC Atrium Core 7.6.04 Web Services Help

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


Application administrators and programmers.

BMC Atrium Integration Engine 7.6.04 ADK Developer's Guide

Information about how to build adapters that can transfer information between an external data store and either BMC Remedy AR System forms or BMC Atrium CMDB.

Developers who have a basic understanding of BMC Atrium Integration Engine and want to build adapters that can exchange data between two data sources.

BMC Atrium Integration Engine 7.6.04 Online Help

Help for using and configuring BMC Atrium Integration Engine.

Note: This Help is provided in HTML and is available through the Help links in the BMC Atrium Integration Engine user interface. It is not available on the BMC Customer Support site.

Users who are responsible for setting up data transfer integrations between external data stores and either BMC Atrium CMDB or BMC Remedy AR System.



BMC Atrium Core documentation

BMC Atrium Integration Engine 7.6.04 User's Guide

Information about creating data exchanges and data mappings, defining rules and queries, activating event-driven data exchanges, defining connection settings, and other BMC Atrium Integration Engine concepts.

Users who are responsible for setting up data transfer integrations between external data stores and either BMC Atrium CMDB or BMC Remedy AR System.

Mapping Your Data to BMC Atrium CMDB 7.6.04 Classes

Spreadsheet that maps common IT objects to the appropriate class, whether part of the CDM or an extension. This spreadsheet also includes information about further categorizing instances using key attributes, and best practices for creating normalized relationships.



About this book 15



Chapter

1
About BMC Atrium Core
This section introduces and describes the components of BMC Atrium Core, including BMC Atrium CMDB.

The following topics are provided:

� Overview of Business Service Management (page 18)� Value proposition of BMC Atrium Core (page 19)� BMC Atrium Core components (page 20)� BMC Atrium Core architecture and features (page 26)� Architecture of the CMS (page 30)� BMC Remedy AR System foundation (page 33)� ITIL and SACM (page 34)� Calbro Services user story (page 38)



Overview of Business Service ManagementBusiness Service Management (BSM) is a comprehensive approach and unified platform for running IT. BSM offers a way to bring together many disparate processes and tools to create quantifiable improvement in efficiency and the ability to view technology as it applies to business process.

BSM enables your IT department to:

� Operate by service rather than by individual configuration items or technology.

� Prioritize your efforts, improving the service that you deliver to your business.

� Understand and predict how technology impacts your business and how your business impacts the IT infrastructure.

BMC Software delivers a BSM solution according to the key functions of an IT organization, as shown in Figure 1-1:

Figure 1-1: BSM overview


Value proposition of BMC Atrium Core

� Request and support—simplify and automate processes for requesting, changing, and supporting business services.

� Provision and configure—deploy business services consistently for applications, servers, networks, and clients.

� Monitor and operate—identify and resolve IT issues for cloud, virtual, distributed, and mainframe environments. Automate repetitive, manual tasks to eliminate errors and get things done more quickly.

� Plan and govern—manage your IT supply, demand, and budget. Ensure compliance with policies and regulations.

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

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

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

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



BMC Atrium Core componentsThis section provides an overview of the following components that compose BMC Atrium Core:

� BMC Atrium CMDB, including the following components:

� Normalization Engine

� Reconciliation Engine

� Atrium Explorer

� Atrium Impact Simulator

� Common Data Model

� Class Manager

� Product Catalog and Definitive Media Library

� Service Catalog

� Atrium Integrator

NOTE Atrium Integrator replaces BMC Atrium Integration Engine. You can continue using BMC Atrium Integration Engine for existing data mappings and exchanges, but BMC recommends that you use Atrium Integrator for all new data transfers.

The BMC Atrium CMDB component of BMC Atrium CoreBMC Atrium CMDB stores information about the configuration items (CIs) in your IT environment and the relationships among them. BMC Atrium CMDB should reflect your current environment—how it exists now rather than what it should be. For a detailed definition of configuration items, see “Configuration items” on page 70.

Data providers, such as discovery applications, put data into BMC Atrium CMDB, where it is partitioned into separate datasets. This data is then brought together into a consolidated production dataset that you use as the single source of reference for your IT environment.

Consuming applications, such as BMC Remedy IT Service Management (BMC Remedy ITSM), BMC Remedy Asset Management, BMC Remedy Service Level Management, applications represented in Figure 1-1 on page 18, and more, use the data in the production dataset.


BMC Atrium Core components

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

� Product categorizations—Replaces the values of Category, Type, and Item and manufacturer data such as ManufacturerName, Model, and VersionNumber with correct values from the Product Catalog.

� Impact—Sets the impact attributes on relationship instances based on rules.

� Relation Name—For relationships, replaces the existing Name value with the BMC-recommended name based on the CI classes in the relationship.

� Row-level security—Sets the row-level and attribute-level permissions on CIs as you define them.

� Version Rollup feature—Sets the MarketVersion attribute for instances to a common value based on default or custom rules. This provides more accurate information for managing licenses.

� Suite Rollup feature—Allows you to define suites and their products and to identify instances as a suite, a suite component, or a standalone application. This allows more accurate management of suite and individual licenses.

With the Normalization Engine, you can define what is normalized and when. You can select the BMC Atrium CMDB classes to normalize and the attributes for each class. You can also choose which datasets are normalized. For more information about normalization, see the BMC Atrium CMDB 7.6.04 Normalization and Reconciliation Guide.

The Reconciliation Engine component of BMC Atrium CMDBThe Reconciliation Engine is installed with BMC Atrium CMDB. The main goal of the Reconciliation Engine is the creation of a production dataset that contains accurate data from all available sources. Data in the production dataset can be used by consuming applications. The following Reconciliation Engine activities work in direct support of this goal:

� Identifying class instances that are the same entity in two or more datasets

� Merging datasets



Additionally, the Reconciliation Engine has default reconciliation rules that simplify the creation of reconciliation jobs and a continuous or near real-time reconciliation mode to support dynamic changes in your environment. The Reconciliation Engine provides other functionality with the following activities:

� Comparing class instances in two or more datasets

� Copying instances from one dataset to another

� Deleting instances from one or more datasets

� Purging instances that are marked as deleted from one or more datasets

� Renaming datasets

For more information about reconciliation, see the BMC Atrium CMDB 7.6.04 Normalization and Reconciliation Guide.

The Atrium Explorer component of BMC Atrium CMDBAtrium Explorer is the BMC Atrium CMDB data visualization tool that enables you to create and edit service models graphically in BMC Atrium CMDB. It also enables you to see and manage CIs and relationships. Atrium Explorer provides the central launch point for federated and related CI information.

All instances visible in the display pane are represented in a view. You can have several views open at once, though only one at a time is displayed.Atrium Explorer can be embedded and launched in context from any application.

In the Atrium Explorer, each CI is represented by an icon that indicates the class of that instance. You can quickly create a CI by dragging an icon into a view. When a CI is related to other CIs, arrows connect its icon to theirs to represent the relationships. When you right-click an icon, you can choose to either expand (show) or collapse (hide) related CIs.

For more information about using Atrium Explorer, see the BMC Atrium CMDB 7.6.04 User's Guide.

The Atrium Impact Simulator component of BMC Atrium CMDBIt is difficult to predict the potential impact of planned or unplanned changes to business services or other critical resources. This process frequently relies on manual research results to arrive at a best-guess impact assessment for determining the risk that a change might have on business services. With this manual method, testing the resiliency of service models or a single point of failure for service models is difficult.

The Atrium Impact Simulator application can make this easier, enabling you to determine the impact of a change to the availability of a CI on other CIs. The same impact data is also used by the BMC Service Impact Manager (SIM) product to perform real-time analysis of impact when events are received about real outages in your environment.



For example, you could run a simulation in Atrium Impact Simulator to learn what devices and applications in the network would be affected if you were to take a server offline. You might also use Atrium Impact Simulator to plan for disaster recovery. You can run simulations to determine where the network is weakest, and plan accordingly. For more information about using Atrium Impact Simulator, see the BMC Atrium CMDB 7.6.04 User's Guide.

The Common Data Model component of BMC Atrium CMDBYou have many different types of CIs, from computer systems to network hardware to software servers. Without a data model that accurately reflects these types and the types of relationships that can exist between them, your CMDB could store attributes that do not pertain to their CIs, leave out necessary attributes, and make it harder to search for groups of CIs.

The BMC Atrium CMDB data model is object oriented, which means that it has a hierarchical set of classes in which each class inherits attributes from its superclass—the class above it in the hierarchy—and then adds its own attributes to create a more specific type of object, a subclass. The benefits of an object-oriented data model include enforcement of common attributes among similar types of CIs and the ability to search within not just a given class of CIs, but within any branch of the hierarchy. From a base class from which all others are derived, you can search for all CIs or all relationships.

The BMC Atrium CMDB data model is also extensible. Your infrastructure, and the technology that comprises it, is constantly changing. That means the types of CIs and relationships in your CMDB must also change, so you need a data model that is extensible. You can add attributes to your classes, and even add classes. Subclasses can have their own subclasses, extending the hierarchy to the level of detail that you want to track.

The Common Data Model (CDM) is the set of CI and relationship classes that ships with BMC Atrium CMDB. These classes are complete enough to model nearly everything in your IT environments. All classes in the CDM reside in the BMC.CORE namespace.

For consistency with industry standards developed to track and manage this type of information, the CDM is based on the Common Information Model (CIM) from the Distributed Management Task Force (DMTF) and Microsoft Windows Management Instrumentation (WMI). The CDM adopted much of the basic design of the CIM and WMI without detailing the internal workings of systems. For a graphic of the CDM, see the BMC Atrium CMDB 7.6.04 Common Data Model Diagram.

Best practices for modeling your environment in the CDM are available in the BMC Atrium CMDB 7.6.04 Data Modeling Guide and BMC Atrium CMDB 7.6.04 Data Model Help.



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

The BMC Atrium Product Catalog and Definitive Media Library components of BMC Atrium CMDBThe BMC Atrium Product Catalog provides a normalized reference of software, hardware, and other types of products and their characteristics that enhance the accuracy of BMC Discovery products by uniquely identifying a product regardless of its installed name or location.

Any application (BMC or non-BMC) can use the Product Catalog to identify a single name for a software application and its versions, which in turn supports license compliance and provisioning. The Product Catalog is used to normalize discovered data, both the name and categorization of software products.

You can also use the Product Catalog to manage the products in your environment, specifying a product version as approved, unapproved, or blacklisted. The Definitive Media Library (DML) is the set of software in the Product Catalog that are approved for your organization to use.

The Product Catalog defines the files and suites associated with each software product, and it enables you to specify the location of the master copies that are used to install the products. For more information, see the BMC Atrium Core 7.6.04 Product Catalog and DML Guide and BMC Atrium Core 7.6.04 Web Services Help.

The Service Catalog component of BMC Atrium CMDBThe Service Catalog provides centralized management of business services across BMC products. It enables you to define in BMC Atrium CMDB a common list of services that IT provides to the business. You can use Atrium Explorer to dynamically update the infrastructure CIs related to these services by using queries and templates.

Relating services to infrastructure CIs in your CMDB enables an IT organization to:

� Establish and set clear expectations for service delivery.

� Rationalize data across IT processes based on a business context.

� Provide a service-oriented approach to enable management reporting.

With the Service Catalog, you can access a list of all the business services and their supporting technical services. For more information about the Service Catalog, see the BMC Atrium CMDB 7.6.04 Administrator's Guide.



The Atrium Integrator component of BMC Atrium CoreThe Atrium Integrator product enables you to transfer data from an external datastore to BMC Atrium CMDB. The Atrium Integrator is ideal for complex transfers that require data transformation, for transfers of large amounts of data, and in instances with multiple integration points. It is also the method of choice for transferring existing data, either discovered by a third-party discovery application or residing in flat files (CSV or XML), because the field mapping feature enables you to map existing data to the BMC Atrium CMDB data model.

The Atrium Integrator supports event-based, scheduled, or manually run information flow. The graphical interface displays both external data sources and BMC Atrium CMDB classes. For more information about Atrium Integrator, see the Atrium Integrator 7.6.04 User's Guide.

NOTE In previous releases, BMC Atrium Core included the BMC Atrium Integration Engine product as the preferred tool for data transfers. Though BMC Atrium Integration Engine is still included with BMC Atrium Core 7.6.04 and any integrations you have built with it continue to work, it has been deprecated.

BMC Software recommends that you use Atrium Integrator for transferring data in any new integrations you develop. There is not currently a means of migrating BMC Atrium Integration Engine definitions to Atrium Integrator, so if you are already using BMC Atrium Integration Engine for any integrations you should continue to use it until BMC provides a migration path to Atrium Integrator.



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

BMC Atrium Core architecture

Figure 1-2: BMC Atrium Core architecture

At the center of BMC Atrium Core is BMC Atrium CMDB. BMC Atrium CMDB uses a federated data model, featuring a centralized database linked to other data stores, to share configuration data without the high setup and maintenance costs associated with a pure centralized approach.

The Normalization Engine makes sure that data from different data providers is consistent in BMC Atrium CMDB. After data is normalized before or after it is created in a dataset, it can be reconciled and saved to the BMC Atrium CMDB production dataset.

NOTE It is a best practice to normalize data prior to reconciliation.

BMC Atrium Core

BMC Atrium CMDB

Atrium IntegratorR

eco

nci

liatio

n

En

gin

e

BMC AtriumProduct Catalog

Data providers

Federated data

ConsumersProduction dataset

Import datasets

Normalization Engine


BMC Atrium Core architecture and features

The Reconciliation Engine merges data from multiple import datasets into the BMC Asset dataset. This consolidated view of your data is the production dataset that data consumers should use and on which you should base business decisions. BMC Remedy Asset Management displays data from the BMC Asset dataset by default. If you manually edit data using BMC Remedy Asset Management, you should save those changes to the BMC.ASSET.SANDBOX dataset rather than writing them directly to the BMC Asset dataset, thereby enabling the changes to be reconciled with those from all active import datasets.

Open access to dataEven the most accurate data is useless if you cannot access it. A wide variety of users and applications must be able to both read and write to the CMDB. Providers create and modify data in bulk, whereas consumers view the data and can also make modifications. Figure 1-3 shows some providers and consumers of BMC Atrium CMDB data.

Figure 1-3: Data providers and consumers



Open access to data includes these features:

� Programmatic access—BMC Atrium CMDB provides C, Oracle Java, and web services application programming interfaces (APIs) to view and modify its data. This includes both instance data and the data model. For more information, see the BMC Atrium Core 7.6.04 Developer’s Reference Guide.

� Bulk data load—BMC Atrium CMDB provides ways to import multiple instances at once, so that discovery applications and others can rapidly populate the database: the BMC Atrium CMDB APIs and Atrium Integrator. The latter maps and transfers data from multiple database and file formats into BMC Atrium CMDB. For more information, see the Atrium Integrator 7.6.04 User's Guide.

� Database and platform independence—BMC Atrium CMDB is compatible with multiple operating systems and database vendors to provide flexibility in your environment.

Data partitioningPartitioning is dividing your configuration data into subsets, each representing a logical group of CIs and relationships. In BMC Atrium Core, these partitions are called datasets. The same real-world object or relationship can be represented by instances in more than one dataset. For example, different discovery applications can create CI and relationship instances in different datasets. You can later merge those instances into a single production dataset.

This is important for the goal of verifying and correcting configuration records against the infrastructure. You can create one dataset representing your intended configuration, then use a discovery application to create another dataset representing your actual configuration, and verify the former against the latter.

FederationBMC Atrium CMDB uses a federated data model, which means that you can keep some data in managed data repositories in lieu of populating BMC Atrium CMDB with all your data. The most common types of federated data are related information and detailed attributes. Related information is information about a CI that does not itself qualify as a CI and therefore should not be stored in a CMDB. Detailed attributes are attributes of CIs stored in BMC Atrium CMDB, but they are attributes that are not important enough to track at the level of a CMDB.

NOTE For information about what qualifies as a CI, see “Configuration items” on page 70.

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


BMC Atrium Core architecture and features

For detailed attributes, the CMDB record for an employee might have a Skills attribute that contains a list of the employee’s skills and a Department attribute that contains the employee’s department name. It might also link to an HR database where additional attributes, like Salary, that are not really important from a configuration perspective are stored.

Federated data might be stored in a discovery database, a Capacity Management system, an Availability Management system, or other external data stores. You can retrieve federated data and view it with Atrium Explorer, as if it were stored in BMC Atrium CMDB. The BMC federated data model enables you to connect to JDBC™ compliant databases, CMDBf-compliant CMDBs, and BMC Remedy AR System forms.

Web services and service oriented architectureBMC Atrium CMDB web services APIs are modified based on the service oriented architecture (SOA). SOA facilitates the loose coupling of product integrations, minimizing the cost and difficulty of upgrading components.

Operations are grouped by related services. This grouping of operations enables services to be versioned and extended independent of each other, which makes it easier to add new services and operations.

With web services, integrations are more robust because services can be located anywhere and can be started or stopped without breaking the integration. For more information about web services and service oriented architecture, see BMC Atrium Core 7.6.04 Web Services Help.

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

Overview of virtualization managementA benefit of virtualization is a dynamic IT environment in which changes can happen rapidly and frequently. However, this can also cause service models to be out of sync just as quickly.

These BMC Atrium Core features avert issues that arise in a virtual environment:

� Continuous, real-time normalization and reconciliation to rapidly update data in BMC Atrium CMDB

� Dynamic service model updates based on queries and templates

� Data models that represent virtual machine (VM) resource pools and settings

� Rapid data loads



Architecture of the CMSITIL V3 introduced the Configuration Management System (CMS), which stores all configuration records and can contain multiple CMDBs. The BMC implementation divides the CMS and its infrastructure into the following layers:

� The CMDB

� The CMS Data—Related data and additional detail linked to or from the CMDB

� The CMS Environment—Applications that interact with the other two layers

Figure 1-4 illustrates these layers.

Figure 1-4: CMS infrastructure

SLA Management

Software Config.Management

Service ImpactManagement

Help Desk

ChangeManagement

AssetManagement

IncidentManagement

ChangeRequests

Help DeskTickets

Federated CIData

Service LevelAgreements

Contracts

Other DataRelated to CIs

DefinitiveMedia Library

Applications

Information related to CIs

Links betweenrecords

Managed by

ApplicationManagement

IdentityManagement

Provisioning

CapacityManagement

DiscoveryApplication 1

DiscoveryApplication 2

ProblemManagement

Requests

Requestsfor

ConfigurationData

Configurationitems and theirrelationships

CMS Environment

AdditionalCI detail

CMS Data

CMDB


Architecture of the CMS

The CMDB layerA CMDB holds only instances that represent physical, logical, or conceptual things (called CIs) throughout your organization that you have a business need to track and the relationships between these items that are also important enough to track. CIs and the relationships between them are called configuration data.

Some of the attributes of these CIs can be links to the CMS Data layer. Not all available CI attributes must be stored in the CMDB: in fact, you should store only the key attributes here and link to the less-important attributes in other CMS data stores.

Even though a CMDB does not hold all attribute data or related data, it still serves as the single source of reference for configuration data because it links to the CMS Data layer. For example, you might have an instance in a CMDB representing a printer, and a federated link to incident requests about the printer in another CMS data store.

You can make all requests to a CMDB, and when the data that you need is not stored there, you find reference links to where that data is stored and information about how that data can be accessed. The data accessed through these links is called federated data.

The CMS Data layerThe CMS Data layer can include several data stores. It includes related data and any CI attributes that you judge as not appropriate to track in the CMDB.

For example, suppose that your discovery application discovers 100 attributes of each computer system on your network, but only 20 of them are critical to your business. You would import the 20 attributes from your discovery database into the CMDB and leave the other 80 in the discovery database, which is part of your CMS.

The two types of data in the CMS Data layer are linked to the CI data in the CMDB in different ways. The “extra” CI attributes are linked from their instances in the CMDB with federation, enabling requests made to the CMDB to reach these attributes. Federated data can include information in another database, BMC Remedy AR System forms, or even another CMDBf-compliant CMDB. For example, you might use multiple CMDBs in a global company to comply with government regulations, with a different CMDB in each country or geographical region. One CMDB serves as your single source of reference about CIs and relationships in your environment, while data in the other CMDBs is federated.

For CMS data that is simply related to CIs, the link can be in either or both directions. For example, a change request record could link to instances of the CIs it will change, and each CI instance could link via federation to the change requests that affect it.



Separating this layer from the CMDB has several benefits:

� The CMDB can focus its functionality on CIs and their relationships. This functionality includes partitions for data from multiple sources, reconciliation of that separate data, and federated data.

� The overhead required to provide CMDB functionality is not wasted on data that does not need it. For example, multiple snapshots of every change request record are unnecessary, so making your change request records part of the CMDB would be confusing and waste valuable storage space.

� You do not have to modify the CMDB to hold related data. With the boundary drawn at CIs and their relationships, the question of whether to store some new type of data in the CMDB is already answered. You store it instead as part of the CMS Data layer, and save the trouble of changing the data model in the CMDB to accommodate the new type of data. You also avoid pitfalls inherent in trimming the data model if you later decided to move data out of the CMDB.

� Transactional data can be stored in databases specifically designed to handle a high volume of real-time requests.

� Data is provided more efficiently. Instead of getting all their data from the CMDB, data consumers can get it from individual data stores that are optimized to provide the specific type of data being requested.

� You do not need to undertake several data migrations and application integrations to move your change requests, incident tickets, and other CI-related data into the CMDB. Applications that use this data can continue to access it where you currently store it.

� The CMDB does not become a bottleneck. With requests for related data on its own being handled by other databases, the CMDB does not have to accommodate all such traffic in addition to CI-related requests. You can spread the load across multiple systems.

Though your CMS Data layer can be a single data store, you do not have to store the data this way. The different types of data in the CMS Data layer are not necessarily linked to or related to each other. The only thing they must have in common is a link to or from the CMDB.

CMS EnvironmentWhere the CMS Data layer contains data, the CMS Environment is devoted to the applications that provide and consume that data. These applications can access the CMDB, the CMS Data, or both. For example, an Asset Management application that views and modifies CI instances in the CMDB is part of the CMDB Environment as a consumer, and a discovery application that creates CI instances in the CMDB is part of the CMDB Environment as a provider.

These applications sometimes store their information in their own databases, but the two are still considered to be part of different layers of the CMS infrastructure. An application is part of the CMS Environment, whereas its configuration-related data is part of the CMS Data. Of course, applications in the CMS Environment can also access data unrelated to CIs. This data is not part of the CMS Data.


BMC Remedy AR System foundation

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

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

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

AR System server

CMDB APIs

AR System APIs

Web clients

BMC Remedy Mid Tier

Other APIprograms

BMC Remedy UserWindows clients

Database

AR System data,including CMDB data

CMDB forms(Console and classes) and

workflow

Other formsand workflow CMDB engine



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

Benefits of using BMC Remedy AR SystemRunning on the BMC Remedy AR System gives BMC Atrium CMDB several benefits, including:

� A proven, stable platform

� Compatibility with a large number of databases and operating systems

� A flexible permissions model with users and groups

� Ability to add customized workflow without having to code

� Easy replication with the Distributed Server Option

� Scalability, using server groups to distribute load

� Easy integration with CMS data stores, such as incident tickets and contracts

� Built-in auditing and archiving mechanisms

� No programming required to configure

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

ITIL and SACMIT departments face numerous challenges in providing dependable services that support a company’s business goals. Solving most of them requires a good Configuration Management strategy: without knowing what is in your environment, you cannot hope to control it, maintain it, or improve it.

Due to a growing interest in adopting best practices across IT departments, particularly according to standards such as the Information Technology Infrastructure Library (ITIL), many organizations are now deciding to implement a CMS. They realize there is a business value in having a single source of reference for their organization’s decision support that provides a logical model of the IT infrastructure to identify, manage, and verify all configuration items (CIs) in the environment.

In ITIL version 3, the process that supports data management of CIs and IT assets for information and knowledge to enable service management decisions is referred to as Service Asset and Configuration Management (SACM). SACM encompasses the Asset Management and Configuration Management processes, managing service assets to support the other Service Management processes.


ITIL and SACM

Purpose of SACMAccording to the ITIL Service Transition manual, the purpose of SACM is to:

� Identify, control, record, report, audit, and verify service assets and configuration items, including versions, baselines, constituent components, their attributes, and relationships.

� Account for, manage, and protect the integrity of service assets and configuration items (and, where appropriate, those of its customers) through the service lifecycle by ensuring that only authorized components are used and only authorized changes are made.

� Protect the integrity of service assets and configuration items (and, where appropriate, those of its customers) through the service lifecycle.

� Ensure the integrity of the assets and configurations required to control the services and IT infrastructure by establishing and maintaining an accurate and complete Configuration Management System (CMS).

Goals of SACMAccording to the ITIL Service Transition manual, SACM pursues the following goals:

� Support the business and customer's control objectives and requirements.

� Support efficient and effective Service Management processes by providing accurate configuration information to enable people to make decisions at the right time (for example, to authorize change and releases, resolve incidents and problems faster).

� Minimize the number of quality and compliance issues caused by improper configuration of services and assets.

� Optimize the service assets, IT configurations, capabilities and resources.

Benefits of SACMAchieving the goals of SACM can benefit your organization in significant, measurable ways related to control, integration, and decision support.

ControlVerifying and correcting configuration records gives you a greater degree of control over your infrastructure. For example, by controlling the versions of configuration items, you reduce the complexity of your environment, and in turn your support costs. Items that disappear or that appear without being paid for are noticed, helping you control assets and avoid legal issues. Exercising greater control over your environment also means that you can increase overall security.



IntegrationWhen processes such as Incident Management, Problem Management, Change Management, and Release and Deployment Management are based on a current record of your configuration, they can be integrated, as shown in Figure 1-6 on page 36. This reduces administrative costs and errors. For example, you might integrate Incident Management and Change Management processes in the following ways:

� When resolving an incident requires a change, the Incident Management application can automatically create that change request.

� An Incident or Problem Management application can use a service model to identify previous changes that might have caused a failure.

Integrating all configuration-related IT processes can reduce the number of staff needed to administer your environment, saving you money.

Figure 1-6: Some of the ITIL processes integrated by the CMS

Decision supportYour IT managers benefit from having accurate configuration information mapped to your Service Management processes. Making decisions is easier when you have complete and accurate data, resulting in better resource and performance estimates. You can commit to service levels more confidently, and your risk management improves, reducing unplanned downtime.

Service LevelManagement

ChangeManagement

Capacityand DemandManagement

Release andDeployment

Management

Service Assetand

ConfigurationManagement

CMS


ITIL and SACM

Data is the key to SACMWhatever SACM processes you implement, their effectiveness depends on the data that they use.

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

Configuration data must also be available to all your IT processes, because even the most accurate data is useless if you cannot access it. For example, if the network topology data provided by your discovery application is not accessible to your Change Management application, you cannot intelligently plan a network redesign.

The solution that enables you to maintain accurate configuration data that is shared by multiple IT processes is a CMDB, preferably one that is frequently updated by an automated discovery tool.

Control of the Configuration Management processAccording to ITIL, you should continually assess the efficiency and effectiveness of your Configuration Management process by using Continual Service Improvement, including regular management reports. You should also schedule a review of the expected growth of Configuration Management activities on a regular basis.

ITIL recommends generating the following reports, and making their results available for interrogation and trend analysis by IT Service Management and other groups within IT services:

� Results of configuration audits

� Information about the number of registered CIs, including growth and capacity information

� Details about any delays caused by Configuration Management activities

� Details about hours worked by Configuration Management staff



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

Calbro Services company backgroundCalbro Services, a large, global company, is headquartered in New York City and publicly traded on the New York Stock Exchange. The company has 27,000 employees in 240 offices in 20 countries. The following table describes Calbro Services key business services.

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

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

Table 1-1: Key business services

Service Description

Online banking 500 ATMs in major cities

World wide web (WWW) presence

Corporate site and online brokerage services

Discount equity brokerage

Online and storefront services

Sales force automation

Automated sales activities such as leads, orders, reports, and so on

Customer support Support centers in the United States, Europe, and Asia

Mass Marketing World-wide marketing campaigns aimed at making Calbro Services a household name


Calbro Services user story

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

BSM at Calbro ServicesCalbro Services has established business services with defined service level agreements. Their business services are modeled, monitored, and managed.

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

Implementation of BMC Atrium Core at Calbro ServicesCalbro Services has chosen BMC Software solutions to manage their IT operations from a business perspective.

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

� Discovering IT assets and components

� Defining user access

� Determining which data should be federated

� Possibly extending the data model

� Transferring existing data

� Establishing guidelines for BMC Atrium CMDB updates

� Populating the Product Catalog

� Configuring normalization of the data

� Configuring reconciliation of the data

The concepts and planning required for performing these tasks are described in this manual.




Chapter

2
Planning a CMDB
This section provides best practices for planning with BMC Atrium Core products. This involves planning the BMC Atrium CMDB population and normalizing and reconciling data.


� CMDB planning stages (page 42)� Phased implementation of a CMDB (page 44)� Challenges, critical success factors, and risks (page 44)



CMDB planning stagesThis section provides an overview of the stages involved in structuring a CMDB project and successfully delivering a comprehensive, effective, and useful CMDB. These stages are set forth in the Step-by-Step Guide to Building a CMDB and are summarized here. You can request this book from http://www.bmc.com.

The stages are further divided into discrete steps, each with specific goals and objectives that help you meet the milestone for each stage. Some aspects of this process are described in more detail in this document and in other BMC Software documentation, as noted in this section.

Stage 1: Assembling the project team

The number of team members that you choose and how many roles each plays depends on the size and structure of your organization, but you should employ project management standards such as including stakeholders and representatives from the user community.

The high-level steps associated with this stage are:

� Step 1, Assemble project team

� Step 2, Obtain CMDB knowledge

� Step 3, Create and agree on CMDB goals and mission statement

� Step 4, Review and define benefits

� Step 5, Build a business case

Your Configuration Management team should collectively be knowledgeable in:

� ITIL Service Support processes and guidelines

� BMC Atrium CMDB administration, best practices, and integration methods

� The BMC Atrium CMDB Common Data Model

� BMC Remedy AR System development

� Project management

� Business management processes

Stage 2: Defining requirements and creating IT service model blueprint


� Step 6, Identify and review governance requirements

� Step 7, Review and select supporting best practices

� Step 8, Identify requirements to address potential problems

� Step 9, Identify inventory and asset requirements


http://www.bmc.com

CMDB planning stages

� Step 10, Define service catalog requirements

� Step 11, Define CMDB requirements to support other processes

� Step 12, Define CI level and IT service model

� Step 13, Define CI relationships

� Step 14, Define CI attributes

� Step 15, Design IT service model blueprint

The result of these steps is a blueprint that models your configuration data requirements.

Based on your configuration data requirements for BMC Remedy Asset Management and other consumers, use the Mapping Your Data to BMC Atrium CMDB 7.6.04 Classes document to identify the CI classes and attributes that you need to populate and store in BMC Atrium CMDB.

For information about the complete structure and class details of the CDM, see the BMC Atrium CMDB 7.6.04 Common Data Model Diagram and the BMC Atrium CMDB 7.6.04 Data Model Help.

Stage 3: Selecting CMDB solution and tools


� Step 16, Select CMDB solution

� Step 17, Plan the CMDB population

For details about this step, see “Planning to populate BMC Atrium CMDB” on page 74.

� Step 18, Select tools to automate CMDB population

� Step 19, Calculate project Return on Investment (ROI)

Stage 4: Constructing and maintaining your CMDB


� Step 20, Construct your CMDB

� Step 21, Create CI lifecycle management processes

� Step 22, Build supporting processes

� Step 23, Populate your CMDB

For details about this step, see “Importing data to BMC Atrium CMDB” on page 138.

� Step 24, Train the CMDB team and users



Stage 5: Driving ongoing value


� Step 25, Implement measures and metrics

� Step 26, Create a continual service improvement program

Phased implementation of a CMDBImplementing a CMDB to manage your entire configuration at once is a daunting task, so a phased approach to implementation is usually better. Consider the following alternatives for breaking up the implementation:

� By critical business services or critical business applications

� By company department

� By geographic region

� By support group

� By importance of CI

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

Your later phases will be less costly if you apply lessons learned in early phases.

Challenges, critical success factors, and risksThe ITIL Service Transition manual identifies the following challenges, critical success factors, and risks with SACM.

ChallengesChallenges to SACM include:

� Persuading technical support staff to adopt a checking in/out policy, which can be perceived as a hindrance to a fast and responsive support service. If the positives of such a system are not conveyed adequately then staff might be inclined to try to circumvent it.

� Attracting and justifying funding for SACM, since it is typically out of sight to the customer units empowered with funding control. In practice it is typically funded as an “invisible” element of Change Management and other ITSM processes with more business visibility.

� An attitude of “just collecting data because it is possible to do.” This leads SACM into a data overload which is impossible, or at least disproportionately expensive, to maintain.


Challenges, critical success factors, and risks

� Lack of commitment and support from management who do not understand the key role it must play supporting other processes.

Critical success factorsCritical success factors for SACM include:

� Focusing on establishing valid justification for collecting and maintaining data at the agreed level of detail.

� Demonstrating a top-down approach that is focused on identifying service CIs and subsequently the CIs that support those services, thereby allowing a rapid and clear demonstration of potential points of failure for any given service.

� Setting a justified level of accuracy, that is, the correlation between the logical model within SACM and the “real world.”

� Making use of enabling technology to automate the CMS practices and enforce SACM policies.

RisksRisks to successful SACM include:

� The temptation to consider it technically focused, rather than service and bsiness focused, since technical competence is essential to its successful delivery.

� Degradation of the accuracy of configuration information over time that can cause errors and be difficult and costly to correct.

� The CMS becomes out of date due to the movement of hardware assets by non-authorized staff. Half-yearly physical audits should be conducted with discrepancies highlighted and investigated. Managers should be informed of inconsistencies in their areas.




Chapter

3
Planning the data model
This section explains the purpose and structure of the BMC Atrium CMDB data model. It defines the Common Data Model (CDM) and offers best practices for extending the model.


� Data model overview (page 48)� Synchronization of changes to classes (page 56)� Overview of the Common Data Model (page 56)� Planning to extend the data model (page 61)



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

Data model classes and attributesThe BMC Atrium CMDB data model is object oriented and extensible. It consists of classes, each representing a type of configuration item that can be stored in the CMDB. Each class equates to a database table or a BMC Remedy AR System form. For example, the data for the BMC_ComputerSystem class, which represents computer system CIs, is accessible in the BMC.CORE:BMC_ComputerSystem join form.

A class can be either a CI class, which defines a type of configuration item, or a relationship class, which defines a type of relationship between CIs.

A class has one or more attributes, each of which specifies a property of the class. For example, BMC_ComputerSystem has attributes such as HostName and Domain. Each attribute equates to a column on a database table or a field on an BMC Remedy AR System form.

Data model extensibilityA key aspect of BMC Atrium CMDB is a data model that is extensible. Infrastructure, and the data that different companies want to track about that infrastructure, is constantly changing. The data model is designed so that it can easily be extended using the Class Manager or the BMC Atrium CMDB APIs. Some BMC applications extend the data model to store data specific to their functionality. To be extensible means that there is no usage distinction between the system-defined and the user-defined data model.

Attribute inheritanceBecause the data model is object oriented, a class can have subclasses that inherit its attributes and the ability to participate in the same relationships. Subclasses are used to further classify a type of CI and give specific attributes to the more granular types.

For example, BMC_ComputerSystem has subclasses to represent mainframes, printers, and storage subsystems. These subclasses inherit HostName and Domain, and all the other attributes of BMC_ComputerSystem. Inheritance of attributes continues to the end of the tree, so the subclasses also inherit from BMC_System, the class above BMC_ComputerSystem, and from BMC_BaseElement, the base class above BMC_System. Figure 3-1 on page 49 shows some of the attributes inherited along this part of the tree.


Data model overview

Figure 3-1: Attribute inheritance

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

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

BMC_BaseElement

AccountIDManufacturerName

BMC_System

AccountIDManufacturerNameisVirtual

BMC_ComputerSystem

AccountIDManufacturerNameisVirtualHostNameDomain

BMC_Printer

AccountIDManufacturerNameisVirtualHostNameDomainAveragePagesPerMinutePaperSizesSupported



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

Relationship cardinalityEvery relationship class has a cardinality that defines how many instances of the source class can be related to each instance of the destination class and vice versa. BMC Atrium CMDB enforces this cardinality.

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

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

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

� Many to many—Each instance of the source class can have this relationship with multiple instances of the destination class, and vice versa.

Fulfilling a many cardinality means that multiple instances of the relationship exist.

Weak relationshipsIf a relationship is a weak relationship, its destination member, called the weak member, cannot exist without its source member, called the strong member. A weak relationship creates a logical composite object consisting of both member CIs. You can extend this composite object by adding more weak relationships either from the source to other destinations or from the destination, acting as a source this time, to destinations a level below.

You can choose to act on these composite objects during certain reconciliation activities. For example, BMC_HostedSystemComponents is a weak relationship commonly used to relate a computer system to its components. If you copy instances of BMC_ComputerSystem from one dataset to another, you can choose whether instances of BMC_Monitor and other components related to those computer systems are copied automatically to preserve the composite objects, even though BMC_Monitor was not specified as a class to be copied by the activity.

Table 3-1: Examples of source and destination relationship members

Class Source acts as Destination acts as

BMC_Dependency Antecedent Dependent. Depends on antecedent.

BMC_HostedSystemComponents Host Component. Hosted by host.


Data model overview

You can also propagate attributes from the strong side to the weak side of a weak relationship. This means that an attribute from the source CI is mapped to an attribute from the destination CI so that for every instance of the relationship, whenever the value changes in that attribute of the source, that value is also written to the corresponding attribute on the destination. This enables you to search for an instance of a destination member, such as a disk drive, and get information about the computer system in which it is installed without having to follow the relationship and read the computer system instance.

For instructions about propagating attributes for weak relationships, see the BMC Atrium CMDB 7.6.04 Administrator's Guide.

Cascading delete optionRelationship classes with a cardinality of one-to-one or one-to-many have an option called cascading delete. This causes a destination member of the relationship, and all destinations of relationships below it, to be deleted when the source member is deleted. Marking a CI as deleted is also cascaded down to destination CIs when this option is enabled.

This option is particularly useful with composite objects. For example, you could use it with the BMC_HostedSystemComponents relationship class so that when you delete a computer system, all its components, such as disk drives and memory, are also deleted.

NOTE Cascading delete does not work in reverse. When you unmark a CI that was previously marked as deleted, only the CI on which you set MarkAsDeleted to NULL or No (BMC recommends NULL) is restored. For example, if you unmark a computer system, it is restored, but its components, such as disk drives and memory, remain deleted. To restore the components as well, you must unmark each of them.

Use cascading delete carefully, because it can have far-reaching effects. Deletions are cascaded all the way down to destination CIs at the end of a relationship chain, and this happens for every instance of a relationship class that has cascading delete enabled.



BMC Atrium CMDB data storage methodsBMC Atrium CMDB stores instance data by a method defined by the type of class containing each instance. BMC Atrium CMDB provides the following types of classes:

� Regular

� Categorization

� Abstract

� Abstract with data replication

Regular classesA regular class stores the data for its attributes in its own BMC Remedy AR System form. If it is a subclass, that form is a join form that joins the attributes of the superclass with the attributes unique to the subclass.

Figure 3-2 shows the forms for a new regular class, with the lines representing a join between the superclass and the form containing the uninherited attributes of the new class.

Figure 3-2: Regular class

By searching in the superclass form, you can find instances of both the superclass and the subclass. This is a useful way to search when you do not know which class an instance is stored in. However, you must then go to the subclass form to see all attributes of the instance.

An example of a regular class in the CDM is BMC_ComputerSystem.

New Class (NC) form

Superclass (SupC) form

SupC_Attribute1 SupC_Attribute2 SupC_Attribute3 NC_Attribute1 NC_Attribute2

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

NC_Instance2 [value] [value] [value] [value] [value]

New Class (NC) join form

NC_Attribute1 NC_Attribute2

NC_Instance1 [value] [value]

NC_Instance2 [value] [value]

SupC_Attribute1 SupC_Attribute2 SupC_Attribute3

SupC_Instance1 [value] [value] [value]

NC_Instance1 [value] [value] [value]

NC_Instance2 [value] [value] [value]


Data model overview

Categorization classesA categorization class does not have its own BMC Remedy AR System regular form. Its uninherited attributes are added to the form of its superclass. Instances of the superclass leave these subclass attribute fields blank, whereas instances of the subclass use them. Because of this, no attributes of a categorization class can be required attributes.

A categorization class does have its own join form, though this is only for the purpose of providing a form (and SQL view) that uses the actual class name. The join form is a join of the superclass form and a stub form with no records, and is not part of the inheritance tree. Any subclasses of the categorization class are joined to the superclass form, not the join form.

Figure 3-3 shows the forms for a new categorization class. The superclass form has one column containing an attribute from the categorization class. The instance of the superclass does not have a value in this column, whereas the instances of the new class do.

Figure 3-3: Categorization class

This data storage method avoids adding a database join to its subclasses. A join form is still created for the purpose of giving the categorization class a form (and therefore a database view) that uses its name, but that form is joined to a stub form and is not used by any subclasses.

Because the superclass holds the instance data for a categorization class, that superclass cannot be an abstract class.

As with a regular class, you can search in the superclass form of a categorization class and find instances of both the superclass and the subclass. But with a categorization class, you have access to all the attributes of that subclass.

An example of a categorization class in the CDM is BMC_Memory.

Stub form

SupC_Attribute1 SupC_Attribute2 SupC_Attribute3 NC_Attribute1

SupC_Instance1 [value] [value] [value]

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



SupC_Attribute1 SupC_Attribute2 SupC_Attribute3 NC_Attribute1



New Class (NC) join form



Abstract classesAn abstract class does not have its own BMC Remedy AR System form and cannot hold any instances. It exists only to organize subclasses, enabling you to add a layer of organization without a database join.

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

Figure 3-4 shows the forms for a new abstract class with two regular subclasses. The lines represent the joins between the superclass and the forms containing the new subclasses’ attributes.

Figure 3-4: Abstract class

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

Subclass 2(SubC2) form


SupC_Attribute1 SupC_Attribute2

SupC_Instance1 [value] [value]

SubC1_Instance1 [value] [value]


SupC_Attribute1 SupC_Attribute2 NC_Attribute1 NC_Attribute2 SubC1_Attribute1

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

Subclass 1 (SubC1) join form




NC_Attribute1 NC_Attribute2 SubC2_Attribute1

SubC2_Instance1 [value] [value] [value]



New Class (NC)




Data model overview

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

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

Figure 3-5: Abstract class with data replication

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







SupC_Attribute1 SupC_Attribute2

SupC_Instance1 [value] [value]




SupC_Attribute1 SupC_Attribute2 NC_Attribute1 NC_Attribute2

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

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

New Class (NC)


New Class (NC) replication form









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

While synchronization is in progress, an icon appears on the class in the Class Manager window to indicate that the class is in Change Pending state.

For information about synchronization error messages and instructions for canceling a failed pending change, see the BMC Atrium Core 7.6.04 Troubleshooting Guide.

Overview of the Common Data ModelThe Common Data Model (CDM) is the set of CI and relationship classes that ship with BMC Atrium CMDB. These classes are intended to represent the physical, logical, and conceptual items that all IT environments would want to track in a CMDB. Most of the classes in the CDM reside in the BMC.CORE namespace. The two federation classes reside in the BMC.FED namespace.

For consistency with the industry standards that have been developed to track and manage this type of information, the CDM is based on the Common Information Model (CIM) from the Distributed Management Task Force (DMTF) and Microsoft Windows Management Instrumentation (WMI). The CDM adopted much of the basic design of the CIM and WMI without going into the same depth on the internal workings of systems.

Classes and attributes needed only by a specific BMC product were removed from the CDM in version 2.0, better reflecting the fact that not all installations of BMC Atrium CMDB use them. These extensions, which are now installed by the product that consumes data from them, reside in separate namespaces. For specific information about what happens to CDM 1.1 classes when you upgrade to the current version, see the BMC Atrium Core 7.6.04 Installation Guide.

For information about the complete structure and class details of the CDM, see the BMC Atrium CMDB 7.6.04 Common Data Model Diagram and the BMC Atrium CMDB 7.6.04 Data Model Help, both available in the Docs directory of the product DVD.

To find out which class you should use to store a particular item from your environment, see Mapping Your Data to BMC Atrium CMDB 7.6.04 Classes. This document maps common items to classes both in the CDM and in BMC Software extensions.


Overview of the Common Data Model

Configuration item classesTable 3-2 describes the BMC_BaseElement configuration item class and its subclasses in the CDM.

Table 3-2: CI classes in the Common Data Model

Class Description

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

BMC_AccessPoint The BMC_AccessPoint class represents the ability to use or invoke a service. Its subclasses include different types of endpoints, such as IP endpoints and LAN endpoints.

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

BMC_Document The BMC_Document class stores information about documentation in your environment, such as design and regulation-compliance requirements.

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

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

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

BMC_Settings The BMC_Settings class is an abstract class under which you can create subclasses to provide detailed settings information about a managed element.

BMC_System The BMC_System class is the superclass for systems such as computer systems, mainframes, application systems, clusters, printers, virtual systems, and network devices. These systems aggregate a set of managed components.

BMC_SystemComponent The BMC_SystemComponent class stores information about the components that compose a system. This includes physical components like disk drives, monitors, and so on; applications like MS Word; and other soft elements like network drivers and file shares.

BMC_SystemService The BMC_SystemService class contains the information necessary to represent and manage the functionality provided by a device or software feature.



Relationship classesTable 3-3 describes the BMC_BaseRelationship relationship class and its subclasses in the CDM. Most relationship classes have subclasses that help further define a relationship. These subclasses, which are all categorization classes, can have additional attributes, but most often they further define a relationship only by using different CI classes as their members.

Table 3-3: Relationship classes in the Common Data Model

Class Description

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

BMC_Component BMC_Component is used to define composite objects such as a computer system, which is made up of a computer system instance, a disk drive instance, monitors, software, network cards, and so on.

BMC_Dependency BMC_Dependency describes configuration items that are dependent on each other. This relationship can be used to define application dependencies, such as a particular program that is dependent on an application server and database for it to run.

BMC_ElementLocation BMC_ElementLocation relates any configuration item to a physical location in your environment.

BMC_MemberOfCollection BMC_MemberOfCollection is used to define groupings of instances in a logical manner. This is used to define network topology, or to define the set of configuration items that make up a business process or service.

BMC_Impact BMC_Impact represents impact relationships between any CIs.

Note: BMC_Impact is deprecated. To indicate an impact relationship, instantiate any other relationship class and set the HasImpact attribute to “Yes.” This strategy reflects the fact that members of any type of relationship can impact each other.

BMC_Genealogy BMC_Genealogy establishes relationships between a parent virtual machine (VM) and its child VMs. For example, If you have a VM named win2k-vm1 and a clone of that VM named win2k-vm2, the win2k-vm1 VM is the parent and the win2k-vm2 VM is the child.


Overview of the Common Data Model

Federated data classesThis section describes the federated data classes in the CDM.

Detailed relationship categorizationWhen creating relationship instances, populate the Name attribute according to the Relationship Normalization table in Mapping Your Data to BMC Atrium CMDB 7.6.04 Classes and use the source and destination CI classes specified in the table.

The number of relationship classes in the CDM is far fewer than the logical types of relationships that you might want to use, so you can achieve a more granular level of categorization by populating the Name attribute. For example, to specify that a BMC_Component instance represents a product-to-patch relationship, enter PRODUCTPATCH for the Name attribute.

By using only Name values that appear in the Relationship Normalization table, you maintain consistency with relationships created by BMC Software products, increasing the accuracy of reconciliation. Future releases of BMC Atrium CMDB will require compliance with the values in this table for compatibility with BMC Software products.

TIP In version 7.6.04, the Normalization Engine now has the ability to set relationship Name values according to the Relationship Normalization table. For more information about this, see the BMC Atrium CMDB 7.6.04 Normalization and Reconciliation Guide.

Table 3-4: Federated data classes in the Common Data Model

Class Description

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

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



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

Sample model for a computer systemThis section illustrates a typical computer system data model. It has an operating system, a BIOS, a word-processing application, a video card, and uses a network printer.

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

Sample model for a computer system in a LANThis section illustrates a data model in which a computer system participates in a LAN. The computer system is in an IP subnet that is part of the LAN.

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


Planning to extend the data model

Planning to extend the data modelThe CDM includes classes that describe a wide variety of IT configuration items and their relationships, and some BMC Software products install extensions that add more classes and attributes to the data model. But some IT infrastructures still do not completely map to this model. This section gives best practices for how to extend the data model in such cases so that you can manage your entire IT infrastructure with BMC Atrium CMDB.

Your first step in deciding whether to extend your data model should be understanding the CDM and the extensions supplied by BMC products. Study the BMC Atrium CMDB 7.6.04 Common Data Model Diagram and BMC Atrium CMDB 7.6.04 Data Model Help in the Docs directory of the product DVD, and the documentation for BMC products that you own that integrate with BMC Atrium CMDB. By reading about the classes that you have, you might find existing classes that serve your needs or at least find the best classes to extend.

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

1. Use federation to extend the data model.

2. Use the Category, Type, and Item attributes to extend the data model.

3. Install an extension from BMC Software to extend the data model.

4. Add attributes to extend the data model.

5. Add subclasses to extend the data model.

If you decide to add attributes or subclasses:

� Perform the work using the Class Manager, an API program, or the cmdbdriver program. Never make those changes directly on class forms using BMC Remedy Developer Studio. Modifying the BMC Atrium CMDB data model requires more than just editing a form, and you might break some functionality.

You can use BMC Remedy Developer Studio to modify field layout and labels.

� Because a CMDB gets its value by sharing data among applications, make your extensions as widely useful as possible, so that they can meet multiple needs. Avoid extensions that narrowly cater to one application, even for high-volume uses.

� Do not create classes more than five database join levels deep. For information about the classes that use joins, see “BMC Atrium CMDB data storage methods” on page 52.

How federation extends the data modelJust 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 taxes your CMDB. Also, creating too many subclasses can leave you with classes so narrowly defined that they hold very few instances. Balance the need for categorization with the need to store similar CIs together.

How the Category, Type, and Item attributes extend the data modelTo further categorize a CI class that has the specific attributes that you need, consider using the existing Category, Type, and Item attributes instead of creating attributes or subclasses. These attributes are part of the BMC_BaseElement class and are thus inherited by all other CI classes. You can use them to provide levels of categorization for instances of a class without the performance cost of a subclass.

For example, the class BMC_PointingDevice does not distinguish between a wired mouse and a wireless mouse. To make this distinction in your data, you do not need to create subclasses called YourModel_WiredPointingDevice and YourModel_WirelessPointingDevice. Just populate the Item attribute with Wired or Wireless when creating instances of BMC_PointingDevice.

NOTE Because this categorization strategy uses a single class, the different categories, types, and items cannot have relationships to different classes. To have different relationships for each Category, Type, and Item, create subclasses for them instead of using this strategy.

How additional attributes extend the data modelIf an existing class describes your CI well but lacks a few pieces of information, add attributes to the existing class to store that information and avoid the performance cost of a subclass. To store some CIs that use these attributes and some that do not, make the entry mode of the attributes Optional.

Adding attributes works well when you have only one variation on a class to accommodate. If you have two or more variations, each with their own set of attributes, consider creating subclasses for them instead.

If you decide to add attributes, follow the Field ID rule in “Naming and numbering rules for new classes and attributes” on page 66.

NOTE When you add attributes to your data model, the new attributes are not automatically picked up by BMC Software products that use BMC Atrium CMDB, such as BMC Impact Solutions or BMC Remedy Asset Management. To use the new attributes with one of these applications, you must customize the application. For more information, see “Making data model changes visible to applications” on page 66.



How additional subclasses extend the data modelBefore you add classes for CIs and relationships, consider the alternatives, such as using federation, using the Category, Type, and Item attributes, installing an extension, and adding attributes. When one of these alternatives can address your problem, it is almost always better than adding subclasses to the CDM.

But there are situations in which none of those alternatives meets your needs, such as when you need to:

� Refine your classification.

� Add new attributes that are not general enough for existing classes.

� Further restrict the types of CI classes that can participate in a given relationship or vice versa.

For example, BMC_HostedSystemComponent is a relationship class that relates a system to a system component, but if you needed more specific relationship types, you could create subclasses. You could create one subclass of BMC_HostedSystemComponent that relates a computer system to a disk drive and another that relates a computer system to a memory card.

You can create subclasses of both CI classes and relationship classes. When creating new classes, consider using categorization and abstract classes instead of regular classes because regular classes require more system resources, and an abundance of regular classes in your data model can slow system performance.

If you decide to create subclasses, follow the class naming rule in “Naming and numbering rules for new classes and attributes” on page 66.

NOTE When you add classes to your data model, the new classes are not automatically picked up by BMC Software products that use BMC Atrium CMDB, such as BMC Impact Solutions or BMC Remedy Asset Management. To use the new classes with one of these applications, you must customize the application. For more information, see “Making data model changes visible to applications” on page 66.

Regular class extentions to the data modelCreating a regular class is the most straightforward way to create a subclass, but it has the potential to affect database performance if you create too many levels of joins. The best practice is to go no deeper than five join levels.

Use regular classes for CIs or relationships that have more than five uninherited attributes or that have any uninherited attributes that must be populated in every instance. Use a regular class for any class that you expect to contain at least as many instances as its superclass. If you expect the class to contain at least 1,000 instances, regardless of how many its superclass will contain, you might want to make it a regular class because that enables you to create indexes on it to improve search performance.



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

Abstract class extentions to the data modelUse abstract subclasses when you need a logical class at a particular organizational level, but only to provide some common attributes that subclasses can inherit or to provide a common relationship type for those subclasses. To work with any instances of the class, use an abstract class with data replication.

The classes BMC_System and BMC_SystemComponent are examples of abstract classes created to provide a common relationship type for their subclasses. You can create a BMC_HostedSystemComponent relationship between instances of any subclass of BMC_System and any subclass of BMC_SystemComponent, because these two abstract CI classes were defined as the endpoints of that relationship class.

Abstract class with data replication extentions to the data modelAn abstract class with data replication avoids a database join, thus improving performance when searching its subclasses and retrieving their instances. However, it results in slower performance when creating and modifying subclass instances, so unless you really need to search the abstract class, you should create it without data replication.

Use abstract subclasses with data replication when you want the benefits of an abstract class but also need the ability to search all its subclasses in one place.

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

The Singleton optionUse a singleton class when you have a unique CI or relationship that you want to store in BMC Atrium CMDB. For example, you might use a singleton class for your company’s CEO so that you can model the impact of particular IT resources on the CEO.



How Calbro Services extended the data modelCalbro Services wants to track the model year of several of the devices on the network, such as servers, workstations, routers, and so on. Because the model year is a critical piece of information, the administrator wants to include it in the data model.

Working through the preferred means of building the data model, the Calbro Services administrator first considers federating the model year data. This data is not information related to CIs, such as incident requests. Neither is it non-critical detailed information about CIs, such as service records. The model year is a critical piece of information about computer equipment used throughout the company, so the administrator discards federation as an option.

Second, the administrator considers using the existing Category, Type, and Item attributes to store the model year data. These attributes are used for classification, and are insufficient for storing model year information.

Third, the administrator considers using an existing BMC Software extension to the data model, but the model year is not included in extensions Calbro Services intends to use.

Next, the administrator considers adding a new attribute to an existing class. The model year is important to different consumers of BMC Atrium CMDB data. After referring to BMC Atrium CMDB 7.6.04 Data Model Help, the administrator learns that the new attribute could be added to the BMC_ComputerSystem class. Because each subclass inherits attributes from its superclass, the BMC_Mainframe and BMC_Printer classes could also use the new attribute. The administrator would like the option of tracking the model year of mainframes and printers, and so decides that the best approach is to extend the data model by adding a new attribute to the existing BMC_ComputerSystem class.



Naming and numbering rules for new classes and attributesIf you create classes or attributes in your data model, use the following guidelines:

� Name a new class with a prefix other than BMC_ to identify it as your own, and make the name descriptive.

� Give an attribute an Attribute Name that is unique across your entire data model.

� Give attributes a Field ID greater than 536870911 or leave this field blank to automatically generate an ID. Specifying a value greater than 536870911 enables you to create custom BMC Remedy AR System workflow on the field and share the workflow between forms, because you can give the same ID to a field on another form.

It is better to give attributes a Field ID that is unique across your entire data model; therefore you should share workflow only between a BMC Atrium CMDB form and a form that is not part of BMC Atrium CMDB. See the BMC Remedy AR System documentation for information about sharing workflow and other benefits of specifying a Field ID.

BMC Software reserves numbers 536870911 and lower.

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

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

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



Documenting data model extensionsJust as you need to occasionally look up information about classes in the CDM, you will need to look up information about classes and attributes that you create. Enter descriptions for each in the Description fields available in the Class Manager.

You can generate an updated version of BMC Atrium CMDB 7.6.04 Data Model Help—the HTML Help system that provides information about the data model—to reflect your current data model and to include the descriptions for the classes and attributes that you add.

For instructions on generating updated BMC Atrium CMDB 7.6.04 Data Model Help with the cdm2html utility, see the BMC Atrium CMDB 7.6.04 Administrator's Guide.




Chapter

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


� What data goes into an ITIL CMDB? (page 70)� Planning to populate BMC Atrium CMDB (page 74)� Planning to use federated data (page 84)� Controlling access to data (page 91)� Sizing considerations (page 94)� Replicating BMC Atrium CMDB data to other servers (page 94)



What data goes into an ITIL CMDB?ITIL recommends that you store several types of data in the CMDB. Its main purpose is to hold configuration items (CIs) and the relationships between them, which together form a configuration at a particular time or state. ITIL also suggests that the CMDB can hold data related to CIs, such as incident tickets or SLA definitions.

Remember that your CMDB deployment should be based on the needs of consuming applications. Unless and until there is a defined use for a piece of data in your CMDB, ideally that data should not be populated in your CMDB.

Configuration itemsCIs are the focal point of a CMDB. Without a clear definition of what qualifies as a CI, you will constantly struggle with deciding whether to put certain kinds of data into the CMDB. Simply put, a CI is an instance of an entity that is part of your environment and has configurable attributes specific to that instance. These entities can be physical (such as a computer system), logical (such as an installed instance of a software program), or conceptual (such as a business service). But they must be a direct part of your environment, rather than information about such a part. Table 4-1 gives some examples to illustrate this boundary:

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

Table 4-1: Example CIs and non-CIs

Configuration items Not configuration items

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

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

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

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

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


What data goes into an ITIL CMDB?

CI eligibility matrixConsider creating a CI eligibility matrix to help you make decisions about which items in your IT environment should be CIs. A CI eligibility matrix lists each CI candidate, its CI type (such as infrastructure or service), and several eligibility criteria to consider as part of your decision-making for CI candidates. Specific eligibility criteria vary according to the needs of your business, but consider using some of the following criteria:

� Cost or value—Does the CI candidate have an associated monetary cost or value to your business?

� Change considerations—Would the CI candidate be impacted by IT change requests?

� Traceability—Are you required to track changes made to the CI candidate?

� Governance and compliance requirements—Is the CI candidate crucial to maintaining compliance with standards and other requirements?

� Management of service commitments—Is the CI candidate required to help you meet your service commitments to the business?

� Maintainability—Are you required to maintain the CI candidate?

� Delivery cost and quality—Is there a monetary cost associated with how the CI is delivered and maintained?

� Do you, and not a third party, manage the CI candidate?

� Is the CI candidate unique?

� Other factors specific to your business needs.

Use the individual eligibility criteria to set your overall acceptance criteria. For example, you might determine that if a CI candidate meets a simple majority of your eligibility criteria, it should be a CI. You might determine that a candidate must meet each of a select few eligibility criteria to qualify as a CI. You might determine that one eligibility criterion is more important than the rest. The final decision is rooted in your business needs.

After you have set your overall acceptance criteria for determining how a candidate will be evaluated, assess each CI candidate against each eligibility criterion as yes/no or true/false, with yes or true indicating that the candidate should be a CI. After you assess all criteria for a CI candidate, see your overall acceptance criteria to reach a final decision for that candidate.

How Calbro Services used a CI eligibility matrixThis section shows an example of a CI eligibility matrix for Calbro Services. It shows the eligibility criteria that the CMDB implementation team identified as important for determining whether a CI candidate should be a CI. For each CI candidate, the team reached a final decision based on the following requirements:



� The CI candidate must meet eligibility criteria D (identifiable) and E (maintainable).

� The CI candidate must also meet at least one of eligibility criteria A (under change control), B (used for impact modeling), or C (used by the Support team).

After completing the CI eligibility matrix, the Calbro Services CMDB implementation team decided to make CIs for all CI candidates except the Person and Role candidates. Those candidates met the first requirement by meeting both criteria D and E, but they failed the second requirement by not meeting any of criteria A, B, or C.

Figure 4-1: Calbro Services example CI eligibility matrix

Relationships among CIsCIs do not exist in a vacuum; they affect each other. For example, one CI could use, depend on, be a component of, enable, be a member of, or be located in another CI. Storing these relationships in the CMDB enables you to see how CIs interrelate and affect one another.


What data goes into an ITIL CMDB?

NOTE The use of relationships is a critical feature that makes a CMDB a powerful tool, and is a significant difference between a CMDB and an asset store.

Relationships can be simple, such as a disk drive being a component of a computer system, or more complex, like those shown in Figure 4-2:

Figure 4-2: Example relationships

Relationships exist not only between physical CIs, but also between logical and conceptual CIs, such as the software instances and service instance in Figure 4-2. Two CIs can have more than one relationship with each other: for example, an employee might own a server and also operate it.

Relationship data makes the CMDB a powerful decision support tool. Understanding the dependencies and other relationships among your CIs can tell you how upgrading Processor A would improve Server B’s performance or which services would be affected if Router C failed. Most downtime is caused by problems stemming from configuration changes. Accurate relationship information can help you prevent those problems.

Data related to CIsYou might have information related to CIs, such as incident tickets, change events, contracts, service level agreements (SLAs), a Definitive Media Library (DML), and so on. Though these things are not CIs themselves, they contain information about your CIs and are an important part of your IT infrastructure.

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

You can federate related data to make it available through BMC Atrium CMDB. For more information about federating data, see “Planning to use federated data” on page 84.

Dependency

Dependency Dependency

Orders database(software)

Online store(service)

Shopping cart(software)

Web server(computer system)

Disk drive 1 Disk drive 2

Dependency Dependency

DependencyComponent

Server group(collection)

Member of



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

Mapping CIs to the data modelCIs and relationships are represented in BMC Atrium CMDB as instances in the data model. The data model is structured into classes that represent the types of CIs in your IT environment, and the relationships between those CIs.

You must plan how your CIs and relationships will be populated in the data model. See the following resources for planning and best practices:

� BMC Atrium CMDB 7.6.04 Data Modeling Guide

� BMC Atrium CMDB 7.6.04 Common Data Model Diagram

� BMC Atrium CMDB 7.6.04 Data Model Help

Mapping CIs to discovery data sources

This section aligns with Stage 3, Step 17, “Task 3. Map CIs to Data Sources,” of the Step-by-Step Guide to Building a CMDB. In this step, you select a discovery provider to generate the CIs required by consuming applications.

If you are implementing discovery products for the first time, select either the BMC Atrium Discovery and Dependency Mapping product, the BMC BladeLogic Client Automation product, or a third-party discovery tool as your discovery provider. If you want to use both BMC discovery products, use them to discover different endpoints. In this situation, duplicate CIs are not collected and imported to the production dataset.

To select the appropriate BMC discovery provider, consult the following topics:

� “Configuration data discovered by BMC BladeLogic Client Automation” on page 75

� “Configuration data discovered by BMC Atrium Discovery and Dependency Mapping” on page 75

If you identify multiple providers for a class or attribute, you must later identify which provider’s data will be reconciled to the production dataset.

Best Practices

Consider these suggestions when working with discovery sources:

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


Planning to populate BMC Atrium CMDB

� You do not have to populate each possible class with every one of your data providers. Bring into the CMDB only the data that is used by a data consumer to make key business decisions. If no application is consuming the data, there is no value in maintaining and managing it in the CMDB.

� If you are using more than one discovery source to populate an attribute and those sources format the attribute’s value differently—for example, one uses capital letters and the other does not—then you should not rely on those values being formatted consistently in your production dataset. Though one discovery dataset will take precedence over the other in reconciliation, there will be cases where the production dataset receives its value from the lower-precedence dataset. For example, a CI might not yet have been imported into the higher-precedence dataset or might have a NULL value for the attribute in that dataset.

Therefore, you should normalize the values of such attributes between datasets before reconciliation. You can use the Normalization Engine to do this for certain attributes. For others you would need to normalize before importing to BMC Atrium CMDB.

� When deciding how often to transfer data to the CMDB, ask yourself how often the data changes and how important it is that you pick up those changes. You might want to split your transfers into longer intervals for stable things like facilities data and shorter intervals for volatile things like network data.

� Network discovery applications are not the only type of discovery source that you can use to update the CMDB. LDAP systems, Human Resources systems, Facilities systems, third-party Asset Management databases, and others can serve as discovery sources.

Configuration data discovered by BMC BladeLogic Client AutomationThe BMC BladeLogic Client Automation product collects hardware and software inventory information about servers, desktops, laptops, and handheld devices across major platforms within your company. The BMC BladeLogic Client Automation Configuration Discovery Integration for CMDB program maps the collected information and transfers those CIs and relationships to BMC Atrium CMDB using Atrium Integrator.

For a complete list of the CIs and relationships imported into BMC Atrium CMDB, see the BMC BladeLogic Client Automation Configuration Discovery Integration for CMDB Getting Started Guide.

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



Transfer existing configuration data with Atrium IntegratorAtrium Integrator enables you to transfer data between an external data store and BMC Remedy AR System forms or BMC Atrium CMDB classes. For example, if you have existing data that has already been discovered with a non-BMC discovery tool, you can use Atrium Integrator to transfer that data to BMC Atrium CMDB.

Atrium Integrator can transfer data between Microsoft SQL Server, Oracle®, IBM® DB2® Universal Database, XML files, flat files such as comma-separated value (CSV) files, BMC Atrium CMDB, and BMC Remedy AR System. For more information, see the Atrium Integrator 7.6.04 User's Guide.

How Calbro Services discovers CIsCalbro Services uses the BMC BladeLogic Client Automation product to discover the desktop and laptop computer systems (including hardware and software), used by Calbro Services employees.

Calbro Services also uses BMC Atrium Discovery and Dependency Mapping to discover information about the servers, software, and other devices used to deliver banking information to Calbro Services customers.

Lastly, Calbro Services uses a third-party discovery tool to collect information about the equipment that supports the corporate payroll services. Calbro Services uses Atrium Integrator to bring relevant data from the payroll database into BMC Atrium CMDB.

Assessing the configuration data source environment

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

� Which endpoints contain the data that you need to discover?

� How many endpoints need to be discovered?

� Should the endpoints be discovered using agentless discovery or agent-based discovery and will that discovery methodology be allowed in the IT environment?

� What type of endpoints need to be accessed: servers, desktops, laptops, hand-held devices, mainframes, or network devices?

� Which ports are opened on the firewall?

� What credentials are required to access the endpoints?



� Will discovery impact production systems or the network?

For more information about planning discovery with BMC BladeLogic Client Automation, see the BMC BladeLogic Client Automation Configuration Discovery Integration for CMDB Getting Started Guide.

Managing unqualified dataYour discovery tools might not be able to identify a device at an endpoint they discover. The unknown device might be a laptop computer, printer, router, server, or some other piece of hardware. For example, your discovery application might discover an IP address, but lack the proper credentials to access and identify the device at that IP address. Information about unknown devices at known IP addresses is called unqualified data.

Consuming applications can use unqualified data just as they use qualified data. For example, BMC ProactiveNet Performance Management can establish performance monitors at known IP addresses for unqualified data. If the unqualified data becomes qualified, BMC ProactiveNet Performance Management does not need to establish new monitors.

To configure unqualified data, create BMC_ComputerSystem CIs in BMC Atrium CMDB, with the IsUnqualified attribute set to Yes. Connect these CIs to discovered BMC_IPEndpoint CIs by BMC_HostedAccessPoint relationships.

For example, Calbro Services discovers three IP addresses, but cannot identify the devices at those IP addresses. The administrator creates BMC_ComputerSystem, BMC_IPEndpoint, and BMC_HostedAccessPoint instances as shown in Figure 4-3.

Figure 4-3: Unidentified devices at known IP addresses

If Calbro Services later learns the identity of a device at an IP address, the administrator updates BMC Atrium CMDB by completing the following tasks:

� Create a new BMC_IPEndpoint CI, a new CI for the identified device, and the appropriate relationship instance between those CIs. Set the IsUnqualified attribute to NULL.



� Mark the original BMC_IPEndpoint, unqualified BMC_ComputerSystem, and BMC_HostedAccessPoint instances for deletion.

� Create a BMC_BaseRelationship instance between the unqualified BMC_ComputerSystem CI (the source CI) and the new CI that represents the identified device at that IP address (the destination CI). Set the Name attribute of the relationship to CorrespondsTo. This enables you to know which qualified CIs correspond to previously unqualified CIs. When the unqualified BMC_ComputerSystem CI is deleted, the orphaned BMC_BaseRelationship instance is also deleted.

Extending the example started in Figure 4-3, Calbro Services gains credentials to access to the unknown devices, and learns that all three IP addresses are used for a single computer system. The administrator creates new CIs and relationships for the computer system and its IP addresses, marks the original CIs and relationships for deletion, and creates new relationships between the old and new BMC_ComputerSystem CIs to indicate that the unqualified CIs have been qualified as a single computer system. Figure 4-4 shows the qualified data associated with the unqualified computer systems marked for deletion.

Figure 4-4: Qualified data associated with unqualified data



Grouping CIs into datasets

This section aligns with Stage 3, Step 17, “Task 5. Group CIs into datasets,” of the Step-by-Step Guide to Building a CMDB. A dataset is a collection of CIs and relationships for a given purpose. Together they form a picture of some state, time, or configuration.

The primary purpose of datasets is to partition data according to the providers of that data. Each discovery application that you use should store the data that it discovers in a separate dataset. Data in a separate database that you import to BMC Atrium CMDB through Atrium Integrator should be stored in a separate dataset.

You can also use datasets for other methods of partitioning data. For example, you could use datasets to represent production data or obsolete data. Your datasets do not all need to contain different versions of the same CIs and relationships. For example, you could use datasets to hold:

� Subsets of your overall data, such as departments or regions

� Data from different companies for multitenancy

� Test data

A dataset can contain only one instance of a given CI. An instance of that CI might also exist in other datasets to represent the CI in the contexts of those datasets. Instances representing the same CI or relationship across datasets share the same reconciliation identity, or reconciliation ID.

Each CI and relationship in BMC Atrium CMDB must reside in a dataset, meaning that they have a DatasetId attribute that must contain a value.

BMC Software datasetsThis section describes the default datasets provided by BMC Atrium CMDB, BMC Remedy Asset Management, and BMC discovery products. If you use a non-BMC discovery product, use Atrium Integrator to import its data.

Table 4-2: Default BMC Atrium CMDB datasets used by BMC discovery products (Sheet 1 of 2)

Data created by Dataset name Dataset ID Purpose

BMC Atrium CMDB BMC Asset BMC.ASSET Production dataset, which is the dataset that you treat as your “single source of reference” and that you use to make business decisions.

BMC Atrium CMDB BMC Sample BMC.SAMPLE A safe place to do testing.

BMC Remedy Asset Management

BMC.ASSET.SANDBOX BMC.ASSET.SANDBOX If BMC Remedy Asset Management is configured with a sandbox dataset, CIs that you manually create or modify flow through the sandbox dataset; otherwise, CIs go directly into the production dataset.



How Calbro Services partitions data into datasetsCalbro Services uses the BMC BladeLogic Client Automation product to discover the desktop and laptop computer systems, (including hardware and software) used by Calbro Services employees. This information is stored in the BMC Configuration Import dataset of BMC Atrium CMDB.

Calbro Services also uses BMC Atrium Discovery and Dependency Mapping to discover information about the servers, software, and other devices used to deliver banking information to Calbro Services customers. This data is stored in the BMC.ADDM dataset.

Lastly, Calbro Services uses a third-party discovery tool to collect information about the equipment that supports the corporate payroll services. Calbro Services uses Atrium Integrator to bring relevant data from the payroll database into BMC Atrium CMDB. The administrator creates a new dataset named Calbro Payroll specifically for this information.

Because some of the instances in these different datasets might represent the same real-world CIs, the administrator configures BMC Atrium CMDB reconciliation jobs to compare those datasets against each other and put the preferred pieces of information in the production BMC Asset dataset.

Overlay datasetsBMC Atrium CMDB offers overlay datasets, which enable you to:

� Make changes in a separate partition without overwriting your production data.

� See your changes in context with the unchanged portions of your data.

� Avoid duplicating your entire production dataset.

� Create multiple overlay datasets that reuse one set of reconciliation definitions for merging each into the production dataset.

BMC BladeLogic Client Automation

BMC Configuration Import BMC.IMPORT.CONFIG Import CIs and relationships from the BMC BladeLogic Client Automation database for reconciliation.

BMC Atrium Discovery and Dependency Mapping

(User-defined) BMC.ADDM Import CIs and relationships from the BMC Atrium Discovery and Dependency Mapping data store for reconciliation.

Table 4-2: Default BMC Atrium CMDB datasets used by BMC discovery products (Sheet 2 of 2)

Data created by Dataset name Dataset ID Purpose



WARNING Overlay dataset functionality applies only to BMC Atrium CMDB API clients. If you use the BMC Atrium Core Console or the class forms to view or modify instances in an overlay dataset, you receive unpredictable results and can compromise data integrity.

How overlays work

When you create an overlay dataset, you must specify an existing regular dataset for it to overlay. Although an overlay dataset starts out empty like any other dataset, any request for an instance in the overlay dataset passes through the overlay dataset and returns that instance from the underlying dataset.

When you modify an instance in the overlay dataset the first time, it is copied there from the underlying dataset with your modifications. You can also create instances in the overlay dataset. The underlying dataset still holds the unmodified versions of its original instances, but it does not hold the newly created instances. A request to the overlay dataset for a new or modified instance returns that instance from the overlay dataset, and a request to the overlay dataset for an unmodified instance returns it from the underlying dataset.

NOTE Requests made to the underlying dataset always return instances from that dataset, never from an overlay dataset.

Figure 4-5 illustrates queries against an overlay dataset, one for a modified instance and one for an unmodified instance. Notice that the modified instance shares the same reconciliation ID with its unmodified counterpart, but not the same instance ID.



Figure 4-5: Query to an overlay dataset

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

Result of deleting instances from an overlay dataset

If you attempt to delete from an overlay dataset an instance that actually exists there, the instance is deleted only from the overlay dataset and remains in the underlying dataset. If you attempt to delete from an overlay dataset an instance that exists only in the underlying dataset, the instance is deleted from the underlying dataset.

You can mark an instance as deleted regardless of whether it already exists in the overlay dataset. In either case, this results in an instance in the overlay dataset that is marked as deleted.

Instance ID and identity in overlay datasets

When an instance is first created in an overlay dataset as the result of a modification, it retains the reconciliation identity of the instance in the underlying dataset, but is assigned a new instance ID.

If the underlying instance has not yet been identified when it is modified in the overlay dataset, the instance has no reconciliation identity in either dataset. This is not a problem. When you eventually identify and merge the two datasets, your Identify rules should be able to match these instances so that they receive the same identity.

BMC_ComputerSystem

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

BMC_ComputerSystem

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

BMC_ComputerSystem

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

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

ResultsSystem Type: DesktopNumberOfSlots: 4

Overlay dataset "Sandbox"

Regular dataset "Production"

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

ResultsSystem Type: DesktopNumberOfSlots: 5



WARNING For each modification that you make to an instance before it is identified, an instance is created in the overlay dataset. You should identify instances before modifying them a second time in the overlay dataset.

If you decide to keep the changes that you modeled in an overlay dataset, you can merge them into the underlying regular dataset.

Controlling client write access to datasetsBy default, all BMC Atrium CMDB clients can create, modify, and delete instances in a dataset. However, you can choose to restrict this write access to one or more specific clients: BMC Impact Solutions Publishing Server, BMC Impact Solutions Service Model Editor, and the Reconciliation Engine. When you do this, BMC Atrium CMDB users cannot write to the dataset with a browser or BMC Remedy User client. You can also set a dataset to have no write access whatsoever.

Consider restricting write access to your production dataset. By allowing only the Reconciliation Engine to write to your production dataset, you prevent unauthorized changes to your single source of reference. Changes then must be made to other datasets and then reconciled to the production dataset.

Identifying the discovery schedule sequence

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

� The requirements of the consuming application

� The amount of data to be collected

� The availability of the data

� The demand on the production environment and other performance factors

� How often the data changes and needs to be updated in the CMDB

After the initial discovery and population of BMC Atrium CMDB, the Discovery Manager and Configuration Manager need to set a schedule for discovering changes (new, modified, or removed CIs), importing the changed CIs to BMC Atrium CMDB, and merging the changed CIs with the production configuration data. If you use non-BMC discovery solutions, you must determine how best to schedule an ongoing discovery process.

Guidelines for scheduling and running BMC Atrium Discovery and Dependency Mapping scansIn BMC Atrium Discovery, you must first select one of the following scanning levels to use:



� Sweep Scan—Confirms only that there is an IP device at each endpoint in the scan range

� Full Discovery—Retrieves all the default information for hosts and complete full inference

In the Configuration Settings, you can set the number of concurrent discovery requests. As this number gets larger, performance could be negatively impacted, especially in environments where the network is slow to respond. The default value varies for each appliance, and is calculated to achieve maximum performance. However, if you experience a situation where many discovery commands are timing out, you can adjust the default value to between 30 and 150 (in increments of 30). Generally, the more discovery requests you enable to process concurrently, the more you increase network traffic and the absolute time to discover a single host. However, you can use different settings as part of an overall approach to improve discovery processing throughput.

For more information about configuring discovery settings and recommended performance factors, see the BMC Atrium Discovery 8.1 Deployment Guide at http://www.tideway.com/confluence/display/81/Deployment+Guide. From that page there is also a link that enables you to download a PDF version of the guide.

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

Planning to use federated dataFederated 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.

In BMC Atrium CMDB, not only can you view federated data, you can retrieve that data for use by a consuming application as if it were part of BMC Atrium CMDB. This feature enables you to access outside data from central CMDB repository and lets you use your existing data store infrastructure.


http://www.tideway.com/confluence/display/81/Deployment+Guide

Planning to use federated data

Figure 4-6 illustrates both types for a BMC_ComputerSystem instance named Computer A. The instance can be linked to incident records about Computer A, which are related information, and also linked to discovered attributes of Computer A that were not imported into BMC Atrium CMDB.

Figure 4-6: Federated data

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

When to use federated dataThough a CMDB is intended as the single source of reference about your environment, it should not be the single repository of reference. Consumers should be able to use the CMDB to find all of your configuration data, but it should federate much of that data to other data stores.

In general, you should have more federated data than you do data stored in the CMDB. The CMDB should be the card catalog that gives you basic information about what is in your library and tells you where to find the rest. It should not be the library. It is better to start small with the data stored in your CMDB, and federate the rest. You can add data directly to the CMDB later if necessary. For example, you might store computer system CIs in the CMDB, and federate data about computer components. Given this general strategy, here are a few more considerations and recommendations when deciding which data to federate:

� Linking to federated data from the CMDB does not mean that you must go through the CMDB to access that data. You can still access the data directly from its own application when you do not need the context provided by a CI.

� Federating avoids rewriting applications to get their data from the CMDB instead of their current data stores.

BMC Atrium CMDB

Incident ID: 0001Category: PerformanceMachine: Computer A

Computer System Name: Computer ARegistry settings: XYZ

Discovery DB

Incident DB

BMC_ComputerSystem

Name: Computer ASystemType: DesktopNumberOfSlots: 4



� Federating avoids extending the CMDB data model.

� You can federate data that exists on databases, CMDBf-compliant CMDBs, and BMC Remedy AR System forms.

� You might use multiple CMDBs in your company. For example, you might use a different CMDB for each of several geographical regions. Use one CMDB as the single source of truth about your IT environment, and federate the data on your other CMDBs.

� Federate attributes that rarely ever change, or that change more than once a day. The former are not important enough to track in your CMDB, and the latter (such as the current load on a server) are likely to be out of date in a CMDB.

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

� Federate data such as change requests or incident records that are not CIs but are information about CIs.

� Federate definitional data such as a Definitive Media Library.

How Calbro Services uses federationCalbro Services stores service and maintenance records for their printers in a Microsoft SQL database. Allen Allbrook, a BMC Atrium CMDB administrator at Calbro Services, knows that only core data for a CI should be stored in BMC Atrium CMDB. Detailed and related data for those CIs should be federated to help organize CIs and make BMC Atrium CMDB more efficient.

Allen determines that the service and maintenance database stores information that is related to CIs in the CMDB, and makes that data available using the retrieval method of federation. The federated data is then available for viewing from within BMC Atrium CMDB through Atrium Explorer.

Federation methods in BMC Atrium CMDBBMC Atrium CMDB enables you to configure federation through retrieval and launch methods. The retrieval method enables you to view federated data as if it were stored in BMC Atrium CMDB. The launch method enables you to view federated data through another application, such as a BMC Remedy AR System form.

These methods enable you to retrieve data in the context of a CI. That is, you want data that is relevant to a particular CI, not every piece of data an external source has to offer.



Retrieval method of federationWith the retrieval method of federation, you create BMC Atrium CMDB classes to represent data that is stored outside of BMC Atrium CMDB. You also create federated relationship classes that join classes that are already part of the BMC Atrium CMDB data model to the new federated data classes. This enables you to view the relationships between federated data and BMC Atrium CMDB data through such tools as Atrium Explorer and Atrium Impact Simulator.

Figure 4-7: Federation objects for the retrieval method

The federated data class represents a set of information on the external source of data (such as a table on a database), so that data can be viewed within the context of the data model. As part of the process of creating a federated data class, BMC Atrium CMDB creates attributes to represent the fields from the external repository. Federated data classes that you create are subclasses of the BMC_FederatedBaseElement class.

The federated relationship class establishes a relationship between CIs stored in BMC Atrium CMDB and external data. Federated relationship classes that you create are added to the data model as subclasses of the BMC_FederatedBaseRelationship class. The source class of the relationship must be in the BMC_BaseElement hierarchy of classes, and the destination class of the relationship must be a federated data class.

Launch method of federationWith the launch method of federation, you define the method of viewing the data (such as opening the data on a BMC Remedy AR System form), and create a link between that data and CIs in BMC Atrium CMDB. For example, you could use the URL method to access any database to which you allow browser access, and you could use the BMC Remedy AR System query method to access data from a BMC Remedy AR System form.

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

Federated relationship

Federated data storeCI class

Federated data class

Externalsource of

data

CMDB



Figure 4-8: Federation objects for the launch method

A CI class or instance has a launch link relationship to a launch interface, which defines the information necessary to access a particular piece of federated data.

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

If foreign key substitution is used, the federated data store also has one or more federated key link relationships to CIs. This relationship carries the key value that identifies the federated data for the CI.

BMC Atrium CMDB offers attribute substitution and foreign key substitution as ways to implement the launch method of federation.

Attribute substitution

Attribute substitution is the more straightforward method of federating data in context. The information in a launch interface can include placeholders representing attributes from the linked class. The values for those attributes are substituted when a user or application launches the link, which enables it to access a different set of federated data for each instance of the class.

Figure 4-9 shows an example of this. The value of the Name attribute is substituted in the launch interface, so that the access string for Computer A queries for incident records where Machine = “Computer A” and the access string for Computer B queries for incident records where Machine = “Computer B.”

Launch link

Launch link

Federated key linkKey value

Federatedproduct link

Federated data storeCI instance

CI class

Launch interface

Externalsource of

data

CMDB



Figure 4-9: Attribute substitution

Foreign key substitution

Some external sources of data do not have data that also exists as attributes of CIs in BMC Atrium CMDB, which means that you cannot use attribute substitution to match a CI to pieces of federated data. You can still federate this data in context by using a foreign key, a unique identifier in the data store that maps to a specific CI.

For example, you might have maintenance contracts for your office equipment, where the contracts do not see individual pieces of equipment. If you have no single piece of data to link the contract to a CI, you can create a foreign key link that enables you to identify the contract that is associated with a particular CI.

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

Figure 4-10 shows an example of this. The Incident DB does not store the name, system type, or number of slots of the computers related to an incident, so foreign key substitution is necessary. The value of the key from each federated key link relationship is substituted in to the launch interface, so that the access string for Computer A queries for an incident ID of 0001 and the access string for Computer B queries for an incident ID of 0002.

Incident ID: 0001Category: PerformanceMachine: Computer A

Incident

ID: 0002Category: ConnectivityMachine: Computer B

Incident DB

BMC_ComputerSystem


BMC_ComputerSystem

Name: Computer BSystemType: LaptopNumberOfSlots: 2

CMDB

Federated Data Store

Incident DB

Launch Interface

Show records where'Machine' = $Name$



You create the key as an instance of the FederatedKeyLink form. An instance of FederatedKeyLink is required for every CI that keys a foreign key link to federated data.

Figure 4-10: Foreign key substitution

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

Incident DB

CMDB

Federated Data Store

Incident DB

Key = 0002

Key = 0001

Launch Interface

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

Incident ID: 0001Category: Performance

Incident

ID: 0002Category: Connectivity

BMC_ComputerSystem


BMC_ComputerSystem

Name: Computer BSystemType: LaptopNumberOfSlots: 2


Controlling access to data

Controlling access to dataBMC Atrium CMDB offers a flexible permissions model that lets you grant role-based permission to areas of BMC Atrium CMDB functionality and grant row-level read and write permission to instance data.

This row-level security enables BMC Atrium CMDB to support multitenancy. Multitenancy means that one CMDB holds data about multiple parties’ IT environments, usually in the case of an IT service provider, and each party can access only their own data. Each party whose data is represented in the CMDB is considered an account.

Overview of multitenancyMultitenancy has long been a feature in the BMC Remedy IT Service Management (BMC Remedy ITSM) product suite that enables you to control which records and configuration data are exposed to a user, based on the user’s membership in a company, business unit, or other group.

Although multitenancy is primarily used by consuming applications such as BMC Remedy ITSM and Service Impact Manager, BMC Atrium CMDB provides the mechanisms for a multitenancy permission model. BMC Atrium CMDB also defines a base implementation for a multitenancy permission model. You can extend this base implementation or develop a new implementation that is consistent with the base implementation. The Product Catalog component also leverages multitenancy. If you have not installed BMC Remedy ITSM, you can set up multitenancy by using the Product Catalog and the AccountID default instance permissions in BMC Atrium CMDB. If you do this, make sure that the AccountID values match the company values in the Company form. AccountID is used to control BMC Atrium CMDB multitenancy, while the company field is used to control multitenancy in the Product Catalog and BMC Remedy ITSM applications.

You can use multitenancy to control access in a hosted environment. For example, in a service provider environment, a single BMC Atrium CMDB application might be used by multiple companies, with the data for each company hidden from the other companies using the application. You can also use multitenancy to control access in a single company, with the data for each business unit hidden from other business units.

Multitenancy is used to segregate data and restrict access by the Company field, in BMC Remedy ITSM, or the Company form in BMC Remedy AR System. Access restrictions can be created so that a user with access to only one company cannot see data for another company. To segregate data by business unit, you must record each business unit as a separate company. In this scenario, a user with access to only one business unit cannot see incidents for another business unit.



NOTE You can use BMC Remedy ITSM to set up multitenancy. However, if you have not installed BMC Remedy ITSM, you can set up multitenancy by using the Product Catalog component of BMC Atrium Core. For more information, see BMC Atrium Core 7.6.04 Product Catalog and DML Guide.

BMC Atrium CMDB multitenancy permission modelThe DefaultAccountPermissions class enables you to define default permissions based on AccountID. From the account ID, you can assign default permissions when you create CIs. Default instance permissions enable you to specify CMDBRowLevelSecurity and CMDBWriteSecurity values for an entire class instead of specifying them every time you create an instance of the class. You can give these permissions to a different group for each account ID, which supports multitenancy by enabling you to grant users access to only the instances for their account. For more information about default instance permissions, as well as roles and other permissions, see the BMC Atrium CMDB 7.6.04 Administrator's Guide.

The Product Catalog supports defining approved products for different organizations. Multitenancy enables you to have a single Product Catalog shared among multiple organizations and track the approved products for each organization.

You can define the approved items for the version and patch levels, not just the product name. All the other options in the Product Catalog are separated for each products by organization as well. For more information, see BMC Atrium Core 7.6.04 Product Catalog and DML Guide.

Calbro Services’ access implementationCalbro Services has several different business units. Although each business unit is part of the overall company, the various business units need access to different applications and data. For example, all employees of Calbro Services can install Microsoft Word, but only certain members of Finance should install and work with the payroll application. HR has a similar restriction on the job posting and recruitment application used by that business unit. Members of IT should have access to all applications.

Calbro Services must set up product access and restrictions in the Product Catalog for Finance and HR. IT will have access to all possible products. Figure 4-11 illustrates the access in this scenario, in which some people have access to Finance products, some people have access to HR products, and others have unrestricted access to all products.


Controlling access to data

Figure 4-11: Access to applications in business units

This scenario includes the following groups:

� Finance—People in this group can access products used only by Finance.

� HR—People in this group can access products used only by HR.

� IT—People in this group can access all products, including those used by HR and Finance.

Allen Allbrook, the Calbro Services administrator, creates Operating Company entries for Finance, HR, and IT in the Product Catalog. This automatically creates BMC Remedy AR System regular groups for these Operating Companies.

Next, Allen assigns individual employees to these BMC Remedy AR System groups. For example, Allen adds Patrick Paycheck to the Finance group, Betty Benefits to the HR group, and himself to the IT group.

Allen can then configure the Product Catalog entries for application access according to the Operating Company. Allen allows the Global company (everyone at Calbro Services) access to Microsoft Word, the Finance company access to the payroll application, the HR company access to the job posting and recruitment application, and the IT company access to all applications.

NOTE Membership in a business unit is not the same as access to a business unit.

Product Catalog entries do not restrict employee access to applications, but Allen can run discovery reports about the applications installed on employee computers, and then uninstall applications that are not approved for use according to the Product Catalog.



Additionally, people in Finance need to see employee information stored in the BMC_Person form, while people in HR need access to change information on that form. To accomplish this, Allen establishes instance permissions to data on the BMC_Person form. He first makes sure that the Finance and HR groups have access to the CMDB Data View role. Next, Allen adds the Finance and HR groups to the CMDBRowLevelSecurity attribute value for BMC_Person entries those employees should see. Allen then adds the HR group to the CMDBWriteSecurity attribute value for entries that HR employees should have access to modify.

For more information about how permissions and multitenancy are related to products used by a company, see the BMC Atrium Core 7.6.04 Product Catalog and DML Guide. For information about setting permissions, see the BMC Atrium CMDB 7.6.04 Administrator's Guide.

Sizing considerationsWhen planning for BMC Atrium CMDB population, you should consider sizing factors, scalability, and hardware recommendations for the BMC Remedy AR System environment. This includes the BMC Remedy AR System server, server tier components such as Approval Server and the Assignment Engine, BMC Atrium CMDB components, and the BMC Remedy Mid Tier. The same consideration should be given to the discovery applications that you choose. For detailed information about sizing, see the white paper titled Reference Architecture for BMC Service Support Solutions.

Replicating BMC Atrium CMDB data to other servers

You might want to replicate all or part of your CMDB to other servers for a number of reasons, including disaster recovery, accessibility, or regional or departmental use. This is perfectly acceptable, and can be accomplished with the Distributed Server Option of BMC Remedy AR System or with database replication.

However, do not split your primary CMDB. Turning a CMDB into a distributed database defeats its purpose of being a single shared access point for all the configuration data about an organization.

If performance is a concern, you can use a server group for the BMC Remedy AR System server where your BMC Atrium CMDB is installed. BMC Atrium CMDB supports server groups with and without load balancers.


Chapter

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


� Overview of normalization and the Product Catalog (page 96)� Normalization (page 97)� Product Catalog (page 98)� How Calbro Services planned normalization and Product Catalog

implementation (page 100)



Overview of normalization and the Product Catalog

The Normalization Engine and the Product Catalog are separate components but are described together because of their close interaction. In the context of BMC Atrium Core, normalization refers to modifying CIs and relationships to conform to consistent standards. Primarily, this involves ensuring that product names and categorizations are consistent across different datasets and from different data providers. Data of the same type follows the same formatting conventions. In that role, the Normalization Engine typically relies on the Product Catalog.

For example, a product that might have different names representing the same product is Microsoft Office Word. Different discovery tools might record this product’s name as Microsoft Office Word, MS Word, Word 2003, and so on. Each of these names might seem to represent a different product. The Normalization Engine can determine that these different names represent the same product, and alters each instance to use the approved name.

The benefit of normalization is that you get accurate results when searching or running reports for your data. For example, you can use the License Engine component of BMC Remedy Asset Management determine whether your environment has more installed copies of something than your license allows.

Figure 5-1 shows a simplified flow of data from either discovery or transfer of existing data with Atrium Integrator. Data from each source or discovery tool is organized into datasets, which are then reconciled so that one production dataset represents your environment. You can also create datasets to group data; however, the datasets represented in Figure 5-1 depict the initial datasets that are part of the discovery or transfer process.


Normalization

Figure 5-1: Data flow

NormalizationYou can choose to normalize data before or after it is written to a dataset in BMC Atrium CMDB.

� Normalization batch (scheduled) mode, enabled by default, can be scheduled or started manually from the Normalization Console.

� Inline normalization mode normalizes CIs before they are written to BMC Atrium CMDB datasets.

� Continuous normalization mode allows CIs to be written to a dataset before they are normalized.

Best practice

When you initially load CIs from your data providers into BMC Atrium CMDB, BMC recommends that you use the batch mode rather than inline or continuous normalization. Batch mode runs a Normalization Engine job on un-normalized data on demand or on schedule that meets your needs. If you are implementing BMC Atrium CMDB for the first time, your current data will not be normalized. After the initial loading of CIs, you can use the inline or continuous mode to update CIs that exist in BMC Atrium CMDB but are not normalized.

To make sure that data is normalized initially and kept normalized, use continuous mode to make sure that your dataset remains normalized.

CMDB

Atrium Integrator

Reco

nci

liatio

n

En

gin

e

BMC AtriumProduct Catalog

Data providers

Federated data

ConsumersProduction dataset

Import datasets

Normalization Engine



Inline mode is used mainly for integrations when a data source is writing to BMC Atrium CMDB, and you might need to take action during the data population process if an error occurs.

For more information about normalization, see the BMC Atrium CMDB 7.6.04 Normalization and Reconciliation Guide.

Product CatalogThe Product Catalog is a BMC Remedy AR System application that includes several components to manage products for companies and organizations. It is a library of all the products available to an organization, defining each product and its attributes, such as name, manufacturer, version, and so on. The Product Catalog contains characteristics of products that enhance the accuracy of BMC Discovery products by uniquely identifying a package regardless of installed name or location.

The main purpose of the Product Catalog is to enable you to manage the products in your organization:

� By providing identifying characteristics of products

� By providing a single name for each product and its versions

� By providing data for normalization and discovery, including storage of product signatures

� By recording whether a product is approved for use in your organization

� By tracking and managing products by categorization, life cycle, development status, approval status, and other attributes

� By managing products by companies and organizations (multitenancy)

� By providing data for license management, compliance, and usage tracking

For more information about the Product Catalog, see the BMC Atrium Core 7.6.04 Product Catalog and DML Guide.

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


Product Catalog

Components of the Product CatalogThe Definitive Media Library (DML) is a subset, or filter, of the Product Catalog that represents software products that are marked as approved for use in an organization. In previous releases of ITIL, the DML was called the Definitive Software Library.

The Definitive Hardware Library (DHL) is a subset, or filter, of the Product Catalog that represents hardware products that are marked as approved for use in an organization.

CategorizationsProduct categorization divides CIs into groups. Using the tiered structure of product categorization, you can create successively smaller, more tightly defined groups. You can create groups of CIs in Tier 1. In Tier 2, you can define smaller groups of each of those groups. In Tier 3, you can create even smaller groups within these groups.

For example, you might use Tier 1 to divide CIs into hardware and software groups. Within the hardware group, you might define Tier 2 groups for disk device, peripheral, processing unit, and virtual system. Within the processing unit group, you might define Tier 3 groups for desktop, laptop, mainframe, personal digital assistant, and server.

CIs in BMC Atrium CMDB store Product Catalog categorizations in the Category (Tier 1), Type (Tier 2), and Item (Tier 3) attributes of the BMC_BaseElement CDM class.

Multitenancy with the Product CatalogThe Product Catalog supports defining approved products for different organizations. Multitenancy enables you to share a single Product Catalog among multiple organizations but track the approved products for each organization from the same Product Catalog data.



How Calbro Services planned normalization and Product Catalog implementation

Because Calbro Services is populating BMC Atrium CMDB for the first time, the administrator uses the default batch mode to normalize data. This makes sure that all of the existing CIs are normalized by a single Normalization Engine run. After the initial normalization, the administrator sets up the continuous normalization mode to make sure that the data remains normalized.

The Normalization Engine evaluates CIs with information it retrieves from the Product Catalog and normalizes the following attributes for Calbro Services’ hardware and software products:

� Name

� Product categorization attributes: Category, Type, and Item

� ManufacturerName

� Model (applicable to hardware)

� VersionNumber (applicable to software)

� PatchNumber (applicable to software)

� Other attributes as defined by each class

For example, software CIs named Microsoft Visio and Visio 2007 are normalized to the approved name Microsoft Office Visio 2007. Printer CIs are normalized to the approved Category, Type, and Item values of Hardware, Printer/Multifunction, and System—Printer, respectively.


Chapter

6
Planning data reconciliation
This section describes how to plan for the reconciliation of data from source datasets to a production dataset. With multiple data providers loading data into multiple datasets of BMC Atrium CMDB, you need a reconciliation process to compare expected data against discovered data and create one complete and correct production dataset. The BMC Atrium CMDB Reconciliation Engine performs the main reconciliation tasks of identifying, merging, and comparing datasets and also gives you other tools for working with datasets.


� Identifying instances (page 102)� Comparing datasets (page 103)� Merging datasets (page 103)� Other reconciliation activities (page 107)� Combining activities as a job (page 107)� Qualification groups (page 108)



Identifying instancesBefore you can compare or merge different versions of an entity, you must determine that they indeed represent the same entity. You must identify each instance.

The Identify activity accomplishes this matching by applying rules that you specify against instances of the same class in different datasets. For example, a rule to identify computer system instances might specify that the IP addresses of the instances be equal.

When the rules find a match, both instances are tagged with the same reconciliation identity, an extra attribute that shows that they each represent the same item in their respective datasets.

You can also manually identify instances that were not identified by rules in an Identify activity.

To identify instances, you must create an Identify group for each participating dataset. In this group you must create Identify rules that attempt to match instances of a particular class in that dataset against instances in all other participating datasets. For example, to compare datasets A, B, and C you need the following groups: one each to match A against B and C, B against A and C, and C against A and B.

To identify data in different classes based on different criteria, you must create more Identify groups. Because the subclasses of the specified class inherit the groups, if your data is sufficiently normalized, you could specify groups only for the base class BMC_BaseElement.

You then create an Identify activity and associate the Identify groups to it. Designate one of the participating datasets as the master dataset, meaning that the reconciliation identity of its instances is applied to matching instances in the other datasets, which are known as auto-identify datasets. If the instance in the master dataset does not have an identity, one is automatically generated.

TIP If you identify a class between datasets that are poorly normalized and you cannot find attributes of the class itself on which to match, you can match on an attribute of a source CI if a weak relationship exists and has any propagated attributes. For example, if you always give a disk drive a BMC_HostedSystemComponent relationship to the computer system where it is installed, you can match two disk drives because their source computer systems have the same name, because BMC_HostedSystemComponent propagates the Name attribute from system to component.

For more information about identifying, see the BMC Atrium CMDB 7.6.04 Normalization and Reconciliation Guide.


Comparing datasets

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

Compare lets you compare an expected configuration against an actual one, which you could use for more than one purpose. You might use Compare to alert you that something has changed in a configuration that you expected to remain static. Alternatively, if you have a change request in progress, you might use Compare to verify that the configuration reaches its expected new state.

Only instances that have been given a reconciliation identity can be compared, and they are compared only against other instances with the same identity. If you choose to execute workflow as a result of the comparison instead of creating a report, that workflow can execute against instances from either dataset but not both.

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

To execute workflow as a result of the comparison, you must also create a Workflow Execution group to associate with the Compare activity and from that group, create a Workflow Execution rule for each qualification that, if true, causes workflow to execute. The qualification can evaluate attributes from both datasets.

You also must create one or more BMC Remedy AR System filters to perform the workflow for each Workflow Execution rule.

For more information about comparing, see the BMC Atrium CMDB 7.6.04 Administrator's Guide.

Merging datasetsMerging takes data from multiple source datasets and creates a composite by copying that data to a single target dataset according to precedence values that you specify.

Merging is essential to produce a single, valid configuration when different discovery applications provide overlapping data about the same items, or when you need to commit changes that were made in an overlay dataset. Only instances that have been given an identity can participate in a Merge. To take advantage of the areas of strength in each dataset, you create precedence values that favor those strengths. Merging the highest-precedence attribute values gives you one CI instance with the best of all discovered data.



An overall precedence value is given to each dataset, with the ability to override it for particular classes and attributes in each dataset. Whichever dataset has the highest precedence value for a given attribute has its value for that attribute placed in the target dataset. A precedence value specified for a class also applies to its subclasses unless they override it with precedence values of their own.

You can merge data from multiple source datasets either by creating one Merge activity that includes all the source datasets or by creating independent Merge activities that each merge only the data from one source dataset.

TIP No matter which of these strategies you choose, you can shorten the run time of a Merge activity by setting Force Attribute Merge to No. This causes the activity to perform an incremental merge, processing only the attribute values that have been modified since the activity was last run. If an attribute value has not changed, there is no need to merge it again.

Using a single Merge activityWhen you use one Merge activity, the precedence values of all source datasets are compared to each other at once, and the data from the dataset with the highest precedence value is written to the target dataset. Figure 6-1 provides an example of precedence values being applied when two datasets are merged with a single Merge activity.


Merging datasets

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

In this example, source Datasets A and B are merged into target Dataset C. Though Dataset A has a higher precedence value (500) than Dataset B (300), Dataset A has class and attribute precedence values for Application System and the IPAddress attribute of Computer System (both 200) that are lower than Dataset B. Dataset C has a precedence value (100) lower than either source, and as a result, none of the data it contained in step 1 survives the merge.

In the Merge activity represented by step 2, Dataset C receives the Monitor and the SystemType attribute of the Computer System from Dataset A, with a precedence value that trumps Dataset B’s. But because the Application System and the IPAddress attribute of the Computer System have lower precedence values in Dataset A, Dataset C receives these from Dataset B.

Using independent Merge activitiesUsing independent Merge activities is the recommended method of merging datasets, using only one source dataset per Merge activity. After each Merge activity runs, the target dataset retains—for each attribute that was merged—the precedence value of the dataset that supplied the data for that attribute. When you use independent Merge activities, each activity compares the precedence values of its source dataset to the precedence values of those “last victorious” datasets.

2

1

Dataset A (500)

Computer System

IPAddress (200): 10.20.30.50SystemType: Laptop

Application System (200)

Monitor

Dataset B (300)

Computer System

IPAddress: 10.20.30.60SystemType: Desktop

Application System

Monitor

Dataset C (100)

Computer System


Application System

Monitor

Dataset C (100)

Computer System

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


Monitor (500)



Because the source dataset in any merge is always compared against the highest precedence value from previous merges, it is as though precedence values from all source datasets are compared in each merge. This frees you from having to design a Merge activity for every combination of source datasets that might be merged together, and enables you to add new source datasets in the future without reworking all your Merge activities. Figure 6-2 provides an example of precedence values being applied when two datasets are merged with independent Merge activities.

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

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

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

2

1

3

Dataset A (500)

Computer System

IPAddress (200): 10.20.30.50SystemType: Laptop


Monitor

Dataset B (300)

Computer System


Application System

Monitor

Dataset C (100)

Computer System


Application System

Monitor

Dataset C (100)

Computer System


Monitor (500)

Dataset C (100)

Computer System



Monitor (500)



Other reconciliation activities

In the Merge activity represented by step 3, Dataset B is merged into Dataset C. Dataset B’s precedence value of 300 is enough to beat the precedence values stored for all attributes of the Application System and the IPAddress attribute of the Computer System, so its data replaces the data written from Dataset A in step 1. But Dataset B’s data for all attributes of the Monitor and the SystemType attribute of the Computer System is not written to the target because the data placed there from Dataset A has higher precedence values.

For more information about merging, see the BMC Atrium CMDB 7.6.04 Normalization and Reconciliation Guide.

Other reconciliation activitiesThe Reconciliation Engine offers the following additional activities:

� Rename Dataset—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—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—deletes instances from one or more datasets. It does not delete the dataset itself.

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

� Execute Job—executes a reconciliation job.

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

� With schedules defined for the job

� Manually

� From another job

� From a BMC Atrium CMDB API program

� From BMC Remedy AR System workflow



When you use BMC Remedy AR System workflow or a BMC Atrium CMDB API program to execute a job, you can dynamically specify datasets and qualifications for the job to operate against, replacing those defined for the job. This enables you to reuse reconciliation definitions with multiple overlay datasets and with subsets of data.

Qualification groupsMost reconciliation activities enable you to specify a Qualification group to restrict the instances that participate in an activity. Qualification groups, which are reusable between activities, are sets of qualification rules that each select certain attribute values. Any instance that matches at least one Qualification in a group can participate in an activity that specifies the group.

For example, if your company just opened a Frankfurt office and you are reconciling its discovered CIs for the first time, you might create a Qualification group that selects instances that were discovered within the last 24 hours and have the domain Frankfurt.


Chapter

7
Planning a service model
This section provides information about designing, developing, and maintaining service models that enable you to manage your IT resources from the perspective of the business services that they provide.


� Service model overview (page 110)� Designing a service model (page 113)



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

Relationships between service componentsA physical or logical resource represented in the model is known as a service component instance or component instance. The functional relationship between two resources (component instances) is called a service component relationship or a relationship. These concepts are illustrated in Figure 7-1.

Figure 7-1: Service model objects

For example, Calbro Services uses an online banking application that supports its customers’ ability to access accounts and complete transactions. The relationship between these two items—the online banking application and the actual banking service—is part of the service model.


Service model overview

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

Adding CIs and relationships to service models using BMC Atrium CMDB

BMC Atrium CMDB is a possible source for service model objects that are used by BMC Service Impact Manager (BMC SIM) and other BSM applications. Understanding service models in general can help you as you plan, populate, and work in BMC Atrium CMDB. Typically, objects used by BMC SIM are discovered using discovery tools. They are reconciled by the BMC Atrium CMDB Reconciliation Engine, and then automatically published to the BMC Impact Manager by using BMC Impact Publishing Server.

You can also use Atrium Explorer to create relationships between CIs for special cases, such as when you have two CIs that were created manually through Atrium Explorer. You can use this method for creating business assets like business service objects and organization objects.

You can use Atrium Impact Simulator whether you use BMC SIM in your environment or not. The Atrium Impact Simulator predicts the impact on CIs by using the impact relationships that you configure within BMC Atrium CMDB. Atrium Impact Simulator can also use the impact relationships configured with BMC Service Impact Manager.

For more information about service models as used in BMC Service Impact Manager, see the BMC Impact Solutions: Service Model Administrator’s Guide. For more information about Atrium Impact Simulator, see the BMC Atrium CMDB 7.6.04 User's Guide.

Service model componentsTo support a service model that complies with ITIL v3, BMC Atrium CMDB includes several components that combine the utility (what a service does) and warranty (how the service is delivered). Figure 7-2 on page 112 shows a high-level view of these components.



Figure 7-2: Service model components

� Service—Describes functionality that an organization provides. In BMC Atrium Core, the service is a container that includes service and requestable offerings and service level targets.

� Business service—Services available to customers that show the consumer view of services, such as email or an online store.

� Technical service—Supporting IT and infrastructure resources required to support business services that are not visible to customers, such as servers, applications, and network CIs. These technical services can be associated in Atrium Explorer with CI queries.

� Service offering—Defines what service an organization provides and how it is provided that customers can select. All technical and business services must have at least one service offering, but a service can have more than one service offering. Each service offering defines a level of service for a price: it combines the service (utility), a service level target (warranty), and add-on options. You can also associate a service offering with a technical service.

Business Service

Options

.

.

.

CI

Service LevelTarget

Requestable OfferingService Offering

Service LevelTarget

Service Offering

Service LevelTarget

Technical Service

.

.

.

Service Offering

Service LevelTarget

Service Offering

Service LevelTarget

CI

Options

Options

Options

Options

Service LevelTarget

Requestable Offering

Options


Designing a service model

� Requestable offering—Defines what service an organization provides and how it is provided. Unlike a service offering, end users can select a requestable offering. The requestable offerings provide options for how IT implements the service offering. Service offerings do not require a requestable offering but can have one or more. Each requestable offering defines a level of service for a price: it combines the service (utility), a service level target (warranty), and add-on options.

� Service level target—Describes measurements for the performance of a service or offering.

� Options—Describes discrete choices that customers can select. for a service, requestable offering, and transactional offering. Each option has one or more choices, each of which has cost and price information. These options and their choices are available for users to select. They are managed separately from offerings because they do not rely on a specific offering, making the options reusable.

Designing a service modelBuilding a service model can be a daunting task. When you begin the process, it might be helpful to select one critical business process or service, decompose it to identify all aspects of the service, and build a complete service model for that part of your enterprise.

Understanding how the various components of one business service interact helps you construct other pieces of your service model, and helps you understand how services themselves affect each other. For example, you might discover that your payroll service depends on a technical service that provides access to information through the corporate intranet.

Figure 7-3 on page 114 shows an example of a service model with business users, services, and IT structure layers. The lines between the component instances represent impact relationships.



Figure 7-3: Example of a service model

Consider the following factors in determining how to design a service model:

� The diversity of IT resources and how they are monitored

� The location of resources and how the management responsibilities for them are distributed within and among IT groups

� The relative importance of various resources in the delivery of business services

� The need for Change Management

� The maintainability of the service model over time

The service modeling process involves:

� Defining business goals

� Decomposing a business service

� Defining the service model



This overall process is graphically represented in the following diagram.

Best practices

When designing a service model, consider the following best practices:

� Agree on a model blueprint that applies to all service models. The model blueprint acts as a template to the construction of the different service models, and should define a hierarchical organization and the types of CIs that relate to each other. The blueprint should allow some flexibility.

� Define terms and concepts beforehand. To your organization, what is a business process or an IT component? What are your severity and priority levels and what is the meaning of each? You don’t necessarily have to use the ITIL definitions for all these things, but you should have definitions that can guide you and help settle disputes while you design service models.

Defining business goals for the service model

The most basic step involved in defining a service model is defining the specific business goals that you hope to achieve with the model.

To do so, the IT group must engage the business managers in defining short-term, mid-term, and long-term goals for the enterprise. These goals guide the design and development of deliverables for all service model development phases and define the amount of time and effort required for development and implementation.


1 De�ne business goals 2 Decompose a business service 3 De�ne the service model





Some possible goals are:

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

� Business-focused operational efficiency—This type of implementation is likely to involve various populations and centers of management in the enterprise. It consists of a balanced representation of the operational environment, encompassing the IT components, such as systems and applications, and the logical components, such as services, and other business objects.

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

Decomposing a business service

The purpose of decomposing a business service is to identify and document business processes, identify the IT (technical) services that support them, and identify IT components and assets that provide the technical services. Business processes are determined at a high level and can include other processes, such as Marketing and Sales. This document focuses on how business services are impacted and supported by IT.

For example, the online banking division of Calbro Services might identify a business service as the ability of customers to transfer funds, a common service for an online banking company. A technical service that supports this service is the maintenance of the network on which the servers that facilitate the fund transfer communicate. The supporting IT assets are the servers, databases, and related hardware and software systems that facilitate the fund-transfer service.

Figure 7-4 depicts a scenario in which the application server resides on a virtual machine (VM), which, in turn is running on a server capable of hosting several VMs. The system is set up so that, if one VM fails, another VM resumes the process without interruption. The fund-transfer business service depends on everything in the gray box, which IT provides and supports.





Figure 7-4: Example of a business service and the supporting IT assets

The fund-transfer service is only one business service provided by Calbro Services. The service model created by Calbro Services is a collection of service components, each of which represents a business service. Each component can contain several functional applications, each of which can have multiple IT components. A service model shows how the components are interconnected and shows how component failures can impact other services. See Figure 7-3 on page 114.

Best practices

When decomposing a business service, consider the following best practices:

� To find IT services and the components that support them, look at service level agreements and operational level agreements.

� Determine the entry point to each service model, the highest object in the model. The entry point depends on who is consuming the model. Working from here down to the bottom of a service model makes sure that you operate from the perspective of the business.

Identifying business servicesTo identify business services, start by gathering information from such sources as business unit managers, business process managers, and staff personnel knowledgeable about the business services. Company organization charts might be helpful in identifying the relevant people.

The process involves interviewing the managers and identifying the following information:

� Business processes—Identify key business processes such as Market Research, Product Planning, Response Management, or Case Management. There can be multiple levels of business processes, starting with higher level core competencies and business functions, to specific sub-business processes.

� Functional applications—Identify the business applications that support the business processes. Map the business processes to the functional applications.

Map functional applications to service components to create the business service models. See Figure 7-4 for an example of functional applications mapped to a business service.

VMVM

Fundtransfers

VM Host

IT application

on VM

BusinessService



Identifying technical servicesTo identify technical services, consult IT managers and staff. Disaster recovery plans, help desk documents, and purchase orders might be useful in identifying IT components and the business processes that they support.

The process involves identifying the list of IT assets (components). Interview the IT management and staff, or use an asset database or CMDB as resources:

� Create a list of technical services and discover what technical services are offered to business units through use of IT assets. Examples of technical services include customer support and customer call monitoring.

NOTE The Service Catalog component of the BMC Atrium Core Console depicts IT services as Technical Services.

� For each technical service, identify the IT components that support the service.

� Identify the interdependencies among IT components and formulate a topology map. Consider the relationships and dependencies between IT components.

As you build your model, use whatever tools you have to depict the dependencies between business services and technical services. Use graphical and spreadsheet software if you do not have a solution such as BMC Impact Solutions. Table 7-1 shows a portion of a spreadsheet depicting a few business services and their relationships.

Table 7-1: Portion of a sample business service model spreadsheet

Business service Business functions Business processes Technical services

IT component

24/7 online banking

Transfer funds Operational efficiency

Administrative software and hardware

Software applications, application servers, virtual machines, databases

Pay bills

Discount equity services

Execute trades

Manage customer relations

Front office sales Response management

Incident tracking software

Application server

Customer support Support service requests

FTP Server: FTP

Sprint Server: Walrus

Sales Logix Database: SALLOGApplications: Sales LogixUser group: Tech Support deptServers: Antelope



Defining the service model

Defining the service model involves establishing a list of all the IT resources that should be represented in the service model. This information should include:

� Each resource’s name or component identification pattern

� Its location or site

Use this information later in the design phase and when creating service model components.

The first step in developing a service model is to design its logical architecture. To do this, you must analyze the IT environment to:

� Identify the resources that make up the service model.

� Determine the functional relationships and dependencies between various resources that can affect services.

For information about using the Service Catalog in the BMC Atrium Core Console, see the BMC Atrium CMDB 7.6.04 Administrator's Guide. For information about how to create CIs, see the BMC Atrium CMDB 7.6.04 User's Guide.






Chapter

8
Implementing BMC Atrium Core
This section describes the tasks necessary to implement your BMC Atrium Core solution end-to-end, including configuring permissions, bringing data into to BMC Atrium CMDB, and reconciling that data into the production dataset for consuming applications.

NOTE For a video demonstration of the core pieces of this process, see BMC Atrium Core 7.6.03: Taking Your Data Into Production End to End, available on your documentation media.


� Overview of the process to implement BMC Atrium Core (page 122)� Configuring permissions and multitenancy (page 123)� Configuring the Product Catalog (page 127)� Configuring the data model (page 129)� Creating datasets (page 130)� Configuring Atrium Integrator for data import (page 131)� Configuring normalization (page 133)� Configuring reconciliation (page 134)� Creating the service model (page 136)� Importing data to BMC Atrium CMDB (page 138)� Best practices for specific implementation scenarios (page 143)



Overview of the process to implement BMC Atrium Core

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

Some of these steps might not be relevant to your situation, and you can perform some in a different order from that shown in this process.

Step 1 Configure permissions and multitenancy for access to BMC Atrium Core components, to classes and attributes, and to instances.

Step 2 Configure the BMC Atrium Product Catalog and the approved software and hardware.

Step 3 Configure the data model as needed for imported data.

Step 4 Create datasets as needed for imported data.

Step 5 Configure Atrium Integrator for importing data.

Step 6 Configure normalization for system defaults and individual datasets.

Step 7 Configure reconciliation.

Step 8 Create the service model that contains the services IT offers the business, and the IT infrastructure CIs necessary to deliver services.

Step 9 Use discovery tools, Atrium Integrator, and manual tasks to import data into BMC Atrium CMDB.


5 Con�gure 6 Con�gure 7 Con�gure 8 Create the 9 Import data to Atrium Integrator normalization reconciliation service model BMC Atrium CMDB

1 Con�gure permissions 2 Con�gure the 3 Con�gure the 4 Create datasets and multitenancy Product Catalog data model


Configuring permissions and multitenancy


To start the end-to-end process, set up permissions for users who need access to BMC Atrium Core applications. After completing the configuration tasks, verify that the roles and permissions have access to the data as planned.

For more information about configuring permissions, see the BMC Atrium CMDB 7.6.04 Administrator's Guide.

Configuring rolesTo give people access to components of the BMC Atrium Core solution, you must complete the following steps:

Step 1 Open the Group form and create a BMC Remedy AR System regular group for each level of access that you need defined. For example, create a regular group (CMDBAdmin) to use for all your BMC Atrium Core administrators. You can also reuse regular groups that you have previously created.

� For general information about working with groups, see the BMC Remedy Action Request System 7.6.04 Form and Application Objects Guide.

� For detailed information about groups in the BMC Atrium Core solution, see the BMC Atrium CMDB 7.6.04 Administrator's Guide.

Step 2 Append your regular group to a computed group (for example, CMDB Console Admin Group).

For example, your Group Definition would now read:

"Administrator" OR "CMDBAdmin"

Step 3 (optional) Open the Roles form and map a group that you created in step 1 to the Production state of the BMC Atrium Core roles that you want associated with that group.

Many roles already have groups mapped to them. For example, the CMDB Console Admin role is mapped out-of-the-box to the CMDB Console Admin Group in the Production state.

NOTE If a group is already mapped to the role, add your group to that computed group instead of modifying the mapping.






� For general information about working with roles, see the BMC Remedy Action Request System 7.6.04 Form and Application Objects Guide.

� For detailed information about roles in the BMC Atrium Core solution, see the BMC Atrium CMDB 7.6.04 Administrator's Guide.

Step 4 Open the Users form and create BMC Remedy AR System users. In the Group List field, select the regular groups associated with the access permissions needed by each user.

NOTE You cannot choose a computed group from the Group List field when creating a user. This is why you had to create a regular group and then add it to the group definition of the computed group.

For information about the BMC Remedy AR System license types to grant users of BMC Atrium Core, see the BMC Atrium CMDB 7.6.04 Administrator's Guide. For information about creating users, see the BMC Remedy Action Request System 7.6.04 Configuration Guide.

Configuring class and attribute permissionsAssign groups and roles with the following permissions on each class or attribute.

WARNING Do not use BMC Remedy Developer Studio to change permissions on the class forms and attribute fields. These permissions are overwritten the next time a change is made to the class with the Class Manager.

Specify the following class permissions from the Permissions tab when viewing a class (in the Class dialog box) from the Class Manager:

� Hidden—Members of these groups and roles can access the class through workflow, but cannot see its instances in the Atrium Explorer or open its form.

� Visible—Members of these groups and roles can see and access the class in all ways: instances in the Atrium Explorer, the class form, and through workflow.

Specify the following attribute permissions from the Permissions tab when viewing an attribute (in the Attributes dialog box) from the Class Manager:

� View—Members of these groups and roles can view the attribute in the class form, but cannot modify its value.

� Change—Members of these groups and roles can view and modify the attribute value.

You can also specify that a user without Change permissions can set the attribute’s value when creating an instance. To do so, select the Allow Any User to Submit option.

For more information about class and attribute permissions, see the BMC Atrium CMDB 7.6.04 Administrator's Guide.



In version 7.6.04, the Normalization Engine can now normalize attribute permissions. For instructions on configuring this, see the BMC Atrium CMDB 7.6.04 Normalization and Reconciliation Guide.

Configuring instance permissionsIn addition to the CMDB Data View and CMDB Data Change roles, you can control access to contents of instances with the following attributes:

� CMDBRowLevelSecurity—Users who are members of a group with row-level access have permission to view the instance if they also have the BMC Atrium Core CMDB Data View or BMC Atrium CoreCMDB Data Change role.

� CMDBWriteSecurity—Users who are members of a group with write access have permission to modify the instance if they also have row-level access and the BMC Atrium Core CMDB Data Viewer role. This permission is useful for giving someone write access to a specific instance without giving write access to all instances with one of the BMC Atrium CoreCMDB Data Change roles.

To set permissions for an instance, when creating or modifying an instance, set the value of the CMDBRowLevelSecurity or CMDBWriteSecurity attribute to a group name or list of group names.

With default instance permissions, you can also define the BMC Atrium CoreCMDBRowLevelSecurity and BMC Atrium CoreCMDBWriteSecurity values for an entire class instead of specifying them every time you create an instance of the class. To set default permissions for a class, use the BMC.CORE.CONFIG:BMC_DefaultAccountPermissions form to assign groups to the ASSIGNRowLevelSecurity and the ASSIGNWriteSecurity fields.

For more information about configuring instance permissions and examples, see the BMC Atrium CMDB 7.6.04 Administrator's Guide.

In version 7.6.04, the Normalization Engine can now normalize instance permissions. For instructions on configuring this, see the BMC Atrium CMDB 7.6.04 Normalization and Reconciliation Guide.

Configuring multitenancyThis section describes the high-level steps to configure multitenancy. You can apply these steps to configure multitenancy in multiple ways, including:

� Using BMC Remedy ITSM, as described in the BMC Remedy IT Service Management 7.5 Guide to Multi-Tenancy.

� Using the Product Catalog, as described in the BMC Atrium Core 7.6.04 Product Catalog and DML Guide.

To configure multitenancy, complete the following high-level steps. For detailed information about configuring multitenancy, see the BMC Atrium CMDB 7.6.04 Administrator's Guide.



Step 1 Select the tenancy mode.

Step 2 Configure companies to represent the business units of your organization.

Step 3 Configure access for people.

Selecting the tenancy modeThe value that you select in the Tenancy Mode field on the System Settings form determines whether the Company field on various forms defaults to a single company or whether users must always select the appropriate company for the field. BMC Remedy ITSM is installed with the Tenancy Mode field set to Multitenancy. If you have changed this field to single-tenancy mode, you must change the value back to Multitenancy. For information about changing this setting, see BMC Remedy IT Service Management 7.5 Guide to Multi-Tenancy.

NOTE In BMC Atrium CMDB, the multitenancy feature is always available. Regardless of the Tenancy Mode setting, data is segregated by company and access to data is controlled by a user’s access to a company.

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

Configuring access for peopleUse the People form to grant people access to business units. Calbro Services uses the People form to grant access as follows:

� Patrick Paycheck is granted access to Finance.

� Betty Benefits is granted access to HR.

� Steve Server is granted access to all applications, including those used by Finance and HR.


Configuring the Product Catalog

Configuring the Product Catalog

To set up the Product Catalog, complete the following procedures. For more information about Product Catalog concepts, see “Product Catalog” on page 98.

Step 1 Create Product Catalog entries.

To normalize CIs, you must have product entries in the Product Catalog. Import or create these products as needed.

Step 2 (optional) Configure the best-practice categorizations.

Step 3 Approve products, versions, and patches for your organization.

You must approve products so that the Normalization Engine can normalize CIs.

Creating Product Catalog entriesYou can add products to the Product Catalog in the following ways:

� Import data from external files—You can import data from an external file or from staging forms by using a browser. For more information, see the BMC Atrium Core 7.6.04 Product Catalog and DML Guide.

� Create entries manually from the Product Catalog Console. For more information, see the BMC Atrium Core 7.6.04 Product Catalog and DML Guide.

� Use the Normalization Engine to create entries—If you have a dataset that is trusted and contains CIs that were normalized before being imported, you can configure the Normalization Engine to create Product Catalog entries from the dataset. You must configure this option before normalizing the dataset. For detailed instructions about creating Product Catalog entries, see the BMC Atrium CMDB 7.6.04 Normalization and Reconciliation Guide.

TIP The Normalization Engine is mainly for normalizing CIs, not populating the Product Catalog with product entries. Because this option is set for a dataset, all CIs in that dataset must be previously normalized by some other method before you run a Normalization Engine job with this option enabled. Otherwise, you could create non-normalized Product Catalog entries and result in duplicate entries for the same product.






If you acquire duplicates in the Product Catalog, you must manually remove them. A clue that indicates you have duplicates is that not all CIs for a specific product have the same Name, ManufacturerName, Model, PatchNumber, VersionNumber, Category, Type, and Item values.

Configuring best-practice categorizationsProduct categorization is defined in the BMC Atrium Product Catalog and with BMC Atrium Discovery and Dependency Mapping. If you already use BMC Atrium Discovery and Dependency Mapping—which applies some of the best-practice categorizations and some others—or you already use the default, or legacy, categorizations with BMC BladeLogic Client Automation Configuration Discovery Integration for CMDB, continue to use those categorizations. Otherwise, you should implement the best-practice categorizations.

Best practice

Implement the best-practice categorizations using the following methods:

� Use the BMC Remedy ITSM Data Wizard

� Select categorizations during the installation of BMC BladeLogic Client Automation Configuration Discovery Integration for CMDB

Changing categorizations with the BMC Remedy ITSM Data WizardTo configure the Product Catalog and BMC Remedy ITSM to use the best-practice categorizations, use the BMC Remedy ITSM Data Wizard, which is installed when at least one BMC Remedy IT Service Management application is installed.

WARNING Before using the data wizard, back up your database.

To maintain data integrity while modifying the categorizations, disable escalations, reconciliation jobs, discovery products, and the Distributed Server Option (DSO) of BMC Remedy AR System. When you have completed modifying the product categorizations, you can restart these components.

From the BMC Remedy ITSM Data Wizard, select to modify the product categorization and map the current categorization values in the target fields and the best-practice categorizations in the new value fields.

For more information about using the ITSM Data Wizard, see the BMC Remedy IT Service Management 7.6.04 Data Management Administrators’s Guide.


Configuring the data model

Selecting categorizations during installation of BMC BladeLogic Client Automation Configuration Discovery Integration for CMDBWhen you install BMC BladeLogic Client Automation Configuration Discovery Integration for CMDB, select either the default categorization or the best-practice categorization. The selected categorization is stored in a local XML file.

When BMC BladeLogic Client Automation discovers a CI, it tries to find a match in the BMC Atrium Product Catalog. If it finds a match, it applies the Product Catalog values of the Model, ManufacturerName, Model, Category, and Item attributes. If it does not find a match in the Product Catalog, it tries to find a match in the XML file selected at installation, and applies those categorization values to the CI.

Approving products, versions, and patchesAs a part of managing your products, approving products in the Product Catalog is important for normalizing products. By default, the Normalization Engine does not update or allow the creation of unapproved CIs, and all products in the Product Catalog are unapproved by default. If you allow normalization of unapproved CIs, the Normalization Engine sets the NormalizationStatus attribute for such CIs to Normalized Not Approved.

For information about approving products versions and patches, see the BMC Atrium Core 7.6.04 Product Catalog and DML Guide.

Configuring the data model

This section aligns with Stage 4, Step 23, “Task 2. Configure the CMDB,” of the Step-by-Step Guide to Building a CMDB.

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






The Common Data Model includes classes that describe a wide variety of IT configuration items and their relationships, and some BMC Software products install extensions that add more classes and attributes to the data model. But there are still some IT infrastructures that do not completely map to this model.

If the classes and attributes that you require are not defined by the BMC Atrium CMDB data model or the extensions, modify the data model.

For detailed information about what to consider before modifying the data model, see “Planning to extend the data model” on page 61.

Creating datasets

Creating datasets in BMC Atrium CMDB to store data provided by different data providers is the first step when importing data. A dataset is a logical grouping of data. It can represent data from a particular source, a snapshot from a particular date, or other purpose.

Make sure that each data provider has its own import dataset.

Also, note which dataset is your production, or golden, dataset so that you can plan your normalization and reconciliation jobs. By default, the BMC.ASSET dataset is the production dataset. In reconciliation, the production dataset is used first to identify duplicate CIs, matching attributes for the CI in the production dataset with the CIs in the imported datasets. Second, it can be the target dataset in a Merge activity so that the CIs are updated to keep the production dataset current and accurate. Also, do not normalize the production dataset because you should normalize CIs before identifying and merging them.

When you need to merge more than one dataset at time, you might want to create an intermediate dataset for merging. For better performance and to minimize the impact on users of the production dataset, BMC recommends that you merge one import or discovered dataset at a time with the production dataset. You might want to merge multiple source datasets in separate jobs to an intermediate dataset and then merge the intermediate dataset with the production dataset.

For more information about planning your datasets, see “Grouping CIs into datasets” on page 79.

For detailed instructions about creating a dataset, see the BMC Atrium CMDB 7.6.04 Normalization and Reconciliation Guide.





Configuring Atrium Integrator for data import

Configuring Atrium Integrator for data import

Using Atrium Integrator to import data into BMC Atrium CMDB from a third-party source consists of the following tasks:

Step 1 Configure source and target connection.

Step 2 Create a job or transformation.

Step 3 Edit your transformation or job.

TIP To create an integration job, use the Integration Job Builder wizard which automatically populates data and includes templates for typical integrations.

Best practices

When configuring Atrium Integrator, consider the following best practices:

� Transform your data on the way in so that all sources (BMC and third-party) are normalized for commonly used attributes like Domain and those related to memory and disk size.

For example, DriveSize for BMC_Media should be specified in GB. For more information about attributes, see BMC Atrium CMDB 7.6.04 Data Model Help and Class Manager.

� Provide data to help reconciliation by ensuring that CI attributes used for identification have unique values and are populated consistently.

� If you need to customize the data mappings in an integration job, familiarize yourself with the Common Data Model so that you can select the appropriate classes and attributes. You can also verify that data types match for the data mappings and plan unique identifying fields.

� Consider bringing in data by chunks and designating separate BMC Atrium Integration Engine instances for such activity so that, if you have a large amount of data to import, you can spread the import work across multiple instances.






� Do not run more than one Atrium Integrator, Normalization Engine, or Reconciliation Engine job at the same time because they might query or update the same data.

� Map the attributes that the Normalization Engine uses to normalize CIs: Name, ManufacturerName, Model, PatchNumber, and VersionNumber. If you do not map these attributes, then the Normalization Engine cannot normalize the CIs.

Configuring source and target connectionsYou must define connection parameters (such as host name, port number, user name, and password) to your external data store and BMC Atrium CMDB. After you create a connection, you can reuse it for multiple transformations or jobs.

For instructions about creating datastore connections, see the Atrium Integrator 7.6.04 User's Guide.

Creating jobsUse the Integration Builder wizard to create a job or transformation.After you specify the source and the CIs that you want to import, the wizard makes recommendations on the relationships for the selected CIs.

For detailed instructions about creating jobs, see the Atrium Integrator 7.6.04 User's Guide.

Editing transformationsYou can add intermediate steps for cleaning up or manipulating your data before adding it to BMC Atrium CMDB. Spoon provides support for JavaScript and a wide variety of prebuilt functions.

For detailed instructions about editing transformations, see the Atrium Integrator 7.6.04 User's Guide.


Configuring normalization

Configuring normalization

To configure normalization, complete the following procedures. For more information about normalization, see “Normalization” on page 97. For detailed instructions about these procedures, see the BMC Atrium CMDB 7.6.04 Normalization and Reconciliation Guide.

Step 1 Configure the normalization settings for datasets, including disabling any Normalization Features (enabled by default) that should not run.

Define custom rules where needed, such as for Version Rollup or permissions. You might need to configure other dataset parameters according to best practices. See “Best practices for specific implementation scenarios” on page 143.

Step 2 If you have created custom classes, you must add and configure them for normalization.

Normalization is not supported for classes that are not derived from BMC_BaseElement.

Step 3 If you know that the product or manufacturer names for CIs in your dataset do not match those in the Product Catalog, map the incorrect names to the correct ones with the Product Name Alias form.

Step 4 Create categorization aliases with Catalog Mapping for the following conditions:

� If the combination of the values of the Name, ManufacturerName, Model, Category, Type, and Item attributes is not in the Product Catalog data.

� If the combination of values is in the Product Catalog but is not related to the company for whom the CI is being submitted.

Step 5 Create a job, and specify when the job runs (continuous or batch).

WARNING Do not run more than one Atrium Integrator, Normalization Engine, or Reconciliation Engine job at the same time. This could cause problems such as multiple jobs querying or updating the same data.






Configuring reconciliation

This section aligns with Stage 4, Step 23, “Task 4. Code data import scripts and reconciliation rules,” of the Step-by-Step Guide to Building a CMDB. To configure reconciliation, complete the following procedures. For detailed instructions, see the BMC Atrium CMDB 7.6.04 Normalization and Reconciliation Guide.

Step 1 Verify standard Identify rules.

� Check that the attributes used for identification have unique and consistent values in the dataset to be reconciled.

� If you created custom classes, add them to the standard Identify rules.

Step 2 Verify standard Merge rules.

� Check that the dataset has the needed precedence value. By default, new datasets have a precedence of 100.

� If you created custom classes and attributes, add them to standard Merge rules.

Step 3 Create a standard identification and merge job.

If needed, you can customize a Standard Identification & Merge job:

� Include a qualification.

� Change Continue on Error and Sequence for the activity.

� Change identification settings for Production Dataset, Generate IDs, and Exclude Subclasses.

� Change merge settings for the Source Dataset, Target Dataset, Precedence Association Set, Include Unchanged CIs, and Merge Order.

To customize the Identify and Merge rules, see if you can modify the standard rules. If modifying the standard rules is not possible, you can create a custom reconciliation job with custom rules as needed.

Step 4 Specify when the job runs, either with a schedule or by using continuous mode.





Configuring reconciliation

WARNING Do not run more than one Atrium Integrator, Normalization Engine, or Reconciliation Engine job at the same time. This could cause problems such as multiple jobs querying or updating the same data.

Best practices

When you configure reconciliation, consider the following best practices:

� Use a Standard Identification & Merge Job if possible.

� Test with a small amount of representative data by using a qualification.

� Do not run during prime (heavy use) hours.

� Consider indexing attributes used in Identify rules. Consult your database administrator to determine what indexes would help you.

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

� After the initial data load into BMC Atrium CMDB, perform an Identify activity on the data, selecting the option to auto-identify the master dataset. This makes sure that your production data has an identity the first time it is identified against another dataset.

� Take advantage of Reconciliation Engine multithreading by breaking up large jobs into smaller ones and running them concurrently, but limit your number of concurrent threads to twice the number of CPUs in the server.

� To avoid redundant processing, make all Merge activities incremental by setting Force Attribute Merge to No.

� To improve performance, define a private queue on the BMC Remedy AR System server for use only by the Reconciliation Engine. Make sure you use RPC socket 390698 or 390699.

� Reconcile discovered data into your production dataset immediately after your discovery application loads data into BMC Atrium CMDB.

� Do not create multiple jobs that merge data into the same target dataset, because this creates the potential for one job to overwrite data that you want to keep. To split a merge into multiple jobs, do it by classes so that the two jobs do not touch the same parts of your data.

� Regularly review your Identify rules to make sure that they are still appropriate for your environment, and spot-check instances to confirm that they are being identified properly.

� Instead of merging multiple discovery sources directly into your production dataset, merge them into a “consolidated discovery” dataset first. You can compare this against your production dataset and use the results to generate change requests or exception reports for any discrepancies.



Creating the service model

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

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

Whether you have implemented BMC Impact Solutions in your environment or not, Atrium Impact Simulator and the Service Catalog offer additional ways to use your service model.





Creating the service model

Deciding on the structure of the service modelHow you organize service model components depends on the goals that your organization wants to attain through Service Impact Management, so determine those goals first. You can organize your service model components by using one of these basic organizational strategies:

� The business continuity and service availability strategy implements a business-centric model in which business processes and services rely on a small number of vital IT components to give a status overview of the underlying environment. This type of implementation is driven from the top, ensuring that IT is delivering their services as agreed. The driving force is business continuity and availability. This strategy is similar to the BMC Software BSM strategy that is called a Business Service Impact Model.

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

� The IT resource management strategy creates a thin layer of logical groupings on top of a large number of IT resources, ranging from applications and systems to hard disks and other hardware components. This type of implementation is run by and for the IT group. Services are just logical groupings that provide a convenient way of classifying the technical resources. The driving force behind this model is operational efficiency.

Although these strategies are only briefly outlined here, they are helpful in understanding that each implementation probably has a different focus, favoring some types of components and having more or less granularity in some branches of the component hierarchy. The strategy that you choose also affects the amount of time and effort required for its development and implementation.

For more information about service models as used in BMC Service Impact Manager, see the BMC Impact Solutions: Service Model Administrator’s Guide. For more information about Atrium Impact Simulator, see the BMC Atrium CMDB 7.6.04 User's Guide. For more information about the Service Catalog, see the BMC Atrium CMDB 7.6.04 Administrator's Guide.

Maintain your service model dynamicallyBMC Atrium CMDB has a dynamic service modeling feature that can automatically relate technical services in your Service Catalog to infrastructure CIs, such as computer systems, that support them. BMC recommends that you take advantage of this feature to enable you to better manage your services.

For instructions on configuring dynamic service modeling, see the BMC Atrium CMDB 7.6.04 Administrator's Guide.



Importing data to BMC Atrium CMDB

Populating BMC Atrium CMDB includes activities such as importing and filtering data and verifying that each data import is successful. To import data into BMC Atrium CMDB, complete the following procedures:

Step 1 Create tests to validate your data population.

Step 2 Bring data into BMC Atrium CMDB using BMC Software discovery products.

Step 3 Import data using Atrium Integrator.

Step 4 Add data manually.

Step 5 Validate the results of your data imports.

Step 6 Remove failed-import data from BMC Atrium CMDB.

Step 7 Normalize BMC Atrium CMDB data.

Step 8 Reconcile BMC Atrium CMDB data.

Best practices

As you prepare to migrate data from existing sources to BMC Atrium CMDB, consider these best-practice recommendations:

� Examine your data to make sure that data exists in each category of your current classification scheme that is being mapped to a class in BMC Atrium CMDB. Do not waste resources attempting to migrate something that does not exist.

� Freeze your current classification scheme a few weeks prior to the migration.

� Test the migration with a representative subset of all the classes you plan to use. For example, import 1,000 computer systems and 1,000 application systems.

� When testing, verify both that the contents of several CIs were migrated correctly and that the correct number of CIs were migrated for each class.

� For better performance, take advantage of the multithreaded nature of the BMC Remedy AR System server when loading your initial data into BMC Atrium CMDB. Either use a multithreaded process on your loading application or split the data into pieces that can be loaded by separate instances of your application.

� If your loading application will do any searching, create indexes on the fields it searches.






� An easy way to load data from many sources is to create BMC Remedy AR System view forms or vendor forms that point to those sources. You can then use workflow, such as an escalation, to transfer the data from those forms to the BMC Atrium CMDB forms.

� When importing data from a source such as a spreadsheet or comma-separated value file, you can use a regular BMC Remedy AR System form as an intermediate storage location. This enables you to use qualifications and workflow to verify that the data made it into the BMC Remedy AR System, normalize the text in your data, and route it to the appropriate BMC Atrium CMDB class.

� If your source data does not include relationships or includes them only as foreign keys on CI records, your loading application should analyze the data and create relationships between appropriate CIs in BMC Atrium CMDB.

� Your loading application is responsible for normalizing text in the data you bring into BMC Atrium CMDB, such as enforcing capitalization and delimiting rules. Data that has not been normalized is much harder to reconcile.

Creating test cases to validate data population

This section aligns with Stage 4, Step 23, “Task 1. Create use cases to validate data population,” of the Step-by-Step Guide to Building a CMDB.

As you prepare to import data into BMC Atrium CMDB, create test cases to verify that the data is being imported successfully. Specifically, test unidirectional and bidirectional data transfers to make sure that the synchronization and import processes between the external data store and BMC Atrium CMDB are working correctly.

You should also test the end-to-end run time of import, normalization, and reconciliation using a small amount of representative data. This enables you to plan your time windows so that these activities don’t overlap in either your initial bulk load or subsequent updates.

Examples of test cases that you can use include the following scenarios:

� Creation of new CIs with related attributes and relationships

� Creation of relationships for existing CIs

� Modification of CI attributes and relationships

� Data reconciliation and merging

� Deletion of any combination of CI attributes and relationships

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



Importing data using Atrium Integrator

This section aligns with Stage 4, Step 23, “Task 5. Perform data import,” of the Step-by-Step Guide to Building a CMDB.

You have already configured your job and transformation as described in “Configuring Atrium Integrator for data import” on page 131. At this point in the end-to-end process, run your jobs and bring the associated data into BMC Atrium CMDB.

For detailed instructions about running jobs, see the Atrium Integrator 7.6.04 User's Guide.

Adding data manually

This section aligns with Stage 4, Step 23, “Task 9, Input additional data manually,” of the Step-by-Step Guide to Building a CMDB. Although you are discovering CIs and their attributes automatically through discovery, you might need to manually enter additional data in the following situations:

� You want to add CIs that are not discovered. Some functions of BMC Remedy Asset Management, such as creating a purchase requisition, create a CI, even if the CI might later be discovered.

� You want to update CIs with attributes that are not discovered.

� You must manually add business services that are used in the Service Catalog.

� You want to create relationships that are not discovered.

� You want to enter additional Asset Management information.

Do not edit CIs directly in the BMC.ASSET dataset. Instead, use Atrium Explorer and the sandbox dataset to add and modify CIs and relationships. This makes sure that edits are reconciled and the production dataset accurately represents your environment. These changes are ultimately used by consumers such as BMC Remedy Asset Management.

Adding CIs to BMC Atrium CMDB manuallySome CIs are not discovered, so plan to enter some CIs manually. Without planning, ad hoc entry of CIs can lead to inconsistency in your CMDB. If the CIs are not discovered, reconciliation with discovered CIs is not an issue.

For instructions about manually entering CIs, see the BMC Atrium CMDB 7.6.04 User's Guide.



Updating CIs with attributesTo maintain CI attributes that are not discovered, such as asset lifecycle dates or cost, you can also enter them manually. You can also manually update attributes that are populated by discovery. For example, if a video card is being repaired, you might want to change the status from Deployed to In Repair.

If you manually update attributes that are populated by discovery, these attributes might get reset during reconciliation, based on precedence rules. Because the BMC Asset dataset is the production dataset, changes made to this dataset take precedence over attributes that are discovered.

For instructions about manually updating attributes on CIs, see the BMC Atrium CMDB 7.6.04 User's Guide.

Adding relationship information that is not discoveredYou might want to create relationships that are not discovered, such as people and support groups responsible for an asset or relationships of business services.

For instructions about manually entering relationship information, see the BMC Atrium CMDB 7.6.04 User's Guide.

Validating data import results

This section aligns with Stage 4, Step 23, “Task 6. Validating import results,” of the Step-by-Step Guide to Building a CMDB.

Follow the test cases that you created in “Creating test cases to validate data population” on page 139 to verify that your data has been imported correctly.

Use the Atrium Integrator job monitoring console to confirm whether a data transfer has finished successfully. You can also check log files. By default, the generation of debug logs for Atrium Integrator data transfers is enabled. On Windows, the log files are stored in the installationDirectory\server\data-integration\bin\error\jobName_TranformationName_Error.txt

For more information about logging, debugging, and job monitoring, see the Atrium Integrator 7.6.04 User's Guide.

Removing failed-import data from BMC Atrium CMDB

This section aligns with Stage 4, Step 23, “Task 7. Removing failed import data from the CMDB,” of the Step-by-Step Guide to Building a CMDB.

If your test cases detected a problem with a data transfer, remove the erroneous data from the BMC.IMPORT.CONFIG dataset or the BMC.ADDM dataset.



Normalizing BMC Atrium CMDB dataNormalize your data to resolve the differences in naming and typing ahead of reconciliation. For more information about the Normalization Engine, see “Normalization” on page 97 and the BMC Atrium CMDB 7.6.04 Normalization and Reconciliation Guide.

Reconciling BMC Atrium CMDB dataReconcile your BMC Atrium CMDB data to compare expected data against discovered data, and to create one complete and correct production dataset.

Reconciliation must begin by identifying the matching instances in all datasets. After they have been identified, you can perform several activities on the matching instances, but the most common are:

� Comparing them and either creating a report on the differences or executing workflow against them

� Merging them into a new dataset based on precedence values that you have defined for each source dataset

For details about reconciliation activities, see the BMC Atrium CMDB 7.6.04 Normalization and Reconciliation Guide.

How Calbro Services discovers their IT environment and imports dataIn the process of consolidating their IT departments, Calbro Services plans to populate BMC Atrium CMDB with the data from the various IT departments. Some IT data resides in spreadsheets or in databases. In some cases, data must be discovered. This disparate data from various IT departments must be moved to BMC Atrium CMDB so that Calbro Services has a complete picture of the components in its IT department.

Calbro Services has some existing data in flat files in CSV format. The data in these files will be transferred to BMC Atrium CMDB with Atrium Integrator.

The remaining data will be discovered with BMC discovery tools.

� Calbro Services will use BMC BladeLogic Client Automation to discover hardware and software inventory information about servers, desktops, laptops, and handheld devices. Calbro Services will then use BMC BladeLogic Client Automation Configuration Discovery Integration for CMDB to map the collected information and transfer the CIs and their relationships to BMC Atrium CMDB.

� Calbro Services will use BMC Atrium Discovery and Dependency Mapping to build a topology of applications and infrastructure including switches, servers, operating systems, software, configuration files and logs, business applications and dependencies. Calbro Services will then use the CMDB Sync function of BMC Atrium Discovery and Dependency Mapping to map the collected information and transfer the CIs and their relationships to BMC Atrium CMDB.


Best practices for specific implementation scenarios


For specific scenarios, BMC recommends particular settings for Atrium Integrator, Product Catalog, Normalization Engine, and Reconciliation Engine.

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

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

Component Tasks

Atrium Integrator � When transferring a large amount of data, use parallel processing with a different Atrium Integrator instance per exchange.

� For an attribute that is used as a primary key or as a relationship key, create a separate index in BMC_BaseElement.

� Database/External Data Store can have an index on the column that is the Primary Key.

� Check the log files and confirm that there are no errors, especially data errors.

Product Catalog Verify that Product Catalog data is current and accurate.



Best practices for incremental loadsAfter you have loaded initial data, use the following guidelines to normalize and reconcile changes to the data.

Normalization Engine � Turn on normalization across all datasets into which you are loading bulk data.

� Create a batch normalization job.Use the batch job after the data is loaded into the import dataset. Then, use the reconciliation batch job to merge the normalized data to a different dataset.

� Do not modify the default dataset configurations.

Note: Do not enable the Allow new Product Catalog entry parameter because it could result in duplicate entries for the same product.

� Do not allow an installer to start normalization jobs because the standard reconciliation Identify and Merge rules are not sufficient to reconcile only normalized CIs.

Reconciliation Engine Create a batch reconciliation job.After the import dataset has been normalized, use the batch reconciliation job to merge the normalized data to a different dataset.

Table 8-1: Best practices for bulk loads

Component Tasks

Table 8-2: Best practices for incremental loads

Component Tasks

Atrium Integrator Check the log files and confirm that there are no errors, especially data errors.


Normalization Engine � Turn on normalization across all datasets into which you are loading bulk data.

� Create a continuous normalization job to normalize changes and additions to the import dataset.

� Do not modify the default dataset configurations.

Note: Do not enable the Allow new Product Catalog entry parameter because it could result in duplicate entries for the same product.

Reconciliation Engine Create a continuous reconciliation job.After the initial reconciliation, the continuous job identifies and merges new and changed CIs in the import dataset.



Best practices for Atrium Explorer editsWhen modifying CIs in Atrium Explorer, use the following guidelines. When you promote a CI, it is reconciled using a standard Identify and Merge job. Table 8-3: Best practices for Atrium Explorer edits

Component Tasks

Atrium Integrator Not applicable


Normalization Engine � Verify that Catalog Mapping aliases are current and accurate.� If normalization is turned off across all datasets, do not turn

on normalization.� Configure the normalization settings for the dataset where the

manual edits are made:� Normalization Type: Name & CTI lookup� Inline Normalization: Enabled� Allow Unapproved CI: Disabled� Allow new Product Catalog entry: DisabledIn the edit form that appears in a failed normalization, you must know which attributes are required and what values are valid.

� If the Product Catalog has no entries for hardware or other classes, disable normalization for those classes by deleting them from the Class Configuration tab in the Configuration Editor. You can add the class later, if needed.

Reconciliation Engine Create a reconciliation job for the specific user sandbox to start manually; do not create a schedule or select Continuous for the job.



Best practices for BMC Remedy ITSM manual editsWhen modifying CIs from the BMC Remedy IT Service Management suite, use the following guidelines. Table 8-4: Best practices for BMC Remedy ITSM manual edits

Component Tasks

Atrium Integrator Not applicable


Normalization Engine Configure the normalization settings for the specific user sandbox where the manual edits are made:� Normalization Type: Name & CTI lookup� Inline Normalization: Enabled� Allow Unapproved CI: Disabled� Allow new Product Catalog entry: Disabled

Reconciliation Engine You can use the existing reconciliation job for the BMC Remedy ITSM sandbox.


Chapter

9
Managing BMC Atrium Core
This section describes the administrative tasks that help you manage your implemented BMC Atrium Core solution.


� Tracking changes to CIs and relationships (page 148)� Deleting CIs that are no longer discovered (page 157)� Custom workflow (page 157)



Tracking changes to CIs and relationshipsBMC Atrium CMDB takes advantage of the auditing feature of BMC Remedy AR System to track changes to instance data. You enable BMC Atrium CMDB auditing on a per-class basis, and you select which attributes trigger an audit and which are written as a result.

An audit is triggered when an instance is created or deleted or when the value of one or more selected attributes changes as the result of an instance being modified.

You can view audit results from the View History link on the BMC Atrium Core Console. For instructions about viewing instance history, see the BMC Atrium CMDB 7.6.04 User's Guide.

Auditing versus the Compare Dataset activityAuditing is not the only way to track changes to CIs and relationships. If you use BMC Remedy Asset Management with your CMDB, you could instead track changes with the Compare Dataset reconciliation activity.

You must have the Sandbox dataset (BMC.ASSET.SANDBOX) enabled in BMC Remedy Asset Management, so that user edits to a CI are saved to the Sandbox dataset. Then you can create a reconciliation job with a Compare Dataset activity that compares the Sandbox to BMC Asset, looking for the particular differences that you want to catch. You could then perform custom workflow against instances found by the comparison.

Best practices

Keep these considerations in mind when deciding which method to use for tracking the changes to your CIs and relationships:

� Audits give you access to information about changes to your data as soon as they happen, whereas comparisons are usually run daily.

� Audits take a small amount of processor and disk time at the moment a change occurs, slightly slowing down real-time performance for users, whereas comparisons concentrate that performance hit during a non-peak window.

� If you have auditing enabled on your production dataset, it can increase the time required for reconciliation because Merge activities that write to the dataset trigger audits.

� Audits provide a better long-term view of the history of a CI than do comparisons.

� Comparisons are better when you need to track changes to multiple attributes because this has a larger performance cost, and the cost can be absorbed during a non-peak window.

� Comparisons provide flexibility in executing workflow when a change occurs.

Given these considerations, audits are usually better for keeping a history, and comparisons are better for alerting you to changes that require investigation.


Tracking changes to CIs and relationships

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

You cannot use Log auditing above Copy auditing in the inheritance tree. This means that if you already have Copy auditing enabled for a class you cannot enable Log auditing for any of its superclasses, and if you already have Log auditing enabled for a class you cannot enable Copy auditing for any of its subclasses. This is due to the structure of audit forms.

Best practices

Keep these considerations in mind when deciding whether to use Copy or Log auditing:

� Copy audits degrade performance more than Log audits because their structure matches that of the actual BMC Atrium CMDB class forms, which use database joins. Also, because those join forms must be created when Copy auditing is enabled, there is a bigger performance cost at that time and possibly more disruption related to your change control procedure.

� Copy audits provide a more powerful search capability than Log audits because you can search on each attribute in a separate field.

Copy auditingCopy auditing creates a copy of each audited instance. When you enable Copy auditing for a class, each form pertaining to that class is duplicated to create audit forms that hold audited instances. This includes forms from superclasses, because they hold data for instances of their subclasses. The audit forms are automatically named with the suffix :AUDIT. For example, if you enable auditing for the BMC_Person class, which is a subclass of the BMC_BaseElement class, three audit forms are created:

The audit forms have the same BMC Remedy AR System permissions as the class itself. If you make a change to a class after these forms have been created, they are automatically updated to match. When you delete a class, its associated audit forms are also deleted.

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

The audit form mirrors the class form, containing a field for each attribute in the class. When an audit occurs, values for the selected attributes are written to their respective fields, creating a new copy of the instance.

Table 9-1: Audit forms created for BMC_Person

Form type Class form Audit form

Regular BMC.CORE:BMC_BaseElement BMC.CORE:BMC_BaseElement:AUDIT

Regular BMC.CORE:BMC_Person_ BMC.CORE:BMC_Person_:AUDIT

Join BMC.CORE:BMC_Person BMC.CORE:BMC_Person:AUDIT



In addition to the class attribute fields, each audit form also includes the following 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_fieldId_C, using the field ID of the attribute on its class form.

Copy attributes and None attributes do not have Fields Changed fields in the audit form because they cannot trigger an audit.

� Audit 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 9-2 lists the possible values and their meanings:

When an audit is triggered, the audited instance is copied from each class form to the corresponding audit form.

NOTE When auditing is enabled for a class, audits can be triggered by instances of either the class or its subclasses, even if auditing is not enabled for the subclasses. This is due to the hierarchical structure of class forms. When an audit is triggered by an instance of a subclass, only the attributes of the audit-enabled superclass are written to the audit form. You can avoid subclass instances triggering an audit by using an audit qualification that matches the class ID of the superclass.

Copy auditing in BMC Atrium CMDB is implemented using BMC Remedy AR System form-style auditing. For more information about form-style auditing, see the BMC Remedy Action Request System 7.6.04 Form and Application Objects Guide.

Log auditingLog 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.

Table 9-2: Audit actions

Action field value Instance action

2 Modify

4 Create

8 Delete

16 Merge



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 following 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 9-2 on page 150 lists the possible values and their meanings.

When an audit is triggered, an entry is created in the log form. For information about selecting attributes to write to the Log field, see “Setting the Audit option for attributes” on page 152.

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

How Calbro Services uses auditingThe Calbro Services administrator knows that changes to the service model can be disruptive to the customers using those services. To help identify all of the changes to business services and the supporting technical services, the administrator decides to audit the BMC_BusinessService class.

Copy auditing this class should not affect overall system performance because changes to the BMC_BusinessService class should be few in number. Copy auditing also enables greater ability to search for changes to the class. For these reasons, the administrator configures copy auditing instead of log auditing.



Selecting which instances and attributes are included in an auditYou can restrict which instances of a given class are audited and determine which attributes can trigger an audit and are written in an audit.

Restricting audited instances with a qualificationYou restrict which instances are audited by specifying an audit qualification for each class that has auditing enabled. If an instance does not match the qualification, an audit cannot be triggered for it.

However, a superclass with auditing enabled can alter the effect of an audit qualification. If an instance of an auditing-enabled class fails the audit qualification for that class but matches the audit qualification of an auditing-enabled superclass, the attributes of the instance that are inherited from the superclass are audited.

For example, if auditing is enabled for both BMC_System and BMC_ComputerSystem, and an instance of BMC_ComputerSystem fails its own audit qualification but matches that of BMC_System, the attributes of BMC_System are audited for the instance. If BMC_System did not have auditing enabled, no part of the instance would be audited.

Setting the Audit option for attributesFor each attribute in a class, you can choose one of the following Audit options:

� None—Changes to this attribute do not trigger an audit. NULL is written to the attribute in the audit form in a Copy audit, and nothing is written to the Log field in a Log audit. This option is the default.

� Audit—Changes to this attribute trigger an audit, and the attribute value is written to the audit form or log form. When another attribute triggers an audit, this attribute is not written.

� 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—Changes to this attribute trigger an audit. This attribute value is written to the audit form or log form in any audit, regardless of whether its value changed.

NOTE As long as a class has at least one attribute with the Audit, Copy, or Audit and Copy option specified, a Create or Delete operation triggers an audit regardless of the values of the attributes. Audit, Copy, and Audit and Copy attributes are all written during such an audit.



Table 9-3 shows whether certain operations to a sample instance, taken in chronological order, trigger an audit. It assumes an instance that matches the audit qualification for its class.

In this example, Audit attribute Attribute1 and Audit and Copy attribute Attribute3 are the only attributes that can trigger an audit. However, when the instance is created, an audit is triggered regardless of the fact that they are both NULL.

When the instance is modified in Operation 2, the value of Attribute1 changes, triggering an audit that writes that attribute. Attribute2 and Attribute3 are also written, as they are in any audit. Both Attribute2 and Attribute4 change value in Operation 3, but no audit is triggered.

In Operation 4, Attribute3 changes value and another audit is triggered. This time Attribute1 is not written because its value did not change. And when the instance is deleted in Operation 5, a final audit is triggered.

Best practices

This section gives you several best practices for working with auditing.

� Enable auditing for only up to five classes, as high on the inheritance tree as possible and preferably no more than five join levels deep. For each of those, use only up to five Audit attributes.

� Do not audit system attributes like LastModifiedBy or ModifiedDate if you use Log auditing. BMC Remedy AR System keeps a history of these already.

� Rather than auditing a lower-level class in your data model inheritance tree, audit the highest-level class with attributes you want to keep and then use a qualification on the ClassId attribute to control which classes’ instances are audited. This improves performance by preventing join forms from being involved.

Table 9-3: Audit life cycle of a sample instance

Operation order

Operation Attribute1 (Audit)

Attribute2 (Copy)

Attribute3 (Audit and Copy)

Attribute4 (None)

Audit triggered?

Attributes written to audit form

1 Create NULL Chicago NULL Compact disc

Yes Attribute1 Attribute2 Attribute3

2 Modify Green Chicago NULL Cassette tape

Yes Attribute1 Attribute2 Attribute3

3 Modify Green Dallas NULL 8-track tape No None

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

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



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

� Use a qualification on the DatasetId attribute to restrict auditing to your production dataset. You rarely need to audit other datasets, so you will save processor time and disk space.

� When a component such as a disk drive disappears from the display of its parent CI such as a computer system in BMC Remedy Asset Management, it is usually caused by the connecting relationship being unintentionally soft-deleted while the component CI still exists. To track this behavior, enable auditing on BMC_BaseRelationship (with a qualification on source and destination class IDs if you want), use MarkAsDeleted as an Audit attribute, and use the source and destination instance IDs as Copy attributes.

� Not every Copy attribute must also be an Audit attribute.

Receiving CI change events with Event ChannelsApplications that rely on CI and relationship data stored in BMC Atrium CMDB sometimes need to know whether CIs and relationships have been created, updated, or deleted. For example, you might provide an email service using multiple servers. Your email service monitoring application might have the logic to identify the potential impact to the service of changes to the servers, but to apply this logic it must be notified of such changes.

The BMC Atrium Event Channels component enables applications to subscribe to and receive events using the BMC Atrium CMDB Java™ API. Events are generated when CIs and relationships are created, updated, or deleted in your production dataset, which defaults to BMC Asset. This means your application is notified of changes to your CMDB in near real time instead of it having to poll for changes periodically.

Enabling and disabling Event ChannelsThe Event Channels feature is disabled by default. To enable it, find the following line to your ar.cfg (Windows) or ar.conf (UNIX®) configuration file and change the setting from F to T. The BMC Atrium Core installer adds this option to the configuraiton file.

Event-Channel-Enabled:F

You must restart your BMC Remedy AR System server for the change to take effect.

For more information about the ar.cfg or ar.confconfiguration file , see the BMC Remedy Action Request System 7.6.04 Configuration Guide.



WARNING The Event Channels feature uses the Filter API plug-in of BMC Remedy AR System, and occasionally this use can interfere with Reconciliation Engine processing. To avoid reconciliation jobs hanging, if you use Event Channels then set your BMC Remedy AR System server’s Filter API RPC Timeout to 240 seconds.

To make this setting, from the Home page choose AR System Administration > AR System Administration Console > System > General > Server Information > Timeouts.

Class configurationsYou must configure a class for events before a subscription will deliver events for the class. The following classes are preconfigured for events:

� BMC_ComputerSystem

� BMC_BusinessService

� BMC_Application

� BMC_SoftwareServer

� BMC_IPEndPoint

These class configurations cannot be deleted. You can configure other classes for events. For instructions, see the BMC Atrium CMDB 7.6.04 Javadoc Help.

Event subscriptionsWhen subscribed, your application receives events in near real time whenever an instance of a CI or relationship class configured for events is created, updated, or deleted.

If an instance is deleted, events indicate that the instance was deleted. If the instance is marked for deletion (by setting the MarkAsDeleted attribute to Yes), events indicate that the instance was modified.

Instructions for subscribing to events are in the BMC Atrium CMDB 7.6.04 Javadoc Help. Events include the following information about the instance in question:

� Class ID and namespace

� Instance ID

� Dataset ID

� Event type—Create, Update, or Delete



BMC Atrium Event Channels applies the following security checks before sending events:

� Row-level check to make sure that the subscriber has the permission to view the relevant CI class

� Multitenancy check to make sure that the event is being delivered to a subscriber with the authority to view the relevant CI class

If a subscriber application disconnects, events are queued for delivery when it reconnects. Events that are undelivered for a day are removed, and you would then need to re-sync with BMC Atrium CMDB using the CMDB API.

NOTE Each subscribed application must have a unique BMC Remedy AR System user ID for the Event Channels feature to work correctly. In a case where multiple instances of an application subscribe to events, each instance must use a different user ID to receive events independently of the other instances.

Performance considerationsThe event generation rate is limited by the combined throughput of the Normalization Engine, Reconciliation Engine, and BMC Atrium CMDB engine.

When the BMC Atrium CMDB server is heavily loaded, change events might be generated faster than the rate at which the server can send them. In such a case, the events are queued. At times of intermittent load conditions (say for a few minutes), the queue might provide sufficient buffering, but for a longer load period it might not. When performing a bulk load of BMC Atrium CMDB, consider turning off event generation or event delivery to avoid overflowing the queue.

You can improve the speed at which the server delivers events by increasing the number of Alert threads on your BMC Remedy AR System server. To set the number of threads, from the Home page choose AR System Administration > AR System Administration Console > System > General > Server Information > Ports and Queues. In the table row for the Alert queue, set Min Threads to 5 and Max Threads to 10.

Interfaces to BMC Atrium Event ChannelsYou can configure classes, subscribe to BMC Atrium Event Channels, and turn off event generation or event delivery through the BMC Atrium CMDB Java API. For information, see the BMC Atrium CMDB 7.6.04 Javadoc Help. You configure classes for events with the ECUtil.java class and subscribe to events with the CMDBEventSubscription.java class.

Permission rolesTo subscribe to events, you must have the CMDB Console User role. To configure classes for events, you must have the CMDB Console Admin role.


Deleting CIs that are no longer discovered

Deleting CIs that are no longer discoveredOccasionally, your discovery application will not discover a CI or that it regularly discovered before. Though you might be tempted to delete the CI from BMC Atrium CMDB, do not do so right away. Usually such a missing CI is only temporarily removed or unavailable, such as when a computer system is shut down while its owner is on vacation.

Instead of deleting the instance from BMC Atrium CMDB, known as hard deleting, mark it as deleted. This is known as soft deleting, and you perform it by setting the MarkAsDeleted attribute to Yes. Soft deleting has two benefits:

� When instances have been soft deleted, you can exclude them from searches, reconciliation, and other activities by using the MarkAsDeleted attribute in your qualifications.

� Soft deleting preserves relationships and reconciliation identity in case a CI is later discovered again.

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

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

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

Calbro Services’ custom workflow for viewing unreconciled CIsCalbro Services has a process that involves creating computer system CIs manually in the production dataset. These new CIs have no reconciliation identity, and the administrator wants a visual cue when viewing a CI that it has not yet been reconciled with CIs imported by using Atrium Integrator, or with data discovered by BMC BladeLogic Client Automation or BMC Atrium Discovery and Dependency Mapping.

To satisfy this requirement, the administrator creates custom workflow that changes the label color of the Name attribute to red when an unreconciled CI is displayed.



Filter execution orderBMC Atrium CMDB uses two BMC Remedy AR System filters that act on all class forms. Each filter triggers processing by the BMC Atrium CMDB engine on the instance that is created, modified, or deleted. One filter is at execution order 100, and one at execution order 600.

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

To create a filter on a class form, choose its execution order based on these filters. In most cases, you should choose an execution order from 101 to 599. This enables your filter to work with the class ID and instance ID that are created at execution order 100 and to modify attribute values before they are pushed to subclass forms.

WARNING If your workflow modifies attribute values after execution order 600, it can compromise your data integrity.

You might choose an execution order of 99 or less to create your own instance ID instead of letting the system create it automatically.

Best practices

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

� First, identify the scope of your customization. Should it apply to all subclasses, all datasets, all data inputs, or a subset of these?

� Do not modify any of the existing filters attached to the class forms. They are typically attached to many forms, and your changes could ripple to unwanted locations.

� Add active links to an application that consumes BMC Atrium CMDB data instead of to BMC Atrium CMDB itself. For example, if you have BMC Remedy Asset Management, add your active links to the AST: forms. Add filters and escalations to the BMC Atrium CMDB class forms.

� Consider the subclasses of any class you touch. For example, workflow defined on the BMC.CORE:BMC_BaseElement form applies to all CIs unless you restrict it to particular subclasses with a Run If qualification.

� Remember the scope you identified for the customization.

� Document all customizations.


Glossary

abstract classA class that has attributes but of which no instances can be created. An abstract class exists for the purpose of creating an organizational layer without a database join. See also data replication.

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

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

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

AIE Definitions AdminA BMC Atrium Integration Engine application role. Members can view, create, and modify data mappings and data exchanges, and manage the configuration and connection settings. See also AIE User.

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

AIE UserA BMC Atrium Integration Engine application role. Members can view data mappings, data exchanges, and configuration and connection settings. See also AIE Definitions Admin.

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

attributeA property or characteristic of a class, such as the IP address of a computer system. An attribute equates to a column on a database table or a field on a BMC Remedy AR System form.

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

attribute substitutionA method of data federation in context that uses placeholders to represent attributes from a linked class. Launching the link triggers the respective attribute values to be substituted for the placeholders.

Glossary 159


auditA logging of attribute values and other information for purposes of tracking the history of changes to instance data. An audit is triggered when the value of one or more specified attributes changes or when the instance is created or deleted.

base classA class that has no superclass.

BMC Atrium Core ConsoleThe main user interface of BMC Atrium CMDB, accessible from both web and BMC Remedy User clients. The BMC Atrium Core Console replaced the CMDB Console.

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

BMC Atrium Product CatalogA BMC Remedy AR System application that is part of the BMC Atrium Core solution and provides data for normalization and discovery, including storage of product signatures, and tracks and manages products by categorization, life cycle, development status, approval status, and other attributes.

bulk functionsA set of functions you can use to create, update, and delete multiple instances in a single call. These functions can manipulate instances of different classes in a single operation.

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

cardinalityThe number of members a relationship class can have on each side. Cardinality can be one to one, one to many, many to one, or many to many.

cascading deleteTo automatically delete, or mark as deleted the destination member of a relationship when the source member is deleted or marked.

Categories, Types, and Items (CTI)A method formerly used for categorizing assets in BMC Remedy Asset Management. Category, Type, and Item are each an attribute on the BMC_BaseElement class, so you can use CTIs in BMC Atrium CMDB.

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

CDMSee Common Data Model (CDM).

childSee destination.

CISee configuration item (CI).

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

CIMSee Common Information Model (CIM).

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

Class ManagerA component of BMC Atrium CMDB where you can view, create, modify, and delete the classes and attributes that make up the data model, as well as view a list of subclasses for each class.

class permissionsPermission to view instances of a class in the BMC Atrium CMDB interface or access them with BMC Remedy AR System workflow.

CMDBSee Configuration Management Database (CMDB).


Glossary

CMDB ConsoleSee BMC Atrium Core Console.

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

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

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

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

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

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

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

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

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

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

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

cmdbdriverA utility that executes BMC Atrium CMDB C API functions from a command line, prompting for parameters.

Common Data Model (CDM)The object-oriented, hierarchical set of classes in BMC Atrium CMDB used to represent types of CIs and relationships. The CDM is based on industry standards such as the Common Information Model (CIM) and Microsoft Windows Management Instrumentation.

Common Information Model (CIM)A definition of management information developed by the Distributed Management Task Force (DMTF) that facilitates the exchange of management information between systems.

Comparison activityA Reconciliation Engine activity that compares identified instances between two datasets, either producing a report that shows the differences or executing workflow.

configuration dataData about your IT environment, consisting of CIs and relationships.

configuration item (CI)A physical, logical, or conceptual entity that is part of your IT environment and has configurable attributes. Examples include computer systems, buildings, employees, software, and business services. One of the two types of classes in BMC Atrium CMDB. See also relationship.

Configuration Management Database (CMDB)A database that stores information about your IT configuration, including both CIs and relationships.

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

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

Glossary 161


CTISee Categories, Types, and Items (CTI).

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

data mappingA BMC Atrium Integration Engine integration object that defines the data to be transferred. A data mapping defines the source and destination of a data transfer, the primary key, and other fields and attributes. You can use a data mapping by associating it with a data exchange.

data replicationAn option for abstract classes. With this option, the instances of all subclasses are replicated to a single form to allow you to search the abstract class as though it had data. Only the attributes inherited from the abstract class are replicated.

datasetA logical group of data in BMC Atrium CMDB. A dataset can represent data from a particular source, a snapshot from a particular date, or other purpose. The dataset used by BMC Software products for reconciled production data is named BMC Asset. See also overlay dataset.

Dataset Merge PrecedenceA pairing of a dataset with a Precedence group. Each Merge activity references a collection of these, called a Dataset Merge Precedence set.

defined datasetOne of a pair of dataset IDs that is specified when executing a job with dynamic dataset substitution. The job is executed with the working dataset in place of the defined dataset.

Definitive Hardware Library (DHL)The Definitive Hardware Library (DHL) is a subset, or filter, of the Product Catalog that represents hardware products that are marked as approved for use in an organization.

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

Definitive Software Library (DSL)See Definitive Media Library (DML).

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

destinationThe CI class defined as Class 2 in a relationship class, or an instance of that CI class as a member of such a relationship. Also known as the child member. In a weak relationship, the destination is the weak member.

discoveryThe act of scanning your environment for configuration data.

discovery applicationAn application that scans your environment for configuration data and can act as a provider to BMC Atrium CMDB.

Distributed Management Task Force (DMTF)An organization appointed to facilitate the exchange of management information by promoting the initiation of industry standards and interoperability.

DHLSee Definitive Hardware Library (DHL).

DMLSee Definitive Media Library (DML).


Glossary

DMTFSee Distributed Management Task Force (DMTF).

DSLSee Definitive Media Library (DML).

Enterprise Integration EngineSee BMC Atrium Integration Engine.

eventA particular type of change to the instances of specified classes. You can publish an event so that any instance of it is written to the CMDB:Events form. You can receive notification each time an instance of the event occurs by polling the form.

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

Execute Job activityA Reconciliation Engine activity that executes a job.

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

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

federated dataData linked from CIs in BMC Atrium CMDB but stored externally. Federated data might represent more attributes of the CIs or related information such as change requests on the CIs.

federated interfaceAn instance of the BMC_FederatedInterface class that specifies how to access a particular type of federated data. See also federated link.

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

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

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

Federation ManagerA component of BMC Atrium CMDB that you can use to manage federated data. From the Federation Manager, you can view, create, and modify federated products, federated interfaces, and federated links.

filterA set of criteria for restricting the information displayed by the Atrium Explorer. This is different from a BMC Remedy AR System filter.

final classA class that cannot have subclasses.

foreign key substitutionA method of federation that assigns a key from the federated product to each linked CI. Foreign key substitution is useful when no attributes that also exist in BMC Atrium CMDB are stored in the federated product.

graph walkThe act of searching for CIs and relationships in BMC Atrium CMDB.

graph walk functionsA set of specific functions that are used to search for CIs and relationships in BMC Atrium CMDB. Use these functions when you want to search for CIs regardless of their class or relationship.

groupA set of a particular type of reconciliation definition that is referenced by an activity. See also Identification group, Precedence group, Qualification group, Workflow Execution group.

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

Glossary 163


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

Identification activityA Reconciliation Engine activity that matches instances from two or more datasets and assigns them the same identity, meaning that they represent the same real-life object.

Identification groupA set of Identification rules that collectively identify instances from a particular dataset against other datasets. Each dataset that participates in an Identification activity is paired with one Identification group.

Identification ruleA rule used when identifying instances between datasets. When two instances match the qualification for the rule, they are assigned the same reconciliation ID.

identitySee reconciliation ID.

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

incremental mergeA Merge activity that only processes instances created or modified since the activity was last run, saving otherwise useless processing time. Setting Force Attribute Merge to No makes a Merge activity incremental.

instanceAn actual incarnation of a particular class, represented as a record in BMC Atrium CMDB. Both CIs and relationships are instances of their respective classes.

instance IDA GUID that BMC Atrium CMDB applies to each instance to uniquely identify it.

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

instantiateTo create an instance of a class.

ITIL®

The IT Infrastructure Library® (ITIL) is an internationally accepted set of best practices developed by the British government for management of IT services.

jobA group of one or more reconciliation activities executed in sequence. You cannot run an activity by itself; only as part of a job. You can start a job manually, with a schedule, with an Execute Job activity, with workflow, or with an API program.

key queryLimits the records transferred in a data transfer in the BMC Atrium Integration Engine. See also row-level query.

Merge activityA Reconciliation Engine activity that merges two or more datasets into a single complete and correct dataset based on precedence values that favor the strengths of each dataset.

metadataDefinitions that describe the data stored in BMC Atrium CMDB. Metadata includes classes in the data model and special classes to define things such as datasets and federation objects.

multitenancyThe separation of data and access so that a single BMC Atrium CMDB can contain the data of multiple parties, but each party can access only their own data. See also account, role.

namespaceA logical set of classes and attributes in the data model, usually related to a specific consumer or provider. The Common Data Model (CDM) uses the BMC.CORE namespace.


Glossary

normalizeTo ensure that data of the same type follows the same text formatting conventions. This helps reconciliation by making it more likely for instances to match in an Identification activity.

Normalization EngineA BMC Atrium CMDB application that provides a centralized, customizable, and uniform way to overcome consistency problems by normalizing attributes for software and hardware products.

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

overlay datasetA dataset that provides a layer in which to make changes that are pending approval. API queries to the dataset seamlessly return its modified instances along with unmodified instances from the underlying regular dataset.

parentSee source.

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

precedence valueA method of assigning weight to specific datasets, classes, and attributes in a Merge activity. Attribute precedence values override class precedence values, which override dataset precedence values.

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

Product CatalogThe BMC Atrium Core component that provides normalized manufacturer names, model names, categorization values, and other information about hardware and software products.

product categorizationDivides CIs into groups. Using the three-tier structure of product categorization, you can create successively smaller, more tightly defined groups. You can create groups of CIs in Tier 1 followed by smaller groups in Tier 2 and Tier 3.

production datasetThe dataset that serves as the single source of reference for your organization and from which you make business decisions. It acts as the target dataset in most Merge activities.

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

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

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

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

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

Qualification groupA set of Qualifications that can be used in various types of activity. An instance that meets one or more Qualifications in the group is included in the activity.

Glossary 165


reconciliationThe process of managing data in multiple datasets using the Reconciliation Engine. The main activities of reconciliation are identifying, comparing, and merging datasets, though the Reconciliation Engine performs other activities as well.

reconciliation definitionAn entity defined in the Reconciliation Manager such as a job, activity, or group.

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

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

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

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

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

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

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

relationship filterSee filter.

relationship keyA relationship key uniquely identifies a row of data in a relationship mapping. In BMC Atrium Integration Engine you must specify the attributes of a primary CI class and a secondary CI class to create the relationship key. After a data transfer, the relationship key is the link that matches a record in the external data store with its counterpart in BMC Atrium CMDB.

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

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

row-level queryLimits the transfer of data on a row-by-row basis in the BMC Atrium Integration Engine. See also key query.

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

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

rulesetA group of rules.

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

service modelThe CIs and relationships that define business services and the resources that deliver and support them, enabling you to see infrastructure items in a business context.

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


Glossary

snapshotA set of data that represents a configuration at a certain point in time, usually stored in its own dataset. There can be multiple snapshots of a given configuration.

soft deleteThe act of marking an instance as deleted from BMC Atrium CMDB by setting the MarkAsDeleted attribute to Yes. See also hard delete.

sourceThe CI class defined as Class 1 in a relationship class, or an instance of that CI class as a member of such a relationship. Also known as the parent member. In a weak relationship, the source is the strong member.

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

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

synchronizationThe automatic process of creating BMC Remedy AR System forms and workflow to represent a class that has just been created or modified. The class is not available until synchronization completes.

text normalizationSee normalize.

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

weak referenceSee weak relationship.

weak relationshipAn optional characteristic for relationship classes, signifying that the members of a relationship form a composite object that can be reconciled as one. The destination member is considered the weak member of a weak relationship, existing as part of the source member (also known as the strong member).

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

WMISee Windows Management Instrumentation (WMI).

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

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

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

working datasetOne of a pair of dataset IDs that is specified when executing a job with dynamic dataset substitution. The job is executed with the working dataset in place of the defined dataset.

write securityThe permission required along with row-level security to modify or delete a specific instance. See also row-level security.

Glossary 167



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

Aabout BMC Atrium CMDB 26abstract classes

about 54data replication 55, 64extending 64

accessingBMC Atrium CMDB 91CMDB data 27

addingattributes to existing classes 62data manually 140subclasses to the Common Data Model 63workflow to BMC Atrium CMDB 157

application layer infrastructure 32applications, using with extended data models 66approving products 129AR System

See BMC Remedy Action Request System (BMC Remedy AR System)

architectureAR System 33BMC Atrium CMDB 30BMC Atrium Core 26

assessing configuration data source environments 76Atrium Explorer

about 22relating CIs 111

Atrium Impact Simulator 22Atrium Integrator

about 25configuring 131

attributesabout 48adding to existing classes 62Category 62extending the Common Data Model 62generating fields for AR System 66Item 62naming and numbering rules 66substitution of 88Type 62updating manually 141

audit forms 149auditing, best practices 153audits

attribute options 152Calbro Services example 151copy option 149life cycle 153log option 150restricting 152specifying qualifications 152tracking changes to instance data 148types 149

Bbenefits

BMC Remedy AR System 34decision-making support 36federated data 32integration 36Service Asset and Configuration

Management 35best practices

adding workflow 158auditing 153categorizations 128importing data to BMC Atrium CMDB 138

bidirectional data transfers, testing 139BMC Asset dataset 79

Index 169


BMC Atrium CMDBSee BMC Atrium Configuration Management

Database (BMC Atrium CMDB)BMC Atrium Configuration Management Database

(BMC Atrium CMDB)about 20architecture 30data model 48production dataset 79

BMC Atrium Corearchitecture 26implementing 121managing 147

BMC Atrium Discovery and Dependency Mappingconfiguration data discovered 75dataset 80discovering data 75running and scheduling tasks 83

BMC Atrium Integration Enginetransferring data 76

BMC Atrium Product Catalogabout 24, 98approving products 129best-practice categorizations 128relation to Normalization Engine 96

BMC BladeLogic Client Automationrunning and scheduling tasks 84

BMC Configuration Import dataset 80BMC Configuration Management

configuration data discovered 75dataset 80

BMC Impact Solutions, using new classes 66BMC Remedy Action Request System (BMC Remedy

AR System)architecture 33benefits 34BMC Atrium CMDB and 33using with extended data models 66

BMC Remedy AR SystemSee BMC Remedy Action Request System (BMC

Remedy AR System)BMC Remedy Asset Management, dataset 79BMC Sample dataset 79BMC Software, contacting 2BMC.ADDM dataset 80BMC.ASSET.SANDBOX dataset 79BMC_AccessPoint class 57BMC_BaseElement class 57BMC_BaseRelationship class 58BMC_Collection class 57BMC_Component class 58BMC_Dependency class 58

BMC_Document class 57BMC_ElementLocation class 58BMC_Equipment class 57BMC_FederatedBaseElement class 59BMC_FederatedBaseRelationship class 59BMC_Genealogy class 58BMC_Impact class 58BMC_LogicalEntity class 57BMC_MemberOfCollection class 58BMC_Person class 57BMC_Settings class 57BMC_System class 57BMC_SystemComponent class 57BMC_SystemService class 57building CMDBs

phased implementation 44Stage 1 42Stage 2 42Stage 3 43Stage 4 43Stage 5 44

bulk data, loading 28business services

Calbro Services example 116described 111

CCalbro Services

about 38adding custom workflow 157auditing 151business service 116CI eligibility matrix 71extending the data model 65federating data 86mapping CIs to data sources 76multitenancy 92normalizing data 100populating BMC Atrium CMDB 142reconciling datasets 80service model 110

cardinality 50cascading delete 51categorization classes

about 53extending 64

Category attributes 62CDM

See Common Data Model (CDM)challenges to SACM 44changes, tracking instance data 148



changing attribute permissions 124CI change events 154CI eligibility matrix 71CIM

See Common Information ModelCIs

See configuration itemsClass Manager, about 24classes

about 48abstract 54abstract with data replication 55adding attributes to existing 62BMC Atrium CMDB 56categorization 53configuration item 48data model 56data storage methods 52deleting instances of 51extending 63naming and numbering rules 66regular 52relationship 49replicating subclasses 55

CMSee configuration management

CMDB Environment layer 32CMDBRowLevelSecurity permission 125CMDBs

BMC Atrium infrastructure layer 31configuration items and 70data types 70implementing 44integrating ITIL processes 36

CMDBWriteSecurity permission 125CMS architecture 30CMS Data layer 31combining reconciliation activities 107

Common Data Model (CDM)about 23, 48, 56abstract classes 64abstract classes with data replication 64adding attributes 62adding subclasses 63BMC applications and 66BMC Impact Solutions and 66BMC products and 61categorization classes 64classes 63configuration item classes 57diagram 61documenting 67existing attributes 62extending 61final classes 64naming and numbering rules 66regular classes 63relationship classes 58, 63sample models 60singleton classes 64

Common Information Model 23, 56Compare Dataset activity, tracking changes with 148comparing datasets 103computer systems, sample data models 60configuration data

assessing source environments 76datasets and 79discovered by BMC Atrium Discovery and

Dependency Mapping 75discovered by BMC Configuration

Management 75unified representation 48

Index 171


configuration items (CIs)about 70BMC_AccessPoint 57BMC_BaseElement 57BMC_Collection 57BMC_Document 57BMC_Equipment 57BMC_LogicalEntity 57BMC_Person 57BMC_Settings 57BMC_System 57BMC_SystemComponent 57BMC_SystemService 57classes 48CMDBs and 70Common Data Model classes 57datasets and 79, 96defined 70deleting 157examples 70extending 63mapping to discovery data sources 74missing 157related data 73relationships 72undiscovered 157

Configuration Managementcontrolling 37teams, establishing 42

configuration management databasesSee CMDBsconfiguringAtrium Integrator 131multitenancy 125permissions 123

controllingaccess 91Configuration Management 37

copying dataset instances 107custom workflow, adding 157customer support 3

Ddata

access 27auditing 148BMC Atrium CMDB model 48bulk loading 28configuration 48federated 84importing to BMC Atrium CMDB 138migrating to BMC Atrium CMDB 138open access 27partitioning 28programmatic access to 28reconciling 101, 142related to configuration items 73replicating abstract class 55replicating BMC Atrium CMDB 94tracking changes 148types stored in ITIL CMDBs 70

data modelsSee also Common Data Modelabout 23, 48abstract 54abstract with data replication 55attributes 48Calbro Services example 65categorization 53classes 48data storage methods 52extensibility 23, 48industry standards 23, 56inheritance 48object-oriented 23regular 52synchronizing changes 56

data storage methods 52



datasetsabout 79, 96BMC Asset 79BMC Configuration Import 80BMC Sample 79BMC.ADDM 80Calbro Services example 80comparing 103copying instances 107deleting instances 107identifying 82merging 103production 79purging instances 107reconciling 101renaming 107

Definitive Hardware Library (DHL), approving products 129

Definitive Media Library (DML)about 24approving products 129defined 99See Also BMC Atrium Product Catalog

deletingcascading 51configuration items 157dataset instances 107instances 51relationships 51

destination classes 49DHL

See Definitive Hardware Librarydiagram of the Common Data Model 61discovery

BMC Atrium Discovery and Dependency Mapping 75

data sources 76deleting undiscovered CIs 157tasks 75

Distributed Management Task Force 23, 56DML

See Definitive Media LibraryDMTF

See Distributed Management Task Forcedocumenting extensions 67

Eeligibility matrix 71Event Channels

configuring classes for 155interfaces to 156overview 154performance considerations 156permission roles for 156subscribing to 155

examplesconfiguration item 70relationship 73test cases for validation 139

Extended Data layer 31extending the Common Data Model

about 61abstract classes 64abstract classes with data replication 64adding attributes 62adding subclasses 63BMC applications and 66BMC Impact Solutions and 66BMC products and 61categorization classes 64classes 63diagram 61documenting 67existing attributes 62final classes 64naming and numbering rules 66regular classes 63relationship classes 63singleton classes 64

extensible data models 23

Ffederated classes 59federated data

about 28, 84as part of a CMS 30attribute substitution 88benefits 32Calbro Services example 86foreign key substitution 89model 26, 28using 85

federated data model, about 28federated infrastructure 30federation methods 86

Index 173


final classesextending 64

foreign key substitution 89forms

audit 149log 150

Ggoals of SACM 35groups 93

Hhidden class permissions 124

Iidentifying

datasets 82instances 102

implementingBMC Atrium Core 121CMDBs 44

import management module, purpose 75importing data to BMC Atrium CMDB 138incremental merge jobs 104, 135industry standards, data model 23, 56infrastructure

about 30application layer 32BMC Atrium CMDB 30CMDB Environment layer 32CMDB layer 31CMS Data layer 31federated 30related data 31

inheritance 48instances

audited 149CMDBRowLevelSecurity permissions 125CMDBWriteSecurity permissions 125copying dataset 107deleting dataset 107deleting from overlay datasets 82deleting relationship class 51identifying in datasets 82, 102purging dataset 107replicating 55sample audit 153

integrating IT processes 36

integration benefits 36IT Infrastructure Library (ITIL)

about 34data types 70SACM 34

Item attributes 62ITIL

See IT Infrastructure Library

Jjobs, combining reconciliation activities 107

Llaunch method of federation 87left-side classes 49loading bulk data 28log forms 150

Mmanaging BMC Atrium Core 147manually updating attributes 141mapping configuration items to discovery data

sources 74members, relationship 49merging datasets

about 103incrementally 104, 135independent activities 105one activity 104

Microsoft Windows Management Instrumentation 23, 56

migrating data to BMC Atrium CMDB 138multitenancy

Calbro Services example 92configuring 125defined 91

Nnaming rules for extensions 66normalization

Calbro Services example 100modes 97

Normalization Engineabout 21example 96relationship to Product Catalog 96

numbering rules for extensions 66



Oobject-oriented data models 23open access to data 27overlay datasets

about 80deleting instances 82instance IDs 82queries to 81

Pparent classes 49partitioning

about 28data 28datasets and 79

pending changes 56permissions

about 91BMC Atrium CMDB 91change attribute 124configuring 123groups 93hidden class 124roles 94view attribute 124visible class 124

phases of CMDB implementations 44planning

bringing data into BMC Atrium CMDB 69building CMDBs 43CMDB requirements 42data model 47driving value 44establishing management teams 42normalization 95reconciliation 101service model 109solutions and tools 43

processes, integrating IT 36Product Catalog

See BMC Atrium Product Catalogproduct support 3production datasets, defined 79programmatic access to data 28purging dataset instances 107

Qqualifications, audit 152queries, overlay dataset 81

Rreconciliation

about 142combining activities 107comparing datasets 103copying dataset instances 107data 101deleting dataset instances 107executing jobs 107identifying instances 102jobs 107merging datasets 103purging datasets 107renaming datasets 107

Reconciliation Engineabout 21, 101executing jobs 107

regular classesabout 52extending 63

related data 31relating CIs using Atrium Explorer 111relationships

about 49BMC_BaseRelationship 58BMC_Component 58BMC_Dependency 58BMC_ElementLocation 58BMC_Genealogy 58BMC_Impact 58BMC_MemberOfCollection 58cardinality 50cascading delete 51Common Data Model 58configuration item 72datasets and 79, 96deleting 51deleting instances of 51destination 49examples 73extending 63extending classes 63left-side 49members 49placement 49right-side 49source 49weak 50

renaming datasets 107replicating data 94restricting audits 152

Index 175


retrieval method of federation 87right-side classes 49risks to successful SACM 44roles 94

SSACM

See Service Asset and Configuration Management

samplesCommon Data Model 60instance audits 153LAN computer system data models 60typical computer system data models 60

Service Asset and Configuration Management (SACM) 19, 34

benefits 35challenges, success factors, and risks 44data accuracy 37data availability 37goals 35ITIL and 34

Service Catalog, about 24service models

Calbro Services example 110defined 110structure 137

service oriented architecture (SOA) 29singleton classes

extending 64SOA

See service oriented architecturesource classes 49subclasses

adding to the Common Data Model 63creating 63federated data 59

substitutionattribute 88foreign key 89

success factors with SACM 44support, customer 3synchronizing data model changes 56

Tteams, Configuration Management 42technical support 3test cases for validation 139testing unidirectional and bidirectional data

transfers 139

tracking instance data changes 148Type attributes 62

Uundiscovered relationship information, adding

manually 141unidirectional data transfers, testing 139

Vvalidating data import using Atrium Integrator 141virtual machines 58virtualization management 29visible class permissions 124

Wweak relationships 50web services 29WMI

See Microsoft Windows Management Instrumentation

workflowbest practices for adding 158Calbro Services example 157


*176777**176777**176777**176777*

*176777*

BMCAtriumCore7604ConceptsPlanningGuide

Documents

definitive

atrium impact

bmc remedy

bmc atrium

formsupcattribute1

bmc atrium

bmc impact

bmc atrium