What was once known as ITIL configuration management no longer exists in the same form or approach. However, the core principles – recording what will come, what currently exists, and what once was – remain intact. Those familiar with PRINCE2 might recall that it also had a configuration management component, though its meaning differed from what ITIL specialists referred to. In the past, architects documented IT landscapes in designs and architectural blueprints. Risk and continuity managers focused on CIA ratings, audits, and findings concerning so-called assets. The finance department also talked about assets but meant something entirely different. Meanwhile, the technology itself, as well as its management, has significantly evolved. And then AI arrived, turning the world upside down once again.

Configuration Management: No Longer a Manual Process

The days of configuration management as a manual process, where data was painstakingly entered and maintained, are over. Today, Change Management no longer determines what should be recorded in the CMDB. Instead, automated tools detect what is actually present with a granularity and accuracy that manual processes could never achieve.

The speed of change and the growing complexity of IT landscapes make a manual approach unsustainable. Discovery and monitoring tools have taken over, detecting not only devices and configurations but also real-time relationships and dependencies. This creates a dynamic, up-to-date view of the environment that manual processes simply cannot replicate.

Change Management now plays a different role. Rather than managing the CMDB’s contents, it focuses on recording changes at a higher level, such as policies and processes. The actual configuration data is fully automated, supplied, and maintained by intelligent systems. This shift allows organizations to respond more accurately and quickly to changes while minimizing human error and preventing data leaks caused by manual entry.

In a world where speed and precision are critical, manual configuration management has become obsolete. Automation ensures the CMDB is always a reliable representation of reality, independent of human intervention. This not only improves data quality but also enhances overall IT management efficiency.

Products and Instances

Modern IT landscapes distinguish between products and instances of those products.

  • Products are the designs, specifications, or plans – a model, either physical or logical, or even something delivered “as a Service.”
  • Instances are the actual implementations of those products – what is installed, provisioned, deployed, or rolled out. An instance is a unique manifestation of a product

For example, the Volvo V70 is a product, with its specifications detailed in a brochure. The Volvo V70 with license plate “XX-YY-ZZ” is an instance of that product, adhering to all its specifications. Products can have versions; multiple iterations of the Volvo V70 were produced, each with unique features and specifications.

A company’s digital portfolio encompasses both products and their instances, though they are often managed differently. Some departments focus exclusively on products, while others deal with instances or a mix of both.

Data Segments in the Digital Portfolio

A modern digital portfolio consists of four data segments with interconnected objects:

  1. Foundational Data: Core data central to the organization.
  2. (Product) Baselines: Models, designs, specifications, commitments, entitlements, and capabilities.
  3. (Product) Components: Documentation, configurations, and technical building blocks.
  4. (Product & Component) Instances: Information about who uses them, where they run, and their purpose.

Various processes, such as tasks, plans, and budgets, reference these artifacts. Here’s a breakdown of responsibilities:

  • Enterprise Architects define the IT landscape, including high-level baselines, ownership, dependencies, and information storage. They outline the current state, the desired state, and the roadmap to transition between the two.
  • Product/Platform Owners manage demand, plans, contracts, and forecasts for products baselines and instances. They are responsible for building, procuring, and implementing them. They define the product that is delivered “as a Service” .
  • Developers create, maintain, document, and test product components.
  • Service Delivery Managers ensure that instances meet specifications and commitments.
  • Security and Continuity Managers classify baselines, identify risks, and periodically audit the effectiveness of mitigating measures.

Data Management and Automation

Each data segment is managed differently:

  • Foundational Data is maintained by respective data owners in their systems (e.g., HR data in HR systems).
  • Product Baselines are defined by product owners and architects and recorded in a centralized tool.
  • Product Components are managed in technical repositories and deployed via CI/CD pipelines.
  • Product Instances are automatically discovered or periodically delivered from source data to a CMDB.

Automation is pivotal. Discovery algorithms and integrations are maintained by platform teams, while manual updates in target systems are discouraged to avoid shadow data and compliance issues.

Although most data is collected automatically, ensuring its quality remains vital. Automated completeness and compliance checks, periodic audits, and reviews of discovery logs all contribute to maintaining high data standards. Fixing data outside the source system is strongly discouraged, as it leads to inconsistencies and compliance risks.

Conclusion

In an increasingly automated world, consistency and simplicity in data management are essential. Each of the four data segments must be well-integrated and maintained, with attention to data quality and interdependencies. This demands discipline, strict processes, and a shared understanding of what products, instances, and their relationships mean in the digital landscape. Configuration management is no longer what it once was – and that’s a good thing.