C4 vs ArchiMate vs UML: Which View for Which Decision?

Developers draw C4 diagrams, enterprise architects model in ArchiMate, analysts reach for UML or BPMN, and the three sets of diagrams rarely meet. The result is familiar: the executive committee cannot read the container diagram, the development team ignores the capability map, and nobody can say which business process depends on the service being refactored. The question is not which notation wins. Each one answers a different question for a different reader, and the real work is choosing the right view for the decision at hand and keeping the levels linked.

TL;DR

• C4, ArchiMate and UML do not compete: C4 zooms into one software system, ArchiMate links strategy, business, applications and technology across the whole organisation, UML details structure and behaviour inside the code.
• Pick the view from the question and the reader, not from habit: a capability question calls for ArchiMate, a "what runs where" question for a C4 container diagram, a "what happens when it fails" question for a UML sequence diagram.
• C4 and ArchiMate can be mapped (Person → Business Actor, Software System → Application Component…), but the mapping is pragmatic, not normative. Download it as a cheat sheet below.
• The pivot between the two worlds is the application: one name, one identifier, shared by the landscape repository and the C4 workspace.
• Most modelling waste comes from describing the same thing three times, or from pushing a language below or above the level it was designed for.

What are C4, ArchiMate and UML, and who is each one for?

C4 is a way of drawing one software system at four zoom levels for the people who build it; ArchiMate is a modelling language for the whole enterprise, from strategy down to infrastructure; UML is a general-purpose language for the detailed structure and behaviour of software.

The C4 model, created by Simon Brown and documented at c4model.com, describes a software system through a hierarchy of abstractions: a software system is made up of containers (applications and data stores), each container contains components, and each component is implemented by code elements. People use the software systems. Each abstraction has its diagram: System Context, Container, Component and Code, plus supplementary diagrams (system landscape, dynamic, deployment). C4 is deliberately notation-independent and tooling-independent: boxes and lines with clear labels, readable without training. Its sweet spot is a team explaining its system to a newcomer or a security reviewer.

ArchiMate, maintained by The Open Group, is a formal modelling language for enterprise architecture. In version 3.2, it covers strategy (capabilities, value streams), business (actors, processes, objects), application (components, services, data objects), technology (nodes, system software), plus motivation (goals, requirements) and implementation and migration (work packages, plateaus). Its strength is the typed relationships that cross these layers: a capability is realised by a process, the process is served by an application, the application runs on a node. Its readers are architects, CIOs and transformation leaders. We cover the notation itself in our ArchiMate guide.

UML (Unified Modeling Language), maintained by the Object Management Group, is the oldest of the three. Version 2.5.1 defines fourteen diagram types, half structural (class, component, deployment…) and half behavioural (sequence, state machine, activity…). In everyday work, a handful survive: sequence diagrams, state machines and class diagrams.

The C4 site is candid about the overlap: its FAQ says that a team already communicating well with UML or ArchiMate should keep doing so, and that C4 diagrams can be supplemented with UML, BPMN or ArchiMate diagrams for what C4 does not cover.

Which view answers which question?

Start from the decision you need to make and the person who will read the diagram: the right language follows from them.

Two patterns stand out. Every question that crosses the business/IT boundary lands on ArchiMate, because it is the only one of the three that has business concepts. Every question about the inside of one system lands on C4 or UML, because ArchiMate becomes heavy and unreadable at that grain.

How do C4 elements map to ArchiMate elements?

Most C4 concepts have a natural ArchiMate counterpart: a person becomes a Business Actor, a software system and a container become Application Components, a component becomes an Application Function or a finer Application Component. The mapping is pragmatic: neither The Open Group nor the C4 model defines an official one.

The best-known reference is a post on the Archi blog, C4 Model, Architecture Viewpoint and Archi, which treats each C4 diagram as a viewpoint and maps the C4 metamodel onto ArchiMate. Its choices are in the second column below; the third column gives the alternatives many teams use, depending on what the model is for.

Two remarks. First, the Archi post maps relationships to Triggering; many landscape models prefer Serving for a dependency and Flow for a data exchange, which is what impact questions need. Neither is wrong; mixing them in one model is. Second, the element names above are those of ArchiMate 3.2. The ArchiMate 4 specification, published by The Open Group on 27 April 2026, supersedes it: layers become "domains", behaviour elements are merged across domains into a single service, process, function and event (an Application Function becomes a Function), and the Business Role gives way to a generic Role. The logic of the mapping does not change, but check which version your tool implements before you standardise the names.

Download the cheat sheet: the mapping table and the "question → view" table on two pages, as a printable PDF or an editable spreadsheet you can adapt to your own conventions. If you want the ArchiMate side explained element by element, see ArchiMate for developers: the 12 elements you need.

Keeping the landscape side of this mapping up to date by hand is the part that usually breaks first. UrbaHive keeps applications, flows, capabilities and processes in one shared repository, and exports them in the ArchiMate exchange format. Try it on the free plan: 1 user, 25 applications, no credit card.

How do you trace a decision from strategy down to code?

You trace it through a chain of levels, each owned by one language and one team, joined at a single pivot: the application, which is an Application Component in ArchiMate and a Software System in C4.

The chain gives every decision a path: retiring a capability leads to the applications that support it, then to their software systems and the teams that own them; a team changing an API can climb back to the processes it serves.

For the chain to hold, three conventions matter more than any notation:

• One name and one identifier per application, used both in the landscape repository and as the Software System name in the C4 workspace. Without that join key, the two worlds drift apart within months.
• One owner per level. The enterprise architect does not maintain container diagrams; the development team does not maintain the capability map. Each level is updated by the people who change it.
• A link from the landscape to the detail. The application record points to where its C4 diagrams live (a repository, a wiki page, a technical architecture document), instead of copying them.

What mistakes should you avoid when combining C4, ArchiMate and UML?

The most expensive mistake is modelling the same thing three times; the second is pushing a language outside the level it was designed for.

• Modelling the same application three times. The CRM appears in a slide, in the Archi model and in the C4 workspace, under three names and with three different lists of integrations. Decide which level is the master for each fact: the landscape repository for "which applications and flows exist", the C4 workspace for "what is inside this system".
• Using ArchiMate at component level. Modelling every microservice, module and queue as Application Components produces a model nobody can read and nobody maintains. In ArchiMate, stop at the application, or at the containers that matter to a cross-system question.
• Showing C4 container diagrams to an executive committee. Leadership asks which capabilities are at risk and what a project changes for the business; a container diagram answers neither. Show a capability or process view.
• Mixing levels in one diagram. A business process, a database and a SaaS tool linked by unlabelled arrows is a picture, not a model. One diagram, one level, one question.
• Arguing about the mapping instead of the decision. Whether a C4 relationship becomes Serving or Triggering matters less than writing the convention down once and applying it consistently.
• Redrawing what could be generated. A diagram drawn by hand starts going stale the day after it is drawn. Wherever possible, keep the data in one place and generate the views from it, a point developed in living architecture documentation.

Where does UrbaHive fit between C4, ArchiMate and UML?

UrbaHive works at the landscape level of the chain: applications, flows between them, capabilities, business processes and servers, for mid-sized organisations of roughly 50 to 5,000 employees. It is neither a C4 tool nor an ArchiMate modeller, and C4 detail stays with the development teams.

What it covers:

• The landscape repository. Applications (vendor, stack, hosting server, responsible person), flows (direction, type, frequency), servers, a capability hierarchy with a capabilities × applications coverage matrix, and business processes whose steps are linked to applications.
• Generated views, not drawn ones. An application-flow diagram and an infrastructure diagram are generated from the repository and exported as PNG or PDF. Impact analysis shows the direct dependencies, upstream and downstream, of an application, a server, a process or a capability, one level deep.
• The ArchiMate bridge. The repository exports to the ArchiMate Open Exchange Format: applications become Application Components, flows become Flow relationships, servers become Nodes (with programs, vendors, roles and architecture documents), plus three generated views you can open in Archi. A model built in Archi can be imported in the same format, with a per-item preview of what will be created, updated or ignored. There is no ArchiMate notation editor, and no strategy, motivation or migration layer.
• The link to C4. UrbaHive does not import C4 or Structurizr workspaces. Each application record has a technical architecture document field (with version), and a custom field can hold the link to the repository where its C4 diagrams live.
• AI agents as a bridge from code. Through the MCP connector, an AI assistant such as Claude Code or Cursor, given a write-scoped token, can read a codebase or its manifests and propose the corresponding applications and flows in the repository, every call recorded in the audit log. The method is described in bootstrapping your IT map from code with MCP.

You can start in a couple of hours. The free plan (1 user, 25 applications, no credit card, no time limit) has every feature, including the ArchiMate import and export.

FAQ

Can I use C4 and ArchiMate together?

Yes, and it is the usual setup when an organisation has both software teams and an architecture function. ArchiMate covers the landscape and its links to the business; C4 covers the inside of each software system. The join is the application: an Application Component in ArchiMate, a Software System in C4, with the same name in both.

Is C4 a replacement for ArchiMate?

No. C4 describes one software system and the people and systems around it; it has no concept of capability, business process, goal or migration plan. ArchiMate is built for those cross-domain questions. The C4 model's own FAQ recommends supplementing C4 with ArchiMate, UML or BPMN diagrams where needed.

Which one should a mid-sized organisation start with?

Start with the question you most need to answer. For "which applications do we have, how do they exchange data and who owns them", start with a landscape inventory and a few ArchiMate-style views, without learning the whole language. For "how is this product built and deployed", start with C4 Context and Container diagrams. UML can wait.

Can Archi draw C4 views?

Yes, with conventions rather than a built-in C4 notation. Archi has no C4 viewpoint as such, but the Archi blog shows how to map C4 concepts to ArchiMate elements and, since Archi 4.7, use label expressions and a custom palette so that the boxes display C4-style labels (name, technology, description). The result is a C4-looking diagram backed by a real ArchiMate model.

Choose the view, then keep it alive

C4, ArchiMate and UML are three lenses on the same information system: pick the lens from the decision and the reader, and link the levels through one shared application list. Start with the cheat sheet to agree on conventions. Do it by hand with the template, or let UrbaHive keep the landscape up to date: start your repository on the free plan, 1 user, 25 applications, no credit card.