Abstract
This paper is about the Zachman Framework and its overall use as an Enterprise Architecture. The paper begins with the definition of Enterprise Architecture and framework in general. Then it shows a brief background about the maker of the framework, John A. Zachman. Next is the history of the Zachman Framework itself. Finally, we discuss the main purpose and structure of the Zachman Framework. Who is John Zachman?
John Zachman was born in 1934 and is the pioneer of the Zachman Framework. He was a former line officer in the United States Navy and a retired commander in the United States Naval Reserve. He graduated at Northwestern University with a degree in chemistry, was a former teacher at Turfs University, and served as a special advisor in three Schools of Library and Information Management: at the University of Southern California, Emporia State University, and at Dominican University (“John Zachman,” n. d. ).
In 1964 he joined the IBM Corporation and was best known for his contribution in the Information Strategy methodology (Business Systems Planning) and the Executive team planning techniques (Intensive Planning) (“John Zachman,” n. d. ). After 26 years of service, he retired from IBM Corporation. According to (“John Zachman,” n. d. ) he is now the Chairman of the board of the Zachman Framework Associates and the Chief Executive Officer of the Zachman Institute for Framework Advancement (ZIFA), an organization specializing in the advancement of company’s Enterprise Architecture.
Outside Enterprise Architecture, according to (http://www. zifa. com/zachman. html): Mr. Zachman serves on the Elder Council of the Church on the Way (First Foursquare Church of Van Nuys, California), the Boards of Directors of Living Way Ministries, a radio and television ministry of the Church on the Way; of the Los Angeles Citywide Children’s Christian Choir; and of Native Hope International, a Los Angeles-based ministry to the Native American people. Definitions Before we divulge into the Zachman Framework, we begin by defining what a “framework” really is.
According to The American Heritage Dictionary a framework is:
- A structure for supporting or enclosing something else, especially a skeletal support used as the basis for something being constructed.
- An external work platform; a scaffold.
- A fundamental structure, as for a written work.
- A set of assumptions, concepts, values, and practices that constitutes a way of viewing reality. It’s clear that we will be discussing the “technical” definition of what a framework is.
Based on the definitions the Zachman framework can be viewed as the “fundamental structure” of an Enterprise Architecture or even the fourth definition as a “concept, values, and practices” but according to one website the Zachman framework is not your typical framework per se, “Instead of representing the process as a series of steps, he organized it around the points of view (perspectives) taken by the various players” (http://www. valuebasedmanagement. net/methods_zachman_enterprise_architecture. html).
Others, like Bentley and Davis (2010) describe the Zachman Framework as a taxonomy “for developing and documenting the basic element of an Enterprise Architecture” (p. 80). Another important aspect of the Zachman framework is its development of the Enterprise Architecture. According to Ross, Weill, and Robertson (2006), Enterprise Architecture is “the organizing logic for business processes and IT infrastructure reflecting the integration and standardization requirements of the company’s operating model” (p. 7) The Enterprise Architecture serves as the checklist for the company’s business application and its alignment to its IT capabilities. Framework The main ideology of the Zachman framework is to populate and organize all elements of an enterprise and have an alignment to its information infrastructure. The Zachman Framework is built on the focus of six perspectives: planner, owner, designer, builder, subcontractor, and the working system. These six perspectives are represented on the row part of the matrix.
According to Zachman, “it was derived from analogous structures that are found in the older disciplines of Architecture/Construction and Engineering/Manufacturing that classify and organize the design artifacts created over the process of designing and producing complex physical products (e. g. buildings or airplanes. ). ” Principles The principle in creating a Zachman framework is simple: fill the gap within each cell of the rows and columns. Each cell should be unique. The rows represent the six perspectives and the columns are different aspects of the architecture to reduce complexity.
Therefore it can also be used by different levels of the organization. According to Bentley and Davis (2010), the framework “is defined independently of tools or methodologies, and you can map any issues against it to understand where they fit (p. 81). ” The framework will include a mixture of business plans and technical supports. In that sense, the framework should serve as an alignment between business and IT infrastructure. The alignment between business and IT can make the company agile to change.
Whether it is a simple improvement or a total change in the system, the company will be able to adjust smoothly and continue to improve on their architecture. In the end, the framework will yield a simple and none too technical descriptive representation of all the elements in the enterprise system. It can also be used as a tool to make decisions that involves improving or changing current systems. The next page show as a diagram of the Zachman Framework (Figure 1). Rows For this part, we look at Rows of the Zachman Framework.
The rows represent the six perspectives of the enterprise. The first one being the Planner, he or she is in charge of the overview of the system. The second being the Owner, he or she represents the business aspect of the architecture. Third is the Designer, he or she is in charge of the application of the technologies necessary in solving business issues. Fourth would be the builder, he or she is in charge of building the system. Fifth are the subcontractors, they are in charge of implementing the systems. Finally, the actual system itself.
Scope (Planner): This is where the scope of the enterprise is defined. This will stand as one of the basis of what systems to build. The planner is in part to create an executive summary of the model. Business Model (Owner): This is where the “nature” of the business is stated. It will include the business entities, functions, and processes. The owner defines his/her expectations from the architecture. System Model (Designer): This row defines the logical models and information required in building the system. This will also include model requirements and management.
The designer is tasked to create a system model that will be aligned with the business process. Technology Model (Builder): This row includes the technology, program, and data that will be used to meet the system model. The builder is tasked to choose the technology to be used for the system model. Detailed Representation (Sub-contractor): This row will have data definitions and actual implemented solutions. This can be viewed as improve and implement stage. Functioning System (Working Structure): This simply describes the functioning system that is in place in the enterprise.
It represents the end-product of the “architectural” system. It should be noted that the top two rows of the framework is heavy on the business aspect of the company. With that in mind, the top two rows should be aligned with the bottom rows or the technical side of the system. Figure 2 shows a brief summary of the Zachman Framework. (Bentley p. 81) Columns What – describes the material or physical tools required for creating the system. As shown in the Zachman framework, this column includes all entities in different perspectives.
How – or the functional description of the models. It also includes the list of all processes in each perspective. Where – is the list of locations in which the business operates and its corresponding interconnections in the enterprise. Who – describes the team members of the enterprise. It shows all varying positions, work allocation, and work instructions. According to Minoli (2008), the row shows the authority and the column describes the work allocation. When – describes the time frame of the projects and programs. This puts the time-box appropriated for every process.
It can be used as a measuring stick whether or not a certain project will make it on time, or if there’s an adjustment needed to make it through the deadline. Why – as seen in the chart, this describes the company’s business goals, objectives and strategies. It shows the motivation of the company in pursuing its goals. Figure 3, shows a more detailed summary of the Zachman Framework. (http://www. valuebasedmanagement. net/methods_zachman_enterprise_architecture. html) Advantages The advantage of the Zachman Framework is its simplicity.
It can be used by non-technical people like other department managers, owners, and other high-level executives. At the same time it can be used by the IT managers or CIOs of the company. Not only does it help in aligning both the business and technical support of the company it also helps bridge the communication gap between the departments. The framework also covers all aspect of the enterprise. As Minoli stated (2010), “the purpose of the framework is to provide a basic structure that supports the organization, access, integration, interpretation, development, management, and a (possibly changing) set of architectural representation of he organization’s information systems (p. 111)”.
By having all different perspectives of the system, the framework helps gain the buy-in of the high-level executives and shows the descriptive model of the IT department’s enterprise system. The framework can also be used as a “decision-tool” because as you fill the cells in the framework, you get a better scope of which will work within the system and which will not. Having all aspects makes decision makers see what the repercussions of their implementations. Disadvantages
Whether you view it as total freedom of the Zachman framework, other books have disapproved of the lack of methodologies for implementation in the Zachman framework. The methodology is only based on your understanding of the framework (Bentley ; Davis, 2010, p. 8). Another issue is that most of the guidance for building the framework is available through “consulting services contracted through ZIFA” (Minoli, 2010), which is a constraint for other companies. Some view the Zachman framework more of a “checklist” rather than an actual “blue print” for building an Enterprise Architecture.
A comparison chart was made by Roger Sessions (2007), Figure 4. He compared the Zachman Framework, TOGAF, FEA, and Gartner in twelve different categories and measured them to its value. He ranked them having 4 as doing a very good job in that category and 1 as doing a poor job in that area. Zachman Framework, scores low from almost all categories, but the author notes that not all criteria may be applicable to all organizations and that some may be more important to different companies.
Conclusion
In conclusion the framework can easily be understood, the concept of every cell is put in place, from different perspective to different aspects. The top two rows constitute mostly of the business side and the rest are focused on the technical aspect of the model. The Zachman framework tackles all entities of the enterprise and aligns business process with technical solutions. Hence it can also serve as a decisions model to look at which process needs improvement or should be changed.
As was said, the framework is independent of any tools or methodologies and can be used at different levels of the organization. The Zachman framework is not perfect in itself. More methodologies are needed in order to have a complete Enterprise Architecture and even then, changes from the environment can cause changes in the IT infrastructure. The Zachman Framework can be viewed as a start up for creating a functional Enterprise Architecture, it can be said that doing the Zachman Framework simplifies the whole concept but at the same time it defines a broad perspective.
According to Minoli (2008), there are two challenges in the present-day enterprise: one is creating a descriptive representation or model of the enterprise explicit and the other is developing the enterprise architecture process. The Zachman framework, answers the first challenge as it covers all aspects of an enterprise and covers the enterprise in its entirety. It gives business and technical managers a look in formulating enterprise architecture by populating all cells in the framework.
The second challenge is more of an on-going procedure, as teams build their Enterprise Architecture through the Zachman framework there will be constant changes and improvements. Even after completion, there is still administration and control needed, and perhaps even more improvements to adapt to changes in the environment.
