CelinQ Insights · No. 13

Working offline, syncing later: modelling on a train and a plane

Connectivity should shape your day, not your ability to work.

There is a particular kind of frustration that architects have learned to accept as normal, and it usually arrives about forty minutes into a train journey. You have two clear hours ahead of you, a laptop with plenty of battery, and a stretch of modelling work you have been meaning to get to for a week. You open the repository, and something hesitates. A dialog appears, or a status bar spins, or an operation that should be instant simply refuses to complete. The connection to the shared database has dropped, or it never came back after the tunnel, and the tool you rely on has quietly decided that without the server it cannot let you do the thing you sat down to do. So you close the laptop, or you switch to answering email, and the two hours you had earmarked for real work become two hours of waiting for a signal.

This is not a rare edge case that happens to a handful of unlucky people. It is the ordinary texture of professional life for anyone who models on the move, and enterprise architects move a great deal. They sit in client offices with guest networks that block database ports. They ride trains through regions where coverage comes and goes every few minutes. They fly. They work from hotel rooms where the connection is technically present but slow enough to make any round trip to a central server feel like wading through wet sand. For all of these people, the assumption baked into a great deal of shared-repository tooling — that the network is always there, and that being connected is the same thing as being able to work — is simply false, and it has been false for the entire history of the profession.

The hidden tax of the always-connected assumption

It helps to be precise about where the pain actually comes from, because the instinct is to blame the network, and the network is only half the story. Sparx Enterprise Architect can be pointed at a shared database, and for teams sitting on the same fast local network that arrangement can feel perfectly comfortable. The trouble begins the moment the distance between the architect and the database grows. Every meaningful operation — opening a package, reading the properties of an element, saving a change — becomes a conversation with a machine that might be in another building, another city, or another country. When that conversation is fast, you barely notice it. When it is slow, every click carries a small delay, and those delays accumulate into a workday that feels like it is happening underwater. When the conversation fails entirely, the work stops.

The usual workaround is to keep a local copy and reconcile it later by hand, and anyone who has done this knows exactly how it ends. You take a private version of the model away with you, you make your changes, and when you come back you face the reconstruction problem: what did I change, what did my colleagues change while I was gone, and how do I fold my work back into the shared model without quietly overwriting theirs or losing my own? The reconciliation is manual, it is tedious, and it is precisely the kind of task where fatigue produces mistakes. So people avoid the situation altogether. They wait until they are back at a desk with a good connection before touching the model at all, and in doing so they surrender all the scattered hours — the trains, the flights, the quiet mornings in a hotel — that could have been productive. The always-connected assumption does not just cost the occasional interrupted session. It teaches architects, over years, not to even try.

There is a second cost that is easier to overlook. When working offline is unreliable, people stop trusting their own tools during the moments that matter most. A client asks a pointed question in a meeting where the guest wifi is unusable, and instead of opening the live model and answering with confidence, the architect reaches for a stale screenshot or a printout, because that is the only artefact they can be sure will be there. The model, which should be the authoritative source, becomes something you consult only under laboratory conditions. That erosion of trust is subtle and corrosive, and it undermines the whole point of maintaining a rigorous repository in the first place.

Local-first is a different starting assumption

CelinQ begins from the opposite premise. Instead of treating your machine as a thin window onto a distant database, it treats your machine as the place where the work genuinely lives. Each architect edits a local repository that sits on their own laptop, and that local repository is the real thing, not a temporary cache waiting to be validated by a server. Every operation you perform — opening a package, editing an element, restructuring a diagram, saving your progress — happens against local storage at the full speed of the machine in front of you. There is no round trip. There is no waiting for a remote database to acknowledge a read. Whether you are sitting on a fast office network, riding through a tunnel with no signal at all, or working from a plane at cruising altitude, the experience of modelling is identical, because the modelling never depended on the network to begin with.

Alongside Enterprise Architect, a background companion watches your local repository and keeps it in step with a shared workspace that your organisation runs on its own server. When you have a connection, that companion quietly carries your saved changes up to the shared workspace and brings your colleagues' changes down to you. When you do not have a connection, it simply waits, holding your work safely in the local repository, and picks up again the moment the network returns. Crucially, none of this waiting is your problem to manage. You do not switch the tool into an offline mode before boarding, and you do not remember to switch it back afterwards. You work, you save, and the synchronisation happens around you as conditions allow.

The train scenario, then, looks completely different. You board, you open the repository, and you work for two uninterrupted hours exactly as you would at your desk, because you are editing local storage and nothing is asking a distant server for permission. Somewhere in the middle of the journey the train passes through a stretch with decent coverage, and the companion takes the opportunity to send up what you have done so far and pull down anything new. You are not aware of it happening. You certainly are not blocked by it. When you finally arrive and connect to a proper network, whatever remains outstanding flows across, and the shared workspace reflects your morning's work as though you had been at the office the whole time.

What happens when the plane lands

The genuinely interesting question is not how the offline editing works — editing local storage quickly is not, on its own, a remarkable feat. The interesting question is what happens on reconnection, because that is where the manual-reconciliation nightmare has always lived, and it is where most attempts at offline modelling quietly fall apart. You spent three hours in the air reworking a domain model. While you were gone, two colleagues were also working, and the shared workspace has moved on. The moment your companion reconnects, it has to fold your three hours of work together with everything that changed underneath you, and it has to do so without silently discarding anyone's contribution.

This is the job of CelinQ Fusion, the merge engine at the centre of the platform. Fusion does not work at the crude level of whole files or whole packages, where any overlap forces an all-or-nothing choice about whose version survives. It works at the granularity of individual model facts — the specific properties, relationships, and attributes that make up your model. When you and a colleague have been working on entirely different parts of the model, or even on different aspects of the same element, Fusion recognises that your changes and theirs do not actually collide, and it combines them cleanly. The merge is deterministic and reproducible, which means that given the same set of changes it always produces the same result, and that result does not depend on who happened to reconnect first.

That last point deserves emphasis because it is the quiet killer in so many synchronising systems. The default behaviour in a great deal of tooling is last-write-wins: whoever saves most recently overwrites whatever came before, and the earlier work simply vanishes, often without anyone noticing until much later. In an offline-heavy workflow this is catastrophic, because the person coming back from a long flight is almost guaranteed to be writing last, and last-write-wins would mean their reconnection could erase hours of a colleague's careful work — or their own could be erased by someone else's later save. CelinQ refuses this behaviour outright. It never resolves a real disagreement by picking a winner based on timing. When two changes genuinely conflict — when they touch the same fact in incompatible ways — Fusion does not guess. It isolates the conflict explicitly, sets it aside, and surfaces it so that a person can look at both sides and decide, with full knowledge of what each change was trying to do.

There is a real honesty in that design. A merge engine that promised to resolve every possible conflict automatically would be lying, because some conflicts are genuine disagreements about the shape of the model that only a human with context can settle. What CelinQ promises instead is narrower and more trustworthy: it will merge everything that can be merged without ambiguity, it will never destroy work to make a conflict disappear, and it will show you clearly and specifically the small number of places where two people really did make incompatible decisions. Coming back from a plane, you are not handed a monolithic wall of differences to untangle. You are handed a clean, combined model with a short, honest list of the specific points that need your judgement, if there are any at all.

Deletions, history, and the fear of losing work

Deletion is the case that makes people most nervous about any offline arrangement, and rightly so. Suppose that while you were offline, a colleague deleted an element that you then went on to edit, unaware it was gone. A naive system faces an impossible dilemma: either it resurrects the element because you touched it, quietly undoing your colleague's deliberate removal, or it discards your edits because the element no longer exists, quietly throwing away your work. Both outcomes are wrong, and both happen silently, which is the worst part.

CelinQ handles this with tombstones — explicit records that an element was deleted, carried through the synchronisation rather than simply implied by absence. Because the deletion is a recorded fact rather than a gap, Fusion can see the collision for what it is: one person removed something, another changed it, and those two intentions are in tension. That is exactly the kind of situation it isolates for a human rather than resolving by accident. Nobody's decision is silently reversed. The tension is made visible and put in front of someone who can weigh it.

Underpinning all of this is a complete, ordered revision history. Every change that flows through the shared workspace is recorded in sequence, which means the state of the model is never a mystery and never merely the accumulated residue of whoever saved last. This matters enormously for the offline worker, because it is what makes the whole arrangement safe to trust. Your three hours of work on the plane are not a fragile diff that might or might not survive contact with the server. They are a sequence of recorded facts that can be replayed, inspected, and reasoned about. If something looks wrong after a merge, you are not left guessing. You can see what happened and when, and you can recover a prior state if you need to.

The measure of an offline modelling tool is not how well it lets you work when disconnected. It is how confidently you can reconnect without holding your breath.

Cadence that reads the room

Not every network deserves to be treated the same way, and a system that synchronised aggressively regardless of conditions would create its own problems. On a strong office connection, you want changes to propagate promptly so that presence feels live and colleagues see your work without noticeable lag. On a metered mobile connection in a moving train, hammering the network with constant traffic is wasteful and can make an already-marginal link worse. On a saturated conference wifi shared by three hundred people, restraint is simply good manners as well as good engineering.

Smart Sync is how CelinQ adapts to this. Rather than following a fixed schedule, the synchronisation cadence responds to the conditions it actually finds. When the connection is healthy and there is fresh work to share, it moves promptly. When the connection is poor or intermittent, it backs off, batches, and waits for a better moment, without ever putting the burden of that decision on you. The architect on the train does not think about any of this. They work, and the companion makes sensible choices on their behalf about when to spend the scarce resource of a flaky connection. This is the difference between a tool that merely tolerates poor conditions and one that behaves intelligently within them.

It is worth being clear about what this adaptivity is and is not. It is not a feature you configure obsessively or tune per journey. For the overwhelming majority of the time it is something you never see, which is exactly the point. The best infrastructure is the kind you stop thinking about, and the goal here is that the question of connectivity simply recedes from your daily awareness. You should be able to forget which of your working hours were online and which were offline, because the experience of modelling was the same throughout and the results reconciled cleanly regardless.

There is also a fairness to how the adaptive cadence treats the different people on a team, which is easy to miss until you think about it. In a team spread across offices, homes, and the road, connectivity is never uniform. One architect is on a fast wired connection, another is tethered to a phone in a rural station, a third is on hotel wifi that comes and goes. A system that expected all of them to keep a live conversation with a central database would punish the ones with the worst connections most, making them the slowest and the most likely to be blocked, purely as an accident of where they happened to be sitting. When the real work is local and synchronisation adapts to conditions, that unfairness disappears. Everyone models at full speed regardless of their connection, and the network merely determines how quickly each person's work reaches the others — a difference measured in the background, not in anyone's ability to get their job done.

The organisation keeps control

None of this requires handing your model to a service you do not control, and for the public-sector and enterprise contexts where this kind of tooling matters most, that is not a minor detail. The shared workspace runs on a server the organisation operates itself, backed by storage the organisation chooses — SQLite for lighter deployments, PostgreSQL where more is needed. The transport between each architect's companion and the shared workspace is encrypted, with certificate pinning so that the companion will only talk to the server it is genuinely supposed to talk to, and access is authenticated with tokens rather than left open. Roles govern who can do what, from those who only need to read the model through to those who administer the workspace. The offline worker on the train is not sending sensitive architecture out to some third party on the public internet; they are working locally and, when connected, exchanging changes with infrastructure that stays entirely within the organisation's own boundary.

This sovereignty is not a bolt-on reassurance for the security team. It is structural, and it is part of why the offline story holds together. Because the real work lives in the local repository and the shared workspace lives on the organisation's own server, there is no external dependency that has to be reachable for you to function. The core of the platform needs no outside service at all. The architect disconnected over the Atlantic is not cut off from something essential; they simply have everything they need with them, and the reconciliation waits patiently for a connection to infrastructure that the organisation itself stands behind.

What this changes about a working day

Step back from the mechanics and the real change is about how a professional relates to the scattered, imperfect hours that make up a working life. The train, the plane, the client site with the hostile network, the early morning before the office fills up — these are not obstacles to be endured until proper conditions return. They are simply time, and time is the thing an architect never has enough of. A tool that treats connectivity as a precondition for work quietly writes off all of that time. A tool that treats your own machine as the real workshop, and treats the network as a convenience that determines only when your colleagues catch up, gives it back to you.

It is tempting to oversell this, and it is worth resisting the temptation, because skeptical architects can smell overselling from a distance. Offline modelling does not make distributed collaboration effortless, and it does not abolish conflicts; genuine disagreements about the model still have to be settled by people who understand the domain. What it does is remove a specific, daily, corrosive friction — the friction of a tool that stops working when the network does — and it removes it without introducing the far worse friction of manual reconciliation. The honest claim is not that connectivity no longer matters at all. It is that connectivity should shape your day, not your ability to work, and that the line between those two things is exactly where a local-first design earns its keep.

The practical test is simple, and any architect can imagine running it. Picture the next long journey you have coming up. Picture opening the repository as the train pulls out, working steadily through a stretch of modelling you have been putting off, saving as you go without a single hesitation from the tool, and arriving to find your work already folded cleanly into the shared model with nothing lost and nothing to reconstruct by hand. That is not an aspiration for some future version of the way we work. It is simply what happens when the software stops assuming the network is always there, and starts assuming, correctly, that the person doing the work is.