TOGAF View and Viewpoints Explained (with examples)

In my TOGAF EA 10 workshop, there is a section where we discuss the concept of views and viewpoints.

To expand on this further, I thought it would be a good idea to explore some examples of views and viewpoints within the context of TOGAF EA 10 (Architecture Development Method). It's important to remember that TOGAF emphasizes that views are what you see (with respect to the stakeholder’s concerns), and viewpoints are how you see it. A viewpoint frames the view (from the perspective of the stakeholder).

Here are some examples, trying to be practical and hopefully relatable:

1. Stakeholder Viewpoint (Focus: Business Value)

●????? View: A diagram showing the dependencies between key business capabilities and the IT systems that support them. This could be a capability map linked to applications.

●????? Purpose: To communicate to business stakeholders how IT investments contribute to business value. It might highlight which capabilities are most impacted by a proposed change.

●????? Concerns Addressed: Business value, return on investment, impact of IT on business operations.

●????? Stakeholders: Business executives, business unit managers, finance department.

2. Technical Viewpoint (Focus: System Internals)

●????? View: A component diagram detailing the internal components of a specific application and their interactions. This might include databases, APIs, and internal modules.

●????? Purpose: To communicate to software engineers and technical architects the internal design of a system. It's used for development, maintenance, and troubleshooting.

●????? Concerns Addressed: System performance, scalability, maintainability, technology choices.

●????? Stakeholders: Software architects, developers, system administrators.

?

3. Operational Viewpoint (Focus: System Behavior)

●????? View: A sequence diagram illustrating the interactions between different systems during a specific business process. This might show the flow of data and control messages.

●????? Purpose: To communicate to operations staff and system administrators how the system behaves during runtime. It's used for monitoring, incident management, and capacity planning.

●????? Concerns Addressed: System availability, performance under load, error handling, security.

●????? Stakeholders: System operators, network engineers, security analysts.

?

4. Data Viewpoint (Focus: Data Structure and Flow)

●????? View: A logical data model showing the key data entities and their relationships within the organization. This could be an Entity-Relationship Diagram (ERD).

●????? Purpose: To communicate to data architects and data analysts the structure and meaning of data within the enterprise. It's used for data governance, data integration, and database design.

●????? Concerns Addressed: Data quality, data consistency, data security, data lineage.

●????? Stakeholders: Data architects, data analysts, database administrators.

?

5. Security Viewpoint (Focus: Security and Risk)

●????? View: A diagram showing the security zones and firewalls within the network architecture. This might highlight vulnerabilities and potential attack vectors.

●????? Purpose: To communicate to security architects and security analysts the security posture of the enterprise. It's used for risk assessment, security planning, and incident response.

●????? Concerns Addressed: Data breaches, unauthorized access, denial-of-service attacks, compliance with security regulations.

●????? Stakeholders: Security architects, security analysts, IT security team.

?

Key Considerations:

●????? Multiple Viewpoints for a Single View: You could use the same diagram (the view) but interpret it through different viewpoints. For example, the capability map could be used with a cost viewpoint (showing cost of IT supporting each capability) or a risk viewpoint (showing the risk associated with IT failures impacting each capability).

●????? Tailoring: The level of detail in a view should be tailored to the specific stakeholder and their concerns. A business executive doesn't need to see the intricacies of the database schema.

●????? Consistency: While views are tailored, they should be consistent with the overall architecture. Inconsistencies can lead to confusion and errors.

By using viewpoints to frame views, architects can effectively communicate complex architectural information to a wide range of stakeholders, ensuring that everyone understands the architecture and its implications. This is a core principle of TOGAF's approach to Enterprise Architecture.

Thanks again to GenAI for doing the heavy lifting!