| Myles Standish is introduced to an organization that has adopted the Zachman Framework (ZF) as an approach to structured technology development. This group is composed of mostly senior IT technologists and their adoption of the Zachman Framework has been successful in managing many enterprise-scale technology initiatives at Canaxia. The group has successfully applied many of the company's required processes for technology delivery and has also created a series of additional process definitions to satisfy all the dimensions of the ZF perspectives. Myles notices though that the culture of this group is centered around its framework and that, regardless of project size or intention, the entire framework is required to be applied, thus inducing an impressive initial overhead just to support the framework. The Zachman Framework, originally authored by John Zachman in the 1980s at IBM, has since become widely adapted by IT organizations as a framework for identifying and disciplining the various perspectives involved in an enterprise architecture. In practice, the ZF summarizes a collection of perspectives based upon an architecture. Those perspectives are described in a two-dimensional matrix that has axes defined by type of stakeholders and aspects of the architecture. The rows in Table 5-2 represent the views of different types of stakeholders. The columns, respectively, represent different aspects or views of your architecture as shown in Table 5-3. There are three important concepts to understand about the ZF: Within a column, the models are evolved/translated to reflect the views of the stakeholders for each row. The models within a single row should be consistent with one another, with the caveat that agile models are just barely good enough, so the models may not be perfectly consistent with an agile instantiation of the ZF. The ZF does not define a process for architecture. Rather, it defines the various perspectives that architecture should encompass. The ZF is a template that must be filled in by the processes specifically required by the organization. If the processes do not exist already, the ZF will help identify these gaps in the architecture.
Figure 5-2 is an example instance of the Zachman Framework. For each perspective defined by the two axes, a process is defined that is required for each perspective of the framework. Figure 5-2. Zachman Framework. 
Tables 5-2 and 5-3 describe the details for each item in the two axes described in Figure 5-2. Table 5-2. The rows of the Zachman Framework.Row | Description |
|---|
1. Scope (Planner's view) | Defines your organization's direction and purpose, defining the boundaries of your architecture efforts. | 2. Enterprise Model (Business owner's view) | Defines in business terms the nature of your organization, including its structure, processes, and organization. | 3. System Model (Architect's view) | Defines the enterprise in more rigorous terms than row 2, basically taking the model to a greater level of detail. In the original version of the ZF, this row was originally called information system designer's view. | 4. Technology Model (Designer's view) | Defines how technology will be applied to address the needs defined by the previous rows. | 5. Detailed Representation (Builder's view) | Defines the detailed design, taking implementation language, database storage, and middleware considerations into account. |
Table 5-3. The columns of the Zachman Framework.Column | Description |
|---|
1. Structure (What) | Focus is on the entities/objects/components of significance, and the relationships among them, within your organization. This column was called data in the original version of the framework. | 2. Activities (How) | Focus is on what your organization does to support itself and its customers. This column was called function in the original version of the framework. | 3. Locations (Where) | Focus is on the geographical distribution of you're organization's activities. This column was called network in the original version of the framework. | 4. People (Who) | Focus is on who is involved in the business of your organization. | 5. Time (When) | Focus is on the effects that time, such as planning and events, has on an organization. | 6. Motivation (Why) | Focus is on the translation of business goals, strategies, and constraints into specific implementations. |
Benefits and Shortcomings of the Zachman Framework The primary strength of the Zachman Framework is that it explicitly shows that many views need to be addressed by architecture. An immediate benefit of the views shown in Figure 5-2 is that they provide a reminder of the issues you need to consider in your architecture, whether or not you decide to adopt the ZF. Another implication is that one model does not fit all, as Agile Modeling (AM) multiple models principle implores. Furthermore, a single level of detail isn't sufficient either. Hay's data-driven approach in Data Model Patterns, requires several flavors of data model in the first column, whereas Moriarty's object-driven approach, in Business Rules Forum 2002 Presentation on Model Driven Architecture, requires several different flavors of class model. They do this because the audience for each row changes. A related strength is that the ZF explicitly communicates that architecture has several stakeholders in addition to the architects and developers. An implication is that you need to involve your stakeholders in the development of your architecture to ensure that it meets their needs, and ideally you want to follow the practice of active stakeholder participation. Unfortunately, ZF also has several potential problems: The ZF can lead to a documentation-heavy approach. There are thirty cells in Figure 5-2, each one of which needs to be supported by one or more artifacts. This is potentially a lot of documentation, so you have to really think about what information you actually need versus what information is nice to have; in other words, adopt AM's travel light principle. The value of creating and maintaining a document must be that it exceeds its cost. The ZF can lead to a methodology-biased approach. It is very easy to use the ZF to promote your preferred way of working, to use it to beat your methodological drum. That might work very well for you, but is it really the best option for your organization or your clients? It can be countereffective if you are not in a position to choose the right artifacts for your situation, artifacts that reflect your organizational culture, your business environment, your technical environment, and the skills of the people involved. The ZF can lead to a process-heavy approach to development. In Figure 5-2, you can see immediately the necessity of defining a collection of rigorous processes to support the ZF. To maintain traceability among the artifacts in those thirty cells, you need to develop and maintain a detailed traceability matrix or database of metadata. That sounds good in theory, but these activities quickly add overhead that grinds progress to a halt. The ZF is not well accepted within the development community. Although the ZF seems to be growing in popularity within the IT architecture community, it doesn't seem to have made it into the mainstream development culture. The ZF promotes a top-down approach to development. When people first read about the ZF, they tend to think that it implies a top-down approach in which you start with the models in row 1, work on row 2 models, and so on. This doesn't have to be the case. A top-down approach works in some situations, sometimes a bottom-up approach works, and other times a middle-out approach works. Start in whatever cell is most appropriate for your situation and iterate from there.
|
