Skip to content

Part of a trilogy. This is article 1 of 3 — the philosophical "why." Next: Practitioner's Guide (strategic "what/when") → Application Layer vs C4 Containers (tactical "how"). See reading guide.

C4 and ArchiMate — Diagramming Approach Meets Modeling Language

Two Extreme Positions on Whether You Really Need Both

Before you start

This article argues two extreme positions in full force, then synthesizes. It's deliberately polarized. If you're looking for a balanced practitioner's guide rather than a debate, article 2 might be a better starting point.

C4 and ArchiMate aren't really the same kind of thing — C4 is a diagramming approach with a small set of abstractions; ArchiMate is a formal modeling language spanning the full enterprise. The framing matters for what follows. See C4 and ArchiMate — Reading Guide for the full context, or read on if you already know.

This document presents two deliberately extreme — but defensible — positions on the relationship between ArchiMate and C4/Structurizr. Each is argued as strongly as possible, steel-man style. The truth for any given organization likely lies somewhere between them, but understanding the extremes sharpens the decision.

Position 1: ArchiMate Is a Superset of C4 — C4 Is Unnecessary

The Argument

C4 is a simplification of concepts that already existed in architecture modeling long before Simon Brown formalized them in the early 2010s. ArchiMate (developed 2002–2004 as a Dutch research project, standardized by The Open Group in 2009), UML (1997), the 4+1 View Model (Kruchten, 1995), and BPMN (2004) collectively cover everything C4 does — and far more. C4 didn't invent hierarchical decomposition of software systems. It repackaged it with friendlier labels.

1.1 Every C4 concept maps to an existing ArchiMate concept

C4 Concept ArchiMate Equivalent Notes
Person Business Actor, Business Role ArchiMate is more precise — it distinguishes the actor (who) from the role (in what capacity)
Software System Application Component (coarse-grained) ArchiMate uses the same element type at multiple granularities — a system-level Application Component maps to a C4 Software System
Container Application Component (fine-grained) + Technology layer elements A "container" is also an Application Component, but deployed on a Node. ArchiMate doesn't distinguish granularity by type — it uses nesting
Component Application Function, Application Process, or nested Application Component ArchiMate provides richer semantics — is it a function? A process? A structural sub-component? C4 lumps them all into "component"
Relationship labels 11 formal relationship types ArchiMate's typed relationships (Serving, Flow, Triggering, Access, Realization, etc.) are strictly more expressive than C4's free-text labels
Deployment diagram Technology layer (Node, Device, System Software, Artifact) + Assignment relationships ArchiMate's Technology layer is a complete infrastructure modeling vocabulary. C4's deployment diagram is a simplified subset
System Landscape Application Cooperation viewpoint or Landscape Map viewpoint ArchiMate has had landscape views since its inception
Dynamic diagram ArchiMate + BPMN ArchiMate's Triggering and Flow relationships model sequences. For detailed process flows, BPMN provides a complete behavioral notation

There is no C4 concept that lacks an ArchiMate equivalent. The reverse is not true — ArchiMate has dozens of concepts (Capability, Value Stream, Goal, Principle, Requirement, Business Process, Data Object, Application Service, Application Interface, Application Event, etc.) that have no C4 equivalent at all.

1.2 ArchiMate's Application layer is richer than C4's entire vocabulary

C4's complete vocabulary is: Person, Software System, Container, Component, Code element, and free-text relationship labels. That's five element types and one relationship type (unlabeled arrow with text).

ArchiMate's Application layer alone provides nine element types:

  • Application Component — the structural unit (maps to both C4 Software System and Container depending on granularity — ArchiMate uses nesting rather than distinct types)
  • Application Collaboration — temporary multi-component configurations (no C4 equivalent)
  • Application Interface — the access point / API contract (C4 has no interface concept — it uses naming conventions or relationship labels as workarounds)
  • Application Function — internal automated behavior (C4's "component" is a vague approximation)
  • Application Process — a sequence of behaviors achieving a result (no C4 equivalent)
  • Application Interaction — joint behavior across collaborating components (no C4 equivalent)
  • Application Event — state changes that trigger processes (C4 captures this only as relationship labels)
  • Application Service — the externally visible unit of functionality (no C4 equivalent — C4 conflates the service with the component that provides it)
  • Data Object — structured data for automated processing (C4 models databases as containers but has no concept of logical data)

Each of these connects via formal relationships to the Business, Strategy, Motivation, and Technology layers. This cross-layer traceability — "which business capabilities are realized by which application services, which are exposed through which interfaces, which access which data objects" — is the entire point of enterprise architecture. C4 cannot express any of it.

1.3 Detailed diagrams existed before C4 — UML and BPMN already solved this

C4 was born from frustration with UML's complexity. But the answer to "UML is too complex" is not "abandon formal modeling" — it's "use UML's relevant subset."

UML Component Diagrams (UML 2.0, 2005) model exactly what C4 Container and Component diagrams model — deployable units, their interfaces, and their dependencies — with the added benefit of formal interface specifications, ports, and provided/required interface semantics. A UML Component Diagram of a microservices system is structurally identical to a C4 Container diagram, but with typed interfaces instead of free-text labels.

UML Deployment Diagrams model what C4 Deployment diagrams model — the mapping of software artifacts to infrastructure nodes — with richer semantics (execution environments, communication paths, deployment specifications).

UML Sequence Diagrams model what C4 Dynamic diagrams model — runtime interactions between components — with precise message ordering, lifelines, activation bars, and combined fragments (loops, alternatives, optional).

BPMN models behavioral flows with a precision that neither C4 nor ArchiMate can match. For the "how does this process work?" question, BPMN provides lanes, gateways, events, sub-processes, message flows, and error handling — a complete behavioral notation.

The combination of ArchiMate + UML + BPMN covers every concern that C4 addresses, plus everything C4 cannot address:

Concern C4 ArchiMate + UML + BPMN
System context ✅ System Context diagram ✅ ArchiMate Application Cooperation viewpoint
Deployable units ✅ Container diagram ✅ ArchiMate Application layer + UML Component diagram
Internal modules ✅ Component diagram ✅ UML Component diagram (nested) or ArchiMate nested Application Components
Code structure ✅ Code diagram (optional) ✅ UML Class diagram
Runtime interactions ✅ Dynamic diagram (basic) ✅ UML Sequence diagram (far richer)
Deployment topology ✅ Deployment diagram ✅ UML Deployment diagram or ArchiMate Technology layer
Business processes ❌ ✅ BPMN + ArchiMate Business layer
Strategy & motivation ❌ ✅ ArchiMate Strategy + Motivation layers
Data modeling ❌ ✅ ArchiMate Data Objects + UML Class diagrams
Impact analysis ❌ ✅ ArchiMate cross-layer relationships + derivation rules
Governance & compliance ❌ ✅ ArchiMate viewpoints + SHACL validation

1.4 The Archi tool already implements C4 as ArchiMate viewpoints

The Archi tool (free, open-source ArchiMate modeler) demonstrated in 2020 that C4's four levels can be implemented as ArchiMate viewpoints within a single ArchiMate model. The Archi blog post C4 Model, Architecture Viewpoint and Archi 4.7 showed this explicitly. The Archi community forum reinforced the point: "C4 model is in fact simply a definition of 4 interrelated viewpoints. Nothing more."

This means you can have C4-style views (System Context, Container, Component) as filtered projections of a richer ArchiMate model — getting the communication benefits of C4's simplicity while retaining the semantic richness of ArchiMate underneath.

1.5 The "architecture as code" argument is a tooling concern, not a modeling concern

The strongest argument for Structurizr is "architecture as code" — DSL files in Git, version-controlled, reviewable in PRs. But this is a tooling feature, not a modeling language feature. Nothing prevents ArchiMate models from being stored as code:

  • ArchiMate models can be serialized as XML (Open Exchange Format) or RDF/Turtle (as this repository demonstrates) and stored in Git
  • The Linked.Archi ecosystem converts ArchiMate models to RDF, which is text-based and version-controllable
  • Tools like Archi store models as XML files that can be committed to Git
  • PlantUML supports ArchiMate notation, enabling text-based ArchiMate diagrams in code repositories

The "as code" workflow is orthogonal to the modeling language. You can have ArchiMate-as-code just as you can have C4-as-code.

1.6 C4's simplicity is a weakness, not a strength

C4 advocates frame its minimal vocabulary as a feature: "easy to learn, low barrier to entry." But in architecture, precision matters. When a C4 diagram shows an arrow labeled "Uses REST API," it conflates:

  • The interface (the API contract) — ArchiMate: Application Interface
  • The service (the behavior exposed) — ArchiMate: Application Service
  • The relationship type (serving? accessing? triggering?) — ArchiMate: 11 distinct types
  • The technology (REST, HTTPS) — ArchiMate: Technology layer
  • The data (what's being exchanged) — ArchiMate: Data Object + Flow

C4 collapses all of this into a single labeled arrow. This is not simplicity — it's ambiguity. When the architecture review board asks "which services does this system expose?" or "what data flows between these systems?", a C4 diagram cannot answer precisely. An ArchiMate model can.

1.7 Summary of Position 1

ArchiMate is a strict superset of C4. Every C4 diagram can be expressed as an ArchiMate viewpoint. ArchiMate additionally provides cross-layer traceability, formal relationship semantics, governance viewpoints, and integration with strategy and business modeling. For detailed behavioral and structural modeling, UML and BPMN — both predating C4 by over a decade — provide richer, more precise notations. C4 is a popularization of ideas that already existed, packaged for an audience that found UML intimidating. An architecture practice with trained architects does not need C4.

Position 2: C4 Is Essential — ArchiMate Alone Is Not Enough

The Argument

ArchiMate is a powerful enterprise architecture language, but it was designed for enterprise architects talking to enterprise architects. It fails at the one thing that matters most in modern software delivery: getting developers to actually use, trust, and maintain architecture documentation. C4 solves this problem, and no amount of ArchiMate viewpoint filtering can replicate what C4 achieves in practice.

2.1 The adoption problem is real and fatal

The most beautiful, semantically precise ArchiMate model is worthless if nobody outside the EA team looks at it. This is not a hypothetical — it is the lived experience of most enterprise architecture practices:

  • Developers don't open EA tools. They don't have licenses, they don't know the notation, and they don't see the relevance to their daily work.
  • ArchiMate diagrams shown to development teams are met with glazed eyes. The notation is unfamiliar, the element types are confusing ("what's the difference between an Application Function and an Application Process?"), and the cross-layer relationships feel like overhead.
  • Architecture documentation maintained only by enterprise architects becomes stale within weeks of a sprint cycle. The EA team updates quarterly; the development team ships daily.

C4 solves this by meeting developers where they are:

  • Learnable in hours, not days. A developer can understand and create C4 diagrams after a 2-hour workshop. ArchiMate Foundation certification takes 2–3 days.
  • Notation-independent. C4 diagrams can be drawn on a whiteboard, in draw.io, in PlantUML, or in Structurizr. No specialized tool required.
  • Lives with the code. Structurizr DSL files sit in the same Git repo as the source code. They're updated in the same PR that changes the architecture. They're reviewed by the same people who write the code.
  • Speaks developer language. "Container" maps to "thing I deploy." "Component" maps to "module in my codebase." These are concepts developers already think in.

2.2 ArchiMate's precision is overhead for 80% of architecture communication

ArchiMate distinguishes Application Component from Application Function from Application Service from Application Interface from Application Process. This precision is valuable for enterprise-level governance. It is counterproductive for a team standup where someone asks "how does our system work?"

Consider the question: "What does our Order Management system look like?"

C4 answer (Container diagram, 30 seconds to read): 

C4Container
    title Order Management — Container Diagram

    Container(api, "Orders API", "Spring Boot", "REST API for order operations")
    Container(db, "Orders DB", "PostgreSQL", "Stores order data")
    Container(bus, "Event Bus", "RabbitMQ", "Async messaging")
    Container(worker, "Orders Worker", "Spring Boot", "Processes async events")
    System_Ext(fulfillment, "Fulfillment Service", "External")

    Rel(api, fulfillment, "REST")
    Rel(api, db, "SQL")
    Rel(api, bus, "AMQP")
    Rel(bus, worker, "AMQP")

ArchiMate answer (Application Cooperation viewpoint, requires notation knowledge): 

flowchart TD
    OM[Order Management<br/><i>Application Component</i>]
    OV[Order Validation<br/><i>Application Function</i>]
    OP[Order Processing<br/><i>Application Function</i>]
    OE[Order Confirmed<br/><i>Application Event</i>]
    OI[Order API<br/><i>Application Interface</i>]
    OS[Order Placement<br/><i>Application Service</i>]
    DO[Order<br/><i>Data Object</i>]
    BServ[Order Fulfillment<br/><i>Business Service</i>]
    FS[Fulfillment System<br/><i>Application Component</i>]

    OM -->|assigned to| OV
    OM -->|assigned to| OP
    OV -->|accesses| DO
    OP -->|triggers| OE
    OM -->|exposes| OI
    OI -->|serves| OS
    OS -->|realizes| BServ
    OM -->|serves| FS

    classDef business fill:#FFFFB5,stroke:#C6C600,color:#000
    classDef application fill:#B5D5FF,stroke:#4A90D9,color:#000

    class BServ business
    class OM,OV,OP,OE,OI,OS,DO,FS application

The ArchiMate version is more precise. It's also harder to read, requires training to interpret, and answers questions the developer didn't ask. The developer wanted to know "what runs where and what talks to what." The ArchiMate model answered "what services realize what business capabilities through what interfaces." Both are valid questions — but they're asked by different people at different times.

2.3 "Architecture as code" is not just a tooling concern — it's a cultural shift

Position 1 argues that ArchiMate can be stored as code too. Technically true. Practically false.

The Structurizr DSL was designed from the ground up for text-based, version-controlled workflows:

workspace {
    model {
        customer = person "Customer"
        orderSystem = softwareSystem "Order Management" {
            api = container "Orders API" "Spring Boot" "REST"
            db = container "Orders DB" "PostgreSQL"
            worker = container "Orders Worker" "Spring Boot"
        }
        customer -> api "Places orders via" "HTTPS"
        api -> db "Reads/writes" "SQL"
        api -> worker "Sends events" "AMQP"
    }
    views {
        container orderSystem {
            include *
            autolayout lr
        }
    }
}

This is readable by any developer. It diffs cleanly in Git. It can be reviewed in a pull request. It generates diagrams automatically.

Now compare the equivalent ArchiMate in Open Exchange Format XML, or even in Turtle:

ex:OrderManagement a am:ApplicationComponent ;
    skos:prefLabel "Order Management"@en .
ex:OrdersAPI a am:ApplicationComponent ;
    skos:prefLabel "Orders API"@en .
ex:OrderManagement am:composedOf ex:OrdersAPI .
ex:OrdersDB a am:ApplicationComponent ;
    skos:prefLabel "Orders DB"@en .
ex:OrderManagement am:composedOf ex:OrdersDB .
ex:OrdersAPI am:serves ex:FulfillmentSystem .
ex:OrdersAPI am:accesses ex:OrderDataObject .
# ... 30 more triples for relationships, services, interfaces ...

This is not "architecture as code" in the way developers experience it. It's a serialization format. The Structurizr DSL is a purpose-built language for defining architecture models. ArchiMate serialized as XML or RDF is a data format that happens to be text.

The cultural difference matters: developers will maintain a .dsl file in their repo. They will not maintain a .ttl file with 50 triples describing ArchiMate relationships.

2.4 The 4+1 View Model and UML didn't fail because they were wrong — they failed because nobody used them

Position 1 argues that Kruchten's 4+1 View Model (1995), UML Component Diagrams, and UML Deployment Diagrams already covered what C4 covers. This is historically accurate and practically irrelevant.

UML's decline is well-documented. Google Trends shows steady decline since 2004. The reasons are well-understood:

  • 14 diagram types is too many. Teams don't know which to use.
  • Notation complexity creates a barrier. Stereotypes, tagged values, OCL constraints — the full UML spec is 796 pages.
  • Tool dependency. UML modeling tools (Rational Rose, Enterprise Architect, MagicDraw) are expensive, complex, and disconnected from development workflows.
  • Waterfall association. UML became associated with heavyweight, upfront design processes. Agile teams rejected it along with the process.

C4 succeeded precisely because it learned from UML's failure:

  • 4 diagram types, not 14. Clear guidance on when to use each.
  • No notation to learn. Boxes and arrows with text. Any tool works.
  • No tool dependency. Whiteboard, draw.io, PlantUML, Structurizr — whatever fits the team.
  • Agile-native. Lightweight, iterative, lives with the code.

Saying "UML already did this" is like saying "Betamax already did what VHS does." Technically superior, practically irrelevant. The best architecture notation is the one people actually use.

2.5 ArchiMate viewpoints cannot replicate C4's zoom experience

Position 1 argues that C4's four levels can be implemented as ArchiMate viewpoints. The Archi tool demonstrated this. But there's a fundamental difference between "filtering an ArchiMate model to show only certain elements" and "C4's progressive zoom from context to code."

C4's zoom is conceptual, not just visual:

  • Level 1 (Context): The system is a black box. You see users and external systems. No internal details.
  • Level 2 (Container): You open the black box and see deployable units. Technology choices become visible.
  • Level 3 (Component): You open a container and see its internal modules. Code structure becomes visible.
  • Level 4 (Code): You open a component and see classes/interfaces. Implementation becomes visible.

Each level has a different vocabulary, a different audience, and a different level of technology detail. This progressive disclosure is built into C4's DNA.

ArchiMate viewpoints filter by element type and relationship type, but the underlying model is flat — all elements exist at the same semantic level. An ArchiMate "Application Cooperation" viewpoint doesn't hide technology details because the architect chose to model them; it hides them because the viewpoint definition excludes Technology layer elements. The zoom is a filter, not a conceptual progression.

More importantly, ArchiMate viewpoints are defined by the specification for specific stakeholder concerns — but the notation still requires familiarity to interpret. C4 levels are defined by audience: Level 1 for all stakeholders, Level 2 for technical roles broadly (architects, developers, ops, security), Level 3 for architects and developers on that container, Level 4 for developers on that specific code. This audience-first design, combined with a notation that requires no training to read, is what makes C4 effective as a communication tool.

2.6 Notation as a consumption barrier

Architecture documentation serves its purpose only when its audience can read it. C4 diagrams use a minimal set of conventions — boxes labeled with what they are, arrows labeled with what they do — so a reader without prior training gets the gist immediately. ArchiMate's visual grammar encodes typed semantics that the reader cannot infer from the diagram itself: element shapes distinguish Components from Services from Functions, arrow styles distinguish Serving from Flow from Triggering, and layer colors carry meaning. A practitioner who knows the notation reads all of this fluently; the broader audience — team leads, ops engineers, security reviewers — who need to consume architecture views but will never produce ArchiMate models can't. The result: ArchiMate views often stay within the architecture team. C4 diagrams circulate.

2.7 C4 fills the gap ArchiMate deliberately leaves

ArchiMate was designed for enterprise architecture — the "30,000-foot view." The specification explicitly positions ArchiMate as complementary to detailed design notations:

"The most important design restriction on the language is that it has been explicitly designed to be as small as possible, but still usable for most Enterprise Architecture modeling tasks." — ArchiMate 3.2 Specification, Chapter 3 (Language Structure)

Appendix D reinforces this by positioning ArchiMate as the "Enterprise model" layer, with UML (software model), BPMN (business process model), and ERD (data model) as the detailed notations below it.

C4 fills exactly this gap — the space between ArchiMate's enterprise view and UML's code-level detail. It provides a developer-friendly way to describe the structure of a single system at a level of detail that ArchiMate considers out of scope and UML makes unnecessarily complex.

The question is not "can ArchiMate express what C4 expresses?" (it can, technically). The question is "will the people who need this information actually consume and maintain it in ArchiMate?" (they won't).

2.8 The Structurizr ecosystem enables workflows ArchiMate tools don't

Structurizr provides capabilities that are native to developer workflows:

  • CI/CD integration: Validate models, generate diagrams, and publish them as part of the build pipeline
  • Pull request reviews: Architecture changes are reviewed alongside code changes
  • Workspace extension: One team's model can extend another team's model via workspace extends
  • Export to multiple formats: PlantUML, Mermaid, DOT, PNG, SVG — whatever the documentation system needs
  • Lite version: A free, local tool that runs as a single Docker container — no enterprise license required

ArchiMate tools (Sparx EA, BiZZdesign, MEGA) are enterprise products with enterprise pricing, enterprise complexity, and enterprise procurement cycles. The Archi tool is free but is a desktop GUI application — not a CI/CD-friendly, text-based, version-controlled workflow.

2.9 Summary of Position 2

C4 is essential because it solves the adoption problem that ArchiMate cannot. ArchiMate is semantically richer but practically inaccessible to the 95% of the organization that builds and maintains software. C4 provides a lightweight, developer-native, version-controlled way to document software architecture that people actually use. The combination of ArchiMate (for enterprise governance) and C4 (for developer documentation) is strictly better than ArchiMate alone, because the best model is the one that gets maintained.

Synthesis: What the Two Extremes Reveal

Both positions are defensible. Both are incomplete. What they reveal together:

Insight From Position 1 From Position 2
Semantic precision matters ArchiMate's typed elements and relationships enable analysis that free-text labels cannot But precision without adoption is shelf-ware
Cross-layer traceability is unique to ArchiMate No C4 diagram can answer "which capabilities does this system support?" But most developers never ask that question — enterprise architects do
Adoption is the real constraint Training can address the knowledge gap But the economics of training 500 developers in ArchiMate don't work
"Architecture as code" is a cultural shift ArchiMate can be serialized as text But serialization ≠ developer experience. DSL matters.
UML and BPMN predate C4 The concepts aren't new But C4 succeeded where UML failed — by being simple enough to use
Viewpoints ≠ zoom levels ArchiMate viewpoints can filter to C4-like views But C4's audience-first progressive disclosure is a different design philosophy
The ArchiMate spec itself acknowledges the gap ArchiMate is comprehensive for EA It explicitly says it doesn't replace detailed design notations

The uncomfortable truth for Position 1

ArchiMate + UML + BPMN is theoretically complete. In practice, the only organizations that successfully use all three are large enterprises with dedicated architecture teams, formal governance, and significant tooling budgets. For the vast majority of software teams, this combination is too heavy. C4 exists because the "correct" answer was too expensive to adopt.

The uncomfortable truth for Position 2

C4's simplicity is also its ceiling. As an organization grows, the questions shift from "what containers does this system have?" to "which business capabilities are at risk if we decommission this platform?" C4 cannot answer the second question. Organizations that start with C4-only eventually need ArchiMate (or something like it) for enterprise-level concerns. C4 is necessary but not sufficient.

The real issue: both need tailoring

Neither is perfect out of the box. Both need tailoring.

ArchiMate covers a broader scope than C4 — it can accommodate C4's top three levels (Context, Container, Component) and the behavioral concepts they imply, plus strategy, motivation, business, and migration concerns that C4 cannot. But it's not a strict superset: C4's code level (Level 4) and detailed internal component structures are below ArchiMate's granularity and outside its intent — by design, ArchiMate is meant to be complemented by detailed notations for what lies below the enterprise layer (see §2.7). The real issues are:

  1. Perceived complexity. ArchiMate 3.2 defines 60 element types. Most organizations use 15–20. The full metamodel intimidates teams who see the spec for the first time. ArchiMate 4 addresses this — it removes several elements (interactions, constraint, contract, gap, representation) and merges behavior elements across domains into a single set of Service, Process, Function, and Event, consolidating them into shared "Common" domain concepts. The result is 42 concrete element types — a significant reduction. But the perception problem persists because the spec is still a large document and the conceptual framework (domains, aspects, relationship rules) takes time to internalize. (See ArchiMate 3.2 vs 4.0 for the full breakdown.)

  2. Tooling. ArchiMate tools are either expensive (Sparx EA, BiZZdesign, MEGA), or free but rough around the edges for collaborative work (Archi has a Git plugin, but multi-architect collaboration on the same model is painful — merge conflicts on XML, no real-time co-editing, not exactly Miro). There's no ArchiMate equivalent of Structurizr's DSL-in-a-repo workflow. PlantUML supports ArchiMate notation, but it's a rendering layer, not a modeling tool.

C4 solves both problems — it's simple to learn and lives in Git. But on its own it creates a gap: no typed relationships means no formal validation, no cross-layer traceability means no enterprise governance, and the moment you need to express "this API is provided by this service which realizes this business capability" you've hit C4's ceiling.

In my experience, both need tailoring — but in different directions.

C4's strength is its simplicity: a minimal set of elements, plain-language labels, no formal notation to learn. Some organizations extend it — Simon Brown's "archetypes" (specialized container types like Database, Message Queue, API Gateway) add useful visual semantics, and teams sometimes introduce typed relationships or validation rules. Whether that's needed depends on the organization's maturity and governance requirements. But one thing is always required regardless of whether you extend C4 or keep it minimal: mapping it to the broader architecture repository. A C4 Software System named "Order Management" becomes useful at the enterprise level when it's linked to the ArchiMate Application Component of the same name, which in turn connects to Business Services, Capabilities, and Goals. Without that mapping, C4 diagrams remain isolated team artifacts.

ArchiMate needs the opposite: simplification and specialization. You simplify by restricting the palette — "for our organization, we use these 18 element types." You specialize by subclassing — ApplicationComponent becomes Microservice, MonolithicApplication, SaaS Platform. ApplicationInterface becomes REST API, gRPC Endpoint, Event Topic. This is what ArchiMate's specialization mechanism is for, but most organizations never use it.

The real integration point is not making C4 more like ArchiMate or ArchiMate more like C4 — it's connecting them through a shared knowledge graph where each retains its own character but both contribute to a unified, queryable architecture repository. C4 stays simple and accessible; ArchiMate stays formal and enterprise-wide; the graph links them by name and lets you traverse from one to the other.

That shared knowledge graph is what Linked.Archi provides: ArchiMate models and C4 models converted to RDF, unified under a common naming convention, queryable with SPARQL, and validated with SHACL — without requiring either notation to change what it is. For the practical walkthrough, see Build Your Own Metamodel.

References

Linked.Archi — This Repository

Original Sources