Change impact simulator

A change impact simulator reads your CMDB as a dependency graph and walks the edges that would carry a planned change outward. The output is not a go/no-go decision. It is a set of impact paths, each step tied to a CMDB relationship identifier when that edge exists in the source data.

You use it the same way a release lead uses a pre-flight checklist: narrow the unknowns before people enter the bridge. Pair it with a pre-flight configuration validator so configuration drift and missing baselines surface in the same planning window, not during execution.

The simulator answers one question with evidence: if this change lands on asset X, which configured items and services sit downstream according to recorded relationships? It does not count devices, users, or revenue. It does not approve the change.

Start from the configuration items and relationship types your organization already stores in ServiceNow, BMC, or another CMDB-backed platform. Export or query the subgraph around the change target: the CI being patched, the load balancer rule being updated, the database instance receiving a schema migration.

Include relationship records, not just nodes. An impact path is only as trustworthy as the edge it walks. If your CMDB stores Runs on, Depends on, Connected to, or custom types, pass those type codes through unchanged. Do not merge relationship types in the loader to make the graph look cleaner.

Observability platforms such as Datadog and Splunk hold runtime signals, not authoritative topology. They can hint that two services talk, but they do not replace CMDB relationship IDs for change planning. Use observability to prioritize which subgraph to load, not as a substitute for cited edges.

A practical load sequence:

1. Identify the primary CI and change scope (host, cluster, application service record).
2. Pull inbound and outbound relationships to a bounded depth your CAB expects (often two or three hops for application tiers, more for shared infrastructure).
3. Attach relationship sys_ids or equivalent foreign keys on every edge object passed to the simulator.
4. Flag nodes with no outgoing edges in the export separately from nodes whose edges were never retrieved.

If an edge is missing from CMDB, the correct state is empty on that hop, not an inferred link.

Feed the loaded graph to the simulator with the planned change descriptor: what field changes, which CI is the touch point, and which relationship types are in scope for traversal. The model proposes downstream paths by following allowed edge types and stopping where data ends.

Each hop in an output path must carry the CMDB relationship ID that justified the step. Format varies by platform; what matters is that a reviewer can open the relationship record and confirm type, endpoints, and freshness.

Illustrative example (no production metrics): A team plans to raise connection pool limits on APP-PAYMENTS-01. The simulator returns two paths:

• Path A: APP-PAYMENTS-01 → (relationship rel_8842, Depends on) → DB-PAYMENTS-PRIMARY → (relationship rel_9103, Connected to) → SVC-CARD-TOKENization
• Path B: APP-PAYMENTS-01 → (relationship rel_8845, Runs on) → K8S-NODE-POOL-B

Path B ends after one hop because the export contained no further outbound relationships from the node pool CI. That blank terminus is correct. Do not backfill Path B with guessed hosts because Datadog shows traffic elsewhere.

When a path prints a hop without a relationship cite, treat that output as a failure mode, not a soft warning. Discard the hop or rerun with a narrower scope until every printed step maps to a stored edge. A path with no relationship cite is indistinguishable from hallucination in a CAB packet.

Uncited hops. If the simulator prints APP → unknown middleware → DB without IDs, stop. Either the graph load omitted edges or the model inferred a shortcut. Neither belongs in a quality outcome. Fix the load, tighten allowed relationship types, or reject the path.

Treating simulation as approval. Simulation output informs the Change Advisory Board; it does not replace it. CAB still approves scope, timing, backout, and communications. Auto-implementing because the graph looked quiet has caused production incidents when unmodeled manual dependencies existed outside CMDB.

Invented blast radius counts. Stakeholders sometimes ask for "42 systems affected." The simulator does not produce that number unless your CMDB export and counting rules define it explicitly. Summarize paths and named CIs instead. If leadership needs a count, derive it from cited nodes with a documented rule (unique CIs in all paths, services only, etc.), and show the rule beside the figure.

Stale or duplicate CIs. Two records for the same logical service can fork paths. Deduplicate in review, not silently in the model. Note last-updated timestamps on relationship records when your platform exposes them.

Scope creep in traversal. Following every edge type to maximum depth produces noise. Align depth and edge filters with what your deployment runbook generation step will actually touch, so simulation, runbook, and execution share one boundary.

Package simulation results as an appendix to the standard change record: primary CI, change description, allowed relationship types, depth limit, and the path list with cites. Call out empty termini explicitly ("no further CMDB relationships exported") so approvers do not read silence as safety.

CAB members care about three things the cites enable:

• Evidence: Each hop opens in CMDB for spot checks during the meeting.
• Gaps: Blank ends and missing subgraphs become questions for service owners before approval.
• Backout alignment: Downstream names on cited paths should appear in rollback planning. Cross-check against a rollback decision assistant if your process separates forward impact from revert order.

State plainly in the change record: "Simulation is advisory; approval remains with CAB." That sentence prevents the most common governance failure, conflating graph completeness with risk acceptance.

Simulation quality improves when post-change signals feed back into CMDB hygiene, not when the model guesses harder. If production behavior diverges from cited paths, log the mismatch for CMDB correction rather than retroactively inventing edges in the simulator.

Use post-deploy anomaly clustering to group signals that appeared only after the change window. When anomalies cluster on a CI that never appeared in simulated paths, that is a graph gap to fix before the next release, not proof the simulator failed on its own terms.

Re-run the same load and simulation after CMDB updates when the change slips weeks. Relationship records change when teams onboard services or decommission hardware. A path valid at draft time can be stale at execution time.