An EA team maintains one enterprise architecture - a single set of catalogues, standards and diagrams covering all 14 business units at the same level of detail, refreshed annually. Two units are regulated insurers, one is an eight-month-old digital venture, the rest are stable back-office functions. Any change to the model is assessed against the whole of it, so a revision takes about six weeks. Review this. What would you remove, what would you change, and what would you leave alone?

What is actually required

Three different questions are being asked of one artefact, and they have different answers.

The insurers need a model deep enough to answer a regulator: which systems hold policy data, where it is processed, who approved the processing. The digital venture needs almost nothing, because its architecture will be unrecognisable in two quarters and recording it is writing a model with a half-life shorter than its review cycle. The back-office functions need a stable inventory refreshed slowly, because that is how fast they change.

Architecture partitioning has been part of TOGAF since version 9 in 2009, and this is the problem it exists for: splitting the model by subject matter, level of detail and time horizon so the partitions become the unit of change.

One depth for all three means the model is too shallow for the regulator and too heavy for the venture. The six-week revision time is the symptom: the unit of change is the whole enterprise model, so every edit inherits the review surface of every other part.

What I would remove

• The uniform depth. This is the single change that fixes the six weeks. A segment architecture for claims can then be revised without reopening the enterprise architecture, so a claims change touches one partition instead of fourteen business units' worth of review surface.
• The annual refresh for the venture. Record its external interfaces and its data classification and nothing else. An eight-month-old product has no stable internal structure to model.
• Diagram parity. The insurers get detailed application and data views because a regulator asks for them. Back-office functions get a one-page landscape. Producing both at insurer depth costs roughly three times the effort and changes no decision.

The one change that matters

Give each partition its own refresh cadence and its own authority to change itself. A segment owner revises their own segment; the enterprise layer is consulted only when a change crosses a partition boundary. The test is mechanical: if the edit alters something another partition depends on, it escalates; otherwise it does not.

This converts the six-week queue into two queues - a short one for the 90% of edits that are local, and the slow careful one for the few that genuinely bind other units.

What I would leave alone

The enterprise-level constraints that actually cross units, even though they look like the bureaucratic part: identity, data classification, the contract for inter-unit integration, and the naming of systems of record. These earn central ownership because a mistake in them lands on somebody else. The insurers' retention rules do not.

Also leave the single catalogue of applications. One inventory at shallow depth is more valuable than fourteen deep ones, because the questions it answers - what do we run, who owns it, what does it cost - are enterprise questions by nature.

How I would argue this in the review

Not as a reduction in rigour. As a reduction in coupling: the model is slow to change because it has no seams, which is the same diagnosis you would make about a codebase. Partitioning is modularity applied to the architecture description, and the measurable outcome is revision lead time.

When this is the wrong answer

Below roughly 300 people in one line of business, partitioning is overhead. There is one segment, the model fits in a handful of pages, and inventing partitions creates escalation paths for decisions that three people could make in a room. Choose partitioning only when the units have genuinely different regulators, change rates or funding - not when they merely have different managers.

Partitioning also fails in a predictable way: partitions drawn on the current organisation chart have to be redrawn at every reorganisation, which breaks every cross-reference in the model. Draw them on subject matter and regulatory boundary, which outlive the reporting lines.