Architecture comparison

CelinQ vs coArchi

Two real, purpose-built answers to the same question: how should a team collaborate on an Archi model? This is a comparison, not a takedown — coArchi is a genuine, actively maintained plugin, and the right choice for real situations described below.

coArchi gives a team version-controlled collaboration on a shared Archi model, backed by Git: commit, push, pull, and a merge step when two people have touched the model since the last shared commit. CelinQ takes a different path — the same local-first, semantic sync architecture that already serves Sparx Enterprise Architect, now extended to Archi. The full narrative account is here. This page is the short, structured version.

Dimension by dimension

Collaboration architecturecoArchi: Git-backed — commit, push, pull, merge, the same model a code team already uses. CelinQ: local-first — a background service exchanges changes continuously; no commit step.
Reconciliation levelcoArchi: file-level — Git's merge machinery reconciles the serialised .archimate XML. CelinQ: model-level — Fusion reconciles by what an element or relationship means, not by comparing file text.
Workflow requiredcoArchi: commit-and-pull discipline, a Git remote to maintain, conflict resolution inside Archi's own merge UI. CelinQ: none of the above — sync happens in the background without an explicit step.
Conflict handlingcoArchi: Git merge, with Archi's own UI for resolving what Git flags as conflicting. CelinQ: CelinQ Fusion's deterministic three-way merge at model-fact granularity, with tombstones for deletions.
Offline operationcoArchi: works offline between commits, same as any Git workflow. CelinQ: works offline as normal editing; changes synchronise when a connection returns.
Revision historycoArchi: full Git commit history. CelinQ: an ordered revision history per workspace, with a Control Plane view of open Fusion decisions.
Infrastructure requiredcoArchi: a Git remote (GitHub, GitLab, self-hosted, or similar) the team already has or can stand up cheaply. CelinQ: a CelinQ Server your organisation runs.
Tool interoperabilitycoArchi: Archi only. CelinQ: the same server and Fusion engine also serve Sparx Enterprise Architect — one shared workspace for both tools.
Governance & RBACcoArchi: whatever the Git hosting platform provides (branch protection, PR review, etc.). CelinQ: workspace roles (Viewer/Editor/Administrator/Owner) enforced server-side on every call, plus an audit log.
DocumentationcoArchi: none built in. CelinQ: a built-in generator produces a searchable static documentation portal from the workspace.
MaturitycoArchi: an established, widely used part of the Archi ecosystem. CelinQ's Archi client: real and independently verified against a live server, but newer than CelinQ's EA integration — Smart Sync's background cadence is not yet ported to Archi (sync is manual-trigger today).
Best fitcoArchi: teams already fluent in Git, comfortable with a commit-and-pull workflow, working in Archi only. CelinQ: teams who want collaboration to feel invisible, teams mixing Archi with Enterprise Architect, or teams who want the same governance and merge engine across both tools.

When coArchi may be the better choice. If your team already lives in Git for everything else, has Git-fluent architects, and is comfortable with a commit-and-pull rhythm, coArchi is a legitimate, low-friction, purpose-built answer — introducing a second server and a different sync model is a real cost that has to earn its place. coArchi is also the simpler choice for an Archi-only team with no Enterprise Architect side to reconcile with.

Go deeper

Full comparison

Archi Was Built for One Editor at a Time

What Archi's core actually is, what coArchi solves, and what's left.

Cross-tool proof

CelinQ for Archi: One Server, Two Modelling Tools

The real, verified cross-tool proof — and the honest limits of where it stands today.

For Archi teams

CelinQ for Archi

How CelinQ fits alongside your existing Archi models.