Why create models?
EOModeller blog · post 001
Most architects can describe how they model in considerable detail — the notation, the tool, the viewpoint, the metamodel. Fewer can say why. The tools are there, the training was given, the job demands it. The work gets done. But the why is usually left implicit, and when I press architects to articulate it the answers are thinner than they should be. "Because we have to document it." "For the repository." "Because TOGAF says so."
These are reasons, but they are partial ones. They describe a single purpose — usually documentation — and miss the others, which are arguably more important. I've spent the last year paying attention to what architects are actually doing when they model, in meetings and in their own time, and I've come to think we model for more reasons than we generally admit. And our tools, mostly, are built for only one of them.
Before getting to the list, though, a distinction that usually gets skipped.
Diagrams and models are not the same thing
Most of what gets produced in architecture meetings are diagrams, not models. The two words are often used interchangeably. They shouldn't be.
A diagram is a picture. It renders information visually. When you draw three rectangles, label them, and connect them with arrows, you have made a diagram. The diagram may or may not carry meaning underneath — often the meaning exists only in the head of the person who drew it, and is lost when they move on.
A model is something quite different. A model has semantics: each element in it is of a type — a Service, a Database, a Business Process, an Actor — and the types come from a vocabulary that constrains what the element means and how it can be related to other elements. A model has identity: the "Customer" I add to my model is the same Customer whether I show it in a context diagram, a class diagram, or a data flow. A model has rules: ArchiMate prescribes which kinds of elements can relate to which, and how; UML has a metamodel; C4 has levels with specific roles at each. A model can be queried — "what uses this Service?" is a question the model can answer. A diagram, as such, cannot.
The relationship between the two is that a diagram is a view onto a model. One model supports many diagrams. If I delete a diagram, the underlying elements persist; they just aren't shown in that particular view. If I update an element, every diagram that shows it can reflect the update automatically, because the diagrams are all looking at the same thing.
Excalidraw produces diagrams and only diagrams. Mermaid produces diagrams. Most of what architects draw in meetings is diagrams. Sparx, Bizzdesign, Ardoq, and EOModeller produce models, with diagrams as views. This is the dividing line between the two tool categories — not aesthetic, not price, not deployment model, but whether the output carries its own semantic backbone.
Why the distinction matters is that once you know what you're making, you can ask what you're making it for. And the answer is richer than most people assume.
Seven reasons — and one to be careful about
I've been testing a list of reasons architects model. There are seven that I think are genuinely distinct, and an eighth that I think deserves to be named and treated carefully.
1. To think
The model is an externalisation of cognition. When an architect draws, the drawing surface becomes working memory; placing an element is reasoning made visible. In this mode, much of what gets drawn is wrong or provisional or abandoned — and that is correct. The value is in the thinking, not the artefact.
This is what whiteboards and Excalidraw are genuinely good at, and what most enterprise modelling tools are genuinely bad at. A tool that demands commitment before thought has stabilised — type this element, validate that relationship, populate these attributes — prevents thinking. The architect's mind cannot work that way under that friction, so the architect works elsewhere. This is why the Excalidraw-in-the-Bizzdesign-shop phenomenon exists: the formal tool has taken an implicit position that thinking is not real work, and architects vote against it every time they open a different tab.
2. To align
Alignment is getting a group of people to share an understanding, in real time. It is different from communication, because the goal is not to transmit a fixed message to an audience but to converge multiple people on a common picture. The model is a coordination device; the conversation the model provokes is where the alignment actually happens, and the model is the excuse for that conversation.
This is why "walking through" a diagram live is so much more effective than sending it. The same diagram pasted into a document is a communication artefact. Drawn on a whiteboard with four people in the room, with people pointing at it and arguing about it and adding scribbles, it is an alignment artefact. These are not the same thing, even though they look identical when photographed.
3. To decide
Decision modelling is teleological: the model exists to support a specific commitment. It is distinct from thinking (which is open-ended and exploratory) and from documenting (which follows commitment rather than preceding it). The candidate-architecture-A-versus-B diagram is decision modelling. The whiteboard conversation that ends with "right, so we'll use the queue approach" is decision modelling. The architecture decision record is a deliberate attempt to make decision modelling a first-class artefact; most decisions, though, are mediated through diagrams that never become ADRs.
Tools that force you to pick one model and develop it fully prevent decision modelling, because decisions require holding several candidates lightly and discarding most of them. The friction of committing to a candidate in the tool is higher than the friction of merely considering it, so the candidate never makes it into the tool. The decision gets made anyway — architects have to decide things — but it gets made outside the tool's reach, and the reasoning is lost.
4. To communicate
The model becomes an artefact directed at an audience. Communication modelling is distinct from documentation because it is shaped by the assumed reader. An executive summary is not a bad HLSD; it is a different kind of artefact with a different purpose, and the model behind it needs to be filtered, abstracted, or re-projected to suit the audience.
The same underlying model often serves multiple communication artefacts — one view for executives, another for implementers, another for reviewers, another for auditors. The flexibility of producing multiple directed views from one underlying model is one of modelling's clearest wins over diagramming. A diagram drawn for executives and a diagram drawn for implementers are two different diagrams; the model they draw from, if it exists, is one.
5. To document
Documentation is the conservative use of models. The architect captures an already-understood thing so it persists. The model in this mode is a record — it describes what is, or what was decided, at a point in time. Documentation is what the enterprise repositories are mostly for: storing decisions so they survive the architects who made them.
The trouble is that most tools assume documentation is the only reason to model, which is why they privilege completeness and conformance over speed and exploration. That works for the documentation case and actively breaks the thinking and aligning cases. A great deal of enterprise architecture tooling is, in effect, optimised for a single purpose out of seven, and then deployed as though it served all of them.
6. To learn
Models serve as a pedagogical instrument. Someone new to a domain — a new team member, a student, a developer joining a codebase, an architect moving from one sector to another — studies existing diagrams to get oriented. The model in this mode teaches.
This purpose matters more than it seems, because it is where the quality of the notation produces real leverage. Clarity, conventions, visual hygiene. A good model teaches; a bad model confuses; a great model causes the reader to have the insight the original architect had. Most tools optimise for the producer's convenience rather than the learner's clarity, which is one reason institutional architectural knowledge fails to transfer. New joiners do not read the repository; they ask colleagues. The repository is pedagogically inert, and everyone knows it.
7. To reason about change
Models allow an architect to work out the consequences of a proposed change. "If we deprecate this service, what breaks?" "If this system goes to the cloud, which integrations are affected?" "What depends on this database?"
This is a genuinely distinct purpose, because it requires the model to be queryable. A diagram alone cannot answer these questions — it has no structure beyond its visual layout. A model with typed relationships and preserved element identity can, and the answers can be fed back into planning and risk work. This is where graph-native tools like Ardoq have a real structural advantage, and where the current generation of AI assistants is beginning to add surprising leverage: LLMs can reason over a structured model in ways that humans find tedious, generating impact analyses that a human would take hours to produce.
The eighth — and why I'm naming it carefully
There is a plausible eighth purpose: to govern. Models used to enforce conformance. Are we doing what we said we would do? Do these applications match the approved reference architecture? This is what LeanIX, Bizzdesign, and the enterprise platforms spend most of their effort on, and it is a real purpose for real organisations.
I am listing governance separately and tentatively, because it tends to pull tools toward scope they cannot serve well for the earlier purposes. Once you are building governance workflows you are also building approval gates, audit logs, RBAC, and SSO — and the cost of those features is paid by the architect trying to think on a Tuesday morning. The tools that are best at governance are usually the worst at thinking and aligning, and this is not a coincidence. It is what happens when a tool is optimised for the organisation buying it rather than the architect using it.
This is a trap worth naming. Governance is a legitimate purpose, but building for it is how modelling tools drift toward serving the enterprise rather than the architect. I do not think EOModeller should try to serve governance, and I do not think most tools that try to serve thinking and governance end up serving either well.
What this means
Seven purposes — or eight, if you count governance — and most tools serve only one or two of them. Bizzdesign serves documentation and governance, and actively obstructs thinking. Excalidraw serves thinking and aligning, and cannot support documentation or reasoning about change. Sparx tries to do everything and ends up with an enormous feature surface and a UX that matches none of the purposes well. Ardoq serves reasoning-about-change beautifully, at the cost of requiring heavy upfront structure that is hostile to early thinking.
A better question than "which tool should I use?" is "what am I modelling for this time?" — and then picking the tool that serves that purpose. The trouble is that the purpose shifts within a single piece of work, often within a single hour. The sketch I drew to think becomes the thing I use to align the team, which becomes the artefact I communicate to leadership, which becomes the reference documentation we later maintain. Each transition currently requires re-authoring into a different tool, and because re-authoring is expensive it mostly does not happen. Artefacts are stranded at whatever purpose the tool they were born in permits.
This is the problem that has drawn me back to my original idea for EOModeller. It is not a diagramming tool, and it is not an enterprise repository. It is a modelling tool for practising architects, built around the observation that the same artefact often needs to serve several of these purposes over its life. The primary purposes — the ones the tool is genuinely built for — are thinking, aligning, and deciding. Communication, documentation, and learning come as consequences. Reasoning about change is a longer-term capability that the metamodel has to mature into. Governance is deliberately not on the list.
I will have more to say about how the tool supports this. In particular, there's a two-dimensional space — formality and detail — that every architectural artefact lives in, and moves through as it matures. That's the next post.
For now, though, the prior question is the one worth sitting with. Why do we model? Not how. Not with what. Why. I think the answer is that we model for at least seven distinct reasons, and pretending otherwise is why our tools fail us.
EOModeller is in pre-release development. If the framing in this post resonates and you want to hear when the tool is ready, request early access. The book that accompanies the tool, Models That Matter, is in draft.