Deployment Modeling: ArchiMate Technology Layer vs C4 Deployment Views vs Backstage¶

Purpose¶

This document compares how ArchiMate (specifically the Technology layer and its cross-layer relationships), C4/Structurizr (deployment diagrams), and Backstage (Resource entities) model the deployment and infrastructure dimension of software architecture. It examines what each can express, what each cannot, and how they relate to each other.

1. What Each Model Provides for Deployment¶

1.1 ArchiMate Technology Layer — 13 element types, full cross-layer semantics¶

ArchiMate's Technology layer is a complete infrastructure modeling vocabulary organized by the same three-aspect structure (Active Structure, Behavior, Passive Structure) as every other ArchiMate layer:

Aspect	Element	Definition
Active Structure	Node	A computational or physical resource that hosts, manipulates, or interacts with other resources. The primary structural element. Can be composed of sub-nodes.
Active Structure	Device	A physical IT resource upon which system software and artifacts may be deployed. A specialization of Node.
Active Structure	System Software	Software that provides or contributes to an environment for running other software. OS, middleware, DBMS, container runtime. A specialization of Node.
Active Structure	Technology Collaboration	A temporary configuration of two or more nodes working together to perform collective technology behavior.
Active Structure	Technology Interface	A point of access where technology services are made available to the environment. Ports, APIs, protocols.
Active Structure	Path	A link between two or more nodes through which they can exchange data or material.
Active Structure	Communication Network	A set of structures that connects nodes for transmission, routing, and reception.
Behavior	Technology Function	A collection of technology behavior that can be performed by a node.
Behavior	Technology Process	A sequence of technology behaviors that achieves a specific result.
Behavior	Technology Interaction	A unit of technology behavior performed by a collaboration of two or more nodes.
Behavior	Technology Event	A technology state change.
Behavior	Technology Service	An explicitly defined piece of technology functionality exposed to the environment.
Passive Structure	Artifact	A piece of data that is used or produced in a software development process, or by deployment and operation of an IT system. Deployed on nodes.

Additionally, ArchiMate's Physical layer extends the Technology layer with four elements for modeling the physical world:

Element	Definition
Equipment	Physical machines, tools, or instruments that can create, use, store, move, or transform materials.
Facility	A physical structure or environment (data center, building, office).
Distribution Network	A physical network for transporting materials or energy.
Material	Tangible physical matter or energy.

Total: 17 element types for infrastructure and physical modeling.

1.2 C4/Structurizr Deployment — 2 element types, container-to-node mapping¶

C4's deployment vocabulary is deliberately minimal:

Element	Definition
DeploymentNode	A physical or virtual infrastructure element — server, VM, container host, cloud instance, Kubernetes cluster, AWS region, availability zone. Can be nested.
InfrastructureNode	A specialization of DeploymentNode for specific infrastructure components — load balancer, firewall, DNS, CDN.

Plus two instance types (in Structurizr, not in the abstract C4 model):

Concept	Definition
ContainerInstance	An instance of a Container deployed on a DeploymentNode.
SoftwareSystemInstance	An instance of a SoftwareSystem deployed on a DeploymentNode.

And one structural concept:

Concept	Definition
DeploymentEnvironment	A named environment (Development, Staging, Production) that scopes a set of deployment nodes and instances.

Total: 2 element types + 2 instance types + 1 environment concept.

The Structurizr DSL expresses deployment as:

production = deploymentEnvironment "Production" {
    deploymentNode "AWS" {
        deploymentNode "eu-west-1" {
            deploymentNode "EKS Cluster" "" "Kubernetes" {
                deploymentNode "Pod" "" "Docker" {
                    containerInstance webapp
                }
            }
            deploymentNode "RDS" "" "Amazon RDS" {
                containerInstance database
            }
        }
    }
}

1.3 Backstage — 1 element type, no deployment topology¶

Backstage's deployment-related vocabulary:

Element	Definition
Resource	A physical or virtual infrastructure resource needed to operate a component — database, S3 bucket, Kafka cluster, external SaaS service.

That's it. Backstage has no concept of: - Deployment nodes or infrastructure topology - Where components run - Network paths between nodes - Deployment environments (dev, staging, production) - Container instances or replicas

Backstage knows that a component uses a resource (usesResource). It does not know where either the component or the resource runs.

2. Side-by-Side Vocabulary Comparison¶

Infrastructure Concept	ArchiMate	C4 / Structurizr	Backstage
Physical server	`Device`	`DeploymentNode`	—
Virtual machine	`Node`	`DeploymentNode`	—
Container host / K8s cluster	`Node` (composed of `System Software`)	`DeploymentNode` (nested)	—
Operating system	`System Software`	`DeploymentNode` (annotation)	—
Middleware / runtime	`System Software`	`DeploymentNode` (annotation)	—
Database engine	`System Software`	`DeploymentNode` (annotation)	—
Database instance	`Node` + `System Software`	`DeploymentNode` + `ContainerInstance`	`Resource`
Message broker	`Node` + `System Software`	`DeploymentNode`	`Resource`
Object storage (S3)	`Node`	`DeploymentNode` or `InfrastructureNode`	`Resource`
Load balancer	`Node` or `Device`	`InfrastructureNode`	—
Firewall	`Node` or `Device`	`InfrastructureNode`	—
CDN	`Node`	`InfrastructureNode`	—
Network / VPC	`Communication Network`	`DeploymentNode` (nested, by convention)	—
Network path	`Path`	Relationship between `DeploymentNode`s	—
Network interface / port	`Technology Interface`	—	—
Data center / region	`Facility` (Physical layer) + `Location`	`DeploymentNode` (top-level nesting)	—
Availability zone	`Location` or nested `Node`	`DeploymentNode` (nested)	—
Deployment environment	Custom property or `Plateau`	`DeploymentEnvironment` (first-class)	—
Deployed artifact	`Artifact`	`ContainerInstance`	—
Software deployed on node	`Artifact` assigned to `Node`	`ContainerInstance` inside `DeploymentNode`	—
Technology service exposed	`Technology Service`	— (relationship label)	—
Technology behavior	`Technology Function`, `Technology Process`	—	—
Technology event	`Technology Event`	—	—
Physical equipment	`Equipment`	—	—
Physical facility	`Facility`	—	—
Physical network	`Distribution Network`	—	—

3. What ArchiMate's Technology Layer Can Express That C4 and Backstage Cannot¶

3.1 Typed infrastructure elements¶

ArchiMate distinguishes between a Device (physical hardware), System Software (OS, middleware, DBMS), and Node (a logical composition of both). C4 has only DeploymentNode for all of these. Backstage has nothing.

This matters when you need to answer: - "Which physical devices run in our data center?" — ArchiMate: query for Device instances. C4: all deployment nodes look the same. - "Which middleware versions are we running?" — ArchiMate: query for System Software instances. C4: buried in deployment node descriptions. - "What operating systems are in our estate?" — ArchiMate: System Software with type annotation. C4: free-text annotation on deployment nodes.

3.2 Technology behavior and services¶

ArchiMate models what infrastructure does, not just what it is:

flowchart TD
    K8s["Kubernetes Cluster (Node)"]
    CO["Container Orchestration<br/>(Technology Function)"]
    PSE["Pod Scaling Event<br/>(Technology Event)"]
    SD["Service Discovery<br/>(Technology Function)"]
    SM["Service Mesh<br/>(Technology Service)"]
    API["Cluster API<br/>(Technology Interface)"]
    DP["Deployment Pipeline<br/>(Application Process)"]

    K8s -->|"assigned to"| CO
    CO -->|"triggers"| PSE
    K8s -->|"assigned to"| SD
    SD -->|"realizes"| SM
    K8s -->|"exposes"| API
    API -->|"serves"| DP

C4 deployment diagrams show only structure — what runs where. They cannot express what the infrastructure does (functions, processes), what events it produces, or what services it exposes.

3.3 Communication networks and paths¶

ArchiMate has dedicated elements for network topology:

flowchart LR
    CN["Corporate Network<br/>(Communication Network)"]
    VPN["VPN Tunnel (Path)"]
    VPC["Cloud VPC<br/>(Communication Network)"]
    IL["Internet Link (Path)"]
    CDN["CDN (Node)"]
    AS["Application Server (Node)"]
    TI["Technology Interface:<br/>HTTPS Port 443"]
    WA["Web Application<br/>(Application Component)"]

    CN -->|"path"| VPN --> VPC
    CN -->|"path"| IL --> CDN
    AS --> TI -->|"serves"| WA

C4 models network topology only through nesting of deployment nodes (e.g., a "VPC" deployment node containing other nodes) and relationship labels. There are no dedicated network or path elements.

3.4 Cross-layer relationships — the critical differentiator¶

This is where ArchiMate's Technology layer becomes fundamentally different from C4's deployment view. ArchiMate's Technology layer doesn't exist in isolation — it connects to the Application and Business layers through formal relationships:

flowchart TD
    subgraph strategy["Strategy Layer"]
        Cap["Capability: High Availability"]
    end
    subgraph business["Business Layer"]
        BS["Business Service: 24/7 Order Processing"]
    end
    subgraph application["Application Layer"]
        AS["Application Service: Order Placement"]
        AC["Application Component: Order Management"]
    end
    subgraph technology["Technology Layer"]
        EKS["Node: EKS Production Cluster"]
        EC2["Device: EC2 m5.xlarge (×3)"]
        K8s["System Software: Kubernetes 1.28"]
        CO["Technology Function: Container Orchestration"]
        CP["Technology Service: Compute Platform"]
        VPC["Communication Network: Production VPC"]
        RDS["Node: RDS Multi-AZ"]
        PG["System Software: PostgreSQL 15"]
    end

    Cap -->|"realized by"| BS
    BS -->|"realized by"| AS
    AS -->|"realized by"| AC
    AC -->|"assigned to"| EKS
    EKS -->|"composed of"| EC2 & K8s
    EKS -->|"assigned to"| CO
    CO -->|"realizes"| CP
    CP -->|"serves"| AC
    EKS -->|"path"| VPC
    VPC -->|"path"| RDS
    RDS -->|"composed of"| PG
    PG -->|"serves"| AC

This full chain — from business capability through application service to technology infrastructure — enables questions that neither C4 nor Backstage can answer:

Question	ArchiMate	C4	Backstage
"Which business capabilities are at risk if this server fails?"	✅ Trace: Node → Application Component → Application Service → Business Service → Capability	❌	❌
"What technology services support the Order Placement capability?"	✅ Technology Service → serves → Application Component → realizes → Application Service → realizes → Business Service → realizes → Capability	❌	❌
"Which infrastructure changes require a business impact assessment?"	✅ Any Technology layer change can be traced upward	❌	❌
"What is the full technology stack supporting this business process?"	✅ Business Process → served by → Application Service → realized by → Application Component → assigned to → Node → composed of → Device + System Software	❌	❌

3.5 Physical layer integration¶

ArchiMate's Physical layer extends the Technology layer for modeling the physical world:

flowchart TD
    F["Facility: Frankfurt Data Center"]
    E["Equipment: Server Rack A1"]
    D["Device: Dell PowerEdge R750"]
    SS["System Software: VMware ESXi 8"]
    N["Node: VM-Prod-01"]
    DN["Distribution Network: Power Grid"]

    F -->|"contains"| E
    E -->|"contains"| D
    D -->|"composed of"| SS
    SS -->|"composed of"| N
    F -->|"connected via"| DN

Neither C4 nor Backstage can model physical facilities, equipment, or distribution networks. For organizations with on-premises infrastructure, co-location facilities, or IoT/OT environments, this is essential.

4. What C4 Deployment Views Can Express That ArchiMate Handles Differently¶

4.1 Deployment environments as first-class concepts¶

Structurizr has a dedicated deploymentEnvironment concept that scopes deployment nodes and container instances to a named environment (Development, Staging, Production, DR). You can define multiple environments and generate separate deployment diagrams for each.

ArchiMate has no native "environment" concept. You model environments using: - Plateau elements from the Implementation & Migration layer (representing a state of the architecture at a point in time) - Location elements (representing physical or logical locations) - Custom properties or tags on Technology layer elements - Separate views filtered by environment

C4's approach is simpler and more developer-friendly. ArchiMate's approach is more flexible but requires modeling conventions.

4.2 Container instances (replicas)¶

Structurizr explicitly models ContainerInstance — an instance of a Container deployed on a specific node. This allows showing that the same container is deployed multiple times (e.g., 3 replicas of a web application behind a load balancer, or the same service deployed in both production and DR).

ArchiMate models this via Artifact (the deployed software) assigned to Node (the infrastructure). Multiple deployments of the same application component are modeled as multiple artifacts or multiple assignment relationships. It works but is less intuitive than C4's instance concept.

4.3 Developer-readable deployment topology¶

A C4 deployment diagram in Structurizr DSL is immediately readable by any developer:

production = deploymentEnvironment "Production" {
    deploymentNode "AWS" "" "Amazon Web Services" {
        deploymentNode "eu-west-1" "" "AWS Region" {
            deploymentNode "EKS" "" "Kubernetes 1.28" {
                deploymentNode "orders-pod" "" "Docker" instances 3 {
                    containerInstance ordersAPI
                }
            }
            deploymentNode "RDS" "" "Amazon RDS" {
                deploymentNode "Multi-AZ" "" "PostgreSQL 15" {
                    containerInstance ordersDB
                }
            }
            infrastructureNode "ALB" "" "Application Load Balancer"
        }
    }
}

The equivalent ArchiMate model requires knowledge of Node, Device, System Software, Artifact, Assignment, Composition, and the visual notation. It's more precise but less accessible.

5. What Backstage Provides — And What It Doesn't¶

5.1 What Backstage's Resource concept captures¶

Backstage's Resource is a deliberately simple concept: "infrastructure needed to operate a component." It captures:

What exists: A PostgreSQL database, an S3 bucket, a Kafka cluster, an external SaaS API
Who uses it: Component → usesResource → Resource
Who owns it: Resource → ownedBy → Group
What domain it belongs to: Resource → belongsToDomain → Domain

5.2 What Backstage cannot express¶

Concern	Backstage Capability
Where does this resource run?	❌ No deployment topology
What physical hardware hosts it?	❌ No physical modeling
What network connects it to consumers?	❌ No network modeling
What technology stack does it use?	❌ No system software / middleware modeling
What technology services does it expose?	❌ No technology behavior modeling
How many instances/replicas exist?	❌ No instance concept
Which environment is it in?	❌ No environment concept
What business capabilities depend on it?	❌ No cross-layer traceability

Backstage's Resource is an inventory entry, not a deployment model. It answers "what infrastructure exists and who owns it?" but not "where does it run, how is it configured, and what depends on it at the business level?"

6. Modeling the Same System in All Three¶

Consider an Order Management system deployed on AWS with a Kubernetes cluster, a managed database, and a load balancer.

6.1 ArchiMate — Full architectural semantics¶

flowchart TD
    subgraph biz["Business Layer"]
        BizSvc["Business Service: Order Fulfillment"]
    end
    subgraph app["Application Layer"]
        AppSvc["Application Service: Order Placement"]
        OM["Application Component: Order Management"]
        API["Application Component: Orders API"]
        DB["Application Component: Orders DB"]
    end
    subgraph tech["Technology Layer"]
        Facility["Facility: AWS eu-west-1 (Physical)"]
        EKS["Node: EKS Production Cluster"]
        K8s["System Software: Kubernetes 1.28"]
        Docker["System Software: Docker Runtime"]
        CO["Technology Function: Container Orchestration"]
        CP["Technology Service: Compute Platform"]
        Pod["Node: orders-pod (×3)"]
        Art["Artifact: orders-api:v2.3.1"]
        RDS["Node: RDS Multi-AZ Instance"]
        PG["System Software: PostgreSQL 15"]
        HW["Device: db.r6g.xlarge"]
        DP["Technology Function: Data Persistence"]
        MDB["Technology Service: Managed Database"]
        Schema["Artifact: orders-schema"]
        ALB["Node: Application Load Balancer"]
        HTTPS["Technology Interface: HTTPS :443"]
        VPC["Communication Network: Production VPC"]
    end

    BizSvc -->|"realized by"| AppSvc
    AppSvc -->|"realized by"| OM
    OM -->|"composed of"| API & DB
    Facility -->|"contains"| EKS & RDS & ALB
    EKS -->|"composed of"| K8s & Docker
    EKS -->|"assigned to"| CO -->|"realizes"| CP
    EKS -->|"contains"| Pod -->|"contains"| Art -->|"realizes"| API
    RDS -->|"composed of"| PG & HW
    RDS -->|"assigned to"| DP -->|"realizes"| MDB
    RDS -->|"contains"| Schema -->|"realizes"| DB
    ALB --> HTTPS -->|"serves"| API
    VPC ---|"Path: orders-pod ↔ RDS"| RDS

What this enables: Full traceability from "Order Fulfillment" business service down to "db.r6g.xlarge" hardware instance. Impact analysis in both directions. Technology service catalog. Physical facility mapping.

6.2 C4/Structurizr — Developer-readable deployment topology¶

production = deploymentEnvironment "Production" {
    deploymentNode "AWS" "" "Amazon Web Services" {
        deploymentNode "eu-west-1" "" "AWS Region" {
            deploymentNode "EKS Cluster" "" "Kubernetes 1.28" {
                deploymentNode "orders-pod" "" "Docker" instances 3 {
                    containerInstance ordersAPI
                }
            }
            deploymentNode "RDS" "" "Amazon RDS" {
                deploymentNode "Multi-AZ" "" "PostgreSQL 15" {
                    containerInstance ordersDB
                }
            }
            infrastructureNode "ALB" "" "Application Load Balancer"
        }
    }
}

What this enables: Clear visual diagram showing where each container runs. Environment-specific views (dev vs staging vs production). Readable by any developer in 30 seconds. Version-controlled in Git.

What this cannot express: No link to business services or capabilities. No technology behavior (what the infrastructure does). No network topology beyond nesting. No physical facility modeling.

6.3 Backstage — Operational inventory¶

# catalog-info.yaml for Orders API
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: orders-api
spec:
  type: service
  lifecycle: production
  owner: orders-team
  system: order-management
  consumesApis:
    - orders-openapi
  dependsOn:
    - resource:orders-db
    - resource:orders-kafka
---
apiVersion: backstage.io/v1alpha1
kind: Resource
metadata:
  name: orders-db
spec:
  type: database
  owner: platform-team
  system: order-management
---
apiVersion: backstage.io/v1alpha1
kind: Resource
metadata:
  name: orders-kafka
spec:
  type: message-broker
  owner: platform-team

What this enables: "Orders API depends on orders-db and orders-kafka." "Platform team owns the database." "Orders API is in production lifecycle." Searchable, browsable catalog.

What this cannot express: Where any of this runs. What hardware, what region, what Kubernetes cluster. No deployment topology at all. No business traceability.

7. The Expressiveness Gap¶

flowchart TD
    Full["Full deployment semantics"]
    AM["<b>ArchiMate Technology + Physical layers</b><br/>17 element types, 11 relationship types,<br/>cross-layer traceability, physical modeling,<br/>technology behavior, network topology"]
    C4D["<b>C4 Deployment diagrams</b><br/>2 element types, environments, instances,<br/>developer-readable, version-controlled"]
    BS["<b>Backstage Resources</b><br/>1 element type, ownership, lifecycle,<br/>no topology, no deployment"]
    Min["Minimal deployment semantics"]

    Full --- AM --- C4D --- BS --- Min

7.1 What each adds over the one below¶

Step up	What you gain
Backstage → C4	Deployment topology (where things run), environments (dev/staging/prod), infrastructure nodes (load balancers, firewalls), container instances (replicas), visual diagrams
C4 → ArchiMate	Typed infrastructure elements (Device vs System Software vs Node), technology behavior (functions, processes, events, services), network topology (Communication Network, Path, Technology Interface), physical modeling (Facility, Equipment), cross-layer traceability to Application and Business layers, formal relationship semantics (11 types vs 1)

7.2 What each sacrifices compared to the one above¶

Step down	What you lose	What you gain
ArchiMate → C4	Cross-layer traceability, typed infrastructure, technology behavior, network elements, physical modeling, formal relationships	Developer readability, "as code" workflow, environment-first modeling, 30-second comprehension
C4 → Backstage	Deployment topology, environments, visual diagrams, infrastructure nodes	Auto-discovery, always-current inventory, ownership, lifecycle, API-centric view

8. When to Use Which¶

Scenario	Recommended Approach
"Show a developer where their service runs"	C4 deployment diagram
"Track what infrastructure exists and who owns it"	Backstage Resources
"Analyze business impact of an infrastructure failure"	ArchiMate (Technology → Application → Business traceability)
"Document the production deployment for a specific system"	C4 deployment diagram (per environment)
"Model the enterprise infrastructure landscape"	ArchiMate Technology layer
"Map physical data centers and equipment"	ArchiMate Physical layer
"Understand network topology and communication paths"	ArchiMate (Communication Network, Path, Technology Interface)
"Track technology services exposed by infrastructure"	ArchiMate (Technology Service, Technology Function)
"Ensure every component has a known infrastructure dependency"	Backstage (Resource + usesResource)
"Compare deployment across dev/staging/production"	C4 (DeploymentEnvironment with separate views)
"Audit which middleware versions are in the estate"	ArchiMate (System Software instances)
"Answer 'if this Kubernetes cluster goes down, which business processes are affected?'"	ArchiMate only (cross-layer trace)

9. Integration Strategy — Using All Three Together¶

9.1 Ownership boundaries¶

Concern	Owner	Model
Enterprise infrastructure landscape (all platforms, networks, data centers)	Enterprise / Infrastructure Architect	ArchiMate Technology + Physical layers
Technology-to-business traceability	Enterprise Architect	ArchiMate cross-layer relationships
Per-system deployment topology (where my containers run)	Solution Architect / DevOps	C4 deployment diagrams
Runtime infrastructure inventory (what exists, who owns it)	Platform Engineering	Backstage Resources

9.2 Integration points in the Linked.Archi knowledge graph¶

ArchiMate Technology Layer          C4 Deployment              Backstage
─────────────────────────          ──────────────              ─────────

am:Node "EKS Cluster"  ◄─────────► c4:DeploymentNode          
                                    "EKS Cluster"              

am:SystemSoftware       ◄── (no    c4:DeploymentNode           
"PostgreSQL 15"             direct  "PostgreSQL 15"            bs:Resource
                            map,    (annotation)               "orders-db"
                            align                              (type: database)
                            by name)

am:Node "RDS Instance"  ◄─────────► c4:DeploymentNode  ◄─────► bs:Resource
                                    "RDS"                      "orders-db"

The integration rule: ArchiMate owns the semantic identity of infrastructure (what it IS, what it DOES, how it connects to business). C4 owns the deployment view (where containers run, per environment). Backstage owns the operational inventory (what exists, who owns it, what lifecycle state).

9.3 SPARQL query across all three¶

PREFIX am:   <https://meta.linked.archi/archimate3/onto#>
PREFIX c4:   <https://meta.linked.archi/c4/onto#>
PREFIX bs:   <https://meta.linked.archi/backstage/onto#>
PREFIX arch: <https://meta.linked.archi/core#>

# For a given Backstage resource, find:
# - The C4 deployment node it maps to
# - The ArchiMate technology service it realizes
# - The business service ultimately affected

SELECT ?bsResource ?c4Node ?amTechService ?amBizService
WHERE {
    ?bsResource a bs:Resource ;
                skos:prefLabel ?name .

    ?c4Node a c4:DeploymentNode ;
            skos:prefLabel ?name .

    ?amNode a am:Node ;
            skos:prefLabel ?name ;
            am:assignedTo ?amTechFunc .
    ?amTechFunc am:realizes ?amTechService .
    ?amTechService am:serves ?amAppComp .
    ?amAppComp am:realizes ?amAppService .
    ?amAppService am:realizes ?amBizService .
}

10. Summary¶

Dimension	ArchiMate Technology Layer	C4 Deployment	Backstage Resources
Element types	17 (13 Technology + 4 Physical)	2 + instances	1
Relationship types	11 formal types	1 (`deployedOn`) + nesting	1 (`usesResource`)
Infrastructure typing	Device, System Software, Node (distinct)	DeploymentNode (generic)	Resource (generic)
Network modeling	Communication Network, Path, Technology Interface	Nesting convention	—
Physical modeling	Facility, Equipment, Distribution Network, Material	—	—
Technology behavior	Technology Function, Process, Interaction, Event, Service	—	—
Deployment environments	Convention-based	First-class (`DeploymentEnvironment`)	—
Container instances	Artifact → assigned to → Node	`ContainerInstance` (first-class)	—
Ownership	Custom property	—	`ownedBy` (first-class)
Lifecycle	Custom property or I&M layer	—	`lifecycle` (first-class)
Cross-layer traceability	Full (Technology → Application → Business → Strategy)	—	—
Developer readability	Requires training	Immediate	Immediate (YAML)
Version control	Possible (XML/RDF export)	Native (DSL in Git)	Native (YAML in Git)
Auto-discovery	Manual modeling	Manual (DSL)	Auto-discovered + YAML

ArchiMate's Technology layer is an order of magnitude richer than C4's deployment vocabulary, which is in turn richer than Backstage's Resource concept. But richness and adoption are inversely correlated. The practical answer is to use all three at their appropriate scope: ArchiMate for enterprise infrastructure architecture and business traceability, C4 for per-system deployment documentation, and Backstage for runtime inventory and ownership.

References¶

ArchiMate 3.2 Specification — Technology Layer — The Open Group
ArchiMate 3.2 Specification — Relationships Between Core Layers — Cross-layer semantics
ArchiMate Patterns — Technology Layer — Practical patterns
Modeling Technology Architecture with ArchiMate — Nilus guide
ArchiMate Technology Layer Concepts — Archimetric
Structurizr — Deployment View — Official Structurizr deployment documentation
Structurizr — AWS Deployment — Cloud deployment example
Structurizr — Deployment Groups — Multi-instance deployment
Backstage System Model — Official Backstage entity model
C4 Ontology — Linked.Archi C4 metamodel
Backstage Ontology — Linked.Archi Backstage metamodel
ArchiMate Ontology — Linked.Archi ArchiMate metamodel
Backstage as C4 Complement or Replacement — Broader Backstage vs C4 comparison
ArchiMate Application Layer vs C4 Containers — Application layer comparison