Skip to content

Bridging Formal Architecture and Practical Adoption

The gap

Enterprise architecture modeling languages — ArchiMate, UML, BPMN — are expressive enough to describe an entire organization's architecture from strategy to infrastructure. That's not the problem.

The problem is that the models stay locked inside EA tools. Developers don't open Sparx EA. Product owners don't read ArchiMate diagrams. Compliance officers don't query the model repository. The architecture knowledge exists, but it doesn't reach the people who need it.

This isn't a training problem. You can't train 500 developers in ArchiMate notation and expect them to maintain fluency. The economics don't work, and the motivation isn't there — developers care about API contracts and deployment dependencies, not the distinction between an Application Function and an Application Process.

The Linked.Archi approach is: model once in whatever notation fits the author, then generate outputs in whatever format fits the consumer. The knowledge graph is the intermediary.

How it works

The pipeline has three stages:

1. Convert — Architecture artifacts from various tools (ArchiMate Exchange XML, BPMN 2.0.2 XML, PlantUML files, Backstage catalogs) are converted to RDF, typed against the Linked.Archi ontologies. Each converter produces three named graphs: semantic (the knowledge), views (diagram layout), and provenance (where each fact came from).

2. Validate — SHACL shapes check the unified graph against metamodel rules (ArchiMate relationship validity, required properties) and organizational governance rules (every component must have an owner, every decision must have a rationale). This runs in CI/CD.

3. Generate — Generators consume the graph and produce stakeholder-specific outputs: Markdown docs for developers, interactive capability maps for executives, SPARQL workbenches for architects, MCP server access for AI agents.

The key property: all sources share the same arch:core ontology foundation. An ArchiMate Application Component and a Backstage Component that represent the same system can be linked. A BPMN process and an ArchiMate Business Process that model the same workflow can be connected. The graph unifies what the tools keep separate.

What this looks like in practice

Cross-source queries

The most immediate value is asking questions that span multiple tools. Consider: "For each team, what business capabilities do their services support?"

This requires Backstage data (team ownership) and ArchiMate data (capability mapping). Neither tool can answer it alone. In the unified graph:

PREFIX am:   <https://meta.linked.archi/archimate3/onto#>
PREFIX bs:   <https://meta.linked.archi/backstage/onto#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>

SELECT ?team ?component ?capability
WHERE {
    ?comp bs:ownedBy ?teamNode ;
          skos:prefLabel ?component .
    ?teamNode skos:prefLabel ?team .

    ?comp am:assignedTo ?func .
    ?func am:realizes ?appSvc .
    ?appSvc am:realizes ?bizSvc .
    ?bizSvc am:realizes ?cap .
    ?cap skos:prefLabel ?capability .
}
ORDER BY ?team

This traverses from Backstage ownership through ArchiMate's application layer to business capabilities — four hops across two source systems, one query.

Automated governance

SHACL shapes turn governance rules into executable checks:

# Every Application Component must have an owner
:OwnershipShape a sh:NodeShape ;
    sh:targetClass am:ApplicationComponent ;
    sh:property [
        sh:path bs:ownedBy ;
        sh:minCount 1 ;
        sh:severity sh:Warning ;
        sh:message "Application Component has no owner."@en ;
    ] .

Run validate.sh --shacl archimate in CI/CD. The architecture review board still handles judgment calls, but the mechanical checks — ownership, required properties, relationship validity — run automatically on every commit.

Impact analysis

"What is affected if we decommission the Orders database?" In a traditional setup, this is a research project. In the graph, it's a SPARQL query that traces from the data object through accessing components, through realized services, to business capabilities:

PREFIX am:   <https://meta.linked.archi/archimate3/onto#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>

SELECT ?level ?affected ?label WHERE {
    {
        ?affected am:accesses <ex:OrdersDB> ;
                  skos:prefLabel ?label .
        BIND("1-component" AS ?level)
    } UNION {
        ?comp am:accesses <ex:OrdersDB> .
        ?comp am:assignedTo ?func .
        ?func am:realizes ?affected .
        ?affected a am:ApplicationService ;
                  skos:prefLabel ?label .
        BIND("2-service" AS ?level)
    } UNION {
        ?comp am:accesses <ex:OrdersDB> .
        ?comp am:assignedTo ?func .
        ?func am:realizes ?svc .
        ?svc am:realizes ?affected .
        ?affected a am:BusinessService ;
                  skos:prefLabel ?label .
        BIND("3-business-service" AS ?level)
    }
}
ORDER BY ?level

Four layers of impact in one query. The ArchiMate model already contains this information — the graph just makes it queryable without clicking through diagram after diagram.

AI agent access

The MCP server loads the RDF graph into an in-memory SPARQL engine (Oxigraph) and exposes it to AI agents. An architect can ask Claude: "What business capabilities are at risk if we decommission the legacy CRM?" The agent translates to SPARQL, queries the graph, and returns a structured answer grounded in the actual model — not hallucinated from training data.

This works because the ontology provides the schema the agent needs to construct valid queries. Without typed relationships and a formal class hierarchy, the agent would have to guess at the data structure.

Current Scope and Practical Notes

This approach has real limitations:

The conversion step is lossy. ArchiMate Exchange XML preserves everything. PlantUML conversion is best-effort — sequence diagram semantics don't map cleanly to static architecture elements. Backstage catalog-info.yaml is straightforward but shallow.

Keeping the graph current is an unsolved workflow problem. If the ArchiMate model changes in Archi and nobody re-runs the converter, the graph is stale. Continuous sync requires either tool plugins (which don't exist for most EA tools) or a discipline of running converters as part of a CI/CD pipeline triggered by model file changes.

SPARQL is not a mass-market query language. The cross-source queries above are powerful, but they require someone who can write SPARQL. The MCP server helps (AI agents can write SPARQL for you), but it's still a barrier for self-service analytics.

Diagram generation from RDF is immature. Structurizr generates polished, interactive diagrams natively. Generating equivalent visual quality from RDF triples requires layout algorithms that don't exist in the current toolset. The static navigator provides a graph explorer, but it's not a replacement for a proper diagramming tool.

The "model once" promise assumes someone models. If nobody maintains the ArchiMate model, there's nothing to convert. This approach amplifies the value of existing models — it doesn't create models from nothing.

Where this approach fits

This works best when:

  • An organization already has architecture models (ArchiMate, BPMN) that are actively maintained
  • Multiple tools contain overlapping information (EA tool + Backstage + ADR repo + CMDB)
  • Cross-cutting questions ("which capabilities are at risk?", "which systems have no owner?") are asked regularly and currently require manual research
  • Governance rules exist but are enforced manually through review boards

This is overkill when:

  • The architecture fits in one person's head
  • A single tool (Structurizr, Archi) already serves all stakeholders
  • The organization doesn't have the semantic web skills to maintain ontologies and SPARQL queries

Getting started

The incremental path:

  1. Convert one model. Export your ArchiMate model as Open Exchange XML. Run the converter. Load the output into the static navigator. Browse your architecture as a graph for the first time. See if the cross-source queries are interesting.

  2. Add SHACL validation. Pick one governance rule you currently enforce manually (ownership, naming conventions, required properties). Write a SHACL shape. Run it against your converted model. See what it catches.

  3. Connect a second source. If you have Backstage, convert the catalog. If you have ADRs, model a few as ad:Decision instances. Run a cross-source query. This is where the graph approach starts paying for itself.

  4. Deploy the MCP server. Load your RDF files. Connect an AI agent. Ask it questions about your architecture. See if the answers are grounded and useful.

Each step delivers standalone value. You don't need the full pipeline to benefit from any single stage.

References