From One Architect to an Architecture Practice

Nobody arrives here in one move

Organisations that end up with a governed architecture repository rarely decided to build one. They arrived, over two or three years, because something specific stopped working and the fix happened to be a step along this path.

Understanding that is useful because it tells you how to sequence the work. Each step has to deliver something on its own. A programme that only pays off at the end will be cancelled somewhere in the middle, and the half-built thing will be worse than what it replaced.

Where organisations actually are

Most are at stage two: several architects, models on a share or in Git, conventions that mostly hold, and a set of frustrations everyone has learned to work around.

The frustrations are informative. Whichever one your team met most recently is the one that will fund the next step, and it is worth naming honestly rather than proposing a repository on general principles.

Sequence it around one team

The pattern that works is unglamorous: pick one team, migrate their models, let them work for a month, fix what they complain about, then move to the second team.

This is slower than a big-bang migration and finishes sooner, because the problems that surface in the first month are workflow problems that would otherwise have surfaced simultaneously across every team, at the point where nobody has capacity to fix them.

Choose the first team for enthusiasm rather than importance. A team that wants this to work will report problems constructively. A team that was told to migrate will report that it does not work.

What to leave until later

Several things feel essential and are better deferred:

• Migrating the whole back catalogue. Migrate what is current and owned. Abandoned models can stay where they are; moving them only makes the new repository harder to trust.
• Perfecting conventions first. Conventions improve much faster once search makes inconsistency visible. Waiting for a clean model before adopting the tool that would clean it is backwards.
• Publishing to a wide audience. Get the practice working before adding an audience. A published portal amplifies whatever state the repository is in.

What not to defer

Two things, because retrofitting them is genuinely expensive.

The permission model. Grants made carelessly in month one are the ones nobody dares revoke in year two, because no one is certain what depends on them. Scope properly from the start even when everyone could reasonably see everything.

Audit. It cannot be backfilled. The day someone asks a question about March, either the events exist or they do not.

Knowing it worked

Not adoption numbers. Three observable changes:

1. Architects stop asking each other whether it is safe to open a model.
2. Somebody outside the architecture team answers an architecture question without asking an architect.
3. A governance or audit question gets answered in an afternoon rather than a fortnight.

If none of those has happened after six months, the tooling is in place and the practice has not changed — which is the more common outcome, and the one worth watching for.

What it costs

Being concrete about the investment, since "adopt a repository" can mean anything from a weekend to a programme.

The security review dominates the calendar and almost none of the effort. Starting it early, with the artefacts prepared, is the single largest lever on how long the whole thing takes.

Common ways this stalls

1. Migrating everything first. Six months of data cleanup before anyone gets any benefit, and the sponsor loses interest.
2. Waiting for perfect conventions. The repository is what makes inconsistency visible; waiting for consistency before adopting it is circular.
3. Treating it as an IT project. The tooling is the small part. If no architect is accountable for the practice changing, the tooling gets installed and nothing else happens.
4. Skipping the pilot. Going straight to all teams produces a support queue at exactly the moment the change most needs to look successful.

The pattern behind all four is the same: front-loading cost and back-loading benefit. Anything that gets one team working better within a month is worth more than a comprehensive plan that pays off in a year.

The handover that never happens

The single-architect estate has a specific fragility that nobody plans for: everything that makes it work is in one person's head, and the transition to a practice usually begins when that person leaves.

What goes with them is rarely the models. It is the conventions nobody wrote down, the reason three things are modelled inconsistently, the knowledge that a particular diagram is out of date, and the relationships that made the architecture role possible at all.

The mitigation is not documentation, which will not be written. It is making a second person genuinely co-own something — one domain, modelled by them, reviewed by the incumbent — long before anyone plans to leave. The knowledge transfers through the work or it does not transfer.

The second architect is the hard one

Going from one to two is a bigger step than going from two to five, and organisations are consistently surprised by it.

With one architect there are no coordination problems, no convention disagreements, and no question about who owns what. The second person creates all three at once, and none of the mechanisms exist because none was needed. The estate has no naming convention because it never had to; the packages are structured around how one person thinks; there is no notion of who may edit what.

The instinct is to solve this socially — the two of them agree to coordinate — and that works for about a quarter. What ends it is usually holiday: one person away, the other needing to change something in their area, and no established way to do it.

Getting ahead of this means introducing structure before it is obviously necessary, which is a hard argument to make and the cheapest moment to act.

Where the tooling decision actually bites

A single architect can work happily with files on a laptop for years, and this is often held up as evidence that repository tooling is premature. It is a fair observation about the present and a poor predictor.

The point where file-based working stops is not a headcount. It is the first time two people need the same model in the same week, and that can happen at two architects or not until five, depending entirely on how the domains are split.

What is predictable is the cost of moving later. A file estate at two architects migrates in a day. The same estate at eight, after three years of divergence, is a project with a duplicate reconciliation phase in it. The tooling argument is really an argument about when to pay, and paying early is substantially cheaper.

Splitting the estate between people

The first real decision a practice makes is how to divide ownership, and the three obvious options have different failure modes.

Most practices end up with domains plus a named owner for the integration layer, because the second column of that table is the one that hurts most.

What the first hire should actually do

The instinct when a second architect arrives is to give them a domain and let them model. It is reasonable and it misses the opportunity, because the first month is the only time someone will look at the estate with genuinely fresh eyes.

A more useful first assignment is to have them try to answer three real questions using only the existing estate, and write down where it failed. What depends on this system. Who owns that one. What changed since last quarter. The failures are the practice's actual backlog, and they will never again be as visible as they are to someone in their first fortnight.

Then give them a domain. But the two weeks spent on the questions will shape everything that follows, and they cost nothing.

Stalling at three people

Practices frequently reach three architects and stop developing, which looks like stability and is usually a plateau with a specific cause: at three, everything can still be coordinated in conversation, so none of the mechanisms that would support five ever get built.

The tell is that the practice cannot absorb a fourth person quickly. Onboarding takes a quarter because it depends on absorbing undocumented context. Any new domain requires one of the existing three to be involved. The estate is navigable by those three and nobody else.

Breaking the plateau means doing things that feel like overhead for a team of three: writing the conventions, publishing to a real audience, making ownership explicit. The argument for doing them is not that they help today — they do not — it is that without them the practice cannot grow, and the plateau is invisible from inside it.

What good looks like at each size

It is worth being concrete about the destination, because "mature architecture practice" describes nothing anyone can act on.

• One architect. A model that a successor could pick up. That is the whole bar, and most single-architect estates fail it.
• Two to three. Written conventions, explicit domain ownership, and a repository where concurrent editing does not lose work. Publication is optional but the estate should be readable by someone outside the team.
• Four to eight. A published register with a real audience, a metamodel that is governed rather than accumulated, scoped permissions, and a monthly report somebody acts on.
• More than eight. Everything above, plus an onboarding path that does not depend on any individual, and a measure of the gap between the model and reality.

The budget conversation, and what actually persuades

Growing a practice needs funding, and architecture is chronically bad at asking for it, because the case is usually made in terms of maturity models and capability levels that mean nothing to whoever holds the budget.

What persuades is a cost that is already being paid. The delivery programme that discovered a dependency three months late. The integration built twice because two teams did not know about each other. The regulatory response that took six weeks because nobody could say which systems held the data. Each of those has a number attached and each is an architecture failure with a specific, avoidable cause.

Collecting two or three of them, with the cost and what would have prevented it, is a stronger case than any maturity assessment. It also has the advantage of being true, and of naming what the next hire would actually do rather than describing a capability.

What year three looks like

The adoption path above ends where most guides end — at the point where the machinery works. It is worth describing the state two years later, partly as a destination and partly as a warning about what still needs tending.

By year three, the practice that sequenced this well has stopped being defined by its tooling at all. The repository is assumed, the way source control is assumed by a development team; the Monday publication is ambient; the governance rhythm runs off generated catalogues; and the founding architect — the one whose laptop once was the architecture — has become dispensable in the best sense, able to take three weeks of holiday without the practice noticing operationally. The estate has probably doubled, and the interesting fact is that the operating cost has not: the pipeline, the gates and the conventions absorb growth in a way that the file era absorbed only as pain.

What still needs tending is the human layer, because it decays on a different schedule than infrastructure. Conventions drift as new modellers join faster than the culture transmits; the coverage and quality reports need a reader, not just a generator; and the original sense of why — the lost afternoon, the unanswerable audit question — fades into folklore, leaving rules whose reasons nobody remembers. The year-three practice lead's actual job is curation: retiring perspectives that stopped earning their keep, pruning rules that fire without consequence, and retelling the origin stories often enough that the discipline stays chosen rather than merely inherited. Infrastructure, it turns out, was the easy two years; the practice is the asset, and practices are maintained in conversation, not in configuration.

The path from laptop to practice is walked one funded step at a time, and the walking order matters more than the destination — each stage has to solve a pain someone currently feels, or the next stage never gets its budget. Sequence it that way and the practice arrives almost without noticing; sequence it as a grand programme and it arrives, if at all, exhausted. Small steps, each one paying rent: that is the entire strategy, and it has never needed improving.

Wherever you are on the path, the next step is smaller than it looks — and it is the only one that needs deciding today.