There’s a phrase that you’ll sometimes see used in relation to enterprise models – “the map is not the territory”. It’s a useful reminder that a model is only a representation of something. Ordinance survey maps show roads as much wider than they really are, for readability. Enterprise models hide certain details for precisely the same reasons. At the same time a map is a snapshot in time - and so a model. Roads and buildings are built after the map is created; the enterprise architecture continues to evolve as new services are implemented, applications are retired and servers are installed.
So a given model is also a snapshot of the current state of something. It might be a snapshot of the actual current state of the enterprise. It might be the current application consolidation roadmap. But it’s a static record of a particular point in time.
Why this is of consequence is that snapshots can often have value long after they ceased to be valid – because they provide an audit trail. It can sometimes be helpful to compare and contrast how a previous snapshot matches up with the existing snapshot, to examine the evolution of the item being modeled. In other words, what has changed in the periods between the two snapshots were taken?
So it’s worth keeping old versions of models in order to perform this kind of comparison. A simple enough observation in theory, but in practice it raises a couple of factors that need to be considered in order to actually gain benefit from keeping old models.
The first question is – what is the model? Assuming the models are being kept in a repository of some sort, there will be version control on them… but usually on a view-per-view basis. There’s no guarantee that version 4 of one view matches version 4 of a different view in terms of referring to the same point in time. With this being the case, we need to investigate if the tool being used can take a wholesale copy of the model in question for archiving purposes. This might be by branching the model, or possibly by publishing an HTML snapshot of the model to a file store. I’ve seen both done with iServer.
The next question is what comparison methods are available, to identify and examine differences between the two models. This is naturally going to be dependent on the modeling tool being used.
The final question that we need to consider is one of archiving frequency. Put another way, what does ‘old’ mean? Once we’ve identified a way to archive off old models, we could take a copy every week – but that imposes an overhead in terms of time and storage that is unlikely to be justified. So how often should we create these model archives? The answer is going to be dependent on the development cycle of the organization – but once a year is a reasonable starting point.
It turns out that an enterprise model can have real value long after it has been superseded, as a record of how things have change. However, taking advantage of this opportunity requires careful consideration of several factors.