Back to Top

Defense Acquisitions Made Easy

Blog Archives

DoDAF Architecting

CV-5 Capability to Organizational Development Mapping

The CV-5 “Capability to Organizational Development Mapping” addresses the fulfillment of capability requirements. It shows the planned capability deployment and interconnection for a particular phase and should provide a more detailed dependency analysis than is possible using the CV-3 “Capability Phasing” model. It’s used to support the capability management process and, in particular, assist the planning of fielding.

Guide: DoDAF Architecture Framework Version 2.02 – Page 124

The intended usage of the CV-5 includes:

  • Fielding planning.
  • Capability integration planning.
  • Capability options analysis.
  • Capability redundancy/overlap/gap analysis.
  • Identification of deployment level shortfalls.

The CV-5 shows deployment of Capabilities to specific organizations and are specific to a phase. If a particular Capability is/was used by (or is due to be used by) a specific organization during that phase, it should be shown on the CV-5, mapped to the organization. The CV-5 may also show interactions between them (where these have been previously defined in a SV-1 “Systems Interface Description” or SvcV-1 “Services Interface Description”). The CV-5, along with SV-8 Systems Evolution Description, SvcV-8 “Services Evolution Description” and PV-2 “Project Timelines” models can be regarded as amplifying the information contained in the CV-3.

To conduct a comprehensive analysis, several CV-5s can be created to represent the different phases. Although the CV-5s are represented separately, Capabilities may exist in more than one model. The information used to create the CV-5 is drawn from other DoDAF described Models (PV-2 “Project Timelines”, CV-2 “Capability Taxonomy”, OV-4 “Organizational Relationships Chart”, SV-1 “Systems Interface Description”, SvcV-1 “Services Context Description”), and the timing is based on PV-2 Project Timelines indicating delivery of Capabilities to actual organizational resources, and also the point at which those organizational resources cease to use a particular Capability.

System interaction (from the SV-1 Systems Interface Description) or Service interaction (from the SvcV-1 Services Context Description) can be shown on a CV-5. In addition, where a Capability or resources is deployed across a number of Organizations, a parent Organization can be created for context purposes, and the Capability or resource stretched across the domain of the parent Organization.

   DoDAF Viewpoint Matrix
AV 1 2                      
CV 1 2 3 4 5 6 7            
DIV 1 2 3                    
OV 1 2 3 4 5a 5b 6a 6b 6c        
PV 1 2 3                    
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2                      
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 6/26/2018

DoDAF Architecting

DIV-1 Conceptual Data Model

The DIV-1 Conceptual Data Model addresses the information concepts at a high-level on an operational architecture.  The DIV-1 is used to document the business information requirements and structural business process rules of the architecture. It describes the information that is associated with the information of the architecture. Included are information items, their attributes or characteristics, and their inter-relationships.

Guide: DoDAF Architecture Framework Version 2.02 – Page 133

The intended usage of the DIV-1 includes:

  • Information requirements
  • Information hierarchy

The DIV-1 describes the structure of an Architectural Description domain’s information types and the structural business process rules (defined in the Operational Viewpoints (OV) Models).

The Architectural elements for DIV-1 include descriptions of information entity and relationship types. Attributes can be associated with entities and with relationships, depending on the purposes of the Architectural Description.

The intention is that DIV-1 describes information or data of importance to the business (e.g., information products that might be referred to in doctrine, SOPs, etc.) whereas the DIV-3 “Physical Data Model” describes data relevant at the system-level.

The purpose of a given Architectural Description helps to determine the level of detail needed in this model. This level of detail is driven in particular by the criticality of the interoperability requirements.

Often, different organizations may use the same Entity name to mean very different kinds of information having different internal structure. This situation could pose significant interoperability risks, as the information models may appear to be compatible but having different and incompatible interpretations of what Target Track means.

A DIV-1 may be necessary for interoperability when shared information syntax and semantics form the basis for greater degrees of information systems interoperability, or when an information repository is the basis for integration and interoperability among business activities and between capabilities.

The DIV-1 defines the Architectural Description’s information classes and the relationships among them. For example, if the architecture effort is describing missile defense, some possible information classes may be trajectory and target with a relationship that associates a target with a certain trajectory. The DIV-1 defines each kind of information classes associated with the Architectural Description scope, mission, or business as its own Entity, with its associated attributes and relationships. These Entity definitions correlate to OV-2 “Operational Resource Flow Description” information elements and OV-5b “Operational Activity”.

   DoDAF Viewpoint Matrix
AV 1 2                      
CV 1 2 3 4 5 6 7            
DIV 1 2 3                    
OV 1 2 3 4 5a 5b 6a 6b 6c        
PV 1 2 3                    
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2                      
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 9/27/2017

DoDAF Architecting

CV-7 Capability to Services Mapping

The CV-7 “Capability to Services Mapping” describes the mapping between the capabilities required and the services that enable those capabilities. It provides a bridge between capability analyzed using Capability Viewpoints (CV) and services analyzed using Service Viewpoint (SvcV).  Specifically, it identifies how services can be performed using various available capability elements. It is similar in function to the SV-5a “Operational Activity to Systems Function Traceability Matrix” which maps system functions to operational activities. The capability to service mappings may include both situations where a service fully satisfies the desired capability and those where the service only partially meets the capability requirement.

Guide: DoDAF Architecture Framework Version 2.02 – Page 128

The intended usage of the CV-7 includes:

  • Tracing capability requirements to services
  • Capability audit

A CV-7 shows which elements of capability may be utilized in support of specific services by means of a mapping matrix. If it is created as part of a strategic architecture (i.e., before the creation of supporting service models), it is recommended that the services used as part of the CV-7 are common functions. This model may be used indicate that an operational capability (perhaps reflecting a particular user requirement) does or does not fulfill the requirements for capability for a particular phase.

In principle, there could be a different CV-7 created for each phase of the capability development, or perhaps for different capability phasing scenarios. In most cases, it is considered that a single table can be constructed because the services that are most likely relevant to this model may be relatively high-level. If capabilities associated are generic (see CV-1 “Vision model”), then they should have a well understood relationship with a standard set of services and this relationship is unlikely to change over time.

This model is analogous to the SV-5a “Operational Activity to System Function Traceability Matrix” – but provides the interface between Capability and Service Models rather than Operational to System Models.

The CV-7 can have a tabular presentation. The rows can be the capabilities and the columns can be the services. An X indicates that the capability may be utilized in support of that service whereas a blank indicates that it does not. Alternatively, a date or phase can indicate that the capability may support that service by the date or phase indicated.

   DoDAF Viewpoint Matrix
AV 1 2                      
CV 1 2 3 4 5 6 7            
DIV 1 2 3                    
OV 1 2 3 4 5a 5b 6a 6b 6c        
PV 1 2 3                    
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2                      
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 6/26/2018

DoDAF Architecting

CV-4 Capability Dependencies

The CV-4 “Capability Dependencies” describes the dependencies between planned capabilities and also defines logical groupings of capabilities.   It’s intended to provide a means of analyzing the dependencies between capabilities.

The groupings of capabilities are logical, and the purpose of the groupings is to guide enterprise management. In particular, the dependencies and groupings may suggest specific interactions between acquisition projects to achieve the overall capability.

Guide: DoDAF Architecture Framework Version 2.02 – Page 122

The intended usage of the CV-4 includes:

  • Identification of capability dependencies.
  • Capability management (impact analysis for options, disposal etc.).

The CV-4 describes the relationships between capabilities. It also defines logical groupings of capabilities. This contrasts with CV-2 “Capability Taxonomy” model which also deals with relationships between Capabilities; but CV-2 only addresses specialization-generalization relationship (i.e., capability taxonomy).

A CV-4 shows the capabilities that are of interest to the Architectural Description. It groups those capabilities into logical groupings, based on the need for those elements to be integrated.

An approach for describing a CV-4 is graphical. In some cases, it may be important to distinguish between different types of dependency. Graphically, this can be achieved by color-coding the connecting lines or by using dashed lines. From a data perspective, the CV-4 can make use pre-existing capability dependency types in the DoDAF Meta-model; else new, specific dependency types can be created. The new dependency types need to be recorded the in the AV-2 “Integrated Dictionary”.

   DoDAF Viewpoint Matrix
AV 1 2                      
CV 1 2 3 4 5 6 7            
DIV 1 2 3                    
OV 1 2 3 4 5a 5b 6a 6b 6c        
PV 1 2 3                    
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2                      
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 6/26/2018

DoDAF Architecting

CV-6 Capability to Operational Activities Mapping

The CV-6 “Capability to Operational Activities Mapping” describes the mapping between the capabilities required and the activities that enable those capabilities. It provides a bridge between capability analyzed using Capability Viewpoints (CV) and operational activities analyzed using Operational Viewoints (OV). Specifically, it identifies how operational activities can be performed using various available capability elements. It is similar in function to the SV-5a “Operational Activity to Systems Function Traceability Matrix”. The capability to activity mappings may include both situations where activities fully satisfy the desired capability and those where the activity only partially meets the capability requirement.

Guide: DoDAF Architecture Framework Version 2.02 – Page 126

The intended usage of the CV-6 includes:

  • Tracing capability requirements to operational activities.
  • Capability audit.

A CV-6 shows which elements of capability may be utilized in support of specific operational activities by means of a mapping matrix. If the CV-6 is created as part of a strategic architecture (i.e., before the creation of supporting operational models), it is recommended that the operational activities described in the CV-6 should be common functions. This model may be used indicate that an operational capability (perhaps reflecting a particular user requirement) does or does not fulfill the requirements for capability for a particular phase.

In principle, there could be a different CV-6 created for each phase of the capability development, or perhaps for different capability phasing scenarios. In most cases, it is considered that a single table can be constructed because the operational activities that are most likely relevant to this model may be relatively high-level. If capabilities associated are generic (see CV-1 Vision Model), then they should have a well understood relationship with a standard set of operational activities and this relationship is unlikely to change over time. This model is analogous to the SV-5a “Operational Activity to System Function Traceability Matrix” – but provides the interface between Capability and Operational Models rather than Operational to System Models.

The CV-6 can have a tabular presentation. The rows can be the Capabilities and the columns can be the Operational Activities. An X may indicate that the capability may be utilized in support of that activity whereas a blank indicates that it does not. Alternatively, a date or phase can indicate that the capability may support that activity by the date or phase indicated.

   DoDAF Viewpoint Matrix
AV 1 2                      
CV 1 2 3 4 5 6 7            
DIV 1 2 3                    
OV 1 2 3 4 5a 5b 6a 6b 6c        
PV 1 2 3                    
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2                      
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 6/26/2018

DoDAF Architecting

CV-1 Vision

The CV-1 Vision addresses the enterprise concerns associated with the overall vision for transformational endeavors and thus defines the strategic context for a group of capabilities. The purpose of a CV-1 is to provide a strategic context for the capabilities described in the Architectural Description. It also provides a high-level scope for the Architectural Description which is more general than the scenario-based scope defined in an OV-1 “High Level Operational Concept Graphic”.

Guide: DoDAF Architecture Framework Version 2.02 – Page 117

The intended usage is communication of the strategic vision regarding capability development.

The CV-1 defines the strategic context for a group of capabilities described in the Architectural Description by outlining the vision for a capability area over a bounded period of time. It describes how high-level goals and strategy are to be delivered in capability terms. A CV-1 may provide the blueprint for a transformational initiative. The CV-1 may be primarily textual descriptions of the overarching objectives of the transformation or change program that the Enterprise is engaged in. Of key importance is the identification of Goals, together with the desired outcomes and measurable benefits associated with these.

   DoDAF Viewpoint Matrix
AV 1 2                      
CV 1 2 3 4 5 6 7            
DIV 1 2 3                    
OV 1 2 3 4 5a 5b 6a 6b 6c        
PV 1 2 3                    
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2                      
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 6/26/2018

DoDAF Architecting

CV-2 Capability Taxonomy

The CV-2 “Capability Taxonomy” presents a hierarchy of capabilities. These capabilities may be presented in context of a timeline – i.e., it can show the required capabilities for current and future capabilities. The CV-2 specifies all the capabilities that are referenced throughout one or more architectures. In addition, it can be used as a source document for the development of high-level use cases and user requirements.

Guide: DoDAF Architecture Framework Version 2.02 – Page 118

The intended usage of the CV-2 includes:

  • Identification of capability requirements.
  • Capability planning (capability taxonomy).
  • Codifying required capability elements.
  • Capability audit.
  • Capability gap analysis.
  • Source for the derivation of cohesive sets of user requirements.
  • Providing reference capabilities for architectures.

In CV-2, the Capabilities are only described in the abstract. A CV-2 is structured as a hierarchy of capabilities, with the most general at the root and most specific at the leaves. At the leaf-level, capabilities may have a measure specified, along with an environmental condition for the measure. When capabilities are referenced in operational or systems architectures, it may be that a particular facility, location, or organization or configuration meets more than one level of capability.

The CV-2 is used to capture and organize the capability functions – required for the vision set out in the CV-1 “Vision”.   In contrast to AV-2 Integrated Dictionary, a CV-2 is structured using only one type of specialization relationship between elements: sub-supertype. A sub-supertype relationship is a relationship between two classes with the second being a pure specialization of the first. In DoDAF V2.0, capabilities exist in space and over time, that is they are intended to provide a framework across the lifetime of the enterprise that is being modeled. This means that it is feasible to develop a capability taxonomy that can apply to all architecture phases.

In addition to the capability nomenclature, appropriate quantitative attributes and measures for that specific capability or function need to be included e.g., the required speed of processing, the rate of advance, the maximum detection range, etc. These attributes and measures will remain associated with the capability whenever it is used across the Architectural Description. The quantitative values expressed may be linked to specific phases (or be “As-Is” values and/or or “To-Be” targets).

The CV-2 has no mandated structure although the architectural data must be able to support the representation of a structured/hierarchal list. This structure may be delivered using textual, tabular or graphical methods. The associated attributes and measures for each capability can either be included on the main CV-2 or in tabular format as an appendix if the inclusion of the attributes and measures would over complicate the presentation of the populated view.

   DoDAF Viewpoint Matrix
AV 1 2                      
CV 1 2 3 4 5 6 7            
DIV 1 2 3                    
OV 1 2 3 4 5a 5b 6a 6b 6c        
PV 1 2 3                    
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2                      
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 6/26/2018

DoDAF Architecting

CV-3 Capability Phasing

The CV-3 “Capability Phasing” addresses the planned achievement of capability at different points in time or during specific periods of time. The CV-3 supports the capability audit processes and similar processes used across the different COIs by providing a method to identify gaps or duplication in capability provision. The CV-3 indicates capability increments, which should be associated with delivery milestones within acquisition projects (when the increments are associated with capability deliveries).

Guide: DoDAF Architecture Framework Version 2.02 – Page 120

 The intended usage of the CV-3 includes:

  • Capability planning (capability phasing).
  • Capability integration planning.
  • Capability gap analysis.

A CV-3 can be used to assist in the identification of capability gaps/shortfalls (no fielded capability to fulfill a particular capability function) or capability duplication/overlap (multiple fielded capabilities for a single capability function).

The CV-3 is populated by analyzing programmatic project data to determine when projects providing elements of capability are to be delivered, upgraded and/or withdrawn (this data may be provided in part by a PV-2 “Project Timelines” model). Then capability increments identified can be structured according to the required capabilities determined in the CV-2 “Capability Taxonomy” model and the phases. Alternatively, a set of desired capability increments can be viewed and then compared to the project plans. In practice, the population of the model tends to iterate between considering the desired capability and considering what capability is planned to be delivered. The output from this iterative approach can be a table that represents the required capability phasing.

The CV-3 can be presented as a table consisting of rows representing Capabilities (derived from the CV-2 Capability Taxonomy model) and columns representing phases (from CV-1 “Vision model”).

At each row-column intersection in the CV-3 table, the capability increment that represents the change in Capability within that phase can be displayed. If the availability of the Capability spans multiple periods of time, then this can be indicated by an elongated color coded bar. If there are no Capabilities planned to satisfy the Capability Requirements in that period of time then a blank space can be left.

A variant CV-3, in which the names of the projects that can deliver the capability increments are included, can identify capability gaps and shortfalls. The essence is the relationship between projects, capabilities and time. The model may be used to envisage the need for interventions in projects (to fulfill a capability gap) or to represent current plans (the availability of capability according to their delivery timescales).

   DoDAF Viewpoint Matrix
AV 1 2                      
CV 1 2 3 4 5 6 7            
DIV 1 2 3                    
OV 1 2 3 4 5a 5b 6a 6b 6c        
PV 1 2 3                    
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2                      
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 6/26/2018

DoDAF Architecting

System Viewpoints (SV)

Systems Viewpoint (SV) describes systems and interconnections providing for, or supporting, DoD functions. DoD functions include both warfighting and business functions. The Systems Models associate systems resources to the operational and capability requirements. These systems resources support the operational activities and facilitate the exchange of information. The Systems Models are available for support of legacy systems. As architectures are updated, they should transition from Systems to Services and utilize the models within the Services Viewpoint.

The thirteen (13) System Viewpoints are:

   DoDAF Viewpoint Matrix
AV 1 2                      
CV 1 2 3 4 5 6 7            
DIV 1 2 3                    
OV 1 2 3 4 5a 5b 6a 6b 6c        
PV 1 2 3                    
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2                      
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 9/27/2017

DoDAF Architecting

AV-1 Overview and Summary Information

The AV-1 provides executive-level summary and overview information in a consistent form that allows quick reference and comparison between Architectural Descriptions. The written content of the AV-1 describes the concepts contained in the pictorial representation of the Operational View (OV)-1. [1]

Guide: DoDAF Architecture Framework Version 2.02 – Page 110

The AV-1 frames the context for the Architectural Description and includes assumptions, constraints, and limitations that may affect high-level decisions relating to an architecture-based work program. It should contain sufficient information to enable a reader to select a single Architectural Description from among many to read in more detail. The AV-1 serves two additional purposes: [1]

  • In the initial phases of architecture development, it serves as a planning guide
  • Provides summary information on the plan concerning who, what, when, why, and how
  • Provides navigation aid to the models that have been created

The usage of the AV-1 is to: [1]

  • Scope the architecture effort
  • Provide context to the architecture effort
  • Define the architecture effort
  • Summarize the findings from the architecture effort
  • Assist search within an architecture repository

The AV-1 is usually a structured text product. An architecting organization may create a template for the AV-1 that can then be used to create a consistent set of information across different architecture-based projects. While the AV-1 is often dispensed with or “retrofitted” to a finished architecture package, it’s desirable to do it up-front because the AV-1 provides a summary of a given Architectural Description and it documents the following descriptions: [1]

  •  Architectural Description Identification: Identifies the Architectural Description effort name, the architect, and the organization developing the Architectural Description. It also includes assumptions and constraints, identifies the approving authority and the completion date, and records the level of effort required to develop the Architectural Description.
  • Scope: Identifies the Viewpoints, DoDAF-described Models, and Fit-for-Purpose Views that have been selected and developed. The AV-1 should address the temporal nature of the Architectural Description, such as the time frame covered, whether by specific years or by designations such as “current”, “target”, or transitional. Scope also identifies the organizational entities and timelines that fall within the scope of the Architectural Description.
  • Purpose and Perspective: Explains the need for the Architectural Description, what it will demonstrate, the types of analyses that will be applied to it, who is expected to perform the analysis, what decisions are expected to be made based of each form of analysis, who is expected to make those decisions, and what actions are expected to  result. The perspective from which the Architectural Description is developed is identified.
  • Context: Describes the setting in which an Architectural Description exists. Context includes such things as: mission, doctrine, relevant goals and vision statements, concepts of operation, scenarios, information assurance context (e.g., types of system or service data to be protected, such as classified or sensitive but unclassified, and expected information threat environment), other threats and environmental conditions, and geographical areas addressed, where applicable. Context also identifies authoritative sources for the standards, rules, criteria, and conventions that are used in the architecture. Any linkages to parallel architecture efforts should be identified.
  • Status: Describes the status of the architecture at the time of publication or development of the AV-1 (which might precede the architectural development itself). Status refers to creation, validation and assurance activities.
  • Tools and File Formats Used: Identifies the tool suite used to develop the Architectural Description and file names and formats for the Architectural Models if appropriate.
  • Assumptions and Constraints
   DoDAF Viewpoint Matrix
AV 1 2                      
CV 1 2 3 4 5 6 7            
DIV 1 2 3                    
OV 1 2 3 4 5a 5b 6a 6b 6c        
PV 1 2 3                    
SvcV 1 2 3a 3b 4 5 6 7 8 9 10a 10b 10c
StdV 1 2                      
SV 1 2 3 4 5a 5b 6 7 8 9 10a 10b 10c

AcqTips:  

  • The DoDAF descriptions in this website are very generic and are mostly taken from the DoDAF Architecture Framework website. Make sure you visit the actual website for the most update information and a more thorough explanation of each viewpoint.
  • DoDAF Version 1.0, although outdated, has some good examples on how to construct AV’s, OV’s, and SV’s.

AcqLinks and References:

Updated: 9/1/2017