Generally when we create models of our process or architecture, the goal is to gain insight to assist with the high-level view – whether for enterprise planning, domain planning or simple solutions architecture. But it turns out that the current state model can be used for another purpose as well – diagnosing and recovering from problems. In this post I'm going to outline some specific observations on how I've seen current state models used for fault fixing.
The first consideration in using a current state model for this purpose is one of how the model is shared. Many modeling tools are licensed on a per-seat basis; and they can be somewhat complex to use (much, but not all of the complexity is inherent in the nature of creating and editing models). It's with this in mind that most tools provide some kind of web publication capability, designed to share models with a wider audience – and it's likely that this will be how second-line support, or whoever is using the model for fault diagnosis, will access the model.
This leads to a couple of considerations. First of all, to maximize the usability of a current state model in supporting fault diagnosis, it's important that people can find the parts of the model that can help them. So the appropriate consideration needs to be given to the ability to search the model. Sensible naming conventions and proper metadata design – attributes and tagging needs to be taken into account. In particular, attention needs to be given to how the search options work while using the publication interface. Some modeling tools have a less functional search capability in their online interface – and design of the search metadata needs to be aware of this.
A second consideration is one of scope. Given that you are using the current state model in this way, it can be tempting to expand the scope of the model beyond what is sensible. For example, it might be tempting to start recording the full network design, including VLANs and IP addresses. Now, if this information is not being recorded anywhere else this is a stopgap, but a modeling tool is not a good substitute for a CMDB – they were design to do different things. Such scope creep is often justified by the phrase 'single source of truth', but in practice a tool can only be a good 'single source of truth' for one or perhaps two subjects.
The mention of IP addresses and VLANs brings me to the last consideration when using a current state model for fault fixing, and that is one of access control. IP addresses and VLANs are traditionally seen as sensitive information for an organization. As just mentioned, such information will likely be stored
elsewhere, but an organization might have other sensitive information that they need to control access to – for example a company that performs defense work might only have a certain subsection of their staff cleared to work on that area – so the models relating to that area would need to be similarly restricted. Consequently, this is a subject that needs to be taken into consideration. In particular, whether or not the publication interface that support staff might use can support access permissions in this way is something that needs to be carefully considered.