Blog 4 of 4: Using the Novius Architecture Framework

As I outlined previously, that takes craftsmanship; the architect needs to display knowledge, skills, and attitudes. But I also introduced a “briefcase” of tools for architects at Royal HaskoningDHV: the Novius Architecture Framework. In this blog, I’ll show how we use it to describe architecture and realise change.

Describing architecture using the framework

When we describe different kinds of architecture, we do it using principles and models. To show why each principle is important, each one is explained with a rationale, and is related to certain strategic objectives. By applying these principles to every change, we can be sure the solutions we’re working on are always broadly in line with the future vision for that organisation. Personally, I like to make this more concrete by adding a paragraph to each principle called “implications”

In previous blogs, I’ve used the metaphor of a city’s zoning plan to explain enterprise architecture. Here, the principle might be: “We build sustainable, climate-friendly residential areas.” The rationale could be achieving carbon neutrality by 2050. And the implication is incorporating trees and grass, with separate sewerage for rainwater.
Alongside principles, we describe architecture using models. This has two stages. First, we decide what we’re trying to achieve with the model: which message are we conveying, and to whom?

Then, once that’s agreed, we draw up the model using all the building blocks at our disposal, both inside and outside the organisation. These might include existing enterprise architecture, as well as reference architecture and patterns.
Some models can only be used once. But most of them – like the enterprise architecture and domain architectures – will need to be used repeatedly and understood in a variety of contexts. It’s therefore important to reach clear agreements in advance about layout and language use.

This is why we use a framework and metamodel.

Explaining the Novius Architecture Framework

Put simply, an architectural framework is a way of arranging all the organisational parts of a business. You can think of it like a bookcase, that’s filled with services, channels, departments, business functions, information, applications, and devices.

But the way items are arranged on those shelves is not random; we apply a specific logic that shows how everything is connected. So the framework helps us to understand how changes in one part of the business affects the others – for example, the consequences for information technology

We can also look in the other direction. For example, we can look at a new technology, and deduce exactly where it can bring benefits to processes and services.
I’m no expert on city zoning plans, but you can imagine how important it is to understand what a neighborhood or building is for, and how all the functions relate to each other. If you build an office or a school, what transport connections and utilities will it need?

There are several enterprise architecture frameworks on the market; each contains broadly the same content, but arranges it in a different way. We use our own framework because it emphasises what we believe is important: the ability to look at the various parts of an organisation in a coherent way.

Compared to other frameworks, ours promotes a balance between business and IT. This is unusual, and gives the business side more prominence than we might otherwise see.
As well as looking inside the business, processes, and organisation, there’s a place in our framework for external priorities like customers and service provision. That’s why the business exists, after all. It also makes a clear distinction between logical and physical aspects: what we need, and how we’ll achieve it.

Our architecture metamodel and language

Models come in many shapes and sizes, so it’s important that we can describe them in a consistent way. We therefore use a common language, ArchiMate.

ArchiMate gives us guidelines about which elements and relationships we can use, much like words and grammar in a spoken language. We can build these into models, which are the equivalent of sentences. And these can, in turn, become part of a larger story: the business, domain, or project architecture.

And like any language, these rules give us many ways to express ourselves. Over time, the language has expanded to include additional concepts that are only useful for specific cases. This gives us too many options in some areas, and in others it’s not explicit enough about certain distinctions.

We therefore needed extra agreements about how we use the language in practice – and we recorded those in our metamodel. This shows the ArchiMate elements and relations we use most often in practice, mapped onto our own architecture framework.

While the metamodel shows only the parts of ArchiMate we use most often, we can use other elements if we need them. It works as a guideline, or a starting point – and we can adapt it as needed within the limits of the language.

This shared language helps us to make qualitative models, store them in a structured and recognisable way, and re-use parts of them when appropriate. It’s especially helpful for architects when sharing ideas with colleagues.

However, ArchiMate is less useful for communicating with stakeholders. Its system of symbols and colour coding helps us to create pure models, but can be confusing for non-architects.

So it’s important to be creative, and use other tools to visualise our blocks and arrows – for example, making an informal version of the model in PowerPoint or another similar program, using symbols the target group will understand.

Crucially, everyone still needs to talk about the same elements. So even these informal models still need to reflect the agreements and information in the metamodel. This way, we can ensure clarity and prevent misunderstanding about changes and their implications