Introduction and objectives 🔗

In this article, I will introduce a software architecture metamodel that I find useful for agile digital transformation of complex enterprises. The metamodel is based on ideas from TOGAF and C4 and it provides a simple yet powerful approach to the creation of software architecture models across the four architectural areas of Business, Data, System and Deployment.

If the metamodel proposed here can be used as an inspiration for other people in other companies, this article has fulfilled its purpose.

What is a metamodel? 🔗

At first, we need to agree what we mean by a metamodel and why it matters for software architects. We will start from Wikipedia on Metamodel:

Here is how I like to explain it:

The metamodel is normally created by enterprise architects, whereas the model is created by software architects — often called solution architects. The model is often called a software architecture or solution architecture.

The following diagram depicts it.

In some organizations the terminology could be slightly different, but the idea is the same.

In most places I have worked, there is no established metamodel. In fact, many people are not really aware of the need of a metamodel for software architecture, and we end up with a Babylonian mess where it is very hard to have a meaningful conversation about software architecture, because the very terminology is unclear and not agreed upon.

True, often enterprise architects are hired, but rarely have I seen them succeeding in the most fundamental part: to define the metamodel and hammer out the very language by which we even discuss software architecture.

TOGAF metamodel 🔗

To appreciate the model to be proposed later in this article, let us look at the metamodel coming from TOGAF v9.2 section 30.3:

Reading the diagram is challenging due to the amount of information packed into the diagram. We can make an extract of information by focusing on some of the details and leaving out others. I prefer to look at it in this way:

Even with this simplification, I find the metamodel too ambitious.

For instance, it assumes that we can really drill out concepts such as Business Service, Functions, Processes and Business Capabilities, give them all proper names, describe them and distinguish them. Next we need to relate them to each other and keep track of which processes are realized by which functions etc. I would claim that if any organization ever managed to create such an elaborate analysis of how their business operates, then the business would be either extremely simple, or the model would be understandable to only a few highly specialized architects.

I may be wrong and would be happy to be pointed to a real-world case where the TOGAF enterprise model turned out to be effective for an agile digital transformation.

Proposed metamodel 🔗

Now that we have seen the complexity of the TOGAF metamodel, let us consider the metamodel I am proposing instead:

The following should be noted:

• The metamodel is spanning BUSINESS, DATA, SYSTEM and DEPLOYMENT.
• I assume we work with a business for which the concept of Value Stream from LEAN thinking is well understood. I also assume that it makes sense to break down the value stream in business Capabilities. If this lingo does not fit with the business, some other concepts should be used here instead.
• I assume we work under some kind of agile methodology, in which case the concepts of Epics, Stories and Actors should be clear. If this is not the case, some other concepts such as Function, Requirement and Role could fit better.
• Stories can relate to each other in various ways. For instance, one story can be “following” another story or it could be a “specialization of” another story. These relationships can be more or less formally modelled. If this relationship is too “theoretical” it can be dropped from the metamodel.
• I assume the entire business can be broken down into some Data Areas each holding a number of Entities. Entities can be thought of as tables of data or some other kind of clustering of data. In DDD terms it would be called aggregates.
• The relationship between Entities can be thought of as traditional entity-relationship such as many-to-many relationships etc.
• The relationship between System and Data Area is the idea that a system owns or uses data. This relationship is often overlooked when we are building software architecture models and this is a shame. Creating a mapping between systems (or applications) and the data they own or use is quite useful.
• The concept of System is sometimes called Solution or Application. In the C4-model is it mostly called Software System.
• The concept of Component is called Container in the C4 model. It represents the constituent parts of a software system such as a frontend, a backend, a database etc.
• The self-referencing relationship for Component integration represents such things as a backend connecting to a database or a frontend calling a REST-interface on a backend.
• Deployment Nodes can represent any concept from the infrastructure such as servers, clusters, hosts, containers, IaaS, PaaS, resource groups, subscriptions, VLANs etc.
• The relationship between Deployment Nodes can represent any topology in the infrastructure such as a server connected to a VLAN or a host machine being part of a Kubernetes cluster.
• The relationship between Deployment Nodes and a Component represents the deployment of a component in a running environment.

In order to understand how each part of the model is authored and how it allows the entire organization to collaborate on the model, the following diagram shows which roles would typically fill out each section of the model.

How it relates to the C4-model 🔗

Finally, let us compare with the metamodel from C4. The C4 model is not normally presented as a metamodel, but if you study the c4 website you can extract a metamodel along these lines.

This C4-inspired metamodel has a clear overlap with the model I am proposing, with the following differences:

• As already mentioned, what C4 calls Container, is called Component in the proposed model.
• The proposed model does not include level 3 and level 4 in the System area (marked by red). Not because they are not useful in some cases (they are), but rather because they are mostly relevant when we are dealing with the inner software architecture of a single system. Remember that the purpose of a metamodel is to facilitate communication and collaboration across large complex enterprises and hence it is the relationship between the 4 areas (business, data, system and deployment) that really matters. If you need level 3 and level 4 from the system area (marked by red), simply add them to your model.
• In the proposed metamodel we are adding DATA and BUSINESS as core parts of the model. C4 never intended to say anything in particular on that — which makes perfect sense given the objectives of C4. But for the purpose of creating a useful metamodel covering all needs for digital transformations, I have extended the metamodel to cover BUSINESS and DATA as well.

Architectural domains or areas 🔗

In the previous sections you probably noticed that both TOGAF and the proposed metamodel are divided into areas named something like BUSINESS, DATA etc. This division is used to create a high-level structure in the metamodel.

The following diagram shows the difference between the architecture areas covered by the proposed model, TOGAF and C4:

The following should be noted:

C4 is open-ended and does not say anything particular about how to model the DATA and BUSINESS areas. I have indicated this by leaving them out of C4 in the above picture.
What is called APPLICATION in TOGAF is called SYSTEM in C4 and the proposed model.
What is called TECHNOLOGY in TOGAF is called DEPLOYMENT in C4 and the proposed model.
The lines between the boxes indicates where the model has cross-links between the areas.
In the proposed model the DATA and SYSTEM areas are like siblings instead of in TOGAF where APPLICATION is subordinated to DATA. This is important as we need to create links between stories and data and stories and systems in order to properly model and understand the interplay of business features, systems and data.
NB: The idea of architecture areas is described here on Wikipedia where it is called Architecture Domains.

Conclusions 🔗

A new metamodel has been presented with the purpose of providing a common metamodel for digital transformations of complex enterprises. In my opinion and experience, this metamodel provides a simple yet powerful way of thinking and communicating about the architecture of a large complex enterprise. It is based on commonly accepted ideas from both TOGAF and C4, but still it is quite different.

I am not claiming that the metamodel in exactly this form should be applied. Rather, that each company should understand the importance of establishing a metamodel as the foundation for digital transformations and that the metamodel should be simple enough to work in reality. At the same time, the metamodel should cover the four architectural areas of BUSINESS, DATA, SYSTEM and DEPLOYMENT.

If the metamodel proposed here can be used as a starting point for such initiatives, the objective of this article has been met.