Meta-models in Software Architecture

Abstract: A meta-model is a model of a model. As architects and engineers, we are surrounded by plenty of useful meta-models. More than we learned to recognize intuitively. There are multiple practical benefits of approaching software architecture from the meta-model point of view. Understanding relationships between meta-models may help with closing some traditional gaps between organizational levels, contexts, and problems.

Daily, software architects and the people surrounding them need to deal with many meta-models. Some of them we easily recognise, while others are less obvious. Ignoring important but less common ones makes us less efficient in our communication and decision-making.

What is a meta-model?

A meta-model is a model of a model. For example, a C4 context diagram¹ is a model of a specific software system at a specific enterprise. The meta-model of the context diagram is the concepts, the relationships between them, and the associated rules:

• Concepts: system, relationship, persona, …
• Relationships: “Each system must have a name”, …
• Rules: “A name is a non-empty string”, …

Here is the “meta-model” definition that I found useful:

IF: you create an ontology, which is a set of terms naming concepts (classes) and relations, and you use that vocabulary to create a set of data (instances of the classes, and assertions that the instances are related to each other according to the specific relations in the vocabulary), and you think of the set of data you create as the model of your domain,

THEN: the ontology is the meta-model, and the set of data created is the model.

Whenever architects or engineers create a C4 diagram, they follow an ad-hoc C4 meta-model. It is ad-hoc because Simon Brown never formally defined a C4 meta-model for practical and pragmatic reasons. It is common to encounter very different interpretations of C4, even within the same organisation.

There are plenty of less obvious (or commonly thought of) software architecture meta-models:

• Architecture Decision Records (ADRs) are “concerns”, “architecture elements”, “rationales”, “stakeholders”, “actions”, etc.²
• Socio-technical systems (STS) are “structures”, “physical systems”, “people”, and “tasks”.³
• Business Capability maps of an enterprise are “capabilities”, “capability instances”, “domains”, “applications” etc.⁴

The examples above overlap: “architecture elements” affected by architecture decisions are often the same things as physical systems and applications in the STS and Business Capability meta-models respect. In other words, there is a way to formally link multiple meta-models together by defining a mapping or transformation rule.

Architects trained in frameworks like TOGAF might be familiar with the elaborate Content Metamodel⁵. While it looks very detailed, it isn’t apparent how to benefit from it and any other meta-models in practice. I am also personally not convinced that full-blown (meta-)modelling of an enterprise using tools like ArchiMate is practical for relatively small, fluid, and fast-moving organisations like many of those I worked at.

Yet, these are a few useful practical, daily basis applications of meta-models:

• Reasoning across multiple contexts. Engineers and higher management operate within very different sets of meta-models. Finding a way to link those meta-models together and keeping them consistent might help with discovering gaps, mismatches, and contradictions. That is what makes me more efficient riding the architect elevator.
• Data foundations of architecture activities. When formalised in code, the meta-models can work as a framework for defining and automating technological insights, such as architecture fitness functions. It also opens opportunities for “querying” the architecture for the sake of exploration and education. With the recent breakthroughs and growing accessibility of the Large Language Models (LLMs) it is getting even more interesting, as we can now “speak” to our models.
• Aligning mental (meta-)models between colleagues. Meta-models are models by themselves and can act as a communication tool. So instead of trying to handwave preferences, “I prefer to express Kafka topics as separate C4 containers”, we can land the C4 meta-model we agree to and capture it in an ADR.
• And many others, such as team situational awareness, Decision Intelligence⁶, etc.

Each is a massive topic, many of which I am actively exploring. There’s undoubtedly lots of research on the topic out there. I would love to see them gradually turning into practical, repeatable, and lightweight practices.

— Alexey.