Modeling sound bites can be an enterprise architect's greatest friend when trying to communicate and persuade. Here are our tried and tested top 5!
It’s the nature of working in a large organization that persuasion becomes a core business skill. Advocacy and the ability to win people over to your side is as much a part of architecture as having the knowledge and experience to come to a good solution to a given problem. Now, persuasion and communication skills are a very large topic in and of themselves, and not something that you can begin to cover in one article.
But one technique in the constellation of persuasion techniques is the sound bite - a short, pithy phrase that captures the core of a point. The phrase itself has some negative connotations, being associated with the modern obsession with ‘spin’ and ‘message’ – especially in politics. But, like an elevator statement, a sound bite has value in that it maximizes the communication in a short time, and ‘opens the door’ to a deeper discussion.
In this post, I’m going to outline five such phrases that I’ve found useful, with a brief explanation of each one.
1. “We don't curse a globe of the earth for not having a molten core”
One of the key points about any model is that it omits unnecessary details. This is needed, because otherwise the important details get submerged in the unimportant ones. We don’t need an old-style globe of the earth to contain a mantle, inner core and outer core –because we’re not using it to understand the structure of the earth.
2. “Models expose complexity, they don’t create it”
One complaint that business people can make is that models create complexity out of nothing. It’s possible to argue that business people shouldn’t see the models that architects create, but when they do, they’ll often question why a simple situation being made so complex. What they don’t understand is that the model is exposing subtleties that were not immediately obvious – and the very act of modeling exposed the subtleties – which was the whole purpose of modeling in the first place.
3. “What question does this diagram answer?”
Models are, at their heart, a mechanism to enable communications. But in an IT environment, the overall picture is going to be too complex for an outsider to understand, so a common technique is to selectively show information that meets a specific stakeholders needs – a technique known as viewpoints. The ISO 42010 standard recommends driving viewpoints from stakeholder concerns, but this moves the problem to identifying the stakeholder concern. A good approach to cut through to the core is to pose the question “what question does this diagram answer?”
4. “A model that tells you everything - actually tells you nothing”
One anti-pattern that I’ve seen a few times is colossal diagrams that attempt to show the entirety of an organizations operations on a few sheets that are maybe 3 meters by 2 meters. Often there’ll be a separate room set aside where they are hung. The issue is that when you have a diagram that shows everything, only someone intimately familiar with it can actually find any information on it. So while there can be good political reasons for creating such diagrams (i.e. they look impressive), as a communications tool they’re largely useless.
5. “Terminology is the alternative to talking about things that do things with other things”
One frustration that laymen have in understanding models is their terminology – business service, application function, application component, and so on. To someone unused to modeling, it can seem like manufactured complexity. But there’s a good reason for making a distinction between an application function and an application component – it establishes a vocabulary, without which you’re reduced to talking about different kinds of ‘things’ that do ‘things’ with other ‘things’. And the result looks a bit like this:
What about you? What modeling sound bites have served you well in the past?