CelinQ Insights · No. 32

Pro Cloud Server vs Local-First Enterprise Architect: Architecture and Performance Compared

Two honest answers to the same question — where should the authoritative copy of the model live — and what each answer costs.

Sparx Systems' own answer to the pain of a raw file-share repository is Pro Cloud Server, and it deserves to be taken seriously on its own terms rather than dismissed as a lesser alternative to whatever a challenger product happens to sell. Pro Cloud Server is a mature, capable piece of engineering that solves real problems for a great many teams, and understanding exactly what it solves — and exactly where its architecture still asks something of the network — is the right way to decide whether it, or a genuinely different architecture such as CelinQ's, fits your organisation. This article is a comparison, not a takedown. Both approaches are legitimate engineering responses to the same underlying question: where should the one true copy of the model live, and how should everyone else's view of it stay current?

The central repository answer

Pro Cloud Server's architecture keeps a single authoritative repository running centrally, typically backed by a proper DBMS such as SQL Server, Oracle, or PostgreSQL, and exposes it to EA clients over HTTP or HTTPS rather than a raw database connection. This is a genuine improvement over pointing EA directly at a database across a WAN: HTTP-based access can be more firewall-friendly, easier to secure at the edge, and easier to scale with standard web infrastructure than raw DBMS connectivity ever was. Every architect's copy of Enterprise Architect talks to the same central service, and that service is the one and only place the model actually exists. There is no ambiguity about which copy is correct, because there is only one copy. Concurrency is managed the traditional way, through locking at the package or element level, which is the same mechanism the earliest shared-file deployments used, just delivered through a more robust and more securable transport.

The strength of this design is real and worth stating plainly: because there is exactly one authoritative store, the question "what does the model actually say right now" always has exactly one answer, and everyone who queries it gets that answer immediately, with no reconciliation step and no possibility of two people's views diverging even briefly. For teams whose primary requirement is a single, unambiguous source of truth queried in real time — dashboards, reporting integrations, tools that read the live model rather than a periodic export — a central repository is the simplest architecture that satisfies the requirement, and it is worth not overcomplicating a problem that does not need a distributed answer.

The local-first replicated answer

CelinQ starts from a different premise. Instead of one central store that every client queries live, each architect keeps a genuinely local EA repository — a real file on their own machine — and a background agent, CelinQ Connect, replicates changes to and from a shared CelinQ Server asynchronously, over an encrypted gRPC connection. There is still exactly one canonical workspace, held on the server your organisation runs; the difference is that no architect's interactive session talks to it directly. Every read and every write during normal modelling happens against the local copy, at local speed, and the server's canonical state converges toward what every client has done, and every client converges toward what the server holds, through a continuous background synchronisation rather than a live query on every click.

This is a genuinely different trade than Pro Cloud Server makes, not merely a different implementation of the same trade. Pro Cloud Server optimises the path between client and server so that talking to the central copy is as cheap as reasonably possible. CelinQ removes that path from the interactive loop altogether, at the cost of accepting that, for a brief window, different architects' local copies can be honestly, temporarily out of step with one another and with the canonical server — a gap that the synchronisation and Fusion merge engine exist specifically to close correctly, never by silently discarding anyone's work.

Where authoritative state actually lives

This is the cleanest way to separate the two architectures conceptually. In Pro Cloud Server, authoritative state lives in one place, full stop, and every client is a thin window onto it. In CelinQ, authoritative state — the canonical, agreed history of the model — lives on the CelinQ Server your organisation controls, but each architect also holds a complete, fully functional local copy that is not merely a cache; it is a real repository capable of standing entirely on its own. The distinction matters because it determines what happens when the network is not available, which is the next question worth asking of any architecture.

Network dependency during normal modelling

The performance implications of this difference are covered in detail elsewhere in this series, but the short version bears repeating here because it is the crux of the comparison. Pro Cloud Server's HTTP transport is a real improvement over raw remote database access, and for teams on good connections within a reasonable geographic radius it performs well. But the architecture still places a network request between the architect and every meaningful repository operation, because the repository the client is querying is, definitionally, not on the architect's machine. Latency, when it exists on the path, is still paid on every click, every diagram open, every save — the HTTP transport changes the shape and efficiency of that conversation, not the fact that a conversation with a remote party has to happen at all. CelinQ's local repository removes the network from that specific loop entirely; every read and write during modelling is local disk access, with no round trip of any kind, regardless of what the network is doing at that moment.

Offline behaviour: the sharpest dividing line

This is where the two architectures diverge most visibly. A central repository, however well delivered over HTTP, requires connectivity to function, because the repository the client needs simply is not present on the client's machine. Lose the connection and the modelling session stops, or falls back to a degraded, disconnected mode with real limitations, because there is nothing local to fall back onto that constitutes the actual repository. CelinQ's local repository does not know or care whether the network is present, because it was never depending on the network for reads and writes in the first place. Working offline is simply working — the same repository, the same EA session, the same speed — with the difference invisible to the architect until the background agent has something to synchronise once a connection returns.

Synchronisation complexity: the cost that has to be paid somewhere

It would be a poor comparison if it implied that CelinQ's approach is free and Pro Cloud Server's is merely old-fashioned. Every architecture pays for consistency somewhere, and it is worth being honest about where each one pays. Pro Cloud Server pays for consistency by keeping the client thin and pushing every operation through the central service in real time; the cost shows up as network dependency and, on longer or less reliable links, as latency on the interactive path. CelinQ pays for consistency by accepting that copies can briefly diverge, and it spends real engineering effort — a durable offline queue with replay and duplicate-delivery tolerance, a deterministic three-way merge engine, tombstones so deletions are never silently reversed — on reconciling those copies correctly once they reconnect. Neither cost is smaller than the other; they are simply paid at different moments and in different currencies. A central repository pays continuously, in latency, on every interactive click. A local-first architecture pays occasionally, in engineering complexity, at the moment of reconciliation.

Consistency trade-offs, stated plainly

Because a central repository has exactly one copy, it offers strong, immediate consistency by construction: the moment you read something, you are reading the current state, because there is no other state to be behind. CelinQ offers a different, weaker-sounding but carefully engineered guarantee: eventual consistency, where each local copy converges to the canonical state within the rhythm of the synchronisation cadence — typically within seconds under normal conditions, and always upon reconnection after an offline period — combined with a deterministic merge that never silently loses or resurrects work along the way. For a use case that genuinely requires up-to-the-second consistency across every viewer at all times, such as a live dashboard aggregating data from the model, a central repository's guarantee is the right one and CelinQ's canonical server, queried directly through its REST API rather than through an architect's local copy, serves that same role. For the day-to-day work of modelling itself, where the humans doing the work are not reading each other's keystrokes in real time anyway, eventual consistency measured in seconds is not a meaningfully weaker guarantee in practice — it is simply a different one, chosen deliberately for the part of the system where local responsiveness matters more than instantaneous cross-client visibility.

Conflict prevention versus conflict reconciliation

The two architectures also take opposite philosophical positions on how to keep the model from becoming inconsistent when two people touch the same thing. Pro Cloud Server, following the tradition of the shared repository it descends from, leans on locking: you check something out, you hold it, nobody else can change it until you release it. This prevents conflicts from ever occurring, at the cost of the queuing and contention problem covered in the first article of this series — a cost that scales badly as a team grows, because every additional person is a new potential source of contention against everyone already working. CelinQ takes the opposite position: it does not try to prevent concurrent edits at all. Anyone can edit anything at any time, and the system's job is to reconcile the results correctly afterwards, resolving what can be resolved automatically and surfacing only genuine, irreducible disagreements to a human. This reconciliation-based approach is described in full elsewhere in this series, but the philosophical choice is the thing to notice here: prevention trades throughput for certainty in advance; reconciliation trades a small amount of after-the-fact review for the removal of the queue entirely.

Pro Cloud Server asks: how do we make the central copy as fast and as available as possible? CelinQ asks a different question: does the interactive path need to touch the central copy at all? Both are legitimate engineering answers. They are not the same question.

Operational visibility

Both architectures give administrators a way to see what is happening, though the shape of that visibility differs. Pro Cloud Server's central position gives it a natural vantage point over every client connection and every repository operation as it happens, because everything passes through the one service. CelinQ's Control Plane — a web console covering workspaces, connected clients, synchronisation counters, open Fusion decisions, revision history, subsystem monitoring, audit logging, and backups — gives an equivalent, arguably more structured vantage point, but over the synchronisation and reconciliation layer specifically rather than over live query traffic, because that is the layer where CelinQ's architecture actually does its coordinating work. An administrator watching CelinQ's dashboard sees workspace and client counts, sync throughput, and how many Fusion decisions are open and awaiting a human, which is a genuinely different but equally actionable picture of system health than watching live database connections.

Suitable use cases for each approach

Pro Cloud Server is a strong choice when a team works predominantly from well-connected locations, when the organisation wants the simplicity of a single deployed service and is comfortable with clients depending on it, when live cross-tool integration against the model is a first-class requirement, and when the team's culture and workflow already fit comfortably around package-level checkout. It is mature, well documented, and widely deployed, and none of that should be understated. CelinQ tends to fit better where the team is geographically distributed across offices with meaningfully different network quality, where architects genuinely need to work offline for real stretches of time — client sites, travel, unreliable connections — where the team is large enough that lock contention has become a measurable daily cost, or where the organisation wants an independent, additional layer of semantic revision history and deterministic merge on top of whatever repository technology it already uses.

A worked scenario: three offices, one model

Abstract architecture comparisons are easy to nod along to and hard to actually feel, so it helps to walk through a concrete situation. Picture an organisation with three offices — a headquarters, a regional branch four hundred kilometres away, and a small satellite team that works mostly from client sites and home — all contributing to the same enterprise architecture repository. Under Pro Cloud Server, all three offices point their EA clients at the same central service. The headquarters, sitting on the same network as the server, has a fast, comfortable experience: round trips are short, locking contention is the main friction they notice, and it shows up as the familiar wait for a colleague to release a package. The regional branch, connected over a corporate VPN with a round-trip time in the tens of milliseconds, notices every operation costs a little more than it does at headquarters, and a full day of modelling accumulates that cost into a session that simply feels heavier, even though nothing is actually broken. The satellite team is the hardest case: from a client site with a locked-down guest network, or from a train, Pro Cloud Server's requirement for connectivity to the central service means their options are limited to finding a usable connection or not working in the model at all.

Now replay the same scenario under CelinQ. All three offices, and the satellite team, work against fully local repositories at identical speed, because none of their interactive sessions touch the network at all. The headquarters notices no difference in raw responsiveness, because they were already close to the server; what they gain instead is the removal of lock contention, since colleagues editing different parts of the model no longer queue behind one another. The regional branch, previously paying a real if moderate latency tax on every click, now feels identical to headquarters, because their local repository does not know or care that the canonical server is four hundred kilometres away — the distance only affects how quickly their background synchronisation exchanges changes, which happens invisibly. The satellite team is where the difference is starkest: they work exactly as they would at a desk, on a train, in a client's meeting room with no network access at all, and their work synchronises whenever a connection next becomes available, with nothing lost and nothing requiring a special offline mode to be switched on or remembered.

Neither replay is hypothetical exaggeration; it is simply what each architecture's stated design implies once you apply it to a team that is not uniformly co-located, which describes the overwhelming majority of real enterprise architecture practices. The scenario also clarifies where Pro Cloud Server's design is genuinely sufficient: an organisation where every architect sits within a short, reliable hop of the data centre gains comparatively little from local-first replication, because the problem it solves — the cost and unreliability of that hop — barely exists for them in the first place.

The total-cost question administrators actually ask

Procurement and platform teams rarely frame this choice in terms of latency or consistency models; they frame it in terms of what they will be responsible for operating and explaining a year from now. Pro Cloud Server's operational story is comparatively familiar: a central service, backed by a mainstream DBMS, following patterns that most infrastructure teams already know how to secure, back up, and scale, with well-established guidance from Sparx Systems on deployment. CelinQ's operational story asks an infrastructure team to run one additional service — the CelinQ Server, with its choice of SQLite for lighter deployments or PostgreSQL where more headroom is needed — and to trust a merge engine to reconcile concurrent edits correctly rather than trusting a lock to prevent them from occurring. That is a real ask, and it should be evaluated with the same scrutiny an organisation would apply to any new piece of infrastructure: what does it cost to run, what does it cost to back up and restore, and what does its failure mode look like at three in the morning. CelinQ's answer — durable local repositories that keep working even if the server is briefly unreachable, an online backup path, and a revision history that lets an administrator see exactly what changed and when — is designed to make that evaluation favourable, but it is an evaluation every adopting organisation should genuinely run rather than accept on description.

Why CelinQ is not simply a Pro Cloud Server clone

It would be easy, and wrong, to describe CelinQ as "Pro Cloud Server, but local." The difference is not a feature checklist; it is the fundamental question the architecture was built to answer. Pro Cloud Server was built to make the central-repository model faster, more securable, and easier to deploy over HTTP than raw database access ever was — and at that goal, it succeeds. CelinQ was built to ask whether the central-repository model was the right starting assumption for interactive, offline-tolerant, geographically distributed modelling at all, and it answers that question by replicating full local repositories and reconciling them with a purpose-built deterministic merge engine rather than by making remote access faster. The two products are not competing to win the same race. They are running different races, and the right choice depends entirely on which race your team is actually in.

The honest limits

CelinQ's architecture is not simply better in every dimension, and it would undermine the whole comparison to pretend otherwise. The eventual-consistency model means there genuinely is a window, however brief under normal conditions, where two architects' local views can differ, and any integration that needs a live, always-current view of the model should query the canonical server directly through its API rather than assume any single architect's local repository is perfectly current at every instant. The reconciliation engine, however carefully engineered and however extensively tested, is inherently more complex than "there is only one copy, so there is nothing to reconcile," and that complexity is exactly where bugs would be most costly if they existed — which is precisely why Fusion's guarantees around silent loss and resurrection are the parts of the system that deserve, and receive, the heaviest testing. And organisations already deeply invested in Pro Cloud Server, with integrations built against its live query surface, would be taking on real migration cost to move to a different architectural model, cost that has to be weighed honestly against the problems local-first actually solves for their specific situation rather than assumed away.

The right way to choose between them is not to ask which architecture sounds more modern. It is to ask, concretely, how your team actually works: how distributed they are, how reliable their connectivity actually is on a bad day rather than a good one, how large the team is and how much lock contention already costs them, and whether anything in your toolchain genuinely needs a live query against the one true copy at every instant. Answer those questions honestly and the choice between conflict prevention and conflict reconciliation, between one authoritative copy and many reconciled ones, tends to answer itself.