Skip to content

Pre-Refactor Operating-Model Check

Pre-refactor readiness gate — instantiates Organization–Artifact Topology Alignment

Before an artifact refactor is greenlit, tests whether a real team could actually own and run each proposed new boundary — flagging any module no part of the organization can hold.

A clean refactor on paper can still fail the moment it ships, because a boundary that is elegant in the code is unownable in the org. Pre-Refactor Operating-Model Check is the gate that catches this before the refactor starts. Its defining move is to take each candidate boundary in the proposed refactor and ask an operating-model question, not a technical one: is there a team that could own this module end to end — understand its domain, run it on call, decide its roadmap — without exceeding what one team can hold? Where the domain review says what the boundaries should be and the refactor mechanisms draw them, this check tests whether the organization can sustain them, and blocks the ones it can't.

Example

An insurer plans to break its aging policy-administration monolith into services — quoting, underwriting, billing, claims. The refactor design looks clean, so it goes to the operating-model check before funding. Laying the proposed service boundaries against the domain boundary map and the org's actual capabilities, the check finds two problems the architecture diagram hid. First, the design folds billing and claims into one service, but they sit in two different domains owned by two different departments that have never shared a system — no single team could own the combined module, so it would land back in exactly the split-ownership mess the refactor was meant to cure. Second, the design shatters quoting into three fine-grained services, none of which any current team has the domain depth to run alone, piling on cognitive load. The check returns a verdict per option: quoting-split — not operable as drawn; billing+claims — no viable owner; underwriting — ready. The refactor goes back for a boundary revision before a line of code moves, which is far cheaper than discovering the same facts after migration.

How it works

The distinctive move is a per-boundary ownership feasibility test, run as a gate:

  • Lay each proposed boundary against the domain map. For every candidate module in the refactor's option set, identify which domain it belongs to and whether that domain has a natural owning team.
  • Test operable ownership. Ask whether a single team could realistically own the module end to end — domain knowledge, on-call, decision rights — or whether it would need two teams (shared-ownership trap) or overload one (cognitive-load trap).
  • Return a gate verdict. Mark each option ready, needs-revision, or no viable owner, and hold the refactor on the ones that fail rather than letting them proceed to code.

Tuning parameters

  • Ownership unit — whether "a team" means an existing team as staffed today or a team the org is willing to form. A stricter unit blocks more options but avoids assuming reorganizations that won't happen.
  • Cognitive-load ceiling — how much domain surface one team is allowed to hold before a module counts as too big. Set it high and unownable modules slip through.
  • Readiness bar — how much of the operating model (staffing, on-call, funding, decision rights) must be in place versus merely plausible before an option passes.
  • Gate strength — advisory flag versus hard block. A hard gate prevents unownable refactors but can stall genuinely good designs waiting on an org that could form.
  • Revision loop — whether failing options bounce back for boundary redesign or are simply dropped, trading thoroughness against schedule.

When it helps, and when it misleads

Its strength is that it moves a whole class of failures upstream, from expensive post-migration discovery to a cheap pre-flight check, and it enforces the principle that a boundary a team cannot own is not really a boundary. Team Topologies frames the ceiling precisely: a team's ownership should be bounded by its cognitive load, and a module no team can hold will fail on the operating-model side however clean its code.[1]

It misleads when it assumes the current org is fixed — blocking a good refactor because no team owns the module today, when forming or growing one is exactly the right move. It can also be gamed by nominating a paper owner who has neither the capacity nor the knowledge, passing the gate while guaranteeing the failure it was meant to prevent. And a hard gate wielded defensively becomes a way to kill refactors leadership dislikes. The discipline is to state honestly whether an owner exists or must be created, to require a real (not nominal) owner, and to pair the check with the team-design work that can supply an owner rather than only vetoing for lack of one.

How it implements the components

The check realizes the readiness-gating face of the archetype — testing proposed boundaries for operability, not drawing or executing them:

  • architecture_refactoring_option_set — it operates on this set as its object, annotating each candidate boundary with an operating-model verdict rather than generating the options.
  • domain_model_boundary_map — it uses the domain boundaries as the reference for which module belongs to which domain and therefore which team could own it.

It does not generate the refactoring options or execute the chosen one — that is the artifact-side Artifact Boundary Refactor and, for ownership, Ownership Boundary Refactor — nor does it author the domain boundary map it reads from; that is Bounded Context or Domain Boundary Review.

References

[1] Team Topologies (Skelton & Pais) argues that a team's ownership should be bounded by its cognitive load — the amount of domain it can genuinely hold. A proposed module that no single team could understand and run is a refactor that fails on the operating-model side even when the code is clean. ↩