February 1999        Issue: 7

Journal of Conceptual Modeling
www.inconcept.com/jcm

Zachman Framework
By Dr. John K. Sharp

As a company tries to become better in the creation of information systems a regular discussion occurs about the need or value of an information architecture. The success of an individual application is not dependent on having an information architecture, but the corporate goal of a seamless, integrated corporate information system requires corporate planning. A major part of this planning may involve architecture. This article reflects some of my initial thoughts on a long-term project that I have just started that deals with the Zachman Framework. For information on the general issue of information architectures refer to references at the end of this article.

The Zachman Framework basically deals with the common sense rules that we were given in middle school for writing a story. We were told to provide information about Who, What, When, Where, Why, and How in every story. This same common sense partitioning of knowledge occurs in the columns of the Zachman Framework. I will not try to defend the Zachman Framework over other frameworks, but any framework that is adopted or developed should be easy to explain to management and the involved professionals.

A standard presentation for the Zachman Framework is given in Figure 1. The knowledge that defines an application can be partitioned within the Zachman Framework. Each column has a need for a precise model that defines the knowledge associated with that aspect of the application. A current effort exists to provide the meta-model for each column. This effort would benefit from using the NLM/ORM/NIAM approach of examples and sentences to define these requirements. The type of knowledge captured in individual cells will not be discussed in this article, but an overview of the columns and a discussion of the rows will be presented.

Figure 1: Zachman Framework

The columns of the Zachman Framework originally included only DATA, FUNCTION, and MOTIVATION. Information that could be partitioned into these areas regularly occurs in information system designs. The NETWORK, PEOPLE, and TIME columns were added later. This information is required before an application can be successfully implemented, but it may not be a standard part of an information system design. Each column can be associated with one of the standard questions for story writing.

The first column, DATA, is the "What" things that are involved in the subject area. The data consists of a list of things that are important to the business. The Entity is a major data item that stands for a class of a business thing. Entities are connected via relationships. In NLM these relationships are expressed as sentence patterns and include some constraints.

The second column, FUNCTION, is the "How" things are done in the subject area. This consists of a list of processes that are performed. In the NLM procedure, processes are triggered by an event that requires action be taken. Processes can also generate derived knowledge that may be stored or used to trigger other processes.

The third column, NETWORK, is the "Where" things are done in the subject area. This could be a list of locations or network nodes that need to be supported to allow the knowledge capture and use within the subject area. This availability of access is required for a successful implementation of an application although there is no procedure step to capture this knowledge in NLM. One interpretation of this column could be the physical location for the capture or use of local sentence patterns that participate in the global definition of knowledge. The design should understand if the available network supports that current application. The additional knowledge that is captured to support this conclusion should be documented. The design of this network is outside of the knowledge definition specified using the NLM procedures unless the network is "subject area" of the analysis.

The fourth column, WHO, is the "Who" that are allowed to interact with knowledge. It contains knowledge about the people and organizations within the business. Some of these rules deal with who is allowed to participate in the events that are triggered by an event rule. Other rules deal with who is responsible for a piece of knowledge that is created. This could deal with either a process in a work-breakdown structure or a sentence pattern within a conceptual schema. Again, the successful implementation of an application requires this information. The inclusion of this knowledge creates a better design. This knowledge certainly can be placed in an NLM diagram, but it may not be done without standard design practices established within an architecture.

The fifth column, TIME, is the "When" something is done. This could be a fixed time that triggers a process, the time of an event that triggers another process, or a time sequencing that says this process must be performed before a follow-on process. Again, the successful implementation of an application requires this information. The formal requirement that this be addressed within a design will improve the resulting quality of the design.

The sixth column, MOTIVATION, is the "Why" things are done. Business goals and strategies are listed here. These goals and strategies can be expressed as natural language sentences. In many cases, the sentences that measure these goals and strategies will have derivation rules for determining the performance of the company or organization. The derived fact instances are compared with stated goals that are called out in a business objective.

My attempt at adding value to the successful adoption of this framework was to propose standard deliverables for each of the rows. These deliverables should have the same type of common sense approach that appears in the columns. Each deliverable will have a standard form for its content, a person responsible for placing the knowledge in the standard form, a person that is accountable for the knowledge content, and a person who can validate the knowledge content. The following discussion may more directly apply to the original Zachman Framework columns, but it also applies to the other columns. The standard Zachman Framework row definitions suggest that precision will improve as a project moves down through the rows. My approach here is that each row must have sufficient precision for validation. The validation of the output from a row must be done before the work is initiated in the subsequent row.

The first row, SCOPE, presents high level guidance for the project. The contents of this document, which may be referred to as a Statement of Work, are usually guided by non-technical management and written by subject matter experts who do not have information modeling skills. The document will have wonderful ideas as well as incomplete, inconsistent, irrelevant, and redundant information. Random examples may also be presented. The person performing the technical work is most likely the subject matter expert. The person who is accountable for this work is the manager who has procured funding to support the project. The person who validates that this project is required will also be from the management ranks.

The second row, ENTERPRISE MODEL, presents the subject matter experts understanding of the subject area. This row involves the first formal modeling effort. The person creating the model is a skilled information analyst. The Statement of Work and the initial examples provide the starting point for model creation. The analyst must ensure that the subject matter expert provides the needed input to the modeling process. The person with the most subject area knowledge is the subject matter expert. This expert must be able to fully understand and thus become accountable for contents of the model. For this reason the requirements should be developed using the NLM procedure so that the subject matter expert only has to answer "Yes" or "No" to straight froward questions about the subject area. I have, also, seen a Use Case Model developed at this time that can serve the dual purpose of providing consistent and relevant examples and then be used for training future users of the processes. I will be investigating this in future articles. The person performing the analysis is the information analyst. The person accountable for the model content is the subject matter expert. The person who can validate the model is another subject matter expert. The integrity of the rules developed by the subject matter expert must be maintained throughout the remaining rows.

The third row, SYSTEM MODEL, presents the required or approved graphical model that is targeted at implementation, the corporate repository, or both. Standard models may be required for implementation or to support the corporate data administration function. The analyst can perform the conversion of the NLM sentence based model into alternate graphical forms and be held accountable for maintaining the validated knowledge. Another information analyst can validate that the knowledge was properly converted. The presentation of this knowledge can be in either a relational based or object oriented graphical model.

The fourth row, TECHNOLOGY MODEL, presents an extended model that accounts for a specific targeted platform and deals with performance issues. This row prepares the model for implementation. The person performing this activity is a database administrator. The model presented to the row directly supports the future implementation. Additions to the model can include indexes and meaningless keys to support performance. These additions do not change any of the fact types validated by the subject matter expert. The person who is accountable for this model is also the database administrator. The person validating the resulting model is another database administrator.

The fifth row, COMPONENTS, presents the code that implements the application. The person performing this function is the implementer. The implementer is also accountable for implementing the provided design. The implemented system should be validated by a tester based on the sentence based NLM model and supported by the use case descriptions. This final validation ensures that the desires of the subject matter expert were implemented. The subject matter expert thus becomes accountable for the implemented system in the same manner that the senior engineer is accountable for a production component.

There should be no creative input to the design after validation by the subject matter expert. Any suggested changes or additions to the subject matter expert's model must be properly modeled so that the subject matter expert can validate the changes. This must be done whenever issues come up in rows 3 to 5.

The contents of the row 1 documents can be precisely rewritten from the knowledge stated in row 2. I consider this an academic effort (Although, this is exactly what I do for developing my modeling course examples.) for corporate applications. The knowledge content created for the subject area should be available for the benefit of future projects. This knowledge is first stated in row 2 and then graphically presented in row 3. A corporate repository would at least hold the row 3 and hopefully hold row 2 knowledge. The row 1 documentation is not usually part of the corporate record, so the effort to redo it better has little long-term value. In the implementation of a framework, I do not want to suggest effort be put into what analysts may consider busy work in the name of architecture compliance. I have enough trouble trying to convince analysts and management that the necessary modeling should be precisely done before coding starts.

An information architecture will force a more formal information system process to exist. The effective reuse of the defined knowledge and the future integration of applications should be sufficient justification for establishing an architecture.

Happy Modeling!

References:

1. Spewak, S. H., Enterprise Architecture Planning: Developing a Blueprint for Data, Applications and Technology, John Wiley & Sons, 1992

2. Zachman, J.A., A Framework for Information Systems Architecture, IBM Systems Journal, vol. 26, no. 3, pp. 276-292, 1987

3. Sowa, J.F. & J.A. Zachman, Extending and Formalizing the Framework for Information Systems Architecture, IBM Systems Journal, vol. 31, no. 3, pp. 590-616, 1992

4. Burgess, B.H. & T.A. Hokel, A Brief Introduction to the Zachman Framework, Framework Software Inc., 1994

5. Cook, M.A. Building Enterprise Information Architectures: Reengineering Information Systems. Prentice Hall, 1996

6. Inmon, W.H, J.A. Zachman, & J.G. Geiger, Data Stores, Data Warehousing, and the Zachman Framework: Managing Enterprise Knowledge, McGraw-Hill, 1997

7. Internet Reference: http://www.istis.unomaha.edu/isqa/vanvliet/arch/isa

Dr. John Sharp is the founder and principal consultant for Sharp Informatics.Before starting Sharp Informatics in 1997 he was employed by Sandia National Laboratories in Albuquerque, NM for 18 years. While at Sandia he held staff and management positions in all areas of information technology, including analysis, design, implementation, maintenance, information architecture, data administration, and information technology research. He has worked closely with Prof. Shir Nijssen of The Netherlands to improve the NIAM analysis methodology. Dr. Sharp is the creator of the first information analysis procedure known to be mathematically precise.This procedure reformulates the usual (imprecise and inaccurate) statements and examples from a subject area into verified fact types. The output of this productivity enhancing process (a set of information requirements) is compatible with all the latest and most productive database application creation tools. John is the editor of the international standard for conceptual schemas. He has co-chaired two international conferences on natural language modeling and he has presented numerous papers and seminars at professional conferences.

Contact information:

Dr. John Sharp
Sharp Informatics
1604 Vassar SE
Albuquerque, NM 87106
sharp@sharp-informatics.com
505-243-1498
fax 505-248-0345
http://www.sharp-informatics.com

© Copyright, 1998-2004 InConcept (Information Conceptual Modeling, Inc.) All Rights Reserved. Privacy Statement.
ISSN: 1533-3825