Have you ever created a well-defined and precise model describing the architecture of your project or business – only to see that it is not really used? You end up with outdated diagrams, a beautiful meta-model and an advanced modelling tool that can generate reports and XML, while your key stakeholders keep discussing their stupid “PowerPoint pictures”! We certainly see a lot of frustration and wasted effort coming from this. What is going on?
There are likely several reasons. However, the primary is lack of understanding that modelling is about communication and different viewpoints. We architects must understand that modelling is not about having some sort of universally valuable truth appear out of boxes and relationships. All models are abstractions with the purpose to ensure actions performed by stakeholders are aligned and leading in the same direction. Our stakeholders will do this within their own competence and role in the organisation. So, they will act based on their own experience, worldview and motivation.
Therefore, what is actionable and meaningful to one set of stakeholders is more or less irrelevant to the next. In the modelling theory this is acknowledged and treated as stakeholders having “viewpoints” addressed with different “views” to the same model. This is however rarely adopted in architecture functions. The big modelling tools on the market are designed by software engineers with a strong focus of software development. This strengthens our bias towards those building the solution with views of specification and documentation. It leaves little attention for those owning the solution (business owner) with for example views of the impact of creating new business models.
In our experience a tool-focused “engineer-style” modelling pacifies our most important stakeholders. They don’t really understand the models, the models are not really addressing their concerns, and they can’t change them anyway. We try to make them understand “the model” rather than trying to understand their concerns and facilitate discussions of problems and solutions actionable and meaningful for them.
We can create the most beautiful architectures (in the tool or architecture language). However, we fail if we do not translate this into a story relevant for our stakeholders. As young and eager architects we have probably all been guilty in using our architecture models to explain problems and solutions to senior business stakeholders – that did not work! Instead we have found, that we need to turn the architecture models into a business story for the senior businesspeople and a more technical story for teams. Same solution, but different views and stories with varied levels of detail. However, all enabling the stakeholders to act in an aligned way.
Therefore, we believe best architecture practices value communication and stakeholder engagement over intricate modelling. Perhaps we do need intricate modelling, but it must be justified by a need to engage with different stakeholders and have them act in concert.
What is your experience with architecture modelling and stakeholder engagement?