In this document

In this document, the author explains the zachman framework, where did it came from and the rules of how to implement it in the enterprise architecture. He defines the framework of enterprise architecture as a two dimensional classification scheme for descriptive representation of an enterprise. It was derived through observation descriptive representation of many different objects, for example: airplanes, buildings, ships and computers. Through looking at the descriptive representations, product descriptions and the engineering documentations it was observed that the complex products can be classified by the audience for which the artifacts was constructed. The author also mentioned the perspectives of the framework by being represented over the process of engineering and manufacturing of complex products. The descriptive representations of the product that are prepared over this process are designed to express concepts/constraints relevant to the various perspectives. He also showed the principle prespictives in this order: The Owner’s Perspective (Row 2), The Designer’s Perspective (Row 3), The Builder’s Perspective (Row 4), A Scope Perspective (Row 1), An Out-of-Context Perspective (Row 5). For the sixth row, the author described it as not architecture because it is not a representation, it is the actual thing. In the abstraction of the framework, there are things to be considered that relate to the object being described which are: What it is made of, how it works, Where the components are located relative to one another, who does what work, When do things happen relative to one another, why do things happen. The author chose the word abstractions for this dimension of the Framework because the object being described tends to be so complex that it is impossible to take into consideration all of the interrelationships of all the various components all at one time. For the rules of the framework, the author made seven rules that needs to be followed in implementing the framework. The first rule is do not add rows or columns to the framework. The author says that adding rows or columns to the framework would denormalize the classification scheme because, adding Rows or Columns would introduce redundancies or discontinuities. The second rule is each columns has a simple generic model. Which means the basic generic model of any one Column is very simple: the variable it represents as related to itself. The third rule each cell model specializes its Column’s generic model. The fourth rule is no meta concept can be classified into more than one cell, to make sure there is no redundancy. Fifth rule, do not create diagonal relationship between cells, because it can create a very confusing communication problem. Sixth rule, do not change the names of the rows or cells for the same reason in not adding new ones. The last rule says the logic is generic, recursive. The Framework is generic. It can be used to classify the descriptive representations of anything and therefore to analyze anything relative to its architectural composition. It is recursive. It can be used to analyze the architectural composition of itself.
In this article, the author talks about the definition of Enterprise Architecture, the zachman framework and how to use it. Defining the term Enterprise Architecture as a group of people that are responsible for modeling and then documenting the architecture. Other times, the term denotes the process of doing this work. More commonly, when we are referring to the Enterprise Architecture, we are referring to the models, documents, and reusable items that reflect the actual architecture (Pereira, C. M., & Sousa, P. 2004, March). In the Enterprise Architecture it includes more than one architecture: business architecture, application architecture, information architecture, technical architecture and the product architecture. All these architecture compose the Enterprise Architecture. The author excluded the technical and the product architecture. The author also talked about the zachman framework saying that it provides a structured way for any organization to acquire the necessary knowledge about itself with respect to the Enterprise Architecture. It was formally published in 1987 with the aim to represent the information system artifacts providing a means of ensuring that standards for creating the information environment exist and they are appropriately integrated (Pereira, C. M., & Sousa, P. 2004, March). It helps govern the architectural process with the dependency, coherence, and traceability needed for an enterprise to manage change, and to ensure that the alignment is achieved. With its development it was taking into measures all the participants in the planning and maintaining activities of an organization’s Information Systems. The author also talks about the dimensions of the framework: data, function, network, people, time and motivation and how it is important to focus on each one while keeping the others constant. The author chose a method to define an Enterprise Architecture using the zachman framework saying that the Enterprise Architecture will be the zachman framework. The zachman framework is certainly the most widely known framework in the Enterprise Architecture context. The main reason is due to that fact that it is a very flexible framework, it does not impose a method and it does not restrict any user to a set of predefined artifacts. For the artifacts, they should be easily understood by business people, which implies some technical separation, and these artifacts should represent only and exclusively the content of each cell in helping to develop an Enterprise Architecture. The proposal of a method associated to the Zachman Framework introduces a unique and exclusive ambition (Pereira, C. M., ; Sousa, P. 2004, March). There are six steps that must be understood in wanting to implement the zachman framework. Step one, There is no dependency among cells’ concepts. Step two, The Entity Diagram, artifact of the cell ‘G’, must be elaborated, taking into consideration, the “things” described on the cell. Step three, The Classes Diagram, artifact of the cell ‘M’, has the Entities Diagram as its base. The fourth step is The Functional Decomposition must be fulfilled based on the above row’s artifact, indicating for each place the functional units and business processes. The fifth step, The Organization Chart, artifact of the cell ‘J’ is created by referring to the organization list. The last step is The Systems vs. Roles Matrix (Pereira, C. M., ; Sousa, P. 2004, March). In conclusion, the development and effective implementation of an Enterprise Architecture is a major challenge for organizations, the zachman framework help ease that challenge.
This article is going to talk about the Zachman Framework of Enterprise Architecture and its mapping to the Generalized Enterprise Reference Architecture and Methodology (GERAM) requirements. The aim of the Generalized Enterprise Reference Architecture and Methodology (GERAM) is to generate the contribution of various existing and emerging Enterprise Architecture frameworks and Enterprise Reference Architecture in order to define a complete collection of tools, methods and models to be employed by any enterprise engineering and integration effort (Noran, O. 2003). The author talked about the zachman life-cycle aspects by presenting it the phases as perspective of the various stakeholders involved in the enterprise engineering effort. Any entity being conceived, designed, implemented and possibly operated will eventually reach the end of its useful life. The Zachman framework does not explicitly cover this aspect (Noran, O. 2003). The author thinks that Zachman framework does not have an explicit life history concept, and thus only an implicit mapping is possible. For the zachman methodology, it aims to be generic by not prescribing a particular implementation or modelling methodology. However, some high-level guidance is available. Similar to other frameworks, Zachman identifies two main stages in enterprise modelling: model the existing enterprise so as to improve existing operational processes; change the enterprise using a generalisation of the models developed (Noran, O. 2003). The Zachman framework, like many other architecture frameworks came into existence in an initially partial form and has subsequently evolved into a more complete framework. GERAM may assist the evolution of life cycle architectures such as Zachman by identifying potential gaps and thus helping define their desired development areas (Noran, O. 2003).
The Zachman Framework is considered to be the most referenced framework for the purpose of Enterprise Architecture (Fatolahi, A., ; Shams, F. 2006). It is commonplace to compare other frameworks with this basic one in order to to show correctness and usability of those frameworks. However, the author says that the Zachman Framework is more than a fashion, and it is actually the best framework. The Zachman Framework can be challengeable framework in certain situations because there are not enough well known methods and tools covering all its aspects. The article will mention those three challenges: lack of a methodology, a well defined repository and a popular modeling notation. The Zachman Framework consists of six rows and six columns where the rows represent different participants perspectives in building Enterprise Architecture. Where the columns describe the same product for different purposes. By crossing each column and row they create a cell which contains a unique model. The main idea originated from the traditional architectural ideas in the area of civilization. The author considers it as an advantage for the Zachman Framework because it is based on previously examined and approved ideas. There are also some rules governing the framework which are responsible for its integrity: columns have no order, each column has a basic model, the basic model must be unique, each row represents a unique perspective, each cell is unique, the composition of all cell models in one row constitutes a complete model from the perspective of that row and the logic is recursive (Fatolahi, A., ; Shams, F. 2006). As we mentioned before that the Zachman Framework is the most popular framework in the area of EA, it still has some advantages and disadvantages. It became a basic for some other frameworks such as FEAF (Federal Enterprise Architecture Framework). One could hardly find a written material on EA without a reference to the Zachman Framework (Fatolahi, A., ; Shams, F. 2006). However, it is not an easy task to build up architectures using the Zachman Framework. Some difficulties will appear if you intend to do a full coverage of the framework. Those difficulties are the challenges that we mentioned before: lack of methodology which cover all the aspects in the framework, a well defined repository storing the framework in accordance with the integrity rules and popular modeling notation for all of its columns (Fatolahi, A., ; Shams, F. 2006). There are more than those challenges to be faced in building this framework or other frameworks as well. Since selecting a modeling notation is a prerequisite for making any methodology or implementing any repository for EA practices, the main challenge is selecting a unique modeling notations for all of the cells within the framework. The solution can be made in selecting a UML based methodology since most of the new systems are are being developed using UML a popular modeling language. UML and its business profile can be used for Enterprise Architecture modeling based on the Zachman Framework (Fatolahi, A., ; Shams, F. 2006). There are other opportunities for more work on the Zachman Framework since it is the most applied framework around the world.
This article talks about frameworks in general, organized models, covers the Zachman Framework with different examples and how to use the framework as an assessment tool. The purpose of frameworks is to help people organize and assess completeness of integrated models of their enterprises. Several popular frameworks have been used to architect enterprises, such as the Department of Defense Architecture Framework (DoDAF), the Federal Enterprise Architecture Framework (FEAF), the Treasury Enterprise Architecture Framework (TEAF). The Zachman framework, like many others, considers multiple perspectives of an enterprise (Bahill, A. T., Botta, R., ; Daniels, J. 2006). The more complex a system is, the harder it is to predict its actual performance. We can deal with complexity and performance predictions using integrated models and simulations of a business. Frameworks can help organize these models into multiple levels of abstraction to better understand how the business rules, organizational strategies and resources are turned into a physical system (Bahill, A. T., Botta, R., ; Daniels, J. 2006). The author defines the Zachman Framework as a normalized six by six classification schema for organizing descriptive representations of an enterprise. The rows represent different stakeholder perspectives of an enterprise, while the columns depict different areas of interest within those perspectives (Bahill, A. T., Botta, R., ; Daniels, J. 2006). It is simply just a framework, it is not a process nor a method or a tool. Each cell in the schema can be thought of as having two dimensions scope and level of detail. The rows represent different perspectives and roles of the enterprise: scope, business model, system model, technology model, detailed representation and real system. For the columns, they present these aspects of the enterprise: what (data), how (functions), where (network), who (people), when (item) and why (motivation). The models organized by row and column in the Zachman framework should be horizontally and vertically integrated. This means that you should not work models in a given cell without considering impacts to other cells in the same row and in the same column (Bahill, A. T., Botta, R., ; Daniels, J. 2006). The Zachman Framework is also useful as a general assessment tool. The framework, as a normalized schema for organizing a complete and holistic set of architecture descriptions can be effectively applied to assess existing artifact sets, or even determine an optimal skills mix for architecture development. It can be used to gather existing models and documentation about the subject of the architecture and arrange them into appropriate cells within the framework. For conclusion, to ensure a complete and holistic understanding of the enterprise architecture, it is necessary to develop models that address the perspectives and aspects that constitute the rows and columns, respectively, of the framework. When constructing these models it is important to use whichever modeling notation and tool that is most appropriate for conveying the value of the information captured in the models. This may lead to a list of entities, a differential equation model, a set of DoDAF artifacts using UML or IDEF notation, or maybe a simple paragraph (Bahill, A. T., Botta, R., ; Daniels, J. 2006).