Abstract: Objective: The main objective of this study was to investigate and compare Enterprise Architecture Frameworks (EAFs) from different perspectives due to lack of investigation concerning Holistic Enterprise Architecture Frameworks (HEAFs). In order to achieve this goal, a comprehensive literature review of the history of enterprise architecture was done to determine the Enterprise Architecture Frameworks (EAFs) that is currently in use. This was followed by matching these frameworks to the established five enterprise layers namely business, process, integration, software and technology (or infrastructure). The literature review revealed a lack of investigation thus clearing showing the need to investigate the history of enterprise architecture to realize Enterprise Architecture Frameworks (EAFs) that is in use today and covers Enterprise Architecture’s Layers (EALs) which is considered by this article to be Holistic Enterprise Architecture Frameworks (HEAFs). Conclusion: In conclusion, this study was contributed to the existing body of knowledge by proposing Holistic Enterprise Architecture Frameworks (HEAFs).
INTRODUCTION
In the mid of 1980s, a lot of organisations used emerged technologies such as database and legacy system to store information considered to be a valuable asset of any organisation. With the passage of time and when organisations expand drastically, they realised that they were using these technologies without any strategic planning to minimise effort within their organization. Even later, they missed out the collaborative effort with their stakeholders externally. There has been a lot of rework in storing data and in using legacy systems to perform a lot of tasks in common. They also realised that these systems were not capable to adopt the rapid change in their businesses. Under these circumstances, the concept of Enterprise Architecture (EA) began to emerge. During the last three decades, there have been excellent attempts to establish different architectural frameworks to control enterprise effort. Some of them were built from scratch and some were adopted or improved based on the existed frameworks. This article began with the well Known definition of enterprise architecture. It was followed by identifying the enterprise architecture components. Moreover, it comprehensively reviewed the history of Enterprise Architecture Frameworks (EAFs) and briefly illustrated several of them. It ended up with the presentation of enterprise architecture layers proposed1 and comparing several EAFs against these layers.
ENTERPRISE ARCHITECTURE
Enterprise architecture was well defined by John Zachman, The Open Group, OMB (The Office of Management and Budget, US) and Gartner as summarized below.
John Zachman: Generally, architecture is defined by a set of descriptive arguments that are related and intended to develop a new enterprise which contains the basic things in order to make changes after creation of an enterprise architecture2.
The Open Group: Enterprise architecture is mainly to understand all the different elements making up the enterprise and their inter-relationship3.
OMB (The Office of Management and Budget, US): Enterprise architecture means a strategic information asset base, which defines the mission, the information and technology necessary to perform the mission and the transitional processes for implementing new technologies in response to changing mission needs. It also includes a baseline architecture, a target architecture and a sequencing plan4.
Gartner: Enterprise Architecture (EA) is basically an area, where some forces are identified and used to make changes to achieve the desired business goals and its outputs. In general, EA provides the business community and the IT leaders with some ready to use recommendations for changing policies and modifying projects to achieve the projected targets in business. Basically, EA is used a step forward to help decision makers for formulating future state architecture5.
Enterprise Architecture Component (EAC): Since, enterprise architecture field is too wide and deals with the enterprise as a whole including several sub architectures or layers, therefore the need for governing, controlling and coordinating the effort for integration between these layers is essential. Some researchers stated that there are frameworks, methodology, standards and tool sets that were created to serve this purpose6.
Architecture framework: It is important to understand the meaning of architecture and framework separately before illustrating the combined definitions of Architecture Framework (AF).
Architecture consists of structural components and their interrelationship, rules and guidelines that describe the design and its creation with time3. On the other hand, OMB described it as a unified approach to organize and suggest improvement in planning, documentation of activities, design and analysis of an architecture4.
The framework is composed of different components such as process and contents to be used as a tool to formulate thinking, ensure consistency and completion3. It is also described as a structure where information is organized to determine the scope of architecture and inter-relationship of architecture disciplines4.
After knowing the meaning of both words i.e., architecture and framework, then an architecture framework is defined as follows.
An architecture framework is basically an approach to describe in detail the architecture6. "It is a conceptual structure used to develop, implement and sustain an architecture3”. But oftenly, the term framework is used or misused to indicate the overall approach to architecture. For example, in TOGAF, the framework includes methods, maturity models and other supporting information.
Architecture methodologies: Methodology is a series of steps which are repeatable and can address a particular type of problem that typically centres on a defined process but may also include definition of content3. It is defined also as a sequence of techniques for developing an architecture6.
However, TOGAF Architecture Development Method (ADM) is probably the best known of generic methods, which can be used for most types of enterprises.
Architecture toolsets: There are many tools that can be used within an enterprise that respond to the business need. As a result, selecting a tool should be based on clear criteria to identify the best fit tool for the organisation. The open group architecture framework has a useful overview on this matter which can assist in selection6,7.
Architecture standards: Currently, there are several standards that describe EA and specify some of its components.
Computer Integrated Manufacturing Open System Architecture (CIMOSA): The CIMOSA is a European standard developed by AMICE (European CIM architecture) consortium. It was one of the most significant projects in the European Strategic Program on Research in Information Technology (ESPRIT) between 1983 and 19988.
Reference Model for Open Distributed Processing (RM-ODP): The RM-ODP was jointly developed by International Standards Organization (ISO), International Electro-technical Commission (IEC) and International Telecommunication Union (ITU-T). The main purpose was to define a reference model to integrate a wide range of future Open Distributed Processing (ODP) standards for distribution systems in order to maintain consistency among them. The reference model RM-ODP provided the coordination framework for ODP standards, created an infrastructure within which support of distribution, interworking and portability can be integrated9.
Basically, it is a combination of several basic international standards which are:
| • | Overview (ISO/IEC 10746-1; ITU-T X.901) |
| • | Foundations (ISO/IEC 10746-2; ITU-T X.902) |
| • | Architecture (ISO/IEC 10746-3; ITU-T X.903) |
| • | Architectural semantics (ISO/IEC 10746-4; ITU-T X.904)9 |
Joint Technical Architecture (JTA): The JTA provides the "Building codes" and when implemented, permits this flow of information in support of the warfighter. The JTA identifies a common set of mandatory information technology standards and guidelines for use in all new and upgraded C4I acquisitions across DoD. The JTA standards are used for sending and receiving information (information transfer standards such as internet protocol suite), understanding the information (information content and format standards such as data elements or image interpretation standards) and for processing that information. The JTA also includes a common human-computer interface and "Rules" for protecting the information (i.e., information system security standards)10.
Clinger-Cohen Act of 1996: It was announced by the US congress to appreciate the potential power of TAFIM for better alignment of technical projects with business need. This Act also is known as the Information Technology Management Reform Act (ITMRA). Also, ITMRA requests that all the IT investments within all the federal bodies should be improved in an effective way. This effort was overseen by creating a CIO council, consisting of CIOs from all major governmental agencies11.
Standards and architectures for e-government application (SAGA): It was a German Federal government’s project aimed to provide its services online to more than 350 users by 2005 under the Minister of interior supervision. In another study, it was mentioned that IEEE Std 1471-2000 is a Recommended Practice for Architectural Description (RPAD)12.
There are also many formal and industry-specific standards that were quoted by enterprise architecture. Among these, there are standards that deal with notation to define how to model and present entities and their relationship. For instant, Unified Modelling Language (UML) and ArchiMate were used for modelling the entire scope of enterprise architecture. On the other hand, Business Process Modelling Notation (BPMN) was used to model the business processes within an enterprise. However, all of above mentioned three standards were used as standard notations6.
HISTORY OF ENTERPRISE ARCHITECTURE FRAMEWORKS (EAFs)
In 1984, the original framework called as the information systems architecture: A framework was developed by Zachman having only 3 columns. Since, the enterprise architecture was not invented yet, so this was a framework for information systems architecture13. In 1987, an article titled as a framework for information systems architecture was published in the IBM systems journal13. It helped the organisations to document their information hierarchically and by function14. But according to Zachman, the business value can be realized by a holistic approach to systems architecture14.
In 1992, based on Zachman’s framework, the concept of Enterprise Architecture Planning (EAP) was developed by Stephen and named EA3 "Cube" framework. The main focus of EAP was as how to support business functions in an enterprise by using IT. But at the same time, it was a beginning to focus on business side rather than IT side14. Also it was of the view that the combined work of Zachman and Spewak formed the basis of most of the enterprise architecture frameworks that are in use today throughout business and government including the EA3 "Cube" framework14.
In 1992, Purdue Enterprise Reference Architecture (PERA) was developed at Purdue Laboratory for Applied Industrial Control (PLAIC) involving 10 companies. It is also the only one that clearly captures all interaction aspects of the human activities in an enterprise system8. In 1993, John decided to officially call his framework as The Zachman Framework™. Indeed, the other 3 columns were added as a result of his discussion with several friends from the business rules community because that is where the "Business rules" stayed originally13. In 1994, Zachman framework was influenced by the Department of Defence, US government to create enterprise architecture. It is known as the Technical Architecture Framework for Information Management (TAFIM)11.
In 1995, the open group adopted the work done on TAFIM into a new standard that is known today as The Open Group Architectural Framework (TOGAF). The DoD gave the open group explicit permission and encouragement to create TOGAF by building on the TAFIM, a result of many years of development efforts and many millions of dollars of US government investment3.
In 1996, the first version of Capgemini’s property Integrated Architecture Framework (IAF) was developed. It was influenced by ZF and EAP8. In 1996, the C4ISR architecture framework, version 1.0 was published, as well by the US Department of Defence (DoD). The C4ISR stands for command, control, computers, communications (C4), Intelligence, Surveillance and Reconnaissance (ISR). In 1997, the C4ISR architecture framework version 2.0 resulted from continued development effort by the C4ISR architecture working group15. In 1997, Treasury Information System Architecture Framework (TISAF) was developed by United States Department of the Treasury and in 1998, TAFIM was officially retired by the Department of Defence. This was due to fact that the General Accounting Office (GAO) noticed high-profile of failures among several federal agencies to adopt or use of enterprise architecture and has harshly chastised them. In 1999, the Federal Enterprise Architecture Framework (FEAF), version 1.1 was released by the CIO council and was enclosed11. "Some innovate ideas, such as "Segmented architectures" that is architectural focus on segmented subsets of the larger enterprise" FEAF, drawing on both the Zachman framework and Stephen Spewak’s enterprise architecture planning process.
In 1999, Generalised Enterprise Reference Architecture and Methodology (GERAM), an architecture for enterprise integration was developed by International Federation for Information Processing (IFIP)16. It is not a new framework but was derived from existing enterprise integration architectures such as CIMOSA, GRAI/GIM and PERA17. The IFIP/IFAC task force developed GERAM, because they believed that even though there are overlaps between existing integration frameworks, they are not identical and each has several aspects that the others do not16.
In 2000, Treasury Enterprise Architecture Framework (TEAF) was derived from an early US treasury model (TISAF) established in 1997, the US FEAF and the Clinger-Cohen Act of 19968. In 2001, The Zachman Framework™ was fully recognized, widely distributed and consisted of many refinements from the past 10 years of research13.
In 2001, the new version of IAF emerged as a result of combining the best practice of Capegemini and ernest and young consulting company8. In 2001, TOGAF version 7 was released3. In 2002, the FEAF was developed and included as a part of the Federal Enterprise Architecture (FEA)11. This development was conducted by the Office of Management and Budget (OMB) after the responsibility was assigned to them for federal enterprise architecture8,11.
In 2002, TOGAF version 8 "Enterprise edition", published in December and republished in updated form as TOGAF version 8.1 in December, 200318.
In 2002 as well, the Institute for Enterprise Architecture Developments (IFEAD) developed the Extended Enterprise Architecture Framework (E2AF) utilizing several years of experience in using several frameworks and it was built on other frameworks such as ZF, EAP, IAF and FEA8.
In 2003, the Department of Defence finalised and released the DoD Architecture Framework (DoDAF) developed based on USA DoD C4ISR architecture framework of 1.0 and 2.0 specifications as a result of increasing the demand for joint and international army operation15.
In 2004, after a significant research starting in 2001, The Zachman Framework™ also known as The Zachman Framework2™ was developed and fairly recognizable.
| Fig. 1: | Enterprise architecture frameworks timeline8 |
The most notable changes were the migration away from IS terminology to enterprise architecture terminology. The use of nouns also makes this version dramatically more precise13.
A history of the above frameworks in timeline and clarification of interdependence and their interrelation is given in Fig. 1.
As this figure failed to descript the history up to now, this article covered this shortage by extending the picture of the enterprise architecture history.
Gartner released the Gartner Enterprise Architecture Method (GEAM) by combining its approach with meta group enterprise architecture practice19. The two major parts of the GEAM are the Gartner enterprise architecture process model and the Gartner Enterprise Architecture Framework (GEAF)19. In 2005, MODAF was developed by MOD from the US Department of Defence Architecture Framework (DoDAF) version 1.0, but was extended and modified to meet MOD requirements20. However, in 2006, TOGAF version 8.1.1 was released18. In 2006, Australian Government Information Management Office (AGIMO) released the Australian Government Architecture (AGA) framework which was developed by adapting the Federal Enterprise Architecture Framework (FEAF) developed by the United States government. The FEAF is a comprehensive business-driven blueprint of the entire US Federal government and was adopted by a number of other countries and Australian government agencies21.
In 2007, the Federal EA framework, version 2.0 (FEAF-II) was announced22. In 2007, DoDAF version 1.5 was released23. In 2008, The Zachman Framework2™ was republished. It was the purest graphical representation containing all the improvements in the evolution and research on enterprise architecture for the last 10 years. The terminologies were carefully selected to include names from the enterprise and normative Zachman Frameworks™ giving extremely precise meaning to the enterprise framework and enterprise architecture in general13.
In 2008, MODAF version 1.2 was released22. In 2009, TOGAF version 9 was released3. In 2009, DoDAF version 2 was released24. In 2010, DoDAF version 2.02 was released23. In 2010, the latest release of MODAF version 1.2.004 was released24. In 2011, TOGAF version 9.1 was released3. In 2012, TEAF has been subsumed by evolving federal enterprise architecture policy as documented in "The common approach to federal enterprise architecture4".
Summary of EAFs history: From reviewing the history of Enterprise Architecture Frameworks (EAFs) the following points were noticed:
| • | There are several architectural frameworks for enterprise which were not in use at all. They were suspended or influenced by others. These frameworks are: | |
| • | TAFIM adopted by TOGAF. So, TOGAF will be selected | |
| • | C4ISR influenced in DODAF | |
| • | TISAF influenced in TEAF | |
| • | TEAF subsumed in FAEF | |
| • | EAP influenced in FEAF. So, FEAF will be selected | |
| • | The Zachman Framework™ was developed by the owner and still in use, so it will be selected | |
| • | The MODAF was developed by MOD from DoDAF version 1.0, but was extended and modified to meet MOD requirements. It is now internationally recognized as the best practice for enterprise architecting. It is widely used by its industry partners, such as BAE systems, Thales, Lockheed Martin, Boeing and Serco. It is also used by other government departments, such as GCHQ and external bodies, such as the national air traffic services. The MODAF was recently adopted for use by the Swedish armed forces24. For this reason, MODAF will be selected and DoDAF will be excluded | |
| • | The AGA was developed by adapting FEAF developed by the United States government | |
| • | The GERAM is not a new framework but derived from existing enterprise integration architectures which are CIMOSA, GRAI/GIM and PERA. However, all of these frameworks focus on the technical aspect and software component of enterprise architecture, so it will be excluded | |
| • | The E2AF and Gartner are commercial Enterprise Architecture Frameworks (EAFs) developed by privet sector. They will be excluded due to the restriction of their availability | |
In conclusions, the Zachman Framework2™, TOGAF version 9.1, MODAF version 1.2 and FEAF-II are likely to be the most used frameworks. According to Session11 TOGAF, FEA and Zachman are the most popularly adopted EA methodologies. This means that these frameworks are still the most accepted frameworks. So, they should be investigated to explore which of them covers all enterprise architecture layers proposed1.
Zachman framework: It is a scheme where an interrelationship between two dimensions of the historical classifications since the age of old time is described. Moreover, it is an integration for detailed description of complex ideas. Secondly, it is derived from a hypothesis set narrated by many Greek philosophers who defined it as a definition, identification, representation, pacification and configuration.
The Zachman FrameworkTM is represented by a 6×6 matrix consisting of columns and rows. It also represents an intersection between interrogatives and transformations. Overall it gives an idea of the total descriptive things in an enterprise as shown in Fig. 2.
The Zachman Framework™ is an ontology framework to describe the enterprise and not a methodology to create and implement the enterprise objects. The ontology framework is a structure that establishes the definition whereas a methodology is a process that provides the transformation.
Zachman framework theory: All the Zachman framework’s representations can be articulated in terms of things and relationships (i.e., Thing-relationship-thing models).
Logic of the Zachman framework: The logic of the framework is a two dimensional classification system which represents the communication interrogatives such as what, how, where, who, when and why. While the second part consists of ratification transformations which include to identify, define, represent, specify, configure and instantiation of the objectives.
Comprehensive and complete: As stated by many investigators, the classification of things is a comprehensive and complete on both the x-axis and the y-axis13,23.
TOGAF version 9.1: The TOGAF consists of methods and related tools for the development of an enterprise architecture by any organization for it local use. Moreover, it is developed by the open group’s members in order to improve enterprise architecture in and around the world. Also, TOGAF described four architecture domains namely business, application, data and technology providing full details of different components for the development of successful enterprise architecture according to the the open group3.
Figure 3 shows these layers as a part of meta-model.
FEAF-II: The scope of architecture and the views of relationship between the sub-architecture components were described by EA framework in order to analyse, design, documentation and report writing. However, version 2.0 of FEAF gives details of major areas of architecture to achieve the strategic goals of the business services. Besides, six sub-architecture domains such as strategic, business services, data and information, enabling applications, host infrastructure and security were outlined for successful enterprise architecture.
| Fig. 2: | Zachman framework23 |
| Fig. 3: | Detailed representation of the content meta model3 |
Strategy sub-architecture domain: The main objective of strategy sub-architecture is to highlight the mission, vision and goals of the enterprise under study.
Business sub-architecture domain: In general, the business sub-architecture elaborate the business plan and its relationship with the strategic plan in order to achieve the stated objective in the business plan. It further explains the different components of the business plan such as its units, mission and support services among the various business units. It also defines the efficiency and effectiveness of the business processes adopted for its success. In addition to the above, it also requires to study if improvement is needed in any of the process before its implementation to the sub-architecture domain for its workforce, standards and security issues.
Data sub-architecture domain: This sub-architecture deals with the flow of information needed to make the process successful after the identification of necessary lines of business and particular business services. It also include what methodology was adopted for its harmonization and standardization ensuring the data is protected, safe, secure, accurate and well formatted in a domain.
Applications sub-architecture domain: It is important here to identify the systems and its application, in need for generating, sharing and storing the data, information and knowledge in need by the business services and its merging into the IT systems. Furthermore, it requires to define the role of configuration management to create cost effective and efficient common operation environment. Lastly, domain issues such as workforce, standards and security need to be identified here.
Infrastructure sub-architecture domain: The infrastructure sub-architecture domain is basically a host for IT systems or applications which inquires about the types of data, voice, mobile and video network in this domain. It also involves the physical structures such as buildings, server rooms and other equipments for the working efficiency of this domain. It further determines that if the scalable cloud computing environment is needed and the organization in question is going to act as a consumer or service provider. Finally issues namely security, standards and work force have to be set for efficiency.
Security sub-architecture domain: According to the study of OMB4, this domain covers all the important aspects needed by the other sub-architectures such as security and privacy controls, effectiveness of the system, data flows, service workforce, systems, host network and its application (Fig. 4).
MODAF version 1.2: The review of MODAF provides the whole picture of the architecture, its components of development and full structure. It also allows to integrate the various elements involved in the architecture. Moreover, MODAF describes various standards and their interactions to achieve the desired output of the system.
MODAF views: Different views are described by MODAF where each point is a composite of many views thus highlighting some aspects within each view point. The MODAF also provides interactions among various components of a conceptual graphic and interaction between operational nodes and information flows (OV-3). It was observed that most of the MODAF communities of interest deal with population and exploitation of the sub-set of MODAF views. According to DoD24, the seven most important categorized MODAF views namely, strategic, operational, service, system, acquisition, technical and all other views are presented in Fig. 5.
Enterprise architecture layers: The Enterprise Architecture Layers (EALs) proposed by Winter and Fischer1 and BP trends Harmon25 will be discussed.
Enterprise architecture layers proposed by Winter and Fischer1: The second criteria of Holistic Enterprise Architecture Frameworks (HEAFs) is to include the five Enterprise Architecture Layers (EALs) proposed1. These five layers that should be included in an enterprise architecture framework to be holistic are:
| • | Business architecture: The business architecture represents the fundamental organization of the corporation (or government agency) from a business strategy viewpoint |
| • | Process architecture: The process architecture represents the fundamental organization of service development, service creation and service distribution in the relevant enterprise context |
| • | Integration architecture: The integration architecture represents the fundamental organization of information system components in the relevant enterprise context |
| • | Software architecture: The software architecture represents the fundamental organization of software artefacts, e.g., software services and data structures. A broad range of design and evolution principles from computer science is available for this layer |
| • | Technology (or infrastructure) architecture: The technology architecture represents the fundamental organization of computing/telecommunications hardware and networks. A broad range of design and evolution principles from computer science is available for this layer too |
| Fig. 4: | Federal enterprise architecture framework version 2 (FEAF-II)22 |
| Fig. 5: | MODAF layers20 |
Enterprise architecture layers proposed by BP trends: The BP trends, however, drew similar layers in a diagram named as enterprise architecture pyramid25. It includes strategy level, process level, implementation level and physical level25. However, the strategy level, process level and physical level are the same as the three layers represented1, which are business, process and technology (or infrastructure) layers, respectively. On the other hand, the implementation level in BP trends enterprise architecture pyramid not only compromises the application architecture and software architecture layers1, but also includes the human activity side within an enterprise. Figure 6 shows BP trends enterprise architecture pyramid and illustrates the deferent component of implementation level.
EA frameworks layer comparison: A comparison of selected Enterprise Architecture Frameworks (EAFs) against the Winter and Fischer1 layers is presented in Table 1.
Comparison summary: It is clear from the comparison that all selected frameworks cover all enterprise architecture layers proposed by Winter and Fischer1.
| Fig. 6: | BP trends enterprise architecture pyramid25 |
| Table 1: | Enterprise architecture frameworks comparison |
CONCLUSION AND FUTURE RECOMMENDATION
In conclusion, the Zachman Framework2™, TOGAF version 9.1, MODAF version 1.2 and FEAF-II are Holistic Enterprise Architecture Frameworks (HEAFs) as they are in use today and cover all Enterprise Architecture Layers (EALs). It is recommended for future studies to determine clear and comprehensive criteria for each of Enterprise Architecture Layers (EALs) to be defined as a holistic layer. Over all, this will add an impressive value to this study by determining which layers of these Holistic Enterprise Architecture Framework (HEAFs) are holistic too.
ACKNOWLEDGMENT
This study was carried by the author independently to show his skills as a Researcher and consultant is Management and IT including Enterprise Architecture, Strategy and Business Process Management. This study was done on self-supporting basis.