NDIA SE Architecture Committee March 13, 2013
Page 12 of 22
Some of the limitations were identified in a previous 2009 NDIA study “DoDAF Satisfaction of
Systems Engineering Needs.”
6
The “Context and Scope” for a limitations discussion
In many cases, managers develop DoDAF products as a result of a directive, instruction or guide
that—in effect—mandates DoDAF usage. Thus products are developed to “check off the box.”
Ideally, we would hope that program or acquisition managers would want to employ
architectures as a desired best practice and value-added part of their work to achieve tangible
benefits such as improve performance, facilitate interoperability, save resources, and reduce lead
times. But, in many instances, DoDAF is not fully used in this manner. Why?
To better understand DoDAF usage, a survey
7
was conducted in 2008 (pre-DODAF 2.0) of 18
organizations, many overseeing multiple projects. The results are shown in Figure 4-1. Albeit a
small sample size, the results do indicate that certain DoDAF views have become pervasive such
as the OV-1 High-Level Operation Concept graphic, AV-1 Overview and Summary, OV-5
Operational Activity Model (a process flow and hierarchical model), AV-2 Integrated Dictionary
(definitions), OV-2/OV-3/SV-6 effectively Information Exchange Requirements (IERs), SV-
1/SV-2 system interface/wiring diagrams, and StdV-1 Standards View. Certainly generation of
these types of products, within any design framework, make sense. But, not surprisingly, the
results indicate that many other types of views are not widely used. It is also not clear how many
artifacts were originally developed using non-DoDAF methods that were later tailored to meet a
DoDAF “check-off-the-box” requirement. More recent surveys to provide statistics on DoDAF
2.0, especially related to DM2 usage, have not been conducted, but would be desirable.
Relationship with Solution Development and System Engineering
There exists a perceived disconnect between enterprise architecture and solution development.
The belief is that those who develop architecture frameworks are in one world while system
engineers reside in another. There appears to be a lack of understanding in industry of how
architecture is an integral part of the systems engineering process to enable model based design.
Appropriate application of DoDAF in conjunction with system engineering efforts is often
misunderstood, especially in relating DoDAF to widely-used Model-Based System Engineering
(MBSE). Historically much work has been done showing the inter-relationships of DoDAF
views, but not as much to show how views and data relate to specific systems engineering
techniques and acquisition procedures.
8
However, DoDAF is referenced and used as part of the
Systems and Software Engineering Defense Acquisition Program Support Methodology, Version
2.0, Office of the Deputy Under Secretary of Defense for Acquisition and Technology, Systems
and Software Engineering.
6
“DoDAF Satisfaction of Systems Engineering Needs,” Analysis Conclusions, and Recommendations of the Architecture
Frameworks Working Group, Systems Engineering Division, National Defense Industrial Association, 6 November 2009
7
DODAF Product Development Questionnaire Analysis Report and New Product Recommendations Report, Arlington,
VA, 5 May 2008 Version 4
8
For one example of where DoDAF and system engineering have been linked see DoD Architecture Framework – A Guide
to Applying System Engineering to Develop Integrated, Executable Architectures, Steven H. Dam, Ph.D., 2006