TRAK-Community

Title

EVp-03 - Capability Phasing Viewpoint

Version

6

Date

8th March 2011

Overview

The EVp-03 - Capability Phasing Viewpoint is part of the Enterprise Perspective and one of the 21 TRAK Architecture Viewpoints.

The EVp-03 Capability Phasing Viewpoint provides a way of describing the duration and phasing of capabilities.

It is the specification for the TRAK::EV-03 Capability Phasing architecture view.

Stakeholders Addressed

• Builder of Enterprise
• Developer of Enterprise
• Maintainer of Enterprise
• Owner of Enterprise
• Acquirer of System
• Disposer of System

Concerns Addressed

When is capability required?

Is this capability realised by any solutions?

Are there any capability gaps?

Full size:File:evp03StakeholderConcern.gif

Covered by TRAK IPR and licenses

Description

Describes when Capabilities (planned or actual) are fielded over time. Capabilities are enduring since on their own they have no associated time.  An Enterprise has a start and finish date and therefore when a capability is tied to an enterprise this defines a period for which that capability is required. Similarly a system can realise a capability and when delivered or removed by a project activity there is a time period during which the required capability is realised.

The EVp-03 can be used to show the capabilities needed, the capabilities realised (via the solution and procurement perspectives) or contrast the two to determine Capability gaps. The EVp-03 also describes dependencies between capabilities.

Covered by TRAK IPR and licenses

The phasing of capability requires a duration - start and finish times to be defined. This is available from 2 sources:

• Enterprise attributes. In this case the phasing shown is the required Capability phasing.
• Project Activity attributes in conjunction with the Project Activity delivers / removes System. This is shown on the PrVp-02 Procurement Timeline Architecture Viewpoint which describes how capability is provided or removed by virtue of a system. The net realised capability can only therefore be described if the PrVp-02 is present.

Comparing the required capability phasing with the realised capability phasing provides a way to describe capability gaps.

Mandatory Metamodel Tuples

Capabilities Needed

• Enterprise requires Capability

Capabilities Realised

• Project Activity delivers System
• Project Activity removes System
• System realises Capability

Covered by TRAK IPR and licenses

Optional Metamodel Tuples

Universal

• Concern about Architecture Description Element
• Architecture Description Element traces to Document
• Standard governs Architecture Description Element
• Architecture Description Element traces to Requirement

If any of these optional metamodel elements are added then the appropriate TRAK Master Architecture View must be provided.

Covered by TRAK IPR and licenses

Well-Formedness

An EV-03 view shall contain:

[capabilities needed - phasing]

• at least one Enterprise (the subject of the view)
• every Enterprise must have at least one Capability
• the Enterprise must have both a start and a finish date. If it doesn’t it is assumed to be enduring (exists at all dates)
• the time period during which a Capability is required must be visible (as the point is to show change / dependency with time).

[capabilities realised]

In addition if the capabilities realised are to be shown:

• at least one System
• every System must realise at least one of the Capabilities from the [capabilities needed]
• every System must be associated with 2 Project Activities (one to introduce the System into service, the other to remove it from service)
• every Project Activity must have both a start and a finish date

Covered by TRAK IPR and licenses

The properties/attributes for elements are defined within the TRAK Metamodel document.

Presentation

• table or matrix ([capabilities needed] Capability vs time taken from start and finish dates for each Enterprise; i.e. Capability vs Enterprise [capabilities realised] Capability vs time taken from start and finish dates for each Project Activity that delivers/removes the Capability - i.e. Capability vs System; or contrast the two). The important feature is to be able to see how capability changes with time.
• block diagram (connected blocks to represent Enterprise, Capability, Project Activity and System)

table form:

                                                         

  EV-03 Table or Matrix Form  

Capability	Required by Enterprise	Start Date	Finish Date	Depends on Capability
Ca1	E01	T1	T5	-
Ca2	E01	T1	T5	Ca3
Ca3	E02	T0	T4	-

Capabilities needed: - hierarchy (enduring / no time specified):

Phasing:

Full size:File:EVp-03 examplePresentation blocksGap.gif

Covered by TRAK IPR and licenses

Examples

Views Needed to Construct

• EV-02 - master architecture view for Capability
• PrV-02  - master architecture view for Project Activity
• SV-01 (if System realises Capability shown) - master architecture view for Resource (System)

See Minimum Allowed View Sets

Consistency Rules

• Capability must appear in EV-02
• Project must appear in PrV-01
• System must appear in SV-01

Covered by TRAK IPR and licenses

Further rules are applied through the TRAK Bye Laws

Configuration History

The TRAK Viewpoints project on Sourceforge (trakviewpoints.sourceforge.net) maintains a version-controlled repository. The change record is at http://trakviewpoints.svn.sourceforge.net/viewvc/trakviewpoints/trunk/?view=log

Comments

Other Frameworks

See:

• DODAF::CV-3 Capability Phasing Model
• MODAF::StV-3 Capability Phasing View
• NAF::NCV-3 Capability Phasing Subview

There is no equivalent in DNDAF to the TRAK Enterprise Perspective - see Architecture Framework Comparison.

References

• TRAK Enterprise Architecture Framework Viewpoints. http://trakviewpoints.sourceforge.net

Category:Framework -> Viewpoint
Category:Framework -> Specification
Category:Enterprise
Category:Strategic

Categories:

• Enterprise
• Framework
  • Specification
• Viewpoint

Strategic