Implementing and managing an enterprise model – whether of processes or of architecture, can offer significant benefits in keeping a firm understanding of a highly complex environment. However, there are a number of issues with maintaining enterprise models that can reduce their value and impose unnecessary overhead. There’s value in considering what these issues are, and what steps we can take to mitigate them.
One such issue, that is unfortunately often overlooked, is that of model fragmentation. The problem of model fragmentation occurs when different views in the overall model contradict one another. It comes about because edits made in one view are not reflected in another view – to a large extent, it’s an unavoidable consequence of the way that models are decomposed into views. Usually, it is because lower level changes are not being propagated up into the higher level model.
This in turn is often because the day-to-day changes are made by staff or teams that are not all that concerned with the top-level, strategic view. It’s often hard for them to know that their changes might affect a top-level view… and even if they have awareness, time pressure may mean that manually keeping the models in sync is seen as a lower priority.
So, model fragmentation can become a problem. But, if model fragmentation is proving to be a problem, then what options exist for an organization to address it? In practice there are two possible approaches to address it and mitigate its effects – accepting fragmentation or mitigating it.
In the first approach, the solution is simply to allow different teams to keep different models. Depending on the modeling technology being used, this might depend on tool capabilities. If models are simply being kept in a file share (which raises all kinds of governance issue of its own, but not ones that are relevant here) then that’s simple enough. In practice, most organizations where the modeling capability is mature enough for fragmentation to become a problem will be using some form of model repository, in which case the tool will need to support partitioning into different models – such as the library functionality in iServer.
This might seem a silly approach – how can the top-level model be useful if it doesn’t reflect reality? The answer lies in the fact that the different levels of model have different cadences in their usage. In other words, the lower-level models will be used on a regular, perhaps even day to day basis. In contrast, top-level models tend to be used at a more strategic level that we would hope does not involve day-to-day decision making.
So partitioning is one possible approach. But perhaps the tool doesn’t support partitioning in this way, or perhaps there are external reasons why the models have to be kept in sync continuously. In this case, the second option becomes necessary, which is to implement updates to the model as part of the governance process. Here, the organization will have to mandate that the model is reviewed for what parts need to be updated as part of implementation.