Sparx Enterprise Architect is one of the most capable modelling tools in the world, and almost every organisation that uses it seriously runs into the same wall: the repository was built for one pair of hands at a time. CelinQ removes that wall without asking anyone to leave the tool they already know.
The problem CelinQ was built to solve
An Enterprise Architect project file — a .eap or .eapx
sitting on a network share, or even a shared database repository — assumes a world in
which one person edits at a time. The moment a second architect opens the same model,
the trouble starts. One holds the file open and the other waits. Someone copies the
model to their laptop to work on the train, and now there are two truths that have to
be reconciled by hand. A DBMS repository solves the file-lock problem but introduces a
database server to license, secure, back up and keep available — and it still gives you
no meaningful history of who changed what and why.
The result is a practice that scales badly. A single architect can be productive; a team of four spends a surprising fraction of its week coordinating access, merging changes by eye, re-doing lost work and being nervous about overwriting each other. For a consultancy or a public-sector architecture office, that friction is the difference between an architecture repository that is trusted and one that quietly rots.
How CelinQ works
CelinQ sits alongside Enterprise Architect rather than replacing any part of it. Each architect keeps working in their own local copy of the model — fast, responsive, and usable with or without a network connection. A small companion service watches that local repository and keeps it in step with a shared workspace on a central CelinQ server that your organisation runs. When you save in Enterprise Architect, your changes travel to the server; when a colleague's changes arrive, they appear in your model. No file locks, no waiting your turn, no manual export and import.
Keep working in EA
Everyone edits their own local repository at full speed. Offline on a plane or behind a slow client VPN, the tool stays responsive because nothing depends on a live connection to a shared file.
Changes flow both ways
A background companion detects each save and exchanges just the changes with the shared workspace. Smart Sync adapts its rhythm — quick during hot collaboration, calm when you are heads-down.
CelinQ Fusion reconciles
When two people touch the model at once, a deterministic three-way merge combines their work at a fine grain. Genuine conflicts are isolated and surfaced, never silently resolved by whoever saved last.
CelinQ Fusion: merging you can trust
The heart of CelinQ is its merge engine, Fusion. Most tools that claim to support collaboration fall back on "last write wins" — whoever saves most recently overwrites everyone else. That is not merging; it is data loss with good manners. Fusion instead performs a proper three-way reconciliation: it knows the common ancestor of two versions and can therefore tell the difference between a change one person made and a change the other made, combining both when they do not overlap.
It works at the level of individual model facts rather than whole diagrams or packages, so two architects editing different attributes of the same element, or different elements in the same package, simply both succeed. When two people genuinely change the same thing in incompatible ways, Fusion does not guess. It preserves both versions, marks the point of contention, and lets a human decide — with full context about what each side intended. Deletions are handled with tombstones rather than silent disappearance, so a colleague's in-progress work is never destroyed by someone else's cleanup. The whole process is deterministic: the same inputs always produce the same result, which is what makes it safe to trust and possible to audit.
No intelligence required in the core. Fusion is a rules-based, reproducible engine. It does not depend on any external service or network intelligence to merge your model — which is exactly why it is safe to rely on for work you cannot afford to lose.
One server, two modelling tools
Everything above — the local repository, Smart Sync, Fusion's deterministic merge, the full revision history — was built around a canonical model that was never tied to any one modelling tool's internal schema. Sparx Enterprise Architect was the first client. Archi, the free ArchiMate modelling tool, is the second, and it talks to the exact same CelinQ Server, over the exact same protocol, reconciled by the exact same Fusion engine. Nothing about the server, the sync protocol or the merge logic changed to add it. An architecture practice that mixes EA licence holders with Archi users — a common reality in public-sector teams and consultancies working across client environments — can now put both in one shared workspace rather than running two disconnected repositories that never see each other's changes.
Archi has never shipped a multi-user repository of its own: no locking, no merge, no
change history, nothing beyond a single .archimate file that one person
edits at a time. Teams sharing an Archi model today fall back to a network drive or
version control on the raw XML, neither of which can tell a rename from a deletion
or reconcile two people's concurrent edits. What that gap actually costs a team is covered in full elsewhere in this series →
CelinQ closes it the same way it closes the equivalent gap for EA: a local Archi model stays fully local and fully fast, a companion plug-in synchronises it with the shared workspace in the background, and Fusion reconciles concurrent edits from Archi and EA users alike. This was proven this year with a real, verified test — not a simulation — spanning both tools: a Sparx EA repository published to a live CelinQ Server, a real Archi model pulled that content down and pushed its own new element back, and a second, independent EA repository then cloned the workspace and found the Archi-authored element waiting for it, created through EA's own Automation API. The full account, honest limitations included, is here →
Honest about where Archi support stands today. The Archi client is real and independently verified against a live server this year, 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 about before you rely on them: an EA element created with a type Archi has no equivalent for (typically because the ArchiMate MDG technology isn't active in that EA installation) 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. Both are named, scoped, open work, not silently assumed away.
Because the underlying model is the same regardless of which tool wrote to it, a synchronised workspace also becomes something neither tool offers alone: a single, always-current source that documentation and AI assistants can query without caring whether a given element started life in EA or Archi. Generating documentation that doesn't go stale the day it's produced and turning the model into a searchable knowledge base both work the same way across a mixed EA-and-Archi estate as they do for a single tool, because CelinQ never asked either tool's internal format to be the interface — the canonical model was always the interface, and that is what a documentation tool, a search index, or a governed AI assistant actually reads.
What you get
Every change, recorded
A complete, ordered history of the workspace: who changed what, when, and against which prior revision. Roll back a bad edit; understand how the model arrived where it is. How restore behaves when laptops kept working →
Review before it lands
Roles from Viewer through Editor to Administrator and Owner. Changes can be reviewed and controlled so the shared model reflects deliberate decisions, not accidents. Audit trails public-sector work actually needs →
See who is in the model
Lightweight presence shows who else is active right now, so coordination happens naturally instead of through a stream of "are you in the file?" messages.
Your data stays yours
The server runs on infrastructure you choose — on-premises or in your own cloud. Nothing about your model has to leave your control. Ideal for public-sector and regulated work.
Authenticated and encrypted
Token-based authentication, hashed credentials, encrypted transport with certificate pinning between the companion and the server. Access is deliberate and verifiable.
Generate and analyse designs
From inside Enterprise Architect, describe what you want and have it created directly in the selected package — or ask for a plain-language analysis of an existing part of the landscape. Optional, and entirely under your control.
Design assistance, asked from inside EA
CelinQ includes an optional design assistant you reach from Enterprise Architect's own
menu — Ask CelinQ AI, Analyze Selected Package,
Generate into Selected Package — without switching to another window. Select
a package, describe in plain language what you want — "add a Fraud Check service that
guards the Claims Orchestrator" — and the elements and relationships are drafted directly
into that package as real model content, previewed before anything is applied. Ask the
other way round and you get a grounded reading of the part of the model you selected, with
answers that name the actual elements involved rather than a generic summary.
How a sentence becomes a governed model change →
The request starts on your machine, but the call to the AI provider never does: the add-in never talks to a provider directly. It hands the question to the local CelinQ Connect agent, which relays it to the CelinQ Server — the same server holding your workspace — and only that server calls the provider, and only if an administrator has switched the capability on. Nothing about this changes what stays local: your model, your merges and your history never depend on it. Sovereign and customer-hosted deployment patterns →
Technical specifications
| Works with | Sparx Enterprise Architect (in-process add-in plus a companion sync service) and Archi (an Eclipse plug-in with the same sync engine). Existing .eap/.eapx repositories and .archimate models are used as-is. |
|---|---|
| Collaboration model | Local-first: each author edits an independent local repository; changes synchronise to a shared central workspace. |
| Merge engine | CelinQ Fusion — deterministic three-way merge at model-fact granularity, with tombstones, conflict isolation and reproducible results. |
| Sync | Smart Sync with adaptive cadence (responsive during active collaboration, quiet when idle), plus manual and fixed-interval modes. |
| Authentication | Personal access tokens today (PBKDF2-SHA256 hashed, shown once at issue). OIDC SSO — Entra ID, Keycloak, Okta — is the planned next step; the role model already fits it. |
| RBAC | Workspace roles, strictly ordered: Viewer < Editor < Administrator < Owner, enforced server-side on every call. Azure AD/Entra-issued roles are on the OIDC roadmap above, not shipped yet. |
| History & governance | Ordered revision history per workspace; change review; a full audit log of user, token, membership and workspace actions. |
| Server | Runs on your own infrastructure. Storage on SQLite for small teams or PostgreSQL for larger deployments. |
| Security | Token authentication (PBKDF2-SHA256, constant-time compare), encrypted transport with certificate pinning, workspace authorization re-checked on every call — not just at login. |
| API surface & gateways | gRPC for sync, REST for the Control Plane and admin API. CelinQ has no built-in API gateway — the documented guidance is to deploy it behind your own reverse proxy or API gateway (rate limiting, WAF) when exposed beyond a trusted network. |
| Data residency | Fully sovereign. No dependency on any external service for core collaboration or merging. |
| Optional assistance | In-EA design generation and analysis. Off by default, policy-gated, and separable from the core product. |
Honest about what's shipped versus planned: Entra ID/Azure AD sign-in and an API gateway are both on the roadmap, not in the product today. What's live is documented above — token auth, workspace RBAC, and a server that expects to sit behind your own network edge.
Start with five
If you read nothing else, these five cover the core of what makes CelinQ different.
Proof-Carrying Merges
How automatic conflict resolution explains itself, one rule at a time.
Centralized vs Local-First
The flagship comparison: what each approach actually buys you.
Data Residency for Architecture
Why where the model lives is not a detail for public-sector work.
From Prompt to Production Model
One workshop request, followed end to end through validation and audit.
Eighty pieces, one repository that finally behaves
We have written at length about the specific ways single-user modelling breaks down in real teams — from merge anxiety and lost work to sovereignty, onboarding, governance and disaster recovery — and gone deeper still into performance, synchronisation, conflict resolution, operations and governed AI. Start reading below.