CelinQ Insights · No. 35

Enterprise Architect Cloud Collaboration Without Sacrificing Local Performance

A cloud control plane and a cloud editing loop are not the same thing, and confusing them is how organisations trade away local speed for central visibility they never had to give up.

"Move the model to the cloud" is one of those instructions that sounds simple in a planning meeting and turns out to hide a genuine architectural decision the moment someone tries to implement it. There are at least two very different things it could mean. It could mean putting the repository itself in the cloud, so that every architect's EA session talks directly, over the internet, to a remote database every time they click something — which reintroduces exactly the latency problem this series has covered from several angles, now with the added variable of internet routing rather than a controlled corporate network. Or it could mean putting the coordination layer in the cloud — the shared workspace, the revision history, the audit trail, the administrative console — while leaving the actual modelling loop local, on each architect's own machine, at full desktop speed. These are not two flavours of the same thing. They are different architectures with different consequences, and this article is about the second one, and about why the distinction is worth insisting on before signing off on a cloud migration.

Cloud control plane versus cloud editing loop

The phrase "cloud collaboration" tends to get used as though it describes one architecture, but it is worth separating the two things that could actually be in the cloud. The editing loop is the tight cycle of clicking, reading, typing, and saving that makes up the moment-to-moment experience of modelling — the part covered in detail elsewhere in this series, and the part that is catastrophically sensitive to added latency because it happens continuously, many times a minute, all day. The control plane is a different thing entirely: it is where the organisation's shared, canonical view of the model lives, where revision history accumulates, where administrators manage users and workspaces, where synchronisation and conflict resolution are monitored, and where the audit trail a regulated organisation needs actually gets written. The control plane does not need to be touched on every click. It needs to be touched when a change is ready to be shared, when an administrator is checking on the health of the system, or when someone needs to see who changed what and when. That is a fundamentally less frequent, less latency-sensitive kind of interaction, and it is exactly the kind of interaction that tolerates being in the cloud comfortably.

CelinQ's architecture keeps these two things deliberately separate. The editing loop stays local, against a real EA repository on the architect's own machine, for all the performance and offline reasons covered earlier in this series. The control plane — the CelinQ Server, whether run on-premises or in a cloud environment the organisation controls — holds the canonical workspace, the revision history, and the administrative surface, and is reached over HTTPS on a cadence measured in seconds and minutes rather than on every keystroke. Calling this whole arrangement "cloud collaboration" is accurate, but it is a very different claim than "the repository is in the cloud," and the difference is precisely where the local performance gets preserved or lost.

The local EA repository, unaffected by where the server lives

It is worth stating plainly what does not change when the CelinQ Server moves from an on-premises machine to a cloud host: nothing about the architect's day-to-day experience. Every read and write during modelling still happens against the local repository, at local speed, exactly as described throughout this series. The server's physical location — down the hall, in a regional data centre, or in a public cloud region on another continent — affects only the round-trip time of the background synchronisation traffic, which is tolerant of latency in a way the interactive path never has to be, because nobody is sitting and watching a spinner waiting for that traffic to complete before they can continue working. This is the property that makes a genuinely cloud-hosted CelinQ Server a reasonable choice for a geographically distributed organisation in a way that a genuinely cloud-hosted raw repository connection never quite is: the thing that is sensitive to distance is not the thing you put far away.

The cloud CelinQ Server itself

The CelinQ Server is an ASP.NET Core application exposing gRPC for synchronisation and a REST API for everything else, backed by SQLite for lighter deployments or PostgreSQL where an organisation needs more headroom — the same server, the same code, whether it runs in a server room or a cloud virtual machine. This matters for the honesty of the "cloud collaboration" claim: CelinQ is not asking an organisation to trust a multi-tenant SaaS platform with its architecture model. It is a server the organisation deploys and operates itself, wherever it chooses to run it, with the workspace, the revision log, and the administrative controls entirely under that organisation's own governance. An organisation that wants the operational convenience of not running its own hardware can host the CelinQ Server in a cloud environment of its choosing; an organisation that wants everything to stay strictly on-premises can run the identical server that way instead. The architecture does not force the choice; it simply makes either choice work the same way from the architect's chair.

HTTPS synchronisation and what it actually carries

The traffic between each architect's local CelinQ Connect agent and the server travels over an encrypted gRPC connection with TLS, including certificate pinning so that an agent will only ever talk to the server it is genuinely configured for rather than to an impostor on the network. What travels across that connection is not a live stream of every keystroke; it is periodic, debounced changesets — coherent bundles of the semantic changes an architect has made, sent a few seconds after they stop actively editing, with a safety synchronisation roughly every minute and a deeper reconciliation roughly every five minutes to catch anything the faster paths missed. This is a genuinely modest amount of traffic relative to a live remote-repository connection, which has to carry every single read as well as every write, and it is one of the reasons the architecture tolerates the added latency of a genuinely distant cloud region far better than a live repository connection ever could: the traffic pattern was already designed to be infrequent and batched, rather than continuous and synchronous.

The canonical workspace as the organisation's shared truth

Every workspace on the CelinQ Server holds the canonical, agreed state of the model — not any one architect's local view, but the reconciled result of everyone's contributions, merged through Fusion and recorded as an ordered sequence of revisions. This is the thing that makes distributed collaboration coherent rather than merely parallel: without a canonical workspace, you would have several people's local repositories quietly diverging from each other with no shared reference point to reconcile against. With it, every local repository has a single, unambiguous target to converge toward, and the server's REST API gives any tool that genuinely needs a live, authoritative view of the model — a dashboard, a reporting integration, an external governance tool — a place to query that view directly, without going through any individual architect's local copy at all.

Revisions and audit as cloud-native strengths

This is one area where putting the control plane in the cloud is not merely tolerable but genuinely advantageous. A revision history and an audit log are, by nature, append-only records that benefit from centralised, durable, backed-up storage reachable by everyone who needs to consult them, which is precisely what cloud infrastructure is good at providing. The Control Plane's Revisions view gives a human-readable history per workspace — who changed what, how many entities were touched, and when — and the Audit view gives administrators the security and access log a regulated organisation needs to demonstrate governance over its architecture repository. Neither of these needs to be fast in the interactive-modelling sense; they need to be complete, tamper-evident, and reliably available, and a well-run cloud deployment is a reasonable place to meet those requirements.

Multi-office collaboration without a single point of contention

As the comparison with Pro Cloud Server in this series explored in more depth, a genuinely distributed organisation — headquarters, regional offices, home-based staff — gains the most from an architecture where local speed does not depend on proximity to the server. A cloud-hosted CelinQ Server, reachable from anywhere over HTTPS, gives every office an equally short logical distance to the coordination layer regardless of physical geography, while every office's actual modelling work stays local and therefore equally fast regardless of that same geography. Nobody's office is structurally privileged by being closer to wherever the server physically sits, because the server's physical location no longer determines how fast anyone can click.

Offline continuity even with a cloud server

A cloud-hosted server is, if anything, slightly more likely to be occasionally unreachable from any given architect's specific location than an on-premises server on the same corporate network would be, simply because it depends on the public internet path rather than a controlled internal one. This makes the offline story covered in depth elsewhere in this series not a nice-to-have for cloud deployments but a genuine requirement: the durable local queue, the tombstone-aware conflict detection, and the deterministic Fusion merge all apply identically whether the unreachable server is down the hall or across an ocean. An architect's local repository does not know or care why the server is unreachable, only that it currently is, and the local editing experience is unaffected either way.

Cloud deployment patterns worth naming honestly

A few deployment patterns are worth distinguishing rather than lumping together as "cloud." A single organisation running its own CelinQ Server on a cloud virtual machine it controls, with its own SQLite or PostgreSQL storage, is the most straightforward pattern and the one described throughout this article — full control, full data residency choice, the operational model of "we run our own server, it happens to be a cloud VM rather than a physical box." Container-based deployment, with a Docker image the organisation runs on its own cloud infrastructure or Kubernetes cluster, is a documented direction for organisations that already standardise on that operational model, though it should be evaluated on its own merits per environment rather than assumed identical everywhere. What CelinQ does not offer today, and what this series is careful never to claim, is a multi-tenant hosted SaaS version operated by a third party on the organisation's behalf; every deployment pattern that exists keeps the server under the adopting organisation's own operational control, which is a deliberate choice for a product whose customers include public-sector clients with real sovereignty requirements.

A worked scenario: three continents, one canonical workspace

Concrete scenarios make the distinction between the editing loop and the control plane easier to hold onto than architecture diagrams do on their own. Picture an organisation with architects in Brussels, an office in Singapore, and a small remote contingent working from North America, all contributing to one enterprise architecture programme. If the naive version of "move it to the cloud" had been implemented — a shared repository hosted in a single cloud region, queried live by every architect's EA session — the Brussels team, if the region happened to sit in Europe, would have a tolerable experience, while Singapore and North America would each pay a substantial, unavoidable round-trip penalty on every click, dictated by the speed of light over a very long physical distance, with no engineering fix available short of running separate regional repositories that then have their own reconciliation problem to solve.

Under CelinQ's actual architecture, all three locations run identical local repositories and experience identical local responsiveness, because none of their editing sessions query the cloud server directly. The CelinQ Server, wherever the organisation chooses to host it, only ever exchanges debounced, batched synchronisation traffic with each office's background agent — traffic that tolerates the two-hundred-millisecond-plus round trip between, say, Brussels and Singapore without any of it being visible to the architects actually doing the modelling. The Singapore office is not "the far one" in any way that matters to their daily experience; they simply work, exactly as Brussels does, and the server's job is to fold everyone's contributions into one canonical workspace on a cadence measured in seconds and minutes, a job that genuinely does not care how far apart its contributors are.

Watching the synchronisation layer, not the editing sessions

Because the architects' editing sessions never touch the cloud server directly, an administrator cannot — and does not need to — watch individual clicks the way they might watch queries against a live central database. What they watch instead is the synchronisation layer itself: push and pull counts, how many changes are flowing through the system, how many conflicts are open and awaiting a human, and how many live subscriptions are currently connected. This is a coarser but arguably more useful signal for the questions an administrator actually has, which are rarely "what did one specific architect just click" and almost always "is the system as a whole healthy, and is anything stuck." The Control Plane's Synchronization view exposes exactly this: raw counters for pushes, pulls, changes, and conflicts, alongside the live subscription count, giving a genuine operational picture of a cloud-hosted coordination layer without requiring, or even wanting, visibility into the moment-to-moment editing happening on each architect's own machine.

Local responsiveness as the thing that must never be traded away

It is worth returning, at the end of a discussion about cloud infrastructure, to the point that motivates the whole architecture: none of the coordination benefits above are worth anything if achieving them costs an architect the responsiveness of their actual modelling session. The distinction between optimising a network path and removing that path from the interactive loop entirely is the organising idea of this entire series, and cloud deployment is simply the case where the temptation to blur that distinction is strongest, because "everything is in the cloud now" is such an easy sentence to say and such an easy assumption to let slide into "so the repository must be too." CelinQ's answer is to hold the line deliberately: the editing loop is local, full stop, regardless of where the server lives, and the cloud only ever hosts the parts of the system that were never on the interactive path to begin with.

Ask not whether the server is in the cloud, but whether your next click is. Everything else is an infrastructure decision; that one is an architecture decision.

Choosing a region without pretending it is a purely technical decision

When an organisation does decide to host its CelinQ Server in the cloud, the choice of region is often treated as a performance question — pick the region closest to the most people — but the more important considerations are usually regulatory and organisational rather than technical, precisely because the editing loop's performance no longer depends on that choice the way a live-repository architecture's would. A public-sector client with data residency obligations needs a region, or an on-premises deployment, that satisfies those obligations first, and only secondarily needs to think about round-trip time to the synchronisation layer, because that round-trip time affects background sync cadence rather than anyone's ability to work. This reordering of priorities — sovereignty and governance first, network topology a distant second — is only available to an organisation once the architecture has actually decoupled local performance from server location, and it is worth naming as a benefit in its own right: the cloud deployment decision gets to be made on the grounds that actually matter for a public-sector or regulated client, rather than being forced by a performance constraint that would otherwise dominate the conversation.

The honest limits

Cloud deployment of the CelinQ Server introduces real considerations that an on-premises deployment on a trusted internal network does not. Public internet exposure of any server, however well secured with TLS and certificate pinning and token authentication with workspace roles, is a larger attack surface than a server reachable only from inside a corporate network, and organisations with strict data residency or sovereignty requirements need to think carefully about which cloud region, if any, is acceptable for their specific regulatory context — a decision CelinQ deliberately leaves to the adopting organisation rather than making for them, because it is not CelinQ's decision to make. A cloud-hosted server also introduces an ongoing operational dependency on whichever cloud provider hosts it: outages, however rare, at the provider level become outages of the coordination layer, even though — and this is the point worth repeating one final time — they never become outages of any individual architect's ability to keep working locally.

It is also worth being honest that "cloud" is sometimes chosen for reasons that have little to do with the architecture described in this article, and those reasons deserve their own scrutiny rather than being folded into a performance argument. An organisation might move to a cloud-hosted server purely to avoid managing physical hardware, or because procurement policy favours operating expenditure over capital expenditure, or because an existing cloud commitment makes one more virtual machine administratively cheap to add. Those are entirely legitimate reasons, but none of them are performance reasons, and conflating them with a performance justification risks the same category error this article opened with — treating "cloud" as a single decision when it is really several separate decisions bundled under one word. The clean way to reason about it is to keep asking the same question at every step: does this specific choice touch the editing loop, or only the control plane? If the answer is the control plane, the choice is comparatively low-stakes and can be made on operational or regulatory grounds. If the answer would touch the editing loop, it deserves the same scrutiny this whole series has applied to every other proposal to put a network round trip between an architect and their next click.

Nor does moving the control plane to the cloud remove the genuine engineering cost of the reconciliation layer underneath it; Fusion's merge guarantees, the offline queue's durability, and the audit trail's completeness all have to be earned regardless of where the server physically sits, and a cloud deployment does not make any of that easier or harder in principle. What cloud deployment changes is purely operational — who manages the hardware, how the organisation scales storage and compute, how disaster recovery for the server itself is handled — and none of it touches the one guarantee that actually matters to the architect at their desk: that the model in front of them responds at the speed of their own machine, cloud or no cloud, connected or not.