Enterprise Architecture Framework Analysis Essay
Enterprise Architecture Framework Analysis
In the past few years, information system practitioners and academics have turned there considerations to enterprise architecture (E. A). EA is way that is used to control the complexity and constant changes that are evident in environment of business. The task of managing an EA is complex and requires some ways that makes it less complex and one of the ways is employing Zachman framework. Zachman framework is a structure that is designed in a logical form so that it enables a comprehensive depiction of IT enterprise.
The framework allows multiple categorization and perspectives that works well with business artifacts. Therefore, it brings in older methods that are refined to develop the new model – Zachman framework. It brings rules and abstractions that help it to fulfill its obligations with possession of a 36 celled matrix (William, 2007, pp. 70). This compressive classification is used in descriptive representations or models for Enterprise Architecture in representing an enterprise. It was developed by John Zachman in early 1980’s and it has evolved to become a schematic that is universally accepted.
Its importance is in the describing and defining current complex enterprises system and at the same time manages the multiple perspectives of any kind of knowledge or information that concerns an organization infrastructure. It brings in the views of the artifact target: specifications, models and documents of the project and what specific issues should be addressed. It brings into play two dimensional models that is based into six foci interrogatives that includes function, time, data, people, motivation and network.
At the same time, it comes with six players’ perspectives that constitutes of owner, planner, designer, implementer, worker and builder. Hence, the intersection of the cells that constitutes the framework results to a holistic view of an enterprise. The framework contains rows and columns whereby the issues are represented by columns and the rows represent the roles that are played (Lankhorst 2006, pp. 29). It is an important framework when designing since it reduces the amount of software design when it comes to large information system.
The Zachman framework has the ability to manage and store documented information that concerns the system. It is a flexible means in which if there is any change that occurs, the documented support is able to change to the new demands while at the same time changes the requirements (William, 2007, pp. 58). Zachman defines the phases that are passed in two perspectives: the first one is viewing it has a purely business term and secondly has an information processing term without bringing in the issue of technology.
Zachman Framework defines the issue in terms of matrix that encomprises different foci interrogatives rather than the normal aspect of functions and data. Each process that takes place is not in terms of steps or phases but by perspectives. This means that each row that is in a matrix usually represents the perspective that represents the different players that are in the development process. This means that the system should be developed in terms of distinctive groups at the same time with different point of view.
This is different from other Enterprise Architecture which details its activities in terms of phases that moves from one step to another (Lankhorst 2006, pp. 28 – 29). Zachman Framework does not address the issue of transition explicitly or its relevant documentation. The matrix has system documentation organization and the transition between the process is achieved through movements that are termed as “as is” to the “to be” matrix. Zachman framework represents design representation that allows adjustments of requirements easily without any complexity.
This phenomenal is suitable in view of maintenance of the system. It further allows utilization of resources and supports different weights that are associated with designing criteria through the row by row fashion. Otherwise, if it were presented in terms of columns, solid results will be obtained because of the presence of functions, data, network, time, location, and people which are managed in a column wise fashion. The crosscutting that is associated with the framework can enable different stakeholders in the project.
This means that it has a greater importance in maintaining the infrastructure of any type of an organization in terms of column instead of depicting it as rows so that it enables coping and reducing maintenance problems. Hence, it reduces many complexities that are related with designing and at the same time increases the flexibility that can accommodate any new requirements. Zachman Framework is enterprise architecture but to some extent, it is a generic. This is because it is a comprehensive and a logical structure it allows the descriptive representations: design artifacts and models of the various complex situations that may exist.
However, it doesn’t describe or prescribe any representation technique, or particular method and an automation tool. The framework provides a way that is used for an enterprise in an organized version so that it is possible to analyze and describe the details of an organization. This framework enables it to focus on the specific aspects of the system that is in question, at the same time maintaining the sight of the enterprise context.
During the time of designing and building the relevant complex systems e. g. the enterprise systems where by it is associated with many details and relationships so that it is possible to consider it simultaneously. Therefore, it is useful to employ the Zachman Framework in developing a system instead of sub-optimization that comes with many risks and costs. There is a relationship between the Zachman and TOGAF because of the architectural association. The TOGAF four domains: Business architecture, applications architecture, data architecture and the technical architecture. These four stages fit with the first four stages of the Zachman framework.
Additionally, the other layers that are in the Zachman framework are incorporated into the TOGAF through the representation of Architecture Governance Framework and in the ADM scenario e. g. the Architecture Contracts. Hence, it ensures that viability and validity of the developed solutions suites the business needs (Ryan, 2004, pp. 23). Some parts of Zachman framework are associated with the FEAF enterprise architecture. The FEAF corresponds with the three first columns of the Zachman Framework and Enterprise Architecture Planning (EAP).
FEAF contains the guidance that employs the enterprise architecture and it is opposed to the IT architectures. However, even though the Zachman and the FEAF matrix share the same methodology it doesn’t define the approach that is used in developing the different cells (Inmon, 2006, pp. 157). Zachman Framework has the ability in working in a comprehensive way in taking care of the enterprise architecture stakeholders because it has an intuitive classification matrix. This enables in addressing the enterprise as a whole thing instead of working in terms of parts.
When the method is used (Zachman) it is easy to understand and apply even to the stakeholders and people who have less information concerning the issue. In addition, it does not bring in the methodologies or tools aspect. This means that it can be applied in any scenario if it is called upon. The enterprise architecture allows mapping between different architectures. It has a relation with various architectures that allows the other architectures to be mapped into it. This means that it is referred to as a core in the area of enterprise architecture (William, 2007, pp. 56).
It has some drawbacks such as it cannot allow large number of cells e. g. a maximum of 36. This forms an obstacle in its ability to operate. In addition, the relation between the different cells is not specific or it does not have any demarcations. Therefore, it requires heavy documentation in different models. Moreover, it brings the opportunity in defining collection of processes, hence leading it to become a process-heavy scenario (Ryan, 2004, pp. 26). It promotes a top-down approach to any type of development.
The belief that the starting of the first row in the models followed by the second model and so on seems like it is promoting the top-down approach. However, this is not the case because there is possibility of starting at any point of the cell-matrix. Generally, Zachman Framework provides sensible ways in attempting in building an enterprise architecture system. This is because of its simplicity and it is flexible. Therefore, the thirty six cells of the framework are capable of producing one output document in describing any system from the point that it is supposed to be viewed.
Many models can be employed in enterprise architecture and the Zachman framework is an example that brings in many accepts that deals with enterprise architecture. It has a matrix that contains 36 cells that contains details that describe a certain scenario and gives ways in which it can be worked on. It brings in many details (owner, planner, designer, implementer, worker and builder) that concerns with any business scenario with the help of functions, data, network, time, location, and people.
Additionally, it allows mapping of other enterprise architecture: FEAF and TOGAF into the Zachman Framework. Relation exists between those architectures that employ cells: row and columns like the FEAF and the TOGAF. This brings in its flexibility and diverse application with little restrictions. Even though it has a high flexibility level, it brings in large information hence making the architecture process to be heavy. This is because each model deals with specific issue at a time. The introduction of another issue s requires another matrix.
References Antony, T. , (2004). A comparative analysis of Architecture Frameworks, p. 1 – 15 Inmon, W. , (2006). Building the data warehouse. New York: New York Publishers, pp. 155 – 158 Lankhorst, M. , (2006). Enterprise Architecture at work: Modelling, Communication, and Analysis. London: Macmillan Publishers, pp. 24 -30 Ryan, C. , (2004). Zachman Framework. London: Routledge, pp. 20 – 27 William, H. , (2007). Data stores, data ware housing, and the Zachman Framework: Managing Enterprise Knowledge. New York: McGraw-Hill Publishers, pp. 56 – 70