• DODAF Home 
• Background 
• Architectural Development 
• Meta Model 
  • Conceptual 
  • Logical 
  • PES 
  • IDEAS Foundation Ontology 
• Viewpoints & Models
  • All Viewpoint 
  • Capability Viewpoint 
  • Data and Information Viewpoint 
  • Operational Viewpoint 
  • Project Viewpoint 
  • Services Viewpoint 
  • Standards Viewpoint 
  • Systems Viewpoint 
  • Models 
  • Model Categories
  • Levels of Architecture
  • Architecture Interrogatives 
  • Architecture Modeling Primitives
  • Mapping to DM2 
• Presentation Techniques
  • Composite Views 
  • Fusion Views 
  • Reference Models 
• DODAF-DM2 Configuration Management
• IDEAS 
• Related Links 
• Acronyms List and Glossary of Terms 
• Site Map 
• Archives

Measures

A measure is the magnitude of some attribute of an object. Measures provide a way to compare objects, whether Projects, Services, Systems, Activities, or Capabilities. The comparisons can be between like objects at a point in time, or the same object over time. For example, a Capability may have different measures when looking at the current baseline and over increments toward some desired end-state.  Measures play a much greater, central role in DoDAF V2.0, compared to earlier versions of DoDAF. This change has multiple drivers, including: Core Process use of architectural data. Those management and engineering processes depend on quantification as a means of improving objectivity, accountability, and efficiency of the processes. Federal Enterprise Architecture (FEA) Performance Reference Model.  There are many kinds of Measures that are applicable to many architecture elements. These are described in the following paragraph.

Data Group Description

The DoDAF Meta Model for the data comprising Measures, is depicted in the figure below.

DoDAF Meta Model for Measures
(Click image to enlarge)

The following should be noted about the Measures Data Group:

1. The key elements of the Measure Data group are Measure and Measure Type. Measure refers to the actual measure value and units. It relates to a Measure Type that describes what is being measured. Examples of each are shown below in the table below.
   
   
   
   Non-prescriptive, Illustrative Examples of Measures and Measure Types
   

    

2. Formally, a Measure defines membership criteria for a set or class; e.g., the set of all things that has 2 kg mass. The relationship between Measure and Measure Type is that any particular Measure is an instance of all the possible sets that could be taken for a Measure Type.
   
   
3. The lower part of Figure 20 depicts the upper tiers of a Measure Type taxonomy or classification scheme. It is expected that architects would add more detailed types (make the taxonomy more specialized), as needed, within their federate. Note that Service Level has multiple inheritances because a Service QoS or Service Level Agreement (SLA) could address User Needs, User Satisfaction, Interoperability, or Performance.
   
   
4. All Measure Types have a Rule that prescribes how the Measure is accomplished; e.g., units, calibration, or procedure. Spatial measures' Rules include coordinate system rules. For example, latitude and longitude are understandable only by reference to a Geodetic coordinate system around the Earth.
   
   
5. As a Measure Type, cost can be captured in the architecture at different levels, based on the Process-owners requirements
   
   
6. The upper part of the figure above depicts how Measures apply to architecture elements. Note that they apply to relationships between objects; e.g., the Measure applies to a Performer performing an Activity. The Activity has a relationship to Measure Type that says what Measure Types apply to an Activity. This represents Universal Joint Task List (UJTL) tasks and their applicable Measure Types, including Conditions, that is, Condition is quantified by a Measure Type. (The whole-part relationship feature of Condition allows it to be singular.) This is accomplished by Condition's typeInstance association, saying an elementary Condition is a member (instance) of a Measure Type class.

Usage in Core Processes

Data for Measures are used in the six core processes in the following ways:

PPBE and JCIDS:

1. Planning – adequacy analysis: From an adequacy point of view, Measures that are associated with a Capability (including Capability increment, since Capabilities have whole-part inheritance). Capabilities can be compared with the Measures associated with the Performers to see if the Performer solution(s) are adequate. A set of alternative Performers as part of an Analysis of Alternatives could also be evaluated. Goals or Desired Effects could compare with Measures associated with Performers.
2. Programming – overlap analysis: The purpose of an overlap analysis is to determine if there are overlaps, or undesired duplicative capability, in the spending plan, portfolio, capabilities development, or acquisition plan. Similar functionality is often only an indicator of overlapping or duplicative capability. Often Performers with similar functionality operate under different Measures which are not duplicative or overlapping capability. For example, operational-level situation awareness systems may not be as fast or precise as a tactical-level, but they may handle a larger number of objects over a larger area.
3. Goal Setting: Measures are often part of Goals; e.g., production or efficiency Goals.
4. Requirements: Requirements often have Measure elements.
5. Capability Evolution: Measures are part of capability evolution, showing increments of measurable improvement as the capability evolves and allowing monitoring about when the capability is projected to be achieved or has already been achieved.

SE and DAS:

1. System Engineering/Design: Measures set the design envelope goals, sometimes called performance characteristics or attributes. They can also set the constraints; e.g., cost constraints.
2. Performance–Cost Tradeoffs: Measures of performance (e.g., effectiveness) can be compared to different costs to evaluate and make decisions about alternative solutions.
3. Benchmarking: Measures can be used to establish benchmarks of performance, such as for a personnel skill or a radar tracking accuracy test.
4. Organizational and Personnel Development: Organizational and personnel goals are often established and then monitored using Measures.
5. Capacity Planning: Measures can be used to plan for needed capacity; e.g., for networks, training programs.
6. Quality of Service (QoS) Description: In SOA, QoS is often expressed as a Measure; e.g., bit loss rate or jitter. These Measures show up in the service description and are part of service discovery, so users can discover access to capabilities that meet their quality requirements.
7. Project Constraints: Measures such as cost and risk can be constraints on Projects.

CPM:

1. Portfolio Balancing. Measures can be used to balance a portfolio so that it achieves the right mix of goals and constraints.

Ops Planning:

1. Organizational and Personnel Development. Organizational and personnel goals are often established and then monitored using Measures.

Presentation

Presentation Measures are typically displayed in tabular form and are usually tied to Structural, Behavioral or Tree models and their constituent elements. Measures can also be represented in a tree structure illustrating the traceability of derived metric requirements.