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.

Contents

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

• an architecture repository for enterprise architects?
• an asset register for IT portfolio managers?
• a CMDB (as in ITIL) for IT service managers?

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.

• Life cycle: Is the repository to be used for a short term project or maintained over the long term?
• Architecture domains to be covered: Will it cover all or some of Business architecture? Data architecture? Applications architecture? Technical infrastructure architecture?
• Breath: Will it be used only within a project? The time and resources for that effort naturally constrain the life cycle and level of detail.
• Will it be used enterprise-wide? If so, who pays for it?
• Level of abstraction: You have to consider where your repository stands on the scales of abstraction defined in the paper at ref 1.

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:

• Balanced score cards containing objectives and performance targets

• CASE tools containing business process models and data models

• Requirements catalogues that contain statements, features etc.
• Configuration management tools containing source code and tests
• System management tools have records of (or access to) servers and the technologies/software deployed on them.

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

• makes proper use of the architecture repository in developing solution architectures
• specifies a new artifact before creating it
• looks in the architecture repository to see if a similar artifact exists already
• asks for permission before creating a new artifact similar to an existing one
• updates the architecture repository with any new or changed artifact.

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