In the past seven articles I’ve talked about recommendations for creating giant ‘landscape’ diagrams that show all aspects of a situation. But, as I pointed out in the first post, both Orbus Software and I have historically been skeptical about the value of such diagrams, and the main use for them in my mind is to impress management. In this last post, I’m going to talk about an alternative way to achieve the same goal, which will impose less overhead than spending the time arranging and formatting the diagrams in question.
As stated before, I have not seen a situation where large landscape diagrams such as these are used in day-to-day analysis. Instead, these huge diagrams really serve two purposes around stakeholder management. First, they demonstrate how complicated the situation is, and second, they provide a level of comfort that the people creating and managing the models are actually doing something that is of value.
The first alternative technique that I’m going to propose is the use of dashboards to report the status of the program. A dashboard used in this way would show a summary of the state of the model – no more, no less. No need to show every connector on the diagram, just show a count of them. No need to show every application on a diagram – simply summarize the information.
The second technique is one of war stories – actively looking for cases where the model helped people in some way and making sure to mention them when in front of the executive team. People can relate to success stories far more than they can relate to abstract discussions of possible benefits.
“Having our conceptual data model mapped to applications meant that we could analyze the impact of the European Court’s decision on Safe Harbor in less than a week.”
“Having applications mapped to user communities allowed us to prioritize which applications we could safely wind down support for during the spending freeze last year”
Of course, this does face one challenge - it’s hard to reference success stories in the early stages of a program. In this case, the workaround is to reference previous problems that could have been solved. For example:
“Do you remember the debacle with the divestment of the consumer technology unit last year? We had no idea which shared systems they used. This will address this.”
Now, I realize that this might cause some pushback – it comes across as a salesy technique. And it is, I’ll make no apologies for this. Ultimately, the purpose of these, and the purpose of the large diagrams, is to sell executives to support the program. The issue with relying on a bunch of large diagrams is that it’s metaphorically dumping your better mousetrap on their desk and waiting for the applause.
In this series I’ve talked through ways to create the large diagrams that seem to show up in architecture practices, but in each case it’s been with the acceptance that, given that people will choose to create them, we can at least add value by offering a best practice for each type of diagram. In this post, I’ve tried to offer a couple of alternative approaches that can achieve the same goal more effectively while imposing less overhead on the architecture team.