The choice
There are two coherent answers to multiple people editing one architecture model. Let everyone edit and combine the results afterwards, or let one person edit at a time.
Software development settled on the first decades ago and does not seriously revisit it. Architecture repositories often choose the second, and it is worth understanding why that is a considered choice rather than a limitation.
Why merging works for code
Merging is viable for source code because of properties code has and models do not.
- Code is written as text by humans, so the diff unit and the authoring unit are the same thing.
- Semantics are largely local — a change in one function rarely invalidates another file.
- There is a compiler, and then a test suite. A bad merge is caught automatically, usually within minutes.
An architecture model has none of these. The serialisation is generated, so diff units are arbitrary. Semantics are global — deleting an element invalidates every relationship and every diagram that referenced it. And there is no compiler: a structurally broken model opens fine and is wrong in ways only a human reading it will notice, possibly months later.
What model merge tools actually do
The counter-argument arrives with a demo: tools exist that three-way-merge models, matching elements by identifier, combining non-conflicting property changes, flagging the rest for a human. The demo works. It is worth understanding precisely why the demo works and the second year of production does not.
The demo merges two branches that each changed different things — a renamed element here, a new application there. Identifier matching handles that case perfectly, because the case contains no actual conflict. The estate, meanwhile, produces the other cases. Two architects each add "the missing CRM integration", as two elements with two identifiers and one meaning — no conflict detected, and the model now says the integration exists twice. One deletes an element the other spent the week connecting — the merge either resurrects the deletion or orphans the connections, and both outcomes are wrong in a way the tool cannot know. And the diagrams: layout is data too, so a merged diagram has two authors' opinions about geometry, and the result reliably looks like neither intended, which for a diagram is the same as being wrong.
The honest summary is that model merge tools automate the merges that were never dangerous, and hand the dangerous ones to a human — who must now reconstruct two weeks of two colleagues' intent inside a conflict dialog, on a Friday, with less context than either author had. Locking spends its cost up front, in visible coordination; merging defers the cost to the exact moment when the least context is available. There are situations where the deferred bet is fine — genuinely disjoint packages, a bulk import landing in its own branch — and a practice can permit those deliberately. As the default posture for a shared estate, the demo is not the product.
What locking actually costs
Being fair to the other side: locking has real costs and they are not trivial.
You cannot explore two target architectures in parallel on the same model. Coordination becomes explicit — someone has to wait, and waiting is visible and irritating in a way that a merge conflict resolved alone at 6pm is not. And a lock left held by someone on holiday blocks work.
That last one is the practical objection and it has a practical answer: make the lock a lease rather than a lock. Time-limited, renewed automatically while the client is alive, expiring on its own if it is not. A laptop that closes on Friday releases its lease without anyone chasing anyone.
A lock with no expiry is an operational problem waiting to happen. A lease with a sensible renewal interval removes almost all of the human cost of locking, and it is the single design decision that determines whether people accept the model.
Locking is not enough on its own
A subtlety that catches implementations: a lock prevents concurrent editing but does not prevent stale publishing.
Consider an architect who opens a model, takes a copy, and works offline. Their lease expires. Someone else takes a lease, edits, publishes. The first architect comes back and publishes their version, which was based on a revision that is no longer current. No lock was violated. Work is lost anyway.
The fix is to carry the base revision with the publish and reject it if the server has moved on — optimistic concurrency layered on top of the lock. Locking handles the common case cooperatively; the revision check makes correctness unconditional.
The offline reality
Any locking design meets its hardest test on a train. Architects work on laptops, laptops leave the network, and a scheme that equates "editing" with "holding a live lease" quietly forbids working offline — which means it will be worked around, and the workaround will be copies of the model in personal folders, which is the outcome the whole system existed to prevent.
The design that survives contact acknowledges two modes. Connected, the lease does its job: editing the shared model requires holding it, renewal is invisible, and conflicts are prevented rather than resolved. Disconnected, the tool keeps working against a local copy and is honest about what that means — the copy records which revision it started from, and bringing the work back is an explicit act with an explicit outcome. If the shared model has not moved, the return is a publish like any other. If it has, the revision check from the previous section fires, and the architect is told before anything is overwritten, not after.
What makes the reconciliation tolerable in practice is scope discipline rather than tooling cleverness. An afternoon of offline work on a model nobody else touched — the overwhelmingly common case — reconciles in one click. A fortnight of offline work on the estate's busiest model reconciles as painfully as it deserves to, and the pain is the system communicating something true: that was a branch, not an edit, and it should have been coordinated as one. The tooling's obligation is to make the common case frictionless and the dangerous case loud; it is not to make the dangerous case painless, because painless is precisely the false promise that optimistic schemes make and cannot keep.
Granularity
If locking, what is the unit? Options run from the whole repository (unusable) to individual elements (appealing and much harder than it looks).
Element-level locking sounds like the best of both worlds and founders on the same problem as merging: the semantics are not local. Locking one element does not protect the relationships attached to it, or the diagrams it appears on. A lock that does not cover the blast radius of the change is not really a lock.
Model-level locking is coarse and defensible. It is comprehensible to users — "someone is editing this model" — and it genuinely covers the affected scope. If models are small enough that one architect editing one of them is not a bottleneck, this is the right granularity, and it is also an argument for keeping models bounded.
Partitioning the estate so locks rarely collide
Model-level locking is only as painful as the models are big. That turns partitioning — how the estate is cut into models — from an organisational nicety into the primary concurrency design decision, and it is worth making with the lock explicitly in mind.
The test is simple to state: two architects who are likely to work in the same week should usually be working in different models. Domains achieve this naturally — Payments and Customer Data have different owners with different calendars — which is one more reason domain boundaries beat organisational ones. What breaks it is the accumulator model: the "Shared", "Common" or "Enterprise" model that everything references and everyone occasionally needs to touch, which under locking becomes the estate's one genuine bottleneck. The cure is to make the shared model boring: reference data and stable building blocks, changed rarely and deliberately, with anything actively evolving moved out to the domain that is evolving it. A shared model whose lock is held ten minutes a week is infrastructure; one held three hours a day is a partitioning mistake wearing a concurrency costume.
Cross-model references make the partitioning workable — a domain model pointing at elements it does not own, without needing to hold their lock to do so. The discipline they need is the same one any multi-user convention needs: references point at identifiers, the referenced element's owner remains its only editor, and a periodic check reports references whose targets have moved or retired. With that in place, the practical lock contention in a well-partitioned estate rounds to zero — which is the quiet punchline of the whole locking debate. Most of the concurrency problem was never a tooling problem; it was a boundaries problem, and boundaries are architecture, which is the one thing this audience is professionally equipped to fix.
Choosing
Ask which failure you would rather explain. "You have to wait twenty minutes for Jan to finish" is annoying and comprehensible. "The model has been subtly wrong since March and we do not know which decisions were based on it" is not.
What this looks like in the tools you have
The theory maps onto the two tools this audience actually runs. Sparx Enterprise Architect ships the locking model half-built: "Require User Lock to Edit" turns the repository pessimistic, locks apply per package or element, and the practical craft is choosing the package grain well — which is the partitioning argument above, expressed in Sparx configuration. What EA does not give you is the lease: its locks persist until released, so the architect-on-holiday problem is real and the practice needs an explicit routine for reviewing and force-releasing stale locks, with the audit log switched on so force-releases are visible.
Archi comes from the opposite corner: a file-per-model tool with no server and therefore no locks at all, which works precisely until the models outgrow the files. Teams first reach for Git as the coordination layer and meet every merge problem in this article wearing XML syntax; the workable end state is a collaboration server that owns the models and implements the lease-and-revision scheme properly, with the desktop tool as its client. In both ecosystems the destination is the same: coordination enforced by the platform, visible to the people it coordinates, and boring enough that nobody discusses it in six months — which is the only success criterion a concurrency model has.
Designing the lease
If leases are what makes locking acceptable, the parameters deserve more thought than they usually get.
| Parameter | Typical | What goes wrong at the extremes |
|---|---|---|
| Lease duration | 15–30 minutes | Too short interrupts real work; too long blocks the estate |
| Renewal interval | A third of the duration | Too infrequent loses leases on a slow network |
| Grace after client exit | None — release immediately | A held lease after a clean exit is pure friction |
| Admin force-release | Always available, always audited | Without it, one holiday blocks a model for a fortnight |
The renewal interval matters more than the duration. A thirty-minute lease renewed every ten minutes survives a brief network interruption; one renewed every twenty-five does not, and the architect discovers this when their publish is rejected.
Reviewing changes when there is no pull request
The workflow software teams would miss most under locking is not parallel editing — it is review. A pull request is a proposed change, visible before it lands, with a place to argue. Locking has no natural equivalent: the architect holds the model, edits it, publishes, and the change is simply there. For an estate that answers to governance processes, "review happens after the fact or not at all" is a real weakness, and pretending otherwise concedes the best argument the merging camp has.
The workable substitute is built from revisions rather than branches. If every publish is an immutable revision with an author and a summary, then a change log per model falls out for free, and a generated diff between two revisions — elements added, removed, renamed, re-related, expressed in model terms rather than XML — is a reviewable artefact. Review becomes a cadence instead of a gate: the domain's architects walk the week's revisions in half an hour, the way teams walk a kanban board. For the small set of changes that genuinely need approval before they land — retiring a platform, touching a regulated perimeter — the practice can require a pre-publish review of exactly those, defined by rule, which is a far smaller and more enforceable demand than reviewing everything.
What makes the whole arrangement honest is that the revision history is complete: nothing reaches the shared model except through a publish, every publish is attributed and summarised, and the summaries are written when context is fresh rather than reconstructed for an auditor a year later. Teams that run this well report something unexpected — review quality goes up compared with their pull-request days, because the reviewer reads a semantic change list instead of a serialisation diff, and the conversation happens in architecture vocabulary rather than in line numbers.
What users should see
Locking is only acceptable if it is legible. Three things the client has to show, and most implementations show none of them:
- Who holds the lock, and since when. "Locked" is obstructive. "Held by Jan since 14:20" is actionable — you can message Jan.
- Your own lease status. An architect who does not know they are holding a lease will not release it.
- What happens when it expires. Ideally a warning before, not a rejection after.
Systems that get this wrong generate a support queue that looks like complaints about locking and is really complaints about not being told anything.
The decision, on one page
For the practice lead who has read the arguments and wants the summary to take into a meeting, the choice compresses into five questions. Who reads this model — architects only, or a governed audience that will act on it? What happens when it is subtly wrong — an awkward conversation, or a finding with a reference number? How often do two people genuinely need the same model in the same week — and is that frequency a fact of the work or a symptom of poor partitioning? Does the team have the Git fluency to pay merging's costs competently — because a merge workflow run by people who fear it combines every disadvantage of both models? And can your tooling deliver leases, revision checks and visible lock state — because locking without those is the caricature its critics describe?
Estates that answer "governed audience, findings, rarely, mixed fluency, yes" — which in our experience is most of them — should lock, partition well, and stop apologising for it. The concurrency model is not the interesting part of an architecture practice; the trustworthiness of what it publishes is, and the whole argument of this article is that the boring choice defends that trust better than the clever one.