2009 10th ACIS International Conference on Software Engineering, Artificial Intelligences, Networking and Parallel/Distributed Computing

A Comparative Analysis of Enterprise Architecture Frameworks based on EA Quality Attributes

Department of Network Centric Warfare, 2Graduate School of Information and Communication Technology Ajou University San5 Woncheon-dong, Yeongtong-Gu, Suwon, Korea {nklim71, tglee24, psg77}@ajou.ac.kr and Time. The comparison criteria for each EAQA were also made. Finally, we compared and analyzed EAFs. We discussed the characteristics of the EAFs and the way of selecting the most suitable one to satisfy users requirement. II. RELATED WORK An enterprise is an organization (or cross organizational entity) supporting defined business scope and mission. It implicitly implies the scope concept and it means the widest area in general as in Fig. 1. In this paper, we divide the scope as follows; Enterprise scope, Domain scope, Program scope, Project scope, and Component scope.

AbstractMany Enterprise Architecture Frameworks (EAFs) are in use today to guide or serve as a model for the enterprise architecture development. Researchers offer general comparative information about EAF. However, there has been little work on the quality of Enterprise Architecture (EA). This study provides the characteristics of the five EAFs using comparative analysis based on Enterprise Architecture Quality Attributes (EAQAs). The attribute of EA quality was extracted from the EAFs and the definition of EAQA was defined from EA user viewpoint. The criteria for each quality attribute were developed to compare EAFs using four dimensional concepts. This paper compared several frameworks using the criteria to provide guidance in the selection of an EAF that meets the quality requirement of EA Keywords-enterprise architecture; enterprise architecture framework ; quality attributes

I.

INTRODUCTION

EA provides a knowledge base and support for decision making within the enterprise and it serves as the blueprint of current situation and strategy for future directions of the enterprise [1]. EAF describes the fundamental elements of an EA and the relationship between them [2]. It defines suggested architecture artifacts and generic definition for developing architectures and a logical structure for classifying and organizing enterprise system [3] [4]. It also provides the guidance about the EA artifacts. Since well-defined artifacts provide good enterprise operational information and system management, an appropriate EAF selection determines the quality of the EA. Researchers offer comparative information about EAF. Tang et.al provide a comparative analysis of architecture frameworks based on their own fundamental element goal, input, and outcomes [5]. Goethals compares the EAF based on the artifacts [6]. Urbaczewski et.al distinguishes the EAFs based on the view, abstraction, and system development life cycle [7]. J.W. Kim et.al compares the EAFs based on their feature [8]. The objective of this paper is to provide the characteristics of EAFs using EAQAs. In order to establish a common ground for the comparison based on the EAQAs, we studied well-known EAFs and extracted EAQAs from them. Secondly, we defined EAQAs and reified them using four dimensional concepts; View, Perspective, Scope,

Figure 1. Enterprise scope concept.

The most widely accepted definition of the EA is the one produced by Federal Enterprise Architecture Framework (FEAF). It defines EA as a strategic information asset base, which defines the agencys mission and business activities supporting the mission, the information necessary for agency operations, the technologies necessary to support operations, and the transitional processes necessary for implementing new technologies in response to changing business needs. EA is an integrated model or representation of the enterprise [3]. EAF is a tool that defines the suggested architecture artifacts and generic definition which can be used for developing a different IT architecture and a logical structure for classifying and organizing complex information [3][4]. Many EAFs are in use today and they provide the guidance to produce EA artifacts. EAFs have been designed to address specific needs and concerns of an organization. Examples include; Zachman Framework (ZF) is the earliest framework which provides a generic definition of EA and use it as the enterprise entities description [9], the U.S. CIO council released the Federal Enterprise Architecture (FEA)

978-0-7695-3642-2/09 $25.00 2009 IEEE DOI 10.1109/SNPD.2009.97

283

to provide federal guidance for the EA activities[10], the Department of Defense established the Department of Defense Architectural Framework (DoDAF) to define common approach for architectures of DoD[11], the Department of the Treasury released the TEAF (Treasury Enterprise Architecture Framework) to provide a framework for producing an EA and guidance for EA lifecycle activities of the department [12], and the TOGAF (The Open Architecture Group Framework) was established by the open group to provide tool for defining an IT architecture [13]. There is no standard classification for the EAF, yet. So we classified the frameworks according to their usage for the convenience of EAF categorization -- descriptive, prescriptive and combined frameworks. The descriptive framework mainly specifies what an architect is. The most famous one is the ZF. It models an enterprise with 30 cells to describe enterprise elements and provided the description of each cell. DoDAF and TEAF also can be classified as the descriptive frameworks. Some frameworks describe activity of EA lifecycle consisting of definition, development, use and maintenance activities. We define these types of frameworks as prescriptive frameworks. Examples are FEA and TOGAF. The combined framework has the characteristics of descriptive and prescriptive framework. It describes how to make architect and EA lifecycle activity. FEAF and LTGAF[14] are the combined framework. According to the IEEEs definition, Quality is the totality of features and characteristics of a product or a service that bear on its ability to satisfy stated or implied needs. Quality attribute is the element which affects quality degree. We found that the process quality leads to the product quality [15] [16] [17]. Consequently, EAF induces EA quality because EAF provides guidance about EA modeling, development, employment, and maintenance. Quality can be defined differently by the users concern and viewpoint [18], so the degree of satisfaction about product should be measured by the users viewpoint. III. EA QUALITY ATTRIBUTES We define EA quality as the degree of features and characteristics of a product or a service of EA that bear on its ability to satisfy EA users needs. We firstly had to define users demand of EA to understand EA quality. Based on the understanding of the correlation between EA and EAF, we studied well known EAFs (ZF, FEAF, FEA, TOGAF, TEAF, and DoDAF). The requirements for EA are well specified in terms of objective, purpose, needs, benefit, and reason of EA in each EAF document. The attribute items were condensed by the meaning of the sentence. The following items were collected from EAF analysis: Interoperability, Procurement, Flexibility, Information System Management, Reusability, Scalability, Reduce Redundancy, Portability, Reduce Risk, Standardization, Reduce Complexity, Reduce Time to Market, Alignment, Maximize RIO, Seamlessness, Better and Faster Service, Integration, Efficiency, Communication, Innovation, Information Sharing, Change Management,

Information Quality, Survival and Success, Planning and Decision Making, Adaptability. The quality is the degree of satisfaction of the user about their requirements and these items are defined the reason why the EAF is needed. Therefore we named these items as quality attributes. IV. BASE FOR ANALYSIS

A. Definition for attributes We could understand that various attributes were required to achieve EA quality. However, some have similar and ambiguous meaning, for example, Reduce complexity, Standardization, and Communication. We defined each attributes to make objective and reified evaluation criteria from EA users viewpoint because quality attributes could be understood differently by the EA user such as Planner, Owner, Designer, Builder, and Sub-contractor Interoperability provide information and guidance to facilitate exchange information and use of it among enterprise systems and users such as description about status of enterprise system for the every EA user, standard, reference model and method to reduce system complexity Flexibility provide information and guidance which help enterprise to adapt (change) the external or internal needs such as description about status of enterprise entities for the every EA users concerns, standard and modeling guidance for system construction. Reusability provide guidance that system or artifacts are to be used in more than one system, such as system and business reference model, modeling guidance for artifact. Scalability provide guidance to help efficient modification for system expansion such as standard, modeling guidance, and method to reduce system complexity. Portability provide guidance to facilitate that system or components easily move other places such as system and component standard, modeling method, and reference model. Standardization provide standard to keep standard profile. Alignment provide ways that management intention aligns with system implementation technology, business diver aligns with system development, and enterprise scope system aligns with project scope system. Integration provide method to realize that the business rules are consistent across the organization and system implementation is consistent within enterprise scope Communication provide information to improve communication among the business organization and IT organization within enterprise [6] such as understandable information about enterprise entities for each EA user and standard vocabulary.

284

Information Sharing and Quality provide ways to improve information sharing and quality (timeliness, consistent, integrity) across the organization efficiently and effectively. Planning and Decision Making, IT Investment, Information System Management, Procurement, Highlight Opportunity, Reduce Risk provide information about current and desired status of enterprise and new technology for IT and Business manager and decision maker to explain critical issues Reduce Redundancy provide information for the current system redundancy. Reduce Time to Market, Maximize ROI (Return on Investment), Better and Faster Service, Efficiency provide linkage of SDLC (System Development Lifecycle) management and EA model to increase efficiency of enterprise. Innovation, Management Change, Survival and Success, and Adaptability provide transition plan from current status to desired status for business success and enterprise survival.

B. Defines Criteria for QAs and Categorize QAs Every quality has multifaceted characteristics that can be evaluated differently from the several viewpoint, so that the 4 dimensional concepts: View, Perspective, Scope, and Time are used to categorize the quality attributes and to define concrete evolution criteria as in Fig. 2. The View dimensional concept is used to capture the effectiveness of the EA modeling method and link EAF with QAs. View is the way EAF represents the specific part of the enterprise from a user interest (window) and it provides modeling and categorizing guidance for enterprise entities such as, data, function, network, people, time, and motivation in the ZF also. The following attributes are related to enterprise entities modeling and categorizing method from the effectiveness viewpoint: Interoperability, Flexibility, Reusability, Scalability, Portability, Standardization, Communication, and Reduce Complexity. These attributes need entities standard and modeling method for each entity to achieve quality.

The Alignment attribute requires every enterprise entity to align from the business entities to technology entities. The Seamlessness attribute requires the method of integration for function and business entities to seamless service. The Perspective dimensional concept is used to capture the performance of the EA usage and link EAF with QAs. Perspective defines the way EA usage from the enterprise users such as, Planner, Owner, Designer, Builder, and Sub-contractor in ZF or System development lifecycle (Plan, Design, Build, and implement). The following attributes are related to enterprise entities use from the performance viewpoint: Interoperability, Flexibility, Reusability, Scalability, Portability, Standardization, Communication, and Reduce Complexity. These attributes require entities model to be modulated inside layer and decoupled between layers to support user requirement. Enterprise entities have to be aligned from the business driver to system entities to support Alignment attribute. Description about current, desired enterprise status and transitional plans are needed for every EA user to support Planning and Decision Making attributes. The Scope dimensional concept is adapted to capture the efficiency of the EA use. The Scope dimensional concept is related to the Scope integration for the quality efficiency. EAF needs to provide scope integration concept from project to enterprise scope and between enterprises to achieve efficiency of following attribute --Interoperability, Flexibility, Reusability, Scalability, and Portability. Maintaining alignment from project development to enterprise development plan increases the Alignment attributes quality. Information Quality, Information Sharing, Planning and Decision Making, Reduce Redundancy, and Efficiency attribute increase quality when the implementation area of EA is wider. The Time dimensional concept implies the realizing the outcome of EAs. In order to realize Maximize RIO and Better and Faster Service, the linkage between EA models and system development cycle is required. Transitional plan is required for effective and efficient Innovation, Change Management, Adaptive, and Survival and Success attributes quality. V. EAF COMPARISON This section provides a high level comparison and analysis of three descriptive and two combined EAFs. We categorize the quality attributes into four dimensional concepts and select criteria which need to support attributes from each dimensional concept. Table 1 provides an overview and comparisons of EAFs. If an EAF support criteria in the table, it is reported as . is reported when the EAF supports criteria partially. is reported when the EAF isnt supported. I means that the criteria for the attributes are implicitly supported. Otherwise the criteria are supported explicitly.

Figure 2. EAQA Modeling Framework

285

TABLE I.

COMPARISON OF EAF Descriptive Framework DODAF Combined Framework LTGAF FEAF

EAQAs

Criteria ZF

Interoperability Flexibility Reusability Scalability Portability Standardization Communication Reduce complexity Alignment Seamlessness Interoperability Flexibility Reusability Scalability Portability Communication Reduce Complexity Alignment Integration Planning and Decision Making Interoperability Flexibility Reusability Scalability Portability Alignment

Reference Model/ Standard

From Biz to technology Integration in Function Layer decoupling (Clear description) From business driver to model Integration method Enterprise status & Transitional plan Scope Integration From Enterprise to Component Integration method

(I)

(I)

(I)

(I)

* *

(I)

(I)

(I)

(I)

*

A. Zachman Framework (ZF) ZF describes enterprise with two dimensional models with 30 cells which result from intersection of the five perspectives (Planner, Owner, Designer, Builder, and Subcontractor) and six basic interrogatives (What, How, Where, Who, When, and Why). The ZF can be categorized as the descriptive framework because it provides a brief description of artifacts. The ZF provides alignment for the view, perspective, scope dimension but alignment in view, scope dimension is partially supported because the ZF doesnt provide technology model and align method between enterprises. Several perspective dimensional attributes are supported implicitly. The ZF provides integration --view, horizontal, scope integration -- based on the sliver and Integration concepts. For effectiveness and standardization, most EAFs provide Reference models of each view but ZF doesnt. ZF is a conceptual framework which provides outline of the building model but it does not contain a transition plan and no linkage to SDLC. B. Treasury Enterprise Architecture Framework The TEAF is consisted of the four views (Functional, Informational, Organizational, and Infrastructure) and four perspectives (Planner, Owner, Designer, and Builder) to describe enterprise entities and guide for developing and managing EA activities. Basically, the TEAF adopted the ZFs view and perspective for modeling enterprise entities and it specified more detail and trimmed description about artifacts. The TEAF grouped the work product like EA direction, EA description and EA accomplishment products and categorized product such as essential or supporting work products. The TEAF model the enterprise by the view and perspective. However, designer (logical) and builder (physical) model is not mandatory and may hamper the efficiency of view dimensional attributes. Providing the transition plan increases quality of Planning and decision making and time dimensional attributes. No description of Scope integration results in degrading the efficiency of scope dimensional attributes. C. Department of Defense Architecture Framework DoDAF specifies the three views: the operational view, the systems view, and the technical standard view to provide guidance for describing architectures and it provides several reference models to make converge to the DoD standard. It provides decoupling enterprise entities using only data layer and presentation layer that result in degrading dimensional attributes. It also provides scope integration concept using integrated architecture supporting scope integration related attributes. Linkage architecture model and system life cycle model and transition plan are not specified within the framework. D. Federal Enterprise Architecture Framework The FEAF is a combined framework which prescribes the artifacts and procedure for development and maintenance of EA and framework elements. It adopts two dimensional

Dimension View Perspective Scope Time

TEAF (I)

(I) (I)

(I) (I)

(I) (I)

* * * (I)

(I)

(I)

(I)

*

(I) (I) (I) (I)

(I)

(I) (I) (I) (I) (I) (I) * (I)

* * (I) * * * * * (I)

Integration

Information (I) Sharing Information (I) Quality Scope Planning and Integration Decision (I) (I) Making Reduce IT Redundancy (I) (I) Efficiency Maximize RIO Linkage model with Better and Faster SDLC Service Innovation Management Change Transitional plan Adaptability Survival and Success *: conceptual description, I : Implicitly

*

*

286

model with the five perspectives (Planner, Owner, Designer, Builder, and Sub-contractor) and three interrogatives (What, How, Where) from the ZF. It provides scope integration method related to QAs based on segment architecture concept and time dimensional QAs by providing the conceptual transition plan implicitly. E. LTGAF( LTG Architecture Framework) The LTGAF is composed of two conceptual frameworks. The first one is a descriptive framework based on ZF and the second one is a prescriptive framework specifying the EA life cycle activity. The LTGAF-prescriptive framework is composed of ten phases - Vision, Mission, Goal, Objective and Strategy planning, Business Identification, Transitional plan, Implementation plan, Implementation, Evaluation. The descriptive framework addresses view, perspective and scope for enterprise modeling. The model entity is similar to ZF but this framework explicitly describes the View, Perspective and Scope Integration. LTGAF provides inherited QAs from ZF; such as, scope integration related QAs, time dimension QAs by providing the transition plan from the prescriptive framework. However, LTGAF doesnt provide reference model for the enterprise standardization.

The linkage between the architecture model and system development life cycle is needed to realize EAQ but there are no EAF providing explicit and practical description. The study result articulates that single EAF cant be a panacea to support all the EAQAs. Thus, EA developer needs to carefully select and modify an EAF based on the EAQAs, and then develop EA. Research about more specific criteria is required to give guidance for the selection of EAF and the practical linkage method between EA and system development cycle is required to increase EA Quality. ACKNOWLEDGMENT This research was supported by the MKE(The Ministry of Knowledge Economy), Korea, under the ITRC(Information Technology Research Center) support program supervised by the IITA(Institute for Information Technology Advancement) (IITA-2009-C1090-0902-0003). REFERENCES
[1] [2]

[3]

[4]

[5]

[6]

[7]

[8]

Figure 3. LTGAF

VI.

CONCLUSION
[9]

This paper presented a comparative analysis of EAFs based on EAQAs. It will be helpful to select the suitable EAF which meets the quality requirement or to identify guidance which facilitates EAQAs. In order to compare EAFs, we not only defined EAQAs which are selected from EAFs, but also developed the evaluation criteria for each EAQA. The dimensional concepts are adopted to develop the evaluation criteria. The majorities of EAFs allow only the EAF expert to use concept of EAF related to the EAQAs by providing implicit guidance.

[10]

[11]

[12]

[13]

Armour F, Kaisler S, Liu S. A big-picture look at enterprise architecture. IT Professional 1999;1(1):3542. Department of the Treasury CIO-Council Treasury Enterprise Architecture Framework Version 1, 2000. Available: http://www.eaframeworks.com/TEAF/teaf.doc CIO-Council Federal Enterprise Architecture Framework, Version 1.1, 1999, Available: http://www.cio.gov/Documents/fedarch1.pdf Roger Sessions Comparison of the Top Four Enterprise Architecture Methodologies, Available: http://msdn.microsoft.com/en-us/library/bb466232.aspx Antony Tang, Jun Han, Pin chen, A comparative analysis of architecture frameworks, Proceeding of the 11th Asia-Pacific Software Engineering Conference, 2004. Frank Goethals, An overview of enterprise architecture framework deliverables. January, 2009, Available: www.econ.kuleuven.ac.be/leerstoel/ sap/Frames.Page.htm Lise Urbaczewski, Stevan Mrdalj, A comparison of enterprise architecture frameworks, Issues in Information Systems Volume VII, No2, 2006, Available: http://www.iisonline.org /iis/2006_iis/PDFs/Urbaczewki_Mrdalj.pdf. Jin-Woo Kim, Young-Gab Kim, Ju-Hum Kwon, Sung-Ho Hong, Chee-Yang Song, and Doo-Kwon Baik, An enterprise architecture framework based on a common information technology domain (EAFIT) for improving interoperability among heterogeneous, Proceedings of the 2005 Third ACIS Int'l Conference on Software Engineering Research, Management and Applications (SERA05) information systems, 2005 J. Zachman, A Framework for Information Systems Architecture, IBM Systems Journal, 26(3), IBM Publication G321-5298. 1987 CIO-Council, A Practical Guide to Federal Enterprise Architecture version 1.0, February 2001, Available: http://www.gao.gov/bestpractices/ bpeaguide.pdf Department of Defense, Department of Defense Architecture Framework. Version 1.5 Volume 1, 2, 2003, Available: http://jitc.fhu.disa.mil/jitc_dri/pdfs/dodaf_v1v1.pdf Department of Treasury CIO council Treasury Enterprise Architecture Framework Version 1, 2000, Available: www.eaframeworks.com/TEAF/teaf.doc The Open Group, The Open Group Architectural Framework

287

[14] [15]

[16] [17]

[18]

(ver 8.1 Enterprise Edition), 2003, Available: http://www.opengroup.org/togaf/ Tae-gong Lee, NCW theory and application, Hongrung, 2007, Seoul. Arun Raia, Hindi Al-Hindi, The effects of development process modeling and task uncertainty on development quality performance Information & Management 37, 2000, p. 335~346 Boehm B. A spiral model for software development and enhancement, IEEE Computer 1998; 21:61-72. DeLone, W.H. and McLean, E.R. The DeLone and McLean Model of Information Systems Success: A ten-Year Update, Journal of Management Information Systems, Vol. 19, No. 4, pp. 9-30. 2003 L. Hyatt, L Rosenberg A Software Quality Model and Metrics for identifying Project Risks and assessing Software Quality, Proceedings of the 2nd international conference on Software engineering. 1996, Available: http://satc.gsfc.nasa.gov/support/STCAPR96/quality/stcqual.h tml

288