MDG Technology for C4
Source
MDG Technology for C4 — Sparx Systems Europe
What it is
This is a partner product for Sparx Enterprise Architect that provides an MDG Technology specifically for the C4 model framework. It is the most directly EA-native option identified for enabling C4 notation, because it packages C4 modeling support into reusable Enterprise Architect technology rather than requiring users to build all stereotypes and toolboxes themselves.
C4 levels supported
The technology is intended to support the C4 model's progressive levels of abstraction:
- System Context — people, the system under discussion, and external systems.
- Container — applications, services, databases, and other major deployable or significant parts.
- Component — internal building blocks of a container.
- Code — implementation-level detail, where modeled.
Use the appropriate diagram level for the audience and purpose rather than placing all levels of detail on one diagram.
Likely EA capabilities provided
As an MDG Technology, the product is intended to provide a reusable modeling framework within EA. Verify the current product page and installer documentation for the exact feature set and version, but evaluation should cover:
- C4-specific element types or stereotypes
- C4 relationship types and relationship labels
- Toolboxes for creating C4 elements
- Diagram types or diagram patterns for C4 views
- C4 visual styling, shapes, and colors
- Tagged values or properties for descriptions and technology choices
- Documentation and reporting support
- Installation and deployment instructions for EA users
How to evaluate and enable it
- Open the source page and review the supplier, product description, supported EA versions, licensing, download terms, and release information.
- Obtain the MDG Technology package from the authorized supplier or download location.
- Scan and validate the package according to organizational security policy before installation.
- Install or import the technology in a non-production EA environment first.
- Confirm that the technology appears in EA's available technologies and that its toolboxes and diagram types load correctly.
- Create a pilot package for one system.
- Create a System Context view, then Container and Component views for the same system.
- Check that element names, descriptions, relationship labels, boundaries, and visual styles communicate the intended C4 meaning.
- Test collaboration in the target repository, including permissions, package control, version control, and concurrent access.
- Test documentation and publishing outputs such as HTML, PDF, or browser-based views where applicable.
- Record the installed technology version and define an upgrade procedure.
- Roll out the technology with a short modeling guide and example model.
Example
An Order Management model could use the technology as follows:
System Context:
Customer -> Order Management System : places orders
Order Management System -> Payment Service : authorizes payment
Container:
Order Management System
Web Application
Orders API
Orders Database
Component:
Orders API
Order Controller
Pricing Service
Payment Adapter
The exact element names, toolbox entries, relationship types, and diagram syntax should be taken from the installed technology and its current documentation rather than assumed from generic C4 notation.
Advantages
- More directly aligned with C4 in EA than a general UML approach.
- Avoids building a complete C4 MDG Technology from scratch.
- Promotes consistent element types, diagrams, relationships, and visual conventions.
- Keeps C4 views in the EA repository, where they can participate in EA collaboration, security, baselines, reporting, and publishing.
- Provides a stronger starting point for organization-wide adoption than informal naming conventions.
Disadvantages and risks
- It is a partner product, so support, licensing, pricing, maintenance, and release cadence may be separate from Sparx Systems' core EA product.
- Compatibility with the organization's EA release must be confirmed.
- The technology may impose conventions that need tailoring to local architecture standards.
- Custom or partner technologies can affect model portability and exchange with users who do not have the technology installed.
- Existing models may require conversion or rework if they use different C4 stereotypes.
- The product's exact current capabilities and terms should be verified from the supplier page before procurement or production use.
Comparison with other C4 options
| Option | Position relative to this technology |
|---|---|
| Build a custom C4 MDG Technology | More flexible, but requires greater development and maintenance effort. |
| UML Profile and stereotypes | Lighter-weight pilot; less complete tooling and visual guidance may be available. |
| Standard UML naming conventions | Fastest start, but relies on user discipline and does not enforce C4 semantics. |
| ArchiMate mapping | Better for integrating C4 views with enterprise architecture, but concepts do not map one-to-one. |
| C4-PlantUML or Structurizr | Strong external/documentation-as-code options, but require a defined integration boundary with EA. |
Recommended decision process
Use this MDG Technology as the first product to assess when the requirement is native C4 modeling inside Enterprise Architect. Before adoption, confirm:
- Supplier identity and support route
- License model and redistribution rights
- Supported EA versions and operating systems
- Installation and deployment method
- C4 levels and element types included
- Diagram, toolbox, shape, and tagged-value coverage
- Reporting and publishing behavior
- Repository and collaboration behavior
- Upgrade and backward-compatibility policy
- Export/import behavior when recipients lack the technology
If it meets these checks, it can replace the custom-MDG option for many teams. A small pilot should still precede enterprise rollout.