The phrase landscape diagram is usually used by analogy – no-one believes that the application communications, or project plans are things that you can walk over. But there is one diagram in this set that does deal with physical locations –the deployment diagram.
Following the approach that we’ve laid out, let’s consider what question such a diagram answers and what it contains.
Question – “what applications are hosted on what servers in what locations?”
And from this it follows that the entities that we care about on this diagram are applications, servers and locations.
So how do we go about laying this out?
Let’s start with some observations about the nature of the entities that we’ll be working with. An application can run on multiple servers – in fact, resiliency requires that this has to be the case, at least for mission-critical applications. So we can assume that many, if not most, applications are going to be mapped to more than one server.
However, the situation is better for server-locations mappings, as I’m unaware of any organization that has managed to have the same physical server in more than one location at once. This means that we can use nesting to show which servers are in which locations, but we have to revert to connectors for showing application-server mappings.
The second key point that pertains to this kind of diagram is that from experience, there will be a relatively small number of locations (possibly only a main datacenter and a backup) and a much, much larger number of servers and applications.
With this in mind, to be able to minimize the number of connectors we can start by arranging the locations as large boxes around the edges of the diagram, with the applications in the center. We can then place the servers in the various locations to show which servers are hosted in which locations.
Once we’ve done this, we can show the application-server mappings by drawing connectors between the applications and the servers that host them.
Now, one obstacle in performing this application-server mapping is the effort to identify the mappings from applications to servers, and servers to locations. Granted, if some form of automated discovery has taken place this becomes easier… however, with or without automated discovery, some effort is involved.
In light of this, it may be necessary to compromise and only create this diagram for high priority applications (assuming that applications have been rated for this – alternatively, other ways to filter would be appropriate if they are of interest to the organization) – in such cases it may be useful to show the unmapped applications on the diagram, to make it explicit that only the high priority applications have been mapped. The result would be a diagram similar to that shown below.
In this diagram, there are two locations, with the applications shown as blue boxes, the servers shown as green boxes and the locations as grey boxes. There’s a few points to note here.
First, only a small number of applications have been mapped so far – the unmapped applications are shown in a ‘holding pen’ in the top right corner. Second, there are still a few servers that are yet to be mapped, and these are shown outside of the two locations. So, this diagram effectively presents the current state of analysis visually by the nature of the model.
In this series, I have covered some of the key 'giant' landscape diagrams you may encounter. To round off, next week I'm going to talk about some alternative approaches to employing these diagrams.