Synthesizing DoDAF Architectures to Develop the Joint Capability Enterprise
Architecture
James R. Enos, U.S. Military Academy
309 Lannon Ct., Alexandria, VA 22304
(719) 205-2395
[email protected]
Abstract
As part of the Joint Capability Integration and Development System (JCIDS) process, the
Department of Defense (DoD) requires DoD Architecture Framework (DoDAF) compliant
architectures be submitted with the various capability documents. Although the architectural
data is stored in a central repository, the DoD has not been able to take advantage of this data to
build an enterprise level capability architecture, reuse architectural data from previous
capabilities, or conduct data driven architectural analysis on the impact a capability has to the
overall enterprise architecture. Previous work has validated this shortfall and recommended
potential methods for aggregating DoDAF architectures; however, none have been able to
accomplish this task to date. With advanced in system architecture tools and computing power,
analysts are able to consolidate and analyze massive amounts of data. This capability is essential
for developing a joint capability enterprise architecture that aggregates multiple DoDAF
architecture products. This paper presents an initial methodology for integrating multiple
DoDAF architectures across the DoD to develop an enterprise level architecture. It leverages
several previous efforts that have described potential methodologies for aggregating
architectures, managing portfolios of architectures, and analyzing systems of systems.
Additionally, it takes advantage of the DoDAF meta-model and data standards to automate the
aggregation of the DoDAF compliant architectures in order to capture the enterprise architecture.
This paper presents potential applications of network analysis techniques and methods to identify
risks to the enterprise, opportunities to improve the robustness of the enterprise, and potential
redundancies in capabilities.
Synthesizing DoDAF Architectures to Develop the Joint Capability Enterprise
Architecture
James R. Enos, U.S. Military Academy
309 Lannon Ct., Alexandria, VA 22304
(719) 205-2395
[email protected]
1. Introduction
The Department of Defense (DoD) manages acquisitions through a capability based
process known as the Joint Capability Integration and Development System (JCIDS). The DoD
designed the system to ensure that verified and validated capabilities exist prior to expending
valuable resources on programs. As part of the process, the DoD requires DoD Architecture
Framework (DoDAF) compliant architectures be submitted with the various capability
documents. Although the architectural data is stored in a central repository, the DoD has not
been able to take advantage of this data to build an enterprise level capability architecture, reuse
architectural data from previous capabilities, or conduct data driven architectural analysis on the
impact a capability has to the overall enterprise architecture. Previous work has validated this
shortfall and recommended potential methods for aggregating DoDAF architectures; however,
none have been able to accomplish this task to date. With advanced in system architecture tools
and computing power, analysts are able to consolidate and analyze massive amounts of data.
This capability is essential for developing a joint capability enterprise architecture that
aggregates multiple DoDAF architecture products.
This paper presents an initial methodology for integrating multiple DoDAF architectures
across the DoD to develop an enterprise level architecture. It leverages several previous efforts
that have described potential methodologies for aggregating architectures, managing portfolios
of architectures, and analyzing systems of systems. It takes advantage of the DoDAF metamodel and data standards to automate the aggregation of the DoDAF compliant architectures in
order to capture the enterprise architecture. The methodology is based in enterprise architecture
methodologies and examines system, capability, and mission dependencies of programs that are
identified through DoDAF products. Additionally, future work based on this paper could include
applications of network analysis techniques and methods to identify risks to the enterprise,
opportunities to improve the robustness of the enterprise, and potential redundancies in
capabilities.
2. Background Literature
This section provides a summary of the literature related to the Joint Capability
Integration and Development System, as well as a review of the literature for the Department of
Defense architecture. The review describes the history behind the JCIDS process, a detailed
description of the process, and the linkage to the JCAs. Additionally, the review describes the
DoDAF architectural views and previous efforts to aggregate DoDAF products to gain insights
into the enterprise.
2.1 JCIDS Process
The 2003 Joint Defense Capability Study first presented the concept of Joint Capability
Areas (JCAs) as it proposed the DoD transition from a requirements based acquisition process to
a capability based approach [1]. The study found that programs focused too narrowly on a single
requirement for a single scenario and that throughout the process scope creep increased the cost
and schedule of a program to an unacceptable level. To prevent this and to focus more broadly
on capabilities that could be applied to a range of military operations, the department changed
from to a capability based process to acquire new programs [1].
The DoD established the JCIDS process to support the Chairman and the Joint
Requirements Oversight Committee’s responsibilities to identify, assess, validate, and prioritize
joint military capability requirements [2]. As part of this process, services generate three main
documents: Initial Capability Document (ICD), Capability Development Document (CDD), and
the Capability Production Document (CPD). Each of these documents support different phases
in the development of a technology and provide traceability from warfighter needs to fielded
systems [3]. Additionally, the JCIDS documents support the Defense Acquisitions System
(DAS) as a program progresses through each phase of acquisition. Figure 1 depicts how the
JCIDS documents support the DAS at initiation and in support of milestones B and C in the
process.
Figure 1: JCIDS and DAS Process [3]
Each of the JCIDS documents provides data that is essential to capturing the Joint
Capability Enterprise Architecture. The ICD specifies a capability requirement, derived from
warfighter needs, and identifies any gaps in capability based on current systems. The CDD
provides additional detail on the capability requirement and specifies key performance
parameters that potential solution must achieve to close the capability gap identified in the ICD.
Finally, the CPD specifies capability requirements that support the production of a single
material solution to close the gap [3]. In the process multiple CDDs and CPDs may be traced
back to a single ICD; however, they all must have traceability back to a validated ICD.
2.2 DoDAF
Maier and Rechtin describe a system’s architecture as a description of “whatever aspects
of physical structure, behavior, cost, human organization, or other elements are needed to clarify
the client’s priorities” [4]. Architecture frameworks serve as a communication tool for managing
the complexity of systems by presenting a manageable amount of information to a stakeholder
from a common set of data [5]. The DoDAF is one of many frameworks that architects use to
capture multiple perspectives on a system’s architecture. These frameworks include specific
taxonomies, artifacts, terminology, and taxonomies for describing a system’s architecture to
ensure standardization across multiple architectures [6]. DoDAF specifies 8 different viewpoints
to capture data relevant capability development, integration of systems, military operations, and
the development program management aspects of a system.
Figure 2: DoDAF 2.02 Viewpoints [7]
Figure 2 presents the DoDAF 2.02 viewpoints which include: All, Data and Information,
Standards, Capability, Operational, Services, Systems, and Project viewpoints. The DoD
designed DoDAF to meet the needs of a diverse set of stakeholders involved in the development,
validation, delivery, and sustainment of warfighting capabilities. The intent of the DoDAF is to
assist decision makers by abstracting essential pieces of information and presenting them in
manageable pieces depending on the stakeholder’s perspective [7]. DoDAF products are
required as part of the JCIDS process and provide valuable information and data on individual
systems; however, they must be aggregated to understand the capability of the entire Joint
Capability Enterprise.
2.3 Aggregating DoDAF products
One of the main shortfalls of the DoDAF in its current application is that it is not used to
capture an enterprise perspective of the different systems that interact to provide value to the
warfighters. Some efforts have attempted to aggregate DoDAF products along different mission
threads or areas; however, they have not attempted to look at the entire enterprise. This
enterprise perspective becomes important as decision makers must gain an understanding of the
“as-is” architecture and the impacts a proposed system has on the enterprise. Additionally,
systems engineers within the DoD have identified shortfalls in DoDAF applications that would
help them in the development of systems.
The National Defense Industrial Association’s Systems Engineering Division charted an
Architecture Frameworks Working Group (AFWG) to analyze the needs of systems engineers
within the DoD and provide recommended changes to the DoDAF to better address their needs.
Some of their findings directly support the ability to aggregate DoDAF products to capture the
enterprise level architecture. They recommended greater standardization of architectural
elements and the modeling methodology to permit greater sharing of architectural data. Also,
they recommended developing architectures that are easier to compose and decompose to
address the needs of stakeholders at different levels. This addresses the needs of the systems
engineers who do the detailed design of systems as well as the senior DoD leadership who are
making resourcing decisions based on capabilities [8].
One effort to aggregate DoDAF architectures is the Activity-Based Methodology that
established a common means of integrating DoD architecture information to support JCIDS and
the Clinger-Cohen Act. The intent of this methodology was to develop an understanding of both
the “as-is” and the “to-be” architectures by integrating the operational, system, and technical
views within DoDAF [9]. This method focused on the relationships between roles (systems),
information (data), and activities (system functions) across different architectures and the
interactions that combine to form the enterprise architecture. This method focused on the
organization, the system, and the role aspects of the architecture and began to synthesize DoDAF
products based on these elements [9]. This methodology is helpful in understanding how a datacentric view of the DoDAF products can help, but does not focus on the capability specific
questions this paper examines.
3. Methodology
This section describes the specific methodology for synthesizing DoDAF architectural
products and views in order to create an enterprise level architecture. It describes the emerging
field of enterprise architecture and the potential application to the DoDAF products.
Additionally, the section details how different DoDAF views can be aggregated to create an
enterprise level architecture. This architecture can then provide valuable insights to DoD
leadership on the system, capability, and mission dependencies between individual systems
within the enterprise.
3.1 Enterprise Architecture
Enterprise Architecture is an emerging field that applies holistic thinking to the design of
enterprises as systems with multiple interdependencies at the enterprise level. Nightingale and
Rhodes described Enterprise Architecture as “a new strategic approach which takes a systems
perspective, viewing the entire enterprise as a holistic system encompassing multiple views”
[10]. In this work, they view enterprises as complex, integrated systems that are inseparable
from their environment and architects must view enterprise systems holistically and optimize at
the system level, not in a traditional silo manner. To optimize the entire system, a holistic view
of the enterprise through several lenses is required. Over the last several years, Nightingale and
Rhodes have refined the views to include: strategy, policy/external factors, organization, process,
knowledge, information, product, and services [11]. Additionally, Enterprise Architecture
differs from traditional enterprise analysis methods in that it focuses on designing the enterprise
for value delivery [12].
Rouse proposed thinking of an enterprise as a system or system of systems and defined
an enterprise as “a goal-directed organization of resources—human, information, financial, and
physical—and activities, usually of significant operational scope, complication, risk, and
duration” [13]. He goes on to state that generally enterprise share the same goals of growth,
value, focus, change, future, knowledge, and time. Additionally, he proposes that models and
scientific tools can evaluate the performance of an enterprises’ as-is and to-be states [13]. Using
an enterprise architecture perspective, individual architectures can be synthesized to capture
these interdependencies.
3.2 System Dependencies
Systems are becoming more and more interconnected and the dependency network across
the DoD systems is growing in complexity. At the system level, the DoDAF does an adequate
job of identifying these interconnections with the SV-3 and the SV-6. The SV-3, System-System
Matrix, describes the relationships between systems and the SV-6, System Resource Flow
Matrix, provides details of the resource flows between systems [7]. These views provide a great
deal of detail on the first order connections of systems; however, to understand the true impacts a
system has on the enterprise, one must look past the first order connections to the second and
third order connections within the enterprise.
The SV-3, System-System Matrix, provides an excellent format for capturing these
dependencies at the enterprise level between systems. It enables an enterprise architect to map
the dependencies between multiple systems based on their individual DoDAF products.
Although a SV-6 would provide additional detail, the level of effort required to aggregate
individual SV-6s into an enterprise SV-6 may not provide enough value to the DoD leadership to
be worth the effort. The SV-3 provides a format for identifying binary links between different
systems within the enterprise. By capturing multiple system-to-system dependencies, the
enterprise level SV-3depicts second and third order dependencies within the enterprise.
Figure 3: System Dependency Identification
Figure 3 presents the methodology for synthesizing different system to system
dependencies based on data supplied by individual SV-3s and SV-6s. At the enterprise level, the
important information comes from identifying the actual dependences, in the SV-3. Although
additional value could be found from consolidating the SV-6s, which describe detailed
information flows between systems, it would require a great deal of effort until an automated
approach is developed to collate and manage these products. An enterprise level SV-3, which
identifies all system connections, within and potentially outside of the enterprise, would better
inform senior level decision makers on second and third order implications of resourcing
decisions to individual systems.
3.3 Identifying Capability Dependencies
The DoD manages programs through the JCA construct, so DoDAF products, especially
at the enterprise level must be able to address which capability areas individual systems provide
to the enterprise. Joint Capability areas are logical groupings of DoD capabilities that are used
for capability analysis, strategy development, investment decision making, capability portfolio
management, and capabilities-based force development. The DoD defines a capability as “The
ability to achieve a desired effect under specified standards and conditions through a
combination of means and ways across doctrine, organization, training, materiel, leadership and
education, personnel, and facilities (DOTMLPF) to perform a set of tasks to execute a specified
course of action” [14]. For the most part, JCAs are identified in the Initial Capability Documents
(ICD) and Capability Development Documents (CDD) for individual programs as part of the
JCIDS process. Additionally, architects can use the JCAs to develop their logical grouping of
capabilities in the CV-4, Capability Dependency view.
Figure 4: Capability Dependency Identification
Figure 4 presents the methodology for developing the CV-2 at the enterprise level.
Again, the detail required for an enterprise perspective on individual capability requirements is
not necessary and the JCAs provide an established frame of reference to bin different capabilities
into. By linking individual systems within the enterprise to the respective JCAs, an architect can
depict the capabilities of the overall enterprise. Additionally, there is the potential to identify
unnecessary redundancy; maybe an enterprise has multiple systems that all provide the same or
similar capability. Or, it may identify gaps in capability, in which an enterprise only has one or
no systems that provide the capability as defined by the JCAs.
3.4 Identifying Mission Dependencies
One of the important questions that DoDAF products should be able to answer is how do
these systems work together to accomplish a given mission? The key to linking systems to
missions are the Universal Joint Tasks (UJT). The UJTs provide a list of tasks, or warfighting
functions, that a program or organization executes to support the joint warfighting mission [15].
The UJTs are divided into four major areas, Strategic National, Strategic Theater, Operational,
and Tactical. These tasks are further decomposed into various levels to provide greater fidelity
on the tasks. Additionally, the joint staff has identified how each task supports the capability
areas as part of the capability development process. These tasks are used in the development of
operational missions and concepts of operations (CONOPs). Within the DoDAF, the OV-5a and
OV-5b provide the data required to identify which tasks each individual system performs.
Figure 5: Mission Dependency Identification
Figure 5 presents the methodology for identifying mission dependencies between
systems. By linking the data provided by the OV-5a and OV-5b views of the individual systems,
the enterprise architect can develop an understanding of all of the warfighting tasks that an
enterprise performs. This view will only provide a breakdown of the UJT tasks that are
performed by each enterprise. The architect can then incorporate additional information
provided by missions or CONOPs to develop an enterprise OV-5b. This could utilize swim lanes
to allocate individual tasks to systems within the enterprise over time based on the mission.
Again, this would provide an additional view to identify capability redundancies or gaps. For
example, based on looking at a specific mission, analysts may be able to identify tasks that
cannot be performed based on the current systems available.
4. Conclusion
This paper presents an initial methodology for synthesizing different system level
DoDAF products to capture the Joint Capability Enterprise Architecture. At this point, the
concept appears to provide value to DoD leadership as they assess capabilities and make
resourcing decisions. However, it is very manpower intensive at this point as the aggregation of
DoDAF products is manual. There is potential to take advantage of the DoDAF data standard to
automate this process and to generate enterprise views based on the architectural data of each
system. In a time of diminishing resources and reduced manpower, understanding the potential
for automated aggregation of this data in order to capture valuable information for decision
makers could provide a huge amount of value for the DoD.
As the methodology matures and more detail is added at the lower level JCAs and UJTLs
the department may be able to identify capability gaps given the current systems. This paper
provides a basis for future work in developing the enterprise level architecture for the DoD as it
examines capabilities, missions, and system dependencies. Eventually, it may be possible to
automate the synthesis of DoDAF products to capture the data required for a complete enterprise
architecture for the DoD. This will enable the DoD leadership to visualize the relationships
within the capability enterprise architecture of the DoD. Additionally, this work provides the
basis for potentially exploring how network analysis tools and methods could be used to
visualize and analyze the relationships between programs.
References
[1] The Joint Chiefs of Staff, "Joint Defense Capability Study: Improving DoD Strategic
Planning, Resourcing and Execution to Satisfy Joint Capabilities," Department of Defense,
Washington, D.C., 2004.
[2] Joint Chiefs of Staff, CJCSI 3170.01H: Joint Capabilities Integration and Development
System, Washington, DC: Department of Defense, 2012.
[3] Joint Chiefs of Staff, Manual for the Operation of the Joint Capabilities Integration and
Development System, Washington DC: Department of Defense, 2012.
[4] M. W. Maier and E. Rechtin, The Art of Systems Architecting, 2nd ed., New York, NY:
CRC Press, 2002.
[5] M. Richards, N. Shah, D. Hasting and D. Rhodes, "Managing Complexity with the
Department of Defense Architecture Framework: Development of a Dynamic System
Architecture Model," in Conference on Systems Engineering Research, Los Angeles, CA,
2006.
[6] S. Friedenthal, A. Moore and R. Steiner, A Practical Guide to SysML: The Systems
Modeling Language, New York, NY: Morgan Kaufmann OMG Press, 2012.
[7] DoD Chief Information Officer, "DoD Architecture Framework Version 2.02," August 2010.
[Online]. Available: http://www.dodcio.defense.gov/dodaf20.aspx. [Accessed March 2014].
[8] Architecture Frameworks Working Group, "DoDAF Satisfaction of Systems Engineering
Needs," National Defense Industrial Association, Washington, D.C., 2009.
[9] S. Ring, D. Nicholson, J. Thilenius and S. Harris, "An Activity-Based Methodology for
Development and Analysis of Integrated DoD Architectures - "The Art of Architecture","
MITRE, Bedford, MA, 2004.
[10] D. Nightingale and D. Rhodes, "Enterprise Systems Architecting: Emerging Art and Science
within Engineering Systems," in MIT Engineering Systems Symposium, Cambridge, MA,
2004.
[11] D. Rhodes, A. Ross and D. Nightingale, "Architecting the System of Systems Enterprise:
Enabling Constructs and Methods from the Field of Engineering Systems," in SysCon2009 –
IEEE International Systems Conference, Vancouver, Canada, 2009.
[12] T. Allen, D. Nightingale and E. Murman, Engineering Systems: An Enterprise Perspective,
Cambridge, MA: MIT Engineering Systems Division, 2004.
[13] W. Rouse, Enterprises as Systems: Essential Challenges and Approaches to Transformation,
Atlanta, GA: Georgia Institute of Technology, 2005.
[14] Department of Defense, "Department of Defense Directive 7045.20," Department of
Defense, Washington, DC, 2008.
[15] Joint Chiefs of Staff, "UJTL Task Development Tool," 1 Aprils 2010. [Online]. Available:
https://utdt.js.mil/.
[16] M. Maier and E. Rechtin, The Art of Systems Architecting, Second ed., New York, NY:
CRC Press, 2002.
[17] Joint Chiefs of Staff, "Joint Defense Capability Study: Improving DoD Strategic Planning,
Resourcing and Execution to Satisfy Joint Capabilities," Department of Defense,
Washington, DC, 2003.
[18] Joint Chiefs of Staff, "Joint Force Capabilities Assessment," Department of Defense,
Washington, DC, 2005.
[19] Office of the Secreatary of Defense, "Memorandum for the Vice Chairman of the Joint
Chiefs of Staff: Joint Capability Area (JCA) 2010 Refinement," Department of Defense,
Washington, DC, 2011.
[20] Joint Chiefs of Staff, "Capability Based Assessment (CBA) User Guide," Department of
Defense, Washington, DC, 2006.
[21] D. Nightingale and D. Rhodes, ESD.38J Enterprise Architecture, Cambridge, MA:
Massachusetts Institute of Technology, 2007.
[22] Joint Chiefs of Staff, CJCSI 5123.01F Charter of the Joint Requirements Oversight
Committee, Washington, DC: Department of Defense, 2012.
[23] US Code, Title 10, Section 181, "Joint Requirements Oversight Committee", Washington
DC.
[24] Joint Chiefs of Staff, CJCSI 3137.01D The Functional Capabilities Board, Washington DC:
Department of Defense, 2009.
Biography
Major James Enos is currently serving as the Systems Engineering Branch Chief in the Joint
Requirements Assessment Division on the Joint Staff. He previously served as an assistant
professor in the Department of Systems Engineering at the United States Military Academy,
West Point, NY. Throughout his military service, he has held numerous leadership positions as
an infantry officer, including Rifle Company Commander, Ranger Instructor, and Platoon
Leader. He graduated from the US Military Academy at West Point in 2000 with a Bachelor of
Science degree in Engineering Management. He earned his Master's of Science in Engineering
and Management in 2009 from the Systems Design and Management program at MIT. He
developed and taught classes in modeling and simulation, systems engineering, systems
architecture, and system dynamics.