The Zachman Framework to Select Products Mapping

This presentation is best viewed at a screen resolution of 1024 x 768 pixels

The diagram below shows the Zachman Framework for Enterprise Architecture.

To see how the Select Products may be used to implement the artefacts suggested by Zachman for each cell, click on the cell; the details of the mapping will be displayed in a seperate browser page.  Alternatively, use the menu on the left hand side of the pages to navigate the mappings.

Approach to Creating an Enterprise Architecture

There are two extreme approaches to creating an Enterprise Architecture using the Zachman Framework; Top Down and Bottom Up.

In the Top Down approach you would start at the top right cell of the above grid (Scope-Motivation) and decide the information across that row which is aligned with the strtategy.  You would then work down each row in a similar fashion; if outsourcing was not an issue for you, you would not bother with the Detailed Representation row but you would have gathered all the necessary information by that stage anyway. Once you have the Architecture you can commission project developments that are aligned with it.

The Bottom Up approach relies totally on what you have already. You start by looking at each system/application in turn and feed the relevant information into whichever cell in the Framework is appropriate. This will populate the lower cells of the Framework first and you must factor out common information and aggregate it to a coarser level of detail to populate the higher cells.

In a mature, medium-to-large organization, both these approaches could take some considerable time with little return on investment.

Select Business Solutions recommends any hybrid of the two approaches that conforms to the following pinciples:

1.  All Enterprise Architecture decisions are driven ultimately by business needs

2.  An iterative and incremental approach is required to converge on the appropriate Enterprise Architecture

3.  Delivery of partial Enterprise Architecture artefacts must be timely so as not to hinder system/application development/maintenance

4.  Two-way communication between Enterprise Architecture and project teams is paramount

5.  Testing of Enterprise Architecture artefacts should be done throughout the building of the Architecture

6.  The Enterprise Architecture will never be finished

Given these principles, you can see that the cells in the top 2 rows are the most important starting place but the information for most of them will be already contained in artefacts from existing projects.  We advocate building, as quickly as possible, 'As Is'  models to fill these cells which should be published for early feedback.

The results of the feedback from this first publication and subsequent ones will indicate the priorities for the future development of the Framework.

Back to Top