Skip to content

Post-Reorganization Architecture Impact Review

Post-change impact review — instantiates Organization–Artifact Topology Alignment

After an org change, traces which parts of the architecture now encode the old communication graph as debt, and maps the new external boundaries the change introduced.

A reorganization changes the org chart overnight, but the artifact does not move with it — the code still embodies the previous communication structure. Post-Reorganization Architecture Impact Review is the event-triggered review that assesses the blast radius. Its defining move is to look in both temporal directions at once: backward, to trace which boundaries in the artifact now preserve a communication graph that no longer exists — the debt a reorg silently creates — and outward, to map the new external seams (vendors, jurisdictions, acquired systems) the change dragged in. Where an ongoing audit hunts imprints anytime, this review is fired by a specific event and scoped to its consequences.

Example

A payments company acquires a smaller competitor and merges the two engineering orgs. Six weeks later the impact review runs. Looking backward, it traces lineage: the merged settlement system now carries two parallel ledgers — one from each pre-merger company — split along a boundary that mirrors two organizations that no longer exist as separate teams. That split is recorded as legacy topology: a seam whose only rationale is a dead org chart, now technical debt with a name and an origin. Looking outward, it maps the new external boundaries the deal introduced: a vendor-run fraud-scoring service the acquired company had outsourced, and operations in a new regulatory jurisdiction whose data-residency rules cut across the existing data model. The review's product is not a refactor plan but a clear-eyed impact record: here is what the reorg turned into debt, and here are the new seams the artifact must now respect. That record is what keeps the integration from quietly cementing the old structure as permanent.

How it works

The distinctive move is event-scoped, two-directional tracing:

  • Trace the lineage backward. For boundaries touched by the change, record why they exist and whether their rationale — the old team structure — still holds. Boundaries that now trace only to a defunct org are logged as legacy debt.
  • Map the new external seams outward. Identify the vendor, jurisdiction, and acquired-system boundaries the reorg introduced, and where they cut across the existing artifact.
  • Record impact, don't resolve it. Produce a scoped record of what the reorg created — debt and new constraints — for the decision and refactor mechanisms to act on, rather than trying to fix it in the review itself.

Tuning parameters

  • Trigger scope — which changes warrant a review (a full merger versus a team reshuffle) and how much of the artifact around the change to examine.
  • Lineage depth — how many prior reorgs back to trace a boundary's origin. Deeper tracing catches older ghosts but hits lost history sooner.
  • Timing after the change — run immediately (catches intent before it fades) or after a settling period (sees real consequences). Too early misreads transition noise as structure.
  • External-boundary granularity — how finely to map vendor and jurisdiction seams — per-system, per-contract, per-data-domain — trading detail against effort.
  • Debt-vs-constraint split — how the record distinguishes boundaries that are now removable debt from ones that are new, binding external constraints the artifact must keep.

When it helps, and when it misleads

Its strength is that it catches the quiet failure mode of reorganizations: the org changes, the architecture doesn't, and the old communication graph lives on as debt nobody decided to keep. Lehman's laws of software evolution make the point structural — a system must be continually adapted to its environment or it grows progressively less fit, and an org change is exactly the environmental shift that leaves an unadapted architecture encoding a structure that is already gone.[1]

It misleads when run too early, mistaking the noise of a transition for permanent structure, or when it slides from recording impact into rubber-stamping the reorg that caused it — assembled to show the change went smoothly rather than to find what it broke. It can also over-attribute: not every awkward boundary after a merger is the merger's fault; some predate it. The discipline is to let the dust settle before judging permanence, to separate genuinely new debt from pre-existing seams, and to keep the review a diagnosis that hands off to the decision and refactor mechanisms rather than one that quietly blesses the status quo.

How it implements the components

The review realizes the lineage-and-external-boundary face of the archetype — tracing what a change created, not deciding what to do about it:

  • legacy_topology_lineage_record — its backward-looking product: the record of which boundaries now trace only to a defunct organization and so have become debt.
  • vendor_or_jurisdiction_boundary_map — its outward-looking product: the map of new external seams (vendors, jurisdictions, acquired systems) the reorg introduced into the artifact.

It does not durably store the mirror-or-decouple decisions those findings prompt — that register is Architecture Decision Record with Ownership — nor does it derive the desired domain boundaries the new external seams are judged against; that reference is Bounded Context or Domain Boundary Review.

References

[1] Lehman's laws of software evolution observe that a system in active use must be continually adapted to its environment or it becomes progressively less satisfactory (Meir M. Lehman). A reorganization is precisely such an environmental shift, and this review finds where the artifact has not yet adapted. ↩