What is a CMDB

A configuration management database (CMDB) is a database that contains all relevant service management information about the components of an information system and the relationships between those components.

A CMDB provides an organized view of that data and a means of examining that data from any desired perspective. Within this context, components of an information system are referred to as configuration items.  A configuration item can be any conceivable IT component, including software, hardware, documentation, and personnel, as well as any combination of them. The processes of configuration management seek to specify, control, and track configuration items and any changes made to them in a comprehensive and systematic fashion.

Importance of CMDB

A comprehensive CMDB is a very important tool in a complex and diverse environment as this allows the sharing of information across teams, infrastructures and applications.  This sharing will then facilitate communication and collaboration between teams.

A good CMDB will also help its users understand and visualise the environments that are being managed and the services that are being provided.  This is achieved by linking records and creating relationships between the various environment components and the services that are used to manage them.

Technical challenges

Creating an effective CMDB can be a very challenging task.  This is especially difficult if several tools are being used to manage the various environments.

A typical large organization may use separate tools to manage requirements, documents, test cases, inventory, defects, changes, and releases.  In such an organization, creating a single CMDB would be practically impossible as relating and linking data across different tools is either difficult (or impossible) without extensive customisation and development work.

The technical challenges are compounded if different vendors provide the various tools.  In such a situation, you may find it impossible to connect the various tools together without infringing the supplier warranties.  A further complication arises when different vendors upgrade their products leaving your integration broken and unworkable.

Virtual CMDB

Creating a CMDB where the core data is managed in different tools can be simplified by creating a virtual CMDB.  This is sometimes referred to as a federated CMDB.

With a virtual CMDB the master data resides in the various tools and this is then pulled into the Virtual CMDB repository. Once in the repository this data can be related to each other to provide some of the benefits of a CMDB.

Using a virtual CMDB does not overcome the technical challenges of integrating tools from different vendors.  The main difference here is that the virtual CMDB supplier will provide you with tools to pick up the necessary data from the various applications and then to map this data into a common and consistent format.  Using these tools still requires a lot of technical knowledge and the user will have to understand how the data is organised in the various tools and how this should be mapped to the correct format.

In reality, a virtual (or federated CMDB) is a poor solution to a very complex problem.  In addition, this problem only arises because the various tools that are being integrated to create the CMDB are supplied by different competing suppliers.  The absence of standards for data format and sharing makes this problem more complex than it needs to be.

Using cmwforms

cmwforms eliminates all of the challenges associated with creating a CMDB by:

1. Providing a single integrated environment with all the applications that are used and needed by the CMDB.
2. Providing extensive features to link and relate records.  cmwforms does not impose any limitation on how records can be linked together.
3. Providing a simple and easy to use interface that can be used to visualise the relationship hierarchies.  This hierarchy viewer allows users to display related records and also view and edit the actual records.

On the technical side, cmwforms eliminates the need for any database knowledge and also provides a user friendly way to relating records without the need to worry about how the tables are structured or indexed and how the relationships are defined. 

If you try to create a CMDB on your own then you will need to:

1. Define the data model.
2. Define the integration points between the various tables.
3. Create indexes and constraints.
4. Create relationships, i.e. one-to-one, one-to-many.
5. Create relationship resolvers where a many-to-many relationship is needed.

Once all the above are defined you will need to create the tables, the queries and then the application to allow you to view and maintain the data.

When using cmwforms, all the above is totally unnecessary as you are able to relate records, within the tool, just as they are related in real life.

Relating records in cmwforms

When you create a record in any of the cmwforms applications the record automatically has a tab which can be used to create links with other records.

This tab has four commands:

• New.  This allows you to link the current record to a new record.  When you click this button a new record will be created and this will be linked to the current record automatically.  The New button allows you to select the type of record to create.
• Add.  This allows you to link the current record to an existing record.  You will be presented with a list of record types and then records to select from.
• Open.  This allows you to open a linked record for reading and/or editing.
• Delete.  This allows you to break a link between the current record and its related record.

The New button is a drop down button.  When you click New, cmwforms will automatically list all the applications that exist in the current workspace to which you have access.

In the above example, the current product record can be linked to any other record type supported in the current workspace.

When you use the Add command to create a link to an existing record then you will be presented with a record browser.  This browser includes a record type drop list.  By modifying the value in the drop list and then selecting one or more records you can create a link from the current record to one or more other records in a single go.

When linking records together cmwforms imposes two simple, yet logical restrictions.

1. You cannot create multiple links between two records.
2. You cannot create a circular or recursive link between two records.

Constrained relationships

In the previous section, we covered the process of creating unconstrained relationships between records, i.e. the user can select the type of the records to relate.

In certain cases, you may wish to guide users and provide them with recommended valid relationships.  For example, an incident may be raised against a service in the service catalogue.  This incident may be resolved using a combination of service requests and problems records.   When creating the incident application, the designer can specify in the application definition that this application has primary links to the service catalogue, service requests and problems.   cmwforms will automatically create the tab for each of these and the necessary commands to create and manipulate the links.

The constrained relationship is created in the application form definition by selecting the other applications and adding these as data lookup components.  The figure below shows the form definition for the incident record.

In the above example, the incident application will contain tabs to allow the users to link incident records to service catalogue, problem, and service requests.  The users can still link to other types of records but the CMW Incident form will contain dedicated tabs to show links to the service catalogue, service requests and problems.

When users create an incident, the incident record will have a tab for each of the data lookup links.

When using the New or Add buttons in the data lookup tabs, users will only be able to create links to records of the appropriate type, i.e. the users will not be presented with a list of record types.

The user can still create links to other types by using the unconstraint relationship feature.

Viewing relationships

cmwforms provides two separate methods for displaying relationships.

1. Using the data lookup tab.
2. Using the hierarchy viewer.

If users wish to view the child records for the current record then users should open the record and then select the data lookup tab or the related tab.

If users wish to view the child hierarchy for the current record then users should select the record in the browser and then bring up the context menu and select Child Hierarchy.

cmwforms will search all the related items and create a full list of all child records.

The above example shows the two main child records, Live Application Server and Live Database Server, and then all the related records below these.

You can view the child and parent hierarchy for each of the records in the same view.  You can also open each record by clicking on the document icon.

Understanding relationships

Relationships in cmwforms do not have any specific meaning or significance.  cmwforms encodes all relationships in the form of parent and child records.  If you open a record and from this create a link to another record then within cmwforms the first record is the parent and the second record is the child.

When using cmwforms you need to define, communicate and agree the meaning of each type of relationship with other users.  In most cases, users will be able to figure out what is being implied.   Here are some examples.

• If you link a requirement record with a design record and then to a test case record then most IT practitioners will understand that the design is derived from the requirement and the test case is derived from the design.

• If you link an incident to a service request then this would suggest that the incident is resolved using a service request.

• If you create a release record and link it to several change requests then the changes define the scope of the release.

• If a change is linked to one or more configuration items then this implies that the change affects the configuration items.

• If you create a server record and then link to it an OS record, a COTS record and one or more application records then this would imply that the various software packages are installed on the server.