TRAK Architecture Viewpoints

• SourceForge Project Summary

trakviewpoints project

• Introduction
• What is an Architecture Viewpoint?
• Architecture Viewpoints & Views
  • Architecture Viewpoint Concerns
  • Enterprise Perspective
  • Concept Perspective
  • Procurement Perspective
  • Solution Perspective
  • Management Perspective
• Why Use Triples?
• Modelling TRAK Viewpoints
• Open Source
• Download
• Get Support / Join
• Discussion Forums
• Report Bug
• Support Request
• Keep Informed

TRAK SourceForge Projects

Definition

• TRAK
• TRAK Metamodel
• TRAK Viewpoints

Implementation

• Implementations of TRAK
• UML Profile for TRAK
• Rail Symbols
• MDG Technology for TRAK (Sparx Enterprise Architect)
• TRAK MooD 2010 Template
• TRAK OmniGraffle Stencil
• TRAK Visio Template

TRAK Information

• TRAK - Important Ideas
• TRAK FAQs (SF - trak project)
• Projects Using TRAK
• Demo Model
• Supporting Links
• Blog - "The Residual World"
• TRAK Community Wiki
• Community Discussion Forums

 

 

 

 

 

 

 

 

 

 

 

EVp-02 Capability Hierarchy

This page reproduces part of the EVp-02 Capability Hierarchy architecture viewpoint definition from the specification - TRAK00001. TRAK. Architecture Framework. Viewpoints. The page content is therefore subject to the same GNU Free Documentation License terms and conditions - see https://www.gnu.org/licenses/fdl-1.3.html

Most of the content is produced from a model of TRAK produced using a different set of architecture viewpoints!

Version

The TRAK EVp-02 Capability Hierarchy architecture viewpoint is one of 24 architecture viewpoints defined in TRAK00001. TRAK. Architecture Framework. Viewpoints - current release is dated 10 July 2024.

Summary

The TRAK EVp-02 Capability Hierarchy architecture viewpoint defines the requirements for the TRAK EV-02 Capability Hierarchy architecture view. This involves allowed content and minimum acceptable content ('well-formedness' criteria). The TRAK00001. TRAK. Architecture Framework. Viewpoints specification also defines consistency rules that apply to a set of architecture views (an Architecture Description).

The TRAK EVp-02 Capability Hierarchy architecture viewpoint content is summarised under the following sections:

• stakeholder concerns
• description
• allowed content
• well-formedness criteria
• presentation methods
• examples
• views needed to construct
• consistency rules
• comments

The TRAK Architecture Viewpoints specification provides are complete definition not only of the EVp-02 Capability Hierarchy architecture viewpoint but considerations for the architecture description formed from a set of architecture views.

Something needs fixing?

Return to the Architecture Viewpoints list or Summary of Architecture Viewpoint Concerns.

Description

Describes the capabilities required by the Enterprise / Enterprise Goal(s) and dependencies on other Capabilities.

Allowed Content

TRAK architecture view content is defined in terms of triples - Node - connector - Node e.g. 'Capability depends on Capability' that form short statements about the thing(s) being described.

'Capability depends on Capability' is a Statement or Assertion in a EV-02 Architecture View

The rationale and theory for the allowed content of an architecture view is explained separately.

Subject Statements (Triples)

These are statements (triples) that describe the subject of the EV-02 Capability Hierarchy architecture view. Specifically these statements address the concerns for this EVp-02 Capability Hierarchy architecture viewpoint. These form the basis for the well-formedness section of the EVp-02 Capability Hierarchy architecture viewpoint.

There are 5 possible subject statements in total which include 4 metamodel elements ( Capability , Enterprise , Enterprise Goal and Metric ).

Return to the top of the Capability Hierarchy page.

Optional Statements (Triples)

These optional statements (triples) for the EV-02 Capability Hierarchy architecture view provide useful context with respect to a subject or universally allowed statements involving the subject or object (start or finish) elements in the Subject Statements (triples).

Universal statements may be added to any TRAK architecture view and describe typical concepts such as compliance or traceability:

• ... traces to Argument, Contract, Requirement, Document or Standard
• ... satisfies Contract, Requirement, Document or Standard
• Concern or Claim about ...
• Contract, Requirement, Document or Standard governs ...

'Enterprise traces to Document' - an optional statement or assertion for the EV-02 Architecture View

These statements address the concerns of their respective architecture viewpoint and will have been created first on these other architecture views.

There are 54 possible statements which may be used to augment the EV-02 Capability Hierarchy architecture view, split into 6 groups:

• Context
• Universal - Applicable Requirements
• Universal - Assurance
• Universal - Concern Identified
• Universal - Requirement Compliance
• Universal - Traceability or Reference

Return to the top of the Capability Hierarchy page.

Well-Formedness Criteria

This web site is a partial representation of the TRAK Architecture Viewpoints Specification

Well-formedness criteria define the minimum acceptable view content based on the subject statements (triples). These criteria are not included in this web page.

Please refer to the Well Formedness section within the EVp-02 Capability Hierarchy architecture viewpoint definition in the TRAK00001. TRAK. Architecture Framework. Viewpoints specification (10 July 2024).

Presentation Methods

The EV-02 Capability Hierarchy architecture view may use any of following means to the statements (triples):

• block diagram (blocks to represent Enterprise, Capability, Metric and Enterprise Goal)

Note that a textual presentation is acceptable for any TRAK architecture view.

Examples

Example EV-02 Capability Hierarchy Architecture View - Part of the UK Government CONTEST Counter-Terrorism Strategy

An example of a TRAK EV-02 Capability Hierarchy architecture view describing capabilities required for the UK government CONTEST counter-terrorism strategy.

The Government’s counter-terrorism strategy, CONTEST, was first established in 2003. On Tuesday 18 July, the government published CONTEST 2023 (the fourth iteration).

The strategy’s objective continues to be to reduce the risk from terrorism to the UK, its citizens and interests overseas so that people can go about their lives freely and with confidence.

The core CONTEST framework – Prevent, Pursue, Protect and Prepare – helps to organise and articulate the variety of work required, through CONTEST, to keep the public safe from terrorism.

• Prevent: Stop people from becoming terrorists or supporting terrorism.
• Pursue: Stop terrorist attacks happening in this country or against UK interests overseas.
• Protect: Strengthen our protection against a terrorist attack.
• Prepare: Minimise the impact of an attack and reduce the likelihood of further attacks.

CONTEST 2023 Factsheet

Note that the Prevent, Pursue, Protect and Prepare capabilities could be applied to any form of policing required by an organisation i.e. not just counter-terrorism.

Produced using (Sparx Systems Enterprise Architect UML modelling tool in conjunction with the MDG for TRAK plugin (https://sf.net/p/mdgfortrak.)

Views Needed to Construct

This web site is a partial representation of the TRAK Architecture Viewpoints Specification

Since a triple originates in a particular architecture view if there is a subsequent architecture view that uses the same triple it need not be created. Similarly you might wish to create a triple but in order to do so the node element has first to be created in its originating architecture view.

For example, you cannot describe the functionality of an element without first defining the element having that functionality. These dependencies between architecture views create a natural sequence or order in which architecture views are created by virtue of their content. These criteria are not yet included in this web page.

Please refer to the Views Needed in Order to Construct section within the EVp-02 Capability Hierarchy architecture viewpoint definition in the TRAK00001. TRAK. Architecture Framework. Viewpoints specification (10 July 2024).

Consistency Rules

This web site is a partial representation of the TRAK Architecture Viewpoints Specification

Consistency rules define rules applied to keep the collection of architecture views consistent and also to keep the logic formed by the statements using triples consistent. These criteria are not included in this web page.

Please refer to the Consistency Rules section within the EVp-02 Capability Hierarchy architecture viewpoint definition in the TRAK00001. TRAK. Architecture Framework. Viewpoints specification (10 July 2024).

Comments

The EV-02 Capability Hierarchy architecture view is the master source (origin) on which you first create the following elements or statements:

• Capability
• Capability is quantified by Metric

The creation of taxonomies is more concerned with organisation of collections of any architecture description element, not just capability, and associated with repository management.

Taxonomy diagrams of any type of architecture description element can be included with an architecture description either as a non-conforming product where non-TRAK elements are used (see Conformance with TRAK in TRAK Enterprise Architecture Description document) or using the relevant master architecture view for the TRAK element and the MV-01 definitions to support.

Neighbouring Architecture Views

The EV-02 Capability Hierarchy architecture view content may overlap that of the following neighbouring architecture views:

• CV-04 Concept Activity to Capability Mapping
• EV-01 Enterprise Goal
• EV-03 Capability Phasing
• MV-01 Architecture Description Dictionary
• MV-02 Architecture Description Design Record
• MV-03 Requirements and Standards
• MV-04 Assurance

Navigation & Website Tracker

Spotted an error or want to suggest something - create a ticket

Return to the Architecture Viewpoints list or Summary of Architecture Viewpoint Concerns..

The TRAK architecture viewpoints are subject to the terms of open source license: GNU Free Documentation License (Version 1.3, November 2008) at https://www.gnu.org/licenses/fdl-1.3.html.