Configuration Management and the Database (CMDB) helps manage, audit, and coordinate the change and configuration management processes.
Change management helps ensure that standardized procedures are used for efficient and prompt handling of all changes to control IT infrastructure.
In IBM Control Desk it is possible to create, assign, monitor, notify, and report on change requests and configuration items (CI’s). The tool provides a single source of information for understanding both discovered views and authorized views of an IT infrastructure item as well as change records and processes.
The CMDB provides standardized data of configurations and actual configuration items. In order to manage CI ’s and have them available to the change and configuration management processes, it is necessary to initialize (establish a base data set) the CMDB database after IBM
Control Desk is installed. As well as to enable the change functionality to ensure it supports and controls the changes within the organization that manage the configuration items.
Many organizations struggle with where or how to get started as the processes are so intertwined that it is difficult to determine how to begin. This document is going to assist you in thinking through what the current state of the processes are; is or what is the discovery approach and how to define data or processes for this implementation.
The diagram provided depicts how the CMDB - discovered configuration items interconnect to authorized CIs as well as to assets in order to support the change and configuration processes as well as other ITIL processes.
Assumptions have been made that the user of this document is familiar with the concepts of ITIL, has a general understanding of change and configuration management, and has working knowledge or education on discovery tools. It is important that the user of this document understand what configuration items (CI) and actual configuration items are and how a CI is used and supported in the change and configuration management processes.
Should you need to familiarize yourself with this information you can use the link to Project
Configure which can be found in the additional resources section of this document. There is a tab in the workbook that is focused on Configuration, Change and Release management, as well as a tab about discovery.
As every client situation can be unique it is possible that each implementation will have a different set of objectives and tools that may work into the project and approach. The information in this document provides assistance to help determine or understand where to begin.
Often the question surfaces, is it better to start with configuration management or change management processes. There are arguments for implementing one before the other or tackling the processes at the same time. Organizations have, and are finding success with, tackling both, but with a focus on an area of the business, a particular site (such as a data center), or perhaps focusing on a service and or application. Any of these options allow for a smaller sub set of data and analysis to ensure that procedures and policies will support the overall management areas and the business as a whole.
While taking on both processes for even a small set of data or site, it is necessary to consider:
the big picture and the full organization
ensure all decision makers are consulted and advised to work through different scenarios
a test or development system is set up with the thought that trial and error may be necessary
rate of adoption that can be handled throughout the organization, not just to use a new tool, but accepting of the processes
the data discovered, or configuration item data, can be populated, reviewed and accepted as production ready
To determine change before configuration or as the pair of processes, you may be influenced by the following:
Do you have a discovery tool implemented already? Is it TADDM or another discovery tool? o If yes, this may set the foundation to starting with configuration management first, even if it is focused on a small area of the business, a specific type of data or a specific location.
Are there Asset Management processes in place now? Such as this system may provide asset data as the foundation to change? o If yes, this may drive the decision to start with change management based on assets in order to establish a base process for change.
Can the set of tools you have function together based on vendor or integrations?
Such as API calls to load non TADDM data into IBM Control Desk, or Web calls for assets to be shared to IBM Control Desk? o If one set of data or processes is currently in a system that is still in play it can set the foundation to start with one that is not set up. This would allow the in place process to maintain business processing and connect to new data and structure.
Do you have configuration item and asset data or does that need establishing as part of this or another project? Is it being discovered but not interlocked to other processes and data-sets, like ticketing or change management. o If no configuration items or assets that are accurate exist it will tend to lend the decision to start with change management without either and to free form the configuration item until a source of CIs or assets can be established.
These factors and others will aid you as an organization in determining what approach will work for an implementation. There is no wrong answer or approach as long as it is based on facts and a logical approach. One approach however may be easier or more in-line with the organization and set of tools and processes established today.
As you think through the questions above it makes sense to focus on Change management and can it be enabled with or without CI’s or assets in a/the system? Here is some additional information to aid you in this thought process.
Establishing change without asset, configuration item records can be done, many do it to get started, however it requires strong discipline and well defined processes to ensure that correct and sufficient data is presented in the change record to be able to process the change through the management process.
While it will be important to capture the assets or CI’s that are a part of the change, the degree to which this data is captured will be based on what the organization can enforce. For example, it would be key to ensure the creator of the change provides the asset or CI they wish to change.
This is typically done in a field that is added to the change but is not validated against the CI or asset tables. Some organizations have taken the approach that Assets and CI’s will be created as part of the changes if this is the first time a change is applied against them. Then going forward others will use the created records from the asset and CI tables for future changes. This approach can work, but as stated requires discipline and a strong process for when an asset or
CI should be created and how the record will be validated to ensure standards and approved for use.
If the “create as the change process matures” approach is taken and discovery will not be in play, then it will be necessary to enable the system to support assets or
CI’s and ensure that the users are able to create them either on the fly or through a request.
There are reasons some clients may wish to start with change:
Doing change management can result in quick return because the customer will not introduce additional errors when doing change; however, it may increase time for the change to be created to ensure enough data is added to get the change through the approval process.
Governance is important when dealing with IT equipment and customers do not know what is being applied when or where. Thus they enable change to begin to control the processes and changes. This again may require additional data input if there are no assets to reference when creating the change.
If the organization does not plan to support a database of assets and CI’s then the enablement and configuration of the change application will be the critical piece of work to ensure that data is stored on the change record needed to approve the change.
Many organizations begin the implementation with the roll out of a discovery tool to begin to discover what is in their infrastructure and define what will be configuration items to be managed.
IBM of course has such a discovery tool; IBM Tivoli Application Dependency Discovery Manager
Beginning with configuration management through discovery will require policies and procedures to be established so the users and organization are aware of what can be discovered, what should or needs to be actual configuration items and what should be promoted to authorized and managed within the CMDB and with change. As noted this is not a one size fits all and if using a discovery tool understanding the model and structure of the discovered data is vital to decisions and design.
Customers who may own both IBM Control Desk and a discovery tool have some flexibility in terms of how to get started. Please be aware that IBM Control Desk and TADDM are quite tightly integrated for configuration management. Provided here are some suggestions and information to consider configuration as your starting point.
It is possible to utilize discovery to gain knowledge of a limited set of CI’s. This will enable you to understand the discovery tool and the data that is found and how it is structured, but also provide a level of data that can be moved into the CMDB for use in establishing/defining and learning configuration processes, and establishing the change processes. TADDM has a predefined connection through Integration Composer to load discovered configuration items into ICD.
During this acclimation period, you can utilize all the functions within IBM Control Desk to gain knowledge. This information can be removed from the database and reloaded from discovery source at some future point when the processes and product configuration stabilize and are moving towards a more serious test and production stage. Loading all details gathered from any discovery source into a system is absolutely not recommended. Always remember; in this tactical work, less is often more in the case of
CIs being moved to IBM Control Desk and then on to Authorized CIs.
The starting with discovery data for the foundation of configuration management can be very strong, it can also be very slow to start as it can often take several groups working
together to get discovery rolled out and or understood well enough to leverage into the
Control Desk system for constructive use.
A focus on a small set of data types or a single business service allows for the data to be clear and concise as well as lay a strong foundation to change management processes.
It is recommended to take a backup of the “empty” (new) database and restore to it after the testing and familiarization period is over.
Today CI’s are often brought into the actual configuration item tables typically from TADDM or another discovery source. The tool discovers the C I’s and this data is then populated to the
Actual CI application where the CI’s can then be promoted to Authorized CI’s and used by the change and configuration processes.
Since a configuration item often is also or can be an asset, understanding that interconnectivity allows for the full lifecycle of managing an asset and configuration item to be considered when starting with configuration management.
Example since an asset (server) would be also a configuration item during operations, would be under configuration management processes. The business flow at which to get that asset into the system and connected to its configuration item can be done in multiple ways. The diagram here presents a possible option for establishing the asset into the CMDB.
The asset is received or created,
then discovery of the item occurs, creating an Actual CI,
This can then be promoted to an Authorized CI.
At this point the CI is then connected to the asset record as required.
The CMDB in IBM Control Desk, when combined with discovery, can be used to automatically discover, federate, reconcile, and synchronize the IT resources in an organization.
It is not uncommon that your company may use a non IBM discovery tool, in these cases, Actual
CIs information can be loaded into IBM Control Desk through the IBM Tivoli Integration Composer tool, from one of two data source types: TADDM or a Discovery Library Book. - Commonly, incorrectly referred to as a DLA or IdML.
You will need to create CI ’s in your environment either manually or programmatically if you wish to start with configuration management.
Before loading CI information, you must activate the top-level CI types for which you want to load information. Only resources that are related to the active top-level CI types will be imported.
When pulling Actual CIs from TADDM the GUID field is filled in with the TADDM GUID, and ICD expects TADDM to be there for Launch in Context (LIC) from an Actual CI.
Without discovery data populated in the Actual CI tables of IBM Control Desk, you will not be able to leverage the following functions or do:
Promotion of Actual CIs to Authorize d CI’s
CI Audits – there is not data in the actual tables
CI updates will have to be done through other mechanisms, such as actual changes or discoveries to update the actual tables
Reconciliation or normalization
Common Data Model, although a subset exists within the Deployer ’s Workbench
If your business has assets and/or full asset management processes along with change it is recommended to start with asset management at least from the perspective of getting assets into the system for supporting the change and asset management processes.
While asset management data is not always fully constructed (details) to support change activities it can provide a strong structure for change to ensure changes are evaluated, impact assessed, and changes managed aid in lowering the unplanned issues in the organization.
Asset relationships in IBM Control Desk can be defined as parent/child and through locations, services, and service groups, these asset groupings can be viewed. It is possible to assess a certain level of impact and risk based on these available models.
Additionally using ICD it is also possible to create manually an asset based topology with relationships for assets should this desired. Further data can be found on this capability in the IBM Control Desk knowledge center.
If asset management is in place it would be recommended that a review of the assets and data construct be conducted to ensure the data will support the base change processes or can be updated to do so, such as ensuring there is an appropriate level of detail to the asset, perhaps server name, and does the asset store software (license) information associated to it?
Find a part of the business that wants to partner in this effort. Let this line of business gain the initial value out of CMDB. Discoveries can be done based on that line of business. By doing this it limits impact to the other parts of the organization and builds a framework from which others can adopt more quickly
Select an IT level of management servers as an example, or application XYZ. This limits exposure to allow a foundation of policy and procedures to be put in place and provides
Return On Investment to users
Leave some of the more advanced functions to last, such as audit control. It is important to do, but does not have to be there day one of production
The following links provide additional information;
Blue links take you to the IBM Control Desk project workbooks on the process automation community.
Project Start - Use this workbook as your guide to getting started with IBM Control Desk on
Project Configure - Use this workbook as your guide to configuring the IBM Control Desk on
Developer Works http://www.ibm.com/developerworks/wikis/display/tivoliaddm/Home