A process for creating an architecture repository

This page is published under the terms of the licence summarized in the footnote.


How to manage the structure and behaviour of business systems if you donít know that structure or behaviour?

How to plan changes that are optimal for the enterprise (rather than suboptimal and localized) if you have no enterprise-wide repository of the system estate?

On the other hand, why is building and maintaining an enterprise-wide architecture repository more challenging than CASE tool vendors tell you?

(CASE = Computer-Aided System Engineering).


This paper outlines a step-by-step process you may find helpful when starting up an architecture repository.



Step 1: Define users and uses. 1

Step 2: Define scope. 1

Step 3: Define meta model 2

Step 4: Select technology. 2

Step 5: Define data sources and targets. 2

Step 6: Define update and integration processes. 3


Step 1: Define users and uses

You donít want to end up with enterprise architecture descriptions that meet the abstract goal of fully populating the Zachman Framework, but have more authors than readers.

Be clear who will use your repository and for what.


A common purpose is to support impact analysis in change management.

But different people look after different kinds of asset and manage different kinds of change.

Are you building an

If your goal is the first, then how does this relate to the other two? Weíll return to this later.


Bear in mind that elements of architecture description that are not used, do not have consumers, will decay - as any unused data does.

So donít set out to store what you cannot use.

Be realistic about how much detail can be maintained.

Step 2: Define scope

You have to choose the scope and level of detail that you are able to maintain.

Consider the four dimensions on which the scope of architecture work may be measured.


Nobody has yet built one architecture repository that defines a complete enterprise from top to bottom on every scale of abstraction.

It is wise to start with the simplest repository structure you can maintain and gain value from.

Step 3: Define meta model

You can meet some narrow short term purposes without thinking hard about the meta model of your architecture description, but eventually you need to design this meta model with care to ensure it contains the entities, attributes relationships you need to answer questions and do change impact analysis.


Your entities may include any or all of the deliverable artifacts mentioned in our other guides.

The attributes and relationships of these entities may include any or all of the fields listed in our deliverable templates.

Our templates probably include more attributes than you can maintain in a general enterprise architecture repository, but perhaps less than you need to fully define a specific solution.

Step 4: Select technology

You might start with spreadsheets.

It wonít be long before you need something better.

If you are more concerned to have a repository than a drawing tool, then you might build an MS Access database.

You might build your architecture repository on top of an existing configuration management database.

For a large or long-term effort, youíll need to purchase a CASE tool.

Related papers contains notes on what a CASE tool should do for you.

Step 5: Define data sources and targets

It is to be expected that your enterprise already records architecture artifacts in many place.

E.g. you may find various partial repositories:


It is not to be expected that your repository will replace all these, so you have to regard some or all of them as data sources or targets, to be integrated with your repository.

Step 6: Define update and integration processes

Identify what data from the various repositories can and should be aligned.

Put mutual update processes into place.

If your architecture repository supports a one-time solution architecture, then the data may be migrated from your repository into these other maintained repositories.

If your architecture repository supports a long-term enterprise architecture, then the data may be migrated to your repository from these other maintained repositories.


For long-term maintenance you need governance processes that ensure a solution architect



Copyright conditions

Creative Commons Attribution-No Derivative Works Licence 2.0†††††††††††† 10/06/2015 19:25

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit ďAvancier Limited: http://avancier.websiteĒ before the start and include this footnote at the end.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this page, not derivative works based upon it.

For more information about the licence, see http://creativecommons.org