Skip to content

Interoperability by Design — When AI Makes Every Team a Tool Builder

The Build Your Own Modelling Tool guide shows how to build a tool that consumes a Linked.Archi metamodel. This article is about why the how-to only pays off when the tool is built for interoperability — and what goes wrong when it is not.

Something changed in the last two years. Building a small internal tool used to be a project: a backlog, a team, a quarter. With an AI coding assistant, an architect or a squad lead can stand up a working modelling tool in an afternoon — a palette, a canvas, a store, an export. That is genuinely good. It is also a trap.

The trap is subtle because it does not feel like the old problem. The old problem was vendor lock-in: proprietary tools with closed formats that forced you into yet another integration project. The instinct is that building your own tool escapes that. It does not. It relocates the lock-in from a vendor to your own repository — and because it is cheap now, it happens many times over, once per team.

The Trap

The AI tool-building trap — cheap building leads each team to a tool-local silo and an integration tax AI lowers the cost of building a tool. Without shared vocabulary and identity, each team's tool becomes a new silo, and the cost reappears downstream as an integration tax.

Having control over what you build is not the same as building for interoperability. A tool you own can be just as isolated as one you licensed — the only difference is who wrote the wall. And the economics make it worse, not better: when building is expensive, an organization ends up with one or two tools and can afford to integrate them. When building is nearly free, it ends up with a tool per team, and the integration cost grows with the square of the number of tools.

The point of a data-first approach was never the tool. It was that architectural knowledge should outlive, and interconnect across, whatever tool happened to capture it. A tool that stores its knowledge in a tool-local shape breaks that promise regardless of who owns the source code.

A Worked Example: Two Teams, Two Tools

Consider a mid-size company. Post-AI, two teams each build their own lightweight architecture tool over a weekend.

Team Falcon (payments) builds a React tool backed by Postgres. It stores a component like this:

{
  "id": "svc-4471",
  "name": "Payment Gateway",
  "type": "service",
  "owner": "team-falcon",
  "dependsOn": ["svc-4472"]
}

Team Heron (identity) builds a Python CLI that writes YAML:

- key: IDP_CORE
  title: Identity Provider
  kind: application
  squad: heron
  uses: [SESSION_STORE]

Both tools work. Both teams are happy. Both are fully in control of their own tool. And they cannot answer a single cross-team question, because every axis that matters diverges:

Axis Team Falcon Team Heron Consequence
Type vocabulary type: "service" kind: application No shared notion of what a thing is
Identity id: "svc-4471" key: "IDP_CORE" Local keys, not resolvable or joinable
Relationship name dependsOn uses No shared notion of how things relate
Ownership field owner squad Same concept, different name
Serialization JSON in Postgres YAML files Two extractors before you can even compare

When leadership asks "what across the company depends on the Payment Gateway?", there is no answer without building an integration: an extractor per tool, a schema-mapping layer, an identity-reconciliation step, and a place to run the joined query. That is the same integration project the commercial tools would have imposed — now self-inflicted, and multiplied per team. This is the failure mode named in the diagram above.

The Cost Compounds — Interoperability Debt

The decision to skip interoperability behaves exactly like technical debt: it is nearly free to defer today and increasingly expensive to settle later. The "interest" is integration work, and it compounds with every tool the organization adds.

Interoperability debt — connector count grows with the square of the number of tools on the siloed path, while the data-first path keeps the marginal cost of each new tool flat Two teams feel cheap. The bill arrives at ten. On the siloed path the connector count grows with the square of the number of tools; on the data-first path each new tool is a near-flat cost against one shared graph.

The connector count is only the most visible part of the debt, and even that is unforgiving: connecting N siloed tools point-to-point takes up to N × (N − 1) / 2 connectors — 3 tools need 3, 6 tools need 15, 10 tools need 45. But counting tools understates the problem, because the integration surface compounds on three axes at once:

  • More tools — the N² connector growth above.
  • More functionality per tool — each tool keeps adding element types, relationships, and attributes. Every addition widens the mapping between tools, so integration is never "done" — it is a moving target that grows with each team's roadmap.
  • More overlapping data — as tools mature, they start describing the same systems. That is where the real cost lives, and it arrives as a ladder:
Stage Question it forces Cost when deferred
Integrate Can I even read the other tool's export? An extractor and schema map per tool pair
Reconcile Is svc-4471 the same system as IDP_CORE? A hand-maintained identity mapping that drifts
Unify Which of the conflicting values is correct? Merge logic and tie-breaking rules per attribute
Validate Is the merged whole internally consistent? Cross-tool checks that no single tool can run
Source of truth Which tool owns this fact, and what happens on write conflict? Governance nobody assigned — so it stays unanswered

That last row is the one that quietly breaks a practice. When three tools all hold "Payment Gateway" and disagree, "which tool is authoritative for which fact" becomes an unowned question, and every consumer either picks arbitrarily or stops trusting the data and asks the architect — the exact tacit-knowledge bottleneck the tools were meant to remove.

Put together, these axes are why the cost of using the data — not just building the tools — climbs the way it does:

Cost-over-time chart — the siloed path's cost and complexity of using the data rises steeply and compounds while the data-first path stays flat, the widening gap being accumulated interoperability debt The siloed curve is not linear — each new tool, feature, and overlap adds integration, reconciliation, unification, validation, and a harder source-of-truth question on top of everything already there. The data-first curve stays flat because every tool contributes to one shared graph. The widening gap is the accumulated interoperability debt.

Like technical debt, this is cheapest to pay down at design time — when it costs a few decisions about vocabulary and identity — and most expensive to retrofit after the data exists. The data-first path collapses the whole ladder: shared IRIs mean there is nothing to reconcile, one graph means nothing to unify, a shared SHACL contract validates the whole at once, and provenance metadata on each statement (which team asserted it) makes the source of truth an explicit, queryable property rather than an argument. Adding the tenth tool is the same near-zero marginal cost as adding the first, because it contributes to the graph that is already there instead of standing up another island to bridge.

The Same Two Teams, Built for Interoperability

Nothing about the trap requires the teams to share a tool, a stack, or a UI. Team Falcon can keep React; Team Heron can keep Python. Interoperability is not about the tool — it is about what the tool commits to the record. The fix is that both tools type against the same shared semantic assets and emit RDF with resolvable IRIs.

Team Falcon's tool now exports:

@prefix am4:  <https://meta.linked.archi/archimate4/onto#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix org:  <https://acme.example/id/> .

org:payment-gateway
    a           am4:ApplicationComponent ;
    skos:prefLabel "Payment Gateway"@en ;
    am4:serves  org:merchant-portal ;
    org:ownedBy org:team-falcon .

Team Heron's tool now exports:

@prefix am4:  <https://meta.linked.archi/archimate4/onto#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix org:  <https://acme.example/id/> .

org:identity-provider
    a           am4:ApplicationComponent ;
    skos:prefLabel "Identity Provider"@en ;
    am4:serves  org:payment-gateway ;
    org:ownedBy org:team-heron .

The type is the same class (am4:ApplicationComponent) drawn from a shared ontology. The relationship is the same property (am4:serves). The identifiers are resolvable IRIs in one shared org: namespace, so org:payment-gateway means the same thing in both files. Nobody agreed on a tool. They agreed on a vocabulary and an identity scheme — the two things that actually need to be shared.

Now the cross-team question is one query against the union of both exports, with no integration layer built:

PREFIX am4:  <https://meta.linked.archi/archimate4/onto#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
PREFIX org:  <https://acme.example/id/>

SELECT ?a ?aLabel ?b ?bLabel WHERE {
    ?a am4:serves ?b ;
       skos:prefLabel ?aLabel .
    ?b skos:prefLabel ?bLabel .
    FILTER(?a = org:payment-gateway || ?b = org:payment-gateway)
}

This returns Identity Provider → serves → Payment Gateway (Team Heron's data) and Payment Gateway → serves → Merchant Portal (Team Falcon's data) in a single result set. The graph did the join, because both teams committed their knowledge to the same shape.

Different tools on different stacks stay interoperable by typing against shared assets and emitting RDF into one graph The tools stay independent. The vocabulary, the identity scheme, and the constraints are shared — so three different stacks converge on one knowledge graph that any consumer can query.

The shared contract

The reason both exports line up is not discipline or luck — it is a shared constraint both tools validate against before they publish. The same SHACL shape governs every application component, whoever authored it:

@prefix sh:   <http://www.w3.org/ns/shacl#> .
@prefix am4:  <https://meta.linked.archi/archimate4/onto#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix org:  <https://acme.example/id/> .

org:AppComponentShape
    a              sh:NodeShape ;
    sh:targetClass am4:ApplicationComponent ;
    sh:property [
        sh:path     skos:prefLabel ;
        sh:minCount 1 ;
        sh:message  "Every application component needs a preferred label." ;
    ] ;
    sh:property [
        sh:path     org:ownedBy ;
        sh:minCount 1 ;
        sh:message  "Every application component must declare an owner." ;
    ] .

Team Falcon and Team Heron run this shape in their own pipelines. The contract lives outside both tools, so neither can drift into a shape the other cannot read.

The Interoperability Test

Before shipping a bespoke tool — however you built it, and however small it is — check it against five questions. Each one is the difference between a node in the knowledge graph and another island.

Two paths from the same starting point — tool-local choices lead to a silo, shared semantic assets lead to a graph node Same starting point, two outcomes. The dashed path is the one you fall into by default; the solid path is the one you have to choose.

# Question Siloed tool Data-first tool
1 Vocabulary — where do types and relationships come from? Tool-local strings ("service", uses) A shared ontology and taxonomy
2 Identity — how are things named? Tool-local primary keys (svc-4471) Resolvable IRIs in a shared namespace
3 Serialization — how is knowledge written down? A proprietary blob or bespoke schema RDF, or a lossless export to it
4 Constraints — where do the rules live? Inside the tool's code A shared SHACL contract every tool validates against
5 Access — how does anyone else read it? A tool-private API, or not at all Open SPARQL / graph access

A tool that answers the right-hand column for all five is interoperable by design. A tool that answers the left-hand column for even one or two of them is a silo — and the more of them it gets wrong, the higher the integration tax when someone inevitably needs the knowledge it holds. AI does not change this test. It just makes it easy to fail it faster, and at more points in the organization.

Interoperability as a Design Constraint

The discipline is to treat the five questions as constraints you decide before the first line of tool code, not integration work you defer until a second team needs the data. In practice that means three commitments:

  • Adopt the vocabulary and identity scheme first. Decide the shared ontology (e.g. ArchiMate 4.0 via Linked.Archi) and the IRI namespace before the schema. If no existing vocabulary fits, define your own — see Build Your Own Metamodel — but publish it as a first-class ontology with resolvable IRIs so other tools can type against it too. A custom vocabulary is fine; a tool-local one is the trap. The tool's internal storage can be anything — Postgres, YAML, a graph store — as long as it can emit RDF with those IRIs and types.
  • Make the SHACL contract external and shared. The rules that define a valid model belong outside any single tool, in a place every tool reads. That is what keeps independently built tools producing compatible data.
  • Expose the graph, not just the tool. A tool-private API is fine for the tool's own UI, but the knowledge itself must be reachable by SPARQL or an equivalent open interface, so the next consumer — a report generator, an AI agent, another team — needs no bespoke connector.

Get these right and building your own tool is a genuine win: you get the UX you want without buying another island. Get them wrong and you have rebuilt, at your own expense, the exact problem that made proprietary tools frustrating in the first place. The cheapness of building is not the point. What the tool commits to the shared record is.

Where This Fits