Atrium CMDB Considerations & Lessons Learned

Atrium CMDB Considerations & Lessons Learned
Authors – Trevor O’Brien, BMC Account Manager Eric Ho, BMC Client Architect Alberto Torres, BMC Consulting Services Rich Bradley, BMC Software Consultant Kelly Deaver, BMC Technical Marketing 11/7/2018

Agenda Implementation Planning Pointers CMDB Usage CDM Usage
Requirements Review Common Deployment Decisions Federation CDM Usage Modeling Extending Implementation Tips Technical Tips 11/7/2018 ©2008 BMC Software

Stakeholder Benefit Realization
Where is the business? Where are the customers? What are the expectations? Who will realize the biggest benefits? Can I deliver on the promise? 11/7/2018 ©2008 BMC Software

CMDB: Designing For Information Demand
11/7/2018 ©2008 BMC Software

Benefit Examples Reduce TCO Improve Service Quality
Reduction in number of monitoring tools Reduction in software costs Reduction in hardware costs Increase in license utilization Regulatory compliance (e.g. SOX) Identify owners of services and related components Efficient and auditable Change Management process with electronic approvals Improved cross-business communications Visibility of how IT assets support critical business functions Decrease in detection of unauthorized assets Improved application availability Improved communication with client-facing areas Measure availability (service, not devices) More accurate data improves incident, problem handling Improve Service Quality Improve Compliance and Management Controls Improved prediction of Change impact Remove Change Management collisions Consistent and predictable Configuration Management Improve Change Process -Reduction in number of monitoring tools -Reduction in software costs -Reduction in hardware costs -Increase in license utilization -Decrease in detection of unauthorized assets -Visibility of how IT assets support critical business functions -Consistent and predictable Configuration Management -Efficient and auditable Change Management process with electronic approvals -Regulatory compliance (i.e., SOX) -Improved application availability -Improved communication with client-facing areas -More accurate data improves incident, problem handling -Improved prediction of Change impact -Remove Change Management collisions -Measure availability (service, not devices) -Improved cross-business communications -Identify owners of services and related components 11/7/2018 ©2008 BMC Software

CMDB Implementation Planning – Lessons Learned
Identify pain points Understand data requirements Control the scope of the implementation Adopt a phased approach Use standards and naming conventions Define IT services Create a project team Earn management commitment Prepare for cultural change Follow a communications plan Plan Implement Buy-In 11/7/2018 ©2008 BMC Software

What problem is the CMDB intended to solve?
1. Identify Pain Points What is broken? Asset Management Service Management Understanding network topologies Understanding system dependencies Assess the impact of changes Physical vs. logical connections Identify business stakeholders What problem the CMDB is intended to solve? For instance is the pain related to: asset management service management understanding network topologies understanding system dependencies. assess the impact of changes ( physical vs. logical connections) identify business stakeholders consider the unique pain points of the project sponsors when deciding where to start a CMDB project. What are their specific problems? How will they benefit from the CMDB project? Your goal should be to make key stakeholders early winners in order to maintain support and momentum for subsequent phases of the implementation. detailed analysis often can help them focus the implementation to ensure early successes and increase overall benefits. For example, one company decided that configuration management was the primary focus for its project. However, the change management process was broken —the organization did not track the status of each change, or record what specifically was updated. As a result, that organization would have implemented a configuration management solution that would have been rendered inaccurate by ongoing change. We worked backwards to determine that the first step was to fix the change process. Otherwise, the organization would have undermined the benefits of the overall CMDB project. What is missing? What problem is the CMDB intended to solve? 11/7/2018 ©2008 BMC Software

2. Understand Data Requirements
suppliers Process … CMDB Information consumers The CMDB is the point of integration between diverse data producers and information consumers. Identify these data producers and information consumers and understand specifically what data is needed to optimize their processes. Stakeholders, processes, tools, and external forces such as regulatory compliance all leverage information in the CMDB. Stakeholders may include business units, process owners, and users. Many processes will require information and will produce data/information. You’ll need to consider issues such as how to represent redundant configuration items for high availability. You’ll also need to understand the information required to support and execute service management and IT management processes as well as security and audit functions. In addition, you’ll need to examine a tool’s ability to store, document, and relate different configuration items, as well as extend out-of-the-box fields. Identifying the need for configuration knowledge in your organization will help you determine the scope of the CMDB project, or, if you take a phased approach, the scope over time. Knowledge 11/7/2018 ©2008 BMC Software

3. Control the Scope of the Implementation
What processes need to be controlled? Can they be controlled? What are the benefits gained from control? What are the risks if not controlled? What information is needed to prove control? What are the audit requirements? What are the security requirements? Do systems change frequently? Who requires the information? What level of effort is needed to gather the information? What level of effort is needed to maintain the information? Keep in control, by not wanting to control everything.. You should actively control the scope of the initial phase of the implementation to keep it focused and manageable. You will always find additional “must have” capabilities as individuals get more involved in the project. Keep a list of these additional requirements to acknowledge the good ideas, but wait to include and prioritize them until you start to plan the next phase of the project. This can be especially challenging as progress leads to enthusiasm and creative thinking. For example, a technical team I worked with wanted to include all discoverable system parameters for each configuration item in the CMDB. To control scope, we had to consider how often the information would be updated and how often the information would be accessed. We considered the cost of collecting and maintaining the data, and then reduced the potential number of attributes per configuration item from 3,000 attributes to 300. I then asked the team to identify the top 10. Through negotiation, and repeated focus on the problem we were solving, we settled on the 30 most important attributes. I recommend this negotiation exercise—it’s an effective way to establish the most appropriate scope. Another way to control the scope is to focus on the questions that are related to audit and control requirements: What processes need to be controlled? Can they be controlled? What are the benefits gained from control? What are the risks if not controlled? What information is needed to prove control? What are the audit requirements (e.g. Sarbanes Oxley - Bill 198) What are the security requirements? Do systems change frequently? Who requires the information? What level of effort is needed to gather the information? What level of effort is needed to maintain the information? I also ask: What are the benefits from controlling a particular configuration item? If the configuration item changes and nobody really cares, why put it in the CMDB? If nobody needs that information, then does the cost of collecting the information justify the effort to maintain it? Remember, if the effort to maintain the information is greater than the anticipated benefit, then it should be out of scope. 11/7/2018 ©2008 BMC Software

4. Adopt A Phased Approach
…. Desktop Server Network Services …. BU1 BU2 BU3 BU4 …. Location A Location B Location C Location D Don’t attempt at the outset to design the end goal of the overall “perfect solution.” Do spend some time working with key constituents to understand the potential of an ideal, fully implemented solution, in order to build shared vision. Make a conscious decision to start small, and achieve some quick wins for the project sponsor in order to avoid analysis paralysis. I’ve found that a phased approach to a CMDB project is the most effective. One approach is to look to your company’s organizational structure as a guide for determining the phases. If your organization is geographically dispersed, with each location very autonomous, then consider a location-by-location approach, building on the improved results of each location. If your IT organization has a siloed structure — the server group is isolated from the desktop group, from the network group, and so on — a function-by-function approach may make the most sense. Or, there may be a particular business unit or a business function with very high visibility because it’s new, or very critical to the business, or past exposures have occurred. In that case, focusing on that line of business makes sense. Another approach to phasing your project is to work through different layers of information in the CMDB. Start at the resource level, and configure the infrastructure, making sure you know what physical components are there and how they are related. Next, focus on the service level, where you collect information about how these components support specific services. At this level, you want to identify key services that IT provides, such as incident resolution or capacity planning, and determine the components needed for those processes. Focus the final phase on the business level, where you capture information such as the budget of a business organization versus the service level agreements (SLAs) that IT has in place. When utilizing any of these phased approaches, managing expectations throughout the design and implementation of the CMDB project is especially important. Everyone should know what kind of phased approach has been selected, and what the objectives are at each point in time. Communication is crucial, and key performance indicator (KPI) reports are effective tools for distributing information and showing people where the project stands in the bigger scheme. …. Global CI High Level Complete Detailed …. Asset Assetplus Some linkage Relationships 11/7/2018 ©2008 BMC Software

5. Use Standards and Naming Conventions
Existing standards & conventions Common sense Involvement Leverage standards and naming definitions where possible. Even with a phased approach, eventually the project will impact many different parts of the organization. Make sure you have the right standards in place so that you don’t need to change the naming part way through the project. This can take some time. Everyone needs to buy-in to the standards. You’ll need to involve a lot of people so they feel included, but not include too many so that nothing is ever decided. Take cues from your organization’s management style to determine the best approach with moving to consensus. Use whatever approach works best in your organization. Consensus Organizational structure Locations 11/7/2018 ©2008 BMC Software

ITIL => Service Management
6. Define IT Services ITIL => Service Management CI CI Service A CI CI CI CI CI CI CI CI CI CI CI Service based CI topology (top down) Clearly define IT services early, in order to ensure the success of your CMDB project. If you haven’t formally defined a service catalog or list of what IT services are offer to the business, it will be difficult to map components to services. Although many organizations have advanced service management capabilities, I know many others that are still focused on system management. These organizations need to take that critical step to link into services. Every activity within IT should trace back to a defined service. Ask yourself, “If we are not doing this activity for a service for the business, then why are we doing this?” Asset based CI topology (bottom up) Service Catalog 11/7/2018 ©2008 BMC Software

7. Create A Project Team Process Configuration Process governance
Data providers Information consumers Process owner Process staff Process input Management information To successfully implement an IT-wide strategy, establish a governing body and a cross-functional project team early in the project. A CMDB cannot exist in vacuum. A CMDB project team often includes the configuration management process owner, key stakeholders, and personnel involved in other IT areas such as change management, IT service definition, architecture, standards groups, application development teams, service desk, asset management, and change execution in technology domains such as applications, databases, networks, servers, facilities, and storage. I make sure to define and coordinate the CMDB project team responsibilities with individual IT domain responsibilities and objectives. While individual IT domains continue operations, they can work toward the CMDB requirements. When it’s time to include network components, for instance, then that group’s data is up-to-date and in a format that can be imported into the database. Be sure that your CMDB project team includes a person who has the authority to make decisions. Without a decision-maker, a discussion about naming conventions might extend three months. Consider limiting the number of people involved in the CMDB design to help keep the project moving. You need to gather everyone around the table and reach agreement on the objectives for phase one, but then tackle CMDB design with a smaller group that reports back to the larger group. Otherwise, the project may never come to a finish Communication Advocates Ownership Sponsorship Project team Stakeholders The process will continue after the project has finished!! 11/7/2018 ©2008 BMC Software

8. Earn Management Commitment
focused on results Align plans Clear deliverables Keep Schedule Report progress Gain management commitment on all levels to sustain the initial development and activation of the project, and to enforce configuration management policies and procedures on an ongoing basis. Lack of management commitment can be a barrier to the success of the CMDB project. Demonstrating some obvious process improvements and the benefits of the CMDB can help you maintain management’s commitment to the project. Before implementing the CMDB, I work with the team to establish measurements that make sense to the stakeholders in the CMDB project — the business and senior management. Then we can show improvements against those initial measurements. From a governance point of view, those reports are important to show the quality of the processes and to maintain budget to run the program. Without measurements in place, the budgeting process could be more about politics. By implementing some KPIs and reporting on them, an organization can really start working on continuous improvement. Some examples of KPIs include: Number of incidents related to unknown components or faulty configurations Percentage of infrastructure components that are managed in the CMDB Number of unsuccessful changes, due to missing or invalid impact analysis Measurable controllable process By usage of Performance Indicators Identify & Celebrate (quick) wins 11/7/2018 ©2008 BMC Software

9. Prepare for Cultural Change
Perception expectations – involvement - clarity Anticipate and actively manage cultural change. Cultural change is required to successfully implement something new that impacts a broad range of job functions. Jobs and work procedures, as well as measures of success, may all change. Clearly understand and articulate what you are asking people to do differently, and make sure management is on board to back up and reinforce new desired behavior. I’ve worked with many organizations where the corporate culture rewards employees for the knowledge they have in their heads. For example, if all the systems are down and only one person knows how to restore them, that person becomes the hero. In these organizations, we’ve needed to work diligently to establish a different culture — one that rewards people who contribute their knowledge to the knowledge database that is the CMDB. Incentives 11/7/2018 ©2008 BMC Software

10. Follow A Communications Plan
WHO PLAN HOW Clearly communicate to everyone who will be affected by the CMDB project. Everyone who will be touched by the CMDB implementation needs to understand the project, the goals, the expected benefits, and how it impacts them personally. It is definitely a selling job. People will be more likely to assist you and participate in new processes if they understand how the project will make their job easier. I work with the CMDB project team to have an elevator pitch ready to present to individuals at all levels, giving people the right message and explaining the benefits. Then, I tailor the pitch to the audience, giving specific examples of what will improve for them. For example, tell the people who manage the servers that they don’t need to keep their spreadsheet anymore. If they want to update something, they have an automated tool that will provide information such as who the stakeholders are and what other changes are planned for this type of component. It’s essential to have a communication plan at the start of the project and continued communication of project status throughout the implementation. You can bring in a good tool and top consultants, but if you don’t touch the people who will work with it on a day-to-day basis and who will use the output of the process, then you diminish the opportunity for success. If people are motivated, if they know what’s in it for them, and if they are willing to give their best, then you will have a successful project. WHEN WHAT 3 Success factors for each project: 1) Communicate 2) Communicate 3) Communicate 11/7/2018 ©2008 BMC Software

5 Key Planning Tips Sell vision and benefits
Focus on how the CMDB will improve individuals jobs Establish a governing body and a create cross-functional team The process will continue after the project has finished Determine a clear scope for the project, and stay focused on objectives Clear goals within the right scope and a feasible plan Use a phased implementation approach to show early success Manageable steps, progress report, quick wins, continuous improvement Set expectations and clearly document milestones of progress Maintain Management commitment, communicate, communicate and communicate 11/7/2018 ©2008 BMC Software

CMDB Usage Understand your CMDB requirements Driven by use case
Asset Inventory use case Service Impact use case Change Management Service Desk Use top down approach for defining CIs to store in CMDB Define Services first and the define infrastructure to support service Typically the opposite is done. The whole infrastructure is loaded into the CMDB and then mapped to services 11/7/2018 ©2008 BMC Software

CMDB Sizing: Common Deployment Decisions
Number of Configuration Items (CI) In the CMDB Directly determines effort to implement Sizing of Effort: Number of Desktops and Servers Included in the CMDB Routers, Switches, Load-balancers generally don’t impact CI count much Amount of Data per Computer System Independent Variable that determines size of CMDB Number of CIs per Computer System* Server Desktop Hardware CIs (HostedSystemComponents) 60 CIs Managed Software 80 CIs 20 CIs All Applications 500 CIs 300 CIs All Patches 700 CIs 150 CIs *Does not Include Relationship instances 11/7/2018 ©2008 BMC Software

Federation of Data What is “Federation”?
Definition: Federation refers to a central repository holding Configuration Items and Relationships directly, while linking to other data in other sources There are two types of data to federate: Data you might choose to federate if you want to track it, but not track it as often or as vigorously as a CI’s key attributes (Extended Data) Data referenced by a CI to provide additional content related to the functionality of the CI, but not part of the CI itself (Related Data) Federation of Data: Federation refers to a central repository holding some data directly, while linking to other data in other sources From the library card catalog example, the CMDB is the Card Catalog, or directory service and the extended and related data are the shelves of books holding the related data. There are two types of data to federate: Data you might choose to federate if you want to track it, but not track it as often or as vigorously as a CI’s key attributes AND: Data referenced by a CI to provide additional content on extended functionality to the CI, but not part of the CI itself Example for data type 1:For example, the CMDB record for an employee might have a Skills attribute that contains a list of the employee’s skills, and a Department attribute that contains the employee’s department name. It might also be involved in a relationship with an HR data store where additional attributes, like Salary, that are not really important from a configuration perspective are stored. Example for data type 2:For example, your CI records for software instances might have a License relationship containing the URL to an intranet page where the license is posted, or each CI record might have a Problem relationship that contains the information necessary to search a problem 11/7/2018 ©2008 BMC Software

Federation Best Practices
Practical Federation Examples Financial Data Federated Link to SAP/Oracle Financials This could relate cost information, vendor information, contract information Applications Software inventory can consume a lot of space in the CMDB. If it is not critical for your business to manage in CMDB consider federating these items. Can be done with Configuration Discovery with configuration. Incidents, Problems, Changes These are federated out of the box in ITSM v7. 11/7/2018 ©2008 BMC Software

CDM Usage Understand Common Data Model usage Software Inventory
Product Patches Application Deployment Model Business Service Application Software Server Database Server 11/7/2018 ©2008 BMC Software

Understanding Software Inventory
The Application Inventory model captures the static aspect of applications, i.e. what is installed in terms of packages, products and patches. Products are captured as instances of BMC_Product Patches are captured as instances of BMC_Patch. Both classes are subclasses of the BMC_Software and ultimately of BMC_SystemComponent. According to the definition of a BMC_SystemComponent, each instance of a product or of a patch is associated to the scoping ComputerSystem by the BMC_HostedSystemComponents relationship. 11/7/2018 ©2008 BMC Software

Modeling Software Inventory - Product
(source) (destination) 11/7/2018 ©2008 BMC Software

Modeling Software Inventory - Patch
(source) (destination) 11/7/2018 ©2008 BMC Software

Understanding BMC_BusinessService
Describes what is delivered by a business, organization, or system. A service offered from one company to another, or from one organization to another within a business. A business service is delivered, not performed or executed However it may have operational hours, service level agreements, and access points which can be monitored for availability. Business Process describes how Activities are performed to deliver a business service A business service has a measurable value to its consumers. Edited bullet 2 11/7/2018 ©2008 BMC Software

Mapping a Business Process to Application
Order Fulfillment BMC_ Dependency Order Processing Order Billing Order Shipping Verify Account Info Check Inventory DB Send Invoice Locate Product Inventory Admin Inventory Admin Billing Admin Shipping Admin This is not a class diagram, so arrows indicate impact direction only Order Processing Asset Inventory Order Billing Shipping 11/7/2018 ©2008 BMC Software

Understanding BMC_Application
Captures standalone applications or applications deployed on Application Servers. Examples include J2EE and SAP An application is associated to either: a hosting Computer System (physical or virtual) a hosting Application System (SoftwareServer) 11/7/2018 ©2008 BMC Software

Understanding BMC_SoftwareServer
Captures Software that provides a single Service to client application or other systems. Examples include: DB servers, Web servers, DNS servers Directory Servers A SoftwareServer is associated to a physical or virtual computer system. 11/7/2018 ©2008 BMC Software

Modeling Software Server
11/7/2018 ©2008 BMC Software

Mapping Application to a Software Server
Order Billing Server-2007 Order Processing BMC_ Dependency Name=DeployedApplication BMC_ Dependency Name=ApplicationSystemComputer Note: Relationships can also be established between the SoftwareServer and OperatingSystem & Product. These relationships are optional. Database A BMC_ HostedSystemComponent 11/7/2018 ©2008 BMC Software

Modeling Database Server
11/7/2018 ©2008 BMC Software

Identifying Join Forms for Regular Classes
11/7/2018 ©2008 BMC Software

Identifying Categorization Classes Join Forms
All attributes are on the Super Class table The attributes are only used in the view when the classification is Processor The single record contains the classification value – “Processor” 11/7/2018 ©2008 BMC Software

Additional Best Practices for Adding a Custom Class
Will you create a regular or a categorization class? Where will you place your class within the data model? Which CDM class(es) will be the superclass(es) of your custom class? Whenever possible, create a categorization class vs. a regular class Create a regular class if the new CI Has a unique attribute that is required You anticipate a large number of entries for this CI The CI has more than twenty attributes Placing a Custom Class Within the Data Model Avoid excessive nested joins that will slow performance Do not create a regular subclass that is deeper than five join levels Refer to the CIM produced by the DMTF for guidance on class location 11/7/2018 ©2008 BMC Software

CMDB Extension Packs Available Extensions Packs
Included with Topology Discovery. BMC is planning to make them available for download to CMDB customers that do not have TD. Mainframe Siebel Advanced Network J2EE SAP Business Processes Web Services Other BMC Products also ship with additional extensions. BMC Remedy Asset Management BMC Transaction Management BMC Service Impact Management 11/7/2018 ©2008 BMC Software

CMDB-Enabled BMC Atrium Integration Engine (AIE)
Create Data mappings directly to BMC Atrium CMDB Common Data Model AIE also handle relationships between classes Extensible solution to get any external data into CMDB BMC Configuration Discovery CMDB Enabled AIE Mapping Technology Synchronization Import/Export Multi - threaded Third Party Data Source AIE Adapters Oracle Adapter SQL Adapter DB2 Adapter XML, CSV file adapter Custom Adapters Third Party Discovery 11/7/2018 ©2008 BMC Software 44

3rd Party Discovery Various open Source integration are now available for following data sources ( ) HP Peregrine Asset Center to BMC Atrium CMDB (HPAC2CMDB) Microsoft SMS to BMC Atrium CMDB (SMS2CMDB) LANDesk to BMC Atrium CMDB (LAND2CMDB) Altiris to BMC Atrium CMDB (ALT2CMDB) CiscoWorks to BMC Atrium CMDB (CWKS2CMDB) Other 3rd Party data can be loaded or federated 11/7/2018 ©2008 BMC Software

Implementation Thoughts
Defining CIs using “the level to which we manage” is not absolute – contracts, for example, required us to track certain server processors as CIs due to licensing compliance. Licensing could be: Per box Per cpu physical (wholly used) Per cpu physical (partially used) Per cpu logical (multi-core) Per virtual server Agree to model a few critical services (ocean boiling not allowed), thus validating approach early on CTI deadlock overcome by introducing the services concept (a clear data model) CMDB allowed representation of virtual servers Focus in Impact relationships in anticipation of Service Impact Manager Concept of Systems in an hierarchical data model solved several referential problems 11/7/2018 ©2008 BMC Software

Implementation Thoughts
Use lots of carrots, lots of stick Adhere to OOTB mentality (and the CDM provided with CMDB) to simplify relationship representation Consider limiting relationships to Impact, Dependency and Component Database expertise can be instrumental in transferring data from legacy systems Operations should lead the charge, and should not have to be dragged to the trough Leadership buy-in is key to succes Best practices “rule” – and ITIL wins all ties Without this type project there could be poor audit results (especially SOX) Unable to demonstrate auditable approvals Unable to demonstrate exactly what was changed Unable to demonstrate knowledge of systems impacted “manual processes are audited multiple times, automated processes are assumed to work consistently” 11/7/2018 ©2008 BMC Software

Process Improvement Suggestions
Service Desk should leverage CI data from CMDB to resolve issue more quickly Change Management Process Improvement Create predefined tasks for repetitive tasks. Review standard offerings. Are they meeting their SLAs? Where could number of steps be reduced or time other wise saved? Federate data were applicable to avoid double-keying of some CI information Must establish process-centric approach and continually improve to achieve accuracy goals 11/7/2018 ©2008 BMC Software

Technical Tips Use the CMDB as a directory, not a data warehouse – single point of reference Store less important or infrequently used CI attributes outside the CMDB via federation Justify adding attributes specifically to BMC_BaseElement root class Understand differences and usage of Abstract, Categorization and Regular classes Review flexibility of OOTB relationships (should be categorization 95% of time): Element Location – relates CI to physical location Component – composite objects – computers, disk drives, monitors, software, cards, etc. Dependency – CI dependent on each other such as program, app server and database Member of Collection – define network topology (i.e., domain) or business process or service Use indexing as appropriate on key attributes Frequent searches Do not define QBE Match of Anywhere for character field included in an index Do not create indexes during production hours Do not create indexes on fields that allow greater than 255 characters Do not create indexes on fields for form with less than 1000 records, unless Unique index 11/7/2018 ©2008 BMC Software

Technical Tips Take time to model on paper the proposed design changes
Thoroughly review and understand CDM to limit need for adding classes and attributes Merge discovery datasets sources into single dataset before merge with production dataset Compares best discovered instance data against production dataset Eases management of managing differences between reconciled dataset and production Limits number of compare and merge activities occurring against production dataset During development limit scope with qualification groups, test datasets, recon jobs and logs Reconciliation engine best practices: After initial data load into CMDB, perform Identification activity – ensure production data has ID Leverage multithreading to break up large jobs and run concurrently (limit to 2x # of CPU’s) Schedule discoveries and reconciliations based on frequency of changes Routinely audit Identification and Precedence criteria Ensure Activity Type – Execute Job does not call the same job or have endless loop 11/7/2018 ©2008 BMC Software

Technical Tips For permissions if CMDB represents single organization use CMDB Data View All and CMDB Data Change All roles as opposed to using multitenancy environment (CMDBWriteSecurity and CMDBRowLevelSecurity) Use existing classes that map closely rather than adding an additional class Category, Type and Item attributes provide method to qualify further within general class Do not change the name of classes in the CDM. Can interfere with integrations If custom attributes must be added to existing class Only if variations of CI can not be accommodated using context of general CI This approach does not work if required attributes are specific to certain instances of CIs Create categorization class instead of a regular class Joins associated with regular classes are more labor intensive Create regular class if new CI has unique attribute required Avoid excessive nested joins that impact performance Avoid creating regular subclass deeper than five join levels 11/7/2018 ©2008 BMC Software

Technical Tips Use caution when deleting a class as all subclasses below it will be deleted Never delete classes that are part of the BMC supplied CDM Workflow triggered from RE activities such as Comparison is available, however Do not modify OOTB filters attached to classes When possible, add customizations to consumer applications Document any customizations Define scope of customization – one or several classes 11/7/2018 ©2008 BMC Software

Questions 11/7/2018

Atrium CMDB Considerations & Lessons Learned

Similar presentations

Presentation on theme: "Atrium CMDB Considerations & Lessons Learned"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Atrium CMDB Considerations & Lessons Learned

Similar presentations

Presentation on theme: "Atrium CMDB Considerations & Lessons Learned"— Presentation transcript:

Similar presentations

About project

Feedback