One of the more common landscape maps that I’ve encountered is the application inventory. Simply put, it’s a diagram that shows every single application in an organization, often along with extra information about the applications. So, this would seem to be a simple diagram to create, and indeed in a vacuum, it would be. But we don’t create these diagrams for recreation – they have a purpose, so it’s worth remembering what the purpose of the diagram is.
As described in the first post in this series, I (and Orbus Software) tend to be skeptical of huge landscape diagrams from the point of usability, but they can have value as a demonstration to senior management of the depth of analysis that has taken place. This is why simply dropping all of the applications that we know about onto the diagram will not be enough by itself – it does not look substantial enough, and does not convey enough of the analysis and information that exists for these applications. So, in the rest of this post, let’s consider how to remedy that.
The first thing that we want to do is to establish some structure for the applications – in other words, a classification scheme. There are several ways that we could classify them. One way that suggests itself is by the business unit that uses an application, but this has the obvious problem that many applications will be used by several business units within the organization. A second option is by some attribute such as business criticality, but this risks having a small number of categories, which will make the diagram harder to navigate as it will have less subdivisions.
The purpose of any taxonomy is to enable people to find and navigate information – so in practice the best approach is to define a set of arbitrary categories that can be informed by (but which will not be exactly the same as) the core business functions that they support. The reason for doing this is that such a taxonomy, while arbitrary, meets the test of being navigable to the audience (executives).
With the organization of the applications established, the second way that we can embellish the diagram to have it provide greater value is to visually show various data points about the applications. So this means that the next step is to define what extra information to show. In other words, what extra attributes might we want to display for each application? The rule of thumb in such a case is always – what information, what attributes, might decide or alter a decision?
Some examples of possible attributes might be: vendor; rated stability; rated criticality; internal/external facing.
Now, the recommended way to show such information is by icons on the shapes representing the applications. There are other ways – text annotations, and it’s possible to color the shapes by value for one attribute, but I’m going to recommend against this approach. Text annotations tend to take up more space than icon sets, making an already large diagram more ‘busy’ than it has to be.
So in summary – arrange the applications according to a taxonomy that is based on, but not necessarily the same as, business functions; and choose attributes to show graphically through icon annotations. This provides a visually appealing way to show an application catalog as a landscape diagram.
Next, the Application Communication Diagram...