Skip to content

Backstage Software Catalog: Complement or Replacement for C4?

Purpose

This document examines whether the Backstage Software Catalog system model — which shares structural DNA with C4 but adds operational concerns like ownership, lifecycle, APIs-as-first-class-citizens, and resources — can serve as a complement to or partial replacement for C4/Structurizr in an architecture practice that already uses ArchiMate for enterprise modeling.

The Linked.Archi ecosystem formalizes both as ontologies (modelingLanguages/c4/ and modelingLanguages/backstage/), making this comparison concrete and traceable.

1. The Three Models Side by Side

1.1 What each model is

C4 / Structurizr Backstage Software Catalog ArchiMate
Origin Simon Brown, ~2010. Community practice. Spotify, 2020. CNCF incubating project. The Open Group, 2004. ISO-aligned standard.
Primary purpose Visualize software architecture at multiple zoom levels Centralized runtime catalog of all software, APIs, resources, and ownership Model enterprise architecture across business, application, and technology
Primary audience Architects and developers during design Developers and platform engineers during operations Enterprise architects and governance stakeholders
Temporal focus Design-time ("what are we building?") Runtime ("what is running, who owns it, what depends on what?") Strategic ("how does IT support the business?")
Data source Manually authored (Structurizr DSL) Auto-discovered + YAML descriptors in repos (catalog-info.yaml) Manually modeled in EA tools

1.2 Element vocabulary comparison

Concept C4 Backstage ArchiMate Application Layer
A person/user Person User Business Actor / Business Role
A team/group — Group (with ownership semantics) Business Actor (as organization unit)
A software system SoftwareSystem System Application Component (coarse)
A deployable unit Container Component (service, website, library) Application Component (nested)
An internal module Component — Application Function / nested Application Component
An API contract — (relationship label or convention) API (first-class, typed: OpenAPI, AsyncAPI, GraphQL, gRPC) Application Interface + Application Service
A database/infrastructure Container (tagged as DB) Resource (database, bucket, queue, external service) Application Component + Technology layer Node/Artifact
A business domain — Domain Business layer / Grouping
Deployment node DeploymentNode — (not in catalog model) Node, Device, System Software
Code-level element Component (Level 4) — —

1.3 Relationship vocabulary comparison

Relationship C4 Backstage ArchiMate
Uses/depends on uses (free-text label) consumesAPI, usesResource (typed) Serving, Access, Flow (11 formal types)
Contains hasContainer, hasComponent partOfSystem Composition, Aggregation
Exposes API — (convention) providesAPI (first-class) Application Interface exposed by Application Component
Ownership — ownedBy (Component/System → Group) — (can be modeled via custom properties)
Domain membership — belongsToDomain — (can use Grouping)
Team membership — memberOf (User → Group) —
Deployment deployedOn — Assignment (Application Component → Node)
Realizes business service — — Realization (Application Service → Business Service)

2. Where Backstage Extends Beyond C4

Backstage's system model is not just "C4 with different names." It adds three dimensions that C4 lacks entirely:

2.1 APIs as first-class citizens

In C4, an API is either a relationship label ("Calls Orders REST API via HTTPS") or a naming convention on a Container or Component. There is no formal distinction between the API contract and the component that implements it.

In Backstage, API is a dedicated entity type with: - A type (OpenAPI, AsyncAPI, GraphQL, gRPC) - An owner (which team maintains this API?) - A lifecycle (experimental, production, deprecated) - Explicit provider and consumer relationships (providesAPI, consumesAPI)

This means Backstage can answer questions C4 cannot: - "Which APIs are deprecated and still have consumers?" - "Which team owns the Payment API?" - "Show me all AsyncAPI event contracts in the Order domain" - "Which components consume the Customer API?"

This is architecturally significant. In microservice and event-driven architectures, APIs are the primary integration contracts. Making them first-class — with typed specifications, ownership, and lifecycle — is a modeling improvement over C4's free-text approach.

ArchiMate comparison: ArchiMate models this via Application Interface (the access point) + Application Service (the exposed behavior). ArchiMate's approach is more abstract — it doesn't capture API specification types (OpenAPI vs gRPC) — but it connects to the Business layer via Realization. Backstage captures the operational reality; ArchiMate captures the architectural semantics.

2.2 Ownership and organizational structure

C4 has no concept of who owns what. Structurizr DSL doesn't model teams, ownership, or organizational structure.

Backstage makes ownership a core relationship: - Every Component and System has an ownedBy relationship to a Group - User entities are memberOf Group entities - Domain entities organize systems by business domain

This enables: - "Show me all components owned by the Payments team" - "Which team should I contact about the Order Management system?" - "Which domains have components with no owner?"

ArchiMate comparison: ArchiMate can model organizational structure via Business Actor, Business Role, and Business Collaboration, but ownership of application components is not a native relationship — it requires custom properties or extensions. Backstage's ownership model is simpler and more directly operational.

2.3 Resources as distinct from components

C4 models databases, message brokers, and caches as Containers — the same element type as application services and web apps. The only distinction is a tag or description.

Backstage separates Resource from Component: - A Resource is "physical or virtual infrastructure needed to operate a component" — databases, S3 buckets, Kafka clusters, external SaaS services - A Component is "a piece of software" — services, websites, libraries - The relationship usesResource explicitly connects components to their infrastructure dependencies

This distinction matters for: - Infrastructure cost attribution ("which resources does this system use?") - Dependency analysis ("if this database goes down, which components are affected?") - Platform engineering ("which components use our shared Kafka cluster?")

ArchiMate comparison: ArchiMate handles this more precisely via the Technology layer (Node, Device, System Software, Artifact) and Assignment relationships. ArchiMate's separation of Application and Technology layers is architecturally cleaner. But Backstage's Resource concept is simpler and directly maps to what platform engineers manage.

2.4 Lifecycle management

Backstage components have a lifecycle property with well-known values: experimental, production, deprecated. This is a first-class operational concern.

C4 has no lifecycle concept. ArchiMate can model lifecycle via the Implementation & Migration layer (Plateau, Gap) or via custom properties, but it's not as lightweight as Backstage's approach.

3. Where C4 Extends Beyond Backstage

3.1 Hierarchical zoom (progressive disclosure)

C4's core value proposition is the four-level zoom: Context → Container → Component → Code. Each level serves a different audience at a different level of detail.

Backstage's catalog is flat. All entities exist at the same level. You can navigate from System to Component to API, but there's no concept of "zoom levels" or progressive disclosure. The catalog is a registry, not a set of diagrams.

3.2 Deployment modeling

C4 has DeploymentNode and InfrastructureNode elements with deployedOn relationships. Structurizr supports deployment diagrams that show how containers map to infrastructure.

Backstage has no deployment model. It knows what components exist and who owns them, but not where they run. (Backstage plugins can integrate with Kubernetes, but the core system model doesn't include deployment topology.)

3.3 Visualization and diagramming

C4/Structurizr is fundamentally a diagramming approach. It produces visual diagrams — System Context, Container, Component, Deployment — designed for human consumption in design reviews, documentation, and onboarding.

Backstage is fundamentally a catalog/portal. It produces searchable, browsable entity pages with metadata, not architectural diagrams. You can build plugins that generate diagrams from catalog data, but the core product is a registry, not a visualization tool.

3.4 Dynamic (behavioral) diagrams

C4 supports Dynamic diagrams that show runtime interactions for specific scenarios ("what happens when a user places an order?"). Backstage has no behavioral modeling capability.

4. The Replacement Question: Can Backstage Replace C4?

4.1 What Backstage can replace

Backstage can replace C4 for the inventory and dependency concerns:

C4 Concern Backstage Replacement Quality of Replacement
"What software systems exist?" System entities in catalog ✅ Better — auto-discovered, with ownership and lifecycle
"What containers does this system have?" Component entities with partOfSystem ✅ Better — includes lifecycle, ownership, API provision
"What APIs does this system expose?" API entities with providesAPI ✅ Much better — typed, versioned, with consumer tracking
"What databases/infrastructure does this use?" Resource entities with usesResource ✅ Better — explicit resource type
"Who owns this?" ownedBy → Group ✅ C4 can't do this at all
"What domain does this belong to?" belongsToDomain → Domain ✅ C4 can't do this at all

4.2 What Backstage cannot replace

C4 Concern Backstage Capability Gap
System Context diagram (visual) No diagramming ❌ Backstage is a catalog, not a diagramming tool
Container diagram (visual) Entity pages with relationships ⚠️ Navigable but not a designed diagram
Component diagram (internal modules) No sub-component modeling ❌ Backstage Component ≈ C4 Container, not C4 Component
Code diagram No code-level modeling ❌ Not in scope
Deployment diagram No deployment model ❌ Not in scope (plugins can add this)
Dynamic diagram (behavioral) No behavioral modeling ❌ Not in scope
Progressive zoom (Context → Container → Component → Code) Flat catalog ❌ Different paradigm
Design-time architecture exploration Runtime catalog ⚠️ Different temporal focus

4.3 Verdict: Complement, not replacement

Backstage cannot replace C4 because they serve different purposes:

  • C4 is a design-time visualization tool — it helps architects and developers think about, communicate, and document the structure of software systems through diagrams at multiple zoom levels.
  • Backstage is a runtime catalog — it helps developers and platform engineers discover, navigate, and govern the software that actually exists in production.

However, Backstage can reduce the need for C4 in specific areas:

  • If your primary use of C4 Container diagrams is "what services exist and what do they depend on?", Backstage's catalog provides this information more accurately (auto-discovered, always current) and with richer metadata (ownership, lifecycle, API types).
  • If your primary use of C4 is onboarding ("show me the system landscape"), Backstage's catalog pages with dependency graphs serve a similar purpose — though without the designed, curated quality of a C4 diagram.

The combination is stronger than either alone.

5. The Three-Model Architecture: ArchiMate + Backstage + C4

5.1 Each model owns a different concern

flowchart TD
    subgraph strategic["Strategic / Enterprise"]
        AM["<b>ArchiMate</b><br/>Strategy, Motivation, Business,<br/>Application Services, Data Objects,<br/>Cross-layer traceability"]
    end
    subgraph operational["Operational / Catalog"]
        BS["<b>Backstage</b><br/>Runtime inventory, Ownership,<br/>API contracts, Resources,<br/>Lifecycle, Domain organization"]
    end
    subgraph design["Design / Visualization"]
        C4["<b>C4 / Structurizr</b><br/>Zoom diagrams, Deployment views,<br/>Dynamic scenarios, Design-time<br/>communication, Code-level detail"]
    end

    strategic --> operational --> design

5.2 Ownership matrix

Concern Authoritative Source Why
"What business capabilities does this system support?" ArchiMate Cross-layer traceability to Strategy/Business
"What services does this system expose to the business?" ArchiMate Application Service → Business Service realization
"What data does this system govern?" ArchiMate Data Object → Business Object realization
"What systems, components, and APIs exist right now?" Backstage Auto-discovered, always current, with lifecycle
"Who owns this component?" Backstage Native ownership model
"What API specification does this service expose?" Backstage Typed APIs (OpenAPI, AsyncAPI, GraphQL, gRPC)
"What resources does this component depend on?" Backstage Explicit Resource entities
"What does this system look like inside?" (visual) C4 Progressive zoom diagrams
"How is this deployed to infrastructure?" C4 Deployment diagrams with node mapping
"What happens when a user places an order?" (scenario) C4 Dynamic diagrams
"What are the internal modules of this service?" C4 Component diagrams

5.3 Integration points

Backstage System ↔ ArchiMate Application Component ↔ C4 Software System

All three models represent "a software system." The integration point is the system identity:

ArchiMate:   ex:OrderManagement  a am:ApplicationComponent .
Backstage:   ex:OrderManagement  a bs:System .
C4:          ex:OrderManagement  a c4:SoftwareSystem .

In the Linked.Archi knowledge graph, the same IRI can be typed with all three classes, or owl:sameAs / skos:exactMatch can link separate IRIs. The key is consistent naming.

Backstage Component ↔ C4 Container

A Backstage Component (a deployable service, website, or library) corresponds to a C4 Container (a deployable unit):

Backstage:   ex:OrdersAPI  a bs:Component ;
                 bs:lifecycle "production" ;
                 bs:ownedBy ex:OrdersTeam ;
                 bs:providesAPI ex:OrdersOpenAPI .

C4:          ex:OrdersAPI  a c4:Container ;
                 c4:technology "Spring Boot" ;
                 c4:deployedOn ex:K8sCluster .

Backstage knows who owns it, what APIs it exposes, and what lifecycle it's in. C4 knows what technology it uses and where it's deployed. Neither duplicates the other.

Backstage API ↔ ArchiMate Application Interface + Application Service

A Backstage API corresponds to the combination of ArchiMate's Application Interface (the access point) and Application Service (the exposed behavior):

Backstage:   ex:OrdersOpenAPI  a bs:API ;
                 # typed as OpenAPI, with lifecycle and owner

ArchiMate:   ex:OrderAPI  a am:ApplicationInterface ;
                 am:serves ex:OrderPlacementService .
             ex:OrderPlacementService  a am:ApplicationService ;
                 am:realizes ex:OrderFulfillmentBusinessService .

Backstage captures the operational contract (OpenAPI spec, version, consumers). ArchiMate captures the architectural semantics (what business service does this realize?).

Backstage Resource ↔ C4 Container (database) ↔ ArchiMate Technology Layer

Backstage:   ex:OrdersDB  a bs:Resource ;
                 # owned by Orders team, used by Orders API

C4:          ex:OrdersDB  a c4:Container ;
                 c4:technology "PostgreSQL" ;
                 c4:deployedOn ex:RDSInstance .

ArchiMate:   ex:OrderDataStore  a am:ApplicationComponent ;  # or Technology layer Node
                 # accessed by Application Functions, realizes Data Objects

Three perspectives on the same database: who owns it (Backstage), what technology and where (C4), what data it governs and what business objects it realizes (ArchiMate).

6. Concept Mapping Table

Concept C4 Backstage ArchiMate Notes
Person/User Person User Business Actor ArchiMate distinguishes actor from role
Team/Group — Group + ownedBy Business Actor (org unit) Backstage has native ownership
Software System SoftwareSystem System Application Component Same concept, three perspectives
Deployable unit Container Component Application Component (nested) Backstage adds lifecycle + ownership
Internal module Component — Application Function Below Backstage's granularity
API contract — (convention) API (typed, first-class) Application Interface + Application Service Backstage is most operational; ArchiMate most semantic
Database/infra Container (tagged) Resource Technology layer Node/Artifact Backstage separates from software; C4 doesn't
Business domain — Domain Business layer / Grouping Backstage is organizational; ArchiMate is semantic
Deployment node DeploymentNode — Node, Device Backstage has no deployment model
Business service — — Application Service → Business Service Only ArchiMate has cross-layer traceability
Data concept — — Data Object → Business Object Only ArchiMate models logical data
Lifecycle state — lifecycle property I&M layer (Plateau, Gap) or custom Backstage is simplest
Behavioral flow Dynamic diagram — Triggering, Flow + BPMN C4 and ArchiMate; not Backstage

7. When to Use Which Combination

Scenario A: Platform engineering team, no EA practice

Use Backstage only. It provides the catalog, ownership, API tracking, and resource dependencies that platform teams need. Add C4 diagrams only for complex systems that need visual documentation.

Scenario B: Development teams with a solution architect

Use C4 + Backstage. C4 for design-time diagrams and onboarding. Backstage for runtime catalog and operational governance. The Structurizr DSL lives in Git; the catalog-info.yaml lives in Git. Both are developer-native.

Scenario C: Enterprise with EA practice and developer portal

Use all three. ArchiMate for enterprise-level modeling (strategy, business, cross-layer traceability). Backstage for the runtime catalog (ownership, APIs, lifecycle). C4 for design-time visualization (zoom diagrams, deployment, scenarios). Integrate via the Linked.Archi knowledge graph.

Scenario D: Enterprise with EA practice, no developer portal

Use ArchiMate + C4. Backstage adds value primarily as a running portal. If you don't have one, ArchiMate covers the enterprise concerns and C4 covers the developer concerns. Consider Backstage when the organization reaches the scale where service discovery and ownership tracking become painful.

8. Can Backstage + ArchiMate Replace C4 Entirely?

The argument for yes

If you have: - Backstage providing the runtime inventory of systems, components, APIs, resources, ownership, and lifecycle - ArchiMate providing the enterprise architecture with cross-layer traceability, formal relationships, and governance viewpoints

Then the remaining C4 concerns are: - Visual diagrams — ArchiMate viewpoints can produce equivalent views (as demonstrated by the Archi tool's C4 viewpoint implementation) - Deployment modeling — ArchiMate's Technology layer covers this - Progressive zoom — ArchiMate viewpoints can filter to different levels of detail - Dynamic scenarios — ArchiMate's Triggering/Flow relationships + BPMN cover this

In this view, C4 becomes redundant: Backstage handles the operational catalog that C4 partially addressed, and ArchiMate handles the architectural modeling that C4 simplified.

The argument for no

C4's value is not in the information it captures — it's in the communication experience it provides: - A C4 Container diagram is designed to be read in 30 seconds by a developer who has never seen the system. A Backstage entity page requires navigation. An ArchiMate viewpoint requires notation knowledge. - Structurizr DSL is a purpose-built language for defining architecture models that developers will actually maintain. Neither catalog-info.yaml (which is a registry descriptor, not an architecture model) nor ArchiMate serialization formats provide this. - C4's progressive zoom is a conceptual framework for thinking about architecture, not just a visualization technique. It teaches architects and developers to think at the right level of abstraction for the right audience.

Verdict

Backstage + ArchiMate can cover the information that C4 captures, but they cannot replicate the communication design that makes C4 effective. If your organization values curated, designed architectural diagrams for onboarding, design reviews, and documentation — C4 remains valuable even alongside Backstage and ArchiMate.

If your organization's primary need is "what exists, who owns it, and what depends on what?" — Backstage may reduce the need for C4 to the point where only a few key C4 diagrams (System Context, key Container diagrams) are maintained, rather than a comprehensive C4 model.

9. Summary

Question Answer
Is Backstage a superset of C4? No. Backstage adds ownership, typed APIs, resources, lifecycle, and domains. But it lacks deployment modeling, progressive zoom, visual diagrams, behavioral modeling, and code-level detail.
Is C4 a superset of Backstage? No. C4 adds deployment nodes, progressive zoom, visual diagrams, dynamic scenarios, and component-level detail. But it lacks ownership, typed APIs, resources, lifecycle, and domain organization.
Can Backstage replace C4? Partially. For inventory and dependency concerns, Backstage is superior. For visualization and design-time communication, C4 remains necessary.
Can Backstage + ArchiMate replace C4? For information coverage, yes. For communication design and developer experience, no.
What's the ideal combination? ArchiMate for enterprise semantics, Backstage for operational catalog, C4 for design-time visualization. Each owns a different concern. None duplicates the others.

References