Skip to content

Part of a trilogy. This is article 2 of 3 — the strategic "what/when." Previous: Diagramming Approach Meets Modeling Language (philosophical "why"). Next: Application Layer vs C4 Containers (tactical "how"). See reading guide.

C4/Structurizr and ArchiMate — A Practitioner's Guide

Before you start

This guide assumes you've decided to use both C4 and ArchiMate. If you're still deciding whether to use both — or whether they're even comparable — start with the reading guide, which includes the trilogy's first article on the underlying debate.

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.

Purpose of This Document

This guide helps architecture practices make informed decisions about when and how to use the C4 model (and its primary tooling, Structurizr) versus ArchiMate. It covers what each is, where each excels, how to choose, and — critically — how to use both without duplicating effort or creating inconsistency.

1. What Are They?

1.1 The C4 Model & Structurizr

The C4 model, created by Simon Brown, is a lightweight, hierarchical approach for visualizing the static structure of software systems. The name stands for the four zoom levels it defines:

Level Name Audience Shows
1 System Context Everyone The system in scope, its users, and neighboring systems
2 Container Developers + architects Deployable units inside the system — APIs, apps, databases, queues
3 Component Developers Logical modules inside a single container
4 Code Developers (optional) Classes, interfaces, functions

In addition to the four core levels, C4 defines supplementary diagram types: System Landscape (all systems in the enterprise), Dynamic (runtime interactions for a scenario), and Deployment (mapping containers to infrastructure nodes).

C4 is notation-independent — you can draw C4 diagrams with boxes and arrows, PlantUML, draw.io, or any tool. However, the most common tooling is Structurizr, which implements a "models as code" approach via the Structurizr DSL. You define a single model in a text file, and Structurizr generates multiple diagram views from it. The DSL files live in Git, are version-controlled, and can be reviewed in pull requests — making architecture a first-class citizen in the development workflow.

Key characteristics: - Focused on software architecture (the structure of a single system or a small set of systems) - Designed for developer-friendly communication — fast onboarding, shared mental models - Minimal vocabulary: Person, Software System, Container, Component, Code element - Notation-independent but commonly rendered via Structurizr - "Architecture as code" — models live alongside source code in Git - No formal standard body; community-driven, created by Simon Brown

Sources: c4model.com, structurizr.com, Structurizr DSL docs

1.2 ArchiMate

ArchiMate is an open standard (maintained by The Open Group) for enterprise architecture modeling. It provides a formal visual language with a defined set of element types, relationship types, and viewpoints for describing, analyzing, and communicating enterprise architectures across business, application, technology, strategy, motivation, and implementation layers.

ArchiMate 3.2 defines:

Aspect Content
Layers Strategy, Motivation, Business, Application, Technology, Physical, Implementation & Migration
Elements 62 element types (e.g., Business Process, Application Component, Node, Capability, Goal)
Relationships 11 relationship types (Composition, Aggregation, Assignment, Realization, Serving, Access, Influence, Triggering, Flow, Specialization, Association)
Viewpoints 23+ predefined viewpoints targeting specific stakeholder concerns
Derivation rules Formal rules for deriving implicit relationships from explicit ones

ArchiMate is designed for enterprise-wide architecture — it models not just software systems but the entire landscape of business capabilities, organizational structures, technology infrastructure, strategic goals, and migration plans.

Key characteristics: - Covers the full enterprise architecture scope — from strategy and motivation to physical infrastructure - Formal standard with precise semantics for every element and relationship type - Rich relationship semantics — 11 types with defined valid source/target combinations - Viewpoint mechanism for stakeholder-specific communication - Supported by dedicated EA tools (Archi, Sparx EA, BiZZdesign, LeanIX, MEGA) - Aligned with TOGAF and ISO/IEC/IEEE 42010 - Steeper learning curve; requires training for effective use

Sources: ArchiMate 3.2 Specification, The Open Group

2. Side-by-Side Comparison

Dimension C4 / Structurizr ArchiMate
Scope Software architecture (one system or a small landscape) Enterprise architecture (strategy → business → application → technology → migration)
Abstraction levels 4 hierarchical zoom levels (Context → Container → Component → Code) 7 layers × 3 aspects, plus cross-cutting concerns
Element vocabulary ~5 types (Person, Software System, Container, Component, Code element) 62 element types across 7 layers
Relationship vocabulary Informal — labeled arrows ("Uses", "Reads from") 11 formal types with defined semantics and valid source/target rules
Viewpoints Implicit (each zoom level is a viewpoint) 23+ explicit viewpoints with defined stakeholder, concern, and element scope
Formality Lightweight, convention-based Formal standard (The Open Group)
Learning curve Low — a developer can be productive in hours Moderate to high — effective use requires training (days to weeks)
Primary audience Solution architects, technical architects, development teams, team leads Enterprise architects, governance boards, cross-domain stakeholders
Tooling model "Architecture as code" (DSL in Git, CI/CD integration) GUI-based modeling tools (Archi, Sparx EA, BiZZdesign)
Version control Native — DSL files in Git Possible but not native; depends on tool export formats
Governance Lightweight — team conventions Heavy — formal viewpoints, derivation rules, SHACL validation
Business modeling Not covered Rich — business processes, capabilities, value streams, motivation
Strategy & motivation Not covered Native — goals, drivers, principles, requirements, assessments
Deployment modeling Supplementary deployment diagrams Technology layer with nodes, devices, paths, communication networks
Standards alignment None (community practice) ISO 42010, TOGAF, The Open Group
Typical artifact lifespan Weeks to months (evolves with code) Months to years (evolves with enterprise strategy)

3. Purpose and Capabilities — Where Each Excels

3.1 C4/Structurizr Excels At

  1. Developer onboarding — A new team member can understand the system structure in minutes by reading Context → Container → Component diagrams.

  2. Solution design sessions — Whiteboard-friendly abstractions that developers and architects can sketch together without learning a formal notation.

  3. Living documentation — Structurizr DSL files in Git evolve with the codebase. Pull requests that change architecture also update the model.

  4. CI/CD integration — Structurizr can validate models, generate diagrams, and publish them as part of the build pipeline.

  5. Microservices and distributed systems — The Container level maps naturally to services, databases, message brokers, and API gateways.

  6. API design communication — Relationship labels carry protocol and technology details ("REST/JSON over HTTPS", "gRPC", "AMQP events").

  7. Cross-team alignment on system boundaries — The System Context diagram is one of the most effective artifacts for aligning product owners, developers, and architects on what a system does and what it depends on.

3.2 ArchiMate Excels At

  1. Enterprise-wide landscape modeling — Mapping hundreds of applications, their business capabilities, technology platforms, and interdependencies.

  2. Business-IT alignment — Connecting strategic goals and business capabilities to the applications and technology that realize them.

  3. Impact analysis — Formal relationships and derivation rules enable tracing how a change in one layer propagates to others (e.g., "if we decommission this platform, which business processes are affected?").

  4. Architecture governance — Viewpoints, principles, and formal validation rules ensure models conform to organizational standards.

  5. Migration planning — The Implementation & Migration layer models plateaus, gaps, work packages, and transition architectures.

  6. Regulatory compliance — Formal traceability from requirements through architecture to implementation supports audit and compliance reporting.

  7. Multi-stakeholder communication — 23+ viewpoints provide tailored views for executives, business owners, solution architects, infrastructure teams, and security officers.

  8. Portfolio rationalization — Modeling the full application landscape with lifecycle states, technology dependencies, and business value enables TIME/Gartner-style assessments.

4. When to Apply Each

Use C4/Structurizr When...

  • You are designing or documenting a single software system or a bounded set of systems
  • Your primary audience is solution architects, technical architects, development teams, and team leads
  • You want architecture documentation that lives with the code and stays current
  • You need to onboard new team members quickly on system structure
  • Your team values "architecture as code" and Git-based workflows
  • You are working in an agile/DevOps environment where lightweight, iterative documentation is preferred
  • You need to communicate deployment topology for a specific system

Use ArchiMate When...

  • You need to model the enterprise-wide architecture landscape
  • You must connect business strategy (goals, capabilities, value streams) to IT implementation
  • Governance and compliance require formal, auditable architecture descriptions
  • You need impact analysis across business, application, and technology layers
  • Multiple stakeholder groups (executives, business, IT, security, compliance) need tailored views of the same architecture
  • You are doing portfolio rationalization, migration planning, or technology lifecycle management
  • Your organization follows TOGAF or another EA framework that expects formal modeling
  • Architecture decisions need to be traceable to business drivers and quality requirements

Use Both When...

  • Your organization has both enterprise architects (who think in capabilities, business processes, and application landscapes) and solution/software architects (who think in containers, components, and APIs)
  • You need strategic alignment (ArchiMate) AND developer-level documentation (C4) for the same systems
  • You want to maintain a single source of truth at the enterprise level while giving development teams a lightweight way to document their systems

5. The Choice: One, the Other, or Both?

5.1 Decision Framework

                                    ┌─────────────────────────┐
                                    │  What is the scope of   │
                                    │  your architecture      │
                                    │  practice?              │
                                    └────────┬────────────────┘
                                             │
                          ┌──────────────────┼──────────────────┐
                          │                  │                  │
                    ┌─────▼─────┐     ┌──────▼──────┐    ┌─────▼──────┐
                    │  Single   │     │  Multiple   │    │ Enterprise │
                    │  system / │     │  systems /  │    │ wide       │
                    │  team     │     │  domain     │    │            │
                    └─────┬─────┘     └──────┬──────┘    └─────┬──────┘
                          │                  │                  │
                     ┌────▼────┐       ┌─────▼─────┐     ┌─────▼──────┐
                     │  C4     │       │  C4 +     │     │ ArchiMate  │
                     │  only   │       │ ArchiMate │     │ + C4 for   │
                     │         │       │  (hybrid) │     │ dev teams  │
                     └─────────┘       └───────────┘     └────────────┘

5.2 Factors to Consider

Factor Favors C4 Only Favors ArchiMate Only Favors Both
Team size Small (1–3 teams) N/A Large (10+ teams)
Architecture maturity Low — just starting High — established EA practice Medium to high
Primary stakeholders Developers Executives + governance Mixed
Governance requirements Minimal Heavy (regulated industry) Moderate to heavy
Business modeling needs None Critical Important but secondary
Developer adoption Must be high Not a priority Both matter
Tooling budget Low (open source) Available (EA tool licenses) Available
Strategy-to-code traceability Not needed Essential Desired

6. Using Both Without Overlap — The Integration Strategy

This is the critical section. When an organization uses both C4 and ArchiMate, the biggest risks are:

  1. Duplicate effort — Modeling the same information in two places
  2. Inconsistency — The ArchiMate model says one thing, the C4 model says another
  3. Confusion — Teams don't know which model is authoritative for what

6.1 The Principle: Complementary Scope, Not Overlapping Scope

The key insight is that C4 and ArchiMate operate at different scopes and for different audiences. The overlap zone is narrow and manageable:

ArchiMate Scope                          C4 Scope
─────────────────────────────────────    ─────────────────────────────
Strategy & Motivation                    
  Goals, Drivers, Principles             
  Capabilities, Value Streams            

Business Layer                           
  Business Processes, Actors, Roles      
  Business Services, Objects             

Application Layer ◄──── OVERLAP ────►    System Context (Level 1)
  Application Components                   Software Systems
  Application Interfaces                   
  Application Services                   Container (Level 2)
                                           APIs, Apps, DBs, Queues
Technology Layer                         
  Nodes, Devices, Networks               Component (Level 3)
  System Software, Artifacts               Modules inside containers

Physical Layer                           Code (Level 4)
  Facilities, Equipment                    Classes, interfaces

Implementation & Migration               Deployment (supplementary)
  Plateaus, Gaps, Work Packages            Infrastructure mapping

6.2 The Ownership Model

Define clear ownership boundaries:

Concern Authoritative Source Consumers
Enterprise application landscape ArchiMate C4 (references as external systems)
Business capabilities & processes ArchiMate —
Strategy, goals, principles ArchiMate —
System internals (containers, components) C4 / Structurizr ArchiMate (references at Application Component level)
API contracts and protocols C4 (relationship labels) ArchiMate (Application Interface)
Deployment topology (per system) C4 deployment diagrams ArchiMate Technology layer (aggregated)
Enterprise infrastructure landscape ArchiMate Technology layer C4 (references as deployment nodes)
Migration planning ArchiMate I&M layer —

6.3 The Integration Points

There are exactly two natural integration points between C4 and ArchiMate:

Integration Point 1: C4 Software System ↔ ArchiMate Application Component

A C4 "Software System" at Level 1 corresponds to an ArchiMate ApplicationComponent (or a grouping of Application Components). This is the primary bridge.

Rule: The ArchiMate model is the master for the existence and naming of application-level systems. C4 models reference the same system names. When a C4 model defines a new Software System, it should be registered in the ArchiMate landscape.

ArchiMate                              C4
─────────                              ──
:OrderManagement                       softwareSystem "Order Management" {
    a am:ApplicationComponent              container "Orders API" { ... }
                                           container "Orders DB" { ... }
                                       }

Integration Point 2: C4 Deployment Nodes ↔ ArchiMate Technology Layer

C4 deployment diagrams show where containers run. ArchiMate's Technology layer models the enterprise infrastructure landscape.

Rule: ArchiMate owns the enterprise infrastructure model (platforms, networks, data centers). C4 deployment diagrams reference those platforms by name but detail the specific container-to-node mapping for their system.

6.4 Avoiding Duplication — Practical Rules

  1. Don't model business processes in C4. If you need to show how a system supports a business process, that's an ArchiMate view. C4 shows the system's internal structure.

  2. Don't confuse ArchiMate's Application layer with C4's Container level — they serve different purposes. ArchiMate's Application layer is far richer than just Application Component. It provides Application Services, Application Interfaces, Application Functions, Application Processes, Application Events, and Data Objects — each with formal relationships to the Business, Strategy, and Motivation layers. These elements model what an application means to the enterprise (what services it exposes, what data it governs, what business processes it supports). C4 Containers model what an application looks like to developers (what runs where, using what technology). Don't create ArchiMate Application Components for every microservice, database, and message queue — those are deployment concerns for C4. But DO model Application Services, Data Objects, and Application Functions in ArchiMate when you need cross-layer traceability. See the detailed guideline for patterns and examples.

  3. Don't duplicate relationship semantics. ArchiMate has formal relationship types (Serving, Realization, Flow). C4 has labeled arrows. Don't try to replicate ArchiMate's relationship formalism in C4, and don't try to capture C4's protocol-level detail in ArchiMate.

  4. Use naming conventions as the glue. The same system should have the same name in both models. Establish a naming convention and enforce it.

  5. Define a single source of truth for each fact. If the question is "what containers does Order Management have?" → C4. If the question is "what business capabilities does Order Management support?" → ArchiMate.

6.5 The Linked.Archi Approach — Semantic Integration

The deeper rationale for semantic integration comes from a convergence observation: once you specialize C4 (add archetypes, typed relationships, validation rules) and tailor ArchiMate (restrict the palette, specialize elements), they move closer together — though they never become the same thing, because C4's intent (developer-facing diagramming) and ArchiMate's intent (enterprise-wide modeling) remain fundamentally different. What both need after tailoring is a domain-specific architecture vocabulary fitted to the organization's specific needs, resources, and skills. Linked.Archi provides the mechanism for that: define your own metamodel, whether you start from ArchiMate simplify and specialize or from C4 and extend, with formal validation and cross-layer queries from a single source of truth. (See Build Your Own Metamodel for the practical walkthrough, and Diagramming Approach Meets Modeling Language — "The real issue: both need tailoring" — for the underlying argument.)

For organizations using the Linked.Archi ecosystem, both C4 and ArchiMate models can be converted to RDF and unified in a single knowledge graph. This eliminates the consistency problem at the data level:

  • The ArchiMate converter produces RDF typed with am: (ArchiMate) classes
  • The C4/Structurizr model can be expressed using the c4: ontology (see modelingLanguages/c4/)
  • Both share the arch: core ontology foundation
  • SPARQL queries can traverse across both models
  • SHACL shapes can validate cross-model consistency (e.g., every C4 Software System must have a corresponding ArchiMate Application Component)
# Find C4 systems without a corresponding ArchiMate Application Component
PREFIX c4: <https://meta.linked.archi/c4/onto#>
PREFIX am: <https://meta.linked.archi/archimate3/onto#>

SELECT ?c4System ?label
WHERE {
  ?c4System a c4:SoftwareSystem ;
            skos:prefLabel ?label .
  FILTER NOT EXISTS {
    ?amComponent a am:ApplicationComponent ;
                 skos:prefLabel ?label .
  }
}

7. Scenarios by Team Structure and Maturity

Scenario A: Small Startup / Single Product Team (5–15 developers)

Context: One product, one team, no formal EA practice. Speed and developer experience matter most.

Recommendation: C4 only

  • Use System Context + Container diagrams as the baseline
  • Add Component diagrams for complex or security-critical areas
  • Store Structurizr DSL in the same Git repo as the code
  • Review architecture diagrams in pull requests
  • No ArchiMate — the overhead isn't justified at this scale

Example artifacts: - docs/architecture/workspace.dsl — Structurizr workspace - System Context diagram in the README - Container diagram for each major system - Component diagram for the payment module

Scenario B: Growing Company / Multiple Product Teams (3–8 teams, 30–80 developers)

Context: Multiple systems emerging, some shared infrastructure, a solution architect or two. Need to understand cross-system dependencies but no formal EA function yet.

Recommendation: C4 as primary, lightweight ArchiMate for landscape

  • Each team owns their C4 model (Structurizr DSL in their repo)
  • A solution architect maintains a lightweight ArchiMate model of the system landscape — just Application Components, their key relationships (Serving, Flow), and the Technology platforms they run on
  • The ArchiMate model is the "map"; C4 models are the "street-level views"
  • Use the Archi tool (free, open source) for the landscape model

Example artifacts: - Per-team: workspace.dsl in each repo - Central: landscape.archimate in a shared architecture repo - Naming convention document ensuring system names match across models

Integration rule: When a team creates a new system, they add it to the landscape model. When they need to understand cross-system dependencies, they consult the landscape model.

Scenario C: Mid-Size Enterprise / Established Architecture Practice (10–30 teams)

Context: Formal architecture function with enterprise architects and solution architects. Multiple domains (e.g., customer, payments, logistics). Governance requirements. Possibly regulated industry.

Recommendation: ArchiMate for enterprise, C4 for development teams — with clear boundaries

  • Enterprise architects own the ArchiMate model covering:
  • Business capabilities and processes
  • Application landscape (Application Components, interfaces, services)
  • Technology platforms and infrastructure
  • Strategy, goals, and principles
  • Migration roadmaps
  • Solution/software architects and development teams own C4 models for their systems:
  • Container and Component diagrams
  • Deployment diagrams
  • Dynamic diagrams for key scenarios
  • A governance process ensures:
  • New systems are registered in the ArchiMate landscape
  • System names are consistent
  • Quarterly reviews align C4 and ArchiMate models

Example artifacts: - Enterprise: ArchiMate model in BiZZdesign/Sparx EA, with viewpoints for different stakeholders - Per-domain: C4 Structurizr workspaces, one per bounded context or system - Integration: naming convention + quarterly architecture review

Roles: | Role | Primary tool | Responsibility | |------|-------------|----------------| | Enterprise Architect | ArchiMate | Landscape, strategy, governance, cross-domain | | Solution Architect | Both | Bridges enterprise and team levels; ensures alignment | | Software Architect / Tech Lead | C4 / Structurizr | System internals, deployment, developer documentation |

Scenario D: Large Enterprise / Mature EA Practice (50+ teams, regulated)

Context: Full EA function with TOGAF or similar framework. Multiple business units. Regulatory requirements (financial services, healthcare, government). Architecture review boards. Formal change management.

Recommendation: ArchiMate as the enterprise backbone, C4 for all development teams, semantic integration via knowledge graph

  • ArchiMate is the authoritative enterprise model covering all layers
  • C4 is the developer-facing documentation standard for every system
  • A knowledge graph (e.g., Linked.Archi) unifies both into a queryable, validatable whole
  • Automated consistency checks run in CI/CD:
  • Every C4 Software System must exist as an ArchiMate Application Component
  • Naming conventions are enforced
  • Cross-model relationships are validated

Example artifacts: - Enterprise: ArchiMate model in enterprise EA tool, published as viewpoint-specific views - Per-team: Structurizr DSL in Git, with CI/CD generating diagrams - Integration layer: RDF knowledge graph with SPARQL queries and SHACL validation - Governance: Architecture review board uses ArchiMate viewpoints; development teams present C4 diagrams

Automation opportunities: - Convert ArchiMate models to RDF → load into knowledge graph - Parse Structurizr DSL → convert to C4 RDF → load into same graph - Run SHACL consistency checks across both - Generate compliance reports from SPARQL queries - AI agents query the unified graph for impact analysis

Scenario E: Low Architecture Maturity / "We Just Need Diagrams"

Context: No architecture practice. Developers draw ad-hoc diagrams in draw.io or Miro. Management wants "some architecture documentation."

Recommendation: Start with C4 only

  • Introduce C4 as a team practice, not a governance mandate
  • Start with just System Context + Container diagrams
  • Use any tool the team is comfortable with (even draw.io with C4 shapes)
  • Focus on the value: "Can a new person understand our system in 10 minutes?"
  • Do NOT introduce ArchiMate at this stage — the learning curve will kill adoption

Growth path: 1. Teams adopt C4 → diagrams exist and are useful 2. Cross-team dependencies become painful → introduce a lightweight landscape view (could still be C4 System Landscape) 3. Business alignment becomes important → introduce ArchiMate for the enterprise layer 4. Governance requirements grow → formalize the ArchiMate practice

Scenario F: Architecture Practice with Mixed Competency Levels

Context: Some architects are experienced with formal modeling; others are developers who've been promoted to "architect" roles. Skill levels vary widely.

Recommendation: C4 as the common language, ArchiMate for specialists

  • Make C4 the minimum standard everyone must know — it's learnable in a day
  • Train enterprise architects in ArchiMate — it's their specialized tool
  • Solution architects learn both and serve as translators
  • Don't force ArchiMate on developers — they'll resist and produce poor models
  • Don't limit enterprise architects to C4 — they need ArchiMate's expressiveness

Training plan: | Role | C4 Training | ArchiMate Training | |------|------------|-------------------| | Developer | 2-hour workshop | Not required | | Tech Lead | Half-day workshop | Awareness (2 hours) | | Solution Architect | Half-day workshop | Foundation certification (2–3 days) | | Enterprise Architect | Awareness | Practitioner certification (3–5 days) |

8. Anti-Patterns to Avoid

  1. "ArchiMate for everything" — Forcing development teams to model every C4 Container as an ArchiMate Application Component. ArchiMate's Application layer is rich (Services, Interfaces, Functions, Data Objects, Events) and should be used for cross-layer traceability — but C4 Containers are deployment units, not enterprise architecture concepts. Don't conflate the two.

  2. "C4 for the enterprise" — Trying to model business capabilities, strategy, and migration plans in C4. It wasn't designed for this and lacks the vocabulary.

  3. "Two models, no integration" — Maintaining both without any process to keep them aligned. Within months, the models will contradict each other.

  4. "Modeling everything" — Creating Component diagrams for every container AND ArchiMate views for every application. Model what's valuable, not everything that's possible.

  5. "Tool-driven architecture" — Choosing ArchiMate because you bought an EA tool, or C4 because developers like code. Choose based on the problem you're solving.

  6. "Big bang ArchiMate adoption" — Trying to model the entire enterprise in ArchiMate before delivering any value. Start with one domain, prove value, expand.

  7. "Ignoring the audience" — Showing ArchiMate motivation views to developers or C4 Component diagrams to the board. Match the notation to the audience.

9. Mapping Between C4 and ArchiMate Concepts

For teams using both, this mapping clarifies how concepts relate:

C4 Concept ArchiMate Equivalent Notes
Person Business Actor / Business Role ArchiMate distinguishes actor (who) from role (what capacity)
Software System Application Component (coarse-grained) Or nested Application Components via Composition
Container Application Component + Technology layer (Node) ArchiMate models both the logical component and its physical deployment
Component Application Function, Application Process, or nested Application Component ArchiMate models behavioral granularity (what the application does) but not necessarily all structural details (how the code is organized) — its behavioral elements serve cross-layer traceability rather than code decomposition
Code element (No equivalent) Not in ArchiMate's scope — Level 4 is optional in C4 and seldom maintained manually
Relationship label Serving, Flow, Triggering, Access ArchiMate has 11 formal relationship types; C4 uses free-text labels
Deployment node Node, Device, System Software, Artifact ArchiMate's Technology layer is richer; Assignment relationships map components to nodes
System boundary Application Component boundary or Grouping
External system Application Component (external) Tag or color to distinguish internal vs external

For a detailed treatment of how to model APIs across both notations, see the C4 Design APIs guide in this repository.

10. Summary — Decision Cheat Sheet

If you need to... Use
Onboard developers on system structure C4
Model business capabilities and processes ArchiMate
Document microservice architecture C4
Do enterprise-wide impact analysis ArchiMate
Keep architecture docs in Git C4 / Structurizr
Present to the board ArchiMate viewpoints
Design a new system in a workshop C4
Plan a technology migration ArchiMate
Satisfy regulatory audit requirements ArchiMate
Align strategy to implementation ArchiMate (enterprise) + C4 (system level)
Understand cross-system dependencies ArchiMate landscape + C4 per system

The two are not competitors — they are complementary tools for different scopes and audiences. The architecture practice that uses both effectively, with clear ownership boundaries and naming conventions, gets the best of both worlds: enterprise governance AND developer adoption.

References & Further Reading

C4 Model — Official Resources

Structurizr — Official Resources

ArchiMate — Official Resources

Articles Comparing C4 and ArchiMate

Videos

C4 Model & Structurizr

ArchiMate

Both Together / Comparisons

Additional Practitioner Articles

Linked.Archi — This Repository