EA Layer

An EA model can be conceptually divided into different architectural layers. The reason for splitting the model into different layers is to reduce complexity and enable manageability, since instances of conceptual entities assigned to each of these layers are manifold. While in the literature usually five architectural layers are differentiated [WS08], in practice often only three layers are distinguished [LM11].

Foundations EA Layer

An EA model consist of various entities like processes, applications or data objects [LM11] which are defined by the implemented information model. To be able to manage the big amount of instances of these entities in practice, EA information models are split into architectural layers. On the highest level these layers can be separated into the business architecture describing the business structure of an organization and the IT architecture characterizing its IT structure [SFS14; Han12b].

Different frameworks using different EA entities and different EA information models also apply different EA layers to their EA model [LM11]. An often cited source when talking about the subject of EA layers is [WS08], who analyzed The Open Group Architecture Framework version 8.1 (TOGAF), the Federal Enterprise Architecture Framework version 1.1 (FEAF) and the ARIS Framework, with regards to the EA layers employed. [WS08] identified and consolidated the five architectural layers listed here:

The business strategy layer comprising goals and success factors, products/services, targeted market segments, core competencies and strategic projects
The organization/business process layer comprising organizational units, business locations, business roles, business functions, business processes, metrics and service flows, business information objects and aggregate information flows
The integration layer comprising applications and enterprise services
The software/data layer comprising software components and data resources
The IT infrastructure layer comprising hardware units and network nodes

In this case, the business architecture would cover the business strategy layer as well as the organization/business process layer. The IT architecture subsumes the remaining layers.

Even though no uniform naming and content rules can be found in literature, the concepts expressed by the layers are very similar [PTS10]. Further EA models including EA layers can be found in [Fuh11a; 11b; Man10; Han12b; Wit07; Kel07; 16; Inta]. This enumeration in non-exhaustive.

Crosscutting Funtions

In addition, in some frameworks crosscutting functions are defined, that refer to entities which exert influence on the concepts in all EA model layers [BMS10]. An example for an EA model with such crosscutting functions is illustrated in Figure 1.

Figure 1: Layers and crosscutting functions of an enterprise architecture [Source: S. Buckl, F. Matthes, and C. Schweda. “Socio-technic Dependency and Rationale Models for the Enterprise Architecture Management Function.” In: 5th International Workshop on Ontology, Models, Conceptualization and Epistemology in Social, Artificial and Natural Systems (ONTOSE 2011). London, United Kingdom, 2011.]

The EA model in Figure 1 is split into the three layers business & organization, application & information and infrastructure & data. Additionally, crosscutting functions influence entities in all three of the aforementioned layers are depicted [RZM14]. These crosscutting aspects are the vision & goals, which are operationalized using strategies & projects [Mat+12]. The projects & strategies are used to transform EA entities. Further, principles & standards are guidelines and rules which restrict the design space of EA entities when they are transformed [Mat+12]. Finally, the questions & key performance indicators (KPI)s are used for controlling the entities and their transformation on different layers [Mat+12].

Findings from Literature Research

In [ARW08] 54 publications are analyzed with regards to how much their EA models cover each of the layers introduced by [WS08]. One result of this analysis is that strategic entities are often not or only scarcely represented in the respective EA models. Similarly, also the entities on the infrastructure layer are less intensively considered compared to entities placed in the organization/business process, the integration or the software/data layer.

Empirical Findings

In [LM11] the findings from semi-structured interviews with 16 EA experts are presented. According to the interviewed experts, in practice most organizations only distinguish between the business, application and infrastructure layer. Merely about one fourth of the participants in the study have an additional separate data layer in place. This means business architecture and process architecture as well as software architecture and integration architecture are merged into one layer respectively.

Further findings of [LM11] are that the interviewed experts expect the infrastructure layer to become less important over time, ultimately being a commodity that should be highly standardized. Additionally, the link between business and application layer is identified as being the most challenging, since most of the participating organizations have difficulties connecting goals and business processes as well as business processes and applications. A possible approach for solving this missing alignment between business and IT is also presented, proposing the introduction of an additional alignment layer linking business and IT.

Sources:

[LM11]	M. Lange and J. Mendling. “An experts’ perspective on enterprise architecture goals, framework adoption and benefit assessment.” In: 2011 IEEE 15th International Enterprise Distributed Object Computing Conference Workshops. 2011, pp. 304–313.
[WS08]	R. Winter and J. Schelp. “Enterprise architecture governance: the need for a business-to-IT approach.” In: Proceedings of the 2008 ACM symposium on Applied computing. Mar. 2008, pp. 548–552.
[SFS14]	D. Simon, K. Fischbach, and D. Schoder. “Enterprise architecture management and its role in corporate strategic management.” In: Information Systems and e-Business Management 12(1) (2014), pp. 5–42.
[Han12b]	I. Hanschke. Enterprise Architecture Management - einfach und effektiv: Ein praktischer Leitfaden für die Einführung von EAM. Carl Hanser Verlag GmbH Co KG., 2012.
[PTS10]	M. Postina, J. Trefke, and U. Steffens. “An ea-approach to develop soa viewpoints.” In: Enterprise Distributed Object Computing Conference (EDOC), 2010 14th IEEE International. 2010, pp. 37–46.
[Fuh11a]	K. Fuhrer. “Teil 1: Einführung und Überblick Metamodelle.” In: Enterprise Architecture Deliverables: Welche Ergebnisse liefert Enterprise Architecture? OPITZ CONSULTING GmbH. 2011.
[11b]	The Open Group. 2011. TOGAF® Version 9.1, an Open Group Standard.
[Man10]	T. Mannmeusel. “EAM im Mittelstand.” In: Enterprise Architecture Management (EAM) in der Praxis. Düsseldorf: Symposion Publishing GmbH, 2010, pp. 331–376.
[Wit07]	A. Wittenburg. “Softwarekartographie: Modelle und Methoden zur systematischen Visualisierung von Anwendungslandschaften.” PhD thesis. Fakultät für Informatik, Technische Universität München, 2007.
[Kel07]	W. Keller. IT-Unternehmensarchitektur, Von der Geschäftsstrategie zur optimalen IT- Unterstützung. 1. Auflage. Heidelberg: dpunkt.verlag GmbH, 2007.
[16]	The Open Group. 2016. ArchiMate® 3.0 Specification.
[Inta]	Z. International. The Concise Definition of The Zachman Framework. by: John A. Zachman. https://www.zachman.com/about-the-zachman-framework. Accessed: 29.10.2016.
[BMS10]	S. Buckl, F. Matthes, and C. Schweda. “Conceputal Models for Cross-cutting Aspects in Enterprise Architecture Modeling.” In: Joint 5th International Workshop on Vocabularies, Ontologies, and Rules for the Enterprise (VORTE 2010). Vittoria, Brazil, 2010.
[RZM14]	S. Roth, M. Zec, and F. Matthes. Enterprise Architecture Visualization Tool Survey 2014. Tech. rep. Munich: Chair for Software Engineering of Business Information Systems. Technische Universität München., 2014.
[Mat+12]	F. Matthes, I. Monahov, A. Schneider, and C. Schulz. EAM KPI Catalog v 1.0. Tech. rep. Munich: Chair for Software Engineering of Business Information Systems. Technische Universität München., 2012.

Incoming references

Content for this topic (0)

Links for this topic (0)