In the world of IT and architects a quote you might hear regularly is „All models are wrong, some are useful“ – George Box. The point being that a model is only a model when it purposefully abstracts some complexity of reality. If all details of reality are included it is no longer a model. If some abstraction or simplification is done, then it is a model, and therefore wrong – not reality.
How can something be wrong and yet useful? In order for a model to be wrong and yet useful it needs to abstract details which are unimportant or irrelevant to the intended stakeholders. These abstractions makes it easier for stakeholders to understand and grasp the details which are important.
Models are only useful when they are used
Since not all stakeholders need to understand the same aspects or level of detail in complex IT systems and landscapes, there are no universally wrong and useful models.
A „customer“ or „user“ centric approach helps to find out what really is useful to the intended audience.
Start by clarifying what the stakeholders would like to better understand? What questions do they have? What decisions would they like to take?
As a modeler it is necessary to understand the context of the model user. What is their understanding of the current system? What is the „domain“? Is there a shared understanding, a ubiquitous language?
What you want to do is fish out the unknowns, the misunderstandings, the assumptions that different stakeholders have. How can you easily visualize this to get people on the same page?
Live modeling
While consulting or facilitating I have found that live modeling, either digitally (using tools like Miro, Lucid or Powerpoint), or physically using whiteboards, has been an extremely value and useful skill. It doesn‘t just help everyone to get on the same page and bring clarity to the situation, it also ensures that my understanding and mental models are correct.
A picture is worth a thousand words. That is why models can be so useful. They ease the burden of understanding complex things.
Tailored models and a meta-model
I have found that the most benefit and value can be derived from having tailored models that are compatible rather than trying to have everything in one, complex and confusing model.
How do you ensure compatibility? By having an underlying meta-model that connects the most relevant aspects of your context.
For large-scale programs, projects and solutions I have found that having common visualization approaches (but distinct models for context, scope, deployment, integration, data flows, security, etc are helpful. But also here, consistency is key. Colors, shapes, format, etc. doing things consistent improves understanding hence increases their value.
A model that has a certain purpose in one part of your organization should look and feel the same as a similiar model for a different part of your organization. Also, ensure you have a key that explains what the different things mean. Don’t underestimate the importance of models being visually appealing. As much as I love the value of true modeling tools (e.g. Archimate, Sparx EA) vs diagraming tools, sometimes I had to adopt tools that enabled “prettier” outputs in order to get better stakeholder engagement.
In a future blog post I will share how I built an Enterprise Architecture level meta-model in a very large, distributed and federated corporation together with several colleagues, mostly Mike Douse and Nick White.
Tools and storage
Make it as easy as possible for relevant stakeholder to have access to the models that are applicable to them. If you are doing Enterprise Architecture, Solution Architecture, Software Architecture or other types of architecture then your users will be different and have differing skills and levels of comfort with things like Sparx Enterprise Architect, Archimate, Gitlab/Github and Documentation as code, etc.
If your model / diagram users and consumers have too high of a burden to use and find what you produce, it won’t be used. Depending on your context, try to have architecture models and diagrams as close as possible to the other relevant content, rather than having an information silo.
I have made useful models using all kinds of tools (whiteboards, archimate, UML, Powerpoint, Visio, Miro, Lucid, Mermaid, Gitpages, LeanIx, ServiceNow Designer, Sparx Enterprise Architect, Google Slides, etc.).
If you can, keeping things in version control and having documentation as code have clear advantages. But if your audience and environment are not at that level of maturity then think twice about the value vs cost.
“Maps”
If you want to call a model or diagram or map then I encourage you to consider some of Simom Wardley’s videos on “Wardley Maps”. In one of his videos he explains something to the effect of ‘maps have meaning’. Placement on a map means something. Moving something on a map should have meaning.
If location on an architecture “map” or a “City Map” doesn’t really meaning anything, then I suggest you don’t call it a “map”.
Final thoughts
In the end I don’t believe that there is a perfect tool or approach. Remember you are not striving for perfection, in fact you can‘t, because ‘all models are wrong‘. So start being wrong and useful!
Finally, if you have some models that are not being used, then stop. Listen, learn, get feedback and start producing outputs that are useful.
References I have found helpful
- The Software Architect Elevator (for this topic section 3 chapters 18-25) – Gregor Hohpe
- Fundamentals of Software Architecture (in particular chapter 21) – Mark Richards & Neal Ford
- Nick Tune – I really like lots of the diagrams he built using Miro and related to strategy, DDD, domains, etc.
- C4 model
- Mermaid
- Documenting Software Architectures: Views and Beyond
