Why we build models

I’m currently experimenting with various types of modelling diagrams, with a goal of finding which work best for us. But what do I mean by “best”, and who do I mean by “us”?

The original profession of architects, i.e. the people who design buildings, have been creating 3-D models for centuries. Minu shows some examples in her blog Architecture Ideas and explains why she uses models for her projects. We IT architects use models for pretty much the same reasons:

To study the design from different viewpoints
To explain (“sell”) the design to the people who will use it
To explain the design to the team who will build it
As a show piece, or perhaps for us, a reference model

Looking beyond individual projects, I would add two more reasons:

To explain the structure of the design to the people who will maintain and modify it
To review the overall portfolio and evaluate whether the mix of entities aligns with the overall strategy

In all these uses, the primary purpose for using models is to communicate the design. In IT, we will often start by getting agreement on the current state of affairs, and then change the models to show what the new state will be,

It’s clear that different stakeholders will be interested in different aspects of the design. For example:

Senior managers will want to know whether we have the right mix of IT services and suppliers
Business analysts may be interested in how the business processes are supported by the application components,
Technical staff may want to know where the applications will be hosted.
Data Protection Officers will want to know which data is held where and for what purposes,
Developers will want to know how the component they are working on will interact with others,
Software vendors will want to know how their product will be expected to fit into the existing digital estate
Service managers will want to know which technology their services rely on
Data Stewards will want to know who is using their data and why

To allow people to explore these different aspects, we create different views of the underlying model. This is where an enterprise architecture modelling tool pays dividends; it stores all the relationships between the entities in the model so that when we change something in one view, that change is captured and stored in the underlying model and shared with other relevant views. And that’s what I’m experimenting with, to find which views work best for the stakeholders that we’re working with.