Impact Radar: Understand Change Before You Make It
A few weeks ago, a platform team I work with decided to deprecate an internal authentication service. It looked straightforward — the service had two known consumers. They updated the diagram, notified those teams, and started planning the migration.
Three sprints later, they discovered four more services depending on it. Two were in other projects entirely. One was a legacy flow nobody had mapped. The migration timeline doubled.
The information was there. It was sitting in the relationships, in the C4 hierarchy, in the flow diagrams. But nobody could see the full picture at a glance. You had to trace each connection manually, across levels, across projects, hoping you didn't miss a path.
That's the problem Impact Radar solves.
Right-Click, See Everything
Impact Radar lives where you already work — on the diagram. Right-click any element in your C4 model — a system, container, component, or code element — and select Analyze Impact. The analysis runs instantly.
The diagram transforms. Every element outside the impact zone fades to the background. The affected elements stay vivid, and the relationships between them light up, color-coded by proximity:
- Red — directly connected (degree 1)
- Amber — one hop away (degree 2)
- Yellow — two hops away (degree 3)
Edges animate to show the direction of dependency flow. You see the blast radius of a change in the time it takes to glance at the screen.
The Impact Panel
A panel slides in from the right with the full analysis. No separate page, no context switch — you're still on your diagram, still in your project.
At the top, a single number: "Impacts X% of your architecture." This is the percentage of your project's elements that fall within the impact zone. It's a gut-check number. If you right-click a utility component and see 2%, you're probably safe. If you right-click a core API gateway and see 38%, you know this change needs a conversation.
Risk Score
Below the percentage sits the Risk Gauge — a 0 to 100 score computed from four weighted factors:
- Upstream dependents (30%) — How many elements depend on this one? The more consumers, the higher the blast radius.
- Downstream reach (25%) — How many dependencies does this element pull in? Changes here might require updating those dependencies too.
- Structural children (25%) — For containers and systems, how many child elements live inside? Modifying or removing a container means dealing with every component it contains.
- Coupling ratio (20%) — How connected is this element relative to the rest of the graph? High coupling means high risk.
The gauge shows green, amber, or red based on the score. Below it, a breakdown of each factor so you understand exactly what's driving the number.
Upstream and Downstream
The analysis separates impact into two directions. Upstream shows everything that depends on the selected element — the services that call it, the systems that consume it, the components that import it. Downstream shows everything the element depends on — the databases it reads from, the APIs it calls, the libraries it uses.
Each direction is organized by degree. Degree 1 elements are directly connected. Degree 2 elements are one hop away — they don't touch your element directly, but they touch something that does. Degree 3 extends the analysis one more step.
This layered view helps you think about impact in concentric rings. Degree 1 changes are immediate. Degree 2 and 3 are the secondary effects — the ones that tend to surprise teams who only looked at direct connections.
Critical Path
If the dependency chain goes deep, Impact Radar highlights the critical path — the longest chain from the selected element to the most distant affected node. This is the path where changes take the longest to propagate and where cascading failures are most likely.
Each node in the critical path is clickable. You can trace the chain step by step and understand exactly how a change at one end reaches the other.
Cross-Project Dependencies
Architecture doesn't stop at project boundaries. If your organization uses Archyl's Global Architecture view to connect systems across projects, Impact Radar follows those connections too.
The panel includes a Cross-Project Dependencies section that shows elements from other projects that fall within the impact zone. Each entry displays the project name, so you immediately know which teams to loop in.
This is where Impact Radar goes from useful to essential. Inside a single project, you might be able to trace dependencies manually. Across five projects maintained by different teams? That's where things get missed. Impact Radar traces the full graph automatically, regardless of project boundaries.
Affected Flows
If you've documented user or system flows in Archyl, Impact Radar cross-references them against the impact zone. The Affected Flows section lists every flow that includes at least one step touching an impacted element, along with how many of that flow's steps are affected.
A flow showing "4/12 steps affected" tells you something different than "1/12 steps affected." The first means the change cuts across a significant portion of the user journey. The second means it's a peripheral touch point.
What-If Simulation
At the bottom of the panel, a toggle: Simulate Removal. This is the "what breaks if we delete this?" button.
Flip it on, and Impact Radar computes the full cascade:
- Broken relationships — Every explicit connection to or from the element (and its children) that would become dangling references.
- Structurally destroyed — The direct children that would be removed along with the element. Delete a container, and every component inside it goes too.
- Orphaned elements — Elements that become unreachable from the rest of the graph after the removal. They're not directly deleted, but they're effectively dead — disconnected nodes with no path to anything.
- Cross-project breaks — Global relationships from other projects that would be severed.
- Total cascade impact — The total count of everything affected.
This isn't speculative. It's a deterministic computation over the relationship graph. The numbers tell you exactly what happens if you proceed.
Why This Matters
The common workflow for evaluating architectural changes today is a meeting. Someone proposes a change. The team discusses who might be affected. People volunteer dependencies from memory. Someone checks a diagram. Someone else checks a different diagram. The meeting ends with an action item to "investigate further."
Impact Radar compresses that cycle into a right-click. The analysis is exhaustive — it follows every relationship, structural edge, and cross-project link in the graph. It doesn't rely on anyone's memory of how the system is wired. It reads the model you've already built and shows you what the model says.
This changes how teams approach architectural evolution:
- Before deprecating a service, see every consumer across every project.
- Before restructuring a component hierarchy, understand the downstream ripple.
- Before a major refactor, quantify the blast radius and identify which teams need to be involved.
- During incident reviews, trace the dependency chain to understand why a failure in one component cascaded across the system.
Getting Started
Impact Radar is available now on all plans. Open any project, right-click any element on your C4 diagram, and select Analyze Impact.
The analysis works best when your architecture model is connected — when relationships between elements are documented, when flows capture real user journeys, and when cross-project links reflect actual system boundaries. The more complete your model, the more useful the impact analysis becomes.
Your architecture is a graph. Impact Radar lets you read it.
Want to build a more connected architecture model? Start with the Introduction to the C4 Model, then connect your projects with Real-Time Collaboration and Global Architecture. For teams that want governance around changes, Architecture Change Requests pair naturally with Impact Radar — analyze the impact first, then propose the change.