CelinQ Insights · No. 37

Enterprise Architect Multi-User Collaboration: Central Repository vs Local-First Sync

Two honest ways to let several architects share one model, and how to work out which one actually fits your team.

Every team that puts more than one architect into the same Enterprise Architect repository eventually has to answer a question that sounds administrative but is actually architectural: where does the model live, and what happens when two people touch it at the same moment? The question rarely gets asked out loud. It gets answered implicitly, by whichever installation choice happened first — a shared project file on a network drive, a database server someone stood up years ago, a Pro Cloud Server instance the infrastructure team was already running for something else. The answer that quietly gets baked in at that point then shapes how the whole team works for years afterwards, and most people never revisit it because it is not obvious there was ever a decision to make.

There is, in fact, a real decision here, and it deserves to be made deliberately rather than inherited. Broadly, a team sharing an Enterprise Architect model has two coherent architectures available to it. One keeps a single authoritative store that every architect reaches into directly, coordinating access so the store never has to reconcile two conflicting views of itself. The other gives every architect their own local repository and reconciles the differences afterwards, accepting a moment of merge in exchange for never making anyone wait. Both are legitimate engineering answers to the same underlying problem — how do several people jointly own one structured, densely interconnected model without corrupting it — and both have genuine strengths. This article is about understanding the two clearly enough to choose on purpose.

The centralised multi-user model

The traditional shape of multi-user Enterprise Architect is centralisation, and it earns that position honestly. A single repository — historically a shared .eap file on a network share, more robustly a database repository, and at enterprise scale a Pro Cloud Server instance sitting in front of that database — holds the one and only copy of the model that matters. Every architect's copy of Enterprise Architect connects out to that store and works against it directly. There is no ambiguity about which version of an element is current, because there is only ever one version: the one sitting in the shared repository at this instant. Read an element and you are reading the live, current, singular truth. There is nothing to reconcile because nothing was ever allowed to diverge.

That guarantee is bought with coordination. Because everyone is working against the same live store, the store has to protect itself from two people changing the same thing at once, and the traditional mechanism is locking: before you can safely edit an element, you take exclusive access to it, and nobody else can touch it until you release that access. This is a genuinely sound engineering strategy for a single shared store, not a mistake or a legacy wart — it is the correct answer to "how do I stop concurrent writers from corrupting one shared structure," and Pro Cloud Server and EA's own database repositories implement it with real sophistication, layering package-level and element-level control, user security, and audit on top of the basic idea. A team that adopts this model gains a design with a long, well-understood track record and a simplicity that should not be undersold: one place the model lives, one thing to back up, one thing to monitor, no reconciliation logic anywhere because reconciliation was never allowed to become necessary. The article on the real cost of the one-editor-at-a-time problem goes into what that locking discipline feels like from inside a working day; the point here is narrower and more sympathetic to the design — locking is what a single shared store needs in order to stay correct, and staying correct is not a small thing to have bought.

Local replicas and where authority actually sits

The local-first alternative starts from a different premise: instead of one store that everyone reaches into, each architect keeps a genuine, full local repository on their own machine. It behaves, from inside Enterprise Architect, exactly like any other local repository, because it is one. Opening a package, editing an element, drawing a connector, saving a diagram — all of it happens against local storage at the speed of the machine in front of you, with no round trip to anywhere and nothing to wait for. This is what removes the queue that centralisation's locking discipline creates. Two architects can be inside the same package at the same moment and neither one is aware of the other doing so, because neither one's editing session depends on the other's in any way.

The word that matters here, and the one worth being precise about, is authoritative. Local-first does not mean each architect's laptop is a peer with equal and independent claim to the truth of the model; that would be a recipe for chaos rather than collaboration. In CelinQ's architecture, the server still holds the canonical state of the model — the sequence of revisions that everyone's changes eventually flow through and that everyone's local repository eventually reflects. What changes relative to the centralised picture is not who is authoritative, but where the editing happens. Editing is local; canonical state is server-side; the two are kept in step by a synchronisation layer running in the background rather than by every keystroke travelling to the server before it can be committed. A background companion — CelinQ Connect — watches each local repository, captures the changes an architect makes, and carries them to the CelinQ Server, which is the place the organisation's canonical revision history actually lives. Your local repository is real and fast and fully yours to work in, but it is not the last word on what the model says; the server's ordered sequence of revisions is that, and your local copy is continuously reconciled against it rather than standing in permanent competition with it.

This distinction is worth dwelling on because it is easy to caricature local-first as "everyone just has their own model and hopes for the best," which is not what is actually being proposed. The honest description is that authority is centralised while editing is distributed: one canonical sequence of revisions, many local working copies kept in step with it by a synchronisation protocol running over gRPC and protocol buffers between each architect's machine and the server, with SQLite as the default persistence and PostgreSQL available where an organisation needs it. The server is not a passive backup target; it is where conflicts are actually adjudicated and where the ordered history of the model actually lives. Local-first changes where you type, not where the truth is decided.

Smart Sync: the rhythm underneath the collaboration

None of the above works if the reconciliation between local editing and canonical state happens on a schedule that is either too aggressive or too lazy. Too aggressive, and the background synchronisation becomes noisy — hammering the network on every keystroke, draining a laptop battery, cluttering the revision history with a thousand tiny partial edits instead of coherent units of work. Too lazy, and two architects working on related parts of the model can drift apart for long enough that the eventual reconciliation becomes larger and more anxious than it needed to be, and colleagues stop seeing each other's progress in anything like real time.

Smart Sync is CelinQ's answer to that balance, and it works in layers rather than a single fixed interval. The first layer is event-driven: as you edit, the add-in notices the activity and, after a short debounce of a few seconds, gathers what you have done into one coherent changeset rather than sending a revision per keystroke. Underneath that fast path sits a safety synchronisation roughly once a minute, which exists purely to catch anything the event-driven path might have missed — a notification that did not arrive, a cursor that fell slightly behind. And underneath that, a deep reconciliation runs roughly every five minutes, comparing the full state of the local repository against the last known snapshot to recover from any drift that neither of the faster layers caught, including changes made directly in Enterprise Architect outside the normal event stream. The layering matters because each layer covers the failure mode of the one above it: the fast path is quick but can miss an event, the safety sync is more thorough but only checks what it already knows to check, and the deep reconciliation is slow but genuinely exhaustive. No single layer has to be perfect because the layers overlap.

When the workspace gets busy, the cadence tightens on its own. If the server's presence signal reports two or more architects looking at the same diagram, the workspace is treated as hot, and the debounce and safety-sync intervals shrink so that changes propagate faster precisely when people are actively colliding in the same corner of the model. When nobody is contending for the same area, the system relaxes back to its normal cadence rather than sustaining an artificially aggressive rhythm everywhere all the time. None of this is something an architect has to configure or think about session to session; it is a property of the synchronisation layer reading the room and adjusting the pace of reconciliation to match how much reconciliation is actually needed right now.

Presence: knowing where colleagues are without controlling where they go

A centralised, locked repository gives you a very specific kind of awareness almost for free: if an element is locked, you know someone has it, because the lock itself is the signal. A local-first architecture has no locks to read, so it needs a different mechanism if it wants to give architects any sense of where their colleagues currently are — and it does want that, because working alongside people without any sense of what they are doing is its own kind of friction, even when nobody is actually blocked.

Presence supplies that awareness without reintroducing the coordination cost that locking carries. Each connected client sends a lightweight heartbeat to the server reporting which package, diagram, or element it currently has open, and the server keeps that information in memory, not as a permanent record, with a short time-to-live measured in tens of seconds. If a client goes quiet — closed, crashed, or simply disconnected on a train — its presence entry ages out on its own once the TTL elapses, rather than sitting there as a stale claim that someone has to remember to clear. There is no equivalent of a lock left dangling because a colleague went home without releasing it; presence simply expires, quietly and automatically, and nobody has to notice or intervene.

The word that has to be attached to presence, and attached honestly, is advisory. Seeing that a colleague currently has the same diagram open tells you something useful — perhaps that now is a good moment to ping them before you restructure the thing they are looking at — but it does not stop you from editing it anyway, and it is not supposed to. There is no reservation being made, no exclusive claim being staked, no gate that blocks your save. This is a deliberate design choice rather than an oversight: a hard lock sitting on top of a local-first architecture would be a contradiction, because the whole point of editing locally is that nothing about your ability to work depends on what anyone else is doing at that moment. Presence is "who's probably looking at what," offered as a courtesy to help people coordinate socially, and it stops exactly there. When presence detects that two or more people are genuinely active in the same diagram, that is also the signal that tightens Smart Sync's cadence into hot collaboration, so the one piece of awareness the system does have about contention gets put to use making convergence faster rather than being wasted as a passive status light.

What concurrent editing actually looks like

It is worth walking through what happens, mechanically, when two architects genuinely edit the same model at the same moment, because "concurrent editing" can sound abstract until you see its shape. Say one architect renames an application component and adjusts its lifecycle status, while a colleague, in a different local repository, simultaneously adds a tagged value to that same component and draws a new connector from it. Neither is aware of the other — there is no lock forcing a wait, and presence may or may not have surfaced the coincidence. Both save. Both changesets flow, independently, to the CelinQ Server.

What happens next is the part a purely centralised model never has to deal with, because it would have prevented the situation by making the second architect wait for a lock. Here, the server has to reconcile two sets of changes made against the same starting state. This is where Fusion, CelinQ's deterministic three-way merge engine, does its work — comparing each incoming change against the causal base it was made from and the current canonical head, resolving what it can at the level of individual merge atoms rather than whole elements. A rename and a status change on one side, a tagged value and a connector on the other, touch entirely disjoint facts, so Fusion merges them cleanly: both architects' work survives, and neither one waited for or negotiated with the other. Concurrent editing, here, is not a hazard to be prevented in advance. It is the normal case, and the system's job is to make it converge correctly afterwards rather than forbid it from happening.

Eventual convergence, and what "eventual" is doing in that phrase

Convergence is the property that makes any of this trustworthy, and it deserves a precise definition rather than a hand-wave. It means that once every architect's changes have made it to the server and back down again, every local repository ends up reflecting the same canonical state — not immediately at the instant of saving, but reliably once synchronisation has caught up. The word "eventual" is doing real work: at any given moment, two local repositories may briefly disagree about the very latest state, because one of them saved a change moments ago that has not yet propagated to the other. That brief window is the price local-first pays for never making anyone wait, and it is worth naming plainly rather than glossing over.

What convergence promises is that the window closes, reliably, and closes onto the correct combined state rather than onto whichever change happened to arrive last. This is why Fusion's determinism matters as much as its automation: given the same set of concurrent changes, the merge always produces the same result regardless of network timing, so two architects reconnecting after being offline for different lengths of time still end up looking at the same reconciled model. Convergence is not "the model eventually settles into some consistent state." It is "the model eventually settles into the one consistent state that correctly reflects everyone's work" — a stronger, more specific claim, and the one that has to hold for local-first collaboration to be trustworthy rather than merely convenient.

Convergence is not a promise that nobody's edits will ever overlap. It is a promise that when they do, the disagreement is visible, deterministic, and resolved the same way no matter whose laptop reconnects first.

Revision history as the record both models can trust

Whichever architecture a team chooses, the ordered history of what changed, when, and by whom is what makes the model auditable rather than merely current. In a centralised repository, that history has traditionally been thinner than architects would like — a shared file or database that shows you the present state clearly but often requires extra tooling to reconstruct exactly how it got there. Pro Cloud Server and modern EA database repositories have improved substantially on this over the years, and a well-administered central repository can maintain a genuinely useful audit trail; it is not a weakness unique to centralisation, just an area where the two architectures have historically differed in how much attention the history layer received by default.

CelinQ's server keeps a complete, strictly ordered sequence of revisions as the structural backbone of the whole synchronisation model, not as an add-on feature bolted onto the side of it. Every changeset that lands on the server becomes a numbered revision, and every merge that Fusion performs is recorded against that sequence along with the rule that justified it, so the history is not just "what does the model look like now" but "what specific facts changed, in what order, and why did the system consider it safe to combine them." This matters for more than compliance box-ticking, though it certainly serves that purpose too. It is what lets an architect returning from two weeks of leave understand exactly what moved in the model while they were away, rather than diffing a file by hand. It is what lets an administrator investigating an unexpected element state trace it back to the specific revision and the specific merge decision that produced it. And it is what makes the operational picture of who is actually in sync possible at all — client heads, server head, and the gap between them are only meaningful concepts because there is an ordered revision sequence for a client head to be a position within.

Conflict avoidance versus conflict resolution

These two architectures are, at bottom, two different philosophies about when a conflict should be dealt with, and naming that difference plainly is the clearest way to compare them. Centralisation practises conflict avoidance: it stops a conflict from ever coming into existence by forbidding the second person from editing until the first person is done. There is never a moment where two incompatible versions of the same fact both exist, because the locking discipline makes that moment structurally impossible. This is a strong guarantee, and it is bought at the cost of concurrency itself — the price of never having a conflict to resolve is that someone, sometimes, has to wait.

Local-first practises conflict resolution: it lets the conflict happen, because forbidding it would mean forbidding concurrent, offline-capable editing altogether, and then it deals with the conflict afterwards through a process — Fusion's three-way merge — that is deterministic, auditable, and honest about the cases it cannot resolve on its own. The guarantee here is different in kind, not weaker in the abstract, but it is a guarantee about a process rather than about an absence. Where centralisation guarantees "this situation cannot occur," local-first guarantees "when this situation occurs, it will be handled this specific, inspectable way, and if it truly cannot be handled automatically, it will be surfaced to a person rather than silently guessed at." Neither guarantee is strictly better than the other in every context; they are answers to different risk appetites and different working patterns, and a team should be honest with itself about which kind of guarantee it actually needs before assuming the answer.

Which model fits which organisation

It is tempting, writing from inside a company that builds the local-first side of this comparison, to present convergence as a strict upgrade over locking in every case. That would not be honest, and it would not survive contact with the range of teams actually running Enterprise Architect today. The two architectures suit different situations.

A small team that is reliably co-located, on a single fast local network, with editing sessions that rarely overlap, may find a traditional shared-file or central-repository setup perfectly adequate, and simpler to reason about than anything with a reconciliation layer underneath it. If everyone is in the same room, a lock resolves itself in the time it takes to lean over and ask a colleague to save and release, and merge determinism, causal bases, and revision provenance never become relevant, because the situations that would exercise them never arise. There is real value in a design with fewer moving parts, and a team in this position gains little from adopting distributed reconciliation to solve a coordination problem it is not actually experiencing.

The calculation changes as soon as any of a few conditions show up, and most growing architecture practices eventually meet at least one. A team spread across offices, home working, or client sites no longer has the five-second conversation available, and every lock becomes a message sent into the possibility of a slow reply. A team that does real work offline — client sites with restricted networks, trains, flights — cannot use a lock-based repository at all during those hours, and ends up improvising private copies and manual reconciliation, which is exactly the risky practice a proper local-first architecture replaces with something deterministic and audited. A team large enough that contention becomes routine finds that the informal social protocol holding a small team's locking discipline together simply stops scaling, and a traffic-controller role starts to emerge — itself a sign the coordination cost has grown large enough to deserve engineering attention rather than goodwill. And any team for whom being blocked has a real cost, a deadline or a client review tomorrow morning, starts to feel locking not as occasional friction but as a structural risk to delivery.

None of this is a verdict that centralisation is wrong for teams still using it well. It is a description of the pressures that tend to make local-first the better trade, and an acknowledgement that plenty of teams do not yet feel those pressures strongly enough for the trade to be worth it. The right question is not "which architecture is more modern" but "which of these two costs — occasional waiting, or occasional reconciling — does my team actually pay, and which would it rather pay instead." Answered honestly, that question points different teams toward different answers, and that is exactly as it should be.

The honest limits of local-first collaboration

Having made the case for convergence over locking in the situations where it earns its keep, it would be dishonest to close without naming what it costs. Local-first convergence asks a team to trust a process it cannot watch happening in real time. A lock is visible and immediate: you know, the moment you try to edit something, whether you are blocked. A merge happens afterwards, on the server, and the team's confidence in it has to come from the process being deterministic, inspectable, and honest about its own limits, rather than from watching it resolve conflicts as they occur. That trust has to be earned through a visible revision history, transparent rule codes attached to every automatic merge, and conflicts surfaced explicitly rather than quietly guessed at.

There is also a genuine limit to what any merge process, however well designed, can do automatically, and it deserves the actual number rather than a softened version. In a deliberately collision-dense benchmark workload run against CelinQ's real store and merge pipeline — a hundred thousand operations from five concurrent clients, seeded and reproducible — roughly seven in ten of the colliding operations were resolved automatically by Fusion, with zero silent loss and zero resurrection of deleted elements across the whole run. The remaining share, close to three in ten, represented a genuine disagreement about the same fact and was correctly escalated to a human decision rather than guessed at. That is not a shortcoming to apologise for; it is the honest shape of what determinism buys you. A system that claimed to resolve every conflict automatically would either be quietly making a choice on someone's behalf without telling them, or lying about the difficulty of the problem. The thirty percent that needs a human is what keeps the other seventy percent credible.

Two architects genuinely, simultaneously changing the very same fact about the very same element — not adjacent facts that merge cleanly, but the identical property, in incompatible directions — is a situation no merge engine can resolve on its own, because there is no version of "automatically" that correctly guesses which of two people's intentions should win when both are equally valid claims about the same piece of truth. That is not a defect in Fusion; it is what a genuine conflict actually is. What a good local-first architecture owes its users at that point is not a magic resolution but a clear, minimally disruptive surfacing of exactly that disagreement, so the person who understands both intentions can settle it in seconds rather than hunting through an undifferentiated wall of differences.

The fair conclusion, then, is not that one of these architectures has won and the other should be retired. Centralisation and local-first sync answer the same underlying problem — several people jointly owning one structured model — with two different, both defensible, bets about where the cost of collaboration should land. A centrally hosted repository keeps the model in one place and pays for that simplicity with a queue that forms whenever two people want the same thing at once. A local-first architecture removes the queue and pays for that freedom with a reconciliation step that has to be trustworthy, transparent about what it cannot do alone, and honest about the residual share of conflicts that only a person can settle. Choosing between them well means being honest about which of those two costs your team would rather carry, rather than assuming the newer idea is automatically correct for every situation it could technically be applied to.