Back to Top

Defense Acquisitions Made Easy

Blog Archives

DoDAF Architecting

OV-6a Operational Rules Model

An OV-6a “Operational Rules Model” specifies operational or business rules that are constraints on the way that business is done in the enterprise. At a top-level, rules should at least embody the concepts of operations defined in OV-1 “High Level Operational Concept Graphic” and provide guidelines for the development and definition of more detailed rules and behavioral definitions that should occur later in the Architectural definition process.

Guide: DoDAF Architecture Framework Version 2.02 – Page 154

The intended usage of the OV-6a includes:

  • Definition of doctrinally correct operational procedures
  • Definition of business rules
  • Identification of operational constraints

At the mission-level, OV-6a may be based on business rules contained in doctrine, guidance, rules of engagement, etc. At lower levels, OV-6a describes the rules under which the architecture behave under specified conditions. Such rules can be expressed in a textual form. These rules are contrasted with the business or doctrinal standards themselves, which provide authoritative references and provenance for the rules (see StdV-1 Standards Profile). Operational Rules are statements that constrain some aspect of the mission or the architecture. Rules may be expressed in natural language (English) in one of two forms:

  • Imperative – a statement of what shall be under all conditions, e.g., “Battle Damage Assessment” (BDA) shall only be carried out under fair weather conditions.”
  • Conditional Imperative – a statement of what shall be, in the event of another condition being met. If battle damage assessment shows incomplete strike, then a restrike shall be carried out.
   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

OV-2 Operational Resource Flow Description

The OV-2 “Operational Resource Flow Description” applies the context of the operational capability to a community of anticipated users. The primary purpose of the OV-2 is to define capability requirements within an operational context. The OV-2 may also be used to express a capability boundary.

Guide: DoDAF Architecture Framework Version 2.02 – Page 144

New to DoDAF V2.02, the OV-2 can be used to show flows of funding, personnel and materiel in addition to information. A specific application of the OV-2 is to describe a logical pattern of resource information, funding, personnel, or materiel) flows. The logical pattern need not correspond to specific organizations, systems or locations, allowing Resource Flows to be established without prescribing the way that the Resource Flows are handled and without prescribing solutions.

The intended usage of the OV-2 includes:

  • Definition of operational concepts
  • Elaboration of capability requirements
  • Definition of collaboration needs
  • Applying a local context to a capability
  • Problem space definition
  • Operational planning
  • Supply chain analysis
  • Allocation of activities to resources

The OV-2 depicts Operational Needlines that indicate a need to exchange resources. The OV-2 may also show the location of Operational facilities or locations, and may optionally be annotated to show flows of information, funding, people or materiel between Operational Activities. The Operational Activities shown in an OV-2 may be internal to the architecture, or may be external activities that communicate with those internal activities. Use of OV-2 is intended to be logical. It is to describe who or what, not how.

   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

OV-4 Organizational Relationships Chart

The OV-4 “Organizational Relationship Chart” shows organizational structures and interactions and may be civil or military. The OV-4 exists in two (2) forms:

  1. Role-based (e.g., a typical brigade command structure) and
  2. Actual (e.g., an organization chart for a department or agency).

Guide: DoDAF Architecture Framework Version 2.02 – Page 150

 A role-based OV-4 shows the possible relationships between organizational resources. The key relationship is composition, i.e., one organizational resource being part of a parent organization. In addition to this, the architect may show the roles each organizational resource has, and the interactions between those roles.

An actual OV-4 shows the structure of a real organization at a particular point in time, and is used to provide context to other parts of the architecture such as AV-1 “Overview Summary” and the Capability Viewpoints (CV).

The intended usage of the role-based OV-4 includes:

    • Organizational analysis
    • Definition of human roles
    • Operational analysis

The intended usage of the actual OV-4 includes:

  • Identify architecture stakeholders
  • Identify process owners
  • Illustrate current or future organization structures

The intended usage of the actual OV-4 includes:

  • Identify architecture stakeholders
  • Identify process owners
  • Illustrate current or future organization structures

A typical OV-4 illustrates the command structure or relationships (as opposed to relationships with respect to a business process flow) among human roles, organizations, or organization types that are the key players in the business represented by the architecture. An actual OV-4 shows real organizations and the relationships between them.

   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

OV-3 Operational Resource Flow Matrix

The OV-3 “Operational Resource Flow Matrix” addresses operational Resource Flows exchanged between Operational Activities and locations. Resource Flows provide further detail of the interoperability requirements associated with the operational capability of interest. The focus is on Resource Flows that cross the capability boundary.

The intended usage of the OV-3 includes:

  • Definition of interoperability requirements

Guide: DoDAF Architecture Framework Version 2.02 – Page 148

The OV-3 identifies the resource transfers that are necessary to support operations to achieve a specific operational task. This model is initially constructed from the information contained in the OV-2 “Operational Resource Flow Description model”. But the OV-3 provides a more detailed definition of the Resource Flows for operations within a community of anticipated users.

The OV-3 identifies resource elements and relevant attributes of the Resource Flows and associates the exchange to the producing and consuming Operational Activities and locations and to the Needline that the Resource Flow satisfies. It’s one of a suite of operational models that address the resource content of the operational architecture (the others being OV-2 “Operational Resource Flow Description”, OV-5b “Operational Activity Model”, and DIV-2 “Logical Data Model“).

   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

Functional Architecture

A Functional Architecture is an architectural model that identifies system function and their interactions. It defines how the functions will operate together to perform the system mission(s). Generally, more than one architecture can satisfy the requirements. Usually each architecture and its set of associated allocated requirements have different cost, schedule, performance, and risk implications. The functional architecture is used to support functional and performance test development. It also supports development, along with the physical architecture, of verification tasks that are defined to verify the functional, performance and constraint requirements. A system will have a functional and Physical Architecture.

During the Functional Analysis and Allocation step, the functional requirements identified in the Requirements Analysis step are decomposes and their associated performance requirements into sub functions to the point that they can be unambiguously related to the system elements or products that make up the design that flows out of a later step. The result is often called the functional architecture. [1]
Functional Architecture

SMC Systems Engineering Handbook, Figure 15

In the Design Loop, synthesized designs are compared with the originating architectures and allocated requirements to assure compliance or to initiate re-evaluation. Sometimes it is necessary to drive toward optimal solutions by presenting various functional views including those that depict functional relationships with existing assets to enable more thorough assessments of plausible solutions. [1]

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

OV-1 High Level Operational Concept Graphic

The OV-1 “High Level Operational Concept Graphic” describes a mission, class of mission, or scenario. It shows the main operational concepts and interesting or unique aspects of operations. It describes the interactions between the subject architecture and its environment, and between the architecture and external systems. The OV-1 is the pictorial representation of the written content of the AV-1 “Overview and Summary Information”. Graphics alone are not sufficient for capturing the necessary architectural data.

Guide: DoDAF Architecture Framework Version 2.02 – Page 142

The OV-1 provides a graphical depiction of what the architecture is about and an idea of the players and operations involved. An OV-1 can be used to orient and focus detailed discussions. Its main use is to aid human communication, and it is intended for presentation to high-level decision-makers. The intended usage of the OV-1 includes:

  • Putting an operational situation or scenario into context.
  • Providing a tool for discussion and presentation; for example, aids industry engagement in acquisition.
  • Providing an aggregate illustration of the details within the published high-level organization of more detailed information in published architectures.
   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

DoDAF Meta Model (DM2)

The DoDAF Meta Model (DM2) defines architectural data elements and enables the integration and federation of Architectural Descriptions. It establishes a basis for semantic (i.e., understanding) consistency within and across Architectural Descriptions.

Website: DoDAF Meta Model (DM2)

The purposes of the DM2 are:

  • Establish and define the constrained vocabulary for description and discourse about DoDAF models (formerly “products”) and their usage in the 6 core processes
  • Specify the semantics and format for federated Enterprise Architecture (EA) data exchange between: architecture development and analysis tools and architecture databases across the DoD Enterprise Architecture (EA) Community of Interest (COI) and with other authoritative data sources
  • Support discovery and understandability of EA data:
    • Discovery of EA data using DM2 categories of information
    • Understandability of EA data using DM2’s precise semantics augmented with linguistic traceability (aliases)
  • Provide a basis for semantic precision  in architectural descriptions to support heterogeneous architectural description integration and analysis in support of core process decision making.

The DM2 supports the exchange and reuse of architectural information among Components, and Federal and Coalition partners, thus facilitating the understanding and implementation of interoperability of processes and systems. As the DM2 matures to meet the ongoing data requirements of process owners, decision makers, architects, and new technologies, it will to a resource that more completely supports the requirements for architectural data, published in a consistently understandable way, and will enable greater ease for discovering, sharing, and reusing architectural data across organizational boundaries.

To facilitate the use of information at the data layer, the DoDAF describes a set of models for visualizing data through graphic, tabular, or textual means. These views relate to stakeholder requirements for producing an Architectural Description.
DoDAF Meta Model (DM2)

What and Where is the DM2
In accordance with standard data modeling conventions, the DM2 has several levels, as shown in the figure below.

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

DoD Enterprise Architecture

An Enterprise Architecture (EA) describes the “current architecture” and “target architecture,” and provides a strategy that will enable an agency to transition from its current state to its target environment. The Office of Management and Budget defines enterprise architecture as the explicit description and documentation of the current and desired relationships among business and management processes and IT. [1]

All DoD architectures, including warfighter, intelligence, business process, and enterprise management architectures, are part of the DoD Enterprise Architecture (EA). The DoD EA is defined as a federation of descriptions that provide context and rules for accomplishing the mission of the Department. These descriptions are developed and maintained at the Department, Capability Area, and Component levels and collectively define the people, processes, and technology required in the “current” and “target” environments, and the roadmap for transition to the target environment. [1]

The DoD EA is part of the organizing construct of the DoD Information Enterprise.

DoD Enterprise Architecture

AcqLinks and References:

Updated: 9/1/2017

 

DoDAF Architecting

DIV-3 Physical Data Model

The DIV-3 defines the structure of the various kinds of system or service data that are utilized by the systems or services in the Architectural Description. The Physical Schema is one of the models closest to actual system design in DoDAF. It’s used to describe how the information represented in the DIV-2 “Logical Data Model” is actually implemented.

Guide: DoDAF Architecture Framework Version 2.02 – Page 137

While the mapping between the logical and physical data models is relatively straightforward, the relationship between the components of each model (e.g., entity types in the logical model versus relational tables in the physical model) is frequently one-to-many or many-to-many.

The intended usage of the DIV-3 includes:

  • Specifying the system/service data elements exchanged between systems and/or services, thus reducing the risk of interoperability errors.
  • Definition of physical data structure.
  • Providing as much detail as possible on data elements exchanged between systems, thus reducing the risk of interoperability problems.
  • Providing data structures for use in the system design process, if necessary.
  • Providing a common dictionary of data implementation elements (e.g., tables and records in a relational database schema) to consistently express models wherever physical-level data elements are included in the descriptions.
  • Providing as much detail as possible on the system or service data elements exchanged between systems, thus reducing the risk of interfacing errors.
  • Providing system and service data structures for use in the system and service design process, if necessary.

The DIV-3 is an implementation-oriented model that is used in the Systems Viewpoint and Services Viewpoint to describe how the information requirements represented in DIV-2 “Logical Data Model” are actually implemented. Entities represent:

Note: that DoDAF talks about information in the Operational Viewpoint and data in the System Viewpoint or Services Viewpoint. The intention of this distinction is that DIV-2 “Logical Data Model” describes information of importance to the business, (e.g., information products that might be referred to in doctrine, SOPs etc.) whereas DIV-3 describes data relevant at the system or service-level.

   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-2 Logical Data Model

The DIV-2 Logic Data Model allows analysis of an architecture’s data definition aspect, without consideration of implementation specific or product specific issues.  Another purpose is to provide a common dictionary of data definitions to consistently express models wherever logical-level data elements are included in the descriptions.

Guide: DoDAF Architecture Framework Version 2.02 – Page 135

Data definitions in other models include:

  • Data described in a DIV-2 may be related to Information in an OV-1 “High Level Operational Concept Graphic” or and Activity Resource (where the Resource is Data) flow object in an OV-5b “Operational Activity Mode”. This relation may be a simple subtype, where the Data is a proceduralized (structured) way of describing something. Recall that Information describes something. Alternatively, the relation may be complex using Information and Data whole-part (and overlap) relationships.
  • The DIV-2 information entities and elements can be constrained and validated by the capture of business requirements in the OV-6a “Operational Rules Model”. The information entities and elements modeled in the DIV-2 also capture the information content of messages that connect life-lines in an OV-6c “Event-Trace Description”.
  • The DIV-2 may capture elements required due to Standards in the StdV-1 Standards Profile or StdV-2 Standards Forecast.

The DIV-2 is a generalized formal structure in computer science. It directly reflects the paradigm or theory oriented mapping from the DIV-1 “Conceptual Data Model” to the DIV-2.

Possible Construction Methods:
DoDAF does not endorse a specific data modeling methodology. The appropriate way to develop a logical data model depends on the technology chosen as the main design solution (e.g., relational theory or object-orientation). For relational theory, a logical data model seems best described using an entity relationship diagramming technique. For Object-Oriented, a logical data model seems best described using Class and/or Object diagrams.

In either case, attention should be given to quality characteristics for the data model.

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