Evaluation of Current Architecture Frameworks Susanne Leist Gregor Zellner

University of Regensburg Institute of Information Management

Universitätsstraße 31, 93040 Regensburg, Germany +49 941 943 3201

{Susanne.Leist | Gregor.Zellner}@wiwi.uni-regensburg.de

ABSTRACT With the growing importance of enterprise architecture the discussion about how to create or choose the right enterprise architecture framework for a specific organization arose quickly. But it is not only a question of choosing the right framework for describing or developing an enterprise architecture. It is more important to discover whether the chosen architecture framework meets the defined requirements or not. In this paper, we describe which requirements currently existing architecture frameworks should meet to constitute a useful procedure that enables to develop, describe and keep up an enterprise architecture. Our evaluation of current frameworks shows their lacks and identifies further improvement.

Categories and Subject Descriptors D.2.10 [Software Engineering]: Design - Methodologies I.6.5. [Simulation and Modeling]: Model Development - Modeling Methodologies

General Terms Management, Documentation, Design, Theory

Keywords Architecture, Method

1. INTRODUCTION As information systems and technologies grow in complexity and scope, the need for a coherent and comprehensive modeling approach becomes of paramount importance. Many attempts in the area of enterprise architecture have been made and many different approaches were developed.

Some approaches provide only a framework, which supports the development of architecture descriptions. One of the most well-known example in this context is the Zachman Framework [35]. The Zachman Framework defines different perspectives for describing enterprise architecture and stipulates the resulting specification documents for each perspective. More comprehensive approaches aim to develop and maintain architecture descriptions. They provide not only a framework but

also procedure models, in which all developing and maintaining activities are defined. Examples are the Model Driven Architecture (MDA) [1] or the Treasury Enterprise Architecture Framework (TEAF) [7]. Most of these approaches are often referred to as architecture frameworks and have the same target: to enable the development of enterprise architecture descriptions.

Since different architecture frameworks with similar targets exist, it is necessary to investigate these approaches, in order to detect their advantages and disadvantages. An evaluation exposes in addition details for further developments of the architecture frameworks. There are only a few publications, in which well-known architecture frameworks are investigated (cf. [26], [32], [13]). Most of these publications (esp. [26] and [32]) provide a similar structured description of the architecture frameworks and pay less attention to an evaluation. The aim of this paper is therefore to evaluate important enterprise architecture frameworks in order to identify their special attributes that support the development of enterprise architecture descriptions. The evaluation describes the chosen frameworks regarding selected requirements for a methodic procedure. For this purpose a brief definition of basic terms is given in section 2 below. Building on from here, basic requirements for the developing process are introduced in section 3. Section 4 investigates the architecture frameworks regarding the requirements. In section 5 the results of the evaluation are pointed out. The paper concludes with a summary of the most important findings and an outlook of further steps in section 6.

2. ARCHITECTURE AND ARCHITECTURE DESCRIPTIONS In this paper, the term architecture refers to any kind of socio-technical system, and stands for the fundamental organization of its components and their relationships to each other and the environment as well as the design rules for developing and structuring the system [18]. The components are depicted in the form of a building plan while reducing insignificant aspects. The design rules, on the other hand, describe stipulations for the development and structuring of the building plan, which specify the types of components, the types of relationships and consistency conditions for the use of components and/or their relationships [28]. The architecture is thus the result of planning the structure.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

Normally models are used to map architecture descriptions (see Figure 1). They can represent in a simple manner different views of the architecture [11]. For example, functions, data or organization units (which are important components of an information system architecture) and their relationships can be specified e.g. in a function hierarchy diagram, entity relationship SAC’06, April, 23-27, 2006, Dijon, France.

Copyright 2006 ACM 1-59593-108-2/06/0004…$5.00.

1546

diagram or organization chart. According to the definition given above these kinds of models can only represent a part of the architecture. To complete architecture descriptions it is essential to describe design rules for developing and structuring the system. With the aid of meta models it is possible to define the languages of all models which are used to describe the architecture and therefore important design rules can be specified. In addition, the procedure model can establish the process of modeling, i.e. important steps in the development process, and can thus define relevant design rules as well.

Enterprise Architecture

Technical Architecture

Meta Model

Object Relation-ship

Relation

Relation

Time Meta Model

Object Relation-ship

Relation

Relation

Time

Object Relation-ship

Relation

Relation

Time

Design RulesDesign Rules

....

das ersteEnkelkind derWurzel

Wurzel Objekt

das erste Kind derWurzel

das zweite Kindder Wurzel

das zweiteEnkelkind derWurzel

das ersteEnkelkind derWurzel

Wurzel Objekt

das erste Kind derWurzel

das zweite Kindder Wurzel

das zweiteEnkelkind derWurzel

Mutter Entität KindEntität

abhängiges KindEntität

Mutter Entität KindEntität

abhängiges KindEntität

Kunden-kontakt auf-genommen

Kundesuchen

Kunden-liste angezeigt

Kunde aus Liste

identifizieren

Kunden-kontakt auf-genommen

Kundesuchen

Kunden-liste angezeigt

Kunde aus Liste

identifizieren

Kunden-kontakt auf-genommen

Kundesuchen

Kunden-liste angezeigt

Kunde aus Liste

identifizieren

BusinessArchitecture

Product Architecture

Information

Architecture

Real World

....

Architecture Architecture DescriptionEnterprise

Artificial World

Increasing Complexity Increasing Abstraction

Application

Architecture

Figure 1 Architecture

Architectures are usually differentiated in several types according to their main objects they refer to (see Figure 1). Usually the types are integrated into a cohesive structure, the enterprise architecture. However, several enterprise architectures have different structures (cf. [11], [22]). As an example we shortly introduce the enterprise architecture of the EA Community [10]. The business architecture is the result of defining the business strategies, processes and functional requirements. The information architecture describes the data’s logical aspects, as well as the management of the data resources. The application architecture is focused on developing and implementing applications to fulfill business requirements. The technical architecture provides the foundation that supports the application, data and business processes. It identifies and plans the computing services that form the technical infrastructure of the enterprise. These types of architectures are related to each other. The development of architectures enables the structuring of the enterprise by describing relevant models (e.g. process or data models). Design and development activities therefore relate to the entire enterprise but can be focused on relevant extracts. At the same time, the complexity of the activities is reduced (see also [22], [35]). In addition describing the architecture enables enterprises to identify organizational bottlenecks or redundancies and gaps regarding the applications. In view of the fact that in architecture models not only individual components are separated but also the relationships are stipulated, the consistency between the focused components is secured. The impacts of adaptation and design activities on other components become visible and can be taken into account when taking decisions.

3. DEVELOPING ENTERPRISE ARCHITECTURE DESCRIPTIONS Despite many approaches exist which support the development of enterprise architecture descriptions, the developing and maintaining process is still a challenging task. One of the most obvious problems relies on the problem domain itself. Developers are confronted with the broad scope and a lack of structure. Usually the broader the scope of the project is and the more people are involved the more complex and difficult it is to carry it out successfully. Furthermore the less structured the problem under consideration is, the more difficult it is to define and communicate [3]. Since every approach supports to structure and reduce complexity, the selection of the appropriate approach becomes of utmost importance too. In addition the architectural concepts should not only focus on how to structure the enterprise components but also on how to increase organizational value. A basic construct of these approaches is the use of techniques especially modeling techniques. Using techniques to design specific components of an enterprise is nothing new. For decades techniques have been used to design components of information systems in a multitude of projects. Considering the complexity of such projects, the techniques are applied in a specified “order” which is provided by the selected method. Because of its great impact on the success of an information system development project, many researchers and practitioners tried to identify the essential requirements a method should meet. Meanwhile well-founded investigations to the term and the constituent elements of a method exist (see the following sections). Assuming the hypothesis that the investigation results are transferable, we could demand several requirements for the development of enterprise architecture descriptions. In doing this we will first give a short summary of the investigations and afterward we derive requirements for the development.

3.1 Method engineering as a theoretical foundation A fundamental contribution to define the term “method” is provided by method engineering. Method engineering is the discipline to design, construct, and adapt methods, techniques and tools for the development of information systems [5] (see also [16], [34]). Starting point of many publications in this discipline is the multiplicity of existing software development methods. Based on this the efforts of most research work concentrate on the analysis, the comparison or the support of the selection of methods, techniques or technologies (cf. e.g. [19], [5], [15], [17], [20], [24], [23]). As a result the authors established the term and constituent elements of a method (e.g. [29], [16], [14]). Apart from insignificant differences all authors agree that a method is an approach to perform a system’s development project, which consists of directions and rules and is structured in a systematic way in development activities with corresponding development products [5]. A technique is a procedure, possibly with a prescribed notation, to perform a development activity [5]. For that reason a technique is an essential part of the method, which specifies the accomplishment of development activities. Since directions and rules as well as structured developing activities are useful for the development of enterprise architecture descriptions too, a method could be a valuable support for development projects.

1547

3.2 Mandatory elements of a method as requirements In order to define requirements for the development of enterprise architecture descriptions we have to identify elements of a method, which are essential to differentiate between methods and other approaches. A closer look at the definition makes these constitutive elements of a method obvious. A method embodies a set of concepts that determine what is perceived (technique/modeling technique), a set of linguistic conventions and rules which govern how the perception is presented and communicated (meta model) and a set of procedural guidelines which state in what order and how representations are derived/transformed (procedure model) [29] (see also [4], [34]). To specify a method it additionally needs a description of participating roles (for the development and management of the architecture descriptions) and the specification of resulting documents (specification documents) [16], [14]. It should be mentioned that roles and the procedure model are related to each other. If there is no procedure model provided by a method, the definition of roles for the development process would not make any sense. To summarize, a method consists of the five constitutive elements

• Meta model,

• Procedure model

• Technique/modeling technique

• Role and

• Specification document In order to provide a systematic approach for the development of enterprise architecture descriptions a specification to every mentioned element should be demanded.

4. EVALUATION OF CURRENT ARCHITECTURE FRAMEWORKS In the following section we describe known and reputable architecture frameworks regarding the elements of a method to figure out what they have in common and where the differences (Section 5) are. As mentioned before, a few enterprise architecture frameworks exist. In our evaluation we will not pay equal attention to every framework. Therefore a selection has to be made. We focus on a number of well-known, reputable and often used (in praxis or science) frameworks.

4.1 ARIS The ARIS concept defines a frame for developing, optimizing and describing integrated information systems. The aim of the ARIS framework is to describe an information system for supporting business processes. Therefore the core of ARIS is the business process, a sequence of activities in an enterprise to generate output for the process customer. Using different views a reduction of complexity within enterprise modeling is achieved. The different views are connected within the process view [25].

Specification document:

In ARIS, specification documents are proposed, that include consistently the meta model of the specific view. At the same

time the documents can be regarded as possible results of a phase or a view. The most important specification document for presenting the business process model is the event driven process chain (EPC) diagram that integrates all possible views.

Meta model:

Each view of the business process is described by a meta model, but there is no overall meta model published which secure consistency between the different meta models. Due to the functionality of the ARIS toolset an overall meta model must be defined (but not published).

Role:

A role model does not exist in ARIS. The nonexistence of this model must be seen in connection with the absence of a detailed procedure model.

Technique:

ARIS contains a lot of different techniques for modeling. Those techniques are for example: entity relationship (ER) modeling technique, UML class diagram technique, use case specification technique and EPC (event driven process chains) technique. A concrete description for the use of each technique during a specific phase is missing.

Procedure Model:

The ARIS concept does not include a consistent procedure model for the development of architecture descriptions. Only basic advice is given, e.g. that the modeling projects in ARIS should start with creating the process view. For each project users and developers have to build up a procedure model regarding their specific context.

4.2 C4ISR and DoDAF C4ISR stands for Command, Control, Communications, Computers, Intelligence, Surveillance, and Reconnaissance. DoDAF stands for U.S. Department of Defence (DoD) Architecture Framework. The DoDAF (Version 1.0) is an evolution of the C4ISR Architecture Framework Version 2.0. The purpose of DoDAF Version 1.0 “is to provide guidance for describing architectures for both warfighting operations and business operations and processes.” [8]. The intent of this framework is to ensure, that architecture descriptions can be interrelated and that resulting systems can interoperate [26]. As a complete architectural description requires the use of multiple views, the C4ISR/DoDAF defines four views: (1) the operational view, (2) the systems view, (3) the technical standards view, and (4) the all view. Besides the C4ISR/DoDAF contains four main types of guidance for architecture development [8]: (1) guidelines, (2) a high level process for using the framework, (3) a discussion of architecture data and tools, and (4) a detailed description of the products. The products defined by the framework are the work products of architecture development, the descriptive artifacts that communicate the architecture. Within the C4ISR/DoDAF 26 different architecture products are defined, which are organized in the different views [26].

Specification document:

There are three major views (operational view, system view, technical standards view) in the framework. A fourth view

1548

concerns all views. For each view products are defined. Products are graphical, textual and tabular items that are developed in the course of building given architecture descriptions [8], [9]. These products represent the character of specification documents.

Meta model:

For each product description an ER diagram exists that shows the relationships between the data elements of the specific product. This construction plan reflects a certain kind of meta model. But even though there are well defined meta models for each product or specification document, there does not exist a major meta model within the C4ISR/DoDAF, which describes the relationships between the products. From that point of view the meta model only exists in parts.

Role:

Within the C4ISR/DoDAF the product “Organizational Relationship Chart (OV-4)” describes the relationships among human roles, organizations, or organization types that are the key players in an architecture. Human roles whose skills are needed to perform the operational activities or business processes described in the architecture may also be defined in OV-4 [9]. Although a role model for the management of the new generated architecture descriptions exists, a role model for the development process is missing. There are no specific descriptions about who is responsible or needed in each step of the procedure model to develop architecture descriptions. From that point of view the role model only exists in parts.

Technique:

If possible, UML representations (e.g. class diagrams, collaboration diagrams, use case diagrams) are used to depict most of the products (e.g. product “Operational Node Connectivity Description (OV-2)” is represented in an UML use case diagram [9] etc.). The use of these UML representations corresponds to techniques for generating the products for each view within the framework.

Procedure model:

Within the C4ISR/DoDAF a generic six-step architecture development process exists to provide some general guidance to the architect for building architecture descriptions [8]. These six steps define a procedure to develop architecture descriptions. The steps are: (1) determine the intended use of the architecture, (2) determine the scope of architecture, (3) determine characteristics to be captured, (4) determine views and products to be built, (5) gather data and build the requisite products and (6) use the architecture for intended purpose. The DoDAF Deskbook contains further descriptions for each step.

4.3 FEAF The purpose of the FEAF (Federal Enterprise Architecture Framework) is to facilitate shared development of common processes and information among U.S. Federal Agencies and other government agencies. The FEAF provides an enduring standard for developing and documenting architecture descriptions of high-priority areas [6]. The FEAF divides a given architecture into business, data, applications and technology architecture descriptions, which are the four levels the FEAF consists of. In Version 1.0 (February 2001) the FEAF includes the

first three columns of the Zachman Framework, so that the FEAF is graphically represented as a 3x5 matrix with architecture types (data, application, and technology) on one axis of the matrix and perspectives (planner, owner, designer, builder and subcontractor) on the other.

Specification document:

Within the FEAF Matrix for each cell specification documents are suggested: for example a business process model to describe the application architecture from the owners perspective or a logical data model to describe the data architecture from the designers perspective.

Meta model:

In the FEAF no explicit meta model for the specification documents exists.

Role:

The FEAF provides a listing of functional roles and the associated responsibilities assigned to enterprise architecture core team members [6]. It is also planed to establish an enterprise architecture program management office to manage, monitor and control the development and maintenance of the enterprise architecture descriptions [6].

Technique:

The FEAF does not contain a detailed description of how to generate the specification documents that are suggested for each cell of the FEAF Matrix.

Procedure model:

Within the FEAF only an unspecific approach to develop the target architectures is represented. This approach consists of four major activities: (1) data collection phase, (2) preliminary product generation, (3) review and revision phase and (4) publication and delivery phase. The activities of this general approach are further detailed in the FEAF description.

4.4 MDA MDA (Model Driven Architecture) is an approach to system development using models to direct the course of understanding, design, construction, deployment, operation, maintenance and modification [2], [21]. “The MDA defines an approach to IT system specification that separates the specification of system functionality from the specification of the implementation of that functionality on a specific technology platform [1]”.

Specification document:

Each phase of the procedure model has its own specification documents that are often described with UML models. Specification documents could be descriptions of a computer independent model (CIM), platform independent model (PIM) or platform specific model (PSM). Additionally the mapping from one model (e.g. PIM) to another model (e.g. PSM) is supported by templates [21], which share the character of a specification document.

Meta model:

In MDA the used UML models represent the design for an application. The models used are: PIM and PSM. Both models are

1549

described with meta models that are expressed with UML, MOF (Meta-Object Facility) or other languages [1].

Role:

In MDA development projects the participating parties are suggested. In the second phase of the MDA procedure model (developing the PIM) business and modeling experts work together to develop business functionality and behavior [27]. Even though the participants are suggested, a detailed role model does not exist in MDA. A role description can only be assumed partially in this case.

Technique:

Using UML models (classes, use cases, activity graphs etc.) within the procedure model could be declared as using techniques [1]. Another technique in the MDA approach is the mapping (transformation) between the phases of the procedure model: for example the transformation from PIM to PSM [12]. But there is no explicit description of other techniques within the MDA.

Procedure Model:

The development process in MDA consists of four steps: (1) creating a computation independent model (CIM; created by business analysts to describe the business) (2) creating a platform independent model (PIM), (3) creating a platform specific model (PSM) and (4) generating the application [27], [12]. These four steps build the procedure model for MDA development projects.

4.5 TEAF The TEAF (Treasury Enterprise Architecture Framework) is derived from an earlier treasury model, TISAF (Treasury Information System Architecture Framework), the FEAF (Federal Enterprise Architecture Framework, 1999) and the Zachman Framework. The purpose of this architecture is to provide guidance for treasury enterprise architecture development and management and to support treasury bureaus and offices with the implementation of their architectures based on strategic planning [7]. The core of the TEAF is the TEAF Matrix which provides a simplified view of the enterprise architecture from various vantage points (views and perspectives) [7]. The 16 cells of the TEAF Matrix contain Work Products which document a set of related information for the enterprise architecture [7].

Specification document:

Within the TEAF Matrix for each cell (work product) different kinds of specification documents are suggested: for example an organization chart to describe the organizational view from the planners perspective or an activity model to describe the functional view from the owners perspective. For generating the activity model the UML activity diagram for example could be used.

Meta model:

In the TEAF no explicit meta model(s) for the specification documents exist(s). But some cells and specification documents of the TEAF Matrix are described on a generic level (e.g. organization chart [7]). Additionally for all suggested specification documents (cells of the TEAF Matrix) their components (entities, attributes and relationships) are described in detail (e.g. the organization chart [7]). But this description of the

structure of the specification documents can only be partly regarded as meta models. Even though there do not exist any detailed meta models for the specification documents, the integrated enterprise architecture structure in TEAF is governed by an underlying integrated meta model that defines both element types and their interrelationships. This meta model provides an integration of information and relationships across the multiple types of models (or specification documents) that are used in the various work products (cells of the TEAF Matrix) [7].

Role:

Within the TEAF one of the key issues is: “Who will use the enterprise architecture descriptions and how?” To contribute to this issue a governance process identifies participant roles and responsibilities. The TEAF contains a description of roles, associated responsibilities and team composition of architecture management participants [7]. Each bureau defines at an appropriate level roles and responsibilities for developing and managing the enterprise architecture.

Technique:

The TEAF does not contain a detailed description of how to generate the specification documents (work products) that are suggested for each cell of the TEAF Matrix. Even if there is a detailed description of the specification document (entities, attributes and relationships), techniques for creating them are missing.

Procedure model:

Within the TEAF a set of activities and guidelines exist to specify the development process. The four basic enterprise architecture activities are: (1) to define an enterprise architecture strategy, (2) to define an enterprise architecture management process, (3) to define an enterprise architecture approach and finally (4) to develop the enterprise architecture repository [7]. These activities represent a roadmap for the remainder of the TEAF and define a procedure model for developing the enterprise architecture descriptions within the TEAF. Another procedure can be seen in the structure of the TEAF Matrix: going down the rows, the work products get more detailed – starting at a high-level contextual view and driving down to a design view.

4.6 TOGAF TOGAF, The Open Group Architecture Framework (cf. http://www.opengroup.org/architecture/wp/), is an industry standard architecture framework that may be used freely by any organization wishing to develop enterprise architecture descriptions for the use within that organization. It is a detailed framework using a set of supporting tools [33]. It enables designing, evaluating, and building the right architecture for any organization. The key to TOGAF is the TOGAF Architecture Development Method (ADM) - a reliable, proven approach for developing enterprise architecture descriptions that meets the needs of the specific business.

Meta model:

TOGAF mainly consist of three parts: (1) The TOGAF ADM, (2) Enterprise Continuum and (3) Resource Base. None of the three parts delivers a meta model to assure a consistent reuse of components during an iterative use of the procedure.

1550

Procedure Model:

The core of TOGAF forms the ADM. This approach delivers a detailed procedure model for developing enterprise architecture descriptions. The ADM is iterative, over the whole development process, between phases, and within phases (architecture development cycle). The cycle consists of eight phases: (A) architecture vision, (B) business architecture, (C) information system architectures, (D) technology architecture, (E) opportunities and solutions, (F) migration planning, (G) implementation governance, and (H) architecture change management. Each of these eight phases contains further detailed steps. The use of reference models (which are provided by the TOGAF Enterprise Continuum) and guidelines (which are provided by the TOGAF Resource Base) can be regarded as other important activities in the developing process. TOGAF uses a set of activities that build a detailed procedure model for developing enterprise architecture descriptions.

Specification document:

Even though TOGAF ADM describes the different inputs and outputs for each phase of the architecture development cycle, there are no specification documents that describe the output. The output often consists of principles or guidelines. Although the used techniques, for example ER modeling lead to a distinct specification document (the ER model), there are no instructions within the TOGAF procedure that clearly describe in which phase of the development cycle which specification documents have to be generated. From that point of view specification documents only exit in part within the TOGAF framework.

Technique:

In some of the phases of TOGAF ADM techniques are used. For example in phase C “information system architecture” (step 3 architecture model(s)) ER models are used to illustrate views of the data architecture. Entity-business function matrices are used to tabulate all relationships (phase C “information system architecture” (step 3 architecture model(s) in TOGAF ADM). Another technique used in TOGAF ADM is for example business scenarios. As those techniques are not used continuously within the framework, the appearance of techniques can only be seen in parts.

Role:

A role description within the ADM cycle or even within TOGAF is missing. There are no hints about who or what organizational unit should be in charge or involved in the different steps of the ADM procedure model.

4.7 Zachman The Zachman Framework (http://www.zifa.com or [35]) is a framework providing a view of the subjects and models needed for developing or/and documenting a complete enterprise architecture. The purpose of the framework is to provide a basic structure which supports the organization, access, integration, development, management and changing of a set of architectural representations of the organization’s information system. The framework is described in a matrix (30 cells) which provides on the vertical axis five perspectives of the overall architecture and on the horizontal axis six classifications of the various artifacts of the architecture as well as flow diagrams.

Specification document:

The description of the Zachman Framework contains suggested specification documents for each cell of the matrix (e.g. using ER technique for modeling the data description in the owners view (business model) or using functional flow diagrams for modeling the process description in the owners view) [35]. This refers to the fact, that an organization has a whole range of diagrams and documents representing different aspects or viewpoints which can be developed within the Zachman Framework.

Meta model:

In the extended version of the framework for information systems architecture a detailed cell meta model is described [30]. As this meta model only describes the cells for three perspectives (owner´s view, designer´s view, builder´s view) and three classifications (data, process, network), a meta model only exists in parts within the Zachman Framework.

Role:

There is no role model within the framework.

Technique:

The Zachman Framework is independent of specific methodologies [12]. Also there are no specific techniques described to create the suggested specification documents in each cell of the framework. Any appropriate technique may be placed in the framework (e.g. for developing an entity relationship diagram).

Procedure model:

Within the Zachman Framework only some major principles and rules exist that guide the application of the Zachman Framework, but there is no guidance on sequence, process or implementation of the framework [31]. The Zachman Framework says nothing about the processes for developing viewpoints or conformant views, or the order in which they should be developed. Some kind of procedure can be identified implying that the top rows in the framework matrix are used early on while the bottom rows become more important during latter phases in developing enterprise architecture descriptions.

5. Results of the evaluation A summary of the results is given in Table 1. Each framework has strengths and weaknesses and no framework meets all requirements regarding the constitutive elements of a method. In addition all frameworks have different weaknesses. FEAF and TOGAF e.g. do not have a specification of a meta model while the ARIS method and MDA describe such a model. In contrast whereas the ARIS method does not include a consistent procedure model, the developing process of the MDA is accurately described in four steps. Table 1 reflects therefore the different capabilities of each framework to support the development and management of enterprise architecture descriptions.

1551

Table 1 Evaluation of current Architectures

AR

IS

C4I

SR/D

oDA

F

FEA

F

MD

A

TEA

F

TOG

AF

Zach

man

Specification document

Meta model Role Technique Procedure model

Legend: Fully accomplished Partly accomplished Not accomplished

For most of the architecture frameworks the strengths and weaknesses are very balanced. The adequacy of a architecture framework to support a development project could be evaluated only in consideration of specific circumstances of a case.

The results of the evaluation indicate at the same time potentials for further development of the frameworks. For example in FEAF and TOGAF a meta model is not defined. The meta models determine all objects and all their relationships, which are modeled to describe the enterprise architecture, in order to establish the consistency of the models. Since the only constant in today’s business world is change architecture models will often be adapted. Therefore the specification of meta models is of utmost importance to assure the consistency of architecture descriptions and would be a great benefit for the architecture frameworks.

The development of a role model would be a valuable advancement for some architecture frameworks too. The role model constitutes responsibilities for certain tasks, which support not only the development but also the maintenance of the architecture descriptions. Including common techniques is helpful for the reuse of universal knowledge. The procedure model is often requested in practice because it itemizes what to do and the specification documents therefore define targets. To sum up, the completion would be in general a great benefit for each architecture framework.

6. CONCLUSIONS The objective of this paper was to evaluate well-known architecture frameworks regarding their contribution to support architecture development projects. Since well-founded investigations to the term and the constituent elements of a method exist we could derive several requirements for the development of enterprise architecture and their descriptions.

A main result of the evaluation is that no framework meets all requirements regarding the constitutive elements of a method. Based on these findings further potentials for developing architecture frameworks are pointed out: for example using a procedure model makes it easier to develop architecture descriptions, because of the ability to follow a structured procedure. Techniques are useful for producing the required specification documents within the procedure model.

Another interesting result is that strengths and weaknesses are very balanced for each architecture framework. The evaluation shows for each framework which requirements regarding a methodic procedure it meets. Furthermore the selection of an appropriate framework must consider the situation and the objectives for which the framework is used. For that reason further research on improving architecture frameworks needs to focus on situations and objectives for which the frameworks are appropriate.

7. REFERENCES [1] Architecture Board ORMSC, Model Driven Architecture

(MDA), Miller, J., Mukerji, J. (Eds.), 2001, http://www.omg.org/cgi-bin/apps/doc?ormsc/01-07-01.pdf, (Access: 17. July 2005).

[2] Blevins, T.J., Spencer, J., Waskiewicz, F., TOGAF ADM and MDA, 2004, http://www.opengroup.org/cio/MDA-ADM/MDA-TOGAF-R1-070904.pdf, (Access: 17. July 2005).

[3] Brancheau, J.C., Building and implementing an information architecture, DATA BASE, Summer (1989), 9-17.

[4] Brinkkemper, S., Method Engineering with Web-enabled Methods, in: Brinkkemper, S., Lindencrona, E., Solvberg, A. (Eds.), Information Systems Engineering: State of the Art and Research Themes (Springer, London, 2000), 123-133.

[5] Brinkkemper, S., Method Engineering: Engineering of Information Systems Development Methods and Tools, Journal of Information and Software Technology, Vol. 38, Nr. 4 (1996), 275-280.

[6] CIO (Chief Information Officer) Council, A Practical Guide to Federal Enterprise Architecture, Version 1.0, (February 2001).

[7] Department of the Treasury (CIO (Chief Information Officer) Council), Treasury Enterprise Architecture Framework, Version 1, July 2000, 2000, http://www.eaframeworks.com/TEAF/teaf.doc, (Access: 15. July 2005).

[8] DoD Architecture Framework Working Goup, DoD Architecture Framework Version 1.0 - Volume I: Definitions and Guidlines, 2004, http://www.tricare.osd.mil/jmis/download/DoDArchitectureFrameworkVersion1Feb2004.pdf, (Access: 26. August 2005).

[9] DoD Architecture Framework Working Goup, DoD Architecture Framework Version 1.0 - Volume II: Product Descriptions, 2004, http://www.defenselink.mil/nii/doc/DoDAF_v1_Volume_II.pdf, (Access: 26. August 2005).

[10] Enterprise Architecture Community, What is Enterprise Architecture?, 2001, http://network.sharedinsights.com/ea, (Access: 15. July 2005).

[11] Ferstl, O.K., Sinz, E.J., SOM Modeling of Business Systems, in: Bernus, P., Mertins, K., Schmidt, G. (Eds.), Handbook of Architecture of Information Systems (Springer, Berlin et al., 1998), 339-358.

[12] Frankel, D.S., Harmon, P., Mukerji, J., Odell, J., Owen, M., Rivitt, P., Rosen, M., Soley, R.M., The Zachman Framework and the OMG´s Model Driven Architecture, Business Process Trends (2003).

1552

[13] Goethals, F., An Overview of Enterprise Architecture Framework Deliverables, 2003, http://www.econ.kuleuven.be/leerstoel/sap/downloads/Goethals%20Overview%20existing%20frameworks.pdf, (Access: 20. September 2005).

[14] Gutzwiller, T.A., Das CC RIM-Referenzmodell für den Entwurf von betrieblichen, transaktionsorientierten Informationssystemen (Physica-Verlag, Heidelberg, 1994).

[15] Harmsen, F., Saeki, M., Comparison of four method engineering languages, in: Brinkkemper, S., Lyytinen, K., Welke, R.J. (Eds.), Method Engineering, Principles of Method Construction and Tool Support, Proceedings of the IFIP TC8, WG8.1/8.2 Working Conference on Method Engineering (Chapman & Hall, Atlanta, USA, 1996), 209-231.

[16] Heym, M., Methoden-Engineering (Rosch-Buchbinderei, Hallstadt, 1993).

[17] Hong, S., van den Goor, G., Brinkkemper, S., A Formal Approach to the Comparison of Object-Oriented Analysis and Design Methodologies, in: Proceedings of the 26th Hawaii International Conference on Systems Science, Vol. Vol. IV (1993), 689-698.

[18] IEEE, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, 2000, http://www.idi.ntnu.no/~letizia/swarchi/IEEE1471.pdf, (Access: 25. June 2003).

[19] Kueng, P., Bichler, P., Kawalek, P., Schrefl, M., How to compose an object-oriented business process model?, in: Brinkkemper, S., Lyytinen, K., Welke, R.J. (Eds.), Method Engineering, Principles of Method Construction and Tool Support, Proceedings of the IFIP TC8, WG8.1/8.2 Working Conference on Method Engineering (Chapman & Hall, Atlanta, USA, 1996), 94-110.

[20] Marttiin, P., Harmsen, F., Rossi, M., A Functional Framework for Evaluating Method Engineering Environments: the Case of Maestro II / Decamerone and MetaEdit+, in: Brinkkemper, S., Lyytinen, K., Welke, R.J. (Eds.), Method Engineering, Principles of Method Construction and Tool Support, Proceedings of the IFIP TC8, WG8.1/8.2 Working Conference on Method Engineering (Chapman & Hall, Atlanta, USA, 1996), 63-85.

[21] OMG, MDA Guide Version 1.0.1, Miller, J., Mukerji, J. (Eds.), 2003, http://www.omg.org/docs/omg/03-06-01.pdf, (Access: 15. July 2005).

[22] Pereira, C.M., Sousa, P., A Methode to Define an Enterprise Architecture using the Zachman Framework, in: Proceedings of the 2004 ACM symposium on Applied computing, SESSION: Organizational engineering (OE) (ACM Press, New York, NY, Nicosia, Cyprus, 2004), 1366-1371.

[23] Powell, A., Vickers, A., Williams, E., Cooke, B., A practical strategy for evaluation of software tools, in: Brinkkemper, S., Lyytinen, K., Welke, R.J. (Eds.), Method Engineering, Principles of Method Construction and Tool Support, Proceedings of the IFIP TC8, WG8.1/8.2 Working

Conference on Method Engineering (Chapman & Hall, Atlanta, USA, 1996), 165-185.

[24] Rolland, C., Prakash, N., A proposal for context-specific method engineering, in: Brinkkemper, S., Lyytinen, K., Welke, R.J. (Eds.), Method Engineering, Principles of Method Construction and Tool Support, Proceedings of the IFIP TC8, WG8.1/8.2 Working Conference on Method Engineering (Chapman & Hall, Atlanta, USA, 1996), 191-208.

[25] Scheer, A.-W., ARIS - Business Process Frameworks, 3rd completely revised and enlarged edition (Springer, Berlin et al., 1999).

[26] Schekkerman, J., How to survive in the jungle of Enterprise Architecture Frameworks - Creating or choosing an Enterprise Architecture Framework, Second Edition (Trafford, Canada, 2004).

[27] Siegel, J., Developing in OMG´s Model-Driven Architecture, Object Management Groupt White Paper, OMG Staff Strategy Group, Revision 2.6, (November 2001).

[28] Sinz, E.J., Architektur von Informationssystemen, in: Rechenberg, P., Pomberger, G. (Eds.), Informatik-Handbuch (Hanser-Verlag, München, 1997), 875-887.

[29] Smolander, K., Lyytinen, K., Tahvanainen, V.-P., Marttiin, P., Meta-Edit - A Flexible Graphical Environment for Methodology Modelling, in: Andersen, R., Bubenko jr., J.A. (Eds.), Advanced Information System Engineering, 3rd International Conference, CAiSE '91, Vol. Lecture Notes in Computer Science, Vol. 498 (Springer, Trondheim, Norway, 1991), 168-193.

[30] Sowa, J.F., Zachman, J.A., Extending and formalizing the framework for information systems architecture, IBM Systems Journal, Vol. 31, No. 3 (1992), 590-616.

[31] System and Software Consortium, Zachman, 2004, http://www.software.org/pub/architecture/zachman.asp, (Access: 15. July 2005).

[32] The Open Group, Other Architectures and Architectural Frameworks, 2002, http://www.opengroup.org/architecture/togaf8-doc/arch/p4/others/others.htm, (Access: 29. June 2005).

[33] The Open Group, Welcome to TOGAF - The Open Group Architectural Framework, 2002, http://www.opengroup.org/architecture/togaf8-doc/arch/p1/preface.htm, (Access: 5. July 2005).

[34] Tolvanen, J.-P., Method engineering: current research directions and implications for future research, in: Brinkkemper, S., Lyytinen, K., Welke, R.J. (Eds.), Method Engineering - Principles of Method Construction and Tool Support, Proceedings of the IFIP TC8 WG8.1/8.2 Working Conference on Method Engineering (Chapmann Hall, Atlanta, USA, 1996), 296-317.

[35] Zachman, J.A., A framework for information systems architecture, IBM Systems Journal, Vol. 26, No. 3 (1987), 276-295.

1553