Importance of organizing Data in the CMDB - ITIL Concepts

Getting data out of the many sources you find it in is the most difficult part of populating a CMDB. Next comes the easier part—planning how you will actually put the data into your still pristine database.

The Importance of Naming Conventions

Naming conventions are absolutely difficult, but it is imperative that you define the naming conventions for all of your data in the planning process.The proper transformation of data which needs to be put into database is not possible until you establish good rules for naming data. Having some documented way to name instances of each category will allow the identification of configuration items to proceed smoothly, but it is hardly the end of naming. As a special case of naming conventions, there are many discrete value lists that can make recording and searching configuration data easier. Some important lists that you will undoubtedly have are the list of all the possible statuses, the list that identifies the criticality of any configuration item, the list of manufacturers for any hardware items, and the list of organizations that might be owners of CIs.

If you have an existing system that tracks all of your in-house developed business applications, the logical naming convention for applications would be to use the unique identifier from that system. On the other hand, if you are going to get data from a wall-to-wall inventory of hardware, it might make sense to incorporate the external asset tag into the naming scheme.

One very important point is that names are much harder to change than they are to create initially. Never use a variable that might change as part of the name of a configuration item, or you will have misleading data in your CMDB as changes occur.

Normalizing and Integrating Data Sources

The second step is to mix up these disparate sources of data to form a single CMDB. The problem will be broken down to two elements – normalizing data and integrating data. In a perfect world, each person would have a unique identifier, such as an employee number, and that number would be the same in both systems. In a less than perfect world, you need to choose the most desirable common data field and build a conversion table to match the data together.

Formatting the data helps some with the problem of normalization, but completely normalizing data cannot be done until after all available sources are brought together. After all the data is linked together by the best possible common fields, it is time to plan for integrating the data.

Integration involves taking all the best parts of the data to include into the CMDB. It is important to have a strong integration plan because the integration will not be a one-time event. As the data in the asset database, the corporate directory, the discovery tools, and all the other data sources changes, you want to reflect those changes through some kind of automated process into the CMDB. These are the most important steps in the plan for ensuring you’ll end up with an accurate and usable CMDB.

Federated Data Models

Finally, a word about the physical storage of data. One of the key buzzwords in configuration management is federation. Although federation is a technical term from the database field, it is used in configuration management to indicate grouping data from several different sources. This grouping can be as simple as moving data from each source into the same single place, or as complex as an indexing scheme that leaves the data stored in its original source but provides access to it from the CMDB.

Let’s check out the simplest case of federation. Imagine you have an asset database full of hardware and software information and an LDAP directory that holds information about the people in your organization.

Building the programs that move both the information together to a single relational data base would be the simplest form of federation. A database administrator would recognize this architectural pattern as simple batch loading of data, as illustrated in Figure. This is the model that most configuration management tools today support.

Federated Data Models

Batch loaders can input data physically to the CMDB.

The more complex case allows for data to remain resident in many different locations but provides a single interface that can query and possibly even update that data.The work of this interface is to copy the data to a CMDB as and when updated, and if built as a two way bridge, could update sources when the CMDB gets updated. This can be done using sophisticated programming and this pattern is called Data Bridge. This can be seen in the Figure .

Batch loaders can input data physically to the CMDB.

It is possible to simulate federation using a two-way data bridge.

The third model is actually what database gurus would call a federated database. Here the data never gets transferred physically. Instead CMDB maintains a pointer to the data. The advantage of this model is that the formatting and transforming of data are completely programmed as rules of federation, and after those rules are established, your data is updated at the source rather than in the CMDB.

It is possible to simulate federation using a two-way data bridge.

True federation leaves data at its source, but references it with pointers

A data model can be chose according to the tools you select .


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

ITIL Concepts Topics