Back to top

EA Viewpoint & View

Viewpoints define conventions on how to address the concerns of stakeholders with regards to an enterprise architecture. Views result from the application of viewpoints to a system [11b].


EA Views & Viewpoints Foundations

The concept of views and viewpoints is best explained using an example taken from TOGAF® Version 9.1. The starting point is an arbitrary system-of-interest, e.g. some kind of business application, and a stakeholder group, namely the users of the business application [11b]. Since the users have to use the business application in the daily business, they users have concerns like the availability or response time of the business application [11b]. These concerns are a subset of the concerns of all stakeholders of the system. For example, users of a system don’t care about cost or compliance of the application, which the owner of the application would be interest in.

This means, the users have a certain perspective on the system, called a viewpoint. The viewpoint identifies which concerns are relevant to the stakeholder group “users” and which collection of models of the system architecture is used to address these concerns [11a]. To clarify the distinction between view and viewpoint, a very helpful comparison is introduced in the ISO/IEC/IEEE 42010:2011 standard [11a]: “a view is to a viewpoint as a program is to a programming language” [11a]. The viewpoint comprises the basic rules (languages, notations, model kinds, design rules, etc.) defining how a certain view is constructed, interpreted and used independently of the underlying system the view is constructed for [11a]. The actual application of the viewpoint to a system yields a view [11a]. Thus, a view can be seen as an instance of applying a viewpoint to a specific system [11a]. Every view should comply with its governing viewpoint [11a].The user view on the business application is unlikely to completely describe the system architecture, since aspects which are irrelevant to the respective stakeholders’ concerns are not captured [11b]. 

As already mentioned, views comprise one or more architecture models [11a]. Each model is specified by its model kind, just like each view is specified by its governing viewpoint [11b]. A model can be part of one or more views [11a; BKS10].

Moving away from the example introduced above, Figure 1 shows the conceptual model of an architecture description proposed by the ISO/IEC/IEEE 42010:2011 standard.

Figure 1: Conceptual model of an architecture description proposed by the ISO/IEC/IEEE 42010:2011 standard. [Source: 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.]

 

Approaches to the Construction of Views

The choice of which architecture views to create is an important decision an architect has to make. Once it is decided which views to develop, the architect can use one out of two approaches for the construction of views, the synthetic or the projective approach [11a]. If the synthetic approach is chosen, the Enterprise Architect first constructs the views and later on mergers them into an architecture description [11a]. On the other hand, if the projective approach is chosen, views are created based on data stored in an EA repository [11a; Fuh12].

 

Advantages and Challenges of EA Views & Viewpoints

The usage of different views with regards to enterprise architecture allows the Enterprise Architect to ensure that the concerns of all stakeholders are addressed and balanced when developing or evolving an architecture [16]. Further, it facilitates clear communication with stakeholders of a system [Fuh12]. Due to these advantages, the concept of viewpoints and views forms an integral part of many EAM frameworks like TOGAF, the "4+1" view model, DoDAF and RM-ODP.

Moreover, if views are developed for the current and the target architecture, a gap analysis can be used to identify required action on the enterprise architecture [11b]. Nevertheless, this procedure is also connected with additional effort.


Sources:

[11b]

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

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

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

[16]

ArchiMate® 3.0 Specification, an Open Group Standard. Standard. The Open Group, 2016.

[Fuh12]

K. Fuhrer. “Enterprise Architecture Management - Zielgruppenspezifische Architektursichten.” In: Informatik Management und Consulting (IM) 4 (2012).