Back to top

EA Principle

EA principles constitute generally valid guidelines for the development of an EA [11b].

EA Principle Foundations

EA principles constitute generally valid guidelines for the use of EA elements [11b]. These principles are independent of a specific EA and self-restraint instead of externally obliged, e.g. by law in terms of compliances [Buc10a]. They are formulated as short but comprehensive statements [Fuh13b]. Examples for principles are “Loose coupling of systems or services” or “Buy before make” [Ale+15].

The EA principles constrain the design space, which comprises all accepted states of an EA [Buc10a]. This way it constitutes a basis for consistent, goal-oriented decision making [Buc10a; Fuh13b]. Figure 1 shows a visual example of how EA principles restrict the design space in the context of the managed evolution approach for EA development.


Figure 1: Influence of EA Principles on the Design Space in the context of managed evolution.


EA Principles and IT Standards

EA principles and IT standards are located on different levels of abstraction [Buc10a]. The EA principles provides an underlying rationale, which is operationalized by IT standards [Buc10a]. This link can be illustrated using an example taken from [Buc10a]. The basic assumption is that an organization has an EA principle in place, which obliges the IT department to concentrate development competences. This EA principle can be operationalized by establishing an IT standard stating that only a restricted set of programming languages can be used in future projects [Buc10a].


List of EAM Principles

A list of EA principles defined in the TUM Pattern Catalog created at the Chair for Software Engineering of Business Information Systems at Technische Universität München can be found in Table 1 [Ale+15]. Another list of EA principles can be found in TOGAF [11b].



Compliance with security regulations

Technology portfolio is based on few technologies

Reuse of functionality

Buy before make

High flexibility, efficency and modularity of architectural solutions

Loose coupling of systems or services

Consider architecture principles in future application landscape development

Service-orientation of architecture

Prevention of replication of inventory data

High availability of sales & and customer portals

Analyses are conducted by a central data warehouse system

Subsidiaries are responsible for own data; common data model for group-wide information

Process- and task-oriented architectural solutions

Provision of target group specific functionalities

Common development of common source code for group-wide information systems

Functional target image as a framework for the deployment of systems

Tool support for product development and direct change opportunities for functional areas

Systems have predefined run time, Removal of old systems is mandatory

Seperated modeling of processes, organization and IT


Table 1: List of EA Principles identified in [Ale+15].



S. Buckl. “A Conceptual Framework for Enterprise Architecture Design.” In: Trends in Enterprise Architecture Research - 5th International Workshop, TEAR 2010. Vol. 70. Lecture Notes in Business Information Processing (LNBIP). Delft: Springer, 2010, pp. 44–56.


K. Fuhrer. “Architecturmanagement: Migrationsschritte zur Servicelandschaft, SOA-Transformation.” In: Business Technology (bt) Magazin 1 (2013).


TOGAF® Version 9.1, an Open Group Standard. Standard. The Open Group, 2011.


P. Aleatrati Khosroshahi, M. Hauder, A. W. Schneider, and F. Matthes. Enterprise Architecture Management Pattern Catalog V2. Tech. rep. Munich, Germany: Technichal University of Munich (TUM), 2015.