In a lot of ways, architecture is about balancing competing demands, and trying to find the right tradeoff between them to try to get to the best solution for the problem in hand. The old phrase says “you can have it done at a low cost, you can have it done to a high quality, you can have it done in a short time – but you can only pick two.” It's a blunt statement that manages to capture the essence of the problem – tradeoffs – but when it comes to architecture it doesn't really call out the number of factors that you have to balance.
This is also true when configuring your architecture repository. The nature of architecture repositories means that there are a number of factors to balance in how you set up whichever tool or repository you have chosen. In this post I'm going to examine the three most common considerations that are encountered when configuring a repository.
1. Permissions and Access
The first tradeoff to make is one of access, which is to say - who can make changes to the models that the architecture repository contains? At one end of the spectrum, the model could be wide open, with anyone able to make changes as required. The obvious problem with this is that it risks incorrect changes being made – for example, staff who are unfamiliar with the repository might accidentally edit the current state model when they meant to edit a draft model. At the other end of the spectrum, access might be restricted to one person who is the identified custodian of the model. However, this risks making this person a bottleneck. In general, I recommend that editor access to the current state be restricted to a small core team of around 5, even if one of that team is the usual identified model maintainer.
2. Number of Models
The second, and related area, is how many different models to maintain. Many organizations maintain a current state – but what about proposed architectures? You could manage a draft model and a current model… but what if there are longer term changes planned as part of an organizational transformation? Should an organization maintain separate models for each phase of such a program? This seems attractive, except that models require maintenance – so each extra model adds to the workload of the modeling team. It can also make it confusing to stakeholders who might be unsure of which model is relevant. The rule of thumb I use is that ideally there should only be a draft and current state area, and in the case of business transformation that requires extra models for the different phases of the program, then an absolute maximum of one model per year should be used.
3. Volume of Metadata
The third tradeoff to make is what metadata to record for the various modeling entities that are in the repository. For example, an organization might want to record the owner and criticality of a business service, or the business fit and technical fit scores for an application. It can be tempting to add a large number of fields for each type of entity – but in practice this is a bad idea. The larger the number of fields for an entity in the model, the harder it becomes to find a specific field. At the same time, information in the model is usually coming from subject matter experts who have other demands on their time, so requiring them to fill out a large number of fields for each entity that they know about is a good recipe for them to not do it carefully – or even to leave fields blank. The rule of thumb I use is that if an attribute is not going to be used to search or in a report, then leave it out of the model.
As with most things in architecture, the right answer for each of these three cases will depend on the circumstances. In this post I’ve attempted to provide some useful guidance on how to decide for each three.
Attributes – how many and what; rule of thumb = would this affect an architectural decision?