CelinQ Insights · No. 05

Modelling together when the team is spread across cities

Central repositories punish distance. Local-first collaboration removes the penalty.

Picture an architecture team that no longer sits in one building. One person works from a city an hour's train ride from the client's offices, another from home in a different region, a third from a partner organisation's site, and a fourth on the move between meetings for days at a stretch. This is not an unusual arrangement any more; for a great many practices it is simply the arrangement. And for the most part it works. The awkward exception, the thing that keeps producing small daily frustrations, is the shared model. Everything else about distributed work has adapted — the calls, the documents, the code — but the enterprise architecture repository often still assumes that the team is gathered around a fast local network, and it punishes them, quietly and constantly, for not being.

The punishment takes a specific technical form, and it is worth understanding precisely, because the instinct to blame the network or the people is usually wrong. The problem is architectural, in both senses of the word.

Why distance hurts a central repository

A shared repository — whether it is a project file on a network drive or a database repository hosted centrally — is designed around the assumption that the connection between the architect and the store is cheap and quick. When you open a diagram, expand a package, or edit an element, the tool is having a conversation with that central store. Over a local network in a single office, the conversation is so fast that nobody notices it is happening. Each request and response takes a fraction of a millisecond, and the thousands of small exchanges that make up a working session blur into what feels like instant, local editing.

Now stretch that connection across a couple of hundred kilometres, or route it through a home broadband link, or a hotel's contended wireless, or a mobile connection on a train. The individual delay on each exchange grows from imperceptible to merely small — but the tool is not making one exchange, it is making thousands, and every one of them now pays that latency tax. The session does not fail; it just becomes viscous. Opening a large diagram takes long enough that you switch to another window and lose your thread. A package expands with a visible pause. An edit that should feel instant instead has a half-beat of hesitation that, repeated a few hundred times a day, is genuinely exhausting. The architect ends up fighting the tool rather than thinking about the architecture.

The latency is only the first layer. The second is availability. A central repository is only as reachable as the link to it. The person on the train enters a tunnel and the model becomes unusable. The home connection drops for ten minutes during an area outage and a working session is interrupted. The partner site's firewall makes the connection unreliable in a way nobody can quite diagnose. Because the model lives elsewhere, the architect's ability to work is hostage to the quality of a network path they do not control and often cannot even see. This is a strange bargain: the model is arguably the team's most valuable shared asset, and yet each person's access to it is only as solid as the weakest segment of cable between their laptop and a server room.

The third layer is the coping behaviour that grows up around the first two, and it is the most corrosive because it undoes the whole point of having a shared model. When editing the central repository is slow and unreliable, people stop editing it directly. They take a local copy, work on it comfortably at full speed, and plan to reconcile later. This feels sensible in the moment and it is a completely rational response to a tool that punishes live editing over distance. But now the team has fragmented the model into private copies, and reconciliation has become a manual, error-prone chore that everyone dreads and therefore postpones. The distributed team has quietly reinvented the very problem — divergent copies that must be merged by hand — that a shared repository was supposed to solve.

The distance penalty is not really about speed. It is about the way a slow, fragile central store pushes a spread-out team back toward private copies and manual merges — the exact failure mode collaboration was meant to prevent.

The false choices teams settle for

Faced with this, distributed teams usually end up choosing among a set of unsatisfying options, each of which trades away something they should not have to give up.

The first is to route everyone through a remote desktop into a machine that sits close to the repository. This solves the latency of the model conversation by moving the whole editing environment next to the store, but it replaces one latency with another: now every keystroke and mouse movement travels the long path, and the interface itself feels laggy in a different way. It also concentrates everyone onto shared infrastructure that has to be sized, licensed, and maintained, and it makes offline work impossible by definition. You have not removed the dependence on the network; you have made the entire session depend on it rather than just the saves.

The second is to accept the private-copy fragmentation as a fact of life and build a ritual around it. Someone becomes the keeper of the master copy; others send their changes to be folded in; a careful, slow reconciliation happens on a schedule. This preserves fast local editing but reintroduces the manual merge in its most painful form, complete with the risk that two people's changes to the same area collide and someone's work is lost or clumsily patched over. The keeper of the master becomes a bottleneck and a single point of failure, and the model is only ever as current as the last reconciliation, which is to say usually somewhat out of date.

The third is to simply tolerate the slowness — to treat the daily friction as the cost of doing business and ask people to be patient. This is the most common choice because it requires no decision at all, only endurance. Its cost is invisible on any budget line and enormous in aggregate: the accumulated minutes of waiting, the lost trains of thought, the edits deferred because making them right now is too tedious, and the slow drift of talented people away from a tool that makes their day worse.

Local-first removes the penalty rather than managing it

The way out is to stop treating fast, reliable access as something that has to be delivered over the wire from a central store, and instead give each architect a full, first-class copy of the model on their own machine. This is what local-first means, and it inverts the assumption that was causing all the trouble.

In a local-first arrangement, each architect edits their own local repository. The conversation between the tool and the store is once again a local one, which means it is fast for everyone, everywhere, regardless of how far they sit from the client's office or how contended their home connection is. There is no latency tax on editing, because editing never crosses the network. The person on the train works at exactly the same speed as the person sitting next to the server, because for the purposes of editing there is no meaningful difference between them — the model each is touching is right there on the laptop.

Availability inverts in the same way. Because the model lives locally, the network dropping does not stop you working; it only defers the moment your work becomes visible to others. The tunnel, the outage, the flaky partner-site firewall — none of them can interrupt a working session, because the session does not depend on the link. Connectivity shapes when your changes reach the rest of the team, not whether you can make them. That single shift turns the network from a precondition for work into a background convenience, which is where it belongs.

The obvious question — and the one a skeptical architect should ask immediately — is what happens to sharing. A room full of private local copies is exactly the fragmentation problem described above. The answer is that the local copies are not private silos left to drift; they are kept in agreement by an engine designed precisely for this, running quietly so that no human has to perform the reconciliation by hand.

How CelinQ keeps distant copies in agreement

In CelinQ, a background companion service watches each architect's local repository and notices every save. When a change is saved, the service synchronises it with a shared workspace on a server the organisation runs on its own infrastructure. The architect does not initiate this, does not wait for it, and for the most part does not think about it; they save as they always would, and the sharing happens on its own. This is what makes local-first collaborative rather than merely local: the speed and resilience of editing on your own machine, combined with a shared workspace that stays current without anyone performing a manual merge.

The synchronisation adapts its rhythm to conditions rather than hammering a fixed schedule. When the network is present and lively, changes propagate briskly, so a distributed team can work in something close to a shared present even when they are hundreds of kilometres apart. When connectivity is poor or absent, the work simply accumulates locally and reconciles when the link returns, without drama and without the architect having to manage it. This adaptive rhythm is what lets the same tool feel right both for someone on a solid office connection and for someone drifting in and out of coverage on a long journey.

The engine that folds everyone's changes together is CelinQ Fusion, and its behaviour is what makes distributed collaboration trustworthy rather than nerve-wracking. Fusion performs a deterministic, reproducible three-way merge at the level of individual model facts. Two architects editing different parts of the model, or even different aspects of the same element, have their changes combined cleanly and predictably, without either having to know the other was working. Deletions are handled explicitly, using markers that record an absence as a deliberate act rather than letting a removed element quietly reappear or silently vanish during a merge. And crucially, when two people really do change the same thing in incompatible ways, Fusion does not pick a winner. It never resorts to last-write-wins, because last-write-wins is simply data loss dressed up as a resolution. Genuine conflicts are isolated and surfaced for a human to settle, so a distributed team never discovers weeks later that someone's careful work was silently overwritten by a colleague who happened to save a moment later from another city.

Working in the shared present without being tethered to it

There is a coordination benefit to this arrangement that is easy to overlook when you focus only on speed and availability. Distributed teams lose a lot of the ambient awareness that an office gives for free — you cannot see who is deep in the model right now, or overhear that a colleague is reworking the very package you were about to touch. CelinQ restores a lightweight version of that awareness with presence, so you can tell who else is currently in the workspace without anyone having to announce themselves in a chat thread. It is deliberately lightweight, because the goal is a glance rather than a surveillance dashboard, but even that glance changes the texture of remote collaboration. It turns "I had no idea you were working on that" into "I could see you were in there, so I picked up the next package instead."

Combined with the complete, ordered revision history that CelinQ maintains, the distributed team gains something the co-located team of the past never really had: not just the ability to work in parallel from anywhere, but a trustworthy account of how the shared model got to its current state, attributed to the people who shaped it. When a colleague three cities away made a change last week, you can see that it happened, who made it, and where it sits in the sequence. Distance no longer means opacity. The model remembers what everyone did, so being spread out stops meaning being in the dark about each other's work.

Sovereignty travels well

For public-sector and regulated work in particular, distributing the team must not mean distributing the data to places the organisation cannot account for. It is worth being clear that local-first collaboration does not imply handing the model to an outside service. The shared workspace runs on infrastructure the organisation controls, with storage in a straightforward database — SQLite or PostgreSQL — on its own soil. Transport between each architect and the workspace is encrypted, with certificate pinning so that the companion service will only talk to the genuine server, and access is governed by token authentication and roles that distinguish who may view, edit, administer, or own the workspace. A spread-out team therefore does not have to choose between working comfortably from anywhere and keeping the model under the organisation's own control. Both hold at once, which for many of the clients this matters most to is not a nice-to-have but a hard requirement.

The day-to-day texture of a spread-out practice

It is one thing to describe the mechanism and another to picture what it does to an ordinary working day, so it is worth walking through the texture of it. Consider a morning where four architects, in four different places, are all contributing to the same broad piece of work. One is refining a set of application components; another is documenting the interfaces between them; a third is reworking a data package that several of those components touch; the fourth is reviewing yesterday's changes over a slow connection from a client site. In a central-repository world, these four would be tripping over each other in small ways all morning — waiting on the same slow store, hesitating to edit near one another, and in the worst case discovering at lunchtime that two of them had been unknowingly reshaping the same corner.

In a local-first world the same morning is unremarkable, which is the point. Each of the four edits at native speed on their own machine, oblivious to the others' latency conditions. As they save, the companion service quietly carries their changes to the shared workspace and brings back everyone else's, folding the streams together at the level of individual facts. The person refining components and the person documenting interfaces are changing different facts, so their work simply combines. The person reworking the data package and the components author may touch shared ground, and where they do, the reconciliation happens automatically wherever it can and surfaces a conflict for a human only where two intentions genuinely clash. The reviewer on the slow connection is not slowed in their reviewing at all, because the model they are reading is local; only the arrival of the freshest changes waits on their link, and it waits gracefully. Nobody has coordinated the morning explicitly, and yet it coheres.

This is the quiet promise of removing the distance penalty: not a dramatic new capability announced with fanfare, but the disappearance of a hundred small frictions that a distributed team had come to regard as the unavoidable cost of not sharing a room. The frictions were never unavoidable. They were the signature of a storage model that assumed a room, imposed on a team that no longer had one.

There is a second-order effect worth naming, because it tends to surprise practices that make the shift. When distance stops carrying a penalty, the team's map of who can do what work quietly redraws itself. Under a central repository, proximity to the store becomes an unspoken factor in who gets assigned to what: the person with the solid office connection ends up doing the heavy, interactive work in the large diagrams, while the colleague on a flaky link is handed the tasks that tolerate slowness. This is never a policy anyone writes down; it is just how the work drifts, because the tool makes some assignments comfortable and others miserable. Remove the penalty and that distortion disappears. Work can be assigned on the basis of who is the right person for it, not who happens to sit closest to the server. For a consultancy that fields specialists from wherever they happen to be, or a public body drawing on architects across several sites, that is not a small thing — it means the shape of the team's output stops being quietly bent by the shape of its network.

The honest nuance

It would be a poor argument that pretended local-first collaboration makes distance disappear entirely, so let me be straight about where it does and does not help. It removes the editing penalty completely: everyone works at local speed, always, online or off. It removes the availability penalty for editing: your session no longer depends on the link. It removes the manual-merge chore and the silent-overwrite risk, which are the truly dangerous parts of the fragmentation problem. What it does not do is repeal the ordinary facts of working apart from other humans. When two people are genuinely reshaping the same corner of the model at the same time, someone still has to make a judgement about how their intentions combine — but now that judgement is surfaced cleanly as a conflict to resolve, rather than hidden until it does damage. The tooling does the mechanical reconciliation faithfully and asks a person only where a person is genuinely needed. That is the right division of labour, and it is a far better place to stand than either the viscous central repository or the ritual of private copies.

A grounded takeaway

A team spread across cities does not need to gather in one building to model well together, and it does not need to accept that the shared repository will always be the slowest, most fragile part of its day. The friction that distributed teams feel around a central model is not an inevitable cost of working apart; it is a consequence of a storage arrangement that assumed everyone would be close to the store. Change that assumption — put a full, fast copy of the model on each person's machine and let a background engine keep those copies in honest agreement — and the distance penalty simply lifts. The person on the train, the person at home, and the person at the client's office are all doing the same work at the same speed, contributing to the same shared workspace, and able to see how it is evolving. That is what CelinQ is built to deliver, working alongside Sparx Enterprise Architect rather than replacing it, so that where your architects happen to sit stops being a fact the model punishes them for.