CelinQ Insights · No. 39

Local-First Enterprise Architect: What Changes When the Repository Lives Beside the User?

The phrase gets used loosely, so it is worth being precise about what actually moves when the repository stops living on a server and starts living beside the person doing the work.

"Local-first" has become one of those terms that gets attached to almost anything with an offline mode, which is a shame, because it originally named something quite specific and quite useful. It is not a synonym for "has a cache" or "can survive a dropped connection for a few minutes." It describes a particular decision about where the authoritative copy of your data lives, and that decision has consequences that ripple through everything else: how the software behaves when you are offline, what the server is actually for, how an organisation deploys the thing, what synchronisation means, who owns the model, how you recover from a bad state, and what the day-to-day experience of using the tool feels like. This article is about taking that phrase seriously for an Enterprise Architect repository specifically, because a model is not a spreadsheet or a text document, and the consequences of moving its primary copy onto an architect's own machine are not the same as moving a to-do list onto a phone.

What "local-first" actually commits you to

Start with the definition, because it is easy to gesture at and harder to pin down. A local-first system is one where the copy of the data on the user's own device is treated as the real thing — not a temporary loan, not a cached view that has to be checked against a more authoritative source before it can be trusted, but the actual working state that reads and writes happen against. The alternative, which is the traditional shape of a shared Enterprise Architect repository, treats the server or the network database as the real thing and treats anything on the architect's machine as, at best, a convenience and at worst a liability that has to be reconciled before it counts. Those two starting points sound similar in casual conversation and are almost opposite in practice.

The test for whether something is genuinely local-first is simple to state: can the user keep doing meaningful, correct work with the network switched off, indefinitely, without that work being provisional? Not "can they view what they last downloaded" — can they actually create new elements, restructure a package, redraw a diagram, and have those changes be as real and as durable as if the network had been present the whole time. If the answer depends on periodically checking in with a server to confirm that an edit is allowed, the system is not local-first no matter how good its offline mode looks in a demo. It is a remote system with a resilient client. The distinction matters because the two designs fail differently, they scale differently across a team, and they put the complexity in different places, which is really the subject of this whole article.

The local repository as working copy, not a cache

In CelinQ's case this is not a metaphor. Each architect works against a local, file-based EA repository sitting on their own machine, and that repository is the one Enterprise Architect actually opens, reads from, and writes to when someone creates an element, drags a connector, or edits a tagged value. Nothing about that interaction touches a network. There is no round trip to validate the write against a server before EA lets you continue, and there is no sense in which the local file is a draft waiting for approval. It is the model. When the architect closes EA at the end of the day, whatever is in that local file is what they made, in the same sense that a document saved on a laptop is the document, not a rough copy of one that lives somewhere else.

Contrast that with a cache, which is the word people reach for when they want to describe something that behaves similarly but isn't quite trusted. A cache exists to be faster than the authoritative source, and it is allowed to be wrong; the whole point of a cache is that it can be invalidated and refreshed without anyone treating that as a loss of data, because the real copy was never at risk. If Enterprise Architect's local file were a cache in that sense, then every offline edit would carry an asterisk — a private note to yourself that it hasn't been confirmed yet, that it might be overwritten wholesale the next time the "real" copy is consulted. That asterisk is exactly what local-first design removes. A background agent, CelinQ Connect, watches the local repository for the changes an architect makes and carries them toward the shared workspace when a connection exists, but it is doing that as a courier for something already complete, not as a gatekeeper deciding whether the work is allowed to have happened.

This has a very practical consequence that is easy to underrate until you have lived without it: read and write performance inside EA never depends on network conditions. Opening a package, expanding a diagram, editing a note — these are local disk operations against a local file, at the speed the machine in front of you can manage, whether you are on the office network, a hotel connection, or nothing at all. A related article in this series looks directly at how CelinQ's approach to what stays local and what moves asynchronously compares with a genuinely centralised repository; the short version is that the repository being real and local, rather than a validated cache, is precisely what makes the performance story possible in the first place, not a separate feature bolted on afterwards.

The server's new job: a control plane, not the primary store

If the local repository is where the real work happens, the natural question is what the server is for, and the honest answer is that it stops being a data store in the sense a traditional shared repository is one, and becomes something closer to a control plane for the collaboration itself. The CelinQ Server holds the canonical shared workspace — the record that everyone's changes eventually converge into — but it is not where any individual architect's edit is made, and it is not something an architect has to reach in order to keep working. Its job is to receive change sets from each local repository, reconcile them against each other, keep an ordered revision history, enforce who is allowed to do what, and make the resulting state available to every other connected client.

That reframing matters because it changes what "the server is down" means. In a traditional centrally hosted repository, the server being unreachable means the model is unreachable, full stop, because the model only exists on the server. In this design, the server being unreachable means the team's collaboration is paused, not that any individual's work is paused. Architects keep modelling locally; what stops is the propagation of changes between people, which is a real cost but a much smaller and more contained one than the whole team being unable to work. The Control Plane console that runs alongside the server reflects this shift in emphasis directly: it is a dashboard for workspaces, connected clients, synchronisation state, Fusion decisions, revision history, monitoring, audit trails and backups — the vocabulary of someone managing a collaboration, not someone managing a single database that everything depends on for basic function.

Offline as the normal case, not the exception being tolerated

It is worth being precise about what "offline-first" means here as well, because it is a phrase that gets weakened in the same way "local-first" does. It does not mean the network is irrelevant, and it is not a claim that a team can stay disconnected forever and everything will be fine — a point this article comes back to in its final section, because pretending otherwise would be dishonest. What it means is narrower and more defensible: connectivity is not a precondition for productive work. An architect on a train, in a client site with a locked-down guest network, or simply between meetings with a laptop and no signal, is not in a degraded mode. They are in the same mode they are in at their desk, because the thing they are editing was never depending on the network to begin with.

Underneath that experience, CelinQ keeps a durable local queue of the changes an architect makes while disconnected. Nothing is held only in memory waiting for a lucky reconnect; the record is written to disk as it happens, which is what makes it safe to close the laptop, lose power, or simply forget about the model for a week and pick it back up later. When a connection returns, the queue replays toward the server, and the replay is built to tolerate exactly the kind of mess that offline periods create — a change sent twice because a connection dropped mid-acknowledgement, an operation replayed after a restart, a batch of edits arriving well out of the order in which some other architect's edits arrived on the server. None of that is treated as an exotic edge case to be handled defensively as an afterthought; it is the ordinary condition the whole synchronisation path is designed around, because if it were not, "offline-first" would just be marketing language sitting on top of a design that still quietly assumed connectivity. A companion piece in this series looks specifically at what a long stretch of disconnected work, such as a flight or a week on a client site, actually does to a repository and to the reconnection that follows; see working offline, syncing later for that detail.

Where the server lives: a deployment choice, not a constraint

Because the local repository carries the weight of day-to-day editing, where the server itself is hosted becomes a genuinely open question rather than something dictated by performance. In a design where every keystroke has to reach a central database, the server's location matters enormously — proximity, network path, and latency to that one machine shape the experience of everyone using it. Once editing happens locally and synchronisation is asynchronous, the server's location stops being a performance question and becomes what it should always have been: an operational and governance question. Does the organisation want to run the CelinQ Server itself, on infrastructure it controls end to end, inside its own network boundary? Or does it prefer to run it in its own cloud account, where it retains ownership of the deployment but benefits from the operational conveniences a cloud environment offers? Both are legitimate answers, and the architecture does not force a choice by making one option slow and the other fast, because neither option sits in the path of an architect's ordinary edit.

What actually needs to be said plainly here, rather than gestured at, is what the server requires to run: an ASP.NET Core host exposing a gRPC synchronisation channel and a REST API, backed by either SQLite for a lighter deployment or PostgreSQL where more concurrency or scale is wanted, reachable over TLS with certificate pinning so that clients only ever talk to the server they are actually meant to. That is a modest, self-hostable footprint by design. Beyond that baseline, the pattern for an organisation wanting deeper integration with a particular cloud provider's identity or managed-database offerings is exactly that — a pattern, a direction the deployment can be taken in according to what the organisation already runs — rather than a specific vendor integration that ships today. The honest way to describe this article's stance is that cloud and on-premises are both real, supportable choices for where the collaboration control plane lives, and the choice belongs to the organisation's own infrastructure policy rather than to the modelling tool.

Synchronisation as coordination, not permission

The word "synchronisation" carries a lot of freight in this design, and it is worth separating it clearly from what it replaces. In a locking model, coordination happens before the edit: you ask permission, in the form of a checkout or a lock, and only once you have it are you allowed to change anything. That is coordination as a precondition. In a local-first model, coordination happens after the edit, in the form of reconciling what has already happened on different machines into a single coherent shared history. That is coordination as an ongoing, asynchronous process rather than a gate you have to pass through before starting work — a distinction the series explores at length elsewhere when it looks specifically at how CelinQ's Smart Sync layer decides when to actually move changes, and at why sending semantic deltas is a fundamentally different exercise from serving every repository interaction over the wire.

In practice this coordination has a rhythm rather than a single fixed moment. CelinQ's default synchronisation behaviour reacts to activity: a short debounce of a few seconds after an edit lets a burst of related changes settle into one coherent change set rather than firing a revision per keystroke, a safety synchronisation runs roughly once a minute regardless of events to catch anything a missed notification let slip, and a deeper reconciliation runs roughly every five minutes to compare the repository's actual state against what was last known and recover from any quiet drift. None of that requires the architect's attention. What it produces, over the course of a working session, is a shared workspace that stays close to current for everyone connected, without any individual edit ever having had to wait for that closeness to be confirmed first.

A locking system coordinates in advance by forbidding concurrency. A local-first system coordinates afterwards by reconciling it. Neither approach makes coordination optional — they only disagree about which side of the edit it happens on.

Who owns the model

Data ownership sounds like a legal or procurement concern rather than an architectural one, but the local-first design actually answers it structurally rather than contractually. When the authoritative copy of a model lives only on a vendor's server, ownership is a matter of trust and terms of service — you own the model in the sense that a contract says you do, but you do not hold it. When the working repository is a genuine local file on the architect's own machine, and the shared workspace runs on infrastructure the organisation itself operates, ownership is closer to a physical fact than a promise. The organisation can point at the machine the server runs on. It can inspect the database. It can take the local `.eap` files off any architect's laptop and open them directly, without CelinQ in the loop at all, because those files were never a proprietary wrapper around the real data — they are the real data, in the same format Enterprise Architect has always used.

This is not a small point for the sector CelinQ is mostly used in. Public-sector and enterprise architecture teams working under procurement rules, data-residency obligations, or straightforward institutional caution about vendor lock-in have a legitimate reason to ask, for any tool, "if this vendor disappeared tomorrow, what would we still have?" For a local-first design built on the file format EA has always used, the answer is the model itself, sitting on the machines and the server the organisation already controls. That is a materially different answer from "whatever the vendor is willing to export," and it follows directly from the architectural decision to make the local and shared copies real rather than dependent artefacts of a hosted service.

Recovery: what it means when there is no single copy to restore

Recovery in a traditional centralised model has a familiar shape: something goes wrong with the one database, you restore it from the most recent backup, and everyone reconnects to the restored copy. It is a clean story precisely because there is only one copy that matters. A local-first design does not have that simplicity, and pretending it does would be the kind of overclaim this series tries hard to avoid. There are now, at minimum, as many meaningful copies of parts of the model as there are architects working locally, plus the canonical shared workspace on the server, and recovery has to account for the possibility that a server restore lands the shared workspace at a point in time that some architect's local repository has already moved well past.

CelinQ's answer to that situation is a workspace epoch — a signal that marks a discontinuity in the shared workspace's history, so that a local client reconnecting after a server restore can recognise that the state it is talking to is not a simple continuation of what it last saw, rather than blindly replaying its queued changes on top of a history that has been rewound underneath it. What actually gets recovered, and how cleanly, still depends on the quality of the revision history the server was keeping before whatever went wrong happened. Recovery is a mechanism for reasoning correctly about that history — it does not replace the need for the history to already be trustworthy. The deeper point, which matters more than any single mechanism, is that recovery in this world is a property of the shared workspace's own audit trail. If that ordered, revision-by-revision record exists and is trustworthy, a bad local state, a bad server restore, or a confusing merge can all be reasoned about and unwound with confidence. If it does not exist, no amount of local resilience helps, because there is nothing authoritative left to reconcile against.

What this actually feels like day to day

It is worth translating all of this out of architecture and into an ordinary Tuesday, because that is ultimately where the value of any of it either shows up or doesn't. An architect opens Enterprise Architect in the morning. The repository opens instantly, because it is a local file, not a connection to negotiate. They spend two hours restructuring a package, adding elements, redrawing a diagram, saving as they go, and at no point does the tool ask them to wait for anything beyond their own machine's disk. A colleague across the building, or across the country, is doing the same thing in their own local repository at the same time, on a different part of the model or occasionally the same part, and neither of them experiences a lock or a "checked out by" message, because there is no shared file for either of them to be locked out of.

In the background, without either architect having to think about it, CelinQ Connect is quietly carrying each of their changes toward the shared workspace on whatever cadence the network conditions and activity level suggest, and quietly bringing the other's changes back down. If both of them genuinely changed the same fact about the same element in incompatible ways, that specific, narrow disagreement gets set aside for a person to look at — visible from inside EA itself through the add-in's Resolve Conflicts option, without anyone having to leave the modelling tool to sort it out. Everything else, which in practice is the overwhelming majority of concurrent work because most edits by different people touch different things, converges without either of them noticing it happened. The published benchmark behind Fusion, CelinQ's reconciliation engine, ran a hundred thousand operations from five concurrent clients through the real storage and merge pipeline, seeded and reproducible, and found zero silent loss of work, zero resurrection of anything genuinely deleted, full convergence to a single agreed state, and roughly seven out of every ten colliding operations resolved automatically — with the remainder correctly escalated to a human rather than guessed at. That last fraction is the honest part of the number: it is not a claim that conflict disappears, only that most of what looks like a conflict at first glance is not one, and the mechanism is careful about which fraction genuinely is.

The presence you see of colleagues working nearby in the model — a small indication of who else has a given diagram or package open — is advisory rather than a lock. It tells you something useful about where attention currently is without ever stopping you from editing what you see someone else looking at. That is a deliberate choice explored more fully in this series' look at multi-user collaboration and the broader question of how a team without hard locks stays coordinated in practice; the short version is that visibility replaces permission, and it turns out to be enough, precisely because the reconciliation underneath it is trustworthy enough not to need permission as a backstop.

The honest limits: complexity relocated, not removed

It would be a poor way to end an article about a genuine architectural trade-off to pretend the trade-off disappears once you like one side of it better. Local-first does not eliminate complexity. It relocates it, and naming exactly where it goes is the responsible thing to do rather than a concession to be minimised in a footnote. In a centralised, locked repository, the hard question a team lives with every day is "can I reach the network right now, and if not, can I do anything at all?" In a local-first design, that question mostly stops mattering, but a different one takes its place: "how much do I trust the reconciliation that happens the next time I do reach the network?" That question is arguably the harder one, because a network outage is at least visible and unambiguous, while a merge that silently made the wrong call is not something you notice by looking at a connection icon. This is exactly why so much of CelinQ's engineering effort sits in Fusion's determinism, its proof-carrying auto-merges, and its refusal to guess at anything genuinely ambiguous — because if that trust were not earned honestly, local-first would simply be trading a loud, visible failure mode for a quiet, dangerous one, which would be a worse bargain, not a better one.

There is a second honest limit that follows directly from the first: a local repository that never synchronises is not a safe, self-contained thing sitting in reserve. It is a repository that is quietly diverging from everyone else's understanding of the model, and the longer it goes without reconciling, the larger and more consequential that divergence can become. Offline-first, properly understood, is not "the network doesn't matter" — it is "the network is not a precondition for productive work," which is a real and valuable property, but it is not the same as saying the network is optional forever. A team is still a team only if the separate local realities its members are building eventually come back together, and that coming-together still depends on connectivity existing at some point, even if it never has to exist at the exact moment someone wants to make an edit.

And recovery, as covered above, is not a free pass either. A local-first architecture makes an individual architect's day-to-day work resilient to a bad network, a bad server, or a bad day entirely — but the organisation's ability to recover from a genuinely bad state, whether that is a corrupted local file, a botched server restore, or a merge someone disputes after the fact, still rests on the shared workspace's revision history existing, being complete, and being trustworthy. That history is not a nice-to-have layered on top of the architecture; it is the thing the whole recovery story quietly depends on, and an organisation adopting a local-first tool is entitled to ask hard questions about how that history is kept, backed up, and audited, in exactly the way they would ask about backups for any system they were about to trust with their institutional knowledge. None of this is an argument against the approach. It is the argument for taking it seriously rather than treating "local-first" as a marketing word that makes the underlying engineering problem disappear. It does not disappear. It moves to where it can actually be inspected, tested, and trusted — which, if you are the person who has to stand behind the model in a review, is a considerably better place for it to live than inside a lock nobody can see the reasoning behind.