Back to Top

Defense Acquisitions Made Easy

Blog Archives

DoDAF Architecting

StdV-1 Standards Profile

The Standards Viewpoint (StdV) StdV-1 defines the technical, operational, and business standards, guidance, and policy applicable to the architecture being described. It also documents the policies and standards that apply to the operational or business context.

The intended usage of the StdV-1 includes:

  • Application of standards (informing project strategy).
  • Standards compliance.

Guide: DoDAF Architecture Framework Version 2.02 – Page 197

In most cases, building a Standards Profile consists of identifying and listing the applicable portions of existing and emerging documentation. A StdV-1 should identify both existing guidelines, as well as any areas lacking guidance. As with other models, each profile is assigned a specific timescale (e.g., “As-Is”, “To-Be”, or transitional). Linking the profile to a defined timescale enables the profile to consider both emerging technologies and any current technical standards that are expected to be updated or become obsolete. If more than one emerging standard time-period is applicable to an architecture, then a StdV-2 “Standards Forecast” should be completed as well as a StdV-1.

The StdV-1 collates the various systems and services, standards, and rules that implement and constrain the choices that can be or were made in the design and implementation of an Architectural Description. It delineates the systems, services, Standards, and rules that apply. The technical standards govern what hardware and software may be implemented and on what system. The standards that are cited may be international such as ISO standards, national standards, or organizational specific standards. With associated standards with other elements of the architecture, a distinction is made between applicability and conformance. If a standard is applicable to a given architecture, that architecture need not be fully conformant with the standard. The degree of conformance to a given standard may be judged based on a risk assessment at each approval point.

DoD Information Technology Standards and Profile Registry (DISR):
DoD Information Technology Standards and Profile Registry (DISR) (Secured) Online repository for a minimal set of primarily commercial IT standards. The DISR can be used to populate the Standards models (StdV-1 and StdV-2) of the Architecture. Conversely, the Standards Models can identify additional or new standards that need to be added to DISR.

   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

PV-1 Project Portfolio Relationships

The PV-1 “Project Portfolio Relationships” represents an organizational perspective on programs, projects, portfolios, or initiatives. It enables the user to model the organizational structures needed to manage programs, projects, portfolios, or initiatives. It shows dependency relationships between the actual organizations that own the programs, projects, portfolios, or initiatives. This model could be used to represent organizational relationships associated with transformation initiatives along with those who are responsible for managing programs, projects, and portfolios. The PV-1 provides a means of analyzing the main dependencies between acquisition elements or transformation elements.

Guide: DoDAF Architecture Framework Version 2.02 – Page 162

The intended usage of the PV-1 includes, but is not limited to:

  • Program management (specified acquisition program structure).
  • Project organization.
  • Cross-cutting initiatives to be tracked across portfolios.

The PV-1 describes how acquisition projects are grouped in organizational terms as a coherent portfolio of acquisition programs or projects, or initiatives related to several portfolios. The PV-1 provides a way of describing the organizational relationships between multiple acquisition projects or portfolios, each of which are responsible for delivering individual systems or capabilities. By definition, this model covers acquisition portfolios or programs consisting of multiple projects and is generally not for an individual project. In essence, PV-1 is an organizational breakdown consisting of actual organizations (see OV-4 “Organizational Relationships Chart”). The model is strongly linked with the CV-4 “Capability Dependencies” model which shows capability groupings and dependencies. The PV-1 is hierarchical in nature. Higher-level groupings of projects (the organizations that own these projects) form acquisition programs or initiatives.

The intent of a PV-1 is to show:

  • All of the acquisition projects delivering services, systems, or SoS within the acquisition programs under consideration.
  • Cross-cutting initiatives to be tracked across portfolios.
  • Other services, systems, and SoS which may have a bearing on the architecture. How the services or systems will be best integrated into an acquisition program.
  • The nesting of acquisition programs to form a hierarchy.
   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:

UpdatedL 9/27/2017

DoDAF Architecting

PV-3 Project to Capability Mapping

The PV-3 “Project to Capability Mapping” supports the acquisition and deployment processes, including the management of dependencies between projects and the integration of all relevant project and program elements to achieve a capability. It maps programs, projects, portfolios, or initiatives to capabilities to show how the specific elements help to achieve a capability. Programs, projects, portfolios, or initiatives are mapped to the capability for a particular timeframe. Programs, projects, portfolios, or initiatives may contribute to multiple capabilities and may mature across time. The analysis can be used to identify capability redundancies and shortfalls, highlight phasing issues, expose organizational or system interoperability problems, and support program decisions, such as when to phase out a legacy system.

Guide: DoDAF Architecture Framework Version 2.02 – Page 166

The intended usage of the PV-3 includes:

  • Tracing capability requirements to projects
  • Capability audit

The PV-3 describes the mapping between capabilities and the programs, projects, portfolios, or initiatives that would support the capabilities. This model may be used to indicate that a project does or does not fulfill the requirements for a capability for a particular phase. This model is analogous to the SV-5a “Operational Activity to System Function Traceability Matrix”, but provides the interface between Capability and Project Models rather than Operational to System Models.

In principle, there could be a different PV-3 table created for each development phase of the program, project, portfolio, or initiative development, or perhaps for different phasing scenarios. In most cases, a single table can be constructed because the programs, projects, portfolios, or initiatives that are most likely relevant to this model can be relatively high level. If capabilities associated are generic (see CV-1 Vision Model), then they should have a well understood relationship with a set of programs, projects, portfolios, or initiatives and this relationship is unlikely to change over time.

The PV-3 can have a tabular presentation. The rows can be the Capabilities and the columns can be the programs, projects, portfolios, or initiatives. An X can indicate where the capability is supported by the programs, projects, portfolios, or initiatives whereas a blank can indicate that it does not. Alternatively, a date or phase can indicate when programs, projects, portfolios, or initiatives will support capabilities by the date or phase indicated.

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

Project Viewpoints

The Project Viewpoint (PV) describe how programs, projects, portfolios, or initiatives deliver capabilities and the organizations contributing to them and the dependencies between them. These models expand the usability of the DoDAF by including information about programs, projects, portfolios, or initiatives and relating that information to capabilities and other programs, projects, portfolios, or initiatives. This expands DoDAF’s support to include the portfolio management process. Different levels of cost data can be captured in the architecture based on the process-owners requirements.

There are three (3) PV are:

  1. PV-1 Project Portfolio Relationship
  2. PV-2 Project Timelines
  3. PV-3 Project to Capability Mapping

These models are especially applicable to the Programming Phase of the PPBE Process and it’s within this phase that the Program Objective Memorandum (POM) is developed. The POM seeks to construct a balanced set of programs that respond to the guidance and priorities of the Joint Programming Guidance (JPG) within fiscal constraints. When completed, the POM provides a fairly detailed and comprehensive description of the proposed programs. The information captured within the Project models can be used within the PPBE process to develop the POM.

The Project Models can be used to answer questions such as:

  • What capabilities are delivered as part of this project?
  • Are there other projects that either affect or are affected by this project?
  • To what portfolios do the projects or projects belong?
  • What are the important milestones relative to this project?
  • When can I expect capabilities to be rendered by this project to be in place?

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

Physical Architecture(arch)

 

The physical architecture is the physical layout of a system and its components in a schema.  It refers to some  representation of the structure or organization of the physical elements of the system.  The physical architecture should be part of the Allocated and Product Baselines.

WBS

SMC Systems Engineering Handbook Example – Page 25

The development of the physical architecture consists of one or more logical models or views of the physical solution. The logical models or views may consist of conceptual design drawings, schematics, and block diagrams that define the systems form and the arrangement of the system components and associated interfaces. The development of a physical architecture is an iterative and recursive process and will evolve together with the requirements and functional architecture. Development of the physical architecture is complete when the system has been decomposed down to lowest system element or configuration item level, and it is critical that this process identify the design drivers as early as possible. Therefore, it is imperative that the driving requirements be identified and the combined processes—Stakeholder Requirements Definition, Requirements Analysis, and Architecture Design—will provide key insights to risk early in the development life cycle, allowing for mitigating strategies. [1]

Key activities performed when developing a physical architecture and design include:

  • Analysis and synthesis of the physical architecture and the appropriate allocation,
  • Analysis of the constraint requirements,
  • Identify and define physical interfaces and components, and
  • Identify and define critical attributes of the physical components, including design budgets (e.g., weight, reliability) and open system principles.

AcqLinks and References:

DoDAF Architecting

PV-2 Project Timelines

The PV-2 “Project Timelines” provides a timeline perspective on programs. The PV-2 is intended primarily to support the acquisition and fielding processes including the management of dependencies between projects and the integration of DoD Directive 5000.1 “Defense Acquisition System” policies to achieve a successfully integrated capability. The PV-2 is not limited to the acquisition and fielding processes.

Guide: DoDAF Architecture Framework Version 2.02 – Page 164

The intended usage of the PV-2 includes:

  • Project management and control (including delivery timescales)
  • Project dependency risk identification
  • Management of dependencies
  • Portfolio management

The PV-2 provides an overview of a program or portfolio of individual projects, or initiatives, based on a timeline. Portfolios, Programs, Projects, and Initiatives may be broken into work streams to show the dependencies at a lower-level. For capability-based procurement, these work streams might conveniently be equated with JCA. Sometimes, however, it is more appropriate to consider these acquisition projects in their own right.

Where appropriate, the PV-2 may also summarize, for each of the projects illustrated, the level of maturity achieved across the DoDD 5000.1 policies at each stage of the Defense Acquisition System lifecycle, and the interdependencies between the project stages.

The PV-2 is intended primarily to support the acquisition and fielding processes including the management of dependencies between projects and the integration of DoDD 5000.1 policy to achieve a successfully integrated capability. However, the PV-2 is not limited to the acquisition and fielding processes. The information provided by the Model can be used to determine the impact of either planned or unplanned programmatic changes, and highlight opportunities for optimization across the delivery program. The inclusion of the DoDD 5000.1 policy information allows areas of concern that are outside the immediate scope being considered. Areas of concern identified across the DoDD 5000.1 Defense Acquisition System policies, e.g., a shortfall in training resource, can be coordinated across a program or group of projects, each of which require additional activity to be initiated for successfully delivery according to the project/program schedule.

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-6b State Transition Description

The OV-6b “State Transition Description” is a graphical method of describing how an Operational Activity responds to various events by changing its state. The diagram represents the sets of events to which the Activities respond (by taking an action to move to a new state) as a function of its current state. Each transition specifies an event and an action.

Guide: DoDAF Architecture Framework Version 2.02 – Page 156

An OV-6b can be used to describe the detailed sequencing of activities or work flow in the business process. The OV-6b is particularly useful for describing critical sequencing of behaviors and timing of operational activities that cannot be adequately described in the OV-5b Operational Activity Model. The OV-6b relates events and states. A change of state is called a transition. Actions may be associated with a given state or with the transition between states in response to stimuli (e.g., triggers and events).

The intended usage of the OV-6b includes:

  • Analysis of business events
  • Behavioral analysis.
  • Identification of 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/27/2017

DoDAF Architecting

OV-6c Event-Trace Description

The OV-6c “Event-Trace Description” provides a time-ordered examination of the Resource Flows as a result of a particular scenario. Each event-trace diagram should have an accompanying description that defines the particular scenario or situation. Operational Event/Trace Descriptions, sometimes called sequence diagrams, event scenarios, or timing diagrams, allow the tracing of actions in a scenario or critical sequence of events.

Guide: DoDAF Architecture Framework Version 2.02 – Page 158

The OV-6c can be used by itself or in conjunction with an OV-6b State Transition Description to describe the dynamic behavior of activities.

The intended usage of the OV-6c includes:

  • Analysis of operational events.
  • Behavioral analysis.
  • Identification of non-functional user requirements.
  • Operational test scenarios
   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-5a Operational Activity Decomposition Tree

The OV-5a “Operational Activity Model” and the OV-5b describe the operations that are normally conducted in the course of achieving a mission or a business goal. It describes operational activities (or tasks); Input/Output flows between activities, and to/from activities that are outside the scope of the Architectural Description.

Guide: DoDAF Architecture Framework Version 2.02 – Page 152

The OV-5a and OV-5b describes the operational activities that are being conducted within the mission or scenario. The OV-5a and OV-5b can be used to:

An Operational Activity is what work is required, specified independently of how it is carried out. To maintain this independence from implementation, logical activities and locations in OV-2 “Operational Resource Flow Description” are used to represent the structure which carries out the Operational Activities. Operational Activities are realized as System Functions (described in SV-4 “Systems Functionality Description”) or Service Functions (described in SvcV-4 Services Functionality Description) which are the how to the Operational Activities what, i.e., they are specified in terms of the resources that carry them out.

The intended usage of the OV-5a and OV-5b includes:

  • Description of activities and workflows
  • Requirements capture
  • Definition of roles and responsibilities
  • Support task analysis to determine training needs
  • Problem space definition
  • Operational planning
  • Logistic support analysis
  • Information flow analysis
   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-5b Operational Activity Model

The OV-5a and the OV-5b “Operational Activity Model” describe the operations that are normally conducted in the course of achieving a mission or a business goal. It describes operational activities (or tasks); Input/Output flows between activities, and to/from activities that are outside the scope of the Architectural Description.

Guide: DoDAF Architecture Framework Version 2.02 – Page 152

The OV-5a and OV-5b describes the operational activities that are being conducted within the mission or scenario. The OV-5a and OV-5b can be used to:

The OV-5b describes the operational, business, and defense portion of the intelligence community activities associated with the Architectural Description, as well as the:

  • Relationships or dependencies among the activities.
  • Resources exchanged between activities.
  • External interchanges (from/to business activities that are outside the scope of the model).

An Operational Activity is what work is required, specified independently of how it is carried out. To maintain this independence from implementation, logical activities and locations in OV-2 “Operational Resource Flow Description” are used to represent the structure which carries out the Operational Activities. Operational Activities are realized as System Functions (described in SV-4 “Systems Functionality Description”) or Service Functions (described in SvcV-4 Services Functionality Description) which are the how to the Operational Activities what, i.e., they are specified in terms of the resources that carry them out.

The intended usage of the OV-5a and OV-5b includes:

  • Description of activities and workflows
  • Requirements capture
  • Definition of roles and responsibilities
  • Support task analysis to determine training needs
  • Problem space definition
  • Operational planning
  • Logistic support analysis
  • Information flow analysis
   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