CelinQ Insights · No. 55

Locks or Convergence? Two Ways to Protect a Shared Enterprise Architect Model

Pessimistic locking and optimistic convergence both protect a shared model, just by paying for different things. Knowing which one your team needs is the real decision.

Every team sharing a single Enterprise Architect model faces the same underlying question, whether or not anyone ever states it explicitly: what happens when two people try to change the same thing at the same time? There are, in the end, only two honest families of answer. One family prevents the situation from ever occurring by making people take turns — this is locking, and Sparx EA's traditional shared-repository behaviour is built on it. The other family lets the situation occur and reconciles the result afterwards — this is convergence, and it is what a local-first, synchronising platform like CelinQ does instead. Neither of these is a trick or a shortcut. Each is a real engineering strategy with a real cost, and the honest way to choose between them is to understand exactly what each one is paying for, not to assume one is simply more modern than the other.

Pessimistic locking: consistency purchased with waiting

Locking is called pessimistic in the technical sense of the word: it assumes, by design, that a collision between two people's edits is likely enough, or costly enough, that the only responsible thing to do is prevent it outright rather than risk it happening. Before you can change something, you take an exclusive claim on it, and while you hold that claim nobody else can touch the same thing. There is no ambiguity to resolve later, because the system never allows the ambiguous situation to arise in the first place. A single shared repository or database, with every read and write passing through the one authoritative store, is the natural home for this strategy, because the store itself is the single point where an exclusive claim can be checked and enforced with certainty.

What this buys a team is genuine and should not be understated: at every moment, the model is in exactly one state, and nobody can be surprised by a change they did not expect, because no change happens without first taking a claim that made its scope visible. For situations where the cost of even a small, mergeable-in-principle collision is unacceptable — a live migration script that must run against a completely static repository, a formal governance review where only the reviewer of record may touch the artefact under examination — that certainty is worth exactly what it costs. The cost, as covered elsewhere in this series, is that the certainty is bought with waiting, and the waiting is paid by far more people than the collisions it was protecting against would ever have actually affected, because a lock cannot distinguish in advance between a genuine coming collision and two people who were never going to touch the same fact at all. It stops both, every time, because stopping both is the only way to guarantee the promise it is making.

Optimistic convergence: availability purchased with reconciliation

Convergence takes the opposite bet. It assumes that most concurrent work does not actually collide — that two architects working in the same model are, most of the time, working on genuinely different things, even when those things happen to sit close together in the package tree — and it lets everyone proceed without asking permission first. Each architect edits a fully local copy of the repository at full speed, with no round trip to anyone else required for any ordinary operation, and a background process reconciles everyone's work afterwards. When the bet pays off, which in practice is most of the time, nobody waited for anything and nobody was ever aware a decision about waiting even needed to be made. When the bet does not pay off — when two people genuinely did change the same fact — the system has to notice, and it has to resolve that collision honestly rather than silently, because an optimistic strategy that occasionally loses someone's work without telling them would be worse than the pessimism it replaced.

This is where the actual engineering weight of a convergence-based system lives, and it is worth being honest that it is real weight rather than a detail to be waved away. CelinQ's local-first architecture keeps each architect's repository fast and fully usable offline; a background agent, CelinQ Connect, carries changes to a shared workspace asynchronously, and Smart Sync's layered cadence — an event-driven fast path, a sixty-second safety net, a five-minute deep reconciliation — keeps the window during which two people's work can diverge undetected as small as it can reasonably be made without ever asking an EA operation to wait on the network. When genuine collisions do occur despite that narrowed window, CelinQ's Fusion merge engine resolves them deterministically at the level of individual model facts, automatically combining everything that does not actually conflict and isolating, for a human decision, only the narrow set of facts where two people genuinely disagreed. None of that is free to build, and none of it is free to run. Convergence trades the certainty a lock provides for availability — nobody ever waits — but it pays for that availability with the complexity of reconciling afterwards, and the honesty of that reconciliation is the entire basis on which the trade is worth making.

Where centralised consistency genuinely wins

It would be a poor argument to pretend the centralised, locked model has no genuine strengths, and this series has been careful throughout not to attack it as a design choice, only to describe honestly what it costs. A small, co-located team working almost entirely on a fast local network, where the model is not so large or so densely worked that lock contention becomes routine, can live comfortably inside a centralised repository for years without feeling much of the friction described elsewhere in this series. Centralisation also removes an entire category of problem that a convergence-based system has to solve deliberately: there is never a moment where two versions of the model actually disagree, because there is only ever one version, full stop. For an organisation whose governance model already assumes a single point of control — a single database to back up, a single access log to audit, a single place where "the current state of the model" is unambiguously defined without needing a revision history to establish it — a centralised repository is not a compromise. It is a clean match for how the organisation already thinks about its own architecture practice, and reaching for a fundamentally different collaboration model in that context would be solving a problem the organisation does not actually have.

The strength of centralisation is sharpest precisely in the situations locking was built for: operations that genuinely require exclusivity, not just convenience. A repository-wide restructuring script, a scheduled maintenance window, a compliance process that deliberately wants a single named individual accountable for a specific change with nobody else able to touch it in the meantime — these are situations where a lock is not friction to be minimised but the actual point of the exercise, and no amount of clever reconciliation engineering changes that. Recognising this honestly is part of why CelinQ's own presence system deliberately stops short of hard enforcement for ordinary editing while leaving room, in principle, for narrower, purpose-built exclusivity where an organisation's specific governance needs actually call for it.

Where local-first availability genuinely wins

The strength of the convergence model is sharpest in exactly the situations that make centralisation painful: distributed teams, unreliable networks, and honestly concurrent, exploratory modelling work where the cost of two people occasionally touching the same fact is real but small, and vastly outweighed by the cost of everyone waiting on everyone else as a matter of routine. An architect working from a client site with a locked-down guest network, a team spread across offices in different countries and time zones, a consultancy whose people spend half their week travelling — all of these situations turn a centralised repository's core assumption, that the network to the authoritative store is reliably present, into the single biggest source of daily friction the team experiences. Offline work stops being a special mode you have to remember to plan for and becomes simply what local-first editing already looks like when there happens to be nowhere to synchronise to yet.

Local-first availability also changes something less obvious than raw uptime: it changes what people are willing to attempt. A team that knows coordinating access to a package costs real friction quietly stops making the small, unglamorous improvements that would have made the model better, because the friction of asking permission is not worth it for a minor fix. A team where nobody ever has to ask permission makes those improvements as a matter of course, because there was never a queue to join in the first place. That effect compounds with team size in a way that matters increasingly as an organisation's modelling practice grows: a centralised repository's contention scales with the number of people trying to use it at once, while a converging, local-first one does not, because there was never a shared bottleneck for a growing team to queue behind.

The honest trade-off, stated as a single sentence each way

It is worth putting the two positions side by side in the plainest possible terms, because most of the disagreement between them, in practice, comes down to which of two sentences a given team finds more true of their own situation. The case for locking is this: when the cost of a genuine collision is high and the rate of true concurrent contention is also high, preventing collisions structurally is worth the waiting it imposes on everyone, including the many people who were never actually going to collide. The case for convergence is this: when most concurrent work does not actually collide, and the cost of occasionally reconciling the small number of cases that do is smaller than the cost of routinely stopping everyone else, letting people proceed and reconciling afterwards is worth the engineering complexity that honest reconciliation requires. Both sentences can be true. They are just rarely true of the same team, on the same model, at the same point in its life.

The question worth asking is not "which approach is better" but "which cost does my team actually pay more often — the cost of waiting, or the cost of reconciling." Most teams, honestly examined, are paying one of these two costs constantly without ever having framed it that way.

What CelinQ actually is: convergence with a deliberate escape hatch, not convergence alone

It would misrepresent CelinQ to describe it as simply "the convergence option" set against "the locking option" as if the platform were a pure ideological commitment to one side of this trade-off. In practice, CelinQ narrows the convergence side's central weakness — the cost and frequency of genuine collisions — through several layers working together rather than leaving that weakness unaddressed. Smart Sync shrinks the window during which two people's work can diverge undetected, so that most potential collisions never get the chance to happen at all. Presence gives architects the same situational awareness a colleague at the next desk would provide, without ever enforcing anything, so that human judgement can prevent a collision before the system ever needs to. Hot Collaboration notices when two people are actually working on the same diagram together and tightens the cadence specifically there, for exactly as long as the contention is real. And when a genuine conflict does occur despite all of that — because it sometimes will — Fusion resolves it deterministically, isolating only the narrow set of facts that truly disagree and never guessing at a resolution for the sake of appearing seamless.

What this design deliberately does not do is pretend that these layers make genuine, human-level disagreement disappear. Two architects who hold different, well-reasoned opinions about how a subsystem should be structured will still disagree after Fusion runs, exactly as they would under any collaboration model, because that disagreement was never a technical merge problem to begin with — it is an architectural judgement call that software should surface honestly to the people qualified to make it, not attempt to resolve on their behalf. What convergence changes is not whether such disagreements happen. It is who has to wait, and for how long, while everything that is not a genuine disagreement gets out of the way automatically first.

A worked comparison: the same afternoon, two architectures

Abstract trade-offs are easier to weigh with a concrete afternoon in front of them. Picture a team of six architects maintaining a large, actively evolving model, and picture the same ordinary Tuesday playing out twice, once under each architecture. Under a centralised, locked repository, three of the six spend part of the morning waiting: one for a package another colleague checked out an hour ago and has not yet released, one for an element inside a diagram someone is quietly still reviewing even though they finished editing it, and one for a lock that was simply never released because its owner stepped into an unplanned call. None of these three people are actually in danger of colliding with the colleague blocking them — their planned changes touch entirely different parts of the model — but the lock cannot know that, so it stops them regardless. By early afternoon, two of the three have given up on the specific task they intended to do and moved to something else, planning to return to the blocked work tomorrow. The model at the end of the day is entirely consistent, with a complete and unambiguous single state at every moment, and roughly half a day of two people's planned work simply did not happen.

Under a converging, local-first architecture, the same six people spend the same morning editing simultaneously without anyone waiting on anyone else, because there was never a claim to take in the first place. Four of the six never touch anything the others touched, and their changes combine automatically as Smart Sync propagates them, with no human decision required for any of it. One pair does genuinely collide — both, independently, adjust the same tagged value on the same element while reorganising overlapping parts of the model — and Fusion isolates exactly that one fact rather than either of their broader changes, presenting it as a short, specific decision that takes the two of them a few minutes to resolve together once they notice it, rather than the half-day the locked scenario cost two entirely different people who were never actually at risk of colliding at all. The model at the end of this day is also entirely consistent, converged through a documented, deterministic process rather than a single continuously-maintained store, and the total cost paid across the team was a few minutes of one pair's attention rather than half a day spread across two people who had done nothing wrong.

This comparison is not intended to prove convergence always wins — a team whose collision rate looked more like the locked scenario's blocked mornings than its rare single conflict would be paying a very different set of costs, and for them the calculation could point the other way entirely. What the comparison is meant to show is where each architecture's cost actually falls. Locking's cost falls broadly, on everyone who might have collided whether or not they actually would have. Convergence's cost falls narrowly, on the specific people who actually did collide, and only for as long as it takes them to look at the specific fact in dispute. Which of those cost distributions a team would rather live with is, again, a question worth answering honestly rather than by default.

A practical way to decide, rather than a universal answer

Teams asking themselves which model actually fits their situation are better served by a small number of honest questions than by a general preference for one philosophy over the other. How often, in practice, do two people on this team actually touch the same element in the same short window — not how often it feels like it happens in memory, which tends to overstate the rare, memorable collisions and forget the much larger number of days nothing collided at all, but how often it genuinely does? How much does the team's work depend on being productive while disconnected from the office network, whether because of travel, client sites, or simply working from home on an unreliable connection? Does the organisation's governance model already assume a single, unambiguous authoritative state at every instant, in a way that a revision history and a merge log would not satisfy even if both were complete and auditable? And, honestly, how much of the team's current frustration with locking is really about genuine risk of collision, versus the accumulated cost of being stopped for collisions that were never actually going to happen?

For teams whose honest answers point toward frequent, high-stakes, genuinely-concurrent contention over the same narrow artefacts, and toward a governance culture that already expects single-point control, a centralised, locked repository remains a reasonable and unembarrassing choice — not a legacy approach waiting to be replaced, but a design suited to a real set of needs. For teams whose honest answers point toward distributed work, unreliable connectivity, and a pattern where most concurrent work simply does not collide, a local-first, convergence-based platform removes a daily cost that a locked repository was never going to stop imposing, in exchange for trusting a reconciliation process that has to earn that trust by being deterministic, transparent, and honest about the narrow set of moments where only a person can decide. Both are real answers to the same real question. The wrong answer is the one arrived at by habit rather than by actually asking, for a specific team on a specific model, which cost they would rather be paying.

It is also worth acknowledging that the choice is rarely made once and left alone. A team's honest answers to these questions change as the team grows, as its clients demand more travel, as a model gets larger and more densely interconnected, or as a governance framework tightens around a specific class of change. A small, co-located team that chose centralisation sensibly five years ago may well find, today, that it has quietly grown into the shape of team that pays convergence's costs more gladly than locking's — more people, more travel, more of the day spent away from the office network that made the original choice comfortable. Revisiting the question periodically, rather than treating the original decision as permanent, is itself part of taking the trade-off seriously rather than defending whichever side of it a team happened to start on.