Comparison of Top Four Enterprise Architecture Frameworks

Introduction

Our world relies on an implicit sense of order and pattern. Everywhere, there is a pattern that governs all life processes and systems. In the business world, there is an implicit reliance on patters and structures as well. One of these patterns is called Enterprise Architecture and refers to the overall general pattern that dictates how the elements of a given organization or agency interact and come together. In a sense, the Enterprise Architecture is the blueprint or master code that determines the how the operations of a business is strategically aligned to best fulfill the goals and carry it in the direction that it has set for itself.

According to Schekkerman an Enterprise Architecture acts as the “collaborative force” that synthesizes business planning, governance, operations, information systems, and the enabling technology that serves as the platform for convergence. (2004, 12)  Different agencies of the United States government use Enterprise Architecture to direct their organization, and the concept is becoming increasingly popular in the business and corporate world because of its proven ability to streamline an organization and make businesses more efficient and profitable.

Order custom essay Comparison of Top Four Enterprise Architecture Frameworks with free plagiarism report

450+ experts on 30 subjects Starting from 3 hours delivery

Get Essay Help

In the corporate and business setting, it may be said that the term Enterprise Architecture refers to the synergistic merging of technology with agency operations. Every modern enterprise relies on some form of information technology and as these technologies develop and become more sophisticated and powerful, the need for Enterprise Architecture becomes more crucial in order to enable all types of organizations to take advantage of these technologies in order to achieve success and growth.

Given the potential value of Enterprise Architecture to a given company or organization, this paper intends to take a closer look at the top four types of Enterprise Architecture frameworks, give their salient features and from there, be able to come up with suggestions as to which types of organizations are best able to benefit from a specific Enterprise Architecture framework or model.

What is Enterprise Architecture?

As previously mentioned, an Enterprise Architecture (EA) establishes the roadmap that will direct the agency to best achieve its goals according to its core values and vision. An Enterprise Architecture achieves this through the streamlining and optimization of core business processes through the use of the most efficient and appropriate use of the various modalities of information technology. Schekkerman thus justifies the need for Enterprise Architecture, “a rigorously defined framework is necessary to be able to capture a vision of the entire organization in all its dimensions and complexity. (2004, 12-13) To be able to accomplish this, an Enterprise Architecture is buttressed by frameworks which allow the disparate elements of an enterprise to become synergized. (Schekkerman 2004, 13)  These frameworks help maintain the consistency of the information represented all throughout the organization, from the smallest departments to the topmost levels of the enterprise. (GAO 2006)

According to Lankhorst, an Enterprise Architecture is important because it allows an organization to have a “holistic view” of the enterprise of which it is a part of. (2005, 3) Enterprise Architecture views changes in light of the bigger picture. For example, a new policy or system may be beneficial for a specific department, but if it has adverse effects on the enterprise as a whole, then it will not be accepted because according to Enterprise Architecture what is good for a part should be good for the whole as well.

Enterprise Architecture has been described as “both a process and a discipline.” (McGovern 2003, 1) Enterprise Architecture is a process because it adheres to specific steps in order to produce the desired effect. It is a discipline because it is a “body of knowledge that instructs people on how to design the most efficient system for their particular situation. (McGovern 2003, 1) The Government Accountability Office in its 2006 report said that “A well-defined enterprise is an essential tool for leveraging information technology (IT) in the transformation of business and mission operations. It goes on to say that any attempt to modify or improve current IT environments is more likely to fail without any Enterprise Architecture to guide the endeavor. (GAO 2006)

Operating Models (OM)

In so far as Enterprise Architecture is concerned, the term operating models involve how the physical infrastructure is designed and deployed all throughout the enterprise. (Pal and Pantaleo 2005, 78)

The first model is the federated model or what is also known as the collaborative environment.  The “Federated model” and collaborative environments are very much dependent on a system of sharing. This model relies explicitly on an array of shared protocols and instruments that is applied or deployed in all aspects of the enterprise. (Pal and Pantaleo 2005, 79) The federated model does not depend on vendor-exclusive protocols or technologies that depend on the manufacturer’s proprietary design. In this model prefers open-source standards or those that are independent of any brand of architecture. Such preference for the open-source types of technology facilitates the use across a broad spectrum of systems and platforms, even as it maintains consistency and reliability. (McGovern 2003, 12) The less demands of a federated model on an enterprise’s existing architecture makes it an ideal model to use, especially in the beginning stages of the deployment of an Enterprise Architecture in an organization. Read about Corporate Governance at Wipro

Strong Centralized Operating Model

A federated model may either be under the strong centralized operating model or the weak centralized model. As the name implies, a strong centralized operating model has advantages in terms of top-level operations, or those processes that involve the entire enterprise. Centralization allows for a more holistic level of planning and affords for a greater sense of control across the entire organization. (Pal and Pantaleo 2005, 81) The term centralized is also synonymous with highly-standardized and allows the implementation of the industry’s best practices in all architectural levels. Because a strong centralized operating model is highly streamlined and tight, it is also very cost-effective and is very suitable for small and medium-sized enterprises.

One marked weakness of the strong centralized model is that it is not so keep on being responsive to the unique needs of the discrete units or departments. The nature or design of the strong centralized model makes it more ideal for top-level operations because it cannot be customized to address specific elements or units.

Weak Centralized Operating Model

The weak centralized operating model addresses the aspects where the strong centralized model fails to address or even consider of. The weak centralized operating model offers a higher level of control among the lower levels or tiers of the architecture and affords the unit a greater sense of autonomy or independence as far as their own units are concerned. By using this model, specific departments are better able to manage their own sub-level goals and priorities.

However, as with all other systems, there are certain limitations and disadvantages to the weak centralized operating model. Among these disadvantages are higher costs of deployment; because a weak centralized operating model may be unit or process specific, its use may require the installation of other infrastructures and technologies to address other areas of the enterprise. Second, the use of a weak centralized operating model may produce redundancies or repetitions of technologies.  This is directly related to the possible need to install other programs. Another possible risk is the creation of modular or disjointed competencies, where a unit is highly independent and competent but is unable to integrate itself in the larger organization. The last possible risk of using a weak centralized operating model is that it may result in an uneven and inconsistent delivery of services, excellent in some, mediocre in others. The last risk is secondary to the creation of modular contingencies. (SPICT, 2003)

“Indeed, the focus on individual unit needs can be at the expense of institutional needs.” (SPICT, 2003) The federated operating approach seeks to find a compromise between the need for unit autonomy and the importance of synergy. The federated model accomplishes this by allowing individual compartments to have a certain level of independence in so far as their local priorities are concerned, but making sure that these priorities are aligned with the goals of the enterprise as a whole. Specific responsibilities are clearly defined but only in so far as how these local responsibilities contribute to the core goals of the organization. (SPICT, 2003) The federated model seeks to achieve autonomy for departments and the streamlined and harmonious operations across the entire enterprise. A successful federated model is characterized by a strong and decisive “central leadership” while recognizing the contributions of the individual units. (SPICT, 2003)

Value of an EA Framework (for all OM)

An Enterprise Architecture framework addresses the concerns of all operating models, in the same way that the federated model attempts to reconcile the best features of the strong centralized operating model and the weak centralized operating model. Regardless of any type of operating model, utilizing enterprise-architecture methodologies has been proven effect positive changes in any enterprise’s bottom line. (Sessions 2007)  An Enterprise Architecture framework ensures than an organization derives maximum value from IT systems while keeping their costs low. IT systems have become increasingly expensive and sophisticated while the real and practical values that can be derived from these bloated IT systems have been diminishing. As such, the use of Enterprise Architecture methodologies has become very valuable in light of this situation, and a solid understanding of the various frameworks is needed to know how to best implement them.

EA Frameworks

Over the years, many frameworks have come and gone. Currently, most organizations make use of one of the following four types of Enterprise Architecture framework:

1.         Zachman Framework

The Zachman Framework provides a rigid and highly-logical model for defining an enterprise. This framework is a simple way of classifying the elements of an organization as based on the interrogatives or the 5 W’s and 1 H (Who, What, When, Where, Why and How). This model is named after John Zachman, who in 1987 introduced this very popular framework. In fact the name Enterprise Architecture came from Zachman himself. The use of a simple classification system is based on the concept of organization based on descriptive representations. (Lankhorst 2005, 24) The framework depicts “the intersection between the roles in the design process”, i.e. owner, designer, builder, and the elements of the design itself or the 5 W’s and 1 H. (Lankhorst 2005, 24) The taxonomy of the Zachman Framework is powerful and all-encompassing because it is capable of capturing the essence of the entire enterprise. Currently, the framework is standard for analyzing the elements of any Enterprise Architecture. It is also easy to understand and implement, can be used with a variety of protocols, and “can be used independent of existing tools and methodologies.” (Lankhorst 2005, 24)Some experts say Zachman Framework is actually a system of taxonomy because of the specific way that it classifies the elements of an enterprise.

The Zachman Framework is made by creating grids or cells whose entry corresponds to the labels in both the rows and columns. A given object therefore is classified in two ways, the role and its attribute. The matrix is then filled out carefully. The “what” corresponds to the data involved; the “how” refers to the function of the data; the “where” refers to the data’s location in the network; the “what” corresponds to the people who will handle the data; the “when” refers to the schedule; and the “why” refers to the purpose or motivation. The main idea behind the Zachman Framework is the use of an analogy between an enterprise designers and an architect. A building architect prepares different responsibilities or artifacts for each process. Every player will benefit from being given the complete picture or goal, but is only given specific domains or responsibilities. Each player functions according to the labels given, and is evaluated based on the performance as defined in the grid or matrix.

The main drawback of the Zachman Framework is that the infinite number of cells and the arbitrary relationships that exist among cells can create confusion and can pose as a potential source of problem. Sometimes, the need to have a good organizer can get in the way of the actual process.

2.       The Open Group Architectural Framework (TOGAF)

Like the Zachman Framework which may be better defined as an architectural taxonomy, most experts consider the Open Group Architectural Framework (TOGAF) as a process more than a framework. According to Lankhorst, TOGAF has four main components and they are the following:

High-level Framework – considers the overall architecture as composed of   closely interrelated elements of business, data, application, and technology. Considered as the “core” of the TOGAF framework. (Lankhorst 2005, 25) It is also called the ADM or the Architecture Development Method which contains the recipe for building the architecture.
TOGAF Enterprise Continuum - captures the interrelationships between different the levels of the enterprise and “illustrates how architectures are developed across a continuum”, (Lankhorst 2005, 25) ranging from core or foundation, to common, to industry, to organization architectures. This is comprised of two elements:

A.    TOGAF Foundation Architecture

B.     Building Blocks Information Base

TOGAF Resource Base – refers to the tools and methods available to achieve the other components.
TOGAF as a process complements the Zachman Framework. Zachman guides in the classification and organization of artifacts and TOGAF provides the actual process for creating the architecture. (Sessions 2007) TOGAF is very flexible in the sense that it does not define the end result or the product. It is disinterested in how the actual architecture turns out. According to Sessions, “TOGAF merely describes how to generate an enterprise architecture, not necessarily how to generate a good enterprise architecture.” (2007) The resulting architecture is dependent on how the actual process is manifested. The TOGAF may be more suitable for organizations that rely on strong interconnections and processes.

3.      The Federal Enterprise Architecture

The Federal Enterprise Architecture (FEA) may be considered as the most extensive application of Enterprise Architecture. It is used by the federal government of the United States in order to centralize and streamline all its agencies and departments under a single and standardized Enterprise Architecture. In the words of Schekkerman, the FEA was created “to identify opportunities to simplify processes and unify work across the agencies and within the lines of business of the Federal Government.” (2004, 105) The FEA will serve as the unifying architecture to integrate all existing architecture of the various agencies of the US government. The main purposes of the FEA are: to organize federal information; promote information sharing, help federal agencies develop their architectures; help federal agencies decide on IT systems investments; and provide better, faster, more responsive service to the citizenry. (Schekkerman 2004, 106)  It includes all federal organizations and bureaus, including sub-agencies and other organizations that federally funded and whose activities involve federal agencies. (Schekkerman 2004, 106)

While the FEA is fairly new and still in its infancy stage, it is a product of the many efforts to tighten the bloated bureaucracy of the government. (Sessions 2007) The FEA may be defined as Enterprise Architecture in practice or a complete methodology in action. The FEA may be adopted by organizations that are as complex and bloated as governments.

4.      The Gartner Methodology

The Gartner Methodology puts more importance on expertise and experiences rather than classification or processes. In the Gartner framework, the dynamic processes of any given enterprise give the architecture its vitality. The sophistication of your taxonomy or the genius of your process is useless if it cannot find any viable implementation or application. Gartner believes that an Enterprise Architecture is basically the creation of synergy among business owners, information specialists, and the technology implementers. The goal is bring these people together and unite them in a common vision, and that is the machine that will drive your architecture towards its goals.

The success of the enterprise or completion of a purpose is measured in terms of actual value such as profits and less overhead costs, not by crossing out an item in the Zachman grid or TOGAF process matrix. (Sessions 2007) In employing the framework, Gartner believes that enterprise architecture practitioners must start with the vision, the direction it wants to go and not where it currently is. (Sessions 2007) By knowing the goal, this can be compared to the current state of affairs and from there, be able to come up with a list of the things that must be done. The vision or goal is then made known to everybody concerned, making sure that it is understood. From there, every step or action is concentrated towards achieving the target.

EA Framework Criteria and Assessment

There are several ways to assess an Enterprise Architecture, but the most important criteria are the results. How has the Enterprise Architecture translated in terms of actual and measurable improvements in the organization? In a 2005 document issued by United States Office of Budget and Management (OMB) entitled “Federal Enterprise Architecture Program EA Assessment Framework 2.0” the FEA is to be evaluated in terms of: cost savings, cost avoidance, improved services to citizens, improved mission performance, improved management and use of information including greater dissemination, reduced collection burden on the public, and greater information sharing and collaboration, and technology consolidation and standardization. All of these criteria may be used by businesses and corporation, making sure to include profits in the factors for evaluation.

There is no law that requires one specific framework for a specific enterprise. Every organization is unique, and the best way to qualify which framework is best to come up with a list of needs according to importance and analyze how each framework addresses those needs. This is a good springboard to start you on your search.

Case Study - Industry Experience with an EA Framework

A leading automobile company had disaggregated operations spread across various locations in the globe. These operations include manufacture, assembly, research and development, sales and marketing, and after-sales services. Some of these processes were outsourced or managed by third-party contractors. As such, this posed a problem in terms of creating a synergy in the IT system given the disparate users, each with their own proprietary requirements. This resulted in significantly higher operational expenses. The company needs to have an IT team that is able to quickly respond to ever-changing business requirements given the disaggregated arrangement of the business.

The idea was to lay the foundations for an Enterprise Architecture that is able to establish a more intimate relationship between business and IT people. The EA practitioner helped the client by identifying a framework that would create the link between the company’s vision and the operations base. The Zachman EA Framework was recommended, where every application was organized and classified. By initiating the change by using Enterprise Architecture, the company was able to move in the right direction for achieving the all-important synergistic relationship between the company vision and the IT infrastructure. (WiPro 2007) The company was now able to use its IT assets in such a way that is purposive and self-directed.

Summary

The heart of any Enterprise Architecture is to harness the capabilities of an organization’s existing IT infrastructure and be able to use these technologies in ways that achieve the core vision of the organization. Enterprise Architecture it a process of designing the most effective template or platform upon which IT systems will be used in the most optimized way. The four frameworks analyzed here are not necessarily antagonistic of each other. They each serve a purpose and have their own unique advantages and disadvantages. The need to have organization and classification is addressed by the Zachman Framework. If process is the problem, then the TOGOF is the best model to use. For highly-complex and interrelated enterprises, the FEA is a good framework to adopt. If vision is the core issue, then the Gartner Framework is the best way to start. As with any endeavor, an intimate knowledge of your organization is required so that you can evaluate the various frameworks based on how it addresses your organization’s unique needs and circumstances.

References:

Enterprise Architecture: Leadership Remains Key to Establishing & Leveraging Architecture for Organizational Transformation. (2006). Government Accountability Office (GAO). DIANE Publishing.

Enterprise Architecture Consulting. (2007) Case Study: Enterprise architecture for an automobile company. Retrieved on November 18, 2007 from http://wipro.com/webpages/consulting/eac/eaccasestudy8.htm

Lankhorst, M. (2005). Enterprise Architecture at Work: Modelling, Communication and Analysis. Springer.

McGovern, J. (2003). A Practical Guide to Enterprise Architecture By Published. Prentice Hall PTR.

Pal, N., Pantaleo, D. (2005). The Agile Enterprise. Springer.

Schekkerman, J. (2004). How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework. Trafford Publishing.

Sessions, R. (2007) A Comparison of the Top Four Enterprise-Architecture Methodologies. ObjectWatch, Inc. Retrieved on November 18, 2007 from http://msdn2.microsoft.com/en-us/library/bb466232.aspx

SPICT. (2003) Advantage U of S: Strategic Planning for Information and Communications Technology at the University of Saskatchewan. Retrieved on November 18, 2007 from http://www.cs.usask.ca/faculty/bunt/AdvantageUS.pdf

United States Office of Budget and Management (OMB Federal Enterprise Architecture Program EA Assessment Framework 2.0. (2005)). Retrieved on November 18, 2007 from http://www.cio.gov/documents/OMB_EA_Assessment_Framework_2.pdf.

Don't let plagiarism ruin your grade

Run a free check or have your essay done for you

Check my essay Hire Writer