Ralyio Blog · July 2026 · 9 min read

Integration Impact Analysis — How to Know What a Change Will Break

Every enterprise integration change is a controlled explosion. The question is whether you know the blast radius before you set it off, or discover it afterward. This is a practical guide to doing impact analysis properly — and why most teams get it wrong.

The problem with "we'll do impact analysis"

Every enterprise with an integration portfolio has a change management process that includes an impact assessment step. In practice, "impact analysis" usually means: asking the person who built the integration, searching Confluence, and hoping someone remembers the undocumented downstream consumer that was added two years ago.

The impact analysis failure pattern
The change passes the impact assessment. It goes to production. A downstream system that nobody remembered breaks. The incident is attributed to "insufficient testing" — but the real cause was an undocumented dependency that no amount of testing would have surfaced if you didn't know to test it.

This failure mode is extremely common and almost never attributed correctly. The root cause is not a testing failure — it's a documentation failure. The dependency wasn't in the model, so the impact assessment couldn't find it.

What a complete impact analysis looks like

A proper impact analysis for an integration change answers four questions:

1
What is directly affected?
The integration being changed, and any system or process that directly consumes its output or provides its input.
2
What is transitively affected?
The downstream consumers of the downstream consumers. A change to a data feed can propagate through three or four integration hops before reaching the system that actually breaks.
3
What shared assets are touched?
Fields, business logic rules, and reference data that are used by more than one integration. A change to a shared field definition can affect every integration that carries that field.
4
What controls or approvals are triggered?
Some changes — touching Restricted data, changing an integration in CHANGE_IN_PROGRESS state, affecting a system in a regulated environment — require additional review or sign-off. A complete impact analysis surfaces these gates automatically.

Why a dependency graph is required

Questions 1 through 4 above are all graph traversal problems. You start at a node (the asset being changed) and traverse its edges (dependencies) in both directions. A wiki page or a diagram cannot do this — you can read it, but you can't query it.

A structured dependency model with typed, explicit relationships can. "What depends on Interaction X?" is a query against a graph, not a search through a document. The answer comes back in milliseconds and is complete — not "whoever happened to update the wiki last."

What a graph gives you
Given any proposed change, a dependency graph traversal tells you the complete set of affected assets — direct and transitive — in under a second. That's the difference between "we ran an impact assessment" and "we know what breaks."

Common impact analysis mistakes

Stopping at the first hop
Direct dependencies are the easy part. The dangerous unknowns are two and three hops away. Always traverse the full transitive closure of the dependency graph.
Ignoring shared field definitions
A field type change doesn't just affect the interaction where you made the change — it affects every integration that carries that field. Shared fields are a multiplier on impact.
Treating the impact assessment as a checkbox
An impact assessment that doesn't produce a named list of affected systems and a named decision on each is not an impact assessment — it's a formality. Specificity is what makes it useful.
Not updating the model after the change
Even a good impact analysis becomes stale if the documentation isn't updated. The next change is analysed against the post-change state — if that state wasn't recorded, the next assessment is already working from incomplete information.

A practical checklist

Identify the specific asset being changed (interaction, field, business logic rule, system)
List all direct upstream dependencies (what does it consume?)
List all direct downstream dependents (what consumes it?)
Traverse transitively — repeat for each dependent until no new dependents found
Check for shared field definitions touched by the change
Identify any control or approval triggers (Restricted data, regulated system, lifecycle gate)
Produce a named list of affected assets and a decision on each
Record the impact assessment with the change request (timestamped, named assessor)
Update the documentation after the change is applied

Frequently asked questions

What is integration impact analysis?

Integration impact analysis is the process of determining, before making a change, which other systems, integrations, fields, or business processes will be affected by that change. A good impact analysis tells you the full blast radius of a proposed change — not just the direct effects, but the transitive effects through the dependency chain.

How do you do an integration impact analysis?

Start with the asset being changed. Traverse its dependencies in both directions: what does it depend on (upstream), and what depends on it (downstream)? For each dependent, assess whether the change breaks, degrades, or alters their behaviour. A structured dependency graph makes this traversal systematic; without it, you're relying on whoever happens to know.

Why is integration impact analysis often wrong?

Because the dependency map it relies on is incomplete or out of date. Impact analysis is only as good as the documentation it's based on. If dependencies are captured in a wiki page that hasn't been updated in six months, your impact analysis will miss the dependencies that were added in the last six months — which are often the most relevant ones.

What is a dependency graph in the context of system integrations?

A dependency graph is a structured model of which integration assets rely on which other assets, with explicit, typed relationships. It enables systematic traversal: given any node, find everything that depends on it, and everything it depends on. This is what makes automated impact analysis possible — and what a diagram or wiki cannot provide.

Know what breaks before you touch it.

Ralyio's dependency graph gives you automated impact analysis on every proposed change.

Get started