View TRAK:MVp-02 Architecture Description Design Record Viewpoint
Title
MVp-02 Architecture Description Design Record Viewpoint
Version
14
Date
7th February 2018
Overview
The MVp-02 - Architecture Description Design Record Viewpoint is part of the Management Perspective and one of the 24 TRAK Architecture Viewpoints.
The MVp-02 Architecture Description Design Record Viewpoint provides a way of describing the architecture task, any concerns and the results or findings. It is also therefore an aid to portability, exchange and re-use.
It is the specification for the TRAK::MV-02 Architecture Description Design Record architecture view.
Stakeholders Addressed
- Owner of Architecture Task
- User of Architecture Task
- Developer of Enterprise
- Maintainer of Enterprise
- Owner of Enterprise
- Owner of Concept
- User of Concept
- Developer of Concept
- Owner of Solution
- User of Solution
- Maintainer of Solution
- Developer of Solution
- Operator of Solution
- Trainer of Solution
- Acquirer of Solution
- Disposer of Solution
Full size:File:mvp02StakeholderConcern.pdf
It is likely that the developer and builder roles of the architecture task are likely to be performed by the same person.
Covered by TRAK IPR and licenses
Concerns Addressed
Do we understand the scope of the architectural task? What are the issues and findings that resulted?
Covered by TRAK IPR and licenses
Description
Describes the purpose, scope and extent of the architecture task and the architecture description. Describes any findings that arose from the architecture modelling.
Covered by TRAK IPR and licenses
Declared Tuples
ISO 42010 AD Scope
Defining the scope of the architecture description / task:
Usually the following stakeholders will take at least the role of Sponsor although other roles might be relevant to the architectural task:
- Organisation plays Role
- Job plays Role
- Role extends to Architecture Task
Describing how the architecture description addresses the stakeholder concerns:
- Architecture Description has part Architecture Description
- Architecture Description addresses Concern
- Architecture View addresses Concern
- Architecture Description has part Architecture View
and reference documents included:
- Architecture Description Element traces to Document
- Standard governs Architecture Description Element
Architecture Task Findings
ISO 42010 AD Scope +
- Standard governs Architecture Product [to allow version of framework, metamodel etc to be declared]
- Concern about Architecture Description Element
Covered by TRAK IPR and licenses
Optional Tuples
- Organisation governs Project
- Architecture Description Element traces to Argument
- Architecture Description Element traces to Contract
- Architecture Description Element traces to Document
- Architecture Description Element traces to Requirement
- Architecture Description Element traces to Standard
- Claim about Architecture Description Element
- Requirement governs Architecture Product
- Standard governs Architecture Description Element
Covered by TRAK IPR and licenses
If any of these optional metamodel elements are added then the appropriate TRAK Master Architecture View must be provided.
Well-Formedness
ISO 42010 AD Scope
A MV-02 view shall contain:
- at least one stakeholder (represented using Organisation/Job plays Role of
Stakeholder)- exactly one architecture task (
the task)- Role of Stakeholder is connected to
the task(Role extends to Architecture Task)- every stakeholder has at least 1 concern (Role of
Stakeholderhas Concern - stakeholder concern)- every stakeholder Concern is related to at least one thing (Concern about Architecture Description Element)
- every stakeholder concern is addressed by at least one View
- references to any task definition documents (Architecture Description Element traces to Document)
- references to any normative documents - relevant to the task execution (Standard governs Architecture Description Element) including the version of TRAK, for example.
Note: Initially architecture views won’t exist and can be identified by placeholders. These can be replaced by the actual view names or links to the views produced within the architecture description for the task.
Architecture Task Findings
A MV-02 view describing the ISO 42010 AD Scope must exist.
In addition one or more MV-02 views must contain:
- concerns that arise from the task or the analysis (Concern about Architecture Description Element)
- each Concern is related to at least one thing (Concern about Architecture Description Element)
Note that the architecture description will itself contain views that, say, contrast the current and proposed architectures or which identify gaps or shortfalls. In this case the MV-02 must make reference to these.
ISO 42010 AD Documentation
Irrespective of any other uses of the MV-02 the following must be provided within the AD:
- task sponsor
- task scope
- concerns addressed
- assumptions & limitations made
- information sources used
- architect(s)/modeller(s) involved
- findings (concerns arising, observations, conclusions)
- models used & developed for task
- any model dependencies
The MV-02 must at the very least reference all the above information.
Covered by TRAK IPR and licenses
Presentation
Likely to be a mixture of:
- Text document(s). Some modelling tools will allow document-like formatted text to be embedded or attached to architectural elements within the AD.
- block diagram (Architecture Task, Resource, View, Concern, Requirement, Standard, Document = block, TRAK relationship = line with text label and direction indicator)
Architecture Task Scope:
Full size:File:MVp-02 presentation scope.jpg
Architecture Task Findings:
Covered by TRAK IPR and licenses
Examples
Initially the MV-02 can be used to capture the scope of the task through the concerns of the task stakeholder.
Full size: File:MV-02 Architectural Task - Scope.jpg
Views Needed to Construct
See Minimum Allowed View Sets|Minimum Allowed Architecture View Sets|Minimum Allowed View Sets
Covered by TRAK IPR and licenses
Consistency Rules
Comments
ISO/IEC 42010 (IEEE 1471) refers to :
system stakeholders (such as architects, designers, programmers, maintainers, testers, domain engineers, quality assurance staff, configuration management staff, suppliers, and project managers or developers) that use it to assist them to understand, interpret, and analyze architectural descriptions to develop, deliver, and maintain their system
TRAK doesn’t have a Stakeholder metamodel element. Using a MVp-02 to define the scope of the architecture description would therefore require the stakeholders for the task to be identified. This is a Role in TRAK and together with Sponsor (another Role) can be represented using the tuples:
- Job or Organisation plays Role (Sponsor or Stakeholder) extends to Resource
- Job or Organisation plays Role (Sponsor or Stakeholder) has Concern about ... any architecture element
The MV-02 can be used in several different ways:
- As the Master Architecture view for Concern it collects together all the concerns expressed in the architecture description (model).
- To record/capture the nub of the discussions with the sponsor for the task.
- In conjunction with a package diagram it can be used (after 2) to plan what models are needed for the task.
- To outline the views that present the results and thereby provide directed points of navigation into the other views within the architecture description.
- To help document the development of the architecture description for a design record.
- To help document considerations that affect or might affect the portability of the architecture description (in conjunction with the MV-01).
Covered by TRAK IPR and licenses
Configuration History
The TRAK Viewpoints project on Sourceforge (https://sf.net/p/trakviewpoints) maintains a version-controlled repository. The change record is at https://trakviewpoints.svn.sourceforge.net/viewvc/trakviewpoints/trunk/?view=log
Comments
References
- TRAK Enterprise Architecture Framework Viewpoints. https://sf.net/p/trakviewpoints
Other Frameworks
See:
- DNDAF::CV-1 Overview and Summary Information Subview
- DODAF::AV-1 Overview and Summary Information Model NAF::NAV-1 Overview and Summary Information Subview
- MODAF::MODAF:AV-1 Overview and Summary Information View
Category:Framework -> Viewpoint
Category:Management
Category:Architecture Perspective -> Management
Category:Framework -> Specification