The Zachman Framework

January 31, 2012

The Zachman Framework

January 31, 2012

During the time of the Industrial Revolution change occurred slowly and the dissemination of information flowed even slower. A great example of this is the machine that really started it all, the first power loom. The first power loom was invented by Edmund Cartwright in England in 1785. The first American power loom was not constructed until 1813 by Francis Cabot Lowell. In this time it took 28 years from the time the first power loom was created until the process was duplicated in America. This is a far cry from today’s fast paced information at your finger tips world. In today’s world companies must learn to adapt to the changes at record pace. We literally have the free flow of information at our finger tips. So how do we handle that change? One way is that we develop processes that will allow us to identify strengths and weaknesses within the organization. Those processes enable us to establish a path or paths for reengineering the company. Let’s not get too far ahead of ourselves though. We want to focus in on the process and how we determine the strengths and weaknesses of our company. The tool that you will find at the root of this process is a Zachman Framework.

The Zachman Framework is an Enterprise Architecture framework for enterprise architecture, which provides a formal and highly structured way of viewing and defining an enterprise. The framework is based on the six communication questions (What, Where, Why, Who, and How). These six questions are often shown at the top of the framework and they do not have any specific priority within the framework. The framework is a simple and logical structure for classifying and organizing the descriptive representations of an enterprise. It is significant to both the management of the enterprise, and the actors involved in the development of enterprise systems. While there is no order of priority for the columns of the Framework (What, Where, Why, Who, and How), the top-down order of the rows is significant to the alignment of business concepts and the actual physical enterprise. The rows represent the points of view of different players in the systems development process, while columns represent different aspects of the process. The level of detail in the Framework is a function of each cell (and not the rows). When done by IT the lower level of focus is on information technology, however it can apply equally to physical material (ball valves, piping, transformers, fuse boxes for example) and the associated physical processes, roles, locations etc. related to those items. The rows are generally a top down view of the different players in the system development process. They are often seen in the framework as (Scope, Business Model, Information System Model, Technology Model, Detailed Representations, and Functioning System). The Scope is the ball park view of the enterprise and business purpose. The Business Model is the owners view or the nature of the business, including its structure, function, and organization. The Information System Model is the architects view, or simply a more in-depth analysis of the business model. The Technology Model is the designer’s view of how technology might be used to address the information processing needs of the enterprise. The Detailed Representation is the builder’s view of the programs, database specifications, and networks. The functioning systems are how a system is implemented and made a part of the organization.

The major contribution of the Framework is its explicit recognition that there is more at work here than functions and data. From the beginning, we should be recognizing the organizational issues; from the beginning, we should be dealing with multiple locations; from the beginning we should be explicitly concerned with timing – triggers, schedules, and so forth.

The major contribution of the Framework is its explicit recognition that there is more at work here than functions and data. From the beginning, we should be recognizing the organizational issues; from the beginning, we should be dealing with multiple locations; from the beginning we should be explicitly concerned with timing – triggers, schedules, and so forth. Very simply put in today’s fast paced ever changing world we must adapt or we will disappear. The Zachman Framework is merely a tool for us to use to identify the areas of the Enterprise that are strong and/or week. It will help us to identify the opportunities and threats that we may encounter as we reengineer the processes of the enterprise.

Submitted by Jeff Putt

Notes:

1.http://en.wikipedia.org/wiki/Zachman_Framework

2.http://zachman.com/ea-articles-reference/54-the-zachman-framework-evolution

3.http://www.tdan.com/view-articles/4140/

4.https://apps.adcom.uci.edu/EnterpriseArch/Zachman/zachman3_files/zachman3.htm

The Open Group Architecture Format (TOGAF) is a framework to support the development of an enterprise architecture (EA). Its role as a framework means that it gives provides a structure and a methodology for defining the architecture, leaving the details to the implementers. While there are many possible frameworks for defining an EA, this post will focus on the development of TOGAF and compare its strengths and weaknesses against the leading competitive frameworks.

TOGAF is currently in version 9.1.(1) The original version dates back to 1995 and was based on the current DoD standard at the time, known as the Technical Architecture Framework for Information Management. The DoD gave The Open Group explicit permission to develop TOGAF based on this standard, and thus TOGAF was born. I believe this is an advantage that TOGAF enjoys, as the mission of The Open Group is “to lead the development of open, vendor-neutral IT standards and certifications.” Besides TOGAF and EA, The Open Group is involved in standards around platforms, security, enterprise management, service-oriented architecture, and others.(2)

TOGAF was originally created to support the Technology Architecture of an organization.(3) As of version 8, TOGAF has been extended to incorporate the four generally-accepted EA domains – business architecture, data architecture, applications architecture, and technology architecture. With this extensibility came a level of complexity unseen neither in the earlier versions nor in the closest competitors, namely Zachmann, Gartner, and FEA.

When I studied the Core Concepts of TOGAF 9.1, I found no less than five detailed diagrams which depict the interrelationships between deliverables, repositories, capabilities and continuums.(4) In my opinion, this is way too complicated without a dedicated staff to build and maintain the EA. The building of TOGAF relies on the Architecture Development Model (ADM) for accurate fulfillment. In this model are nine phases, one preliminary and eight iterative phases to complete an entire cycle of development. To begin a new cycle requires that each of the nine phases be completed once more, which in my view makes the framework somewhat inflexible.

In a comparison of the four major EA methodologies (TOGAF, FEA, Zachmann and Gartner) completed by Roger Sessions of ObjectWatch, he found that the strengths of TOGAF are in the areas of process completeness (guidance towards creating an enterprise architecture), vendor neutrality (likelihood of NOT being locked into a single vendor solution), and information availability (documentation about the methodology).(5) The next highest marks were given for reference model guidance (how the methodology helps with building a set of reference models) and time to value (speed to which high business value can be achieved from using this model). From the same paper, Sessions gave TOGAF its lowest mark in the area of maturity model, which is the ability to assess your organization’s EA maturity using the methodology. The complete scoring is shown in the table below.

Table 1 – EA Framework Ratings

If your organization is adopting ITIL, there is a close linkage to EA within the service lifecycle of ITIL. The chart below (6) depicts the connections between TOGAF and the ITIL frameworks.

Figure 1 – ITIL and TOGAF Mapping

Within my company, our EA team has chosen TOGAF as its methodology for creating our enterprise architecture. The team has been in place for over two years now, and they are still very actively creating content in order to document my company’s EA. I have been part of the meetings where the EA team is performing interviews to collect data that feeds this content. As a manager in the Technology Support area, I can honestly say that my area has seen little value from the contributions of EA. However, it has helped our application development area understand how they impact the lines of business. The volume of information collected by the EA team to date is quite substantial, and the repository is fairly complex.

In summary, the selection of an EA framework is largely dependent on how much of the EA question is being addressed and what criteria are most important to the organization. With sufficient manpower and cooperation across business lines, TOGAF can yield a detailed picture of an organization’s enterprise that is second to none. However, with the complexity of the framework and the level of detail collected, maintenance of the EA under the TOGAF framework will be a continual effort.

Submitted by Paul McGuire

Notes:

1.http://pubs.opengroup.org/architecture/togaf9-doc/arch/

2.http://www3.opengroup.org/

3.http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap02.html

4.http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap02.html

5.http://www.objectwatch.com/whitepapers/4EAComparison.pdf

6.http://www.best-management-practice.com/gempdf/White_Paper_TOGAF_9_ITIL_V3_Sept09.pdf