Visual Paradigm Desktop VP Online

A Comprehensive Guide to Using the C4 Model as the Glue Between Enterprise, Business, Solutions, and Software Architectures

Based on the presentation by Simon Field, Principal Architect, Bank of England (BCS EASG Conference, Sept 2022)


📘 Executive Summary

The C4 model is a lightweight, structured approach to diagramming software architecture that organizes system design into four clear layers of abstraction. When properly embedded into an Enterprise Architecture (EA) metamodel, it acts as the “glue” that aligns business strategy, solution design, and software implementation.

This guide combines theoretical foundations with a complete, practical case study—the Internet Banking System—to show you exactly how to implement the C4 model at every level, using valid, renderable PlantUML code.

Using the C4 Model as the Glue Between Enterprise, Business, Solutions, and Software Architectures


🔍 Section 1: What is the C4 Model?

✅ Core Definition

  • Developed by Simon Brown as a pragmatic approach to software architecture diagramming.

  • Model & diagramming language agnostic: Can be implemented in any modeling tool (e.g., Sparx Enterprise Architect, Draw.io, Structurizr, PlantUML).

  • Focuses on hierarchical clarity and self-explanatory visuals.

⚠️ What C4 Is NOT

  • Not a complete architecture modeling solution.

  • Does not replace specialized artifacts for:

    • Data architecture & data flows

    • Customer journey mapping

    • Business process modeling or workflow orchestration

  • It is a structural visualization framework, not a governance methodology.

💡 Key Value Proposition

  • Provides a consistent, scalable way to transition between abstraction levels without losing context.

  • Enables architects, developers, and business stakeholders to speak a shared visual language.

  • Supports traceability from enterprise capabilities down to deployment infrastructure.


🧱 Section 2: The 4 Layers of Abstraction — With Live Case Study

The C4 model structures architecture into four progressive layers. Below, each layer is explained alongside executable PlantUML code for our Internet Banking System case study.

📐 Layer Overview Table

Level Name Focus Primary Audience Key Elements
Level 1 System Context What & Who (Business/Enterprise view) Business stakeholders, Enterprise Architects People, external software systems, high-level interactions
Level 2 Container How (Solution/Software view) Solution Architects, Development Leads Executable/deployable units (web apps, APIs, databases), technology choices
Level 3 Component Internal Structure (Software view) Software Architects, Senior Developers Logical components within containers (controllers, services, facades)
Level 4 Code / Deployment Runtime & Infrastructure DevOps, Infrastructure Engineers, SREs Classes, interfaces, deployment nodes, networks, scaling

🏦 Case Study: Internet Banking System — All 4 Levels

🔹 Level 1: System Context Diagram

Shows the scope of the system and how users and external systems interact with it.

Purpose: Answer “What is this system and who uses it?”

Key Elements:

  • Personal Banking Customer (Person)

  • Internet Banking System (Software System)

  • E-mail System (External System)

  • Mainframe Banking System (External System)

@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml

LAYOUT_WITH_LEGEND()
title System Context Diagram for Internet Banking System

Person(customer, "Personal Banking Customer", "A customer of the bank, with personal bank accounts.")
System(bankingSystem, "Internet Banking System", "Allows customers to view information about their bank accounts, and make payments.")
System_Ext(mailSystem, "E-mail System", "The internal Microsoft Exchange e-mail system.")
System_Ext(mainframe, "Mainframe Banking System", "Stores all of the core banking information about customers, accounts, transactions, etc.")

Rel(customer, bankingSystem, "Uses")
Rel_Back(customer, mailSystem, "Sends e-mails to")
Rel(bankingSystem, mailSystem, "Sends e-mail using")
Rel(bankingSystem, mainframe, "Uses")
@enduml

Enterprise Alignment Tip: Replace generic Person with enterprise role types like Partner Role or Resource Role to align with BPMN and business architecture standards.


🔹 Level 2: Container Diagram

Zooms into the system boundary, showing high-level technology building blocks.

Purpose: Answer “How is the system structured at a deployable unit level?”

Key Elements:

  • Web Application (Java/Spring MVC)

  • Single-Page Application (JavaScript/Angular)

  • Mobile App (Xamarin)

  • API Application (Java/Spring Boot)

  • Database (Relational)

@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml

LAYOUT_WITH_LEGEND()
title Container Diagram for Internet Banking System

Person(customer, "Personal Banking Customer", "A customer of the bank, with personal bank accounts.")
System_Ext(mailSystem, "E-mail System", "The internal Microsoft Exchange e-mail system.")
System_Ext(mainframe, "Mainframe Banking System", "Stores all of the core banking information about customers, accounts, transactions, etc.")

System_Boundary(c1, "Internet Banking System") {
    Container(webApp, "Web Application", "Java and Spring MVC", "Delivers the static content and the Internet banking single page application.")
    Container(spa, "Single-Page Application", "JavaScript and Angular", "Provides all of the Internet banking functionality to customers via their web browser.")
    Container(mobileApp, "Mobile App", "Xamarin", "Provides a limited subset of the Internet banking functionality to customers via their mobile device.")
    ContainerDb(database, "Database", "Relational Database", "Stores user registration information, hashed authentication credentials, access logs, etc.")
    Container(apiApp, "API Application", "Java and Spring Boot", "Provides Internet banking functionality via a JSON/HTTPS API.")
}

Rel(customer, webApp, "Visits", "HTTPS")
Rel(customer, spa, "Views account info and makes payments using")
Rel(customer, mobileApp, "Views account info and makes payments using")

Rel(webApp, spa, "Delivers to client browser")
Rel(spa, apiApp, "Makes API calls to", "JSON/HTTPS")
Rel(mobileApp, apiApp, "Makes API calls to", "JSON/HTTPS")

Rel(apiApp, database, "Reads from and writes to", "JDBC")
Rel_Back(mailSystem, apiApp, "Sends e-mails using", "SMTP")
Rel(apiApp, mainframe, "Makes API calls to", "XML/HTTPS")
@enduml

Metamodel Integration: Add Deployed on relationships to link containers to infrastructure platforms (e.g., Kubernetes, AWS EC2).


🔹 Level 3: Component Diagram

Zooms into the API Application container to show its internal logical components.

Purpose: Answer “What are the internal building blocks and how do they interact?”

Key Elements:

  • Sign In Controller (Spring MVC RestController)

  • Account Controller (Spring MVC RestController)

  • Security Component (Spring Bean)

  • Mainframe Banking System Facade (Spring Bean)

@startuml
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Component.puml

LAYOUT_WITH_LEGEND()
title Component Diagram for API Application

Container(spa, "Single-Page Application", "JavaScript and Angular", "Provides all of the Internet banking functionality to customers via their web browser.")
Container(mobileApp, "Mobile App", "Xamarin", "Provides a limited subset of the Internet banking functionality to customers via their mobile device.")
ContainerDb(database, "Database", "Relational Database", "Stores user registration information, hashed authentication credentials, access logs, etc.")
System_Ext(mainframe, "Mainframe Banking System", "Stores all of the core banking information about customers, accounts, transactions, etc.")

Container_Boundary(api, "API Application") {
    Component(signinController, "Sign In Controller", "Spring MVC RestController", "Allows users to sign in to the Internet Banking System.")
    Component(accountsController, "Account Controller", "Spring MVC RestController", "Provides endpoints for retrieving account summary and history.")
    Component(securityComponent, "Security Component", "Spring Bean", "Provides functionality related to signing in, changing passwords, etc.")
    Component(mainframeFacade, "Mainframe Banking System Facade", "Spring Bean", "A facade onto the legacy mainframe banking system.")

    Rel(spa, signinController, "Makes API calls to", "JSON/HTTPS")
    Rel(spa, accountsController, "Makes API calls to", "JSON/HTTPS")
    Rel(mobileApp, signinController, "Makes API calls to", "JSON/HTTPS")
    Rel(mobileApp, accountsController, "Makes API calls to", "JSON/HTTPS")

    Rel(signinController, securityComponent, "Uses")
    Rel(accountsController, mainframeFacade, "Uses")
    Rel(securityComponent, database, "Reads from and writes to", "JDBC")
    Rel(mainframeFacade, mainframe, "Makes API calls to", "XML/HTTPS")
}
@enduml

Governance Tip: Enforce that component diagrams are owned by Tech Leads and updated during sprint planning or refactoring cycles.


🔹 Level 4: Code / Class Diagram

Shows the code structure inside the Account Controller—interfaces, implementations, and dependencies.

Purpose: Answer “How is this component implemented in code?”

Key Elements:

  • IAccountController interface

  • AccountController implementation

  • IMainframeFacade abstraction

  • MainframeBankingSystemFacade concrete class

  • AccountSummary domain object

 

@startuml
title Code Diagram for AccountController Dependencies

interface IAccountController {
    +getAccountSummary(customerId: String): AccountSummary
    +getAccountHistory(accountId: String): List<Transaction>
}

class AccountController {
    -mainframeFacade: IMainframeFacade
    -logger: ILogger
    +getAccountSummary(customerId: String): AccountSummary
    +getAccountHistory(accountId: String): List<Transaction>
}

interface IMainframeFacade {
    +fetchAccounts(customerId: String): List<AccountData>
    +fetchTransactions(accountId: String): List<TransactionData>
}

class MainframeBankingSystemFacade {
    -httpClient: HttpClient
    -endpointUrl: String
    +fetchAccounts(customerId: String): List<AccountData>
    +fetchTransactions(accountId: String): List<TransactionData>
}

class AccountSummary {
    +customerId: String
    +accounts: List<Account>
    +totalBalance: Double
}

IAccountController <|-- AccountController
AccountController --> IMainframeFacade : uses
IMainframeFacade <|-- MainframeBankingSystemFacade
AccountController ..> AccountSummary : returns
@enduml

⚠️ Note: Level 4 diagrams are optional and should only be created for complex or critical components. Over-diagramming at this level creates maintenance overhead.

✅ Conclusion

The C4 model is not a silver bullet, but it is a highly effective structural framework for bringing clarity, consistency, and traceability to enterprise architecture. By embedding it into a formal EA metamodel and using practical, renderable diagrams like those in our Internet Banking System case study, organizations can:

  • ✅ Bridge the gap between business strategy and technical implementation

  • ✅ Prevent HLD/LLD divergence through hierarchical validation

  • ✅ Maintain living, self-explanatory architecture documentation

  • ✅ Enable cross-domain collaboration with a shared visual language

Success requires:

  1. Disciplined governance and clear ownership per layer

  2. Strict adherence to the Self-Explanatory Diagram Standard

  3. Integration with existing EA frameworks and tooling

  4. Regular audits and updates tied to delivery cycles

When implemented correctly, C4 becomes the foundational “glue” that aligns enterprise, business, solution, and software architectures into a cohesive, maintainable whole.

References

  1. C4 Diagram Tool & Modeling Software: Comprehensive overview of Visual Paradigm’s dedicated C4 modeling capabilities, including templates, symbols, and integration features for software architecture documentation.

  2. AI Diagram Generator: Complete C4 Model Support : Release announcement detailing how Visual Paradigm’s AI tools now support end-to-end C4 model generation across all abstraction levels.

  3. AI Diagram Generator Release Notes: Technical documentation and feature highlights for the AI-powered diagram generation engine integrated into Visual Paradigm.

  4. AI-Powered C4 PlantUML Studio: Specialized tool description for converting natural language requirements into version-controllable PlantUML code for C4 diagrams.

  5. Visual Paradigm AI Platform: Central hub for Visual Paradigm’s suite of AI-assisted modeling, diagramming, and documentation tools.

  6. AI Chatbot for Diagram Generation: Overview of the conversational AI interface that allows users to create and refine diagrams using natural language commands.

  7. AI-Powered C4 PlantUML Markdown Editor: Feature release introducing markdown-based editing workflows for C4 diagrams with AI assistance.

  8. AI Chatbot Tool: Dedicated page for the AI chatbot interface used for interactive diagram creation and refinement.

  9. Use Case to Activity Diagram Feature: Documentation of Visual Paradigm’s feature for transforming use case models into activity diagrams, supporting broader architectural workflows.

  10. C4 Model Tool in Visual Paradigm Online: Browser-based C4 modeling capabilities including real-time collaboration, symbol libraries, and cloud synchronization.

  11. C4 Diagram Solution: Enterprise-focused solution page highlighting how Visual Paradigm’s C4 tools support large-scale architecture initiatives.

  12. What is C4 Model?: Educational blog post explaining the fundamentals, benefits, and practical applications of the C4 modeling methodology.

Turn every software project into a successful one.

We use cookies to offer you a better experience. By visiting our website, you agree to the use of cookies as described in our Cookie Policy.

OK