Defining a Framework for Strategic Planning and Architecture in a Federal Office
Paul Arveson
Oct. 13, 2000
Everyone recognizes the need for an easier, faster way to find documents and data, especially in the context of the Office Information Management (IM) Team, where there are numerous plans, projects, and product versions in development at any given time.
The Office Intranet Portal project is intended to provide a single entry point for users. This will help greatly in supporting users at the presentation level. However, in order to provide ease of access, information within the portal should be structured in a way that is visually clear and intuitive. Then users (internal developers and managers) will be able to rapidly find any current or past information on any topic of relevance in our domain, and produce reports on the status of work at any point in time. Also, new employees will be able to come up to productive speed more quickly by being able to query a database and find information on any topic. Such a system can raise the visibility of all the knowledge that is required to support the missions of the Office.
As with any project, it should begin by considering the data architecture. This means defining the data model or structure for the information. One of the best practices in managing project development data is the use of frameworks. Our planning methodology is based on Spewak, which in turn is based on the Zachman framework. This framework is also widely used by other government agencies such as the Dept. of Treasury and the CIO Council. Therefore, we should examine how the Zachman Framework might apply to internal information management for Office IM Team planners. The following notes report my preliminary findings.
The Zachman Framework is described in the book Data Stores, Data Warehousing and the Zachman Framework: Managing Enterprise Knowledge, by W. H. Inmon, John A. Zachman and Jon G. Geiger (McGraw Hill, 1997).
Note that this book is newer than the Spewak book that refers to an earlier version of the Zachman framework. Spewak was published in 1992, prior to the web, data warehousing, TQM, and BPR: major management and technology innovations that changed the landscape of IM in the 1990's. The Zachman framework is also more completely described in his own book than in Spewak.
The Zachman framework is based on robust and insightful principles of data modeling and information architectures. These principles are consistent with the basic principles of the relational data model. The framework claims to provide "an architectural context for building any product or process. It accomplishes this through a classification scheme which ensures that all 30 aspects of the product's life cycle receive the appropriate attention. The 30 aspects occupy cells within a matrix pictorial of the Framework. In this matrix, the rows represent different perspectives of the product and the columns represent its dimensions." (Note: in later versions, another layer was added representing the 'functioning systems', so there are now 36 cells.) A figure showing the basic Zachman framework is shown below.
Frameworks are composed of dimensions. Zachman's Enterprise
Architecture Framework has 6 columns representing different dimensions of the
architecture, and 6 rows (or layers) representing the ways these dimensions are
viewed by different people, depending on their relationship to the architecture.
Zachman has a detailed definition of what constitutes a dimension, which derives from
the theory of relational databases.
They have seven key attributes:
1. Each dimension is equally important.
2. Each dimension has a simple basic model.
3. Each dimension has a unique basic model; there is no ambiguity.
4. Each dimension represents a distinct, unique view (they are mutually orthogonal).
5. Each meta entity appears in only one cell of a framework.
6. All six dimensions are needed to fully represent each perspective.
7. The framework, and each cell in the framework is recursive with respect to versions and decomposition.
Dimensions are a vital way of organizing complex data. If the number of attributes along a dimension (the degree) is small, then the attributes can be represented in a database table or visual list. Two such dimensions can be represented as linked tables or a visual grid. These representations allow full linkage between the objects on each dimension.
There are actually four Zachman frameworks, which are interrelated in a recursive hierarchy. At the top is the Enterprise Repository Framework, which embraces all the knowledge and work processes of the organization. The next level is the Enterprise Engineering Framework, which describes the mission of the business unit that develops business systems for the entire organization. The next level is the Enterprise Framework, in which all the business processes are described. The lowest level is the Product Framework, which describes mission outputs from the work of the enterprise.
The IM Team is only concerned with the three lower frameworks. I have modified the names of these frameworks to fit our organizational terminology: the Enterprise Engineering Framework becomes the Office IM Team Framework, the Enterprise Framework becomes the Office Business Processes Framework, and the Product Framework becomes the Project /System Framework.
The goal of any framework is to represent an entire knowledge base in a set of orthogonal dimensions, and to display the information in a clear, consistent and robust way.
Since the framework claims to be complete, there will be no need to revise it later by adding additional dimensions. It is intended to be a stable structure with changing content.
Even if it is complete in its content, there are two general kinds of pitfalls that can cause a proposed
framework to fail in its goals:
a) fragmentation: disconnected lists or tables, in which linkage is
inadequate. This results in a loss of context and difficulty in locating needed information and relating it logically. Paper
documents have this problem.
b) fractalization: excessive linkage that breaks the rules for
dimensional attributes such as the requirement for orthogonality. This
results in 'information overload' and confusion. (The World Wide Web has such a
data structure).
A consequence of either of the pitfalls is instability, i.e. its users will attempt to patch it up, i.e. to change its structure. This will lead to additional confusion. Hence, at the outset, users must be convinced that the framework is complete, and doesn't need anything added to it. This means that a lot of thought must go into the initial design, to ensure that nothing significant is left out and that the structure is as simple as possible.
Adapting the Framework
The Zachman Framework is a model. Like other models, it is a human
invention based to some extent on the assumptions of its creator. If those
assumptions do not apply in our context, it is reasonable to consider adapting
the Framework to make a more appropriate model. But this adaptation should
not be done hastily. The Zachman Framework has been with us since at least 1987,
and Zachman is widely known as a leader in developing the ideas of information
architecture. That being said, it may still be necessary to adapt the
structure of the Framework, while keeping Zachman's basic principles.
Any adaptation of the Frameworks should retain these principles, which are the core concepts that make the Zachman framework valid and coherent in terms of data modeling. However, that leaves several possible ways to adapt the generic framework: we could add or subtract rows and/or columns; we could change the names of the rows/columns to fit an enterprise better; we could narrow the scope of the enterprise knowledge being modeled. Sometimes, as in Spewak, we see the whole Framework truncated to only the first three columns. Whitten and Bentley added a new column, called "system interfaces".
The generic Zachman framework is abstract and difficult to relate to the specific environment and data requirements of the Office. The Zachman framework, or any framework, should not be adopted wholesale without consideration of its fit into our environment.
Proposed Adaptations
The original Zachman Framework columns, which show different aspects of the enterprise from a particular viewpoint, were based on the six "serving men": What, How, Where, Who, When, and Why. However, this generic pattern was then interpreted as Data, Function, Network, People, Time and Motivation. This interpretation is adaptable.
Specifically, the key adaptation is to interpret Where as infrastructures. This includes all subjects related to technology standards, technical architectures, hardware and software and their interconnections and interfaces, networks, nodes and their locations.
Changes made in the names of the frameworks to fit our environment were previously mentioned. The additional changes are mainly these:
The main purpose for making these adaptations is ease of use: to make it more intuitively obvious where a particular document is, or should be located within the Framework.
In the web pages here, we have designed frameworks for the Office that are adaptations of the generic Zachman frameworks. These pages are in the form of HTML tables, but they could be presented in other ways. What matters is that they should offer guidance in defining a data model that is based on a widely-recognized framework and is appropriate for our work processes.
The proposed frameworks are illustrated in the following links:
Image Map Links to all Frameworks
1. Top-level Repository Framework for the Office
2. Framework for SC-65, the Information Management Team of the Office
3. Index of Frameworks for Ongoing Projects in the Office
4. Generic System and Project Framework in the Office
Book References
Data Stores, Data Warehousing and the Zachman Framework: Managing Enterprise Knowledge, by W. H. Inmon, John A. Zachman and Jon G. Geiger (McGraw Hill, 1997).
Enterprise Architecture Planning, by Steven H. Spewak (Wiley & Sons, 1992).
Systems Analysis and Design Methods, by Jeffrey L. Whitten and Lonnie D. Bentley, Irwin McGraw-Hill (1998).
Web References
Government Sites:
US Dept. of Energy CIO Information Architecture
DOE Architectural Principles Explained
Defense Information Infrastructure - Common Operating Environment
Mapping the Zachman Framework to the C4ISR Architecture Framework
Treasury Enterprise Architecture Framework
North Carolina Technical Architecture Documentation
Private Sector Sites:
The Zachman Institute for Framework Advancement
The Enterprise Framework Group
Enterprise-Wide IT Architecture
Microsoft: Architecture-Driven Modeling
Microsoft TechNet: Why is Interoperability Important?