CelinQ Insights · No. 82

Archi Was Built for One Editor at a Time — What Teams Actually Do About It

Archi's own architecture assumes one editor at a time. coArchi adds real Git-backed collaboration on top of it; CelinQ takes a different, local-first path. What each actually solves, and what it doesn't.

A team standardises on Archi for a reason that usually has nothing to do with collaboration. It is free, it is a faithful, actively maintained implementation of the ArchiMate standard, and it asks nothing of procurement. An architect downloads it, opens it, and is modelling within minutes. That first afternoon feels like exactly the right decision, and for a single architect working alone it stays the right decision indefinitely. The question arrives later, quietly, the day a second architect needs to work in the same model: what actually happens when two people hold a stake in the same file at once?

Archi's own answer to that question is architectural, not organisational: the tool itself has no server process, no client-server protocol, and no built-in concept of a repository more than one session could be connected to at the same time. That does not mean Archi teams are left with nothing — the community around Archi built coArchi specifically to close this gap with Git — but it does mean the answer does not come from Archi's own core, the way Enterprise Architect's does with a DBMS repository or Pro Cloud Server. It comes from a separate plugin, with a different architecture and a different set of trade-offs, and it is worth being precise about both what that plugin solves and where CelinQ's own approach diverges from it.

What Archi actually is

It helps to be precise about this rather than simply asserting it, because the underlying claim is easy to overstate in either direction. A model in Archi is an in-memory object graph — folders, elements, relationships, diagrams, diagram objects and diagram connections — built on the Eclipse Modelling Framework, and that whole graph is serialised to and read from a single file on disk, a .archimate document, in XML. That is Archi's own persistence story. There is no server process anywhere in Archi's core design, and no concept, in the tool's own model of itself, of a repository that more than one live editing session is simultaneously connected to. Archi is, at its core, a desktop document editor for a very sophisticated document, in the same family as a word processor or a vector-drawing tool, and it was built with exactly that document editor's assumptions about who is touching the file at any given moment: one person, right now.

None of this is a criticism of Archi as a modelling tool. As a modelling tool it is genuinely good: a faithful, standards-compliant editor for the full ArchiMate meta-model across its business, application, technology, motivation, strategy and implementation-and-migration layers, with real diagrams, real folders, and a plugin architecture — OSGi bundles dropped into its dropins directory — that lets it be extended without anyone needing to fork the project. That plugin architecture is precisely how the community closed the collaboration gap in Archi's core: not by changing Archi itself, but by building coArchi on top of it.

The diagrams deserve a specific mention, because they are where the single-editor assumption shows up in a form that is easy to underestimate. An Archi diagram is not merely a picture; it is its own set of model objects, diagram nodes and diagram connections, each carrying a real, stable identity of its own and each pointing back at the ArchiMate element or relationship it visualises. That is a genuinely well-built piece of modelling — a diagram in Archi is a first-class citizen of the model rather than a disposable rendering — and it means a shared-diagram conflict is not a cosmetic layout disagreement two people can shrug off. It is a disagreement about the model's own structure, carrying exactly the same weight as a conflicting edit to an element's name or a relationship's endpoints, and it is exactly the kind of conflict any collaboration approach for Archi — coArchi included — has to actually handle, not just detect.

coArchi: what it solves, and what it doesn't

coArchi is a real, actively maintained plugin for Archi, and the honest starting point for this whole piece is naming it rather than talking around it. It gives a team version-controlled collaboration on a shared model, backed by Git: an architect commits their changes, pushes to a shared remote, pulls a colleague's changes, and Archi surfaces a merge step when two people have touched the model since the last shared commit. For a team that already lives in Git for everything else, this is a legitimate and low-friction answer, and it closes the specific gap Archi's own core leaves open — there is now a real, purpose-built path to shared editing, not just a shared network drive and good manners.

Adopting coArchi also means adopting a workflow, not just installing a plugin, and that workflow has real shape to it. Someone has to stand up and maintain the Git remote the team pushes to. Architects have to build the habit of committing and pulling before and after a working session, the same discipline software teams already have for code but that a modelling practice does not necessarily start with. And when the merge step does surface a conflict, resolving it happens inside Archi's own UI rather than a raw text-merge tool, which is a real usability advantage over reconciling XML by hand in a generic editor — but the resolution a person is being asked to make is still fundamentally "which version of this file region wins," not "these two edits are actually compatible and can both be kept," because that second judgment requires understanding what an ArchiMate element and relationship mean, which is precisely the layer Git does not operate at.

What coArchi does not change is the shape of what it is reconciling underneath. A .archimate file is XML — a serialisation of a graph, not a naturally line-oriented format — and Git's merge machinery, including the version coArchi drives, ultimately compares and reconciles that structure at the level of the file, not at the level of "this is an ArchiMate element being renamed" or "this relationship's endpoint changed." Two architects renaming two different, entirely unrelated elements in the same session can still produce a conflict that has to be resolved by a person, because the underlying diff has no model of what an ArchiMate element or relationship actually means — only of what changed in the serialised file. coArchi gives a team a real, working answer to "how do we share this model through Git." It is a different question from "how do we keep editing locally at full speed while a background process reconciles meaning, not just text," which is the question CelinQ is built to answer, for Archi in the same way it already does for Enterprise Architect.

What teams choose between, in practice

Not every Archi team ends up on coArchi, and it is worth being honest about why. Some teams do not already have Git infrastructure or Git-fluent architects, and introducing a version-control workflow into a modelling practice is a real adoption cost, not a free upgrade. For those teams, the fallback is usually one of two paths, and both come with real limits worth naming plainly.

The first is the shared network drive: the .archimate file lives in a folder everyone can reach, and whoever needs to work opens it, edits it, and saves it back. This is the same one-editor-at-a-time problem described at length elsewhere in this series for Enterprise Architect's own shared .eap files, without even coArchi's Git-based reconciliation to fall back on. The second is manual coordination: someone announces in a chat channel that they are working on the business layer this afternoon and everyone else should stay out of it, changes get merged by eye or retyped into whichever copy is considered current, and the model's actual state becomes a matter of social convention rather than anything the tooling enforces.

Both of these are real, common, and genuinely fragile compared to either coArchi or CelinQ. They are what a team ends up doing when the purpose-built options do not fit its existing tooling or its Git comfort level — not a reflection of Archi lacking any answer at all.

What jArchi is, and is not

It is also worth being clear about a tool that gets asked to do a job it was never built for. Archi ships a genuinely capable scripting engine, jArchi, running JavaScript against the live model through a documented API, and it is a serious tool: batch renaming, bulk tagging, structural validation, generating diagrams programmatically, exporting to other formats. Teams that use jArchi well save themselves real, unglamorous hours of manual work, and none of that should be dismissed to make a point about collaboration.

But jArchi was built to automate what one person, or one script, does to a model in a single sitting, and it has no concept of two people's changes needing to be reconciled. A jArchi script has no notion of "the state I started from" versus "the state someone else moved the model to while I was running." It reads whatever is currently open, changes it, and that is the entire transaction. Asking jArchi to solve multi-user collaboration is a category error in the same way asking a spell-checker to resolve a merge conflict would be: it is a real, useful tool aimed at an entirely different problem.

An honest look at what a central repository alone does not solve

It is tempting, once coArchi's file-level ceiling is clear, to reach for the obvious-sounding fix: put Archi's model in a central database, the way Enterprise Architect's DBMS repository does, and reconcile it there instead. An earlier attempt at exactly that, aimed specifically at Archi, is worth learning from rather than repeating uncritically, because it got further than nothing and still stopped short of the actual problem. It built a genuine central repository — a real server, a real management portal, a real Archi plug-in a team could install — and reached the point where a user could browse that server's holdings from inside Archi, see what projects and models existed, and inspect their structure. What it never reached was the harder half of the problem: synchronising a live edit, made in a running Archi session, into that central store, or a change made centrally back out into someone's open model. A central copy you can browse is a read-only window. It answers "what does the model on the server currently say," which is a genuinely useful question, but it does not answer the question a working architect actually has, which is "let me change this, right now, at full desktop speed, and have that change find its way to everyone else without anyone stopping what they are doing."

A central repository that can be browsed is not the same achievement as a central repository that can be synchronised into and out of a live editing session. The first is a database with a viewer. The second is what an architect who wants to keep working at Archi's own speed, on their own machine, actually needs.

This distinction matters because it is exactly where the effort tends to run out, and it is also where coArchi's Git model and a central-database model both stop short in different ways: one reconciles at the file level through commits and merges, the other reconciles centrally at the cost of a live network round trip per operation. For Archi, closing the remaining gap requires something more specific: a way for each architect to keep editing their own, fully local .archimate model at full speed, exactly as Archi was built to be used, while a background process reconciles that local model's changes with everyone else's at the level of the model rather than the file — the same way local-first synchronisation removes the queue from Enterprise Architect's own shared-file problem elsewhere in this series.

Why this stays invisible until the second architect arrives

The reason this gap goes unnoticed by so many teams for so long is structural rather than accidental. Archi's single-editor core design is completely adequate, in fact well suited, to the single-editor case, and a great many Archi deployments genuinely are one architect working alone, or close enough to it that occasional manual coordination never becomes painful. The tool's popularity as a free, capable ArchiMate editor means it accumulates users steadily, and a fair number of those users never hit the wall this article describes, because their situation never demands more than the tool's core was built to offer. The wall is real, but it is only real for a specific and fairly common transition: the moment a practice that started with one person modelling alone grows into a team that needs to model together, a transition covered in detail elsewhere in this series for Enterprise Architect and just as real for Archi, whether a team lands on coArchi, an improvised fallback, or neither.

Picture the concrete version of this. A single enterprise architect adopts Archi for a public-sector engagement, builds out a first cut of the business and application layers over a few weeks, and everything works exactly as expected, because exactly one person is touching the file. The engagement grows. A second architect joins to take on the technology layer, and the team either adopts coArchi if Git already fits its workflow, or reaches for the network drive because it is free and already there. A third architect joins to handle motivation and requirements traceability, and whichever path the team chose now has to hold up under three people's independent schedules rather than two — which is exactly where the difference between a purpose-built collaboration plugin and an improvised fallback starts to show.

Why this is not a case for abandoning Archi

None of this is an argument that a team facing this wall made the wrong tool choice, and it would be a disservice to the argument to imply otherwise. Archi's cost, its faithfulness to the ArchiMate standard, and its active maintenance are all real and durable advantages, and a public-sector team in particular, often working under real budget constraint, has good reasons to prefer a free, standards-compliant tool over a commercial one even once the collaboration question becomes visible. The honest framing is not "Archi is inadequate, switch to something else." It is that a genuinely good modelling tool was built, correctly, as a single-editor core, and the ecosystem around it — coArchi included — has grown real answers to the collaboration question on top of that core, each with its own architecture and its own trade-offs.

What a team weighing its options actually needs is not a replacement for Archi. Nobody wants to retrain a working practice onto an unfamiliar tool, relearn a different meta-model editor, or discard diagrams and conventions that already work well. What CelinQ offers is another option alongside coArchi, not a replacement for it: a way to keep working in Archi at the speed the tool was built to deliver, while a separate layer reconciles meaning in the background rather than through Git commits or a central store. How that layer actually works for Archi specifically is covered in the next piece in this series, including the honest limits of where it stands today.

The honest limits

It would overstate the case to claim every Archi deployment needs this solved. A solo architect, or a very small team that genuinely never has two people needing the same part of the model at the same time, will not feel this gap and does not need to go looking for a fix to a problem they do not have. It would also overstate the case to suggest coArchi or the improvised fallbacks never work well — plenty of teams run a Git-backed Archi workflow successfully for years, and plenty of small teams get by on a shared file through nothing more than discipline and good luck, in the same way plenty of small EA teams get by on a shared .eap file without ever hitting a wall serious enough to justify a DBMS repository. The argument here is not that every team is in pain, or that Archi's ecosystem has nothing to offer. It is that the options differ in a specific, describable way — file-level reconciliation through Git, a central store reached over the network, or local-first semantic sync — and a team deserves to know which trade-off it is actually choosing.

None of the three are wrong answers in the abstract. A team already fluent in Git, already running code review and CI for everything else, will likely find coArchi the path of least resistance, and there is no reason to talk them out of a workflow that fits how they already work. A team that wants collaboration to feel invisible — no commits to remember, no merge step to interrupt a working session, reconciliation happening in the background while everyone keeps modelling at full local speed — is the team local-first semantic sync is actually built for. The next piece in this series covers exactly that path for Archi, including where it stands today and where its own honest limits are.