Examples
Creating Capability Architectures
allows users to express capability requirements. This is one of the key areas where MODAF extends the scope of DoDAF. Any architect starting to use MODAF for the first time should acquaint themselves with the terminology used for modelling capabilities. The term capability is not used in the precisely the same way by all communities in the MOD. This level of ambiguity would present some challenges for developing MODAF architectures, so it was necessary to establish a clear vocabulary for capabilities. The MODAF Meta-Model defines a number of architectural elements that are related to capability. These are described at various points in this article:
- Capability Vision
- The overall aims of an enterprise over a given period of time. Although not strictly speaking an architectural element, this document is the “capping paper” providing provenance for the capability architecture and is usually a strategic policy statement or operational concept.
- Capability
- A high level specification of the enterprise’s ability. A capability is a classification of some ability – and can be specified regardless of whether the enterprise is currently able to achieve it. For example, one could define a capability “Manned Interplanetary Travel” which no-one can currently acheive, but which may be planned or aspired to. Capabilities in MODAF are not time-dependent – once defined they are persistent. MODAF allows the architects to develop a formal taxonomy of capabilities which can be re-used across multiple architectures.
Assuming the Capability Vision already exists, the first task in developing a capability architecture is to establish the capability taxonomy. It is likely that capabilities are already defined to some degree, and the main task in creating a MODAF-compliant capability architecture is to organise these capabilities into a formal taxonomy. The example below shows a fictitious ground manoeuvre capability taxonomy:
The diagram above (which happens to use a UML notation) shows a specialisation hierarchy of capabilities. Note that some capabilities specialise from more than one parent – for example, Rapid Ground Support is both a Rapid Ground Manoeuvre and a Ground Manoeuvre Support capability.
The capabilities defined in a MODAF capability taxonomy are used throughout the architecture, and are often used by more than one architecture. MODAF operational architectures refer to capabilities – i.e. they define what capabilities are required for a given scenario or operation. Systems architectures define the personnel, platforms, equipment and processes needed to fulfil capabilities. The capability taxonomy is, therefore, one of the most important parts of a MODAF architecture, so it is vital that the taxonomy is produced according to certain guidelines:
The ability to model capabilities as being components of other capabilities is part of the more general MODAF approach to modelling dependencies between capabilities.
- Capability Dependency
- A relationship that asserts a capability is dependent on another capability – i.e. one capability has to exist before the other can be achieved.
Sticking with the non-military example, this is easily illustrated with a diagram:
The dotted arrow points to the capability upon which another capability depends – i.e. the dotted line should read from tail to head: “depends on”.
Up to this point we have only discussed capabilities in general terms, regardless of whether they are required or not. The capabilities described in a taxonomy may not all be required by the enterprise – some may be capabilities exhibited by coalition partners or opposing forces. To make use of the capabilities in an operational or acquisition architecture, it is necessary to state to what level the capability is required and by when.
- Capability Requirement
- A time-dependent requirement for a Capability. A capability requirement is a statement that a Capability is required to a certain level (specified by formal metrics and natural language assertions) within a specified time frame. Taking the interplanetary travel capability from before, we could create a Capability Requirement stating that a space agency intend to achieve the capability by 2020, with a required journey time to Mars of 6 months.
Capability requirements are usually shown as special cases of the capabilities they describe. In the example below, the Battlefield Repair & Recovery capability is extended to show the requirements for the 1980-2010 and 2010-2030 timespans (or “epochs”):
The capability requirements specify performance metrics – in this case, the required recovery time is greatly reduced. Once a taxonomy of capabilities and capabilities requirements have been defined, these can be re-used across a number of architectures. Operational architectures can apply capabilities to scenarios and plans:
MODAF also specifies how combinations (configurations) of equipment and trained staff can realise capability.
- Capability Configuration
- A combination of organisational aspects (with their competencies) and equipment that combine to provide a capability. A Capability Configuration is a physical asset, organisation or post configured to provide a capability.
Capability Configurations are represented as a collection of assets, systems and people that are inter-connected. The root of a configuration must be a platform, facility, person (post) or organization. People may be deployed to platforms and may use systems. The example below shows a ficitious configuration to that realises the battlefield recovery capability from the previous example:
The final aspect of capability that is covered by MODAF is the concept of actual, physical capability – i.e. a real world instance of a Capability Configuration.
- Fielded Capability
- An actual, fully-realised capability – e.g. HMS Daring in fully operational condition, with a trained crew.
Fielded Capabilities are not often used in architectures, but sometimes it is necessary to refer to an existing capability – e.g. referring to permanent joint headquarters.
Summary
Capabilities are at the core of all MODAF architectures. They provide strategic context and high-level requirements for acquisition architectures, and provide ops planners with an easy way to specify how capabilities are required to interact in an operational architecture. A capability architecture may support any number of other architectures – i.e. the capability taxonomy and requirements may be re-used over and over again. This level of re-use helps to ensure a common understanding across projects and reduces the amount of repeated effort.
Page version 1.001, dated 7th February 2007