CelinQ Insights · No. 82

Archi Has No Repository — And No Merge

Enterprise Architect at least has a shared file, a DBMS repository and Pro Cloud Server to escalate through. Archi has a shared file, and then it has nothing.

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 trouble arrives later, quietly, the day a second architect needs to work in the same model, because at that point the team discovers something the download page never mentioned: Archi has no answer to the question at all. Not a limited answer, not an answer with caveats. No answer.

This is worth stating plainly because it is easy to assume otherwise. Sparx Enterprise Architect has spent two decades building an escalation path for exactly this problem — a shared project file first, a proper DBMS repository when the file starts to strain, Pro Cloud Server when the DBMS repository needs to be reachable over the internet rather than a corporate LAN. Every step on that path has real limitations, and earlier pieces in this series have gone through several of them at length. But the path exists. An EA team that outgrows a shared file has somewhere to go. An Archi team that outgrows a shared file has nowhere to go, because Archi was never built with anywhere for them to go to.

What Archi actually is

It helps to be precise about this rather than simply asserting it, because the claim sounds sweeping until you look at what Archi's own architecture actually contains. 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 the entire persistence story. There is no server process anywhere in Archi's design. There is no client-server protocol for a second Archi instance to speak to a first one. There is no concept, anywhere in the tool's own model of itself, of a repository that more than one editing session could be connected to at the same time. Archi is, architecturally, 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, and nobody else.

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. The gap is specifically and only about what happens once more than one person needs to hold a stake in the same model at the same time, and on that question the tool is, by design, silent.

The diagrams deserve a specific mention, because they are where the single-user 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 Archi's file-based persistence has no more of an answer for it than it has for anything else two people touch at once.

The three things teams actually do about it

Faced with silence, teams do not stop collaborating. They improvise, and the improvisations follow one of three well-worn paths, none of which was designed for the job it ends up doing.

The first and most common 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 exact one-editor-at-a-time problem described at length elsewhere in this series for Enterprise Architect's own shared `.eap` files, and it applies to Archi with one important difference that makes it worse rather than better: EA's version of this problem at least comes with an escape valve, a DBMS repository or Pro Cloud Server a team can migrate to once the pain gets bad enough. A team on a shared Archi file has no such valve. There is no next tier to move up to. The file-lock problem is not a stage on a journey; for Archi, on its own, it is the destination.

The second path is version control on the raw file — Git, typically, because it is the version control system most architects' organisations already run for something else. This looks, on the surface, like exactly the right tool: Git is built to let multiple people change the same files and reconcile the results, which is precisely the problem at hand. The difficulty is what Git is actually comparing when it looks at two versions of a `.archimate` file. Git operates on lines of text. A `.archimate` file is XML, and XML is a serialisation of a graph, not a naturally line-oriented format — an edit that is, semantically, "rename this one element," can shift enough surrounding structure, attribute ordering, or whitespace that the line-based diff Git produces bears little visible resemblance to the one-sentence description of what actually happened. Two architects renaming two different, entirely unrelated elements in the same session can produce a Git merge conflict not because their changes actually collide in any meaningful sense, but because both edits happened to land near each other in the file's serialised text. Git's merge algorithm, faced with that conflict, has no idea what an ArchiMate element or relationship means. It cannot know that renaming one thing and moving another are unrelated operations that could trivially both be kept. All it can do is show two blocks of XML side by side and ask a human to reconcile them by hand, in a format built for machines to parse and not remotely built for people to read.

The third path is the one that requires no tooling at all and costs the most in ongoing attention: 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 exported, merged by eye in a text editor or simply retyped into whichever copy of the file is considered current, and the model's actual, ground-truth state becomes a matter of social convention rather than anything the tooling enforces. This works, in the narrow sense that teams using it do produce models, right up until someone forgets the convention, or two people are convinced they each own the same corner of the model, or the person doing the manual reconciliation goes on leave for a week and nobody else knows which of the three floating copies is the one to trust.

What jArchi is, and is not

It would be unfair to describe Archi's ecosystem as offering nothing at all, and the honest version of this argument has to give real credit to what does exist. 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 whatsoever 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, and no amount of clever scripting turns automation of a single session into reconciliation between several.

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

It is tempting, once the gap is this 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 the problem is solved. 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. Building a server to hold a canonical copy of a model is genuinely useful engineering, but on its own it recreates the same choice Enterprise Architect's own Pro Cloud Server makes: the canonical copy lives centrally, and every meaningful operation against it costs a network round trip, because the architect's own editing session is not talking to a local repository at all, it is talking, directly or through a thin client, to that central store. For Archi, which has no local-repository concept to fall back on in the first place, closing that 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, 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 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 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, arguably more abrupt, for Archi, precisely because Archi offers no gentler intermediate step to grow into first.

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's first instinct is the network drive, because it is free and it is already there. For a week or two, with careful turn-taking and a bit of luck about who needs which package when, this holds up well enough that nobody raises an alarm. Then a third architect joins to handle motivation and requirements traceability, the careful turn-taking stops scaling to three people's independent schedules, and the team discovers, at exactly the moment the model has become valuable enough that losing work in it would actually hurt, that there was never a next tier built into the tool for them to move up to.

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 gap 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-user document editor, and the problem a growing team runs into is not a flaw in that design so much as a gap the design was never asked to close — the same distinction this series draws throughout for Enterprise Architect's own architecture, applied honestly to a different tool with a different starting point.

What a team in this position 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 is needed is exactly what Enterprise Architect teams have had, in some form, for two decades: a way to keep working in the tool they already know, at the speed that tool was built to deliver, while a separate layer takes on the job the tool itself was never designed to do. How that layer actually works for Archi specifically is covered in the next piece in this series, but the shape of the answer follows directly from everything above: local editing has to stay local and fast, because that is what Archi's whole design assumes and what makes it pleasant to use in the first place, and the reconciliation has to happen underneath that assumption rather than by replacing it with a central store Archi was never built to talk to live.

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 claim the improvised fallbacks above never work at all — plenty of small teams have run a shared Archi file successfully for years 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 already in pain. It is that the pain, when it arrives, arrives with no built-in next step, and a team that has grown to the point of needing one deserves to know that in advance, rather than discovering it the day a merge goes wrong and nobody can say with confidence which copy of the file was actually current.

The gap described in this article is not a bug anyone forgot to fix. It is the predictable consequence of building an excellent single-user editor and never being asked, by the tool's own original scope, to also build the layer above it. That layer is buildable, and knowing exactly what it has to do — keep local editing fast, reconcile centrally, and never ask an architect to give up the speed Archi was built to offer — is the difference between another attempt that stalls at "browse a copy" and one that actually closes the gap this article describes.