A list of servers can be accurate while still leaving a team unable to explain what a planned change might affect. That uncertainty comes from missing relationships between infrastructure, applications and services. A configuration management database should make those relationships useful in operational decisions. Choosing CMDB software therefore starts with the questions people need to answer before a change or during an interruption.
Build the evaluation around one important service
A CMDB is a repository of configuration items and the relationships between them. A configuration item, often called a CI, is an element that the organisation chooses to record and manage for service purposes. The evaluation should begin with a service whose operation the team understands reasonably well. A contained example makes it possible to check whether the database reflects reality without turning the selection process into an inventory of everything the company owns.
Consider a hypothetical internal reporting service. Users depend on an application, which relies on a database and several infrastructure components. There may also be supporting authentication or network services. Ask the team to describe which dependencies matter when one component changes. Record uncertainty rather than guessing. The resulting questions provide a practical test of how each proposed CMDB represents relationships and supports their verification.
Agree on the meaning of relationship types. A connection labelled “associated with” may be too vague to support an operational decision. Staff need to understand whether one item hosts another, depends on it or is maintained by a particular team. The chosen terminology should be consistent enough for different people to interpret the same record. Ask participants to explain a small model without help from its author and note where their explanations diverge.
The model also needs boundaries. A service might rely on an external supplier, but the organisation may have little visibility into that supplier’s infrastructure. Represent the dependency at the level that supports your own decisions and responsibilities. Avoid creating detailed records that nobody can verify. A useful CMDB can make uncertainty and ownership visible; it does not need to claim complete knowledge of every component outside the company’s control.
Evaluate how records behave over time. A replaced server, renamed application or retired dependency should not leave the team interpreting old information as current. Use a trial change to test the update process and the availability of history. Ask who decides that a relationship is obsolete and how the decision is recorded. These details matter because impact assessment depends on the state of the environment at the relevant moment.
Compare relationship modelling and the way information is maintained
When reviewing a CMDB software ranking, focus on the candidates’ ability to support the model you have already described. Give suppliers the same service example and ask them to show its components, relationships and responsible teams. Then ask an evaluator to answer a specific question, such as which service owner should be consulted before a component changes. The exercise tests practical understanding rather than the visual appeal of a dependency map.
Check both graphical and record-based views. A diagram can help explain a service, while a structured view may be more convenient for reviewing attributes or filtering incomplete records. Neither format guarantees that the relationships are correct. Ask users to identify the origin and last review of an important connection. The value comes from a dependable explanation of the environment, supported by views that fit the work people need to perform.
OXARI CMDB is part of the service management software developed by Infonet Projekt. The ITManager website describes support for custom configuration item types, relationship modelling and integration with ServiceDesk. These capabilities make it a candidate for organisations that want to connect configuration information with request handling. A trial should establish how the organisation’s chosen service model, data sources and ownership rules work in that environment.
Data import should be tested with imperfect information. Provide a small sample containing a duplicate identifier, a missing owner and a component described differently in two sources. Ask how the platform identifies or exposes the conflict and how a person resolves it. A successful import of clean data says little about maintenance. The organisation needs a repeatable way to recognise inconsistencies without allowing a new feed to overwrite useful context silently.
Some information can be collected from technical sources, while service responsibility may require confirmation from people. Decide which source is authoritative for each important attribute or relationship. If two sources disagree, there should be a defined review path. Ask how evaluators can see the age of information and whether an update was automated or manually approved. Maintaining trust is part of the selection problem, not a task to postpone until after launch.
Test the CMDB in a change and an incident scenario
A pilot should connect the model to an actual decision. For a planned change, ask the team to identify the relevant components, potentially affected services and people responsible for reviewing the proposal. Check whether the information is sufficient to plan verification and recovery. The CMDB should inform the assessment, while the team remains responsible for judging the change and checking assumptions. A recorded dependency alone does not establish the outcome of work on a component.
Then test an interruption. Provide a symptom affecting the selected service and ask participants to use the trial records to narrow their investigation. Observe whether the model gives them useful context or sends them through irrelevant connections. Ask them to document missing relationships discovered during the exercise. This produces an improvement backlog grounded in operational use and prevents the pilot from becoming a demonstration of a database nobody will maintain.
Assign ownership for the model after implementation. Someone should approve changes to item types and relationship terminology, while designated teams maintain their part of the information. Establish a review approach proportionate to the importance and rate of change of each service. It is often more practical to improve a limited set of useful records than to expand the database faster than the organisation can verify it.
The purchasing decision should account for data preparation, integrations and ongoing review work alongside the licence. Compare candidates using the same service model and document the questions each trial answered successfully. Choose the platform that helps people make a defensible assessment of impact and recognise what still needs checking. That provides a stronger foundation than selecting a database because it can hold the largest possible number of records.
Sponsord article