What is a Viewpoint?
In accordance with ISO/IEC/IEEE 42010, the International Standard for Architecture Description a viewpoint is a specification for the construction and interpretation of an architecture view and specifies:-
- the stakeholder concerns that the view is intended to address - this helps prevent spaghetti where there are so many different elements and relationships that it isn't onbvious what the purpose of the view actually is
- the notation and types of model used
- consistency rules within the architecture description as a whole (because any element may appear in many other views)
In the formal language of the standard a viewpoint is:
'work product establishing the conventions for the construction, interpretation and use of architecture views to frame specific system concerns'
Important: This is a precise and defined use of the term 'viewpoint' - it does not therefore refer to a collection of views or a perspective from which the architecture description is viewed. A viewpoint is something the meets the requirements of ISO/IEC/IEEE 42010.
Further information on ISO/IEC/IEEE 42010 is available at:-
- iso-architecture.org - Conceptual Model of Architecture Description
- Wikipedia - ISO/IEC 42010
TRAK Viewpoints
Each TRAK Viewpoint has a standardised structure which is designed to meet the requirements of ISO/IEC/IEEE 42010. The conformance of TRAK as an architecture framework and any TRAK-conforming architecture description against the international standard is described using a TRAK architecture description (which uses MVp-02 Architecture Description Design Record, MVp-03 Requirements and Standards and MVp-04 Assurance views).
TRAK viewpoint definitions and TRAK views are based on tuples i.e. block - relationship - block.
An example of a tuples is Standard. ISO/IEC/IEEE 42010 has part Requirement. '6 Architecture Frameworks and Architecture Description Languages'.
The reason that TRAK uses tuples is:-
- tuples form natural language sentences so anyone can read what they see - you don't need to be a technical what-ML expert. This is one of the reasons why TRAK requires everything to be explicitly named on a view (the other is that this is needed for everyone to read in a consistent way - no guessing or making assumptions about what the architect meant. How many diagrams have you seen with unlabelled lines or rectangles nested inside rectangles ...?).
- a solitary block with no relationship is not a description of any architecture - this requires at least a block and a relationship (to itself) and hence the smallest unit of architecture description is block - reelationship - block
- it is impossible to unambiguously specify a viewpoint or view content using blocks only
- tuples are the basis for assertions and defining meaning and hence TRAK views can be tested, assertions checked and are easy to represent using graphs and semantic notations
- tuples define paths which are the basis for extracting information from your model and allow consistency checks to be specified and verified
The TRAK Viewpoints are listed below.
TRAK viewpoint identifiers always have 'Vp' whereas a TRAK View identifier just has a 'V' e.g. SVp-01 identifies the Solution Structure Viewpoint whereas a SV-01 refers to a Solution Structure View. Links provide more information on the views and examples.
In accordance with ISO/IEC/IEEE 42010 each TRAK Viewpoint addresses a set of concerns. These are the typical questions or concerns that a stakeholder might have i.e. if you were concerned with understanding the structure of the system of interest or the membership of an organisation youd would select the SVp-01 Solution Structure Viewpoint.
The typical concerns addressed by each TRAK Viewpoint are listed separately.
Enterprise Perspective
The Enterprise perspective describes the enterprise in terms of its goals and the enduring capabilities that are required to support the goals.These are high level business needs that everything else contributes to and form part of the long term strategic objectives that need to be managed.
- EVp-01 Enterprise Goal Viewpoint
- EVp-02 Capability Hierarchy Viewpoint
- EVp-03 Capability Phasing Viewpoint
Concept Perspective
The Concept Perspective describes the solution-free (logical) view of what is needed in response to the capabilities required by the enterprise in the Enterprise Perspective. It describes the logical connection of nodes, for example a service control centre, to other nodes with no recognition of how this might be realised either by organisation or technology. It also implies no particular part of a life cycle - it covers everything from concept to disposal ('lust to dust'!) - time is only introduced deliberately in either the Enterprise and / or Procurement perspectives. Any normative documents or standards applied to the concept and described in the Management Perspective are likely to be technology-free - they won't describe 'the how'.
- CVp-01 Concept Need Viewpoint
- CVp-03 Concept Item Exchange Viewpoint
- CVp-04 Concept Activity to Capability Mapping Viewpoint
- CVp-05 Concept Activity Viewpoint
- CVp-06 Concept Sequence Viewpoint
Procurement Perspective
The Procurement Perspective provides a top level view of the procurement of a solution to satisfy the enterprise capability needs outlined in the Enterprise Perspective and developed in the concept perspective. It provides a way of showing how projects deliver the solutions described in the Solution Perspective to provide capability. It provides a way of showing time dependency between projects owing to dependencies on systems being introduced or removed and is an essential for investigating capability gaps. It also provides a way of showing how responsibility boundaries change over time.
- PrVp-01 Procurement Structure Viewpoint
- PrVp-02 Procurement Timeline Viewpoint
- PrVp-03 Procurement Responsibility Viewpoint
Solution Perspective
The Solution Perspective describes the solution - whether proposed or realised. It covers the parts of 'systems' whether human or machine, their exchanges and protocols. It describes how organisations and equipments are organised and governed.The Solution Per- spective describes how the logical requirements outlined in the Concept Perspective are realised and shows how the solution(s) realise the capabilities needed by the enterprise and described in the Enterprise Perspective.
- SVp-01 Solution Structure Viewpoint
- SVp-02 Solution Resource Interaction Viewpoint
- SVp-03 Solution Resource Interaction to Function Mapping Viewpoint
- SVp-04 Solution Function Viewpoint
- SVp-05 Solution Function to Concept Activity Mapping Viewpoint
- SVp-06 Solution Competence Viewpoint
- SVp-07 Solution Sequence Viewpoint
- SVp-11 Solution Event Causes Viewpoint
- SVp-13 Solution Risk Viewpoint
Management Perspective
The Management Perspective describes the architectural task and those relationships that are common across other perspectives. It provides ways of defining the scope and find- ings of the architectural task - structuring the approach and modelling. The Management Perspective provides ways of describing the requirements and normative standards that apply and the assurance against these based on claims, arguments and evidence.
It provides supporting information to aid the portability and understanding of the architecture description produced as a result of the task.
As the Management Perspective underpins all other perspectives all roles are beneficiaries including the lay reader (or external third party) to the architecture description.
- MVp-01 Architecture Description Dictionary Viewpoint
- MVp-02 Architecture Description Design Record Viewpoint
- MVp-03 Requirements & Standards Viewpoint
- MVp-04 Assurance Viewpoint
Modification Date: September 24, 2023