Navigating Complexity: Stakeholders, Viewpoints, and Views in Enterprise Architecture

Introduction

Establishing and maintaining a coherent Enterprise Architecture (EA) is a complex task due to the involvement of diverse stakeholders with varying backgrounds and notations. To manage this complexity, researchers initially focused on defining architectural frameworks to classify and position different architectural descriptions relative to each other, such as the Zachman framework.

Architecture frameworks provide general guidance for delivering Architecture Descriptions along with a process. The ArchiMate language, as a modeling notation, offers detailed insights into the structure and coherence of different architectures, complementing and supporting these frameworks.

The ArchiMate language allows architects and stakeholders to use their own views on EA. Views are specified by viewpoints, which define abstractions on the set of models representing the EA. Each viewpoint targets a particular type of stakeholder and addresses specific concerns. Viewpoints can isolate certain aspects or relate multiple aspects, providing a flexible approach to EA modeling.

The TOGAF framework describes a taxonomy of views for different stakeholder categories and provides guidelines for developing and using viewpoints and views in EA models. However, it is important to note that viewpoints and views are interrelated and often best describe architecture when combined with their underlying inter-dependency relationships. Despite their utility, viewpoints and views are partial depictions of the system, restricting the whole architecture to a limited number of aspects.

Stakeholders and Concerns

This section introduces a method for using the ArchiMate language to systematically address stakeholder concerns through the viewpoint mechanism. This mechanism conforms to the ISO/IEC 42010 standard, which provides a model for Architecture Description. Key elements in this model include stakeholders, concerns, viewpoints, and views, as depicted in Figure below:

The diagram above titled “Conceptual Model of an Architecture Description” illustrates the relationships between key elements involved in describing an architecture, conforming to the ISO/IEC 42010 standard. This model helps in systematically addressing stakeholder concerns through the use of viewpoints and views. Here’s a detailed explanation of the diagram:

1. System-of-Interest:
   • This is the system that is being described by the architecture.
   • It exhibits the architecture and has interests in stakeholders.
2. Stakeholder:
   • A stakeholder is an individual, team, or organization with interests in the system-of-interest.
   • Stakeholders have concerns that need to be addressed by the architecture.
   • They identify the architecture description, architecture rationale, and architecture views.
3. Concern:
   • Concerns are the interests or issues that stakeholders have regarding the system-of-interest.
   • Concerns are framed by architecture viewpoints and addressed by architecture views.
4. Architecture Viewpoint:
   • A viewpoint is a specification for a single view, defining the stakeholders whose concerns are framed and the guidelines for constructing and interpreting the view.
   • Viewpoints frame concerns and govern architecture views.
   • They are associated with model kinds, which govern architecture models.
5. Architecture View:
   • A view is a representation of the architecture that addresses one or more concerns of stakeholders.
   • Views are governed by architecture viewpoints and express the architecture description.
   • They are derived from architecture models.
6. Architecture Model:
   • An architecture model is a representation of aspects of the architecture using specific model kinds.
   • Models govern architecture views and are part of the architecture description.
7. Model Kind:
   • Model kinds are types of models used to represent different aspects of the architecture.
   • They govern architecture models.
8. Architecture Description:
   • The architecture description is the collection of architecture views, models, and other information that expresses the architecture of the system-of-interest.
   • It expresses the architecture and is identified by stakeholders.
   • It includes correspondence rules and rationale.
9. Architecture Rationale:
   • The rationale explains the reasoning behind the architecture decisions.
   • It is part of the architecture description and is identified by stakeholders.
10. Correspondence Rule:
    • Correspondence rules define the relationships between different views and models within the architecture description.
    • They ensure consistency and coherence across the architecture description.
11. Correspondence:
    • Correspondences are the actual relationships between different views and models as defined by the correspondence rules.
    • They are part of the architecture description.

Relationships

• Identifies: Stakeholders identify the architecture description, architecture rationale, and architecture views.
• Has Interests In: The system-of-interest has interests in stakeholders.
• Frames: Architecture viewpoints frame concerns.
• Addresses: Architecture views address concerns.
• Governs: Architecture viewpoints govern architecture views, and model kinds govern architecture models.
• Expresses: The architecture description expresses the architecture.
• Exhibits: The system-of-interest exhibits the architecture.

This conceptual model helps in understanding how different elements interact to describe an architecture, ensuring that stakeholder concerns are systematically addressed through well-defined viewpoints and views.

The ArchiMate language, with its viewpoint mechanism, assists architects in defining and classifying governing viewpoints. This mechanism helps architects construct and design views for stakeholder communication.

Views and Viewpoints

Views are an ideal mechanism for conveying information about specific architecture areas. A view is a part of an Architecture Description that addresses related concerns and is tailored for specific stakeholders. It is specified by a viewpoint, which prescribes the concepts, models, analysis techniques, and visualizations provided by the view. Essentially, a view is what you see, and a viewpoint is where you are looking from.

An Architecture Description includes one or more architecture views, each addressing stakeholder concerns. An architecture view expresses the system’s architecture according to a viewpoint, which frames concerns and establishes conventions for constructing, interpreting, and analyzing the view.

Viewpoints focus on particular aspects and layers of the architecture, determined by stakeholder concerns. What is visible from a viewpoint depends on the argumentation regarding a stakeholder’s concerns. Viewpoints enable communication about certain aspects and layers of an architecture, allowing for bi-directional feedback between architects and stakeholders. The scope of the viewpoint and the relevance to stakeholder concerns determine what elements and relationships appear in a view.

Viewpoint Mechanism

Architects deal with various stakeholders and concerns. The viewpoint mechanism helps select the right viewpoints by providing a framework based on purpose and content. This framework aids in defining and classifying viewpoints, as shown in Figure below.

The architect communicates with stakeholders to understand and document their concerns. The viewpoint mechanism identifies the purpose and content, defining and classifying the viewpoint, which governs the view’s construction and design. The view, governed by the viewpoint, addresses stakeholder concerns.

Creating an ArchiMate viewpoint involves two steps:

1. Selecting relevant concepts from the ArchiMate metamodel based on the information needed to address stakeholder concerns.
2. Defining a representation to depict these concepts in a way understood by stakeholders, which could be a diagram, catalog, matrix, or other visualization.

Applying this viewpoint to an architecture model selects and depicts the relevant parts of the architecture according to the chosen concepts and representation.

Defining and Classifying Viewpoints

The ArchiMate language helps define and classify viewpoints based on purpose and content relevant to stakeholder concerns. The purpose dimension is supported by three categories:

• Designing: Supports architects and designers in the design process, typically using diagrams like UML.
• Deciding: Assists managers in decision-making by offering insights into cross-domain architecture relationships through projections, intersections, and analytical techniques.
• Informing: Helps inform stakeholders about the EA to achieve understanding, obtain commitment, and convince adversaries, using illustrations, animations, and other informative media.

The content dimension uses the ArchiMate Core Framework to select relevant aspects and layers, supported by three categories:

• Details: Focuses on one layer and one aspect, typically for stakeholders like software engineers or process owners.
• Coherence: Spans multiple layers or aspects, enabling stakeholders to focus on architecture relationships, suitable for operational managers.
• Overview: Addresses multiple layers and aspects, typically for Enterprise Architects and decision-makers like CEOs and CIOs.

Creating the View

With a governing viewpoint, the architect can create and design a view containing elements and relationships from the ArchiMate metamodel. The architect designs an appropriate representation for these elements, suitable for the stakeholders and concerns being framed. The view does not have to be visual or graphical; it can use various representations based on the attributes of elements and relationships, such as color-coded heat maps.

Example Viewpoints

The final section provides examples of viewpoints, illustrating how the viewpoint mechanism can be applied to create views that address specific stakeholder concerns. These examples demonstrate the practical application of the viewpoint mechanism in real-world scenarios, helping architects and stakeholders effectively communicate and understand the Enterprise Architecture.

Organization Viewpoint Example

The figure below shows an ArchiMate diagram created under the Organization Viewpoint. By applying a viewpoint you are allowed to draw an ArchiMate diagram with a subset of ArchiMate elements and relationships, as defined under the viewpoint.

Organization Viewpoint example

Business Process Cooperation Viewpoint Example

The figure below shows an ArchiMate diagram created under the Business Process Cooperation Viewpoint. By applying a viewpoint you are allowed to draw an ArchiMate diagram with a subset of ArchiMate elements and relationships, as defined under the viewpoint.

Business Process Cooperation Viewpoint example

Conclusion

The ArchiMate language, with its viewpoint mechanism, offers a structured and flexible approach to managing the complexity of Enterprise Architecture. By defining and classifying viewpoints based on stakeholder concerns, architects can create views that effectively communicate the architecture, ensuring coherence and understanding among all stakeholders.