EAF 2 A Framework for Categorizing Enterprise Architecture Frameworks

Transcription

1 EAF 2 A Framework for Categorizing Enterprise Frameworks Ulrik Franke, David Höök, Johan König, Robert Lagerström, Per Närman, Johan Ullberg, Pia Gustafsson, and Mathias Ekstedt Industrial Information and Control Systems Royal Institute of Technology Stockholm, Sweden {ulrikf, davidh, johank, robertl, pern, johanu, piag, mek101}@ics.kth.se Abstract What constitutes an enterprise architecture framework is a contested subject. The contents of present enterprise architecture frameworks thus differ substantially. This paper aims to alleviate the confusion regarding which framework contains what by proposing a meta framework for enterprise architecture frameworks. By using this meta framework, decision makers are able to express their requirements on what their enterprise architecture framework must contain and also to evaluate whether the existing frameworks meets these requirements. An example classification of common EA frameworks illustrates the approach. Keywords: Enterprise, Enterprise Framework, Classification of frameworks. I. INTRODUCTION During the last decade, Enterprise (EA) has grown into an established approach for management of information systems in organizations. EA is model-based, in the sense that diagrammatic descriptions of the systems and their environment constitute the core of the approach. EA models increase the general understanding of an organization s business and information system landscape and aids in decision making. Within the practice of EA, a framework can be considered a conceptual structure of what an EA should contain and how to create it, i.e. a set of models, principles, approaches, standards and visualizations that guide the development of enterprise architectures [1]. Following the 1987 introduction of the Zachman framework for information systems architecture [1], several EA frameworks have been introduced, including The Open Group Framework (TOGAF) [2], the Department of Defense architecture framework (DoDAF) [3], the Federal Enterprise (FEA) [4], and the CIM Open System (CIMOSA) [5]. These are all EA frameworks, but they differ in content and target audience. While TOGAF details the process of creating an EA but is less detailed on actual modeling, DoDAF emphasizes models and metamodels. There is, however, no consensus on the proper contents of EA frameworks. We propose a method to characterize the different EA frameworks and match them with the goals and needs of different users. This paper proposes a meta framework, called the EA Framework Framework (EAF 2 ) for this classifying task. At least three distinct audiences can be discerned for use of the EAF 2. Firstly, CIO:s and other IT decision makers can benefit from a meta framework that enables them to select an appropriate EA framework for their specific purposes. Thus, someone looking for an architecture maintenance process might choose TOGAF, whereas someone looking for a metamodel might instead choose Archimate. Secondly, EA framework developers and standardization committees can look into the EAF 2 for directions on how to further develop frameworks to support distinct practitioner needs. Thirdly, in an academic context, the present contribution is an incremental step towards a unified idea of what constitutes an EA framework. The rest of this paper is structured as follows. Section 2 describes some related work on framework classification. Section 3 outlines the construction of the EAF 2, while section 4 details the framework itself. Section 5 illustrates the use of the framework, and section 6 concludes the paper. II. RELATED WORK The most famous related work for identifying general components of enterprise architecture frameworks is the Generalized Enterprise Reference and Methodology (GERAM) [6]. GERAM was created by the IFIP/IFAC Task Force from existing frameworks. By identifying overlaps in the frameworks CIMOSA, GRAI/GIM and PERA [7], the IFIP/IFAC Task Force created a general reference architecture, intended to organize existing enterprise integration knowledge. Since the birth of GERAM, however, a vast variety of frameworks has evolved. Work on mapping frameworks onto GERAM for identifying conformity with the general components is presented in [8] and [9]. These sources both indicate that GERAM is a useful baseline for EA and enterprise engineering, but they contend that GERAM does not provide an eternal unified generalization able to stand the test of time. To be able to represent and classify present state-of-the-practice frameworks GERAM would therefore require substantial reengineering. The IEEE 1471 [10] standard, now also adopted by the International Standardization Organization (ISO) and turned into the ISO/IEC standard [11] supports the enterprise architect with content requirements on architectural

2 descriptions. This standard composes a unification of bestpractice solutions from a variety of architectural concepts. In contrast to GERAM, the core of IEEE 1471 is its focus on architectural support and guidance to supplement EA frameworks, especially in the domain of architectural descriptions. IEEE 1471 does not, however, go into any details concerning for instance EA processes. Based on this, the IEEE 1471 standard does not qualify as a meta framework. From the generalization of frameworks we move on to comparative quality analysis by specified architectural purposes and goals. In research presented by Tang, Han and Chen [12] six frameworks are evaluated and compared according to their goals, inputs and outputs. The analysis provides an identification of differences between the frameworks based on the architectural process. However, by only focusing on the evaluation criteria and not on the framework as such, a meta view never materializes. Another work with similar scope is presented by Leist and Zellner [13]. At first they define main components important for an architectural method and from there evaluate a number of frameworks. Leist and Zellner focus strictly on methods for creating architectures. Many EA frameworks do discuss methods and processes for creating architectures, but this is rarely their main focus. Consequently, the framework of Leist and Zellner is inadequate for EA framework classification. Urbaczewski et al. [14] review and compare some of the same frameworks as does the EAF 2. Specifically, four frameworks are mapped to the Zachman framework s views and abstractions. Although this gives an indication of how the different frameworks relate to the Zachman framework, it does not exhaustively describe their contents in a manner that facilitates a choice between the frameworks. Abdullah et al. [15] have devised a framework for categorizing EA frameworks according to goals, inputs, outputs and miscellaneous other criteria. This framework is not merely descriptive; they devise a normative structure based on concepts external to the EA frameworks. Since the structure is not empirically validated it may or may not represent the actual requirements of the EA framework users. Williams et al. [16] compare the relations of some frameworks to product life-cycles. The study is limited to enterprise architecture frameworks and life-cycle related issues only. Furthermore, the frameworks compared in the study (PERA, CIMOSA, GRAI-GIM and others) are strictly research-oriented and not currently in industry use. Having concluded that the previously performed EA framework comparisons are all found wanting with respect to one or many requirements, we now proceed to detail how the EAF 2 was developed. III. THE PROCESS OF CREATING EAF 2 The EAF 2 was designed to reflect current practice within the EA discipline, as reflected by some of the most popularly used frameworks. Another goal of the EAF 2 is to span the space of different EA frameworks in use today. To achieve this, frameworks 1 2 MODAF DoDAF TOGAF FEA E2AF Fig The development process. 1. Selection of frameworks 2. Feature extraction 3. Feature consolidation EAF 2 have been chosen that are in some sense orthogonal to each other, or at least cover different spaces. Thus, Zachman was chosen due to its famous taxonomy-based EA approach, TOGAF due to its architecture development process and FEA due to its prescriptive methodology for developing enterprise architectures. This spatial diversity is alluded to in Fig. 1, where the overall process of creating EAF 2 is outlined. A more detailed description follows: 1. Selection of frameworks. The first step was to choose EA frameworks as a basis for EAF 2. By choosing a number of frameworks frequently cited in academia or commonly used in industry a desirable width of application of the resulting meta framework was achieved. The frameworks included were TOGAF, DoDAF, IAF, MODAF, E2AF, FEA, the Zachman framework, and ArchiMate. According to [17], TO- GAF, FEA, and Zachman, along with the Gartner methodology, are the most popularly adopted EA methodologies. Gartner was excluded from the EAF 2 creation, as it was not fully accessible due to commercial restrictions. DoDAF, MODAF, E2AF and Archimate are intended to compensate for this. 2. Feature extraction. By analyzing the selected frameworks, their most important distinguishing features were identified and compared with each other. This resulted in a draft meta framework for enterprise architecture frameworks. The feature extraction method employed here featured four process steps, each with a set of accompanying rules, which are described below. The process steps were performed iteratively, addressing the frameworks one by one. Step 1: Selection of a starting framework from the set of frameworks. Step 2: Identification of entities to extract. The framework descriptions were scanned for figures,

3 tables, etc. to identify the key entities. In particular, entities that were either (i) given formal definitions, (ii) discussed in contrast with other frameworks, or (iii) recurred very frequently in the text, were chosen. Step 3: Grouping of the extracted entities. The extraction of each entity was accompanied by a classification; either into a class of similar entities, or as a unique one-of-a-kind entity. In the first iteration, every entity was a class of its own. After several iterations, when a larger number of frameworks had been subjected to analysis, fewer and fewer new classes emerged until no new classes emerged. Step 4: The process returned to step 1 with a new framework for feature extraction selected, until the set was exhausted. 3. Feature consolidation. The features extracted in the preceding step were refined and semantically identical concepts were merged, thus consolidating the EAF 2. The result of the preceding method step was a number of classes, many of which were very closely related, albeit not identical. To reduce the number of classes in EAF 2, an iterative process of consolidation was carried out: Step 1: Selection of a class. Step 2: Classes that resembled the initial class were compared to identify a superclass which would encompass all of the above classes. TOGAF s Development Method, DoDAF s Development Method, and the MODAF Architecting Process were, for instance, all consolidated into the EAF 2 superclass Development Process as illustrated in Fig. 2. Step 3: The process returned to step 1, until the set was exhausted and all classes thus consolidated. IV. THE EAF 2 The introduction of superclasses implies that the devised meta framework gets a hierarchical design where each level represents a set of these classes. EAF 2 is divided EAF 2 architecture development process TOGAF architecture development method (ADM) MODAF architecting process into two main classes; Governance and (Enterprise) Modeling Concepts as illustrated in Fig. 3. Governance [2], [3], [18], [19] describes the management aspects of EA, while Modeling Concepts contain definitions and formalisms for actual models. The latter class has also benefited from the GERAM description of Generic Enterprise Modeling Concepts [6]. Proceeding into greater detail, the Governance class is visualized in Fig 4. The most important parts of architecture governance are the two processes Development Process [2], [3], [18], [19] and Maintenance Process. The former one decomposes into Process Step [2], [3], [18], [19], [4], Techniques [19] and Continuous Improvement Process [2], [19], [4]. Process step is a straight-forward entity required to describe the step-wise development approach promoted by most frameworks. Techniques are used to design and implement an architecture by addressing information gathering, decision making and problem solving [19]. Continuous Improvement Processes stress that architecture process should continuously change to respond to the requirements of the enterprise. The final form of the EAF 2 Development Process has also benefited from the GERAM description of Generic Enterprise Modeling Concepts [6]. Maintenance Process [4] is the process for maintaining and evolving EA models to keep them up-to-date with recent developments with the organization s business and/or IT landscape. Supporting these two main processes, architecture governance also contains a set of tools. Guidelines and Principles [2] [3] [19] [4] are instrumental in keeping the construction of an organization s architecture aligned with stakeholder s requirements and can be seen as a support when making architectural decisions. Building blocks and Patterns [2], [19], [4] are the two main components. Our notion of Building blocks stems primarily from TOGAF and FEA. The building blocks provide units of functionality for fulfilling needs in an organization. Solution Alternatives group several building blocks into practical solutions that address organizational requirements. Patterns [2], [19] are more abstract descrip- EAF 2 DoDAF architecture development process Governance Modeling Concepts Fig. 2. Consolidation into a superclass. Fig. 3. The topmost level of EAF 2.

4 Supporting parts governance Main parts Maintenance Process Development Process Compliance Guideline & Review Process Guidelines/Principles Patterns Building Blocks Roles/Skills Maturity Model Fig. 4. The EAF 2 Governance class. tions of how to use building blocks, i.e. how they are put together into architectural solutions. The relationship between Building blocks, Patterns, and a few related concepts in the EAF 2 are illustrated in Table I. Roles/Skills [2], [19] provide a set of roles, skills and experience norms needed for sufficient governance. Compliance Guideline & Review Process [2], [19] is intended to assure compliance of architecture projects with overall architectural principles and provides a process for review of this. Maturity Model [2], [4] encompasses techniques for quantifying organizational EA maturity. A maturity model improves understanding of the state of the organization s EA. Regular maturity assessments allow the identification of strengths and weaknesses within EA programs and adjust them accordingly. Model Taxonomy Fig. 5. Modeling Concepts Reference Model Entity Type Attribute Type Metamodel Relationship Type Viewpoint The EAF 2 Modeling Concepts class. The second main class in the meta framework is depicted in Fig. 5. The first important subset here is Model Taxonomy [2], [21], [1] which provides a way of structuring models used for enterprise modeling. The taxonomy defines which models an enterprise architecture can consist of and provides an overview of the models. The most widespread model taxonomy is the Zachman framework [1], which categorizes models in two dimensions, Abstraction levels [2], [19], [21], [1], [22] and Aspect areas [2], [19], [21], [4], [1], [22]. Another widespread taxonomy is the classification of architectural layers, viz. business, information, application and infrastructure. The second of the modeling concepts is Reference models [2], [19], [18], [4], [6]. These are models capturing knowledge from previous modeling tasks, in a way similar to that of patterns. The main difference is that patterns are always normative, whereas reference models are sometimes purely descriptive, i.e. without endorsement showing how building blocks have been previously put together. The final modeling concept is that of Metamodels [3], [18], [22], providing semantic rigor to EA frameworks. A metamodel formally defines the allowed contents of architectural models, often graphically. In EAF 2 the metamodel concept is made up from Entity Type [18], [22] and Relationship Type [18]. Entity Types represent architectural classes, e.g. information systems, processes, enterprises, and they are used to guide and delimit the contents and semantics of the EA models. Attribute Types [18], [22] are types of entity properties. Relationship Types [18], [22] define the legal entity connections. Viewpoints [2], [3], [19], [18], [21], [4], [1], [22] show excerpts of the metamodels according to the information needs of different stakeholders. The military architecture frameworks offer good examples of viewpoints, viz. the All Views, Operational View, System View, and Technical Standards View of DoDAF [3]

5 Archimate Zachman FEA E2AF MODAF DODAF TOGAF Abstract Concrete i.e. high level and general i.e. low level and specific Descriptive Reference model Descriptions of Legacy systems i.e. necessary to model the present, e.g. FEA [4] These are usually not assembled as-is, state of an enterprise into frameworks Normative Reference model Solutions alternative/building block i.e. available for modeling the desired, e.g. NGOSS [20] e.g. the solutions available in the to-be, state of an enterprise Federal Transition Framework [4] Pattern e.g. a particular SOA solution TABLE I RELATIONS BETWEEN SOME IMPORTANT CONCEPTS. and the Strategic, Operational, System Acquisition, All Views, and Technical Standards viewpoints of MODAF [18]. Under these descriptions, the difference between Model taxonomies and Viewpoints is still somewhat vague. One way to clarify the difference is to consider the intended use of the different concepts. A taxonomy is primarily about classification. A good classification is exhaustive, i.e. it covers all cases, and disjoint, i.e. no case is classified into more than one category. A viewpoint, on the other hand, is a convenient presentation of information tailored for a specific stakeholder. While it is natural to expect that the set of viewpoints is exhaustive, there is no reason why the viewpoints should all be disjoint. Indeed, more often than not there exists some core information, relevant to many, or all, stakeholders. So, while taxonomies and viewpoints are similar, there are important differences as well. V. A SAMPLE CLASSIFICATION OF EA FRAMEWORKS This section presents the classification of seven well known architecture frameworks using EAF 2 and the concepts presented in section 4. The seven frameworks are TOGAF [2], DoDAF [3], MODAF [18], E2AF [21], FEA [4], Zachman [1], and Archimate [22]. These frameworks have been chosen based on wide-spread adoption and frequency of citations, together providing an example of how frameworks are classified using EAF 2. The classification was done by matching the concepts in EAF 2 with related concepts from each framework. A three level scale was used, where a concept can be (i) presented and detailed, as done for instance in MODAF regarding the metamodel and all its sub concepts. The metamodel is a core concept of MODAF and is thus thoroughly detailed. A concept can also be (ii) mentioned and discussed, cf. TOGAF where patterns are introduced and the content of a pattern is defined. However the actual patterns have not (as yet) been integrated into TOGAF [2]. Finally a concept can be (iii) not mentioned at all in the framework to be classified, corresponding to a blank cell in Fig. 6. VI. CONCLUSIONS This paper has demonstrated how the EAF 2 provides an easy and convenient way of contrasting different architectural frameworks with each another. By using the EAF 2, the choice of framework for any particular EA project or initiative is Metamodel / Framework 1. Governance 1.1 Development Process 1.2 Maintenance Process 1.3 Guidelines/ Principles Building blocks Patterns 1.4 Roles/Skills 1.5 Maturity Model 1.6 Compliance Guideline & Review Process 2. Modeling Concepts 2.1 Model Taxonomy 2.2 Reference Model 2.3 Metamodel Entity Type Attribute Type Relationship Type Viewpoint The EAF 2 concept considered is presented and detailed. The EAF 2 concept considered is mentioned and discussed. The EAF 2 concept considered is not mentioned. Fig. 6. A classification of frameworks. simplified and made more transparent. This is particularly important as different frameworks often relate to each other in a complementary fashion, a fact seldom mentioned by the proponents of the various frameworks. It is clear that the concept architecture framework, although abundantly used, is not very coherently defined. The table in the previous section demonstrates the usefulness of the EAF 2 classification for revealing the context dependency of the term. Some frameworks contain only a taxonomy, others focus on a metamodel, while some try to cover everything at the cost of less depth. While the EAF 2 does not resolve this ambiguity, it does provide a structured way to reason about it, and make rational decisions on matters of using enterprise architecture frameworks. As for future work, an expansion of the present contribution to classify more frameworks by the EAF 2 standard would make the resulting catalog considerably more useful. Such an

6 expansion could also be used as a basis for a taxonomy of the terminology currently in use in different EA frameworks. REFERENCES [1] J. A. Zachman, A framework for information systems architecture, IBM Syst. J., vol. 26, no. 3, pp , [2] The Open Group, TOGAF 2007 edition. Zaltbommel, Netherlands: Van Haren Publishing, [3] Department of Defense Framework Working Group, DoD Framework, version 1.5, Department of Defense, USA, Tech. Rep., [4] Office of Management and Budget, FEA Consolidated Reference Model Document Version 2.1, Office of Management and Budget, USA, Tech. Rep., [5] K. Kosanke, F. Vernadat, and M. Zelm, CIMOSA: enterprise engineering and integration, Computers in Industry, vol. 40, no. 2-3, pp , [Online]. Available: 2/2/07d29df c9f8ea5b0ad [6] IFIP-IFAC Task Force, GERAM: Generalized Enterprise Reference and Methodology, IFIP-IFAC Task Force on s for Enterprise Integration, Tech. Rep., [7] H. Li and T. J. Williams, The interconnected chain of enterprises as presented by the Purdue Enterprise Reference, Comput. Ind., vol. 42, no. 2-3, pp , [8] P. Bernus, L. Nemes, and G. S. (eds.), Handbook on Enterprise. Heidelberg: Springer, [9] P. Saha, Analyzing The Open Group Framework from the GERAM Perspective, The Open Group, Tech. Rep., [10] IEEE Working Group, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE Std , IEEE, Tech. Rep., [11] International Standardization Organization/International Electrotechnical Committee, ISO/IEC 42010: Systems and software engineering Recommended practice for architectural description of softwareintensive systems, ISO, Tech. Rep., [12] A. Tang, J. Han, and P. Chen, A comparative analysis of architecture frameworks, Software Engineering Conference, th Asia-Pacific, pp , Nov.-3 Dec [13] S. Leist and G. Zellner, Evaluation of current architecture frameworks, in SAC 06: Proceedings of the 2006 ACM symposium on Applied computing. New York, NY, USA: ACM, 2006, pp [14] L. Urbaczewsk and S. Mrdalj, A comparative analysis of architecture frameworks, Issues in Information Systems, vol. VII, no. 2, [15] S. Abdallah and G. H. Galal-Edeen, Towards a framework for enterprise architecture frameworks comparison and selection, in The Fourth International Conference on Informatics and Systems (INFOS2006), Mar [16] T. J. Williams, H. Li, P. Bernus, G. Uppington, and L. Nemes, The life cycle of an enterprise, in Handbook of Life Cycle Engineering, A. Molina, J. M. Snchez, and A. Kusiak, Eds. Heidelberg: Springer, 1999, ch. 6, pp [17] R. Sessions, Comparison of the top four enterprise architecture methodologies, Available on 4EAComparison.pdf, accessed January 5, 2009, Objectwatch, Inc., Tech. Rep. [18] Ministry of Defence, MOD Framework version , Available on accessed November 14, 2008, Ministry of Defence, UK, Tech. Rep. [19] Capgemini, and the integrated architecture framework, Available on ent_architecture/iaf, accessed November 14, 2008, Capgemini, Tech. Rep. [20] Telemanagement Forum, New Generation Operations Systems and Software (NGOSS), Available on /NGOSS/1911/Home.html, accessed November 14, [21] J. Schekkerman, Extended enterprise architecture framework essentials guide, v1.5. Available on E2AF/Extended%20Enterprise%20%20Framework %20Essentials%20Guide%20v1.5.pdf, accessed November 14, 2008, Institute for Enterprise Developments, Tech. Rep. [22] M. Lankhorst, Enterprise At Work. Heidelberg: Springer, 2005.