EA Model

Generally, models are abstractions of reality created for a certain purpose. Therefore, they only represent those aspects of reality, which are relevant for the corresponding purpose and neglect other, irrelevant details [BBL12].

In the context of EAM, we need to distinguish between two types of models. First, there is the EA model which constitutes a conceptual model of the whole EA [BKS10]. In accordance with ISO/IEC/IEEE 42010:2011, this model is called the architectural description, but sometimes it is also referred to as a “mental model” of the EA [11a]. The architectural description consist of various architecture elements like processes, applications or data objects [LM11] which are defined by the implemented information model. These architecture elements are spread over all architectural layers, from business down to technology, and their relationships [BBL12].

Different viewpoints can be applied to the architecture description, addressing concerns of certain EA stakeholders [11a]. Each of the resulting views comprises one or more architecture models, which are the second type of models [11a]. These models are work products like e.g. business capability maps or business support maps relating business application architecture elements with IT architecture. Each model is specified by its model kind [11b] and can be part of one or more views [11a; BKS10]. Both types of models introduced have the purpose to make the EA transparent and thus enable informed decision making and effective enterprise architecture development [BBL12].

Models are not only purpose bound, but they also have a time dimension. As illustrated in Figure 1, three general kinds of models can be distinguished with regards to time: the current state (as-is), the future desired state (to-be), and the planned transition states along the way (planned) [BBL12; Myk+11]. The as-is model reflects the actual architecture of the organization at a certain point in time [Wit+07]. The target/ to-be / envisioned state model describes the ideal state of the organizations architecture according to strategies and architectural principles [Wit+07]. This state cannot actually be achieved, but helps to decide which projects should be realized. Finally, the planned state model depicts the architecture of the organization when all currently planned and budgeted projects are finalized [Wit+07]. Therefore, they constitute states that can actually be achieved [Wit+07].

Besides general modeling languages like Unified Modeling Language (UML) and Business Process Modeling and Notation (BPMN), architecture description languages (ADLs) like ArchiMate can be used for modeling enterprise architectures.

Advantages and Challenges of EA Models

In addition to making the EA transparent and therefore enable informed decision making and effective enterprise architecture development, the visualization of the EA using models makes it more accessible for stakeholders. Possible topics that can be addressed using these visualizations are the identification of gaps between as-is and to-be, the explanation and motivation of changes or the determination of the impact of incidents and changes [BBL12].

On the other hand, a downside of using an EA model is that it is laborious and expensive in its making and maintenance. Therefore the benefit-cost ration needs to be carefully considered when choosing the level of detail of a model [BBL12].