Diagramming vs modelling

As an industry, we've tended to prefer diagramming over modelling, primarily because the barrier to entry is relatively low, and it's seen as a much simpler task. When diagramming, you're typically creating one or more separate diagrams, often with an ad hoc notation, using tools (e.g. Microsoft Visio or a whiteboard) that don't understand anything about the semantics of your diagrams. The domain language of diagramming tools is really just "boxes and lines", so you can't ask them questions such as "what dependencies does component X have?". Additionally, reusing diagram elements across diagrams is usually done by duplication (i.e. copying and pasting), thereby putting the responsibility on you to keep diagrams in sync when you rename such elements.

With modelling, you're building up a non-visual model of something (e.g. the software architecture of a software system), and then creating different views (e.g. diagrams) on top of that model. This requires a little more rigour, but the result is a single definition of all elements and the relationships between them. This, in turn, allows modelling tools to understand the semantics of what you're trying to do, and provide additional intelligence on top of the model. It also allows modelling tools to provide alternative visualisations, often automatically.

Comparison

Structurizr Express is a text-based diagramming tool, whereas the full version of Structurizr is a modelling tool.

Structurizr Express

(diagramming)

Structurizr (full version)

(modelling)

Create multiple views from a single model?

Structurizr Express is a text-based diagramming tool, built specifically to support the C4 model, with the JSON/YAML definition describing what to show on the diagram.

A Structurizr workspace allows you to create multiple views (diagrams) based upon a single definition of elements and relationships (a model).

Separation of content and presentation?

For simplicity, the Structurizr Express definition (JSON/YAML) mixes the content (the definition of elements/relationships) and the presentation (the layout information).

A Structurizr workspace contains both the content (model) and presentation (views), although these are kept separate. This allows you to create multiple diagrams from the same model.

Consistency across diagrams?

Since every Structurizr Express diagram is created from a separate JSON/YAML definition, changes to that definition only affect a single diagram. If you rename an element in one diagram definition, you need to ensure that it's also renamed in other diagram definitions too.

Structurizr's views use references to model elements and relationships. Changes to an element or relationship definition will be automatically reflected on all diagrams where they appear.

Multiple diagram types?

System Landscape, System Context, Container, Component and Dynamic diagrams.

System Landscape, System Context, Container, Component, Dynamic and Deployment diagrams. Filtered views can also be created on top of the static structure diagrams.

Automatic, alternative visualisations?

Structurizr Express is only able to create the above diagrams.

Structurizr can use the information in the model (elements and relationships) to create a number of alternative visualisations. These allow you to explore the model, and answer questions related to aspects such as dependencies and the impact of change when restructuring.

Scalable?

The more diagrams you need, the more separate JSON/YAML definitions you have, which in turn increases the maintenance effort and complexity of keeping them in sync.

Having a single definition of elements and relationships reduces maintenance effort and complexity.

Recommendations

In summary, Structurizr Express is designed for those situations where you need one or two short-lived diagrams. For long-term usage (e.g. documentation), we recommend using the full workspace-based version of Structurizr instead.