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}@unisg.ch
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 (EDOCW'06)
0-7695-2743-4/06 $20.00 © 2006

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 with
10th IEEE International Enterprise Distributed Object Computing Conference Workshops (EDOCW'06)
0-7695-2743-4/06 $20.00 © 2006

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 (EDOCW'06)
0-7695-2743-4/06 $20.00 © 2006

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 (EDOCW'06)
0-7695-2743-4/06 $20.00 © 2006

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 linked
10th IEEE International Enterprise Distributed Object Computing Conference Workshops (EDOCW'06)
0-7695-2743-4/06 $20.00 © 2006

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 across
10th IEEE International Enterprise Distributed Object Computing Conference Workshops (EDOCW'06)
0-7695-2743-4/06 $20.00 © 2006

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 (EDOCW'06)
0-7695-2743-4/06 $20.00 © 2006

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 (EDOCW'06)
0-7695-2743-4/06 $20.00 © 2006