A modeling repository is a vital resource in getting value from your models. A repository provides a number of benefits – access control and audit trails, having a single source of truth, the ability to search and report across models, and so on.
Generally a repository will let you view your collection of models as one or more trees of folders, adopting the familiar folder-based paradigm that has become so familiar from the WIMP (Windows, Icon, Mouse, Pointer) GUIs that we encounter every day while working with our PCs. Usually, the repository will allow a great deal of flexibility in structuring these hierarchies of folders. Which does beg the question - how do you organize the models? It’s a topic that I’ve not seen a lot of literature about, so in this post I’m going to outline the factors that affect decisions on how to structure a modeling repository.
The first factor that we are going to need to consider is going to be partitioning of your models. I feel that I’m on safe ground when I say that most organizations will be maintaining a current state model – but what about planned models? What about models that have been superseded? It can be useful to look back in time (and forward in time), so it’s often useful to separate a current state model from planned or historical models.
At the same time, depending on the level of co-ordination between groups using the repository, you may or may not want to keep process maps separate from architectural models – in other words, while it’s desirable that they both work from the same identified set of processes, this may only be practicable as a medium-term goal.
The second factor to bear in mind when designing the structure of the repository is the question of access rights. There are likely to be a number of different groups who will want access to the repository – the owners are going to want to restrict this. Even with a high level of trust between different groups (and that’s far from a certainty), the owners of specific models are going to prefer that other groups don’t have full, unrestricted access to their work. There may even be specific legal requirements to hide certain information completely from all but the people working with it– for example, if the company engages in work that requires confidentiality (e.g. for certain parts of the government).
These are the two primary factors that will determine the high level structure of the repository. But operating within the constraints that they place, there is a third factor to consider – making it easy to browse the models themselves. Most repositories will have support for search functions, but some groups (e.g. temporary outside consultants) can find value in simply browsing modeling repositories. So it’s worth investing considering how to facilitate this process, and the best approach that I’ve seen is to base it on organizational structure – this being a classification that staff will be familiar with.
So in summary, there are three factors that should drive how you structure your repository tree - partitioning, access control and browsing. It’s not realistic to propose a structure that will work for every organization, but applying these three factors should give enough guidance to tailor the structure appropriately for the organization’s needs.
Many organizations choose to design their repository on a standard, such as TOGAF, to give them a best practice baseline to work with. Others choose implement a repository solution that can be tailored completely to their needs. This ensures they have a structure that will suit them long term.
If you want to learn more about how to implement the perfect repository structure for you, we’re offering a free consultation call with one of our expert consultants to our readers, so why not get in touch today!