Zachman Framework is "a descriptive framework" for information systems architecture, and was developed drawing on other disciplines as a source of inspiration (Zachman, 1987). The Framework comprises the following elements: identification, definition, representation, specification, configuration and instantiation (Zachman, 2008). This paper will seek to cut through the gobbledygook on the Zachman webpage and develop an understanding of what the framework is and how it was developed. Zachman developed the framework while working for IBM during the 1980s. He saw the problem as being that information systems were increasing in their size and complexity during this period, and believed that a response was to have a framework by which the architecture of such systems could be understood. This framework uses analogies from outside of information systems to explain IS architecture, allowing for better managerial understanding of information systems. He rightly recognized that the pace of IS complexity was increasing, and that moving forward it would be difficult to understand IS architecture without this framework and its accompanying language. Thus, he developed the framework in order to build this basis for understanding IS architecture, and published his ideas in the IBM journal (Zachman, 1987). The framework was developed as a combination of concepts and language from the disciplines of architecture and manufacturing.

In the 1990s, Zachman published the first major update of the framework. There were questions about the framework since it was first published, including about "the other three columns," and Zachman sought to address these questions with his updates and refinements in the early 1990s (Zachman, 2009). One key refinement was rebranding the framework as pertaining to enterprise architecture rather than information systems architecture. This refinement was partly to help market the framework, but also reflected the idea that information systems and the enterprise were closely linked, and both had to be engineered in order to optimized. Information systems, Zachman believed, could not simply be the domain of the IS department, but had to be part of the organization's overall strategy, and IS had to be built into that strategy.

There were further refinements in the 2000s. The framework was expanded, and some of the columns were explained in more detail. Graphic representation of the framework was continually improved over time -- indeed Zachman argues the key refinement in 2002 was, literally, "the use of the black and white gradient between the cells" (Ibid). One of the issues that was addressed in some of the later refinements was the use of IS terminology. The framework was never intended to be strictly for use in IS circles, and indeed Zachman has stated that the framework is meant to be simple, and relatively free from such jargon. Thus, many refinements of the past decade have sought to bring the framework back to the enterprise domain and away from the IS domain. The final evolution of the Zachman Framework was released in 2008. This version is "no different than the previous representation," differentiated only "because of the color of the models in each Row (sic)" (Ibid). The underlying logic of the framework has actually changed little over time, since the "other three columns" were addressed in the early 1990s.

Response

The Zachman Framework is considered to be a pioneering effort in terms of the idea of information systems architecture. It is one of several different frameworks available today. A critique of the framework is that it lacks "guidance on sequence, process or implementation" and "has no explicit compliance rules" (Urbaczewski & Mrdalj, 2006).

Zachman argues that the framework has gained in importance over time because the ideas of information systems architecture and enterprise architecture have become more mainstream in business, as the importance of information systems has grown. Now that information is one of the key sources of competitive advantage for many companies, it seems likely that IS models are increasingly useful in business, and that has called some attention to the Zachman Framework.

Scholars as well have found use for the framework. It has been used to explain modern enterprise architecture, as scholars fill in each box to understand the links between different architectural elements and organizational strategy (Pereira & Sousa, 2004). There has been study as to the best ways to operationalize the cells in the Zachman Framework, in response to the need for the framework to provide greater guidance with respect to implementation (Ostadzadeh, Aliee & Ostadzadeh, 2007). Frankel et al. (2003) acknowledge that the framework is one popular method of understanding enterprise architecture and seeks to compare it with a model-driven architecture. However, the limitation in terms of methodology remains -- if you cannot use it to do anything, why use it?

There have been other critiques...

Simsion (2005) also noted that there is limited explanation of how the framework can be used in practice. Managers, after all, are not overly interested in arcane theoretical constructs, but in what they can do to make their organizations better. While it is true that the framework provides a mechanism for understanding the organization's architecture, there are other methodologies that can also be used for this purpose, and can be extended to reveal coherent strategies for managers to implement.
Strategic Benefits and Industries

The Zachman Framework can be used in any industry, but is particularly useful where information systems are more critical. This encompasses a wide range of businesses. Understanding the architecture of enterprises has a number of advantages for managers. They can better understand how to achieve their strategic objectives, no matter what those objectives are. For example, Ross (2004) examined the effectiveness of enterprise architecture on different types of strategy. To do this she used -- without citation -- Treacy and Wiersma's value disciplines to understand different types of strategy. She found that there were strategic benefits for all types of strategies. Part of this can be explained by the fact that when systems are engineered, as Zachman argues in favor of, they can be tailored to meet different strategic objectives. Further, when management understands the systems that it has, it will be better able to change elements of that system in order to affect organizational change as a whole. The interconnectedness of different systems elements should be understood using the Zachman Framework, and that will help managers to understand how to deploy resources or change systems to bring about specific target objectives.

The basic concepts in the Zachman Framework are fairly universal, and that allows the framework to be used for many different types of company. Though it was developed at IBM, by no means was it intended solely for technology companies or large conglomerates. Any organization with any emphasis at all on information systems can benefit from using the Zachman Framework to understand its IS architecture in the context of its overall business strategy. It is because of this universality that the framework has been used in teaching about enterprise architecture, and it remains a valuable tool for IS practitioners as well.

Conclusion

The Zachman Framework has some merit as a means of understanding enterprise architecture, and has become widely known in the IS industry as a result. Despite attempts to make the framework more digestible for a non-IS audience, those attempts have only been in the theory. The reality in that in practice, the framework suffers from a lack of guidance. While IS professionals appreciate its ability to understand IS architecture, and the role of IS in the overall enterprise architecture, non-IS managers prefer models that offer methodologies and implementation guidance. The lack thereof in the Zachman Framework holds it back from being widely studied and implemented outside of the IS domain. The Framework's success in part comes from its use of metaphor, which helps audiences understand the concepts, but the challenge remains that it is hard to take the framework and make anything happen with it. As a tool, it needs to be able to do more to have true value to the manager. This is one of the most significant critiques of the framework and one of the reasons why it is not a mainstream managerial theory despite the fact that it was always intended to be just that.

References

Frankel, D. (2003). The Zachman Framework and the OMG's model driven architecture. Business Process Trends. Retrieved November 4, 2014 from http://petros.omg.org/mda/mda_files/09-03-WP_Mapping_MDA_to_Zachman_Framework1.pdf

Ostadzadeh, S., Aliee, F. & Ostadzadeh, S. (2007). A method for consistent modeling of Zachman Framework cells. Advances and Innovations in Systems. Vol. 2007, pp. 375-380.

Pereira, C. & Sousa, P. (2004). A method to define an enterprise architecture using the Zachman framework. SAC '04.

Ross, J. (2004). Generating strategic benefits from enterprise architecture. Center for Information Systems Research. In possession of the author.

Simision, G. (2005). What's wrong with the Zachman Framework? The Data Administration Newsletter. Retrieved November 4, 2014 from http://www.tdan.com/view-articles/5279/

Urbaczewski, L. & Mrdalj, S. (2006) A comparison of enterprise architecture frameworks. Issues in Information Systems. Vol. 7 (2) 18-23.

Zachman, J. (1987). A framework for information systems architecture. IBM Systems Journal. Vol. 26 (3) 276-291.

Zachman, J. (2008). John Zachman's Concise Definition of The Zachman Framework. Zachman.com. Retrieved November 4, 2014 from https://www.zachman.com/about-the-zachman-framework

Zachman, J. (2009). The Zachman…