Back to Top

Defense Acquisitions Made Easy

Blog Archives

DoDAF Architecting

AV-2 Integrated Dictionary

The AV-2 presents all the metadata used in an architecture and presents all the data as a hierarchy, provides a text definition for each one and references the source of the. It also shows elements from the DoDAF Meta-model that have been described in the Architectural Description and new elements that have been introduced by the Architectural Description.

Guide: DoDAF Architecture Framework Version 2.02 – Page 113

 It is essential that organizations within the DoD use the same terms to refer to a thing. Because of the interrelationship among models and across architecture efforts, it is useful to define common terminology with common definitions (referred to as taxonomies) in the development of the models within the Architectural Description. These taxonomies can be used as building blocks for DoDAF-described Models and Fit-for-Purpose Views within the Architectural Description. Use of taxonomies to build models for the architecture has the following benefits over free-text labeling:

  • Provides consistency across populated views, based on DoDAF-described Models.
  • Provides consistency across Architectural Descriptions.
  • Facilitates Architectural Description development, validation, maintenance, and re-use.
  • Traces architectural data to authoritative data sources.

The purpose of the AV-2 is to provide a means to explain the terms and abbreviations used in building the architecture and, as necessary, submit them for review and inclusion into authoritative vocabularies developed by COIs that are pertinent to the Architectural Description content.

In the creation of any Architectural Description, reuse of authoritative external taxonomy content, e.g., the FEA Reference Models, or the Joint Common System Function List, or any listed in Architecture Resources, are important to aligning the architectural content across many descriptions to increase their understandability, interoperability, Architecture Federation, and compliance.

The AV-2 content can be organized by the following areas within the DM2 that can be used to expedite architecture development:

  • Capabilities: The taxonomy should minimally consist of names, descriptions, and conditions that may be applicable to performance measures.
  • Resource Flow: The taxonomy should minimally consist of names of information elements exchanged, descriptions, decomposition into constituent parts and subtypes, and mapping to system data elements exchanged.
  • Activities (Operational Activities or Tasks): The taxonomy should minimally consist of names, descriptions, and decomposition into the constituent parts that comprise an activity.
  • Activities (System or Service Functions): The taxonomy should minimally consist of names, descriptions, and decomposition into the constituent parts that comprise a system function.
  • Performance Parameters: The taxonomy should minimally consist of names, descriptions, units of measure, and conditions that may be applicable to performance parameters.
  • Performers: Performers can be persons, services, systems or organizations. The taxonomy should minimally consist of names, descriptions, breakdowns into constituent parts (e.g., a services comprising other services), and applicable categorizations. Each of the above types of performers is a candidate for a being a taxonomy.
  • Skills: The taxonomy should minimally consist of names, descriptions, units of measure, and conditions that may be applicable to performance parameters.
  • Standards: The taxonomy should minimally consist of categories of standards (e.g., DoD Information Technology Standards and Profile Registry (DISR) Service Areas).
  • Triggers/Events: The taxonomy minimally consists of names, descriptions, and breakdown into constituent parts of the event or trigger and categorization of types of events or triggers.
   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

DoDAF Architecting

Data and Information Viewpoint (DIV)

The Data and Information Viewpoint (DIV) provides a means of portraying the operational and business information requirements and rules that are managed within and used as constraints on the organizations business activities. The appropriate level or levels of abstraction for a given architecture are dependent on the use and the intended users of the architecture. Where appropriate, the data captured in this viewpoint needs to be considered by COIs. DoDAF V2.0 incorporates three levels of abstraction that correlate to the different levels associated with most data models developed in support of the operations or business.

These levels are:

  • Conceptual
  • Logical
  • Physical

Experience gained from many enterprise architecture efforts within the DoD led to the identification of several levels of abstraction necessary to accurately communicate the information needs of an organization or enterprise.

   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:

DoDAF Architecting

Operational Viewpoint (OV)

The Operational Viewpoint (OV) describes the tasks and activities, operational elements, and resource flow exchanges required to conduct operations. It may be used to describe a requirement for a “To-Be” architecture in logical terms, or as a simplified description of the key behavioral and information aspects of an “As-Is” architecture. The OV Models re-use the capabilities defined in the Capability Viewpoint (CV) and put them in the context of an operation or scenario.

The OV’s can be used in a number of ways:

  • Including the development of user requirements
  • Capturing future concepts
  • Supporting operational planning processes

The nine OV’s are listed below:

Operational Viewpoints can be used to help answering the following questions:

  • What are the lines of business supported by this enterprise?
  • What activities are in place to support the different lines of business?
  • What is the functional scope of the capability or capabilities for which I am responsible?
  • This can be answered by a combination of information from the activity model and CV Models. What is the organizational span of influence of this capability or capabilities?
  • What information must be passed between capabilities?
  • What strategic drivers require that certain data are passed or tracked?
  • This can be answered by a combination of data within the logical data model, information exchanges, activities, and CV Models. What activities are being supported or automated by a capability or capabilities? What role does organization X play within a capability or capabilities?
  • What are the functional requirements driving a particular capability?
  • What rules are applied within a capability, and how are they applied?
   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:

DoDAF Architecting

Capability Viewpoint (CV)

The Capability Viewpoint (CV) describes the taxonomy and capability evolution. It’s provides visualizations of the evolving capabilities so that Portfolio Managers can synchronize the introduction of capability increments across a portfolio of projects. The Capability Models included within DoDAF are based on the program and capability information used by Portfolio Managers to capture the increasingly complex relationships between interdependent projects and capabilities.

Guide: DoDAF Architecture Framework Version 2.02 – Page 115

There are seven (7) Capability Viewpoints:

  1. CV-1: Vision
  2. CV-2: Capability Taxonomy
  3. CV-3: Capability Phasing
  4. CV-4: Capability Dependencies
  5. CV-5: Capability to Organizational Development Mapping
  6. CV-6: Capability to Operational Activities Mapping
  7. CV-7: Capability to Services Mapping

The reason for CV is the increasing importance of transformational programs within the DoD (e.g., Global Exchange [GEX], Defense Acquisition Initiative [DAI]). These types of programs are focused on the delivery of capabilities and do not conform to the standard for project management and tend to be benefit-driven rather than capability delivery focused. An ability to view these transformational programs, and their interdependencies, provides a potentially powerful tool for DoD Enterprise Architects.

The CV’s are intended to provide support to various decision processes within the Department, one of which is portfolio management. Since the DoD has moved toward the delivery of capabilities, these models take on a more important role. Developing an architecture that includes the relationships necessary to enable a capability thread is essential to improving usability of architectures.

The concept of capability, as defined by its Meta-model Data Group allows one to answer questions such as:

  • How does a particular capability or capabilities support the overall mission/vision?
  • What outcomes are expected to be achieved by a particular capability or set of capabilities?
  • What services are required to support a capability?
  • What is the functional scope and organizational span of a capability or set of capabilities?
  • What is our current set of capabilities that we are managing as part of a portfolio?
   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

Architecture Design Process

The DoDAF Architecture Design Process has 6-step.  These steps provide guidance and guiding rules to the architect and Architectural Description development team.  The process is data-centric rather than product-centric and ensures synchronization between views while ensuring that all essential data relationships are captured to support a wide variety of analysis tasks. The views created as a result of the architecture development process provide visual renderings of the underlying architectural data and convey information of interest needed by specific user and/or decision makers.

The Six (6) Step are:

  • Step 1: Determine Intended Use of Architecture
  • Step 2: Determine Scope of Architecture
  • Step 3: Determine Data Required to Support Architecture Development
  • Step 4: Collect, Organize, Correlate, and Store Architectural Data
  • Step 5: Conduct Analyses in Support of Architecture Objectives
  • Step 6: Document Results in Accordance with Decision-Maker Needs

Step 1: Determine Intended Use of Architecture
Defines the purpose and intended use of the architecture (“Fit-for-Purpose”); how the Architectural Description effort will be conducted; the methods to be used in architecture development; the data categories needed; the potential impact on others; and the process by which success of the effort will be measured in terms of performance and customer satisfaction. This information is generally provided by the process owner to support architecture development describing some aspect of their area of responsibility (process, activity, etc.).

Step 2: Determine Scope of Architecture
The scope defines the boundaries that establish the depth and breadth of the Architectural Description and establish the architecture’s problem set, helps define its context and defines the level of detail required for the architectural content.

Step 3: Determine Data Required to Support Architecture Development Determines
The required level of detail to be captured for each of the data entities and attributes. This includes the data identified as needed for execution of the process, and other data required to effect change in the current process. The initial type of architectural data content to be collected is determined by the established scope of the Architectural Description, and recorded as attributes, associations, and concepts as described in the DoDAF Meta Model (DM2). This step is normally completed in conjunction with Step 4, a bottom-up approach to organized data collection, and Architectural Description development typically iterates over these two steps.

Step 4: Collect, Organize, Correlate, and Store Architectural Data
Architects typically collect and organize data through the use of architecture techniques designed to use views for presentation and decision-making purposes. The architectural data should be stored in a recognized commercial or government architecture tool. Terms and definitions recorded are related to elements of the (DM2).

Step 5: Conduct Analyses in Support of Architecture Objectives
Architectural data analysis determines the level of adherence to process owner requirements. This step may also identify additional process steps and data collection requirements needed to complete the Architectural Description and better facilitate its intended use. Validation applies the guiding principles, goals, and objectives to the process requirement, as defined by the process owner, along with the published performance measures (metrics), to determine the achieved level of success in the Architectural Description effort. Completion of this step prepares the Architectural Description for approval by the process owner.

Step 6: Document Results in Accordance with Decision-Maker Needs
The final step in the architecture development process involves creation of architectural views based on queries of the underlying data. Presenting the architectural data to varied audiences requires transforming the architectural data into meaningful presentations for decision-makers. This is facilitated by the data requirements determined in Step 3, and the data collection methods employed during Step 4.

DoDAF provides for models and views. DoDAF-described Models are those models that enable an architect and development team whose data has already been defined and described consistent with the DM2. The models become views when they are populated with architectural data.

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/20/2017

DoDAF Architecting

DoDAF Architecting Overview

Architecting is a tool used by Program Managers (PM) and Systems Engineers in developing a system to help designers meet all stated function and physical requirements, collaborate across organizations and provides value information for decision makers. There are a number of types of Architectures that are used in system development:

  • Functional Architecture: model that identifies system function and their interactions.
  • Physical Architecture: model that addresses the physical layout of a system and its components in a schema.
  • Reference Architecture: model that guides and constrains the development of architectures.
  • Enterprise Architecture: model that describes the current and/or desired relationships between an organization’s business, mission and management processes, and the supporting infrastructure.

DoD Architecture Framework (DoDAF)
In the Department of Defense (DoD), the development of an architecture for a system is called the DoD Architecture Framework (DoDAF). DoDAF is the overarching, comprehensive framework and conceptual model enabling the development of architectures for DoD systems. The DoDAF serves as one of the principal pillars supporting the DoD Chief Information Officer (CIO) in his responsibilities for development and maintenance of architectures required under the Clinger-Cohen Act. There are 6 steps that make up the DoDAF Design Process. These steps are:

  • Step 1: Determine Intended Use of Architecture
  • Step 2: Determine Scope of Architecture
  • Step 3: Determine Data Required to Support Architecture Development
  • Step 4: Collect, Organize, Correlate, and Store Architectural Data
  • Step 5: Conduct Analyses in Support of Architecture Objectives
  • Step 6: Document Results in Accordance with Decision-Maker Needs

Guide: DoDAF Architecture Framework Version 2.02

Website: DoDAF Architecture Framework Version 2.02

The documented results of the DoDAF process are organizes into the following Viewpoints (aka Architecture Types):

  • All Viewpoint (AV): describes the overarching aspects of architecture context that relate to all viewpoints.
  • Capability Viewpoint (CV): articulates the capability requirements, the delivery timing, and the deployed capability.
  • Data and Information Viewpoint (DIV): articulates the data relationships and alignment structures in the architecture content for the capability and operational requirements, system engineering processes, and systems and services.
  • Operational Viewpoint (OV): includes the operational scenarios, activities, and requirements that support capabilities.
  • Project Viewpoint (PV): describes the relationships between operational and capability requirements and the various projects being implemented.
  • Services Viewpoint (SvcV): is the design for solutions articulating the Performers, Activities, Services, and their Exchanges, providing for or supporting operational and capability functions.
  • Standards Viewpoint (StdV): articulates the applicable operational, business, technical, and industry policies, standards, guidance, constraints, and forecasts that apply to capability and operational requirements, system engineering processes, and systems and services.
  • Systems Viewpoint (SV): for Legacy support, is the design for solutions articulating the systems, their composition, interconnectivity, and context providing for or supporting operational and capability functions.
   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

Other topics that should be known by PM with regards to Architecting include:

 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