CelinQ Insights · No. 23

Impact analysis when the model is edited by a whole team

Understanding what a change touches, even mid-flight.

Impact analysis is one of the things enterprise architecture is supposed to be good at. Someone proposes to retire a system, change an interface, or reorganise a capability, and the model is meant to answer the question that everyone in the room actually cares about: what else does this touch? Trace the relationships outward from the thing being changed and you find the diagrams that reference it, the services that depend on it, the processes that would break, the stakeholders who would need to be told. Done well, this is the moment the model earns its keep. It turns a vague anxiety about downstream consequences into a concrete, defensible list of what needs attention. It is, for many organisations, the single most valuable thing the model does.

The technique itself is not hard. Any competent architect can follow the relationships and reason about consequences. What makes impact analysis quietly unreliable in practice is not the analysis. It is the ground the analysis stands on. Tracing consequences through a model only produces a trustworthy answer if the model you are tracing through is itself trustworthy, and specifically if it reflects the current state of the world rather than some earlier state that has since been overtaken. The technique assumes the map is current. On a team, that assumption is exactly the one most likely to be false, and its falseness is invisible right up to the moment it hurts you.

The map you are reading is not the territory anyone is building

Consider what impact analysis is really doing. It reads the model as a statement of fact: these things exist, they relate to each other in these ways, therefore changing this affects that. The confidence in the conclusion is inherited entirely from the confidence in those facts. If the model says a service depends on a component, and that is true, then the impact you trace through that dependency is real. If the model says nothing about a dependency that in fact exists, the impact analysis will confidently tell you the change is safe when it is not, and it will do so with exactly the same authority as when it is right. A false negative in impact analysis is not a smaller version of a true result; it is a trap, because it produces confidence in the wrong answer.

Now put a team on that model. At any given moment, several architects are partway through changes that are not yet reflected in the shared picture the analyst is reading. One of them has spent the morning adding the very dependency that would change the conclusion, but it is still sitting in their local work and has not yet reached the shared model. Another has just deleted an element that the analysis is about to trace through, unaware that someone else is at that moment building an analysis that assumes it still exists. A third has renamed a capability, so the analyst searching for it by its old name finds nothing and concludes, wrongly, that it is not involved. None of these people has done anything wrong. Each of them is doing careful work. But the model the analyst is reading is a composite of everyone's last-synchronised state, and on a busy team that composite is always slightly behind the truth, and always behind it in ways the analyst cannot see.

Impact analysis fails most dangerously not when the model is wrong in some obvious way, but when it is merely out of date, because staleness produces confident answers that happen to be false.

This is the specific difficulty of doing impact analysis while a whole team edits the model. It is not that the model is bad. It is that the model is a moving target, and impact analysis implicitly treats it as a still photograph. The analyst is answering a question about the present using a picture of the recent past, and the gap between the two is precisely where the dangerous errors live. The larger and more active the team, the wider that gap, and the more consequential the change being analysed, the more it matters that the gap is invisible.

How teams cope, and why the coping makes it worse

Teams are not naive about this. They have developed coping strategies, and it is worth looking at them because each one trades the problem for a different problem rather than solving it.

The most common strategy is to freeze the model before a serious analysis. Announce that nobody should make changes for a period, take the analysis while things are still, and lift the freeze afterwards. This does produce a consistent snapshot to analyse, but it does so by stopping the team from working, which is a heavy price for the privilege of trusting the map for a few hours. It also does not scale to a world where impact questions arrive constantly and cannot each be preceded by a work stoppage. And it quietly assumes that the state at the moment of the freeze is the state you actually want to analyse, which is not true if half the team was mid-change when the freeze came down; you have simply frozen an inconsistent picture rather than a moving one.

A second strategy is to route impact analysis through the one person who knows everything. There is often such a person on a team: the architect who has been there longest and carries the current state of the model in their head, including the parts that have not yet made it into the shared repository. Ask them and they will tell you about the dependency that is still in someone's local work, because they happened to be in the conversation. This works right up until it does not. It makes impact analysis depend on a single human's memory, it does not survive that person being on leave or moving on, and it fails silently, because the day their mental model is out of date is a day that looks exactly like every other day. Institutional knowledge held in one head is not impact analysis; it is a bet that the head is current.

The third strategy is simply to add a margin of caution to every conclusion. Whatever the analysis says, treat the change as riskier than it looks, involve more people than seem necessary, test more than the model suggests you need to. This is not irrational; it is the sensible response to knowing the map might be stale. But it defeats much of the purpose of doing the analysis at all. The value of impact analysis is that it lets you act with precision, touching exactly what needs touching and no more. If you cannot trust it enough to act on it precisely, you are back to treating every change as broadly dangerous, which is the situation the model was supposed to rescue you from. A model you cannot act on precisely is an expensive way of feeling slightly less anxious.

The real requirement: a current, consistent picture

Strip the coping strategies away and the underlying requirement is clear. For impact analysis to be trustworthy on a team, the model you analyse has to be current, in the sense that it reflects what people have actually done, and consistent, in the sense that it is a coherent whole rather than a patchwork of half-synchronised states. Freezing gives you consistency at the cost of currency and throughput. Relying on a person gives you a kind of currency at the cost of reliability. Adding caution gives up on precision. What you actually want is a shared picture that stays close to the truth continuously, without anyone having to stop working to make it so.

This is where the shape of CelinQ matters for impact analysis specifically. Each architect works in their own local repository at full speed, and a background companion synchronises each save with a shared workspace that the organisation runs itself. The consequence for impact analysis is that the shared picture is not a periodic snapshot that someone has to remember to refresh; it is continuously fed by everyone's saves as they happen. The gap between what people have done and what the shared model reflects is not eliminated, because nothing can make synchronisation instantaneous across a distributed team, but it shrinks from weeks or days to the interval between saves. Smart Sync adapts the cadence to the situation, so the picture keeps pace with the work rather than lagging a release behind it. An analyst reading the shared model is reading something much closer to the present than a snapshot taken at the last integration point.

Consistency you can trust, because the merge does not cheat

Currency is only half of it. A shared picture that updated quickly but reconciled everyone's work carelessly would be worse for impact analysis than a stale one, because it would combine the appearance of freshness with hidden corruption, and impact analysis is exactly the activity that hidden corruption punishes hardest. If reconciling two people's edits occasionally dropped a relationship, an impact analysis tracing through that relationship would produce a confident false negative. If a deletion were handled ambiguously, an analyst might trace through a thing that one person had deliberately removed, or miss a removal that mattered.

This is why the reconciliation engine, CelinQ Fusion, is built the way it is, and why its properties are not merely technical niceties but the foundation on which any trustworthy impact analysis rests. The merge is deterministic and reproducible, working at the granularity of individual model facts through a three-way merge rather than by comparing whole files. Two architects editing genuinely different parts of the model both succeed, so the shared picture accumulates everyone's real work rather than discarding some of it. When two people have genuinely changed the same fact incompatibly, the engine never applies last-write-wins and never guesses; it isolates the conflict, preserves both versions, and surfaces it for a human. Deletions are recorded explicitly through tombstones, so a removal is a recorded fact rather than a silent absence.

For impact analysis, the tombstone detail deserves particular attention, because deletions are where naive reconciliation does the most damage to a trace. An element that quietly disappears leaves an analyst unable to tell whether it was removed on purpose or lost in a merge, and an element that quietly reappears after someone deletes it is worse still, because the analysis will faithfully trace through something that was supposed to be gone. Recording deletions explicitly means the shared model states, as a fact, what has been removed and when. An impact analysis run against that model is tracing through a picture where absence is deliberate and recorded, not accidental and ambiguous. That is the difference between an analysis you can defend to a client and one you can only hope is right.

Analysing a change that is still mid-flight

The hardest and most valuable version of the question is not "what would this change touch" asked about a hypothetical, but "what is this change touching" asked about work that is actually underway. A team is midway through a substantial restructuring. Elements are moving, relationships are being redrawn, and someone needs to understand the impact now, before the work is finished, because a decision downstream depends on it. This is exactly the situation the old coping strategies handle worst: there is nothing stable to freeze, no single head that holds the whole in-flight picture, and the change is too large to hand-wave with a margin of caution.

Because synchronisation is continuous and reconciliation is trustworthy, the shared model during a restructuring reflects the work as it accumulates rather than only at its completion. An architect can trace impact through a picture that includes what colleagues have already synchronised, understanding what the change has touched so far and reasoning about what remains. The complete, ordered revision history makes this sharper still: it is possible to see not only the current state but the sequence of changes that produced it, which is often what an impact question actually needs. Understanding whether a dependency was recently added or has been there all along changes how you weigh it, and a model that remembers its own sequence of changes can answer that where a bare snapshot cannot.

The optional in-EA design assistant can play a supporting role here, and it is worth describing precisely so as not to overstate it. It can analyse existing parts of the model, which means it can help an architect survey a region of the model quickly, or draw attention to relationships that a manual trace might overlook in a large and unfamiliar area. It is a way of making a human's analysis faster and more thorough, not a replacement for the human's judgement about what the impact means. It is off by default and sovereign to the organisation, and the core of impact analysis works entirely without it. The conclusions, and the responsibility for them, stay with the architect.

A morning in the life of a stale answer

To see why currency matters more than it seems, follow a single impact question from start to finish in the old way of working. An architect is asked, first thing in the morning, whether a particular integration can be retired. They open the shared model as it stood at the last integration point, which was some days ago, and begin to trace. The model shows a handful of dependencies on the integration, all of which the architect can account for and none of which is a blocker. By late morning they have a clean answer: the integration can go, with modest downstream work. They write it up, it goes into a decision, and the retirement is scheduled.

What the architect could not see was that, two days earlier, a colleague had begun modelling a new consumer of that integration, work that was sitting in a local repository and had not reached the shared snapshot the architect was reading. The dependency that would have changed the answer existed in the world and in someone's model, but not in the picture the analysis ran on. The error was not in the analysis, which was competent, nor in the colleague, who was doing legitimate work. It was in the gap between the two, a gap that was invisible precisely because a stale model looks exactly like a current one. The retirement goes ahead, the new consumer breaks, and the failure is attributed to bad impact analysis when in truth the analysis was only ever as current as the snapshot beneath it.

Run the same morning on a continuously synchronised model and the colleague's new consumer, saved as they worked, has already reached the shared workspace. The architect tracing the integration's dependencies sees it, accounts for it, and gives a different and correct answer. Nothing about the technique changed. The architect is no more skilled, the tracing no more thorough. The only difference is that the map they read reflected what the team had actually built, up to the last save, rather than what it had built up to some integration point days in the past. That single difference is the whole distance between a defensible answer and a confident wrong one, and it is entirely a property of how current the shared picture is kept.

What still requires a human, and always will

It would be dishonest to suggest that a current, consistent model turns impact analysis into a mechanical readout. It does not, and the parts it does not solve are the parts that matter most. A model captures the relationships that someone chose to model. It does not capture the ones nobody thought to write down, and impact analysis can only trace what is present. A current model dramatically reduces one class of error, the error of tracing through stale or corrupted facts, but it does nothing about the error of a dependency that was never modelled at all. That gap is not a tooling problem; it is a modelling-completeness problem, and the honest response is to be clear about it rather than to let the smoothness of the analysis imply a completeness the model does not have.

There is also judgement in what an impact means. The model can tell you that a service depends on a component; it cannot tell you whether that dependency is load-bearing or vestigial, whether the downstream team can absorb the change easily or will find it catastrophic, whether the relationship reflects a genuine coupling or an accident of how the model was drawn. Those are questions of meaning, and meaning lives with people. What a trustworthy, current model does is put the human judgement where it belongs, on the questions that genuinely require it, instead of squandering it on the prior question of whether the map can be believed at all.

The point of it all

Impact analysis is only as good as the model it runs on, and on a team the thing most likely to betray it is not incorrectness but staleness: a picture that was true recently and is quietly no longer true, producing confident answers that happen to be wrong. The traditional coping strategies each trade that problem for another, buying consistency by stopping work, or currency by depending on one person's memory, or safety by giving up the precision that made the analysis worth doing.

The alternative is to make the shared model stay close to the truth continuously, without anyone stopping work, and to reconcile everyone's changes in a way that never quietly corrupts the facts an analysis depends on. Full-speed local editing keeps people productive; continuous, cadence-aware synchronisation keeps the shared picture current; a deterministic merge that preserves conflicts and records deletions explicitly keeps it consistent; and a complete revision history lets an analyst reason about not just the present state but how it came to be. None of that removes the human judgement at the heart of impact analysis. It removes the doubt underneath it, so that when an architect stands in front of a client and says a change touches these things and not those, they are standing on a map that reflects what the team has actually built, right up to the last save.