CelinQ Insights · No. 34

Can Sparx Enterprise Architect Work Offline? A Local-First Collaboration Approach

For offline support to be trustworthy it has to mean the same repository, working exactly as it always does — not a fallback mode.

"Can Enterprise Architect work offline?" is a question that sounds simple and is not. The honest answer depends entirely on what you mean by the question, because there are at least three different things "offline" could describe, and they have three completely different answers. Can you open EA with no network connection at all? Can you make meaningful changes to a shared model while disconnected? Can you trust that those changes will be there, correctly folded into the shared model, when you reconnect? A great many discussions about offline capability answer only the first question and quietly skip the other two, which is unfortunate, because the third question is the one that actually determines whether offline work is something you can rely on or something you do nervously and double-check afterwards.

What "offline" actually means

It is worth being precise here because the word gets used loosely. A tool that lets you open a local copy of a file while disconnected, but offers no principled way to reconcile that copy with whatever the team did in the meantime, is not offline-capable in any meaningful sense; it has simply handed you the manual-reconciliation problem and called it a feature. A tool that genuinely supports offline collaboration has to answer a harder question: not "can I edit something locally," but "can two or more people edit locally, independently, without coordination, for an arbitrary length of time, and then have their work combined correctly, with nothing silently lost and nothing silently duplicated." That is the bar this article is measuring against, because it is the only bar that matters to someone who has just landed after a long flight and needs to know whether the morning's work actually survived.

Local repository availability as the starting point

As described elsewhere in this series, every CelinQ-connected architect works against a genuinely local EA repository — a real file on their own machine, read and written through EA's own engine exactly as in any single-user installation. This is the foundation the rest of the offline story rests on, and it is worth being clear about why it matters so much: a local repository does not become "offline" when the network disappears, because it was never depending on the network to begin with. There is no mode switch, no degraded fallback, no separate offline editor with a reduced feature set. It is the same Enterprise Architect, the same repository, the same speed, whether you are sitting on a fast office network or thirty thousand feet over the ocean with no connectivity of any kind.

What happens when the server disappears

From the local repository's point of view, essentially nothing happens, which is exactly the design goal. The background CelinQ Connect agent, which normally carries your changes to the shared workspace and brings colleagues' changes back, simply cannot reach the CelinQ Server. It does not retry aggressively in a way that would drain a battery or throw errors at you; it notices the server is unreachable, backs off, and continues checking periodically while you carry on working entirely unaffected. EA itself never knows the difference: it is talking to its local repository the entire time, exactly as it always does, network or no network.

The local operation journal

Every change you make while disconnected does not simply sit unsaved and hope for the best; it is captured in a durable local queue, journaled before any network attempt is made at all. This ordering matters more than it might first appear: because the journal is written first and the network exchange happens second, a dropped connection, a crashed process, or a machine that goes to sleep mid-flight can never cost you a change that was already saved locally. The queue is durable across restarts — if you close your laptop for the night and reopen it the next morning still disconnected, the queued changes are still there, waiting, exactly as you left them. This is the mechanism that makes it safe to work through an entire multi-hour flight, or several days at a client site with no network access, without the nagging worry that a crash or a restart along the way might quietly erase the morning's effort.

Automatic replay after reconnect

When connectivity returns — the plane lands, the client site's guest network finally admits your laptop, the home connection comes back after an outage — nothing about reconnection requires you to do anything. The agent notices the server is reachable again and resumes exactly where its queue left off, pushing what accumulated while you were disconnected and pulling down whatever the rest of the team published in the meantime. This is not a manual "sync now" step you have to remember, though that option exists for anyone who wants to force it; the default behaviour is that reconnection is invisible, and the queue drains itself in the background while you continue working, exactly as the ongoing synchronisation always does when connected.

Stale changes and why staleness is not the same as loss

A change you made three hours into a flight is, by the time it finally reaches the server, three-hours-and-however-long-the-flight-took old relative to whatever the rest of the team has done since. That staleness is real and worth naming honestly: it means your view of the model, for the duration you were offline, was not the most current one, and neither was anyone else's view of your changes. But staleness is a fundamentally different and much less serious problem than loss. A stale change is simply a change that has not yet been seen by everyone; it is still fully valid, still fully yours, and still fully capable of being reconciled correctly once it arrives. The entire design of CelinQ's synchronisation and merge layer is built around the assumption that changes will routinely arrive stale — from someone who was offline, from someone on a slow connection, from a queue that took a while to drain — and that staleness on its own is never a reason to discard, override, or silently favour one person's work over another's.

Conflict detection after offline work

The genuinely hard part of offline collaboration is not capturing changes while disconnected — that part is comparatively mechanical — it is correctly detecting when two people's offline changes actually collide once both sets arrive at the server. CelinQ's Fusion engine does this using server-side causality rather than trusting the wall-clock time on anyone's laptop, which matters because laptop clocks drift, time zones confuse naive comparisons, and "whoever's timestamp is later wins" is exactly the kind of shortcut that quietly destroys someone's honest work. Every entity in the model carries a version, and every change declares the version it was made against. If your change's declared base matches the server's current version for that entity, the change applies sequentially with nothing to reconcile. If the server has moved on since your declared base — because someone else changed the same entity while you were offline — that is genuine concurrency, and it triggers a proper three-way merge from the shared ancestor state rather than a guess based on arrival order.

That merge works at a granular level: a rename by one person and a status change by another, made to the same element while both were disconnected from each other's work, touch different atoms of that element and merge automatically, because they were never actually in conflict in the first place, merely concurrent. The genuine conflicts — the small number of cases where two people changed the exact same fact in incompatible ways — are the ones Fusion isolates and hands to a person, with both sides shown clearly, rather than silently picking a winner.

Tombstones: the offline case that breaks naive systems

Deletion is where offline collaboration gets genuinely dangerous if it is handled carelessly, and it is worth walking through exactly why. Suppose a colleague deletes an element while you are offline, and, unaware it is gone, you go on to edit that same element during your own offline session — perhaps correcting a tagged value, perhaps refining its documentation. Two naive resolutions are both wrong. A system that treats a deletion as a simple absence might see your incoming edit reference an element that "does not exist" and either quietly resurrect it because your edit implies it should exist, silently reversing your colleague's deliberate decision, or quietly drop your edit because its target is gone, silently erasing your work. Either outcome is a real loss dressed up as a technical detail, and the person affected typically does not discover it until much later, if ever.

CelinQ avoids both failure modes with tombstones: a deletion is recorded as an explicit, versioned fact carried through synchronisation, never merely implied by an entity's absence. Because the deletion is a fact the system can see rather than a gap it has to infer, Fusion recognises the collision for what it genuinely is — one person removed the entity, another concurrently changed it — and raises it as a capsule for a human to resolve, rather than resolving it by accident in either direction. The 100,000-operation Fusion benchmark that exercises this path recorded 556 tombstone capsules across the run and precisely zero resurrections, which is the specific guarantee that matters here: a deletion, once made, is never silently undone by someone else's concurrent edit arriving later.

The test of an offline system is not whether it lets you work while disconnected. Almost anything can do that. The test is whether it can tell the difference between "this is stale" and "this is lost," every single time, without ever confusing the two.

Delete-and-update cases, and the resolutions on offer

When a tombstone capsule is raised, the person resolving it is not handed a bare technical alert; they are shown the entity's state before deletion, the deletion itself, and the concurrent update that collided with it, and asked to make an actual decision: honour the deletion and let the concurrent update go, restore the entity with the update applied because the deletion turns out to have been premature, or — where the situation calls for it — preserve the updated work under a freshly allocated identity so that the historical deleted entity stays cleanly deleted while the new work is not lost. The equivalent situation for creation — someone creates a new child element under a package that, unbeknownst to them, a colleague concurrently deleted while both were offline — is handled by a parallel mechanism, the Rescue Zone, which preserves the newly created work rather than letting it silently vanish into a deleted parent, and offers comparable choices: keep the deletion and relocate the survivors, restore the parent with the new work intact, or restore the new work as a freshly rooted package of its own.

A worked scenario: five days apart, one deleted package

Abstract descriptions of tombstones and rescue zones are easier to trust once they are put through a concrete story, so consider a scenario that genuinely happens in distributed teams. An architect leaves for a week-long client engagement with no reliable connectivity, taking a laptop with a full local copy of the shared model. On day two of that week, back at the office, a colleague decides that a particular subsystem package the offline architect had been quietly working inside is obsolete, and deletes it as part of a planned cleanup, entirely reasonably, with no way to know the offline architect is mid-flight through a set of changes inside exactly that package. On day four, the offline architect, still disconnected, adds two new elements under that same package and refines several existing ones, working entirely from local context with no idea the package has, as far as the rest of the team is concerned, ceased to exist.

When the architect finally reconnects at the end of the week, the naive outcomes are both bad. If the system trusted whichever change arrived last, the colleague's considered deletion — made with full context, as part of a deliberate cleanup — could be silently reversed by an offline edit that had no idea the deletion had happened, undoing a decision nobody asked to have undone. Or, just as badly, the architect's four days of genuine, careful work could vanish into a deleted package with no trace, discovered only much later when the work is needed and turns out not to exist. CelinQ's actual behaviour is neither: the deletion is a recorded tombstone, the four days of edits and the two new elements are recognised as creation-under-deleted-parent, and a Rescue Zone capsule is raised holding all of it — the deletion, and the offline work — visibly, for a human to look at. Whoever resolves it sees exactly what happened on both sides: the colleague's reasoning is not lost, the architect's four days are not lost, and the decision about which one should ultimately stand, or whether the new work should be relocated somewhere else in the model, is made by a person with the full picture rather than guessed at by a merge algorithm working from incomplete information.

How long can you stay offline?

There is no engineered ceiling on how long a local repository can operate disconnected — a week, as in the scenario above, is well within what the architecture is built to handle, and so, mechanically, is considerably longer. The durable local queue does not expire, and the local EA repository does not degrade or lock itself out of further edits simply because it has been a long time since it last reached the server. The honest limiting factor is not the software; it is the amount of genuine divergence that accumulates the longer several people work in parallel without seeing each other's changes, because more time offline generally means more real work done independently, which generally means more of it will genuinely overlap with what colleagues did in the same window. A single architect working alone offline for a week, touching parts of the model nobody else is concurrently editing, will typically reconnect to find everything merges automatically with nothing to review. A team of six, all offline at overlapping times, all working in a densely connected part of the model, will reconnect to find a correspondingly larger, though still bounded and specific, set of genuine conflicts waiting for a decision — not because the system handled the long offline period any worse, but because six people's honest, independent judgement calls genuinely diverged more than one person's could.

Recovery without silently losing work

Underpinning every offline scenario described above is a complete, ordered revision history held on the server: every change that lands, from whatever source and after however long a delay, is recorded as part of a sequence rather than simply overwriting whatever came before. This matters enormously for confidence in the offline story specifically, because it means the state of the model after a complicated multi-person, multi-day offline reconciliation is never a mystery — it is not "trust that it worked," it is "here is exactly what happened, in order, attributable to whoever made each change." If something about a merge looks wrong after the fact, it can be inspected rather than merely accepted, and the system retains the means to recover a prior state if that inspection turns up a problem. Workspace epochs give administrators a structural signal for restore scenarios specifically, so that recovering from a genuinely bad state is a supported operation rather than an emergency improvisation.

Why this differs from "keep a copy and merge by hand"

It is worth being explicit about why this is not simply a more polished version of the old workaround — keeping a private copy of the model and reconciling it manually later — because on the surface the two can sound similar. The manual approach asks a human to do exactly what Fusion does mechanically: figure out what changed, figure out what changed underneath it, and decide how to combine the two without losing anything. The difference is that a human doing this by comparing exported diagrams or reading change logs by eye is working without the one thing that makes the mechanical version trustworthy — a precise, versioned record of the causal base every change was made against. A person cannot reliably tell, just by looking at two versions of a large model, which specific fields two people both touched versus which merely happen to sit near each other in the same package; the visual similarity of "both edited this element" hides the more important distinction between "both edited the same field" and "each edited a different field of the same element," and only the former is a real conflict. Automating that distinction correctly, at the granularity of individual scalar fields, tree position, relationship endpoints, and tagged-value keys, is precisely the engineering effort described in more depth elsewhere in this series, and it is what separates genuine offline collaboration from a slightly better-organised version of hoping for the best.

What offline collaboration does not solve

It would be dishonest to leave the impression that offline support removes the need for judgement, and the series has been consistent about this from its first article onward: some conflicts are genuine disagreements about what the model should say, made by two people who each had good reasons for their choice, and no amount of engineering makes that disagreement disappear on its own. What CelinQ's offline design promises is narrower and more defensible than "conflicts never happen." It promises that everything which can be merged without ambiguity will be merged automatically and correctly, that nothing will ever be silently lost or silently resurrected regardless of how long you were offline or how many other people were also offline at overlapping times, and that the small residue of genuine, irreducible disagreement will be shown to you plainly rather than buried inside an automatic decision you never got to see. Offline work, under this design, is not a special mode with special risks. It is simply work, done on your own schedule, that happens to reconcile a little later than usual — and the "little later" can honestly be hours or days without changing the guarantee.

The honest limit worth stating plainly is this: the longer a team spends offline relative to each other, and the more of them are editing the same corners of the model concurrently, the more genuine conflicts will accumulate for a human to resolve on reconnection, because more real, human disagreement will genuinely have occurred. That is not a flaw in the reconciliation engine; it is a true reflection of how much divergent work actually happened, and no system, however well engineered, should paper over real disagreement by pretending it does not exist. What offline-first design owes you is not the absence of that reckoning, but the certainty that the reckoning will be accurate, visible, and never silent.