CelinQ Insights · No. 83

CelinQ for Archi: One Server, Two Modelling Tools

The gap this series has just described in Archi is now closed by the same engine that already closes it in Sparx EA — proven, not promised.

The previous article in this series set out plainly what Archi's own core does not have: no server, no locking, no built-in repository concept of any kind — leaving a team either on coArchi's real but file-level Git collaboration, or falling back to shared drives and manual coordination for a tool that otherwise does serious architectural modelling well. This article is about a further option: CelinQ, built originally for Sparx Enterprise Architect, now speaks Archi as well, and it does so through the same server, the same synchronisation engine, and the same deterministic merge that Enterprise Architect users already rely on. That is not a marketing simplification of a more complicated reality underneath. It is the literal, checkable architecture: a second modelling client was added to CelinQ this year, and it plugged into the existing product without touching the parts of CelinQ that make it trustworthy in the first place.

What actually got built

Archi's own model lives behind a real, documented Java API, and CelinQ's Archi client reads and writes it through exactly that API rather than through any indirect or unofficial route. An `ArchiModelReader` walks Archi's folders, elements, relationships, diagrams, and diagram content into CelinQ's canonical model; an `ArchiModelWriter` does the reverse, creating and updating the same kinds of objects back into a live Archi session. Sitting above both is an `ArchiSyncEngine`, and the word "engine" is doing real work in that name rather than standing in for something thinner: it is a deliberate, close port of the same synchronisation engine that already runs inside Enterprise Architect's own CelinQ add-in, carrying across the same scan-detect-queue-push-pull-apply lifecycle, the same fingerprint-based change detection, and the same echo-suppression rule that stops a client from mistaking its own change, arriving back from the server, for someone else's edit. None of that had to be invented again for Archi. It had to be re-implemented, carefully, in Java against a different tool's API, which is a different kind of work entirely and one this series will not pretend was trivial.

Inside Archi itself, this shows up as an ordinary-looking plug-in with menu commands any Archi user would recognise the shape of: Connect to Server, Sync Now, Resolve Conflicts, Status. An architect points Archi at a CelinQ Server and a workspace, and from that point on the model in front of them behaves the way an Enterprise Architect repository already behaves under CelinQ — fast, local, editable offline, converging with everyone else's copy in the background rather than on every keystroke.

None of that plumbing is invisible to the person running it, and it is worth being specific about what installing it actually involves rather than waving at "a plug-in" as though it were a single click. Archi 5.7 requires Java 21 to run at all, a fact stated plainly in Archi's own startup configuration rather than inferred, and the Archi-side build targets that same version deliberately rather than assuming an older one would do. The plug-in itself is packaged as a standard Eclipse OSGi bundle, installed the same way any Archi plug-in is installed — dropped into Archi's own plug-in folder — and it loads through Archi's ordinary plug-in lifecycle rather than through any special-cased hook. An architect does not need to know any of this to use it. It matters to state plainly because the alternative, a plug-in that only works through some fragile, undocumented trick, would not have survived the kind of real testing this article is about to describe.

Why almost nothing else had to change

CelinQ's architecture already drew a firm line, long before Archi was any part of the plan, between the parts of the system that know about a specific modelling tool and the parts that do not. Everything Sparx-specific lives in one adapter layer and nowhere else; the canonical domain model, the synchronisation protocol, and the server itself have no idea Enterprise Architect exists. That boundary was not added retroactively to make this article's case look tidier. It was there from the start, visible in the domain model's own `SourceSystem` field — a piece of canonical data whose entire purpose is recording which tool a given fact originated from, present in the schema well before a second tool was ever built to populate it with anything other than Enterprise Architect's name.

Adding Archi meant writing a new adapter that slots into precisely that seam. It did not mean touching the domain model, the wire protocol, or the server. Zero lines changed in any of the three. That is not a boast dressed up as an architecture diagram; it is a fact you can confirm by looking at what the Archi work actually touched, which is a new adapter and a new synchronisation port and nothing underneath either of them. A system that has to be substantially reopened every time it meets a new tool was not really tool-agnostic in the first place, whatever its documentation claimed. CelinQ's was.

Where the two tools genuinely differ

It would be a little too neat to claim the two adapters are identical apart from the language they are written in, and one real difference is worth naming because it is a small, concrete example of how a second tool can teach you something about the first. Enterprise Architect has no native, stable identity for the little boxes and lines that make up a diagram — a diagram object referencing a given element has to be identified by a synthetic key stitched together from the diagram's identity and the element's, because EA's own Automation API simply does not hand you one. Archi does not have that problem. A diagram object and a diagram connection in Archi carry their own real, persistent identity from the moment they are created, the same as any other model object, which makes the Archi-side mapping for that specific piece genuinely simpler than its Enterprise Architect counterpart. Neither approach is a shortcoming; they are just different choices two different tools made about what deserves its own identity, and CelinQ's canonical model absorbs the difference without either adapter needing to know the other one exists.

A situation this was actually built for

Consider a public-sector architecture office of the kind this series has described before: an enterprise architecture team required, for reasons of licensing budget and standards alignment, to do most of its motivation and strategy modelling in Archi, working alongside a delivery organisation that has used Enterprise Architect for a decade and has no intention of migrating its application and technology layers away from it. Before this year, that split was not a technical inconvenience the two teams worked around cleverly. It was two disconnected practices describing overlapping parts of the same organisation, reconciled by whoever had the patience to open both tools, compare them by eye, and manually keep a shared glossary of "this Archi business service is the same thing as that EA application component" current in someone's head or, at best, in a spreadsheet nobody trusted for long.

Under CelinQ, that same organisation runs one workspace on one server. The Archi-based team models motivation and business layers the way they always have, inside Archi, at full local speed, and those facts synchronise into the shared workspace the same way an Enterprise Architect edit already did before Archi was ever part of the picture. The delivery organisation's application and technology work, still modelled in Enterprise Architect exactly as before, lands in the same workspace through the same server. Neither team has to open the other's tool, learn its notation, or trust a manually maintained glossary to know that "the same thing" really is the same thing — the canonical model, not a spreadsheet, is the single place that fact now lives, carrying a stable identity that both tools' local copies converge toward. This is not a hypothetical extrapolation dressed up as a case study. It is the direct, mechanical consequence of the proof described next, applied to the situation an actual mixed-tooling architecture practice is in today.

The proof that matters more than the architecture diagram

Architecture diagrams are cheap to draw and easy to overstate, so the part of this worth dwelling on is what was actually run, once, for real, rather than what was designed on paper. A genuine Sparx Enterprise Architect repository, driven the same way EA is normally automated, created content and published it to a CelinQ Server running in the cloud. A genuine, live Archi model — the same code path an architect's own Archi session uses, not a stand-in or a simulation — connected to that same workspace, pulled the Enterprise-Architect-authored content down, and separately authored a new element of its own and pushed it back up. A second, entirely fresh Enterprise Architect repository then joined the same workspace from scratch, and the element Archi had authored was there, created inside a real EA repository through the same automation interface EA has always exposed, having travelled from Archi's model, through the server, into a tool that has never heard of Archi and does not need to.

Say that sequence back in one line and its significance is easy to miss under the technical detail: two completely different modelling tools, built by two completely different vendors, each with its own file format and its own idea of what a model even is, ended up looking at the same shared architecture through the same server, each one's edits appearing in the other. That is the actual claim this article is making, and it is a claim backed by a run that happened, not a diagram that was drawn. Anyone sceptical of a vendor's own description of its own test, reasonably enough, should treat the specific, named limitations further down this article as the more trustworthy signal — a description of a proof that only tells you what went right, with no mention of what still does not, is not one you should believe from CelinQ any more than from anyone else.

The test that matters is not whether a diagram shows two boxes reaching the same server. It is whether an edit made in one real tool actually shows up, correctly, in a completely different real tool that has never heard of it. That is the test that was run, and it passed.

What stays exactly the same, regardless of which tool you open

Because Archi and Enterprise Architect meet at the same server, everything this series has already described about that server applies to an Archi workspace without qualification. Fusion's deterministic three-way merge reconciles concurrent Archi edits the same way it reconciles concurrent EA edits, with the same rule codes explaining why an automatic merge was judged safe. Tombstones stop a deleted Archi element from silently overwriting a colleague's in-progress change to it, the identical protection Enterprise Architect users already have. Every workspace still carries a full, ordered revision history, regardless of which tool wrote which entry into it. And data sovereignty is not a separate story for Archi users to evaluate afresh — it is the same CelinQ Server, running on infrastructure the organisation already chose and controls, with an Archi model now sitting alongside Enterprise Architect repositories inside exactly the same boundary. None of this had to be re-argued or re-engineered for a second tool. It simply already applied, because the server never cared which client was talking to it.

What is genuinely still missing

It would undercut everything this series stands for to describe the Archi client as finished, and it is not, so the honest gaps deserve the same directness the rest of this comparison has had. Type mapping between the two tools' meta-models is incomplete. Enterprise Architect and Archi describe the world differently — EA through an open, UML-derived palette that a team can extend however it likes, Archi through ArchiMate's fixed, standards-defined vocabulary — and translating cleanly between them needs real mapping work that has not been finished yet. In testing, an Enterprise Architect element created with an ArchiMate-flavoured type on an installation without the ArchiMate technology active fell back silently to EA's native class type, which has no ArchiMate equivalent at all. The Archi-side writer does the right thing when it meets a type it cannot represent: it refuses to guess, logs the failure plainly, and lets the rest of that synchronisation batch continue rather than aborting the whole thing over one unmappable element. But refusing to guess is not the same as solving the underlying problem, and that element's architectural meaning was genuinely lost in that run, not merely delayed.

It is worth being clear about why this particular gap is hard rather than merely unfinished, because the distinction matters for how much confidence to place in it closing soon. Archi's type system is ArchiMate's own, a fixed, standards-governed vocabulary of roughly a hundred element and relationship types spread across clearly defined layers, and every one of those types means exactly what the ArchiMate specification says it means, everywhere, for everyone using Archi. Enterprise Architect's type system is not fixed in that way at all. It ships with a broad UML-derived palette out of the box, and organisations routinely extend it further with their own custom types, stereotypes, and technologies layered on top through EA's own extensibility mechanisms. Mapping a closed, standards-defined vocabulary onto an open, organisation-extensible one is not a lookup table you write once and forget; it is an ongoing modelling decision, and a defensible one has to account for the fact that two different EA deployments might use the same type name to mean two different things. CelinQ's position is that this deserves to be solved deliberately, with real input from organisations living on both sides of it, rather than shipped early as a best-guess table that quietly gets some fraction of types wrong in ways nobody notices until an audit does.

Two further gaps are about maturity rather than correctness. Smart Sync's adaptive rhythm — fast while two people are actively working the same area, calmer once things go quiet, still checking in periodically underneath both — already runs for Enterprise Architect and has not yet been carried across to Archi, where Sync Now is, for the moment, something an architect has to trigger themselves rather than a background process quietly keeping pace on its own. And Resolve Conflicts on the Archi side currently shows you what Fusion is waiting on without yet letting you act on it from inside Archi the way the Enterprise Architect add-in already allows — visibility without action, a real and named limitation rather than a polished feature described selectively.

Who this is for right now

It also matters to say plainly who this is not yet for, in the same spirit as the gaps named above. A team whose Archi models lean heavily on custom viewpoints, unusual extensions to the notation, or an unusually large number of nested diagram references may find edges the testing so far has not exercised as thoroughly as the core folder, element, relationship, and diagram mapping described earlier — the honest position is that the core path is proven and the long tail of Archi's flexibility is still being worked through, not that every possible Archi model has already been thrown at it. An organisation whose two teams disagree constantly and substantively about what a shared concept should be called, rather than merely modelling it in two different tools, has a governance problem CelinQ cannot solve for them; synchronising two teams' models faithfully is not the same thing as making them agree, and Fusion will surface that disagreement honestly rather than paper over it.

An organisation running Archi today, coordinating a shared model the way the previous article described — a network drive, a Git repository holding XML nobody can meaningfully diff, or a set of side-channel messages about who is touching which layer this week — has, for the first time, a real alternative that does not ask anyone to leave Archi or learn a new modelling tool. It also has, for organisations already standardised on Enterprise Architect for parts of the estate and Archi for others, a way to let both live in the same shared architecture practice rather than as two disconnected islands that happen to describe overlapping parts of the same organisation. Neither of those is a hypothetical use case invented for this article. Both are exactly the situations the underlying architecture, built once and reused rather than duplicated, was designed from the outset to eventually serve — and the point at which "eventually" became "now" was this year, when the second adapter was written, tested against real infrastructure, and shown to work.

The type-mapping gap, the not-yet-ported Smart Sync rhythm, and the visibility-only conflict view are real work still ahead, and naming them plainly here is the same discipline this whole series has applied to Enterprise Architect's own comparisons. What is not still ahead is the harder, more fundamental question of whether CelinQ's architecture could actually extend to a second, structurally different modelling tool without being rebuilt around it. That question has an answer now, and the answer is a real Archi model and a real Enterprise Architect repository, reflecting each other's edits through infrastructure that already existed before either team member ever opened it — the same server, the same merge engine, and the same commitment to naming what still does not work exactly as plainly as what already does.