Essential layers artifact_and_dependencies_of_ea


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Essential layers artifact_and_dependencies_of_ea

  1. 1. Essential Layers, Artifacts, and Dependencies of Enterprise Architecture Robert Winter Ronny Fischer Institute of Information Management, University of St. Gallen {robert.winter | ronny.fischer} Abstract While an EA model is a representation of as-is or to-be architecture of an actual corporation or govern- After a period where implementation speed was ment agency, an EA framework provides [12] more important than integration, consistency and re- • one or more meta-model(s) for EA description, duction of complexity, architectural considerations • one or more method(s) for EA design and evolution, have become a key issue of information management • a common vocabulary for EA, and maybe even in recent years again. Enterprise architecture is widely • reference models that can be used as templates or accepted as an essential mechanism for ensuring agil- blueprints for EA design and evolution. ity and consistency, compliance and efficiency. Al- though standards like TOGAF and FEAF have devel- The components of an EA framework should be ap- oped, however, there is no common agreement on plicable for a broad range of corporations and govern- which architecture layers, which artifact types and ment agencies. which dependencies constitute the essence of enter- Traditionally, architecture in the information sys- prise architecture. This paper contributes to the identi- tems context is focusing on IT related artifacts like IT fication of essential elements of enterprise architecture platforms, software components and services, applica- by (1) specifying enterprise architecture as a hierar- tions, IT processes, and maybe IT strategy in order to chical, multilevel system comprising aggregation hier- support more efficient IT operations, better return on archies, architecture layers and views, (2) discussing IT investment, and faster, simpler and cheaper IT pro- enterprise architecture frameworks with regard to es- curement. [12] In contrast to this approach which bet- sential elements, (3) proposing interfacing require- ter should be designated information systems architec- ments of enterprise architecture with other architec- ture (ISA), EA should also include business related ture models and (4) matching these findings with cur- artifacts like organizational goals, products and ser- rent enterprise architecture practice in several large vices, markets, business processes, performance indi- companies. cators, etc. [1] Only when ‘purely’ business related artifacts are covered by EA, important management 1. Enterprise architecture: definition activities like business continuity planning, change impact analysis, risk analysis and compliance can be According to ANSI/IEEE Std 1471-2000, architec- supported. ture is defined as the “fundamental organization of a system, embodied in its components, their relation- 2. Enterprise architecture: representation ships to each other and the environment, and the prin- ciples governing its design and evolution” [8]. Enter- The above definition of architecture restricts in- prise architecture (EA) therefore is understood as (1) cluded components to be ‘fundamental’. Due to the the fundamental organization of a government agency broad range of relevant component types, EA may or a corporation, either as a whole, or together with nevertheless comprise a huge number of such artifacts. partners, suppliers and / or customers (“extended en- As a consequence, most EA frameworks distinguish terprise”), or in part (e.g. a division, a department, etc.) several architecture layers and architecture views in as well as (2) the principles governing its design and order to reduce the number of artifacts per model [16, evolution. [12] 18]. When several architecture layers and architecture views are differentiated, design and evolution princi- ples have to address consistency and integration issues.10th IEEE International Enterprise Distributed Object Computing Conference Workshops (EDOCW06)0-7695-2743-4/06 $20.00 © 2006
  2. 2. The theory of hierarchical, multilevel systems [11] modeled on various level of aggregation. E.g., the or- provides a conceptual foundation for such methods. ganizational goals of a corporation (or government For EA, a hierarchical approach usually applies the agency) that are defined on a very aggregate level in a ‘IT follows business’ principle, starting with strategic balanced scorecard, are subsequently decomposed into positioning from the business management point of more and more specific performance indicators, result- view, then deriving appropriate organizational proc- ing in a multi-layer goal/indicator aggregation hierar- esses and structures on this basis, and finally specify- chy. Such aggregation hierarchies are commonly used ing the information system, i.e. the interaction between not only for goals/indicators, but also for prod- human and technical information system components ucts/services, business processes, organizational units, that appropriately support business requirements [1]. information objects, or software artifacts. Most frameworks differentiate the following EA layers: Business Architecture • Business architecture: The business architecture represents the fundamental organization of the cor- Process poration (or government agency) from a business Architecture strategy viewpoint. Design and evolution principles for business architecture can be derived e.g. accord- ing to the market based approach [14] or the re- Integration Architecture source based approach [5] to strategic management. • Process architecture: The process architecture represents the fundamental organization of service Software development, service creation, and service distribu- Architecture tion in the relevant enterprise context. Design and evolution principles for this layer focus on effec- tiveness (creating specified outputs) and efficiency Technology Architecture (meeting specified performance goals) [13]. • Integration architecture: The integration architec- Fig. 1. Multi-layer architecture of aggregation ture represents the fundamental organization of in- hierarchies formation system components in the relevant enter- prise context. Design and evolution principles for Fig. 1 is a schematic illustration of an EA compris- this layer focus on agility (e.g. by service orienta- ing the above mentioned five hierarchical layers. On tion [4]), cost efficiency (e.g. by reduction of inter- each layer, aggregation hierarchies are used to repre- faces [10]), integration (e.g. by analysis of data sent artifacts on different levels of aggregation. coupling [6]), and / or speed (e.g. by straight- Alongside the formation of architecture layers and through processing [9]). aggregation hierarchies, views are often used in order • Software architecture: The software architecture to master complexity [17]. In a multi-layer architec- represents the fundamental organization of software ture, views can be layer-specific or cross-layer. Exam- artifacts, e.g. software services and data structures. ples for layer-specific views in EA are the structural A broad range of design and evolution principles view (organizational units, responsibilities) and the from computer science is available for this layer. process view (business processes, performance indica- • Technology (or infrastructure) architecture: The tors) on the organization/process layer. Examples for technology architecture represents the fundamental cross-layer views are security architecture and infor- organization of computing / telecommunications mation architecture. hardware and networks. A broad range of design Based on the concepts of multi-layer representation, and evolution principles from computer science is aggregation hierarchy and cross-layer view, EA can be available for this layer too. defined as the view that represents all aggregate arti- facts and their relationships across all layers (Fig. 2). According to the hierarchical, multi-level systems This is due to the fact that only the most aggregate theory approach, results on each architecture layer re- artifact representations can be ‘fundamental’, and that duce the degrees of freedom of the subsequent layers all more decomposed artifact representations have to [11]. be covered by specialized architectures. Most of the artifacts classes represented in EA can The remainder of this paper is organized as follows: be represented as aggregation hierarchies, i.e. can be In Section 2 we analyze several EA approaches with10th IEEE International Enterprise Distributed Object Computing Conference Workshops (EDOCW06)0-7695-2743-4/06 $20.00 © 2006
  3. 3. regard to the core artifacts they propose. Interfaces to In general, FEAF comprises not many artifact types, other corporate architectures and models are discussed and has – like the Zachman framework from which it in Section 3. In Section 4, we compare our recommen- was adapted – not put much effort into specifying EA- dations against several EA case studies in large com- relevant artifact relationships. Goal/performance re- panies from different countries and industry sectors. In lated artifacts and product specifications are not cov- Section 5, conclusions regarding the level of detail of ered by FEAF at all. EA core artifacts and their interfaces to other architec- The five views of the original ARIS framework [15] tures are drawn, and an outlook to future research in comprise artifacts that are located mainly on the soft- this area is given. ware component layer of the proposed EA framework. This mainly ‘technical’ subset of artifacts has recently Business been extended [7]. But even with ‘business architec- Architecture ture’ extensions, strategy related artifacts are not cov- ered in depth. There is also a lack of artifacts that rep- resent high-level constructs on the integra- Process Architecture tion/application layer (e.g. application clusters, enter- prise services). On the other hand, many artifacts are covered that are considered not to constitute an impor- Integration Architecture tant component of EA (e.g. computer hardware details, machine resources). When comparing these framework approaches to Software EA, the following set of artifact types results as a hy- Architecture pothesis for EA core artifacts: • Strategy specification (“what” questions): hierarchy Technology Architecture of organizational goals and success factors, prod- Enterprise Architecture uct/service model (including partners in value net- works), targeted market segments, core competen- Fig. 2. Enterprise architecture as cross-layer cies, strategic projects, maybe business principles, view of aggregate artifacts dependencies between these artifacts • Organization/process specification (“how” ques- 2. Core artifacts of enterprise architecture tions): − Specification of structure: organizational unit hi- In this section, we discuss which core artifacts erarchy, business location hierarchy, business should be covered on the five regarded EA layers. As a role hierarchy (including skills requirements), basis for consolidating artifact types that are consid- dependencies between these artifacts ered as being important for EA, we analyze widely − Specification of behavior: business function hier- used EA frameworks such as TOGAF 8.1 [12], FEAF archy, business process hierarchy including in- version 1.1 [2, 3] and ARIS [15] with extensions from puts/outputs (internal and external business ser- [7]. vices including service levels), metrics (perform- TOGAF’s business architecture is populated with ance indicators), service flows many artifact types. The five-layer approach presented − Specification of information logistics: business in the preceding section therefore differentiates be- information objects, aggregate information flows tween strategy related artifacts (specifying the “what”) − Dependencies between these artifacts, e.g. re- and organization/process related artifacts (specifying sponsibilities, information requirements the “how”). TOGAF’s IS architecture layer can be • Application specification (business IT alignment compared to the proposed integration/application layer. questions): Data and applications architecture are assigned to dif- − Specification of applications and application ferent layers in TOGAF, whereas they are treated as components views on the software layer in the proposed frame- − Specification of enterprise services and service work. components FEAF’s data architecture, application architecture • Software specification and technology architecture can be interpreted as − Specification of software components: function- cross-layer views, while business architecture comes ality hierarchy, event/message hierarchy close to a simplified business & process architecture.10th IEEE International Enterprise Distributed Object Computing Conference Workshops (EDOCW06)0-7695-2743-4/06 $20.00 © 2006
  4. 4. − Specification of data resources: conceptual, logi- enterprise service – process deliverable – product – cal and physical data models revenue). − Dependencies between these artifacts, e.g. data As a consequence, EA should be ‘broad’ rather than usage by software components (CRUD) ‘deep’: For multi-step dependency analyses and holis- • Technical infrastructure specification tic coverage of IT business alignment, it is much more − Specification of IT components: hardware units, useful to cover a large number of artifact types and network nodes, etc. their dependencies on an aggregate level, than to cover − Dependencies between these artifacts a small number of artifact types and their dependencies • Specification of dependencies between layers, e.g.: in more detail. This understanding of EA is illustrated − Organizational goals/success factors vs. process in Fig. 2. We therefore need to identify appropriate metrics interfaces to partial, specialized architectures like − Products/services vs. process deliverables − Organizational units vs. applications (ownership) • product/service architecture (managed e.g. using a product management tool), − Activities vs. applications • metrics architecture (managed e.g. using a perform- − Activities/business processes/information re- ance management tool), quirements vs. enterprise services (orchestration) • process architecture (managed e.g. using a process − Applications/enterprise services vs. conceptual modeling tool and workflow management systems), data entity types • information/data architecture (managed e.g. using a − Applications/enterprise services vs. software data modeling tool and database management sys- components (composition) tems), In the following Section, we will first discuss which • software architecture (managed e.g. using a soft- artifact types on which aggregation levels should be ware design tool and a configuration management part of EA, and which should be part of other, special- tool) and ized architectures and models. In Section 4, we will • technology architecture (managed e.g. using a com- compare our recommendation with several EA case puter system management tool). studies that exhibit current EA practice in large com- panies. In order to provide an indication regarding the specification of interfacing between EA and special- ized partial architectures, four EA case studies are pre- 3. Interfacing enterprise architecture with sented in the next section. other corporate architectures and models 4. Case studies It is obvious that the complexity of a medium or large corporation (or government agency) cannot be By presenting four case studies of EA initiatives covered by one single EA. In real life, several EAs for conducted by large companies from different industries different parts of the enterprise might be maintained, and countries, we want to validate our recommenda- and/or EA will co-exist with other, more specialized tions for essential EA artifact types in Section 3. architectures that cover a subset of artifacts. Hence a The data was collected by desk research, informal useful interfacing between EA and specialized archi- interviews with EA project managers and/or personal tectures must be specified. involvement of the authors in EA projects of these An analysis of the goals of EA seems useful in or- companies. Table 1 gives an overview of the four ana- der to specify this interface. EA should lyzed companies. • support IT business alignment by providing support Table 1. Overview of case studies for consistent design and evolution of artifacts on different layers and/or in different views, Company Company Company Company • support transformation (business development, A B C D process reengineering, IS reengineering) by provid- Country Switzer- South Germany Switzer- ing impact analyses and land Africa land • support maintenance, compliance, risk management Industry Financial Mining Banking Insurance etc. by documenting not only structures and direct services dependencies, but also allowing to analyze multi- The description of the cases is structured as follows: step dependencies (e.g. server – software service – We start with outlining the core business of the com-10th IEEE International Enterprise Distributed Object Computing Conference Workshops (EDOCW06)0-7695-2743-4/06 $20.00 © 2006
  5. 5. pany. Then we describe the motivation for adopting an hierarchical model which defines organizational units EA program within the respective company. After this, broadly at first and then with increasing detail. Fur- the EA model layers of the respective project are speci- thermore, core business functions are linked to strategy fied and mapped to the architecture layers proposed in implementation projects (as part of the strategy archi- Section 1. Finally we identify core artifacts within each tecture). layer and important intra-layer as well as cross-layer Application services, applications, application clus- dependencies between artifacts. ters and information objects are artifact types assigned to the application architecture. Here the most important 4.1. Company A dependencies regarding artifacts from the same layer as well as from superordinate layers are Company A is a major Swiss financial service pro- • dependencies between application services and vider. The EA program of company A was started in business processes as well as between application 2005 and is ongoing. The program was initiated be- services and core business functions, cause an aggregate, enterprise-wide view of important • dependencies between information objects and ap- entities and dependencies did not exist. plications, and Unlike many other organizations, IT business alignment is not the major driver for EA efforts in • dependencies between information objects and busi- company A. Instead, EA is aimed at supporting strat- ness processes. egy implementation, in particular at supporting the The IT architecture comprises deployed applications project selection/project portfolio planning process. In which are linked to application services on the su- addition, EA is regarded as foundation of business perordinate layer and IT components called “configu- continuity planning, service management and security ration items” (servers, databases, etc.). IT components management. are represented by a hierarchical model. The enterprise architecture model of company A With respect to the development of enterprise archi- comprises four architectural layers (Fig. 3). tecture content, Company A strongly relies on infor- EA layers of Company A Proposed EA layers mation from models which already exist within the enterprise. A single EA repository is used to integrate Strategy Architecture Business Architecture meta data on all EA artifact types. Artifact meta data Business Architecture Process Architecture from various sources is cleaned, and redundancies are eliminated during the repository update process. There Application Architecture Integration Architecture is no need for specific EA modeling activities except for representing aspects that are not covered by exist- Software Architecture ing models. Technical / IT Architecture Infrastructure Architecture 4.2. Company B Fig. 3. Mapping between EA layers of com- Company B is one of the world’s leading producers pany A and proposed EA layers of precious metals with exploration and mining activi- The strategy architecture represents organizational ties in South Africa, Canada, Russia, Brasil and Zim- goals as well as projects aiming at implementing these babwe. goals, and project results linked to these goals. Com- The adoption of an EA program at company B was pany A intends to extend the strategy architecture by motivated by the need for accurate, timely and consis- adding success factors related to organizational goals tent information regarding the corporate structure. and performance indicators for these success factors. Main reasons for dealing with EA at company B have The business architecture corresponds to the process been poor IT business alignment, absence of an effec- architecture mentioned in Section 1 (Fig. 3) and repre- tive IT governance, and unification of modeling meth- sents core business functions, organizational units, ods, tools and standards across the enterprise. business locations and service level agreements which Company B’s EA model is subdivided into five lay- are all linked to high level business processes. The ers (Fig. 4). services offered by company A are also represented on The business architecture represents strategic objec- this layer. This is a major difference to our proposal in tives, business principles, offered products, business Section 1 where we assigned business services to the roles, organizational units and business locations as strategy layer. Organizational units are depicted by a well as risk items. All of these artifact types are linked10th IEEE International Enterprise Distributed Object Computing Conference Workshops (EDOCW06)0-7695-2743-4/06 $20.00 © 2006
  6. 6. to high level business processes. The business proc- business segments should be revealed, and information esses model itself is a hierarchical model consisting of required for sourcing decisions should be provided. enterprise processes (level 0) which are decomposed Company C’s EA approach distinguishes between into value chains (level 1). These value chains are then business architecture and technical/IT architecture, decomposed into processes (level 2). Summarizing with both architectures being subdivided into several these findings, company B’s business architecture can layers. The mapping between company C’s EA layers be understood as a combination of the proposed busi- and the EA layers proposed in Section 1 is illustrated ness architecture and selected parts of the process ar- by Fig. 5. chitecture from Section 1 (Fig. 4). For each business segment, the business model layer represents value networks, targeted market segments EA layers of Company B Proposed EA layers and offered services. The service model is a hierarchi- Business Architecture cal model comprising three levels: level 1 (product Business Architecture categories) is decomposed into level 2 (product Process Architecture groups) which then is decomposed into level 3 (prod- Information Architecture ucts). EA layers of Company C Proposed EA layers Application Architecture Integration Architecture Business Model Architecture Business Architecture (x) Data Architecture Software Architecture Business Process Architecture Process Architecture Technology Architecture Infrastructure Architecture Application Architecture (x) Mapping refers to data-related artifacts only Integration Architecture Integration Architecture Fig. 4. Mapping between EA layers of Com- pany B and proposed EA layers System Architecture Software Architecture The information architecture is comprised of an in- Operational Architecture Infrastructure Architecture formation object hierarchy and a metrics hierarchy as well as dependencies between information objects and Fig. 5. Mapping between EA layers of Com- metrics on the one hand and processes, applications pany C and proposed EA layers and data models on the other hand. The breakdown of enterprise processes/value chains Applications, application clusters, application mod- into sub-processes and their relationships are repre- ules and application interfaces are artifacts represented sented on the business process layer. By means of a by the application architecture. In order to enable IT org unit hierarchy, the organizational structure of the business alignment, applications are connected ‘up- company is represented on the business process layer ward’ to business processes and organizational units too. In addition, the following dependencies are speci- (on the business layer). fied on the business process layer regarding artifacts The data architecture depicts (logical) data models from the same layer as well as from other layers: embracing data subject areas, entities, tables and their relationships to business processes and organizational • Dependencies between business processes and or- units/business roles. ganizational units The technology architecture comprises infrastruc- • Dependencies between business processes and ap- ture applications and network nodes. Both are linked to plication clusters as well as single applications applications, databases, organizational units and busi- • Dependencies between offered services and corre- ness locations. sponding business processes The application layer is comprised of logical appli- 4.3. Company C cation clusters, while the integration layer describes principles and technologies for application integration. Company C is a large German full-service bank Technical components related to applications are rep- with more than four million private customers and al- resented on the system layer. The operational layer most half a million corporate clients. represents mandatory principles for application opera- Company C developed EA to enhance the transpar- tion. ency of process architecture and integration architec- ture. By that means, potentials for optimization across10th IEEE International Enterprise Distributed Object Computing Conference Workshops (EDOCW06)0-7695-2743-4/06 $20.00 © 2006
  7. 7. 4.4. Company D the other hand are specified on the runtime environ- ment sub-layer. Being a major player in the Swiss insurance market The data architecture encompasses data objects, en- with more than one million customers and focusing on tity types and tables. Data objects are linked to busi- non-life insurance, Company D has launched its EA ness objects represented within the business architec- initiative more than four years ago. ture. Investment in EA has been justified by a lack of Business risks, non-functional requirements and transparency regarding dependencies between IT and technical precautions are represented by the security service offerings / business processes. As a conse- architecture. Dependencies between business risks and quence, an EA model was created as a means for en- business activities are also represented as part of the terprise planning, to eliminate redundancies, and to security architecture. standardize business processes as well as information systems. 5. Conclusions and outlook Company D’s EA model is comprised of three ar- chitectural layers. Alongside these three layers, two Based on the discussion of current EA frameworks, architecture views exist. Fig. 6 depicts the mapping of we proposed a set of EA layers, artifacts and depend- this approach to the EA layers proposed in Section 1. encies in Section 2 that we consider as essential for a EA layers of Company D Proposed EA layers business-oriented approach to EA. In Section 3, we presented arguments for differentiating between EA Business Architecture Business Architecture and other, specialized architectures and models in en- terprise modeling. Since the basic layer design “from Security Architecture Process Architecture Data Architecture business to IT”, most of the artifacts and many de- Application Architecture Integration Architecture pendencies can be identified in various actual EA cases Software Architecture summarized in Section 4, it is justified to propose our Technical / IT Architecture recommendation of EA essentials as a hypothesis. Of Infrastructure Architecture course, broad empirical studies need to validate this proposition. Fig. 6. Mapping between EA layers of Com- We believe that an important success factor for EA pany D and proposed EA layers initiatives is to clearly distinguish between the broad, The business architecture is aimed at representing but aggregate EA on the one hand, and a set of special- corporate strategy, services, business principles, busi- ized, detailed partial architectures on the other. Enter- ness scenarios, business processes and corresponding prise modeling can achieve its goals only if interfaces activities as well as business components and business between EA and specialized architectures have been objects. Business processes are depicted by means of conceptually specified and efficiently implemented. an aggregation hierarchy. Elementary processes are With reference to the essential EA artifacts pro- decomposed into activities. Business scenarios are posed in Section 2 and our findings from the case stud- mapped to services. ies in Section 4, we suggest that interfaces between EA Dependencies between business activities and ap- and specialized architectures should be specified as plications, application components, application ser- follows: vices and application interfaces are represented by the application architecture. • Business architecture: While product/service cate- The technical/IT architecture is comprised of two gories, product/service groups and products/services sub-layers designated as “implementation technology” should be comprised in EA, more detailed prod- and “runtime environment”. Software systems and uct/service representations like variants, ver- their decomposition into software components, soft- sions/releases and components should be repre- ware modules as well as software interfaces are repre- sented by a product sub-architecture, and managed sented by the “implementation technology” sub-layer. by a product management tool. Furthermore, pro- Software interfaces are linked to application interfaces. jects aiming at realizing strategic goals should not Platforms, databases, integration systems and network be decomposed in EA. Project portfolio tools and / nodes required to run the systems are represented by or project management tools are more appropriate the ”runtime environment” sub-layer. In addition, de- for this purpose. pendencies between platforms and integration tech- • Process architecture: Business processes should nologies on the one hand, and software components on not be decomposed further than to the sub-process level. Detailed process descriptions including speci-10th IEEE International Enterprise Distributed Object Computing Conference Workshops (EDOCW06)0-7695-2743-4/06 $20.00 © 2006
  8. 8. fications of activities and work steps are out of EA tectures, Proc. of the Workshop in Klagenfurt, Klagen- scope and should be maintained by using special- furt, 2005, pp. 64-79. ized business process modeling tools and / or work- [2] CIO-Council, A Practical Guide to Federal Enter- flow design tools. As a consequence, process per- prise Architecture, February 2001. formance management tools are much better suited [3] CIO-Council, Federal Enterprise Architecture to represent performance indicators related to activi- Framework Version 1.1, September 1999. ties, while the aggregate performance information [4] K.B. Douglas, Web Services and Service-Oriented represented in balanced scorecard tools might be a Architecture: Your Road Map to Emerging IT, Morgan valuable part of EA. Kaufmann Publishers, 2003. • Integration architecture: While aggregate de- [5] G. Hamel and C.K. Prahalad, "The Core Compe- pendencies / data flows between applications or ap- tence of the Corporation," Harvard Business Review, plication components are belonging to EA and vol. 68, no. 3, 1990, pp. 79-91. should be managed by appropriate EA tools, de- [6] IBM, Business Systems Planning - Information tailed interface descriptions for data exchange, re- Systems Planning Guide, 4th ed., IBM-Form GE20- mote procedure calls etc. should be maintained by 0527-4, Atlanta: 1984. using tools like integration repositories of enterprise [7] IDS-Scheer, Enterprise Architectures and ARIS application integration (EAI) tools. Process Platform, White Paper, 2005. • Software architecture: Detailed descriptions of [8] IEEE, IEEE Recommended Practice for Architec- data objects (e.g. attribute lists) are not essential for tural Description of Software Intensive Systems (IEEE EA purposes and should be managed e.g. by using a Std 1471-2000), IEEE Computer Society, 2000. data modeling tool. In addition, structural and be- [9] B. Kuhlin and H. Thielmann, ed., The Practical havioral aspects of single software components are Real-Time Enterprise: Facts and Perspectives, not covered by EA and should be managed by using Springer, 2005. software design tools. [10] D.S. Linthicum, Enterprise Application Integra- • Infrastructure architecture: Detail specifications tion, Reading, Massachusetts: AWL Direct Sales, of IT components (hardware units etc.) are not es- 2000. sential for EA; Asset management tools should be [11] M.D. Mesarovic, D. Macko, and Y. Takahara, used for managing such meta data, and appropriate Theory of Hierarchical, Multilevel Systems, New interfaces have to maintain consistency between the York, London: Academic Press, 1970. different repositories. [12] The Open Group, TOGAF "Enterprise Edition" Version 8.1, 2003. In addition to a broader empirical validation of the [13] H. Österle, Business in the Information Age - proposed essential layers, artifacts and dependencies of Heading for New Processes, New York: Springer, EA, further research will be needed to identify and 1995. validate a reference meta architecture that specifies [14] M.E. Porter, Competitive Advantage: creating and architecture components (EA, performance manage- sustaining superior performance, 2nd ed., New York: ment, product management, project management, Free Press, 1998. workflow design, data management, EAI configura- [15] A.-W. Scheer, ARIS – Business Process Frame- tion, software design, IT asset management, etc.) and works, 3 ed., Berlin et al.: Springer, 1999. interfaces between those components. [16] J. Schekkerman, How to Survive in the Jungle of Another interesting aspect that has not been covered Enterprise Architecture Frameworks: Creating or in depth is the differentiation of EA scenarios, e.g. by Choosing an Enterprise Architecture Framework, 2nd clustering EA approaches based on EA goals, enter- ed., Victoria, British Columbia: Trafford Publishing, prise size, enterprise structure, etc. Based on an appro- 2004. priate scenario model, the recommendation of refer- [17] J.F. Sowa and J.A. Zachman, "Extending and ence structures and reference processes for EA could Formalizing the Framework for Information Systems then be refined by scenario-specific configuration. Architecture," IBM Systems Journal, vol. 31, no. 3, 1992, pp. 590-616. References [18] A. Tang, J. Han, and P. Chen, A Comparative Analysis of Architecture Frameworks, SUTIT- [1] C. Braun and R. Winter, "A Comprehensive Enter- TR2004.01, Swinbourne University of Technology, prise Architecture Metamodel and Its Implementation 2004. Using a Metamodeling Platform," in Proceedings of Enterprise Modelling and Information Systems Archi-10th IEEE International Enterprise Distributed Object Computing Conference Workshops (EDOCW06)0-7695-2743-4/06 $20.00 © 2006