Last week we covered the Process Landscape. The next type of landscape diagram that I’m going to consider shows how the organization’s products or services are delivered by software. Or, to pose the elevator statement of the diagram:
“This diagram shows what external services to customers depend on what IT services, that are provided by what applications”.
Now, there are a number of challenges with this kind of diagram. First of all, even for a small number of products and applications, there can be a large number of services that are provided by just one application; second, each product will likely depend on a substantial number of services. Last of all, depending on the situation, a service might be delivered differently for different products...technically making it a different service.
For example, in a treasury banking situation, the way that settlements, pricing and trade recording take place will be done differently for equities, bonds and derivatives – different services, in effect – meaning that each product will depend on a set of different, product-specific services. Likewise, these services could well be provided by several different applications. So, even for a handful of products, we can very easily end up with a large number of services with a large number of mappings. The result is guaranteed to be a spider web of lines of epic proportions.
So – if the executives are insisting on such a diagram, how can we make it at least vaguely readable? As hinted at above, the greatest challenge is going to be how to disentangle the connectors leading from the services to the applications.
What we really need is a way to structure and collect the connectors together, something like the cable sleeves that you can use to collect all your power cables for a computer workstation. The way that we can achieve this is by introducing a set of ‘grouping’ bands between the applications and the services that they provide. Each connector traces vertically down to the band for the relevant application, then traces horizontally until it can trace vertically down to the application concerned.
Now, I have some concluding remarks about this diagram. First of all, it’s a pretty ugly. To some extent this could be addressed with some more careful choice of colors (I used the colors available in the tool I was using), but to some extent it’s unavoidable as a result of the information being depicted.
Second, in some ways this diagram is the closest to the infamous Stanley McChrystal diagram that I referenced at the start of this series – it conveys one message very clearly – “it’s really complicated, but at least we know everything about what hooks up to what.” In terms of using it for practical analysis or deriving workable insights, it’s not that helpful.
However, this diagram is a real one, which the head of projects for the bank concerned has posted up on their office wall – to my own surprise. However, this does also make it a perfect illustration of the principle that I had talked about – that it looks impressive and conveys the complexity of the domain. And you could argue that if this gains support from executive sponsors and allows the architects to get on with their job – then in that regard it becomes a useful architectural artifact.
Next week we'll look at the Migration Diagram.