Key takeaways
- A system has one or more stakeholders, each with concerns.
- Concern ≠ requirement: the concern is decomposed into requirements.
- Viewpoint = template; view = instance built from models.
- Viewpoints are selected before views are built.
- Vision, ADD, and Communications Plan all rely on concerns.
A five-link chain
A system has one or more stakeholders: individuals, teams, organizations, or classes of these, with an interest in the system. Each one has concerns, meaning areas of interest: performance, reliability, security, distribution, evolvability… Concerns can determine whether the system is acceptable.
A concern is not a requirement. It is the root of a decomposition: it is then translated into requirements, which represent it in the architecture. A security architect, for example, cares about authentication, authorization, audit, or asset protection; these concerns will become verifiable requirements.
The viewpoint defines the perspective: how to build and use a view, which information, which modeling techniques, and why (purpose, audience). The view is the resulting representation: it selects parts of one or more models to show stakeholders that their concerns are addressed.
- Stakeholder → has concerns
- Concern → decomposed into requirements
- Viewpoint → template for a set of concerns
- View → instance of the template, made of parts of models
- Architecture Description → set of views and models
The working method
Order matters: the architect first selects the viewpoints, then builds the corresponding views. Just as a building architect produces floor plans, elevations, and wiring diagrams for different audiences, the enterprise architect produces business, information systems, and technology views for those concerned by these aspects.
The system lives in an environment that determines the influences on it: technical, business, operational, organizational, political, economic, legal, regulatory, ecological, social. A Model Kind sets the conventions for one type of modeling.
Where this appears in deliverables
Key deliverables build in this chain. The Architecture Vision describes the problem in terms of stakeholders and their concerns. The Architecture Definition Document includes, for each domain, views matching the selected viewpoints and addressing key concerns. The Communications Plan groups stakeholders by their information needs. When an audience finds a deliverable unsuitable, the right response is to produce a view from a viewpoint suited to its concerns, not to change the architecture. The same model can thus feed several views, each aimed at a different audience.
TERMS TO KNOW
The terms, in context.
- Concern
- Area of interest of one or more stakeholders in a system, root of requirements.
- Architecture viewpoint
- Perspective setting how to build and use a view, with which techniques, and why.
- Architecture view
- Representation of a system from a set of concerns, made of parts of models.
- Environment
- Context that determines all the influences acting on a system.
- Model Kind
- Set of conventions specific to one type of modeling.