There’s a number of ways that an enterprise modeling initiative can fail - there are classic ones such as lack of sponsorship, failures to engage in proper stakeholder management, paralysis by analysis, and so on. There’s one way that is often not so obvious up front, one that can lead to a slow death of the program – where the model of the enterprise that is being used diverges so far from reality that it becomes unusable. On several occasions I’ve been at an organization that is starting up a program, and they’ll turn out to have a marvelous set of models that just, unfortunately, happen to be 3 years out of date.
The problem is that enterprise modeling is rather like an exercise program – you don’t get results by exercising furiously for 2 weeks and then never going to the gym again, and you don’t get results by establishing a current state and then not updating it. Modeling needs to be an ongoing process, and so it’s important to think about how you’ll maintain the model, and how you can keep the overhead of model maintenance below a manageable threshold.
Now, to some extent you can address this in which modeling repository tool you use. Ease of use should be an important consideration in tool selection, as well as the ability to easily locate and update models within whichever tool you use. At the same time, it’s helpful to consider the tradeoffs that exist around how you maintain your model(s) so that you use the right amount of effort for the job – and that is what I’m going to talk about here.
1. Volume
How many models do you have? Usually an organization will want to maintain some picture of where their IT systems are – the famous ‘current state’. While I’ve seen arguments that this is actually unnecessary, in practice all organizations use a current state model, whether it exists in some modeling tool or it’s distributed amongst the skulls of various local SMEs. So the question exists as to what other models might be necessary.
There might be a temptation to have a ‘draft’ architecture model, containing all architecture drafts, and yearly ‘future state’ architectures for expected future states. In general, I find that both impose too much overhead. New projects appear, new requirements occur, and trying to co-ordinate them into a single cohesive vision is nearly insurmountable.
It’s okay to have a location to store drafts, but trying to fit all projects across the organization into a set of coherent planned future state models simply imposes too much overhead. Likewise, attempting to maintain a coherent future state imposes too much overhead – with one exception. If a major transformation project is underway, such as a move to cloud services, then it can make sense to maintain a future state for this initiative, simply so that other projects can take account of it.
2. Accuracy
How often do you updates your models? In practice, there’s rarely a need to keep the model up to date in real time (i.e. as soon as changes are made), and in practice imposing a requirement to do so means that sooner or later the updates don’t get made (because of some crisis or other), so then they get forgotten. Instead, a target of weekly updates is better.
3. Access
It is vital to know who can access the model, and who is responsible for updating it. While it’s advisable to have at least two staff with editor access to the model, one should be the ‘owner’ of the model. A good candidate for the current state model will be a member of staff involved in the architecture review process, as they will then be aware of the architectural changes that are coming and also be able to use their familiarity with the current state to offer useful input into review.
4. Granularity
The final question to consider is what level of detail the model should contain. What relationships? What attributes should you track against each entity? This is perhaps the trickiest tradeoff to make, and often one that’s worth revisiting. The rule of thumb has to be: would this information be used as part of this model? Or to put it another way, would the planning activities that use this model possibly change as a result of considering this information?
Ultimately, deciding the right level for these four tradeoffs is more art than science and will likely always be so. But having a strategy for each at least helps in ensuring that model maintenance imposes the right level of overhead.