Back to top

EA Model

EA Models capture the EA with the purpose of making it transparent and thus enabling informed decision making and effective EA development.


EA Model Foundations

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

 

Figure 1: Possible time horizons for EAM models.

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


Sources:

[BBL12]

S. Bente, U. Bombosch, and S. Langade. Collaborative Enterprise Architecture: Enriching EA with Lean, Agile, and Enterprise 2.0 Practices. Elsevier, Inc., 2012.

[Myk+11]

M. Mykhashchuk, S. Buckl, T. Dierl, and C. M. Schweda. “Charting the landscape of enterprise architecture management.” In: 10th International Conference on Wirtschaftsinformatik, 16th-18th February 2011, Zurich, Switzerland. 2011.

[BKS10]

S. Buckl, S. Krell, and C. Schweda. “A formal approach to Architectural Descriptions - Refining the ISO Standard 42010.” In: Advances in Enterprise Engineering IV - 6th International Workshop on Cooperation & Interoperability - Architecture & Ontology (CIAO2010), Lecture Notes in Business Information Processing (LNBIP). Vol. 49. St.Gallen: Springer, 2010, pp. 77–91.

[11a]

ISO/IEC/IEEE 42010:2011 Systems and software engineering - Architecture description, Ingenierie des systemes et des logiciels - Description de l’architecture. Standard. International Organization for Standardization, 2011.

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

[11b]

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

[Wit+07]

A. Wittenburg, F. Matthes, F. Fischer, and T. Hallmermeier. “Building an integrated IT governance platform at the BMW Group.” In: Int. J. Business Process Integration and Management 2.4 (2007).