2. ArchiMate Viewpoints

Views are an ideal mechanism to purposefully convey information about architecture areas. In general, a view is defined as a part of an architecture description that addresses a set of related concerns and is addressed to a set of stakeholders. A view is specified by means of a viewpoint, which prescribes the concepts, models, analysis techniques, and visualizations that are provided by the view. Simply put, a view is what you see and a viewpoint is where you are looking from.

Viewpoints are a means to focus on particular aspects of the architecture. These aspects are determined by the concerns of a stakeholder with whom communication takes place. What should and should not be visible from a specific viewpoint is therefore entirely dependent on the argumentation with respect to a stakeholder’s concerns.

Viewpoints are designed for the purpose of communicating certain aspects of an architecture. The communication enabled by a viewpoint can be strictly informative, but in general is bi-directional. The architect informs stakeholders, and stakeholders give their feedback (critique or consent) on the presented aspects. What is and what is not shown in a view depends on the scope of the viewpoint and on what is relevant to the concerns of the stakeholder. Ideally, these are the same; i.e., the viewpoint is designed with specific concerns of a stakeholder in mind. Relevance to a stakeholder’s concern, therefore, is the selection criterion that is used to determine which objects and relationships are to appear in a view.

The following are examples of stakeholders and concerns as a basis for the specification of viewpoints:

• End user: For example, what are the consequences for his work and workplace?
• Architect: What is the consequence for the maintainability of a system, with respect to corrective, preventive, and adaptive maintenance?
• Upper-level management: How can we ensure our policies are followed in the development and operation of processes and systems? What is the impact of decisions (on personnel, finance, ICT, etc.)?
• Operational manager: Responsible for exploitation or maintenance: For example, what new technologies are there to prepare for? Is there a need to adapt maintenance processes? What is the impact of changes to existing applications? How secure are my systems?
• Project manager: Responsible for the development of new applications: What are the relevant domains and their relationships? What is the dependence of business processes on the applications to be built? What is their expected performance?
• Developer: What are the modifications with respect to the current situation that need to be done?