The asset repositories (or CMDB) used within IT operations are critical elements of the information system. In the field, we observe that these repositories suffer from one or more of the following flaws:
– They are ageing;
– Their data is unreliable;
– They are hard to use;
– Essential information is missing.
In this article we look at the problems these flaws cause for the organisation, and suggest ways to address them.
The consequences of the ineffectiveness of repositories
These repository flaws can impact both the BUILD and the RUN:
Impacts on the BUILD:
– Slower IT transformation projects, which need usable data during the design, build and deployment phases;
– Projects must either take on making the CMDB reliable themselves, or only partially cover their scope;
– Tactical recourse to many one-off requests to the teams to obtain additional elements through time-consuming manual extractions.
Impact on the RUN:
– Higher complexity and cost of maintaining the repository over time;
– Lower reliability of the inventories needed for various purposes: auditability, re-invoicing, day-to-day visibility and control of the IS;
– Teams building local repositories (“shadow CMDB”), which are less rigid and undermine the CMDB’s Single Source of Truth (SSOT) logic.
These impacts cause the organisation unplanned costs as well as significant security risks, very often underestimated.
Structuring along a Product logic
One way to solve these problems is to consider the CMDB as an essential IT process in its own right, which must:
– Be formally described and documented;
– Be embodied by someone who guarantees that it works properly.
The CMDB then lends itself particularly well to a Product logic, carried by a Product Owner who:
– Ensures its functional evolution with an adoption and UX logic, listening to user feedback;
– Ensures its technological evolution;
– Runs the governance that manages its lifecycle.
So that the Product Owner can work hand in hand with application owners and IT service owners, it is wise to:
– Make the owner of each application scope accountable for the reliability and completeness of their data;
– Lead IT service owners, at each service creation or change, to ask themselves: “How can this change exploit, enrich or complete the CMDB, for better visibility and control of the IS?”
Once this list is established, several actions must be carried out. First, think about a “No IT” process (a process that can run temporarily, even in a degraded way, with a simple extract of the application’s data) for the applications that allow it. And for these, are there prerequisites (drafting a simplified operating procedure, awareness-raising, etc.) for this way of working?
Taking CMDB challenges into account in projects
Faced with these many difficulties, IT operations frequently show a perpetual wait for the project that will update the CMDB and make it reliable. Unfortunately there is no miracle cure: the CMDB must be seen as an IT process that must be alive and continuous.
To ensure the CMDB’s challenges are properly taken into account, each project must bear the responsibility of interfacing with the CMDB to use it, populate it and enrich it. This interfacing can be guaranteed by a project gating step where the CMDB Product Owner gives their validation.
Improving the usability of the CMDB
The CMDB often contains too much information whose usefulness is unproven and which discourages the teams from populating it. To improve its usability, the CMDB should contain only the information that is really necessary, to limit the effort associated with populating it. It should also be enriched with key information that is too often missing:
– Application ownership of IT assets;
– Technical and application interdependencies;
– Applicable regulations and standards (LPM, PCI-DSS…);
– Re-invoicing allocation keys, to allow proper budget allocation of assets to the different customers.
Checking the reliability of the CMDB
To check the reliability of the CMDB and remedy its flaws, a control plan can be considered, which compares the data from all the tooling that enables asset discovery: SCCM, vulnerability scanners, various probes… and raises an action plan to deal with any inconsistencies between these repositories.
To this discovery process must be added an automated, permanent process for detecting items presumed decommissioned. Frequent human handling (at least monthly) must be carried out: on the item itself (deletion / update) but also on the organisation’s IT processes, so that in a similar future case the item is deleted or updated even before being detected by this last-resort process.