To what extent does a TRAK-compliant architecture description comply with ISO/IEC/IEEE 42010:2011?

[a Concern ] To what extent does a TRAK-compliant architecture description comply with ISO/IEC/IEEE 42010:2011? ()

Created:	14/03/2014 07:38:56
Modified:	31/07/2015 15:35:55
Author:	Nic Plum
Keywords:
Object Identifier:	{A5C3A9F7-C725-44dd-8210-7F3768FE874F}
Advanced:
Appears In:	MV-02 Architecture Task - Scope - TRAK-Conforming Architecture Description, MV-02 Architecture Task - Scope - Stakeholders & Their Concerns

To what extent does a TRAK-compliant architecture description comply with ISO/IEC/IEEE 42010:2011? Although TRAK has been deliberately designed to meet ISO/IEC/IEEE 42010 there are requirements in the standard that affect architecture descriptions. As far as is possible the intent is that in conforming to TRAK an architecture description will automatically comply with the international standard. An initial comparison was done at the Final Committee Draft version of the current (2011) standard but there is a concern that there might be one or more requirements that are not fully met or not within the scope of an architecture framework like TRAK to specify and therefore some additional work might be needed by an architect of a TRAK-compliant architecture description in order to comply. Until a detailed line by line comparison is made the amount of this possible work is unquantified and the degree of compliance of the AD is therefore uncertain.

Associations From
Tagged Values
Other Links

Element
«Role» Builder of a TRAK Architecture Description Role «has»
Details:
«Job» Chief Architect of TRAK Job «has»
Details:
«Role» User of TRAK Role «has»
Details:

Tag	Value
AD exchange element owning ID	Not Specified
Details: Default: Not Specified Description: The unique identifier for the architectural element belonging to the AD element owning organisation.
AD exchange element owning organisation	Eclectica Systems Ltd.
Details: Description: The name of the owning organisation of the architectural description element.
AD exchange element recipient ID	Not Specified
Details: Default: Not Specified Description: The unique identifier for the architectural description element belonging to the organisation receiving the architectural description element.
AD exchange element recipient element name	Not Specified
Details: Default: Not Specified Description: The name of the architectural description element in the recipient organisation
concern ID	1872
Details: Description: Unique identifier for the Concern.
concern scope	Architecture Description
Details: Values: Architecture,Architecture Description,Architecture Framework,Task,Not Specified Default: Not Specified Description: The scope or type of concern. Enumerated list: - 'Architecture' - 'Architecture Description' - 'Architecture Framework' - 'Task' - 'Not Specified' Default value='Not Specified' Used to identify whether the concern applies to the architecture being described, the description of the architecture, the architecture framework used or the task requiring this.
concern status	Open
Details: Values: Open,Closed,Not Specified Default: Open Description: The status of the concern. Enumerated list - allowed values: - 'Open' - 'Closed' - 'Not Specified' default value= 'Open' Provides means to filter and sort concerns.
element author	Nic Plum
Details: Description: The name of the creator of the AD element.
pm codeword	NONE
Details: Default: NONE Description: A codeword is another mechanism to limit distribution - only those with the need to know and the codeword have access to the element
pm commercial	NONE
Details: Values: COMMERCIAL IN CONFIDENCE,COMMERCIAL IN SECRET,IN STRICT CONFIDENCE Default: NONE Description: Commercial privacy marking
pm descriptor	NONE
Details: Values: NONE,BUDGET,COMMERCIAL,IN CONFIDENCE,INVESTIGATION,MANAGEMENT,MEDICAL,PERSONAL,PERSONAL DATA,POLICY & STRATEGY Default: NONE Description: A qualifier used with the protective marking to denote the type of information, sensitivity or need to protect e.g. Personal. Commercial. i.e. combination might be PROTECT - PERSONAL. Enumerated - allowed values: - 'NONE' - 'BUDGET' - 'COMMERCIAL' - 'IN CONFIDENCE' - 'INVESTIGATION'
pm marking	NOT PROTECTIVELY MARKED
Details: Values: NOT PROTECTIVELY MARKED,PROTECT,RESTRICTED,CONFIDENTIAL,SECRET,TOP SECRET Default: NOT PROTECTIVELY MARKED Description: An enumerated list - used to indicate the severity or impact of the loss of the item so marked. In the UK it takes the values: - 'NOT PROTECTIVELY MARKED' - 'PROTECT' - 'RESTRICTED' - 'CONFIDENTIAL' - 'SECRET' - 'TOP SECRET' and may be further qualified through ownership, nationality caveat, descriptor and codeword.
pm marking owner	NONE
Details: Default: NONE Description: The owner of the protective marking who has the authority to sanction release or lower the protective marking classification. It is used in conjunction with the protective marking, usually as the prefix e.g. NHS PROTECT, TFL CONFIDENTIAL, or as a national authority - UK RESTRICTED.
pm national caveat	NONE
Details: Default: NONE Description: A restriction of the audience who can see the element by nationality e.g. UK EYES ONLY would restrict the potential audience to UK nationals. This is not the same as the protective marking owner i.e. UK PROTECT does not restrict the audience and therefore the combination would be for example UK EYES ONLY, UK PROTECT
priority	Not Specified
Details: Values: High,Medium,Low,Not Specified Default: Not Specified Description: Priority attached to the concern. Enumerated list - allowed values: - 'High' - 'Medium' - 'Low' - 'Not Specified' Default value = 'Not Specified' A means of subjectively ranking a concern.

Object	Type	Connection	Direction	Notes
«Architecture View» MV-03 ISO/IEC/IEEE 42010:2011 Section 5.6 Architecture Models	Architecture View	Dependency	From
«Architecture View» MV-04 TRAK-Conforming AD Claims vs ISO/IEC/IEEE 42010:2011 Section 5.8.1 Architecture Rationale-Recording	Architecture View	Dependency	From
«Document» TRAK. Enterprise Architecture Framework. TRAK vs ISO/IEC/IEEE 42010	Document	Abstraction	To
«Architecture View» MV-04 A TRAK-Conforming Architecture Description Meets...	Architecture View	Dependency	From
«Architecture View» MV-02 Architecture Task - Findings - TRAK-Conforming Architecture Description	Architecture View	Dependency	From
«Architecture View» MV-04 TRAK-Conforming AD Claims vs ISO/IEC/IEEE 42010:2011 Section 5.6 Architecture Models	Architecture View	Dependency	From
«Architecture View» MV-03 ISO/IEC/IEEE 42010:2011 Section 5.2 Architecture Description Identification and Overview - Requirements	Architecture View	Dependency	From
«Architecture View» MV-04 TRAK-Conforming AD Claims vs ISO/IEC/IEEE 42010:2011 Section 5.5 Architecture Views - Requirements d)	Architecture View	Dependency	From
«Architecture View» MV-03 ISO/IEC/IEEE 42010:2011 Section 5.5 Architecture Views - Requirements	Architecture View	Dependency	From
«Architecture View» MV-03 ISO/IEC/IEEE 42010:MV-03 ISO/IEC/IEEE 42010:2011 Section 5.7 Architecture Relations Requirements	Architecture View	Dependency	From
«Architecture Description» TRAK.. Architecture Description - Summary. Conformance Assessment - ISO/IEC/IEEE 42010:2011	Architecture Description	Dependency	From
«Architecture View» MV-04 TRAK-Conforming AD Claims vs ISO/IEC/IEEE 42010:2011 Section 5.4 Architecture Viewpoints Requirements	Architecture View	Dependency	From
«Architecture View» MV-04 TRAK-Conforming AD Claims vs ISO/IEC/IEEE 42010:2011 Section 5.8.2 Decision Recording	Architecture View	Dependency	From
«Architecture View» MV-04 TRAK-Conforming AD Claims vs ISO/IEC/IEEE 42010:2011 Section 5.5 Architecture Views - Requirements a)	Architecture View	Dependency	From
«Architecture View» MV-04 TRAK-Conforming AD Claims vs ISO/IEC/IEEE 42010:2011 Section 5.7.1 Consistency Within an Architecture Description Requirements	Architecture View	Dependency	From
«Architecture View» MV-04 TRAK-Conforming AD Claims vs ISO/IEC/IEEE 42010:2011 Section 5.5 Architecture Views - Requirements b) and c)	Architecture View	Dependency	From
«Architecture View» MV-04 TRAK-Conforming AD Claims vs ISO/IEC/IEEE 42010:2011 Section 5.2 Architecture Description Identification and Overview Requirements	Architecture View	Dependency	From
«Architecture View» MV-04 TRAK-Conforming AD Claims vs ISO/IEC/IEEE 42010:2011 Section 5.7.3 Correspondence Rules Requirements	Architecture View	Dependency	From
«Architecture View» MV-03 ISO/IEC/IEEE 42010:2011 Section 5 Architecture Descriptions	Architecture View	Dependency	From
«Architecture View» MV-04 TRAK-Conforming AD Claims vs ISO/IEC/IEEE 42010:2011 Section 5.3 Identification of Stakeholders and Concerns	Architecture View	Dependency	From
«Architecture View» MV-03 ISO/IEC/IEEE 42010:2011 Section 5.3 Identification of Stakeholders and Concerns - Requirements	Architecture View	Dependency	From
«Architecture View» MV-03 ISO/IEC/IEEE 42010:2011 Section 5.8 Architecture Rationale	Architecture View	Dependency	From
«Architecture View» MV-03 ISO/IEC/IEEE 42010:2011 Section 5.4 Architecture Viewpoints - Requirements	Architecture View	Dependency	From
«Architecture View» MV-01 Architecture Description Dictionary - Conformance Assessment ISO/IEC/IEEE 42010:2011	Architecture View	Dependency	From
«Architecture View» MV-04 TRAK-Conforming AD Claims vs ISO/IEC/IEEE 42010:2011 Section 5.7.2 Correspondences Requirements	Architecture View	Dependency	From
ISO/IEC/IEEE42010:2011 Systems and Software Engineering - Architecture Description	Standard	Abstraction	To