Introduction to the Zachman Framework

[tweetmeme source=”gosub3000”]

Traditional Architectural Approaches.

The traditional view of system implementation is seen as a series of steps toward implementation, covering areas such as analysis, design, construction, documentation, handover, etc. Hay (1997) gives a good undertaking of the traditional approach stating:

Many methodologies are organized around the “system development life cycle”, an organization of the steps required to develop systems. This is expressed as consisting of:

• Strategy – The planning of an organization’s overall systems development effort.
• Analysis – The detailed definition of requirements for a particular area of the business.
• Design – The specific application of technology to the requirements defined during analysis.
• Construction – The actual construction of the system.
• Documentation – Preparation of the user manuals, reference manuals, etc. to describe the system.
• Transition – The implementation of the system, so as to make it part of the infrastructure of the organization.
• Production – The ongoing monitoring of the system to ensure that it continues to meet the needs of the organization.

Notice that each of these steps addresses issues of data and function. Data and functions are typically addressed as separate topics, although ideally, they are addressed cooperatively.

Most methodologies portray the system development life cycle in terms approximating these. Some go so far as to give it the acronym “SDLC.”

Introducing the Zachman Framework

The Zachman Framework is given in Figure 1.

Figure 1 Zachman Framework (Zachman, 2008)
It is clear from the description of the traditional methodology, that as each stage nears completion, a certain amount of handover is needed to pass the project from one stage to another.

What Zachman realised, is that each stage accommodates different players within the system development effort, and each player views the system in their own particular way. As such, it does not make sense to speak of a single system architecture, but more sense to speak of a set of architectures, as each player defines the system from their particular viewpoint, as Hay (1997) notes:

In 1987, John Zachman published a different approach to the elements of system development. Instead of representing the process as a series of steps, he organized it around the points of view taken by the various players. These players included

1. someone who has undertaken to do business in a particular industry,
2. the business people who run the organization,
3. the systems analyst who wants to represent the business in a disciplined form
4. the designer, who applies specific technologies to solve the problems of the business,
5. the builder of the system, and finally
6. the system itself.

Mr. Zachman represents each of these perspectives as a row in his matrix.

The columns of the matrix, address the what, how, where, who, when and why questions, more typical of a journalist than an engineer. In engineering terms these are data, function, network, people, time and motivation respectively. These represent different areas of interest for each perspective.

Each row in the data column addresses understanding of, and dealing with the enterprise’s data. Row one shows a list of items that concern the company. As you move down the matrix, you move to progressively more rigorous descriptions of the data. Not only are the descriptions more detailed, they are from the differing perspectives of the owner, designer, builder, operator, etc.
The rows of the function column describe the process of translating the mission of the enterprise into successively more detailed definitions of it’s operations. As you move down the rows, the business processes become more defined, until eventually executable code for the system can be produced.
The Network column is concerned with the geographic distribution of the enterprise’s activities. Any enterprise which operates from two or more physical locations, will eventually need to deal with intra-office communication, networking, networking protocols, etc. Similar to other columns, moving down through the rows, shows the various perspectives and detailed definitions of communications plans, and networking infrastructure needed to accomplish the communications facilities a business would need to effectively operate their information systems in a geographically distributed way.
Column four, represents the ‘who’ or the people affected by any information system. At a high level, this is the various departments which will interface with an information system, but as you descend through the rows, a more detailed description of who needs what for their particular job become apparent. The final goal of this work, is a system developed with the specific needs of the users in mind, and a set of users trained in the operation of the system.
The Time column, details the ‘when’ of the system. A high level view of this column describes the business events, but as the definitions become more detailed, definitions of particular functions and the circumstances under which they should or should not be invoked become available. It is difficult to describe this column in isolation, as it defines constraints on the various functions and processes defined on other columns.
Finally the Motivation column addresses the ‘why’ of the system. Zachman (1987) describes this column as “concerning the translation of business goals and strategies into specific ends and means”. At a high level, strategic business goals are defined, and as more detail is added to the lower rows, specific business rules emerge, which can be enforced through system business logic.

Advantages of the Zachman Framework

Zachman (1987) notes several advantages of his framework:

• Improving professional communications within the information systems community.
• Understanding the reasons for and risks of not developing any one architectural representation.
• Placing a wide variety of tools and/or methodologies in relation to one another.
• Developing improved approaches (including methodologies and tools) to produce each of the architectural representations, as well as possibly rethinking the nature of the classic “application development process” as we know it today.

Possibly the single reason which has made the Zachman Framework so successful, is the realisation that there is no single unified architecture which meets everybody’s needs. By realising that different people have different, yet complimentary perspectives, a richer set of architectures can be generated which in total, define the architecture of the information system.

Addressing this Hay (1997) notes:

Each row in his matrix represents the perspectives of one of the set of players in the development process. It is more important, he [Zachman] asserts, to recognize that systems are developed by distinct groups with different points of view, than it is to see the movement of systems from one step to another.

Nikolaidou & Alexopoulou (2008) give a case study of the Zachman Framework in use, and show that it provides an effective meta-model when creating the architecture of large scale information system development.

Rafidah, Zulkhairi, Rohaya, Siti & Sahadah (2007) discuss the use of the Zachman Framework by both Governmental and private industry in Malaysia. Their findings suggest that while the Zachman Framework is the de-facto enterprise information architecture approach for most western businesses, it is less well known in Malaysia, though many of the practices prescribed by the Zachman Framework are already in use to varying degrees.

Disadvantages of the Zachman Framework

Ambler (2007), states the following weaknesses of the Zachman Framework:

1. It can lead to a documentation-heavy approach (although this does not have to be the case). There are 36 cells in Figure 1, each of which could be supported by one or more models.
2. It can lead to a process-heavy approach to development – you can instantly see the opportunity to define a collection of rigorous processes to support the Zachman Framework.
3. The Zachman Framework isn’t well accepted within the development community and few developers even seem to have even heard about it.
4. The Zachman Framework seems to promote a top-down approach to development. When people first read about the Zachman Framework, they tend to think that it implies a top-down approach where you start with the models in row 1, then work on row 2 models, and so on. This doesn’t have to be the case, you can in fact start in any cell and then iterate from there.
5. The Zachman Framework appears to be biased towards traditional, data-centric techniques (thus explaining its popularity within the data community).

Simsion (2005) also suggests that the metaphor used throughout the Zachman Framework, that of the architectural development of a building, or manufactured product, does not adequately suit the reality of information system development. Information system development is rarely green field, as the building of a new house would be. It is often more likely to be brown field, with newer systems being developed to replace older ones, while interacting with the same peripheral systems.
Simsion (2005) suggests that a metaphor of Urban Planner is more suitable, stating:

If we want a metaphor for the task of coordinating an enterprise’s systems, urban planning would seem much more appropriate. The urban planner is usually heavily constrained by what is already in place, relies largely on coordinating initiatives funded by others, and will frequently need to compromise with developers. This is not an original analogy: on the contrary it is widely used by information systems “architects” to describe their work. Unfortunately, the argument for urban planning is not as fundamental and compelling as the argument for design in manufacturing. The design is essential to the manufactured product. But towns have grown without urban planners.

Varga (2003) also points out the lack of tools and process support for some of the Zachman meta models, stating:

Everyone (i.e. every organization) has to define exactly how each artefact or model should be structured and what information it should contain. Everyone has to define the meta model for each cell, or at least the cells deemed worthy of defining. Therefore, the Framework is not a definite solution. Later, IS development can begin after meta models have been defined to the appropriate degree of detail.
The problem is the lack of standard artefact description for some Framework’s cells. However, this is the evidence of inadequate methodological foundations of parts of the Framework and constant need for their improvement.

Pareira & Sousa (2004) respond to this need by proposing “a method for achieving an Enterprise Architecture Framework, based on the Zachman Framework Business and IS perspectives, that defines the several artefacts for each cell, and a method which defines the sequence of filling up each cell in a top-down and incremental approach”.

Conclusion

On the surface, the Zachman Framework would seem to provide a sensible way to approach the needs of all players when attempting to build a enterprise information system. It’s overall simplicity belies it’s use. Each of the framework’s thirty six cells produces at least one output document to describe the system from that particular viewpoint. It is understandable that critics are vocal about the amount of documentation produced when the framework is put to full effect.

It is also important to note that the Zachman Framework competes with other approaches to building Enterprise Information Systems. Whitman, Ramachandran & Ketkar (2001) along with Leist & Zellner (2006), note several models, methods, frameworks, architectures and methodologies available to an information system designer. Whitman, Ramachandran & Ketkar (2001) show the definitions and concepts behind several, while Leist & Zellner (2006) show the degrees of difference between differing frameworks, what needs they meet and how they could be improved. Given the difference in various frameworks and the needs of differing businesses, it may be useful to assess which framework best suits the type of project being considered by a business.

References

1. Ambler, S. (2007) Extending the RUP with the Zachman Framework. Retrieved on February 3, 2008 from http://www.enterpriseunifiedprocess.com/essays/zachmanFramework.html.
2. Hay, D. (1997) The Zachman Framework: An Introduction. Retrieved on February 2, 2008 from http://www.tdan.com/view-articles/4140/.
3. Leist, S. & Zellner, G. (2006) Evaluation of Current Architecture Frameworks. Proceedings of the 2006 ACM Symposium on Applied Computing. 1546 – 1553.
4. Nikolaidou, M. & Alexopoulou, N. (2008) Enterprise Information System Engineering: A Model-Based Approach Based on the Zachman Framework. Proceedings of the 41st Annual Hawaii International Conference on System Sciences. 399 – 409.
5. Pareira, C. M. & Sousa, P. (2004) A Method to Define an Enterprise Architecture using the Zachman Framework. Proceedings of the 2004 ACM Symposium on Applied Computing. 1366 – 1371.
6. Rafidah A. R., Zulkhairi M. D., Rohaya D., Siti S. K. & Sahadah A. (2007) Enterprise Information Architecture (EIA): Assessment of Current Practices in Malaysian Organizations. Proceedings of the 40th Annual Hawaii International Conference on System Sciences. 219 – 227.
7. Simsion, G. (2005) What’s Wrong with the Zachman Framework? Retrieved on February 3, 2008 from http://www.tdan.com/view-articles/5279/.
8. Varga, M. (2003) Zachman Framework in Teaching Information Systems. Proceedings of the 25th International Conference on Information Technology Interfaces. 161 – 166.
9. Whitman, L., Ramachandran, K. & Ketkar, V. (2001) A Taxonomy of a Living Model of the Enterprise. Proceedings of the 33rd Conference on Winter Simulation. 848 – 855.
10. Zachman, J. A. (1987) A Framework for Information Systems Architecture. IBM Systems Journal. Vol. 26, No. 3. 276 – 292.
11. Zachman, J. A. (2008) Zachman Framework. Retrieved on February 3, 2008 from http://www.zachmaninternational.com/2/Zachman_Framework.asp