Archi has no server, no locking, and no built-in concept of a repository more than one live session is connected to at once — that is Archi's own core architecture, not a gap anyone forgot to fill. The Archi ecosystem's real answer is coArchi, a Git-backed collaboration plugin that gives teams already fluent in Git a genuine, low-friction path to sharing a model. The honest account of what coArchi solves, and what it doesn't, is here. CelinQ is a different answer to the same question — the one Sparx Enterprise Architect teams already use — now extended to Archi.
How CelinQ fits alongside Archi
CelinQ installs as an Eclipse plug-in — an OSGi bundle dropped into Archi's own
dropins directory — running the same sync engine, ported line for line,
that already serves Enterprise Architect. Each architect keeps editing their own
local .archimate model at full Archi speed. In the background, the plugin
exchanges changes with the same CelinQ Server an EA team might already be running,
and Fusion reconciles concurrent edits from Archi and EA users alike — at the level
of the model, not the file.
Nothing about Archi changes
The same install, the same .archimate file, the same diagrams.
No Git remote to maintain, no commit-and-pull discipline to build.
No merge step to interrupt you
Changes exchange with the shared workspace without an explicit commit — reconciliation happens underneath the editing session, not as a step between it and the next one.
Fusion, not a text diff
The same deterministic three-way merge that serves EA reconciles Archi changes by what an element or relationship means, not by comparing serialised XML line by line.
Honest about where Archi support stands today. The Archi client is real and independently verified against a live server — not a roadmap promise — but it is newer than the EA integration, which has months of production hardening behind it. Two gaps are open and worth knowing before you rely on them: an EA element created with a type Archi has no equivalent for does not yet map across automatically, and background auto-sync (Smart Sync) on the Archi side is not yet ported — syncing from Archi is manual-trigger today. The full account is here →
Archi specifications
| Model format | Existing .archimate models are used as-is. No migration or conversion step. |
|---|---|
| Integration | An Eclipse plug-in (OSGi bundle) installed into Archi's own dropins directory. |
| Sync | Manual-trigger sync today ("Sync Now"). Smart Sync's adaptive background cadence is ported for EA but not yet for Archi. |
| Merge engine | The same CelinQ Fusion engine that reconciles Enterprise Architect changes — deterministic three-way merge, tombstones, conflict isolation. |
| Cross-tool mapping | Elements, relationships, folders and diagrams map to CelinQ's canonical model. An EA element with no Archi-side type equivalent does not yet map across automatically — a named, open gap, not silently assumed away. |
| Authentication | The same CelinQ Server, the same token and Entra ID SSO authentication an EA-side workspace uses. |
Read next
CelinQ vs coArchi
An honest architecture comparison, including when coArchi is the better fit.
Archi Was Built for One Editor at a Time
What Archi's core actually is, what coArchi solves, and what's left.
CelinQ for Archi: One Server, Two Modelling Tools
The real, verified cross-tool proof — and the honest limits of where it stands today.
Modelling in Archi, EA, or both?
Tell us what your practice actually looks like — pure Archi, pure EA, or a mix across teams and clients — and we'll answer directly.