Architecture and decision pack
A printable view of the CMDB foundation architecture and decision model.
This pack condenses the published, anonymized CMDB foundation work into a format you can print, share in a working session, and mark up with your own team. It contains only the sanitized descriptions already published on this site - no client-identifying detail, population data, or internal artifacts.
Use the print button next to this note, or your browser's own Print menu, to print this pack or save it as a PDF. The page is styled for paper as well as for screen.
Sanitized architecture flow
How the anonymized CMDB foundation work fits together, from raw sources to accepted decisions.
- Multiple source systems
- Evidence and profiling
- Identity, mapping, and authority
- CMDB design decisions
- Test and acceptance
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 - endpoint management, cloud inventory, security tools, network management, and asset-management sources. Real source-system names and population details are not published.
Six-part 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.
Evidence-to-decision framework
Each stage stays separate on purpose. A source being considered important does not automatically make it authoritative, and a successful analysis does not represent business acceptance until an accountable owner accepts it.
- Evidence
- Finding
- Decision
- Test
- Acceptance
| Stage | What it means |
|---|---|
| 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. |
Questions to bring into a scoping conversation
These are the questions the evidence above is designed to help answer about your own environment:
- Who accepts a CMDB design decision, and what evidence do they accept it with?
- Which of your sources would pass a readiness review today, and which would not?
- Which source should be authoritative for which attributes - and can you show why?
- Can you currently say where a critical attribute in your CMDB came from?
- Which of your workflows would benefit from AI assistance only after the process underneath is clear?
- Would your migration testing catch a broken operating workflow, or only a loaded screen?
- When your system changes, do the people in the workflow find out before go-live or after?
Evidence boundary
This pack reuses only the sanitized descriptions published on this site:
- The architecture and framework describe an anonymized, ongoing engagement; analysis and design do not equal production implementation.
- No client name, source-system name, population detail, metric, or platform version is disclosed.
- No CMDB deployment, incident-reduction, MTTR, or asset-accuracy outcome is claimed.
Planning CMDB or data-foundations work?
Start the conversation with your own evidence in hand.
Bring the marked-up pack to a first discussion, and the engagement can start from your sources, decisions, and readiness instead of from a generic checklist.