Skip to content

Distributed by Nature

Enterprise architecture knowledge is distributed. Not because organisations choose complexity — but because complexity is what they are. The business architect works in ArchiMate. The developer diagrams in C4 or Structurizr. The platform team maintains a Backstage catalog. The PMO tracks capabilities in LeanIX. The process analyst models in BPMN. Each audience picks the notation that fits its reasoning, and each tool stores data in its own format.

This is not a problem to solve. It is the natural state to design for.

Consider a scenario. A platform team needs to deprecate the Payment Gateway microservice. Today, the team opens Backstage and sees 14 downstream consumers. They open the ArchiMate model and find the gateway supports the "Payment Processing" capability — rated business-critical. They check LeanIX and discover it's classified tier-1 with a €2.4M annual run cost. Three tools, three facts, three logins — and no way to ask the compound question: "What is the full blast radius of deprecating this service across business capabilities, downstream dependents, and financial exposure?"

Nobody can answer that question today without checking three tools manually. The data exists — the connections between it do not.

The distributed tool landscape — multiple teams, multiple tools, isolated silos The distributed reality: each team works in its native tool, producing isolated data silos that cannot link to each other.

The single-tool myth

For two decades, the enterprise architecture tool market has sold a compelling story: buy one tool, put everything in it, achieve a "single source of truth." The promise appears on every vendor slide deck — 360-degree visibility, seamless collaboration, one platform to rule them all.

The reality, documented by analysts who study what happens after procurement, is different.

Forrester's 2025 analysis "When Every Enterprise Architecture Tool Looks The Same" observes that EA leaders experience "slide after slide promising a single source of truth" while recognising that tool after tool delivers "the same story with a different logo." The distinction between tools has collapsed — yet organisations keep buying multiple ones, because no single product fits all stakeholder audiences.

Content rephrased for compliance with licensing restrictions.

The same firm's earlier research "Will Enterprise Architecture Exchange Tools Emerge?" acknowledged directly that "many organizations find they can't avoid choosing several tools to satisfy their wide range of enterprise architecture stakeholders" and that maintaining coherence requires "consolidating and exchanging data and metadata between the different tools they've chosen."

Content rephrased for compliance with licensing restrictions.

This isn't a failure of procurement discipline. It's a structural property of organisations that operate across multiple domains, each with different modelling needs, different skill sets, and different governance boundaries.

Why this keeps happening

The root cause is not technical — it's organisational. Architecture knowledge is produced by distributed teams who think in different abstractions:

Who What they produce Their natural tool
Enterprise architect Layered views, capability maps, roadmaps ArchiMate tools (Archi, Sparx, ADOIT)
Solution architect Component diagrams, integration patterns C4/Structurizr, UML tools
Developer Service catalog, API contracts, dependencies Backstage, OpenAPI, IaC repos
Platform engineer Infrastructure topology, deployment models Terraform, Kubernetes manifests
Business analyst Process flows, value streams BPMN tools, Signavio
PMO / CIO office Application portfolio, lifecycle, cost LeanIX, Ardoq, Planview

Asking all of these groups to work in a single tool is asking them to think in someone else's abstraction. It doesn't happen — or when forced, produces low-quality data because the notation doesn't fit the reasoning.

Forrester's Charles Betz, writing in "Still Federating After All These Years" (April 2025), characterises federated architecture governance not as an immature state to outgrow but as the stable operating model for complex organisations. The 2025 Forrester EA Award finalists (Manulife, Verizon) won specifically for "federated governance, platform modernization, and architecture-led innovation at scale."

Content rephrased for compliance with licensing restrictions.

The real problem: orphaned knowledge

Tool diversity is not the disease. The disease is that each tool creates an isolated knowledge silo — data that cannot be queried, linked, or reasoned about alongside data from other tools.

When the enterprise architect's ArchiMate model says "Order Service" is a BusinessService and the Backstage catalog says "order-service" is a Component with 14 downstream dependents, those two facts should be linkable. A change impact analysis should be able to start from the ArchiMate strategic view and trace through to the Backstage runtime graph. Today, that trace exists only in the architect's head — it's not materialised anywhere a machine can walk it.

The knowledge orphans:

  • No shared identifiers — each tool invents its own IDs. There's no way to say "this ArchiMate element IS the same thing as that Backstage entity."
  • No shared vocabulary — each tool defines its own metamodel internally. There's no way to know that "ApplicationComponent" in tool A is semantically equivalent to "Component" in tool B.
  • No shared query interface — each tool has its own API, its own export format, its own query language. There's no way to ask a cross-tool question without building bespoke integrations.

The shift: from repository to knowledge graph

The enterprise architecture community is converging on a fundamental architectural insight: the integration point should be the data model, not the tool.

There is a useful analogy in how the data engineering world arrived at a similar conclusion. Data Mesh (Zhamak Dehghani, 2019–2024) recognised that centralised data warehousing doesn't scale because it creates a bottleneck team — a central data engineering group that becomes the gatekeeper for every domain's data needs. The solution: decentralise ownership to domain teams while maintaining federated governance and shared interoperability contracts.

The organisational pattern is the same in architecture knowledge, even though the technical scale is different. Data Mesh solved a petabyte-scale pipeline problem; architecture knowledge is rarely more than a few million triples. The scaling challenge here is not computational — it's governance and ownership. Who maintains the model? Who is accountable for its accuracy? Who decides what concepts mean?

The analogy holds at the level of organisational principles:

Data Mesh principles mapped to architecture knowledge The organisational principles transfer — the technical scale does not.

Data Mesh principle Architecture knowledge analogy Where the analogy breaks
Domain ownership Each team owns its models in its native tool Architecture teams are smaller; ownership boundaries are less clear
Data as a product Architecture knowledge is published with quality guarantees (SHACL shapes) No SLAs, no streaming, no operational uptime requirements
Self-serve platform Shared ontology + query interface (SPARQL) lowers the barrier to consume The "platform" is just a triple store + SPARQL — far simpler than a data platform
Federated governance Metamodel manifest defines the contract; conformance is verifiable Governance is still largely human review, not automated policy enforcement

The insight is the same: centralised ownership doesn't scale organisationally. The technical machinery differs — you don't need Kafka or dbt for architecture knowledge — but the governance pattern (distributed ownership, shared contract, federated validation) transfers directly.

The Enterprise Knowledge Graph market reflects the broader industry movement toward this pattern. Analysts project growth from ~$1.9B (2024) to ~$10B by 2032, driven by the recognition that "AI agents cannot operate reliably without structured, governed context about how enterprises actually work."

Content rephrased for compliance with licensing restrictions.

What makes federation work

Knowledge graph as the integration point The knowledge graph is the integration point — tools contribute data through a shared interoperability contract; consumers query across all sources.

Distributed architecture knowledge coheres when three conditions are met:

1. Shared identifiers (IRIs)

Every architecture element has a globally unique, dereferenceable identifier. When an ArchiMate model references a service, it uses the same IRI that Backstage uses. The identifier is the join key — no mapping tables, no fuzzy matching.

This is the Linked Data principle, articulated by Tim Berners-Lee and standardised by W3C: use URIs as names for things, dereference them to get further information, and include links to other data.

2. Shared vocabulary (ontology)

A common metamodel defines what "element," "relationship," "viewpoint" mean — regardless of which tool produced the data. The tool-specific types (ArchiMate's ApplicationComponent, Backstage's Component, C4's Container) remain intact but declare rdfs:subClassOf a shared superclass. Nothing is lost; everything is queryable at the right level of abstraction.

This is what the arch:Metamodel manifest provides: a machine-readable declaration of what concepts a modeling language defines, how they're classified, and how they should be rendered. Any tool that reads this manifest can consume any modeling language — no hardcoding.

3. Shared validation (shapes)

SHACL shapes define quality rules: required properties, valid value ranges, cardinality constraints. They travel with the data, not the tool. Any consumer can validate incoming architecture data against the published shapes — without knowing which tool produced it.

Industry standards enabling this

The building blocks already exist as open standards:

Standard Role Published by
RDF Universal data model (subject-predicate-object triples) W3C
OWL Ontology language (class hierarchies, property semantics) W3C
SKOS Lightweight classification (palette grouping, taxonomies) W3C
SHACL Constraint language (validation shapes) W3C
SPARQL Query language for RDF graphs W3C
Linked Data Principles Best practices for publishing structured data on the Web W3C
UML 2.5.1 General-purpose modeling language for software systems OMG
MOF 2.5.1 Meta-Object Facility — the meta-metamodel for OMG languages OMG
ODM 1.1 Ontology Definition Metamodel — formal MOF↔OWL mapping rules OMG
BPMN 2.0.2 Business process modeling notation OMG
SysML Systems Modeling Language (extends UML for systems engineering) OMG
ISO/IEC/IEEE 42010:2022 Architecture description — concepts, viewpoints, and views ISO
ISO/IEC/IEEE 42020:2019 Architecture processes — governance and evaluation ISO
ISO/IEC 25010:2023 Systems and software quality models ISO
ISO/IEC 15288:2023 Systems and software engineering — system life cycle processes ISO
ISO/IEC 12207:2017 Systems and software engineering — software life cycle processes ISO
ArchiMate 3.2 / 4.0 Enterprise architecture modeling language The Open Group
ArchiMate Exchange Format XML exchange between ArchiMate tools The Open Group
TOGAF Architecture Repository Federated repository concept The Open Group

The ArchiMate Exchange File Format (v3.1) demonstrates that even within a single notation, The Open Group acknowledged the need for data to move between tools. But XML exchange between tools of the same type solves only the intra-notation problem. The inter-notation problem — linking ArchiMate to Backstage to BPMN — requires the graph.

The Linked.Archi approach

Linked.Archi implements this vision with a minimal set of conventions:

  1. Metamodel manifest (arch:Metamodel) — a single Turtle file per modeling language that declares all its resources: ontology, taxonomy, notation, shapes, viewpoints, templates. This is the entry point for any tool.

  2. Dereferenceable IRIs — every concept, class, and property has an IRI that resolves to its definition. https://meta.linked.archi/archimate3/onto#BusinessActor returns the OWL class definition. No proprietary API needed.

  3. Palette conformance spec — a tool vendor can implement palette construction by following three steps: discover classes (OWL), group them (SKOS), style them (NotationSet). The spec is language-agnostic — it works identically for ArchiMate, C4, EDGY, UML, BPMN, Backstage, and LeanIX.

  4. Multiple notation sets — the same model data can be rendered with ArchiMate standard shapes, AWS architecture icons, or simplified executive notation. The visual layer is separate from the semantic layer.

  5. Federated canonical layer — when models from different languages land in one graph, a thin layer of shared superclasses enables cross-source queries without collapsing the native semantics. See Bridging Architecture Silos for the technical mechanism.

The result: each team keeps its tool. The graph is the integration point. Knowledge becomes queryable, linkable, and actionable — regardless of where it was authored.

What this means for tool vendors

If you build an architecture tool, you don't need to replace everything. You need to:

  1. Publish your metamodel as an arch:Metamodel manifest — declare what concepts your tool produces.
  2. Use dereferenceable IRIs for the elements your tool creates — so other tools can link to them.
  3. Export RDF (Turtle) alongside your native format — so the graph can ingest your data.
  4. Consume the shared shapes — validate incoming data from other tools against the published contract.

This is a lower bar than "support ArchiMate." It's: "describe what you produce in a machine-readable way, and use stable identifiers." Any tool that does this participates in the graph.

The Build Your Own Modeling Tool guide shows the implementation in detail, including the Palette Construction Conformance Specification that defines exactly what a conformant tool must do.

What this means for enterprise architects

Stop trying to get everyone into one tool. Instead:

  1. Define the ontology — decide what concepts matter to your organisation and how they relate.
  2. Assign ownership — each domain team owns its slice of the graph, authored in its native tool.
  3. Publish the contract — the metamodel manifest is the interface definition between teams.
  4. Query across boundaries — use SPARQL (or an MCP-enabled AI agent) to ask questions that span tools.

The architecture is distributed because the organisation is distributed. The knowledge graph is what makes it coherent.

The scenario, resolved

Return to the Payment Gateway deprecation. With a shared graph, the compound question becomes a single SPARQL query — or a natural-language prompt to an MCP-enabled AI agent:

"What is the blast radius of deprecating the Payment Gateway?"

The graph walks the links: Backstage provides the 14 downstream consumers. ArchiMate provides the business capability mapping (Payment Processing, critical). LeanIX provides the tier-1 classification and €2.4M cost. The response arrives in seconds — not because someone built a bespoke integration, but because all three tools published their data against a shared vocabulary with stable identifiers.

No one changed tools. The developer still works in Backstage. The architect still models in ArchiMate. The PMO still manages the portfolio in LeanIX. What changed is that their outputs became linkable — and the question that used to live in one person's head now lives in a graph anyone can query.

Further reading

This article presents the strategic argument. For the technical mechanisms:

References