EA Principle

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.

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].