Practical systems support, shaped around the work.
Anonymized enterprise work - ongoing
Building a CMDB Foundation for an Established ITSM Organization
Anonymized, ongoing enterprise work that turns a broad CMDB initiative into an evidence-driven engineering process covering source readiness, identity, authority, reconciliation design, and implementation readiness.
Project category: Enterprise ITSM - CMDB design and governance. The client is described only as an established enterprise ITSM organization introducing a structured CMDB capability; its industry is not identified.
Anonymized enterprise workEvidence before configurationCMDB foundation for an established ITSM organization
Situation
An established organization had operated IT service-management processes for years and was introducing a more structured Configuration Management Database capability. The challenge was not installing a CMDB. Multiple systems already held information about technology assets, and before those sources could be trusted as inputs, the organization needed to understand what each source actually contained, who owned the data, which identifiers were stable, where information conflicted, which source might be authoritative for which attributes, and what evidence was still missing before implementation decisions could be approved.
Evidence boundary
The engagement is anonymized and ongoing. The organization is described only as an established enterprise ITSM organization introducing a structured CMDB capability; its industry is not identified. No client name, internal contact, location, source-system name, population detail, metric, or platform version is disclosed.
The engagement is ongoing; analysis and design do not equal production implementation.
No final business-performance metrics are claimed.
The supporting analysis tooling is an evidence and design system, not a production CMDB writer.
No CMDB deployment, incident reduction, MTTR improvement, or asset-accuracy percentage is claimed.
Objectives
Establish defensible source scope, ownership, and readiness before design
Understand identity, conflicts, freshness, and lifecycle semantics across sources
Develop class, attribute, authority, and reconciliation proposals grounded in evidence
Keep every decision traceable from evidence to eventual acceptance
V'Ali's role
CMDB engineering and source-system analysis
Source-owner discovery and stakeholder coordination
Representative evidence collection and data profiling
Stable-key and identity/correlation analysis
Class and attribute mapping proposals
Source-authority, reconciliation, and precedence analysis
Conflict and duplicate investigation
Governance, decision tracking, and evidence/decision traceability
Workshop and customer-safe deliverable preparation
Record 01 / Architecture
How the work fits together
Proposed source precedence can be simulated without changing the production CMDB, so evidence can accumulate before configuration is locked in.
Source categories are described generically. Real source-system names and population details are not published.
Record 03 / Work record
What the work covers
Source-readiness evaluation for each candidate source before design work relies on it, using a six-part readiness framework.
Cross-source analysis that compares individual technology assets across systems to expose matching values, conflicting values, missing values, duplicate records for the same apparent asset, different update timestamps, and potential rebuild or stale-record scenarios.
CMDB design proposals covering CI class scope, attribute mappings, source lineage, attribute authority, identification rules, reconciliation behavior, dataset strategy, relationship scope, and lifecycle behavior.
A supporting local analysis workbench that organizes source profiles, evidence records, mapping proposals, identification investigations, reconciliation simulations, decision records, validation controls, traceability, and customer-safe review artifacts. The workbench deliberately does not write directly to the production ITSM/CMDB platform.
Record 04 / Risk controls
Constraints and guardrails
Constraints
The engagement is ongoing; analysis and design do not equal production implementation.
Design elements remain proposals until supported by accountable decisions and implementation evidence.
A source being considered important does not automatically make it authoritative.
The analysis workbench never writes directly to the production CMDB.
Record 02 / Approach
The evidence-to-decision model
Evidence
collect representative source data, profiles, and ownership facts.
Finding
state what the evidence actually shows, including conflicts and gaps.
Decision
record an accountable choice about scope, authority, mapping, or precedence.
Test
validate the decision against representative data and validation controls.
Acceptance
business acceptance by an accountable owner, supported by evidence.
These stages intentionally remain separate. A source being considered important does not automatically make it authoritative. A mapping proposal does not mean the mapping has been approved. A successful analysis does not mean configuration has been deployed. A technical test does not represent business acceptance unless an accountable owner accepts it.
Interactive example: tracing one attribute back to its evidence
This working example applies the same evidence-to-decision model described above to a small sanitized sample: one sample CI, five generic source categories, and four reconciled attributes. Choose an attribute to see how competing source observations become one reconciled CMDB value - then switch the direction to trace that value in reverse, from the final attribute back to the source observation behind it.
Illustrative sample data - not customer production data.
Sample CISample managed serverDEMO-SRV-001
Freshness is shown as a relative offset. T-2 means the observation was recorded two days before the illustrative decision date, so the sample never expires.
Identity first: one CI, five source records
Five source records were correlated into one sample CI. No single source held every identifier, so the correlation rests on source-native keys plus two cross-matched hardware identifiers.
Endpoint managementEndpoint record IDEPM-DEMO-4417
Cloud inventoryResource IDres-demo-7f3a
Security toolingSensor ID (matched on serial)SEN-DEMO-5521
Network managementDiscovery ID (matched on address)ND-DEMO-204
Asset managementAsset tagAT-DEMO-118
A sixth asset-management record (asset tag AT-DEMO-118B, name demo-app-01-old) was investigated as a suspected duplicate. It was retired as a pre-rebuild leftover instead of merged, so it can never feed reconciliation for this CI.
Showing forward reconciliation for Name.
Forward reconciliation: Name
What is this server actually called in operations?
Reconciled valuedemo-app-01accepted from Endpoint management
Endpoint management is authoritative for the name in this sample: it holds the source-native record for the managed device, applies the managed naming standard, and carries the freshest observation. The cloud value is a provider-suffixed instance name, not the managed name, and the asset value predates a rebuild.
Source observations
Endpoint managementCurrent observation
demo-app-01Observed T-2Matches the managed naming standard; the record follows the device itself.
Cloud inventoryCurrent observation
demo-app-01-aObserved T-1Fresh, but provider-suffixed; it names the instance, not the managed server.
Security toolingCurrent observation
demo-app-01Observed T-2Agrees with the endpoint record; adds confidence but not authority.
Asset managementOlder observation
demo-app-01-oldObserved T-260Names the pre-rebuild machine; the record was never updated after the rebuild.
Stopped and overridden values
StoppedCloud inventorydemo-app-01-a
Stopped: freshest observation in the sample, but it identifies the cloud instance, and name authority for the managed server sits with endpoint management.
OverriddenAsset managementdemo-app-01-old
Overridden: a lifecycle event (the rebuild) invalidated the record, and no owner refreshed it. Stale pre-event values never win.
The precedence decisions below are simulated for demonstration. In a real engagement, a precedence decision is recorded, tested, and accepted by an accountable owner before configuration relies on it.
The sample is illustrative and self-contained. It runs entirely in this page, reflects no customer environment, and publishes no customer data.
Source-readiness framework
Before treating a data source as design-ready, the work evaluates whether the organization has:
Representative data. A sample that reflects real populations, not just clean examples.
Defined source or data owner. An accountable owner for the data the source provides.
Known extraction method. A documented, repeatable way to retrieve the data.
Source-native identifier. A stable key the source system itself maintains.
Completed data profile. Formats, distributions, nulls, and cardinality are understood.
Understood lifecycle semantics. Creation, change, and retirement can be interpreted.
This prevents the CMDB design from being built around assumptions that later become expensive integration or reconciliation problems.
Interactive lab: source identity and reconciliation decisions
This working example shows how reconciliation decisions hold up under review. Five generic source categories observe one sanitized demo server; the lab derives a source key from the identity inputs you choose, applies the documented precedence, freshness, duplicate, and retirement rules, and keeps every value that loses - nothing is deleted to make a decision fit. Switch scenarios to inspect duplicate records, conflicting attributes, aging observations, a returning asset, and a finding that has to follow identity instead of an address.
Illustrative sample data - not customer production data.
Sample itemDemo cloud-hosted Linux serverDEMO-LNX-4417
Showing Duplicate records, one item. Source keys derive from durable identity inputs.
Four source records mention the demo estate. Which records describe the same server, and which stay separate?
Source records and derived keys
R1Linux system inventory source
Inventory record for the demo server
Durablemachine-id9f18-demo-4417
Ephemeralreported namedemo-web-01
Ephemerallast address10.254.7.114
Derived source key57875b4d-7354-77a3-577b-8981530ab33fSame key as R2, R3
R2Endpoint management source
Managed-device record for the demo server
Durableserial number9f18-demo-4417
Ephemeralmanaged device nameDEMO-WEB-01
Derived source key57875b4d-7354-77a3-577b-8981530ab33fSame key as R1, R3
R3Cloud inventory source
Cloud instance record for the demo server
Durableinstance identity tag9f18-demo-4417
Ephemeralinstance namedemo-web-01-vm
Ephemeralprivate address10.254.7.114
Derived source key57875b4d-7354-77a3-577b-8981530ab33fSame key as R1, R2
Three records converge into one item because their durable inputs derive one key; the second server keeps a separate identity. No source record is discarded - converging duplicates stay attached with their own observations.
Rules applied in this scenario
identityRecords whose durable identity inputs derive the same source key describe the same configuration item.
duplicatesDuplicate records reconcile into one item; observations from every source are preserved.
lineageOverridden, stale, and historical values stay attached to the item with the reason they lost.
The derivation and reconciliation decisions are computed in this page from the fixed sample above. Nothing is sent anywhere, no visitor or customer data is collected, and the same inputs always produce the same keys.
The lab is illustrative and self-contained. It runs entirely in this page, reflects no customer environment, and publishes no customer data.
Record 05 / Outcomes
What the work is enabling
Created a repeatable evidence foundation for CMDB decisions.
Made unresolved ownership, identity, mapping, and lifecycle questions visible before production configuration.
Improved traceability between evidence, design decisions, validation, and eventual acceptance.
Provided a structured way to compare source observations without prematurely declaring a golden value.
A CMDB should not begin with bulk loading data. It should begin with evidence, identity, ownership, lifecycle, and explicit decisions about what the organization is prepared to trust.
Relevant capabilities
CMDB design and governance
Source-system analysis
Data profiling and canonicalization
Identity and correlation analysis
Source authority and reconciliation design
Identification-rule design
Evidence and decision traceability
Implementation-readiness assessment
Workshop preparation
Customer-safe deliverables
Related evidence
Separate anonymized enterprise work demonstrates related ITSM platform experience.
Start with evidence before you lock the implementation scope.
Ford Enterprise Systems helps organizations build defensible configuration and data foundations - source readiness, identity, authority, and governance decisions that can stand up to review.