Skip to main content

CMDB

Best Practice: Implementing an IT documentation and CMDB solution

IT documentation projects are often undertaken because no comprehensive overview of all IT components exists. These are often spread across a company in wikis, Excel and Word documents, various ERP systems or even inventory lists.

In this sort of scenario, a CMDB would serve as a centralised repository for your entire IT inventory and also as a basis for good IT planning. With a proven CMDB system you can, for example, choose both rack space and a dedicated IP address before you even order a server. Once the server has been delivered, all parties know exactly where it is to be installed, what power source is to be used as well as other specific details that significantly reduce workloads. Increased transparency in your company's IT business is also a positive side effect and indeed one delivered by the employees themselves.

Gaining clarity

An overview of all items included in the CMDB must be achieved as a first step. In addition to company locations and buildings and rooms, good, comprehensive IT documentation should cover servers, maintenance contracts, IT addresses, cabling, storage systems, clusters, installed software, licences, clients and other components. When implementing such a system, the first and most basic items to be recorded in the i-doit IT documentation software should be buildings, architectural elements and locations. Once this has been done, you can then add servers, switches, cabling and other system components. At the same time, you can also use the JDisc discovery software to automatically locate and import further devices into your i-doit system. JDisc will save you a great deal of manual effort even if you find a certain amount of manual adjustment of the data is required once it has been discovered and imported into the system.

Expert opinion

It is highly recommended that you use the automatic, one-time import feature from JDisc into i-doit when initially populating the CMDB with data.

Creating policies

Creating policies for adding items to the system and providing thorough training for your staff are extremely important. During training, you must ensure that employees are repeatedly reminded of the importance of adhering to the new processes and tools so that they don't fall back into bad habits, such as updating and using their now out-dated Excel spreadsheets and other superfluous asset tracking methods. Users often report that the continued use of familiar workflows can tremendously complicate the creation of a CMDB and that the only thing that helps here is a regular review of work and a bit of helpful "nudging".

Continuously updating the CMDB

Another best practice policy is to regularly update the CMDB: To achieve a target of 98% valid data in the system, this information must be repeatedly checked each year to remove any "dead wood". This is where the JDisc IT discovery solution comes into its own: It will independently scour your IT network, automatically discovering and adding new components to your existing i-doit system. Another indispensable element in correctly using your CMDB is the creation of checklists that your employees can use to record new items and that will serve to describe which procedures are applicable for what devices (e.g. when commissioning a new server, etc.).

Ensuring data quality

Your two greatest challenge will always be implementing your new documentation and getting your employees to stop using their old workflows. We strongly recommend you proactively achieve early buy-in from all stakeholders. In doing this, it is very helpful to make repeated, friendly enquiries about what information your employees need to accomplish their work so that you firmly establish a basic acceptance of the new system. At the same time, it is also necessary – especially in the early days – to review and track the data being entered and those entering it, if the rules are not being observed.

Agentless detection of items

There are always companies that don't want to have any agents or scripts running on their systems. The solution is using the agentless and scriptless discovery solution, JDisc. Additionally, you can request data via the open interfaces provided by i-doit and openITCOCKPIT. When dealing with particularly stubborn customers, we recommend asking them to supply the necessary data. Then, they will have to do all the requisite work themselves and will immediately become more receptive to the idea of installing agents to simplify this task.

Practical example

Added value through the integrated use of monitoring, CMDB and ticketing

A utilities provider in Hessen, Germany, combined their IT documentation with their system monitoring and achieved not just a comprehensive overview of all their IT components, but also a complete overview of each item's status. Using the ITSM stack, which is a combination of network monitoring, IT documentation and a ticketing system, this utilities provider put in place a comprehensive open source solution that covered all their needs: openITCOCKPIT for their infrastructure monitoring, i-doit as their CMDB and OTRS for their helpdesk needs. The company became aware of openITCOCKPIT because they were looking for a cost-effective product that was easy to use and provided plenty of interfaces and monitoring support for SAP.

It is important to emphasise how much easier the three systems are to maintain once these solutions are in place. With just two steps, items can be transferred from i-doit into openITCOCKPIT, where automated monitoring schedules can be applied. This means only one system now needs to be maintained – the CMDB – while the status of all services and devices recorded in openITCOCKPIT are also displayed in i-doit. By using the openITCOCKPIT reporting function, it is possible to see which servers have been down for how long or what components (if any) are defective and need to be replaced. If a service is down, a trouble ticket is automatically created in OTRS. Once the ticket has been successfully processed, this information is then, in turn, passed back to i-doit and openITCOCKPIT. Using interfaces, this data can automatically be written into the i-doit logbook so that a historical record of an item's lifecycle can be created.

Because the three systems are in constant contact with each other, all data is kept completely up-to-date in real time. This means not only are you assured that all information is current, but also that any manual administration of the system is greatly reduced.

Most CMDB system do a good job technically of scanning different operating systems, taking an inventory of a company's hardware and software and performing a reliable network discovery. The decisive point, however, in a successful CMDB project is soft skills. Successful CMDB projects initially start off small and then grow incrementally. Policy frameworks not only need to be worked out for employees, they also need to be implemented with a gentle, but firm hand. Only once the CMDB is operational and is continuously maintained and updated can it begin do its job efficiently.

Benefits of a CMDB

Centralised information hub for the entire software, hardware and services lifecycle

Network documentation and a server / software inventory quickly provide all relevant information to support staff in the event of an outage.

By mapping interdependencies between services and assets, impact analyses can predict the ramifications of outages as well as provide an assessment of imminent SLA violations

An essential building block in establishing a service-oriented organisation