Documente Academic
Documente Profesional
Documente Cultură
Abstract
After a period where implementation speed was more important than integration, consis-
tency and reduction of complexity, architectural considerations have become a key issue
of information management in recent years again. Enterprise architecture is widely ac-
cepted as an essential mechanism for ensuring agility and consistency, compliance and
efficiency. Although standards like TOGAF and FEAF have developed, however, there is
no common agreement on which architecture layers, which artifact types and which de-
pendencies constitute the essence of enterprise architecture. This paper contributes to
the identification of essential elements of enterprise architecture by (1) specifying enter-
prise architecture as a hierarchical, multilevel system comprising aggregation hierarchies,
architecture layers and views, (2) discussing enterprise architecture frameworks with re-
gard to essential elements, (3) proposing interfacing requirements of enterprise architec-
ture with other architecture models and (4) matching these findings with current enter-
prise architecture practice in several large companies.
Keywords
enterprise architecture, architectural components, architectural layers, architectural
views, interfaces
Business
Architecture
Process
Architecture
Integration
Architecture
Software
Architecture
Technology
Architecture Enterprise
Architecture
In this section, we discuss which core artifacts TOGAF 8.1 (Opengroup 2003), FEAF version
should be covered on the five regarded EA lay- 1.1 (CIO-Council 1999, CIO-Council 2001) and
ers. As a basis for consolidating artifact types ARIS (Scheer 1999) with extensions from (IDS
that are considered as being important for EA, Scheer 2005). The results are exhibited in Table
we analyze widely used EA frameworks such as 1 below.
The description of the cases is structured as was initiated because an aggregate, enterprise-
follows. We start with outlining the core busi- wide view of important entities and dependen-
ness of the company. Then we describe the cies did not exist.
motivation for adopting an EA program within
the respective company. After this, the EA Unlike many other organizations, IT business
model layers of the respective project are speci- alignment is not the major driver for EA efforts in
fied and mapped to the architecture layers pro- company A. Instead, EA is aimed at supporting
posed in Section 1. Finally we identify core arti- strategy implementation, in particular at support-
facts within each layer and important intra-layer ing the project selection/project portfolio plan-
as well as cross-layer dependencies between ning process. In addition, EA is regarded as
artifacts. foundation of business continuity planning, ser-
vice management and security management.
Software Architecture
Technical / IT Architecture
Infrastructure Architecture
The business architecture is aimed at represent- business risks and business activities are also
ing corporate strategy, services, business prin- represented as part of the security architecture.
ciples, business scenarios, business processes
and corresponding activities as well as business
components and business objects. Business CONCLUSIONS AND OUTLOOK
processes are depicted by means of an aggre-
gation hierarchy. Elementary processes are Based on the discussion of current EA frame-
decomposed into activities. Business scenarios works, we proposed a set of EA layers, artifacts
are mapped to services. and dependencies in Section 2 that we consider
as essential for a business-oriented approach to
Dependencies between business activities and EA. In Section 3, we presented arguments for
applications, application components, applica- differentiating between EA and other, special-
tion services and application interfaces are rep- ized architectures and models in enterprise
resented by the application architecture. modeling. Since the basic layer design “from
business to IT”, most of the artifacts and many
The technical/IT architecture is comprised of two dependencies can be identified in various actual
sub-layers designated as “implementation tech- EA cases summarized in Section 4, it is justified
nology” and “runtime environment”. Software to propose our recommendation of EA essen-
systems and their decomposition into software tials as a hypothesis. Of course, broad empirical
components, software modules as well as soft- studies need to validate this proposition.
ware interfaces are represented by the “imple-
mentation technology”sub-layer. Software inter- We believe that an important success factor for
faces are linked to application interfaces. Plat- EA initiatives is to clearly distinguish between
forms, databases, integration systems and net- the broad, but aggregate EA on the one hand,
work nodes required to run the systems are and a set of specialized, detailed partial archi-
represented by the ”runtime environment” sub- tectures on the other. Enterprise modeling can
layer. In addition, dependencies between plat- achieve its goals only if interfaces between EA
forms and integration technologies on the one and specialized architectures have been con-
hand, and software components on the other ceptually specified and efficiently implemented.
hand are specified on the runtime environment
sub-layer. With reference to the essential EA artifacts pro-
posed in Section 2 and our findings from the
The data architecture encompasses data ob- case studies in Section 4, we suggest that inter-
jects, entity types and tables. Data objects are faces between EA and specialized architectures
linked to business objects represented within the should be specified as follows:
business architecture.
• Business Architecture: While prod-
Business risks, non-functional requirements and
uct/service categories, product/service
technical precautions are represented by the
groups and products/services should be
security architecture. Dependencies between
comprised in EA, more detailed prod-
CIO-Council (2001). A Practical Guide to Fed- Scheer, A.-W. (1999). ARIS – Business Process
eral Enterprise Architecture. Frameworks, 3rd Ed., Springer, Berlin et al.