Part of a trilogy. This is article 3 of 3 — the tactical "how." Previous: Diagramming Approach Meets Modeling Language (philosophical "why") → Practitioner's Guide (strategic "what/when"). See reading guide.

Guideline: Modeling Application Internals — ArchiMate Application Layer vs C4 Containers¶

Before you start

This is the tactical end of a three-article trilogy on combining C4 and ArchiMate. If the framing of "Application Layer vs Containers" feels like it presupposes context, see the reading guide for orientation.

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.

Context¶

A common oversimplification when combining ArchiMate and C4 is to say "use ArchiMate only at the Application Component level and leave everything below that to C4." This misses the point. ArchiMate's Application layer provides nine distinct element types, each with precise semantics and — crucially — formal relationship types that connect them to the Business, Strategy, Motivation, and Technology layers. That cross-layer traceability is something C4 simply cannot provide.

This guideline clarifies what to model where, and why ArchiMate's Application layer elements are not "container internals" but first-class architectural concepts that serve a different purpose than C4's zoom levels.

1. What ArchiMate's Application Layer Actually Provides¶

The Application layer in ArchiMate 3.2 defines nine element types organized by aspect:

Aspect	Element	Purpose
Active Structure	Application Component	A modular, deployable, and replaceable part of a software system that encapsulates behavior and data
Active Structure	Application Collaboration	A temporary configuration of two or more components working together
Active Structure	Application Interface	A point of access where an application service is made available to a user, another component, or another system
Behavior	Application Function	Automated behavior performed by a component
Behavior	Application Process	A sequence of application behaviors that achieves a specific result
Behavior	Application Interaction	A unit of behavior jointly performed by two or more collaborating components
Behavior	Application Event	An application state change
Behavior	Application Service	An explicitly defined exposed behavior — the externally visible unit of functionality
Passive Structure	Data Object	Data structured for automated processing

These are not implementation details. They are architectural concepts that answer questions like:

What services does this application expose? (Application Service)
What data does it own or access? (Data Object)
What behavior does it perform internally? (Application Function, Application Process)
How do consumers interact with it? (Application Interface)
What events does it produce or consume? (Application Event)

The cross-layer power¶

The real value is in the relationships these elements form with other layers:

flowchart LR
    subgraph Strategy
        Cap[Capability]
    end
    subgraph Business
        BS[Business Service]
        BP[Business Process]
        BO[Business Object]
        BA[Business Actor]
    end
    subgraph Application
        AS[Application Service]
        AF[Application Function]
        AI[Application Interface]
    end

    AS -->|realizes| BS
    BS -->|realizes| Cap
    AS -->|serves| BP
    AF -->|accesses| BO
    AI -->|serves| BA

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

    class Cap strategy
    class BS,BP,BO,BA business
    class AS,AF,AI application

These links are what enable: - Business-IT alignment — "Which application services realize which business services?" - Impact analysis — "If we change this application function, which business processes are affected?" - Capability mapping — "Which capabilities are supported by which application services?" - Data governance — "Which application functions access which business objects?" - Motivation traceability — "Which requirements are realized by which application services?"

C4 has no vocabulary for any of this. A C4 Container is a deployment unit. It doesn't distinguish between the service it exposes, the function it performs, the data it owns, and the interface through which consumers access it.

2. What C4 Containers and Components Actually Provide¶

C4 operates at a different level of concern:

C4 Concept	What it answers
Container	"What are the deployable/runnable units?" — APIs, web apps, databases, message brokers, workers
Component	"What are the major structural building blocks inside a container?" — modules, packages, logical groupings
Relationship labels	"How do they communicate?" — REST, gRPC, AMQP, SQL, with protocol and technology details

C4's strength is in the deployment and technology dimension: what runs where, what talks to what, using which protocol. It's technology-specific, maps directly to code repositories and deployment pipelines, and speaks the language of technical teams.

C4 does NOT answer: - What business services does this system realize? - What capabilities does it support? - What business processes depend on it? - What requirements drove its design? - What data objects does it govern?

3. The Guideline: Model by Concern, Not by Granularity¶

The distinction is not "coarse-grained = ArchiMate, fine-grained = C4." The distinction is what question you're answering.

Model in ArchiMate when the concern is...¶

Concern	ArchiMate Elements	Why
What services does this application expose to the business?	Application Service, Application Interface	These link via `realizes` to Business Services and via `serves` to Business Processes
What data does this application own or process?	Data Object	Links via `accesses` to Application Functions and via `realizes` to Business Objects
What behavior does this application perform?	Application Function, Application Process	Links via `realizes` to Application Services and via `serves` to Business Processes
How do applications collaborate?	Application Collaboration, Application Interaction	Models joint behavior across components
What events trigger or are produced by this application?	Application Event	Links to Application Processes via `triggers`
What capabilities does this application support?	Application Service → (realizes) → Business Service → (realizes) → Capability	Full traceability chain
What requirements does this application satisfy?	Application Service → (realizes) → Requirement	Motivation layer traceability

Model in C4 when the concern is...¶

Concern	C4 Elements	Why
What are the deployable units inside this system?	Containers	Maps to repos, build pipelines, deployment targets
What technology does each unit use?	Container technology annotations	"Spring Boot API", "React SPA", "PostgreSQL"
How do units communicate at the protocol level?	Relationship labels	"REST/JSON over HTTPS", "gRPC", "AMQP events"
What are the major modules inside a container?	Components	Maps to packages, modules, bounded contexts in code
How is this deployed to infrastructure?	Deployment diagrams	Maps containers to nodes, clusters, cloud services

The overlap zone — and how to handle it¶

The overlap is specifically at the level of "what applications/services exist." Both ArchiMate's Application Component and C4's Software System / Container answer this question, but from different angles:

Dimension	ArchiMate Application Component	C4 Container
Identity	Architectural identity — what it IS in the enterprise landscape	Deployment identity — what RUNS and where
Relationships	Formal typed relationships to business, strategy, technology	Labeled arrows with protocol details
Granularity	Can be coarse (a system) or fine (a module) via nesting	Always a deployable unit
Audience	Enterprise architects, business stakeholders, governance, audit/compliance, security reviewers	Software/solution architects, technical architects, development teams, team leads, ops, security reviewers

Rule: Model the same application in both, but model different things about it.

flowchart TD
    OM[Order Management<br/><i>Application Component</i>]
    OPS[Order Placement Service<br/><i>Application Service</i>]
    OQI[Order Query Interface<br/><i>Application Interface</i>]
    OV[Order Validation<br/><i>Application Function</i>]
    OE[Order Confirmed<br/><i>Application Event</i>]
    OD[Order<br/><i>Data Object</i>]

    BServ[Order Placement<br/><i>Business Service</i>]
    BCap[Order Fulfillment<br/><i>Capability</i>]
    BRole[Customer Service Agent<br/><i>Business Role</i>]
    BObj[Order<br/><i>Business Object</i>]
    BProc[Fulfillment Process<br/><i>Business Process</i>]

    OM -->|exposes| OPS
    OM -->|exposes| OQI
    OM -->|performs| OV
    OM -->|produces| OE
    OPS -->|realizes| BServ
    BServ -->|realizes| BCap
    OQI -->|serves| BRole
    OV -->|accesses| OD
    OD -->|realizes| BObj
    OE -->|triggers| BProc

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

    class BCap strategy
    class BServ,BRole,BObj,BProc business
    class OM,OPS,OQI,OV,OE,OD application

C4Container
    title Order Management — C4 Container Diagram (what it looks like to technical teams)

    Container(api, "Orders API", "Spring Boot, REST")
    Container(worker, "Orders Worker", "Spring Boot, AMQP consumer")
    Container(db, "Orders DB", "PostgreSQL")
    Container(bus, "Orders Event Bus", "RabbitMQ")

    Rel(api, db, "SQL")
    Rel(api, bus, "publishes events", "AMQP")
    Rel(bus, worker, "delivers to")

Both models describe the same system. Neither is redundant. They answer fundamentally different questions for different audiences.

4. Practical Patterns¶

Pattern 1: ArchiMate Application Service ↔ C4 Container API¶

An ArchiMate Application Service represents the externally visible behavior. A C4 Container tagged as an API represents the deployable unit that implements it.

flowchart LR
    OPS[Order Placement Service<br/><i>Application Service</i>]
    OM[Order Management<br/><i>Application Component</i>]
    OPS -->|realized by| OM

    classDef application fill:#B5D5FF,stroke:#4A90D9,color:#000
    class OPS,OM application

C4 equivalent:

C4Container
    Container(api, "Orders API", "Spring Boot REST API", "Exposes POST /orders, GET /orders/{id}")

Naming convention: Use the same base name. The ArchiMate service is "Order Placement Service." The C4 container is "Orders API." A naming mapping document or tag links them.

Pattern 2: ArchiMate Data Object ↔ C4 Container (data store)¶

An ArchiMate Data Object represents the logical data concept. A C4 Container of type database represents where it's physically stored.

flowchart LR
    OD[Order<br/><i>Data Object</i>]
    OV[Order Validation<br/><i>Application Function</i>]
    BO[Order<br/><i>Business Object</i>]
    OV -->|accesses| OD
    OD -->|realizes| BO

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

    class BO business
    class OD,OV application

C4 equivalent:

C4Container
    ContainerDb(db, "Orders DB", "PostgreSQL", "Stores order records, order line items, order status history")

Don't duplicate: ArchiMate models the logical data and its business meaning. C4 models the physical storage and its technology. Both are needed; neither replaces the other.

Pattern 3: ArchiMate Application Event ↔ C4 relationship label¶

ArchiMate models events as first-class elements that trigger processes. C4 captures the same information as relationship labels on message broker containers.

flowchart LR
    OE[Order Confirmed<br/><i>Application Event</i>]
    FI[Fulfillment Initiation<br/><i>Application Process</i>]
    OE -->|triggers| FI

    classDef application fill:#B5D5FF,stroke:#4A90D9,color:#000
    class OE,FI application

C4 equivalent:

C4Container
    Container(api, "Orders API", "Spring Boot", "Publishes events")
    Container(bus, "Orders Event Bus", "RabbitMQ", "Message broker")
    Container(worker, "Fulfillment Worker", "Spring Boot", "Processes fulfillment")

    Rel(api, bus, "publishes OrderConfirmed", "AMQP")
    Rel(bus, worker, "delivers to")

Pattern 4: ArchiMate for cross-application, C4 for intra-application¶

When modeling how multiple applications interact at the business level, use ArchiMate:

flowchart LR
    OM[Order Management<br/><i>Application Component</i>]
    FS[Fulfillment System<br/><i>Application Component</i>]
    BS[Billing System<br/><i>Application Component</i>]
    CM[Customer Master<br/><i>Data Object</i>]
    OPS[Order Placement Service<br/><i>Application Service</i>]
    BServ[Order Placement<br/><i>Business Service</i>]

    OM -->|serves| FS
    OM -->|serves| BS
    OM -->|accesses| CM
    OPS -->|realizes| BServ

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

    class BServ business
    class OM,FS,BS,CM,OPS application

When modeling what's inside Order Management, use C4:

C4Container
    title Order Management — Container Diagram

    Container(api, "Orders API", "Spring Boot", "REST API")
    Container(worker, "Orders Worker", "Spring Boot", "AMQP consumer")
    Container(db, "Orders DB", "PostgreSQL", "Order storage")
    Container(bus, "Event Bus", "RabbitMQ", "Async messaging")
    System_Ext(fulfillment, "Fulfillment API", "External")
    System_Ext(billing, "Billing Service", "External")

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

5. What NOT to Do¶

Don't model C4 containers as ArchiMate Application Components¶

If "Orders API", "Orders Worker", "Orders DB", and "Orders Event Bus" are all containers inside the Order Management system, don't create four ArchiMate Application Components for them. In ArchiMate, "Order Management" is the Application Component. The containers are deployment concerns, not architectural concepts at the enterprise level.

Exception: If a container has its own lifecycle, its own team, its own business service exposure, and its own governance — then it IS an Application Component in ArchiMate terms. A microservice that independently serves a business capability is both a C4 Container and an ArchiMate Application Component.

Don't model ArchiMate Application Services as C4 Components¶

An Application Service is a business-facing concept — "the ability to place an order." A C4 Component is a code-level structural element — "the OrderController class." They operate at different levels of abstraction. Don't try to force one into the other's model.

Don't skip ArchiMate's behavioral elements¶

The most common mistake is modeling only Application Components in ArchiMate and skipping Application Services, Application Functions, Application Processes, and Data Objects. This strips away the very elements that create cross-layer traceability. Without Application Services, you can't link to Business Services. Without Data Objects, you can't link to Business Objects. Without Application Functions, you can't show what accesses what.

Don't duplicate technology details in ArchiMate¶

ArchiMate's Application layer is deliberately technology-neutral. "Order Placement Service" doesn't say REST or gRPC — that's a Technology layer concern (or a C4 relationship label concern). Don't annotate ArchiMate Application Services with protocol details. Keep the layers clean.

6. Decision Matrix: Where to Model What¶

What you're modeling	ArchiMate	C4	Notes
Application exists in the landscape	✅ Application Component	✅ Software System	Same system, both models
Application exposes a service to the business	✅ Application Service	❌	C4 has no equivalent concept
Application has an API consumers call	✅ Application Interface	⚠️ Container or relationship label	C4 can approximate but lacks formal semantics
Application performs internal behavior	✅ Application Function / Process	⚠️ Component (loosely)	ArchiMate links to business; C4 links to code
Application owns/accesses data	✅ Data Object	✅ Container (database)	ArchiMate = logical; C4 = physical
Application produces/consumes events	✅ Application Event	⚠️ Relationship label	ArchiMate = first-class; C4 = annotation
Application is deployed as containers	❌	✅ Containers	Deployment is C4's strength
Application uses specific technology	⚠️ Technology layer	✅ Container annotations	ArchiMate separates layers; C4 embeds tech
Application realizes a business service	✅ Realization relationship	❌	C4 has no business layer
Application supports a capability	✅ Via realization chain	❌	C4 has no strategy layer
Application satisfies a requirement	✅ Realization to Requirement	❌	C4 has no motivation layer
Internal modules/packages of a container	❌	✅ Components	Below ArchiMate's concern
Protocol and technology of communication	❌	✅ Relationship labels	C4's strength
Deployment to infrastructure nodes	⚠️ Technology layer	✅ Deployment diagrams	Both can; C4 is more accessible for technical teams

✅ = primary/authoritative, ⚠️ = possible but not primary, ❌ = not in scope

7. Summary¶

ArchiMate's Application layer is not just "Application Component." It's a rich vocabulary of nine element types that model what an application means to the enterprise — what services it exposes, what data it governs, what behavior it performs, and how all of that connects to business processes, capabilities, goals, and requirements.

C4 models what an application looks like to technical teams — what runs where, using what technology, communicating how.

The two are complementary, not competing. The guideline is:

Model the architectural semantics (services, data, behavior, events) in ArchiMate. Model the deployment structure (containers, components, protocols) in C4. Connect them through consistent naming of the application/system they both describe.

8. How This Looks in Linked.Archi¶

The patterns above become concrete when both models live in the same knowledge graph. Here's the Order Management example expressed as Linked.Archi Turtle — ArchiMate semantics and C4 structure, side by side in RDF.

ArchiMate model (what it means to the enterprise)¶

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

:OrderManagement a am:ApplicationComponent ;
    skos:prefLabel "Order Management"@en .

:OrderPlacementService a am:ApplicationService ;
    skos:prefLabel "Order Placement Service"@en ;
    am:realizedBy :OrderManagement .

:OrderPlacement a am:BusinessService ;
    skos:prefLabel "Order Placement"@en ;
    am:realizedBy :OrderPlacementService .

:OrderFulfillment a am:Capability ;
    skos:prefLabel "Order Fulfillment"@en ;
    am:realizedBy :OrderPlacement .

:OrderValidation a am:ApplicationFunction ;
    skos:prefLabel "Order Validation"@en ;
    am:assignedTo :OrderManagement .

:OrderDataObject a am:DataObject ;
    skos:prefLabel "Order"@en ;
    am:accessedBy :OrderValidation .

:OrderConfirmed a am:ApplicationEvent ;
    skos:prefLabel "Order Confirmed"@en ;
    am:triggers :FulfillmentInitiation .

:FulfillmentInitiation a am:ApplicationProcess ;
    skos:prefLabel "Fulfillment Initiation"@en .

C4 model (what it looks like to technical teams)¶

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

:OrderManagementSystem a c4:SoftwareSystem ;
    skos:prefLabel "Order Management"@en .

:OrdersAPI a c4:Container ;
    skos:prefLabel "Orders API"@en ;
    c4:technology "Spring Boot" ;
    c4:partOf :OrderManagementSystem .

:OrdersDB a c4:Container ;
    skos:prefLabel "Orders DB"@en ;
    c4:technology "PostgreSQL" ;
    c4:partOf :OrderManagementSystem .

:OrdersWorker a c4:Container ;
    skos:prefLabel "Orders Worker"@en ;
    c4:technology "Spring Boot" ;
    c4:partOf :OrderManagementSystem .

:OrdersEventBus a c4:Container ;
    skos:prefLabel "Orders Event Bus"@en ;
    c4:technology "RabbitMQ" ;
    c4:partOf :OrderManagementSystem .

:OrdersAPI c4:uses :OrdersDB ;
    c4:protocol "SQL" .
:OrdersAPI c4:uses :OrdersEventBus ;
    c4:protocol "AMQP" .

The connection: same name, queryable together¶

Both models use skos:prefLabel "Order Management"@en. That's the glue. A SPARQL query can now answer questions neither model can answer alone:

# Which business capabilities depend on containers running on PostgreSQL?
PREFIX am:   <https://meta.linked.archi/archimate3/onto#>
PREFIX c4:   <https://meta.linked.archi/c4/onto#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>

SELECT ?capability ?capLabel ?container ?tech
WHERE {
  # C4 side: find containers with a specific technology
  ?container a c4:Container ;
             c4:technology "PostgreSQL" ;
             c4:partOf ?system .
  ?system skos:prefLabel ?sysLabel .

  # ArchiMate side: trace from Application Component to Capability
  ?amComp a am:ApplicationComponent ;
          skos:prefLabel ?sysLabel .
  ?service am:realizedBy ?amComp .
  ?bizService am:realizedBy ?service .
  ?capability am:realizedBy ?bizService ;
              skos:prefLabel ?capLabel .
}

SHACL: validate that Application Services have business traceability¶

This shape ensures architects don't skip the cross-layer links that make ArchiMate valuable:

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

:ApplicationServiceMustRealizeBusinessService
    a sh:NodeShape ;
    sh:targetClass am:ApplicationService ;
    sh:property [
        sh:path am:realizes ;
        sh:minCount 1 ;
        sh:class am:BusinessService ;
        sh:message "Application Service '{?this}' does not realize any Business Service — cross-layer traceability is missing." ;
    ] .

This is what "model the architectural semantics in ArchiMate" means in practice: not just drawing boxes, but creating typed, validated, queryable knowledge that connects business intent to technical implementation.

References¶

Linked.Archi — This Repository¶

Design API Interfaces in C4 — Mapping API concepts across both notations
C4/Structurizr and ArchiMate — Practitioner's Guide — The parent comparison document
ArchiMate Ontology — Application Layer Elements

Original Sources¶

Application Architecture Modeling with ArchiMate — Hosiaisluoma

Guideline: Modeling Application Internals — ArchiMate Application Layer vs C4 Containers¶

Context¶

1. What ArchiMate's Application Layer Actually Provides¶

The cross-layer power¶

2. What C4 Containers and Components Actually Provide¶

3. The Guideline: Model by Concern, Not by Granularity¶

Model in ArchiMate when the concern is...¶

Model in C4 when the concern is...¶

The overlap zone — and how to handle it¶

4. Practical Patterns¶

Pattern 1: ArchiMate Application Service ↔ C4 Container API¶

Pattern 2: ArchiMate Data Object ↔ C4 Container (data store)¶

Pattern 3: ArchiMate Application Event ↔ C4 relationship label¶

Pattern 4: ArchiMate for cross-application, C4 for intra-application¶

5. What NOT to Do¶

Don't model C4 containers as ArchiMate Application Components¶

Don't model ArchiMate Application Services as C4 Components¶

Don't skip ArchiMate's behavioral elements¶

Don't duplicate technology details in ArchiMate¶

6. Decision Matrix: Where to Model What¶

7. Summary¶

8. How This Looks in Linked.Archi¶

ArchiMate model (what it means to the enterprise)¶

C4 model (what it looks like to technical teams)¶

The connection: same name, queryable together¶

SHACL: validate that Application Services have business traceability¶

References¶

Linked.Archi — This Repository¶

Original Sources¶

Related Work¶