Your projects are separate. Your architecture is not.

This isn't a pitch to merge every Archi file into one undifferentiated blob. It's the opposite: keep the project views, keep the project pace, keep the project ownership — and stop asking every new project to re-document architecture that already exists somewhere else in the organisation.

See the shared workspace, not a slide

Two teams, two Archi projects, the same underlying architecture under different names — synchronised into one workspace they both draw from. Captured straight off the running product.

What a project-by-project Archi practice quietly costs

Most organisations don't decide to fragment their architecture. It happens by accident, one project at a time. Project A models a customer-facing application because, from where that team sits, nothing describes it yet — and they're right, nothing does. A year later, Project B needs the same application for an unrelated initiative, doesn't know Project A's file exists, and models it again under a different name. Project C arrives later still and does the same thing to a capability both earlier projects had already defined, slightly differently, in their own words.

None of this is anyone doing their job badly. Each individual .archimate file can be perfectly correct, internally consistent, and genuinely useful to the project that produced it. The damage is invisible at the project level and only shows up once you try to look across projects: the same application counted twice in a portfolio review, a capability map that contradicts itself depending on which team drew it, an impact analysis that can only ever see as far as one project's own file, and a new architect who opens a blank canvas because nobody can tell them which of the three existing files, if any, already covers the ground they're about to cover.

Four rows, arguably four real systems — and up to three names apiece. Nothing here is a modelling mistake. It's what happens when every project starts from zero.

The issue was never the notation. ArchiMate is more than capable of representing all of this correctly. The issue is that a .archimate file, on its own, has no way of knowing that another file three projects ago already answered the question it's currently re-asking. That's not a tooling limitation so much as what "one file per project" necessarily means: continuity has nowhere to live.

The shift: from documenting the enterprise to inheriting it

That's the actual difference between document-based and model-based architecture. A project shouldn't repeatedly document the enterprise from scratch just because it's the one holding the pen this quarter. It should start from what the organisation already knows, and contribute back whatever it genuinely changes.

Concretely, with CelinQ: each project keeps working in its own local Archi model — its own views, its own pace, offline if needed, exactly as today. A companion service synchronises that project's changes with a shared CelinQ workspace your organisation runs, the same mechanism that already lets several architects share one Sparx Enterprise Architect repository. Nothing about that local-first architecture changes — what changes is what the workspace on the other end represents: not one project's file, but the architecture several projects draw from and contribute to.

Views are different on purpose. Elements shouldn't be.

This distinction carries most of the weight, so it's worth stating precisely. Project A might need a Customer Onboarding view. Project B might need an Identity Migration view. There is nothing wrong with either project drawing its own diagram, scoped to its own concerns, in its own language for its own stakeholders — that variety is normal, not a governance failure to stamp out.

What both diagrams should be able to point at, when they genuinely mean the same thing, is the same underlying Customer Portal element — the same identity, the same relationships, the same history — rather than two elements that happen to look similar. CelinQ's Fusion engine works at exactly this granularity: individual model facts, not whole diagrams, which is what makes "shared element, separate views" possible instead of "shared file, no separate views" or "separate files, no sharing" being the only two choices on offer.

Why this is worth doing

What happens when two projects touch the same architecture

In the document-based world, two projects changing "the same" system never generates a conflict — because there was never one system to begin with, only two separate files that each believed they held the truth. That absence of conflict is not safety. It's two contradictory architectures nobody has yet noticed are contradictory.

Sharing the underlying model changes this for the better, not the worse: a real conflict becomes visible and gets handled, instead of an invisible one quietly persisting. When Project A and Project B genuinely change the same architectural fact at the same time, CelinQ Fusion does exactly what it already does for two architects sharing one Sparx repository — reconciles what it can prove is safe, and surfaces the rest as a real decision for a person to make, with both versions preserved. Deletions are handled the same careful way, so one project's cleanup can't silently erase another project's in-progress work.

Shared architecture gives AI something to reason against

CelinQ's optional design assistant — off by default, switched on deliberately, policy-gated — is more useful the more of the real architecture it can see. Asked in isolation, an AI can only reason about the requirement in front of it. Asked against a shared workspace, it can check the requirement against applications, capabilities, services and relationships that other projects have already put there.

Some of the resulting questions are already answerable today with CelinQ's deterministic tooling — not AI guesses, direct queries against the model: what depends on a given element, and what it depends on. Others — "does this application already exist somewhere else in the organisation," "is this a duplicate," "which existing service could satisfy this instead" — are exactly the kind of judgement call CelinQ's duplicate-detection scoring was built to assist with inside a single Enterprise Architect repository; extending that same assistance across an Archi-based, multi-project workspace is the direction this is heading, not a claim about what ships today.

Honest about what's shipped versus direction: the deterministic one-hop dependency queries are real and live today. Cross-project duplicate detection for Archi, and multi-hop "full blast radius" impact analysis, are the natural next steps of this same architecture, not yet-built features being described as if they exist.

Keeping control while you do this

Where it runs	Your own infrastructure — on-premises, your own Azure subscription, or air-gapped. The shared workspace is yours, not a hosted service you're handing architecture to.
Who approves changes	A person, always, for anything AI proposes. Deterministic queries and Fusion's own reconciliation don't need AI at all.
Roles	The same Viewer/Editor/Administrator/Owner roles that already govern a shared EA workspace apply identically to a shared Archi workspace — no separate permission model to learn.
History	Every change, ordered, attributable — who changed what, and against which prior revision, across every project that touched the workspace.
AI	Off by default. An administrator switches it on feature by feature. Sovereign mode removes it entirely and irreversibly for organisations that can't accept it at all.

The governance questions worth asking up front

Moving from document-based to model-based architecture does raise real questions, and it would be dishonest to pretend otherwise. Who owns a shared application once two projects depend on it? What happens when a project-specific element is genuinely ready to become enterprise architecture, and when is it not? How are naming differences between two people's honest description of the same thing actually resolved?

CelinQ doesn't claim to have turned these into solved, automated workflows — they're organisational decisions as much as technical ones. What it does provide is the mechanism underneath them: workspace roles to say who can change what, Fusion to reconcile or surface concurrent changes rather than silently pick a winner, a full audit log of who did what and when, and ordered history so a disputed change can always be traced back to its origin. The judgement calls stay with your architects. The tooling stops those judgement calls from being undermined by architecture nobody can see in the first place.

A way to think about where you are today

Not an industry standard, not a formal maturity model — just a useful way to place a practice on a spectrum from documents to shared, governed, AI-assisted context.