DoD Systems Engineering Guide For Systems of Systems 2008
DoD Systems Engineering Guide For Systems of Systems 2008
Systems of Systems
Version 1.0
August 2008
This publication is intended for use by program managers and systems engineers.
To submit questions or corrections, contact the Office of the Deputy Under Secretary of
Defense for Acquisition and Technology, Systems and Software Engineering,
3020 Defense Pentagon, Room 3B938, Washington, DC 20301-3020; [email protected],
703-695-7417.
Systems Engineering Guide for Systems of Systems
PREFACE
The Department of Defense (DoD) continually seeks to acquire, sustain, and manage
material and non-material solutions to address capability needs of the war fighter in
military operations and to provide efficient support and readiness in peacetime. A
growing number of military capabilities are achieved through a system of systems (SoS)
approach. As defined in the DoD Defense Acquisition Guidebook (DAG) [2008], an SoS
is “a set or arrangement of systems that results when independent and useful systems
are integrated into a larger system that delivers unique capabilities.”
This guide assumes an understanding of SE and is intended as a reference only and not
as a comprehensive SE manual. The Office of the Secretary of Defense (OSD) will
update the guide periodically to expand the scope of SoS SE topics addressed, to reflect
advances in SoS SE application, and to capture additional best practices and lessons
learned.
In keeping with its purpose to aid those working in SoS SE within the DoD, this guide
provides both high-level and detailed discussion of the SoS environment and associated
SE considerations. The table below provides a roadmap to this guide.
A comparison of systems and systems of systems from a management, operational, implementation, or Section 2
engineering/design considerations
A high level overview of SoS SE core elements as currently being performed on the pilot SoS programs Section 3
A detailed description of SoS SE core elements and how they relate to the DAG SE processes Section 4.1
A detailed description of how each DAG SE process supports SoS SE core elements Section 4.2
A high level summary of this version of the guide and plans for additional topics to be included in future Section 5
releases of this guide
iii
Systems Engineering Guide for Systems of Systems
CONTENTS
PREFACE................................................................................................................iii
FIGURES ...............................................................................................................vii
TABLES................................................................................................................ viii
ABBREVIATIONS AND ACRONYMS ...........................................................................ix
1. Introduction..................................................................................................... 1
1.1. Purpose....................................................................................................... 1
1.2. Background ................................................................................................. 1
1.3. Approach to Development of this Version of Guide.......................................... 2
1.4. Definition of Terms....................................................................................... 3
1.5. Types of SoS ............................................................................................... 4
1.6. Scope.......................................................................................................... 6
1.7. Related Areas .............................................................................................. 7
1.7.1 SoS Management ................................................................................ 7
1.7.2 Net-Centricity ..................................................................................... 8
1.7.3 Emergence ......................................................................................... 9
1.7.4 Modeling and Simulation.................................................................... 10
2. Comparison of Systems and Systems of Systems .............................................. 11
2.1. Management and Oversight ........................................................................ 11
2.2. Operational Environment ............................................................................ 13
2.3. Implementation of SoS ............................................................................... 13
2.4. Engineering and Design Considerations........................................................ 14
3. SoS and SoS SE In the DoD Today .................................................................. 16
3.1. DoD SoS Environment ................................................................................ 16
3.2. Core Elements of SoS SE ............................................................................ 17
3.3. Emerging Principles for SoS SE .................................................................... 21
3.4. Relationship of Current SE Technical and Technical Management Processes
to SoS SE Core Elements ............................................................................ 23
4. SE Processes Applied in SoS Environments ....................................................... 27
4.1. Core Elements of SoS SE ............................................................................ 29
4.1.1 Translating Capability Objectives ........................................................ 33
4.1.2 Understanding Systems and Relationships........................................... 36
4.1.3 Assessing Performance to Capability Objectives ................................... 43
4.1.4 Developing and Evolving an SoS Architecture ...................................... 47
4.1.5 Monitoring and Assessing Changes ..................................................... 54
4.1.6 Addressing Requirements and Solution Options ................................... 59
4.1.7 Orchestrating Upgrades to SoS........................................................... 66
4.2. SE Process Support for System of Systems Engineering................................. 72
4.2.1 Requirements Development ............................................................... 73
4.2.2 Logical Analysis................................................................................. 75
4.2.3 Design Solution................................................................................. 75
4.2.4 Implementation ................................................................................ 77
4.2.5 Integration ....................................................................................... 78
v
Systems Engineering Guide for Systems of Systems
FIGURES
vii
Systems Engineering Guide for Systems of Systems
TABLES
ix
Systems Engineering Guide for Systems of Systems
SE Systems Engineering
SEP Systems Engineering Plan
SIAP Single Integrated Air Picture
SIL System/Simulation/Software integration Laboratory
SMC Space and Missile Systems Center
SoS System of Systems or Systems of Systems
SR IPO Space Radar Integrated Program Office
T&E Test and Evaluation
TJTN Theater Joint Tactical Networks
TMIP-J Theater Medical Information Program - Joint
Systems Engineering Guide for Systems of Systems
1. Introduction
1.1. Purpose
The purpose of this guide is to address systems engineering (SE) considerations for
integrating independently useful systems into a larger system that delivers unique
capabilities—a system of systems (SoS)—within the Department of Defense (DoD).
Drawing from the lessons of current SoS SE practitioners, the guide is intended to
provide a resource for systems engineers who are supporting SoS work, particularly as
part of an SE team for an SoS. This initial version of the guide begins the process of
understanding and guiding SE for SoS. In some cases, given the limited understanding
in this area, the guide raises issues for awareness which may need to be addressed by
systems engineers doing SoS work, but it does not provide practical advice on the
issues. As experience with SoS grows, subsequent versions of the guide will expand in
scope and detail. This guide assumes an understanding of SE, including chapter 4,
“Systems Engineering” of the Defense Acquisition Guidebook (DAG) [DoD, 2004]. 1 This
guide is intended as a reference only and not as a comprehensive SE manual.
1.2. Background
Changes to both the requirements development [CJCS, 2007(1)] and acquisition
processes [DoD, 2003] have resulted in increased emphasis on addressing broad “user
capability needs” as a context for developing new systems. Requirements identification
and prioritization processes have been updated in response to the force development
community’s realization that decisions in these areas need to be made in a broader
capability or portfolio context [CJCS, 2007(2)]. Capabilities-based analyses have
become the basis for defining user needs. Acquisition roadmaps and, more recently,
capability portfolios are being explored as mechanisms for investment decisions [DoD,
2003]. With the adoption of a net-centric approach to information management,
developers recognize that systems operate in a broader context today than in the past
[DoD CIO, 2003]. Most importantly, changing threat situations increase the need for
flexibility and adaptability in the way the war fighters configure and apply suites of
systems to respond to changing situations [OUSD(AT&L), 2004(1)]. The notion of
“systems of systems” is becoming a critical perspective in thinking about systems.
1
Hereinafter referred to as “DAG chapter 4.”
1
Systems Engineering Guide for Systems of Systems
Army Battle Command ABCS Army Acquisition A digital battlefield that will be interoperable with theater,
System Program joint, and combined command and control systems
Air Operations Center AOC Air Acquisition Development of effective AOC weapons system as the
Force Program primary tool for commanding air and space power
Ballistic Missile Defense BMDS Joint Acquisition Integrated, global ballistic missile defense enterprise of
System Program interconnected sensors, battle managers, C2 systems and
weapons
USCG Command & Control C2 Coast Strategy Support transition plan to facilitate C2 and common
Convergence Convergence Guard operational picture (COP) systems convergence
Common Aviation Command & CAC2S Marine Acquisition Integrated modular, scalable and mobile C2 systems with
Control System Corps Program reduced footprint
Distributed Common Ground DCGS-AF Air Program Office Provides integrated intelligence information to the war
Station Force fighter
DoD Intelligence Information DoDIIS Intel DIA CIO Provide global enterprise access to intelligence data and
System Initiative services
Future Combat Systems FCS Army Program Office Army's modernization program consisting of a family of
systems, connected by a common network
Ground Combat Systems GCS Army Program Capability baseline to identify and assess differences
Executive Office between current force and future force requirements
PEO
Military Satellite MILSATCOM Joint AF Wing Planning, acquisition, and sustainment of space-enabled
Communications global communications capabilities to support National
Objectives
Naval Integrated Fire Control – NIFC-CA Navy SE Integrator in Provides Naval integrated air defense capability, utilizing
Counter Air PEO the full kinematic range of active missiles
National Security Agency NSA Intel Agency Developing and employing a net-centric enterprise system
with a focus is on adaptability and agility, modularity
Systems Engineering Guide for Systems of Systems
Naval Surface Warfare Center NSWCDD Navy Warfare Center Engineering, development, and integration of Navy Surface
Dahlgren Division SoS
Single Integrated Air Picture SIAP Joint Acquisition Improve the quality of the integrated air picture
Program
Space and Missile Systems SMC Air SE Authority Technical authority for Center engineering, technical,
Center Force test/evaluation, architecting, and mission assurance
activities
Space Radar SR Joint Acquisition Horizontally integrated SoS to provide high-volume space-
Program based intelligence products
Theater Joint Tactical TJTN Joint PEO Oversee, coordinate, and synchronize networked-
Networks communications systems
Theater Medical Information TMIP Joint Acquisition Provides integrated in-theater medical information
Systems – Joint Program capability
In addition, a set of research teams active in areas related to SoS SE provided input to
this version of the guide. These include researchers from the Massachusetts Institute
of Technology, the MITRE Corporation, the Purdue University School of Engineering, the
Software Engineering Institute, the Stevens Institute of Technology, the University of
Southern California, and the University of California at San Diego as well as a research
and policy team from Australia. These teams provided feedback on the draft guide and
input based on the results of their research as it applies to the guide’s contents. In
addition, several panels were held with the International Council on SE (INCOSE), and a
workshop was held with industry representatives under the auspices of the National
Defense Industrial Association (NDIA) SE division. Other industry representatives,
including Aerospace Industries Association (AIA), participated in the guide review
process.
The results and experiences of SE practitioners were emphasized in this version of the
guide since they most closely represent the perspective, circumstances, and concerns of
the guide’s primary target audience. The views of the research community and industry
have been critically important in understanding the limits of this version with respect to
the broader areas of SoS SE and in assessing the alignment of views between SoS SE
practitioners and researchers.
A capability is the ability to achieve a desired effect under specified standards and
conditions through combinations of ways and means to perform a set of tasks [CJCS,
2007(2)].
3
Systems Engineering Guide for Systems of Systems
This definition is included for completeness. FoS are fundamentally different from SoS
because, as CJCSI goes on to say, a family of systems lacks the synergy of a system of
systems. The family of systems does not acquire qualitatively new properties as a
result of the grouping. In fact, the member systems may not be connected into a
whole. This guide specifically addresses SoS, but some of its contents may apply to
FoS.
SoS systems engineering deals with planning, analyzing, organizing, and integrating
the capabilities of a mix of existing and new systems into an SoS capability greater than
the sum of the capabilities of the constituent parts [DoD, 2004(1)]. Consistent with the
DoD transformation vision and enabling net-centric operations (NCO), SoS may deliver
capabilities by combining multiple collaborative and autonomous-yet-interacting
systems. The mix of systems may include existing, partially developed, and yet-to-be-
designed independent systems.
In DoD and elsewhere, SoS can take different forms. Based on a recognized taxonomy
of SoS, there are four types of SoS which are found in the DoD today [Maier,1998;
Dahmann, 2008]. These are:
• Virtual. Virtual SoS lack a central management authority and a centrally agreed
upon purpose for the system-of-systems. Large-scale behavior emerges—and
Systems Engineering Guide for Systems of Systems
may be desirable—but this type of SoS must rely upon relatively invisible
mechanisms to maintain it.
• Collaborative. In collaborative SoS the component systems interact more or less
voluntarily to fulfill agreed upon central purposes. The Internet is a collaborative
system. The Internet Engineering Task Force works out standards but has no
power to enforce them. The central players collectively decide how to provide or
deny service, thereby providing some means of enforcing and maintaining
standards.
• Acknowledged. Acknowledged SoS have recognized objectives, a designated
manager, and resources for the SoS; however, the constituent systems retain
their independent ownership, objectives, funding, and development and
sustainment approaches. Changes in the systems are based on collaboration
between the SoS and the system.
• Directed. Directed SoS are those in which the integrated system-of-systems is
built and managed to fulfill specific purposes. It is centrally managed during
long-term operation to continue to fulfill those purposes as well as any new ones
the system owners might wish to address. The component systems maintain an
ability to operate independently, but their normal operational mode is
subordinated to the central managed purpose.
This characterization offers a framework for understanding SoS in the DoD today. With
the advent of networks and increased efforts to link systems for information sharing
across the battle space, most systems are part of virtual SoS. DoD net-centric policies
and strategies [DoD, 2003; DoD CIO, 2003; DoD CIO, 2005] have attempted to provide
crosscutting approaches to fostering information sharing in the absence of explicit
shared objectives or management. (See section 1.5.2)
As users and systems owners understand their interdependencies, there are increasing
examples of collaborative SoS where representatives of systems choose to work
together for their mutual benefit. Communities of interest (COI), where volunteers
come together to develop ways for shared interests to be addressed collaboratively by
participants working under their current structures, are a good example.
In a few cases, most notably Future Combat Systems, a common objective has driven
the development of the constituent systems from the outset. Systems in this category
therefore constitute a directed SoS.
In the DoD today we see a growing number of acknowledged SoS. Like directed SoS,
acknowledged SoS have recognized authorities and resources at the SoS level.
However, because an acknowledged SoS comprises systems that maintain independent
objectives, management, and resources, along with independent development
processes, these SoS are largely collaborative in practice. For systems in these SoS, in
particular, their normal operational mode is not subordinated to the central managed
purpose—a distinct feature of a directed SoS. Because defense acquisition and funding
5
Systems Engineering Guide for Systems of Systems
are still largely platform focused, many SoS do not have authority over the systems,
and they typically try to address SoS objectives by leveraging the developments of the
systems, which are normally more long-standing and better supported than the SoS.
Consequently, acknowledged SoS, like directed SoS, have objectives, management, and
funding without authority over the constituent systems. Like collaborative SoS, changes
in systems to meet SoS needs are based on agreement and collaboration, not top-down
authority from the SoS manager.
In this context, new efforts are under way to create structures or standing
organizations to address the higher-level capability needs and investments. DoD-wide
Capability Portfolio Managers (CPMs) have been created to address investments and
synchronization of capabilities across the DoD [DSD 2006]. The Army, in particular, is
exploring governance approaches to address SoS throughout its organization. The
Navy has recommended that the engineering needs be viewed as a hierarchy and that
the engineering needs at each level be recognized, defined, and addressed in the ways
that best suit the needs at each level. Finally, as more systems are integrated into
DoD’s net centric environment, information technology systems are evolving from sets
of individual systems to sets of services that work in different combinations to meet
different user needs. Work is needed to specifically address the issues of systems
engineering in net-centric enterprise systems.
1.6. Scope
This version of the guide focuses on acknowledged SoS that have SoS objectives,
management, and funding as well as constituent systems that have their own
independent objectives, management, and funding. The majority of the SoS identified
during the pilot phase fit this category, and as the DoD continues to address more
capability needs by leveraging existing investments under the current organizational
structures, it is likely that there will continue to be more SoS of this type. As
organizations recognize the need to provide standing organizational structures to align
objectives and authorities, the DoD may expect to see more directed SoS, and this
guide will be updated to address this.
The guide describes the core elements of SE as applied in today’s environment and
describes how the 16 Technical and Technical Management processes outlined in DAG
chapter 4 are employed in this SoS context (see section 4.1 and 4.2). The DAG
describes these 16 processes as the basic SE processes in the context of acquisition
Systems Engineering Guide for Systems of Systems
Since this guide addresses considerations for applying the 16 SE processes to core
elements of SoS SE, it should be used in conjunction with the DAG and not as a stand-
alone document. See the references for titles of DoD directives and instructions related
to SoS.
Management issues for SoS are sizable. Successful SoS management requires reaching
across organizational boundaries to establish an end-in-mind set of objectives and the
resourced plan. Experienced managers are needed in an SoS environment, which
requires considerable flexibility to negotiate among the competing interests in an SoS
environment.
SoS increases the complexity, scope, and cost of both the planning process and
systems engineering, and introduces the need to coordinate inter-program activities and
manage agreements among multiple program managers (PMs) as stakeholders who
may not have a vested interest in the SoS. The problems that need to be addressed
are large and complex and are not amenable to solution by better systems engineering
alone. Without a solid governance and management approach for an SoS, independent
authorities who oversee the multiple governance processes of DOD are unlikely to
accept guidance from a systems engineer they do not control, placing the systems
engineer in an untenable position in attempting to support an SoS. An
administrative/governance structure that addresses these realities will enable SoS SE to
be more effective in all phases of the processes as outlined in this document. This
document acknowledges these issues but does not make any recommendations for
changes to existing management and control structures to resolve inter-system issues,
7
Systems Engineering Guide for Systems of Systems
since these are beyond the scope of SE. However, attention is needed to improve SoS
administration and management.
These management issues have an impact on SE. At times, particularly in the DoD, the
discussion focuses on the need to clarify management relationships in these situations
as the best way to address the issues. Unfortunately, the fact that many systems play
a role in multiple SoS means that this is not easily accomplished. In the DoD, multi-
mission systems are especially valuable contributors to multiple different user
capabilities and can be important participants in multiple SoS. This is not likely to
change in the near future. In other applications beyond defense, systems or services
may be designed to be broadly useful and have as their business objective to support
numerous user applications. They naturally retain authority over decisions regarding
their development and are not likely to agree to limit themselves to one specific
customer. Consequently, the management issues posed by acknowledged SoS are likely
to persist, making it important to recognize the impact of these management
considerations on systems engineering and to address these technical issues.
Acknowledged SoS by definition have managers and resources which coexist with
managers of the systems, and SoS systems engineers provide technical support to the
SoS managers. This guide is focused on the role and activities of these SoS SE teams.
1.7.2 Net-Centricity
Net-Centricity is defined as the ability to provide a framework for full human and
technical interoperability that (1) allows all DoD users and mission partners to share the
information they need, when they need it, in a form they can understand and act on
with confidence, and (2) protects information from those who should not have it. The
Net-Centric vision is to harness the power of information and network connectivity for
all DoD users [DoD, 2008].
The Net-Centric Data Strategy [DoD CIO, 2003] establishes the use of communities of
interest to solve high-priority data, information, and services issues facing the
Department. At the same time, systems engineering is trending away from engineering
point-to-point interfaces and towards exposing data to the enterprise in a common
vocabulary, built around key principles. Through the principle of visibility, unanticipated
users can discover the information sources on the network; through the principle of
accessibility, users pull that data if they meet the access control policies; through the
principle of reliability the data is supplied by a single trusted source and through the
principle of understandability, users pull the metadata that describes how to bind to the
data.
coupling of the systems in an SoS and enables relatively autonomous evolution of the
constituent systems.
The DoD approach to net centricity is relevant to DoD SoS of all types. The process of
networking multiple systems to support the user capability is a common element of
almost all SoS [DoD CIO, 2003]. How this is accomplished is not discussed in any detail
in this guide because it is discussed in DoD policy and regulations directly addressing
this area [DoD, 2003; DoD CIO, 2003; DoD CIO, 2005]. Additionally, there are
standards that have been identified for use in DoD systems; these are provided in
Defense Information Technology Standards Registry (DISR). The assumption is made
that net-centric policies and practices will be applied as appropriate throughout the SE
process for SoS considering the available networking infrastructure (capacity, etc).
Future versions of the guide may address specific issues in this area if it appears that
there are gaps not otherwise addressed by this community.
1.7.3 Emergence
The terms emergence and emergent behavior are increasingly being used in SoS
contexts. While the concept of emergence and its derivative terms has a long history in
science and technology, to this day there is no single, universal definition of emergence.
In SoS contexts, the recent interest in emergence has been fueled, in part, by the
movement to apply systems science and complexity theory to problems of large-scale,
heterogeneous information technology based systems. In this context, a working
definition of emergent behavior of a system is behavior which is unexpected or cannot
be predicted by knowledge of the system’s constituent parts.
The emergent behavior of an SoS can result from either the internal relationships
among the parts of the SoS or as a response to its external environment. Consequences
9
Systems Engineering Guide for Systems of Systems
Because of the characteristics of SoS, M&S can be a particularly valuable tool to the SoS
SE team. M&S is used to support SoS SE in a number of areas. Models, when
implemented in an integrated analytical framework, can be an effective means of
understanding the complex and emergent behavior of systems that interact with each
other. They can provide an environment to help the SoS SE team to create a new
capability from existing systems and consider integration issues that can have a direct
effect on the operational user. M&S can support analysis of architecture approaches
and alternatives, and it can also support analysis of requirements and solution options.
Stakeholder Clearer set of stakeholders Stakeholders at both system level and SoS levels (including the system
Involvement owners), with competing interests and priorities; in some cases, the system
stakeholder has no vested interest in the SoS; all stakeholders may not be
recognized
Governance Aligned PM and funding Added levels of complexity due to management and funding for both the
SoS and individual systems; SoS does not have authority over all the
systems
Operational Environment
Operational Focus Designed and developed to Called upon to meet a set of operational objectives using systems whose
meet operational objectives objectives may or may not align with the SoS objectives
Implementation
Acquisition Aligned to ACAT Added complexity due to multiple system lifecycles across acquisition
Milestones, documented programs, involving legacy systems, systems under development, new
requirements, SE with a developments, and technology insertion; Typically have stated capability
Systems Engineering Plan objectives upfront which may need to be translated into formal
(SEP) requirements
Test & Evaluation Test and evaluation of the Testing is more challenging due to the difficulty of synchronizing across
system is generally multiple systems’ life cycles; given the complexity of all the moving parts
possible and potential for unintended consequences
Boundaries and Focuses on boundaries and Focus on identifying the systems that contribute to the SoS objectives and
Interfaces interfaces for the single enabling the flow of data, control and functionality across the SoS while
system balancing needs of the systems
Performance & Performance of the system Performance across the SoS that satisfies SoS user capability needs while
Behavior to meet specified balancing needs of the systems
objectives
11
Systems Engineering Guide for Systems of Systems
On the other hand, for SoS, there are stakeholders for both the SoS and for the
constituent systems themselves. These stakeholder groups each have their own
objectives and organizational contexts which form their expectations with respect to the
SoS. The stakeholders of the SoS may have limited knowledge of the constraints and
development plans for the individual systems. In some cases, every SoS stakeholder
may not be recognized. Stakeholders of individual systems may have little interest in
the SoS, may give SoS needs low priority, or may resist SoS demands on their system.
These competing stakeholder interests establish the complex stakeholder environment
for SoS SE.
System of Systems –
The Management Challenge
$ $
$ $
On the other hand, SoS SE is conducted to create operational capability beyond that
which the systems can provide independently. This may make new demands on the
systems for functionality or information sharing which had not been considered in their
individual designs. In some cases these new demands may not be commensurate with
the original objectives of the individual systems.
In creating a new capability from existing systems, the systems engineer will need to
consider issues that can have a direct effect on the operational user. Differences in
nomenclature, symbology, interaction conventions, or any of a host of other human
interface variations among the individual systems can create challenges in the usability
of the SoS as well as in the training pipeline needed to instill the required skill sets.
Similarly, there may be implications in the personnel requirements for an SoS that must
be considered. On the positive side, the combined effect of multiple systems may
present opportunities to the war fighter by producing or enabling a capability that was
not originally planned.
Typically, SoS involve multiple systems that may be at different stages of development,
including sustainment. SoS may comprise legacy systems, developmental systems in
acquisition programs, technology insertion, life extension programs, and systems
related to other initiatives. The SoS manager and systems engineer need to accept the
challenge to expand or redefine existing SE processes to accommodate the unique
considerations of individual systems to address the overall SoS needs. It is the role of
the SoS systems engineer to instill technical discipline in this process. The development
or evolution of SoS capability generally will not be driven solely by a single organization
but will most likely involve multiple DoD Program Executive Offices (PEOs), Program
Managers (PMs), and operational and support communities. This complicates the task of
13
Systems Engineering Guide for Systems of Systems
the SoS systems engineer who must navigate the evolving plans and development
priorities of the SoS constituent systems, along with their asynchronous development
schedules, to plan and orchestrate evolution of the SoS toward SoS objectives. Beyond
these development challenges, depending on the complexity and distribution of the
constituent systems, it may be infeasible or very difficult to completely test and
evaluate SoS capabilities.
Further, an SoS can place demands on constituent systems that are not supported by
those systems’ designs. Combinations of systems operating together within the SoS
Systems Engineering Guide for Systems of Systems
In addition, beyond the ability of the systems to support the functionality and
performance called for by the SoS, there can be differences among the systems in
characteristics that contribute to SoS “suitability” such as reliability, supportability,
maintainability, assurance, and safety. These characteristics cut across the 16 SE
processes in the DAG chapter 4. The challenge of design in an SoS is to leverage the
functional and performance capabilities of the constituent systems to achieve the
desired SoS capability as well as the crosscutting characteristics of the SoS to ensure
the meets the broader user needs.
15
Systems Engineering Guide for Systems of Systems
When we look at SoS in the DoD today, we see that a SoS generally is recognized as a
formal entity when something important enough brings into play management and
governance processes that cut across established individual system boundaries.
Reasons can vary. In some cases the criticality of an SoS capability becomes a concern,
as when the Air Force recognized that the suite of systems supporting the Air
Operations Center (AOC) was coming together without benefit of coordinated pre-
planning and integration, jeopardizing a critical military operational asset. Alternatively,
an SoS may be created to address operational problems in which new needs cannot be
supported without cooperative efforts of multiple systems (e.g., Single Integrated Air
Picture (SIAP)).
Once the need for a formal SoS is recognized, typically an organization is identified as
responsible for the SoS area along with the broad definition of the objective of the SoS.
In most cases, however, this does not include changes in ownership of the constituent
systems in the SoS or reduction of those systems’ existing objectives. For example,
figure 3-1 shows the mix of systems and owners in the MILSATCOM SoS. In addition,
the SoS objective is often framed in terms of improved capabilities and not as a well-
specified technical performance objective.
SoS are not typically new acquisitions; rather, they tend to overlay an ensemble of
existing, evolving, and new systems with the objective of improving the way the
systems work together to meet a new user need. Under these circumstances, SoS
managers, when designated, typically do not control all the requirements or funding for
all the individual systems in the SoS and consequently find that they can only
influence—rather than direct—system managers to meet SoS needs. The SE approach
for the SoS therefore must recognize that SoS needs may not be accommodated in the
individual systems’ development.
Systems Engineering Guide for Systems of Systems
Challenge of SoSE
SoS SE typically focuses on the evolution of capability over time, with initial efforts
working to enhance the way current systems work together, anticipating change in
internal or external effects on the SoS and eventually adding new functionality through
new systems or changes to existing systems. In some cases the aim may be to
eliminate or re-engineer systems to provide better or more efficient capability.
However, providing more efficient capability may be problematic because features that
are redundant across systems may be needed when the systems operate apart from the
SoS.
17
Systems Engineering Guide for Systems of Systems
2
An architecture is the structure of components, their relationships, and the principles and guidelines
governing their design evolution over time [IEEE Std 610.12 and DoDAF]. The architecture of an
SoS is a persistent technical framework for governing the evolution of an SoS over time.
19
Systems Engineering Guide for Systems of Systems
These core elements provide the context for the application of SE processes. The core
SE processes developed and used in the acquisition of new systems continue to support
SoS, and the SoS environment affects the way these processes are applied. These core
3
A design defines the characteristics of an entity (system, component, SoS, etc.) in sufficient detail to
enable the entity’s implementation. Typical characteristics include components, control logic, data
structures, input/output formats, interface descriptions, and algorithms (IEEE Std 610.12). The design
of an SoS consists of the architecture of the SoS together with changes to the designs of the
constituent systems that enable them to work together according to the architecture.
Systems Engineering Guide for Systems of Systems
elements of SoS SE will be discussed in a later section in more detail in terms of the SE
processes that support them.
Systems engineers of SoS find that they need to focus on those areas that are
critical to the SoS success and leave system-level issues to their systems engineers.
The systems engineers at the system level have the knowledge and responsibility
and are in the best position to address implementation details. For example, figure
3-2 shows the partitioning of responsibilities between the SoS and the systems in
the Army’s Future Combat System (FCS). The biggest challenges are determining
the areas that need to be addressed at the SoS level to enable SoS systems
engineers to focus on them. SoS systems engineers typically concentrate on risk,
configuration management, and data as they apply across the SoS. For SoS, a key
area of concern is the synchronization across development cycles of the systems.
21
Systems Engineering Guide for Systems of Systems
The SoS Integrated Master Schedule (IMS) focuses on key intersection points and
dependencies across the SoS rather than concentrating on individual systems’
schedule details.
Given the tension between the needs of systems themselves and the demands of
the SoS, there is a real advantage to an SoS architecture based on open systems
and loose coupling which impinges on the systems as little as possible. This type of
architectural approach provides systems maximum flexibility to address changing
needs of original users, and permits engineers to apply technology best suited to
those needs without an impact on the SoS. Hence, SoS architecture trades may
place a greater emphasis on approaches which are extensible, flexible, and
persistent over time and which allow the addition or deletion of systems and
changes in systems without affecting other systems or the SoS as a whole. While it
is unlikely that the systems supporting an SoS objective will comply with such an
architecture at the outset, the development of an open architecture and migration of
systems over time is a typical and desirable approach for an SoS. Service Oriented
Architectures (SOA) is an example of this type of architecture approach.
• Focusing on the design strategy and trades both when the formal SoS is
first established and throughout the SoS evolution
23
Systems Engineering Guide for Systems of Systems
essence, the 16 processes are a set of tools used to implement the core elements. In
an SoS, the SoS systems engineer employs SE processes in ways that address the
specific constraints and opportunities of the SoS environment.
Technical Processes
Requirements Development takes all inputs from relevant stakeholders and
translates the inputs into technical requirements.
Logical Analysis is the process of obtaining sets of logical solutions to improve
understanding of the defined requirements and the relationships among the
requirements (e.g., functional, behavioral, temporal).
Design Solution translates the outputs of the Requirements Development and
Logical Analysis processes into alternative design solutions and selects a final design
solution.
Implementation is the process that actually yields the lowest-level system elements
in the system hierarchy. The system element is made, bought, or reused.
Integration is the process of incorporating the lower-level system elements into a
higher-level system element in the physical architecture.
Verification confirms that the system element meets the design-to or build-to
specifications. It answers the question "Did you build it right?”.
Validation answers the question of "Did you build the right thing".
Transition is the process applied to move … the end-item system to the user.
The relationships between the core elements and the SE processes are depicted in table
3-2. In general, the technical management processes are more heavily represented in
the SoS SE core elements, reflecting the SoS SE role of coordination and orchestration
across systems, with detailed engineering implementation taking place primarily at the
system level. This is consistent with the emerging principles for SoS SE discussed in
section 3.3, especially acknowledging roles and relationships and using an architecture
based on open systems and loose coupling.
The mappings are based on a close reading of the process definitions in the DAG
chapter 4 as they apply to SoS SE. In some cases, such as configuration management
(CM), only elements where the SoS is actually controlling baselines or other
configuration managed information are tagged with CM. In some core elements, such
as Understanding Systems and Relationships, the SoS systems engineering team is
assessing information that is under configuration management but not by the SoS;
hence, in these elements, CM is not noted. Instead, the SoS-specific data collected and
addressed in these elements is handled under data management (DM). It can be
argued that the 16 processes affect all the elements either directly or indirectly. The
purpose of this mapping and the discussions in this version of the guide is to highlight
the key processes directly addressing the SoS SE elements.
Table 3-2. Technical & Technical Management Processes as They Apply to the Core Elements
of SoS SE
Technical Processes Technical Management Processes
Tech Planning
Config Mgmt
Tech Assess
Data Mgmt
Implement
Rqts Mgmt
Risk Mgmt
Transition
Rqts Devl
Integrate
Interface
Decision
Solution
Analysis
Analysis
Validate
Logical
Design
Verify
Mgmt
Translating Capability
X X X X X
Objectives
Assessing Performance to
X X X X X
Capability Objectives
Orchestrating Upgrades to
X X X X X X X X X X X
SoS
25
Systems Engineering Guide for Systems of Systems
For example, decision analysis is a basic process in SE. In an SoS context, decisions for
the SoS need to be considered in light of the impact on the systems themselves.
Likewise, configuration management and data management at the SoS level deal with
aspects of the SoS not addressed in SE of the individual systems.
Before moving to the details, this section begins with a discussion of SE focus areas
that are used across applications of SE including in SoS. These have been the focus of
DoD SE policy and they are important in SoS. These focus areas will be discussed
throughout this section as they apply to specific core elements and processes, but they
warrant separate discussion as they apply across SE for SoS.
The DoD requires SE or technical plans for all acquisition programs. These plans
provide a vehicle for a foundational description of the SE organization and approaches
that are used across SE of the system. In the sections that follow, technical planning is
described for key SoS development activities, but it is as important that the SoS SE
team creates a broad-based SoS SE Plan (SEP) to guide the SE of the SoS. While some
SoS are not acquisition programs and consequently their structure may differ, the five
focus areas [REF, SEP Prep Guide, p.1] for SEPs apply in SoS:
• Program Requirements: The SEP should define how the program will manage all
requirements (statutory, regulatory, derived, certification).
• Technical Staffing and Organization Planning: The SEP should show how the
program will structure and organize the program team to satisfy requirements.
• Technical Baseline Management: The SEP should establish a technical baseline
approach.
• Technical Review Planning: The SEP should show how the program will manage
the technical effort, including the technical baselines, through event-based
technical reviews.
• Integration with Overall Management of the Program: The SEP should link SE to
other management efforts, including the Acquisition Strategy, test planning,
sustainment planning, configuration management, risk management, and life-
cycle management.
In addressing these areas, the SoS SE team addresses the core elements of SoS SE
described in this guide and how they apply the SE processes to these elements. In
each area, the SoS SE has issues to address that are specific to SoS.
27
Systems Engineering Guide for Systems of Systems
stakeholders, and users, to derive the SoS requirements from the capability objectives
and then address them using the functionality of current systems, augmented with
enhancements or new developments. The SoS SE team has the added challenge of
working with the constituent systems as they address their system requirements, which
may not align with the SoS requirements.
Technical Staffing and Organization Planning: In an SoS, this area includes both
how the SoS SE team will be composed and structured and how the SoS systems
engineers will interact with the SE teams of the constituent systems. What type of
crosscutting structures will be created? How will the SoS and system SE teams
interact? Each SoS has particular circumstances that will drive these decisions. Most
have created some type of cross-SoS SE council, but in many cases direct relationships
between the SoS SE team and the SE teams of key systems with MOAs/MOUs provide
the foundation for working relationships. The SoS SE team may have representatives
on integrated product teams (IPTs) or on the configuration boards of the key systems.
These arrangements often evolve as the SoS matures, but they need to be considered
early and reviewed periodically in terms of their effectiveness.
Technical Review Planning: As with systems, the SoS SE team needs to develop an
approach to manage the technical work of the SoS, including identifying critical decision
points and planning for technical reviews. Because SoS technical implementation is
through systems that have extant capability and their own objectives, users, sponsors,
funding, and development plans, this is an area of major change for the SoS systems
engineers in an acknowledged SoS. It is critical that the SoS systems engineers have a
good understanding of the constituent systems’ processes, organization structures, and
plans as the basis for planning the SoS technical approach. Because the systems will
undoubtedly be on different schedules, the SoS will need to develop a ‘battle rhythm’ as
a method for pacing the activities of the SoS. Planning for increments of SoS
Systems Engineering Guide for Systems of Systems
Integration with Overall Management of the Program: As with systems, the role
of the systems engineer is to support management decisions and the SE plans need to
be aligned to the SoS management process. With the management issues faced by
SoS, it is particularly important that systems engineer provide the discipline and
objective assessment of gaps and options to support SoS technical planning and
execution.
These crosscutting focus areas will be addressed in more detail in subsequent sections
as the elements of the SoS SE are discussed and the basic SE processes are described
in terms of how they support the elements.
Figure 4-1 displays these core elements and their interrelationships. The elements are
conducted on an ongoing basis. Whereas a systems engineer of a single system
implements the 16 SE processes using a waterfall, incremental, or iterative approach,
there is less structure in timing or sequencing these SoS SE core elements. They may
be conducted by members of single or multiple SoS SE teams depending on the size or
scope of the SoS.
As the figure shows, three of the core elements reflect areas critical to SoS SE:
translating capability objectives, understanding systems and relationships, and
monitoring and assessing changes. These elements may also play a part in SE of
systems but, because external influences play such a heavy part in the SoS
environment, they are emphasized for SoS.
29
Systems Engineering Guide for Systems of Systems
Translating
Translating Assessing New
Translating
capability Assessing
capability (actual)
Assessing
(actual) SoS SE
objectives
capability performance role
objectives performance
performance
objectives totocapability
tocapability
capability
Orchestrating
Orchestrating objectives
objectives
Orchestrating
upgrades objectives
upgrades
upgrades
to
toSoS
SoS Persistent
to SoS SoS overlay
Understanding
Understanding
Understanding
systems
Developing,
Developing
Developing, framework
systems&& evolving and
evolving and
relationships & evolving
systems &
relationships
(includes
maintaining
SoSmaintaining
(includesplans)
plans) design/arch
SoS
relationships SoS design/arch
Addressing
Addressing
Addressing new
new architecture SoS
requirements
requirements
requirements upgrade
&&options
& solution
options process
options
External
Monitoring
Monitoring
&Monitoring
assessing influences
&&changes
assessing
assessing
changes
changes
External Environment
In most cases the technical requirements for a system or a system increment have
been defined and are provided to the systems engineer as a starting point. In SoS,
because requirements may be at a higher level or cast in terms of capabilities rather
than requirements, the systems engineer plays an important role—working with
stakeholders and the SoS manager to articulate the high-level technical SoS
requirements that will provide a basis for the SE for the SoS. Similarly, identifying the
systems affecting SoS objectives and understanding their technical and organizational
relationships goes beyond what is typically done by the systems engineer to address
the interfaces for a new system.
Finally and most important, the SoS systems engineer pays considerable attention and
invests substantial time understanding changes that are outside his span of control but
could potentially impact the SoS. The SoS SE team monitors these influences and
assesses feedback on the SoS from the field as well as the results of other core
elements. The SoS systems engineer focuses on understanding and, in fact,
anticipating change as a core element of the SE for SoS.
Understanding
Systems & Developing
Relationships & Evolving
Translating Monitoring & SoS
Capability Assessing Architecture
Objectives Changes
Assessing
SoS
Performance
Orchestrating
Addressing upgrades
requirements to SoS
& solution SoS
options
Systems
As these figures show, upgrades of the SoS follow a two-level process shown in terms
of the SE “V”. The SoS SE looks across the SoS to recommend requirements to be
addressed in an increment, working with the SE teams of the systems to identify
opportunities and approaches for addressing the requirements and developing a plan
for the increment through analysis and trades. The SE teams for constituent systems
examine options for implementing new functionality in their own systems using the
same processes they would apply for any type of a requirement. Once a plan is
developed, the systems implement the plan while the SoS systems engineer provides
oversight and takes responsibility for integration and test across the systems for the
SoS objectives.
31
Systems Engineering Guide for Systems of Systems
Assessing
performance
to capability
objectives
Recommend Assess SoS
rqts for this capabilities
increment Addressing & limitations
Identify
requirements Orchestrating
candidate
systems to & solution upgrades Validate sets
of systems
support
functions options to SoS
Assess options
Negotiate
Verify sets
of systems SoS
with systems Integrate sets
Develop plan of systems
Systems
Figure 4-3. SoS SE with a Focus on SoS Upgrade for a Single Increment
The SoS SE core elements are not necessarily executed in a predetermined order. As
the SoS capability is developed, certain elements need to be addressed at the time an
SoS is acknowledged. These include translating capability objectives, understanding
systems and relationships, and assessing performance to capability objectives. The
results of these elements provide the basis for the others. However, these elements
are revisited as the SoS evolves and may be implemented concurrently.
The SoS SE core elements are implemented under the auspices of the SoS systems
engineer in partnership with the systems engineers of the constituent systems as
appropriate for the elements and the characteristics of the SoS. Different SoS efforts
create SE councils or other organizational entities as the vehicle for this type of
cooperative activity. Throughout this guide we alternatively use the terms systems
engineers or SE teams without further specifying an organization or group, since at this
stage of SoS SE there has not yet been enough experience to provide definitive
crosscutting recommendations in this area. Similarly, different SoS efforts have
employed a variety of work breakdown structures to organize their efforts. As the
community gains more experience in this area, this topic will be considered in future
guide versions.
Systems Engineering Guide for Systems of Systems
This SoS SE core element involves codifying the SoS capability objective, which may be
stated at a high level, leaving the task of clarifying and operationalizing the objectives
and expectations to the SoS manager, systems engineer, and stakeholders. The
following examples illustrate the type of capability objectives an SoS might have:
Once the SoS establishes the capability objective (often based upon desired operational
tasks and missions), the SoS SE team defines the functions required to provide the
capability and the variability in the user environment which will impact the different
ways these functions will be executed. The articulation of objectives may be somewhat
general at the outset, but as the SoS and SE processes mature, the objectives become
more focused and they may change. ‘Reference missions’ or ‘use cases’ can be
developed to evaluate the operational utility of the SoS and derive requirements that
directly address usability of the SoS in the operational environment. Working with the
SoS manager, users, and stakeholders, the systems engineer plays an important role in
articulating capability objectives. This activity provides the systems engineer with a
broader understanding of priorities and relationships, and that understanding will be
useful in the further development and management of requirements. The product of
this element is a set of requirements ready for incorporation to a future functional
baseline for the SoS.
Within this core element the systems engineer develops a broad understanding of the
context and drivers for the SoS. Beyond the specific functionality needs, it is very
important for the systems engineer to have a good understanding of the motivation for
the SoS, particularly the need to be more responsive to the increasing change tempo of
the battle space, be it cyberspace, non-nation state terrorism, or health care
management for veterans. Because SoS tend to evolve over time, the systems
engineer needs to understand and continue to track the dynamics of change as they
influence the SoS objectives and expectations. This provides the drivers for the SoS SE
element ‘monitoring and assessing change’; in effect, it provides the context to help the
33
Systems Engineering Guide for Systems of Systems
systems engineer anticipate the type of changes and variability the SoS will need to
address over time.
Figure 4-3 shows the relationship between this element and the other SoS SE core
elements. Translating Capability Objectives receives inputs from a number of sources,
including the following:
• External sources that affect the SoS objectives, including the stakeholder needs,
the assessment of the threat, etc.
• Feedback on feasibility in terms of systems and their functionality, architecture
limitations, and field experiences
Translating Capability Objectives provides the other SoS SE elements with information
on the first-order goals and expectations for the SoS, which serve to ground the work of
the SoS systems engineer across the board.
In Translating Capability Objectives the systems engineer draws on the following five
technical and technical management processes as described in table 4-1:
• Requirements Development
• Requirements Management
• Risk Management
• Configuration Management
• Data management
Systems Engineering Guide for Systems of Systems
Input:
Input: User needs based Assessing
Stakeholder needs on operational
Threat conditions feedback performance
National priorities Output: to capability
Translating First order SoS objectives
capability objectives and
External Influences
expectations
objectives
Input:
Design feasibility
Output:
First order SoS
objectives and
expectations
Output: Developing
First order SoS Input: & evolving
objectives and Status of SoS architecture
expectations systems,
relationships
and functionality
Output:
First order SoS
objectives and
Monitoring expectations
Understanding
& assessing systems &
changes relationships
Figure 4-3. Relationship between Translating Capability Objectives and Other SoS SE Core
Elements
35
Systems Engineering Guide for Systems of Systems
Aviation Command and Control System (CAC2S)). These are certainly major areas of
concern for the SoS systems engineer. However, because of the characteristics of an
SoS, there are other relationships that are also important. Examples of ways to depict
these dimensions are shown in figures 4-4, 4-5, 4-6 and 4-7. In each case they
selectively illustrate the perspective of some dimensions of the relationships among the
systems from specific SoS. These views include:
These examples of ways to depict relationships (figures 4-4 - 4-7) selectively illustrate
the perspective of some dimensions of the relationships among the systems for specific
SoS. Several of these views are based on the DoD Architecture Framework, which
provides a resource for the SoS SE team both in terms of available data on systems and
in terms of a format for presenting some SoS views.
37
Systems Engineering Guide for Systems of Systems
RAINDROP (COTS) Predator Video (ISRSG) Portable Flight Planning GPS Interference & Auto Deep Ops Coord
System (MPSG) Navigation Tool System (Army JPSDO)
Theater Battle Mgmt Multimedia Message Global Broadcast System Weapons System Video Global Cmd & Control
Core System (OC2SG) Manager (ISRSG) (GIGSG) (AF/ILC) System - I3 (DISA)
InfoWorkSpace (COTS) C2 Network Access Air Defense System PCI3 (ACC/IN) Joint Weather Impacts
(ISRSG) Integrtr (GIGSG) System (BMSW)
ACEP (OC2SG) Deployable Transit-case Cross Domain Solutions * C2 Info Processing C2 Personal Computer
System (ISRSG) (CPSG) System (AMC) (USMC)
Boundary Security Space Battle Mgmt Core Defense Message System Interim Targeting Collection Mgmt Mission
System (OC2SG) System (CC2SG) (OSSG) Solution (AFRL) Applic’n (Navy)
C2 Wpn System Part Process’g & Display Air Operations Net Generic Area Limit’n
Task Trainer (OC2SG) Subsys Migrat’n (CC2SG) (Theater A6) Envrnmt Lite (NRO)
Infrastructure Core * Purple Net (Theater A6) Imagery Product Library
(COTS) (NGA)
Geospatial Product Personnel Recovery Mssn
Library (AF/XOI) Software (JPRA)
•• 45
45 Systems,
Systems, 20+
20+ vendors
vendors Global Decision Sppt Global Transportation
System (AMC) Network (TRANSCOM)
•• AOC
AOC isis not
not the
the only
only user
user of
of many
many of
of
Precision Lghtwght GPS INTELINK and INTELINK-
these systems
these systems Rcvr (WR/ALC) S (DISA)
•• Some
Some provide
provide operational
operational capability,
capability, AF Tactical Receive Suite Requirements Mgmt
(AFC2ISRC/SC) System (DIA)
others
others infrastructure
infrastructure
* “Bin” of systems
Figure 4-4. Example of an Organizational View of an SoS: AOC WS 10.1 – Systems and Their
Sources [Source: AC Modernization Team]
Systems Engineering Guide for Systems of Systems
FTA
FTL
FTS
Figure 4-5. Example of an Operational View of an SoS: Naval Integrated Fire Control -
Counter Air [Source: Navy Chief Engineer’s Office]
Local 3D JFACC
INTEL
Air Surv Radar Joint Forces Air
GCCS TBMCS Systems AFATDS
Long Range Component
(MIDB)
(AN/TPS - 59) Commander
ATC Functionality
Figure 4-6. Marine Corps Common Aviation Command and Control System Depiction of
Datalinks [Source: PM Support CAC2s]
39
Systems Engineering Guide for Systems of Systems
Defense COCOM
JIOC JIOCs
JFCC- NMCC
ISR
COCOM
Multi- Operations
National Centers
Coalition
Other
Services, DoD
S&T JTF &
& Non-
Centers Compo
nent
Figure 4-7. Example of a stakeholder view: DoD Intelligence Information System (DoDIIS)
[Source: DoDIIS]
As the SoS matures, this element also maintains an understanding of the plans for the
systems and SoS, including the SoS architecture and the strategy of migration to that
architecture over time.
Another reason Understanding Systems and Relationships is important to the SoS effort
is because it provides integrated knowledge of and data on the SoS environment
including linkages to data maintained by the systems relevant to the SoS. It considers
both those systems under direct responsibility of the SoS manager and those that are
outside the manager’s immediate span of control and thus will have to be influenced
through collaboration and establishing common goals.
Importantly, Understanding Systems and Relationships provides the basis for identifying
where formal and informal working agreements are required. They are the basis for
understanding primary areas of focus, i.e., instances where SoS functionality and
performance are affected by changes in systems. Because SoS in the DoD today are not
typically supported by standard, basic organizational structures and processes, the SoS
manager and systems engineer must assess when specific working agreements need to
be established for the SoS. Some SoS have created types of memorandums of
agreement (MOAs) or understanding (MOUs) which formalize the relationships between
the SoS and the systems. The MOA or MOU specify the responsibilities of SoS and
system management and SE and other aspects of their SoS related working
relationships. Moreover, as SoS adopt a Services-Oriented Architecture (SOA)
approach, they will adopt Service-Level Agreements (SLAs) to specify agreed upon
support to the SoS.
Figure 4-8 shows the relationship between this element and the other SoS SE elements.
Understanding Systems and Relationships receives inputs from a number of sources:
Systems Engineering Guide for Systems of Systems
Input:
First order SoS
objectives and Translating
expectations capability
Output: objectives
Status of systems,
relationships, and
functionality
Input:
Understanding Updated architecture
systems & information
relationships Output: Developing
Status of systems, & evolving
relationships, and SoS architecture
functionality
Input:
Changes which impact Input:
systems and relationships Upgrades which
Output: impact systems and
Status of systems, Output: relationships
relationships, and Status of systems, Orchestrating
functionality relationships, and
functionality upgrades
to SoS
Addressing
Monitoring requirements
& assessing & options
changes
Figure 4-8. Relationship between Understanding Systems and Relationships and Other SoS SE
Elements
• Logical Analysis
• Risk Management
• Configuration Management
• Data Management
• Interface Management
41
Systems Engineering Guide for Systems of Systems
43
Systems Engineering Guide for Systems of Systems
acknowledged, one of the first things done by the systems engineering is to collect
performance information as the starting point for identifying areas of the SoS which
need attention.
Because acknowledged SoS typically comprise existing (often fielded) systems (e.g.,
AOC, SIAP, MILSATCOM), data from operations is an important source of understanding
the state of the SoS. Because the SoS will likely evolve based on incremental changes
in individual systems, it is important to have a set of user-oriented metrics which can be
applied in different settings over time. The SoS systems engineer uses data from these
settings to analyze SoS performance and behavior; hence, the metrics should include
measures which use data from operations.
These SoS metrics should also be traceable to the capability objectives established for
the SoS, and there may even be a need to rank the metrics by importance. These
metrics should not change as the capability of the SoS matures unless the capability
objectives themselves change. They must remain applicable as the SoS matures to
assess whether the changes made are actually translating into better user support.
Data from these operational venues also can be used to identify unanticipated external
changes that affect SoS performance and therefore need to be factored into the SoS
SE. Because of the complexity of many SoS, when changes made to support SoS
objectives are introduced into an operational environment, unexpected interactions are
not uncommon. Therefore, SoS test and evaluation needs to identify and assess the
additional capability provided by these unexpected interactions. This includes the need
to consider potential harmful interactions between systems, and how those interactions
can be identified and managed. Just as important, test and evaluation needs to address
new and unexpected capabilities that result from SoS. Users often find new ways to
employ new functionality; by watching those creative adaptations, systems engineers
can often discover new categories of functionality that will further aid users. In short,
systems and their users evolve synchronously, and it is important to be aware and
adapt the SoS SE to leverage these changes.
Inputs also come from the external environment on factors that may impact the
performance of the SoS.
Input: Input:
External factors First order SoS
which may Assessing objectives and
expectations
impact SoS
performance performance Output:
to capability User needs based Translating
on operational capability
External Influences
objectives feedback objectives
Output:
Feedback on factors
impacting capability
and on user
behavior (including
Output: new or unexpected
Feedback on ways of using SoS
implementation components Monitoring
variability Input: & assessing
Changes to SoS changes
with objective of
improved user
capabilities
Orchestrating
Developing upgrades
& evolving to SoS
SoS architecture
Figure 4-9. Relationship between Assessing Performance to Capability Objectives and Other
SoS SE Core Elements
The output of the assessments provides feedback to the systems engineer on the
accomplishment and feasibility of the capability objectives. It also provides input to the
systems engineer’s assessment of changes potentially impacting the SoS by supplying
information on relevant behaviors—both expected and unexpected—that have been
observed. This also includes unanticipated changes in the way that users employ the
SoS which may need to be considered in planning for SoS evolution.
• Validation
• Decision Analysis
• Technical Assessment
• Risk management
• Data management
45
Systems Engineering Guide for Systems of Systems
The Validation Process Validation is at the heart of Assessing Performance to Capability Objectives. This core
answers the question of "Did element is directed at validating the evolution of the SoS over time by monitoring the
you build the right thing". objectives of the SoS through use of established metrics that provide feedback to the
systems engineer on the state of SoS capabilities. As new iterations of SoS capability are
fielded, this feedback will tell the systems engineer the degree to which the changes are
improving the SoS capability to meet user needs, and will help identify new areas to be
addressed.
Decision Analysis activities Decision analysis in Assessing Performance to Capability Objectives addresses the
provide the basis for questions, Are the right metrics/indicators being collected? In the right venues? At the
evaluating and selecting right points? And in SoS SE, decision analysis goes further. The SoS metrics are collected
alternatives when decisions and analyzed as part of analyses to assess whether the SoS is making progress towards
need to be made. objectives. Analysis of the results supports decisions on required SoS SE actions. Examples
of analysis techniques include root cause analyses, assessments of alternative approaches,
and investigations of potential secondary effects of using multiple implementations of
common functions.
Technical Assessment The SoS systems engineer is responsible for monitoring the progress of implementing
activities measure technical changes in the systems directed at improving SoS performance. This is the technical
progress and the effectiveness assessment process. The SoS SE core element Assessing Performance to Capability
of plans and requirements. Objectives, provides the SoS systems engineer an opportunity to assess the degree to
which these changes are having the desired effects, and if not, an opportunity to
understand what other factors are affecting the SoS performance.
Risk Management … helps Risk Management applied to Assessing Performance to Capability Objectives identifies
ensure program cost, and monitors those risks related to the ability to achieve performance and capability
schedule, and performance objectives. Risk management is applied in several ways. First, in this SoS SE core element,
objectives are achieved at the SoS systems engineer has the opportunity to assess if risks identified as part of the SE
every stage in the life cycle process have been adequately mitigated or removed. New risks are identified and plans are
and to communicate to all made to manage them.
stakeholders the process for In addition, there are risks inherent in the assessment process itself. Particularly in
uncovering, determining the exercises or operational environments, there is not the level of control available in
scope of, and managing laboratory-based technical investigations of single systems. In these less controlled venues,
program uncertainties. it is important to identify and assess risks when the observed results are due to something
other than the SoS. There are two types of risks to the validity of the results. First, there
are risks based on internal threats to validity of the results. What else was going on within
the venue which might account for the results? For example, use of a training exercise as a
venue might mean that effects of new SoS features may not be apparent because the
training audience acting as users in the exercise are not yet proficient in use of these
features. Second, there are risks due to external threats to validity of the results. Did
characteristics of the test venue itself influence the results? For example, did the
operational scenario stress the SoS in areas where upgrades had been made? If not, a lack
of performance improvement may be due to this rather than ineffectiveness of the changes.
Because the feedback on SoS progress is important input across SoS SE core elements, it is
important to ensure that these risks are addressed and the results are appropriately
understood.
Systems Engineering Guide for Systems of Systems
Data management … The types of data collected in this core element, Assessing Performance to Capability
addresses the handling of Objectives, include the characteristics of the assessment venue (the players, the scenarios,
information necessary for or the state of the systems and SoS at the time of the event), the measurement data collected,
associated with product and the analysis approach and results. By collecting and accumulating data across venues
development and and using common measures, the systems engineer can develop a body of knowledge about
sustainment. the SoS. This body of knowledge represents different perspectives that can provide a
valuable resource to the systems engineer as the SoS evolves. It also provides a data
resource for identifying unintended effects over time or for assessing issues later without
repeated assessments.
4
An architecture is the structure of components, their relationships, and the principles and guidelines
governing their design evolution over time (IEEE Std 610.12 and DoDAF). The architecture of an SoS
is a persistent technical framework for governing the evolution of an SoS over time.
5
The DOD Architecture Framework (DoDAF), V1.5, describes itself as “a three-volume set that inclusively
covers the concept of the architecture framework, development of architecture descriptions, and
management of architecture data. The current version, DoDAF v1.5, is a transitional version that
responds to the DoD’s migration towards NCW. It applies essential net-centric concepts in transforming
the DoDAF and acknowledges that the advances in enabling technologies—such as services within a
Service Oriented Architecture (SOA)—are fundamental to realizing the Department’s Net-Centric Vision.
Version 1.5 addresses the immediate net-centric architecture development needs of the Department
while maintaining backward compatibility with DoDAF v1.0.” The DoD has invested in the DoDAF and
required that it be used in a variety of ways—for instance, as a mechanism to document relationships
and design decisions—by DoD systems of record. As such, DoDAF is a resource for SoS engineers.
47
Systems Engineering Guide for Systems of Systems
For long-term viability, architecture developments are served well by up-front analyses
to explore sensitivities through modeling, simulation, analysis, and/or lab
experimentation to identify scalability issues or knees in the curve (e.g., concerning
requirements or usage assumptions, assumed network bandwidth, or others) beyond
which performance starts to break down. This type of analysis provides a basis for the
architecture decisions. Similarly, development of metrics for assessment of SoS
performance and maturity provides a basis for both selecting an architecture and
assessing it over time.
The architecture of an SoS is somewhat constrained by the structure and content of the
individual systems, particularly the extent to which changes in those systems are
affordable and feasible, since systems will typically need to continue to function in other
settings in parallel with participation in the SoS. The functionality that the individual
systems contribute to the SoS can be described in a functional architecture that puts
the key functions in order, thereby sequencing the SoS tasks. An example is the ballistic
missile defense end-to-end process through boost, mid-course, and terminal phases of
ballistic missile threats which would serve as the framework for this functional process
in the case of one SoS. The functional architecture provides a functional 'picture' of the
system. It details the complete set of functions to be performed within the SoS as well
as the relationships among the functions. The output of the design process is the
design of the SoS, or the physical architecture that defines the physical components
(constituent systems) of which the SoS will be composed. The variability in the
execution of these functions in the field also needs to be understood and factored into
the SoS architecture [Boxer, 2008].
Ideally the architecture of an SoS will persist over multiple increments of SoS
development, allowing for change in some areas while providing stability in others. This
ability to persist and provide a useful framework in light of changes is a core
characteristic of a good architecture. Over time, the SoS will face changes from a
number of sources (e.g., capability objectives, actual user experience, changing
CONOPS and technology, and unanticipated changes in systems) which may all affect
the viability of the architecture and may call for changes. Consequently the SoS
systems engineer needs to regularly assess the architecture to ensure that it supports
the SoS evolution.
In most cases, because of the nature of SoS as an overlay on multiple existing systems,
the migration to an architecture of an SoS will be incremental. For example, figure 4-10
Systems Engineering Guide for Systems of Systems
shows the technical evolution of the Air Force’s Distributed Common Ground System’s
information management architecture. In some situations, the first step in an SoS
evolution is to improve the way the SoS functions without making any explicit
architecture changes. Only then, based on this experience, will the SoS systems
engineer develop an architecture that can be implemented over time.
Network/Communications
Point-to-Point, Single Net Contol element, GIG connectivity, Redundant Net Control,
Server-based access Portal Access
Figure 4-10. Evolution of the Distributed Common Ground Station—Air Force (DCGS-AF)
Information Management Architecture [Source: DCGS AF Program Office]
The Air Operations Center approach began by improving current systems and then
integrating them in a follow-up increment, as shown in figure 4-11. The architecture of
an SoS will evolve and mature over time through the result of technical reviews at the
SoS level and the linkage to specific systems, as the architecture is employed to
increase the capability of the SoS.
Because systems are likely to continue to face new functional requirements and the
need for technology upgrades independent of the SoS, there is an advantage to an SoS
architecture which is ‘loosely coupled’—that is, it has limited impact on the individual
systems, allowing for changes in functionality and technology in some systems without
impact on others or on the SoS objectives. For example, figure 4-12 shows the Army
Battle Command System’s approach to integrating the set of Army battle systems.
49
Systems Engineering Guide for Systems of Systems
Mission Applications
A&OCWSCM10.2CM C
Planning X
Execution A B
Aam
pplica
ic tion(s) NECC NECC App
Mission Capabilities
Dyn App
A&OCWSCM 10.2CM C
Mission Applications
Planning X
Execution A B
Dyna milication(s) NECC NECC App
App App
MissionApplications
Planning& CM CM C X
• Provide an integration platform for the Dynamic NECC NECC App App Execution
Application(s)
A B
Infrastructure
Net-Centric AOCWSInfrastructure I/F
Infrastructure
Planning & CM CM C X
Net-Centric AOCWSInfrastructure I/F
AOC WS
Infrastructure
Net-Centric AOC WSInfrastructure I/F
Infrastructure
• Align with NECC/NCES approach
• Integrate within the AOC and across Net-Centric AOC WS Infrastructure I/F
the NC Enterprise
• Leverage SOA, Orchestration
AOC WS 10.1
Mission Capabilities
Legacy Systems
• Mainly stovepiped with
Infrastructure
Figure 4-13 shows the relationship between this core element and the other SoS SE
core elements. Developing and Evolving an SoS Architecture receives inputs on:
As outputs, this core element provides the persistent framework for assessing options
for meeting SoS requirements and for feedback to the SoS objectives from the
perspective of feasibility and limits.
Translating
capability
objectives Input: Capability objectives for the SoS, including changes
Output: Feedback on the design feasibility of the desired objectives
Figure 4-13. Relationship between Developing and Evolving an SoS Architecture and Other
SoS SE Core Elements
• Requirements Development
• Logical Analysis
• Design Solution
• Decision Analysis
• Technical Planning
• Requirements Management
• Risk Management
• Configuration Management
• Data Management
• Interface Management
51
Systems Engineering Guide for Systems of Systems
53
Systems Engineering Guide for Systems of Systems
Hence, it is critical that the SoS systems engineer engage with the systems engineers of
the constituent systems to understand the nature of their changes and to assess the
potential impacts on the SoS. The SoS systems engineer may identify alternatives for
implementing the changes that would not affect the SoS and work to influence the
systems to adopt alternatives. A major challenge is to sensitize the constituent systems’
SE teams to the types of changes in their systems that are relevant to the SoS, and to
create an environment of trust, where systems engineers are willing to share their plans
early without fear that the SoS response may hamper their ability to support their own
system user needs. To address this, some SoS have established early configuration
boards where systems engineers of constituent systems are asked to share all
anticipated changes with the SoS systems engineer early in the planning processes. For
instance, figure 4-14 shows how MILSATCOM has established a review process in which
systems engineers for constituent systems can share their potential changes early in the
process so that the effects of prospective changes on the SoS or other systems in the
SoS can be evaluated and addressed when they appear to be problematic. The process
is tailored to make it easy to share plans early, and only when the plans affect the SoS
are technical details needed. The concept is that if issues are identified at the earliest
stages, actions can be taken to minimize the disruption to SoS SE plans. Another
approach is to have members of the SoS SE teams selectively participate in the
configuration and technical reviews of key systems. In any case, the SoS systems
engineer needs to be mindful that the time of systems engineers for the constituent
systems is already fully committed even without the SoS.
55
Systems Engineering Guide for Systems of Systems
AEHF
Changes that affect other segments or programs
BCB reviewed at respective ICWGs for technical Joint
CCS-C coordination PM Council
CRB
WGS Pgm
CRB MCB 0 ICWGs MCB 1a MCB 1b
FAB-T
CCB
- Authority to - CCB Approval
TSAT - PMs
disclosure proceed with RFP
CCB
Milstar
Figure 4-15 shows the relationship between this core element, Monitoring and
Assessing Changes, and the other SoS SE core elements. As the figure indicates, inputs
internal to the SoS include:
• Changes in demands on the SoS (new CONOPS, unplanned use of or demand for
SoS capabilities)
• Changes in demands on the individual systems (new CONOPS, unplanned use of
or demand for constituent system capabilities)
• Technology changes
Translating
capability
objectives
Input: Input:
External factors SoS objectives
which could impact and expectations
SoS (e.g. Input:
technology, threat, Status of systems,
budget, etc. relationships, and
Monitoring functionality Understanding
Output: systems &
& assessing
External Influences
Changes which
relationships
changes impact systems and
relationships
Input:
Output: Feedback on factors
Changes to requirements impacting capability
and changes which impact and on user
requirements and options behavior (including Assessing
new or unexpected performance
ways of using SoS to capability
components objectives
Addressing
requirements
& options
Figure 4-15. Relationship of Monitoring and Assessing Changes to Other SoS SE Core
Elements
The output of this core element is an understanding of how changes affect the SoS. As
a result the SoS systems engineer may review and update:
• SoS objectives
• Technical requirements
• Planned individual system changes to support SoS objectives
In this element, the SoS SE team monitors and assesses changes that are outside the
control of the SoS to identify implications for the SoS. At the same time, the team is
able to capture changes to the SoS product baseline.
In Monitoring and Assessing Changes, SoS SE draws on the following five technical and
technical management processes as described in table 4-5:
57
Systems Engineering Guide for Systems of Systems
• Decision Analysis
• Risk Management
• Configuration Management
• Data Management
• Interface Management
In this core element, the SoS systems engineer can be viewed as working through the
key activities of an extended version of the SE “V” with respect to one pass at changes
in the SoS to address selected capability needs, as shown in figure 4-16. As the SoS
Team addresses this core element, along with the last element, Orchestrating SoS
Updates, they are essentially implementing a two-level version of the process used with
the SE of an individual system. At the top level, the SoS SE team recommends
requirements to be addressed and works with the constituent systems to identify and
assess alternative approaches. In parallel, the SE teams of the constituent systems are
working at the system level, assessing options for changes in their systems to address
the needs. The result is the selection on an approach and a plan for implementing that
approach.
59
Systems Engineering Guide for Systems of Systems
Assessing
performance
to capability
objectives
Recommend Assess SoS
rqts for this capabilities
increment Addressing & limitations
Identify
requirements Orchestrating
candidate
systems to & solution upgrades Validate sets
of systems
support
functions options to SoS
Assess options
Negotiate
Verify sets
of systems SoS
with systems Integrate sets
Develop plan of systems
Systems
Input: Monitoring
Changes in SoS,
including planned & assessing
system changes, SoS changes
objectives, and
Addressing organizational changes
requirements Input:
& options Windows of opportunity
for changes and
associated options Understanding
systems &
Input: Input: relationships
Problems/issues associated Current SoS architecture
with implementation of SoS information and associated
upgrades constraints
Output: Output:
Technical plans for SoS Status of systems, relationships,
upgrades and functionality Developing
& evolving
SoS architecture
Orchestrating
upgrades
to SoS
Figure 4-17. Relationship between Addressing Requirements and Solution Options and
Other SoS SE Core Elements
Systems Engineering Guide for Systems of Systems
Outputs of this core element to other SoS SE core elements are identification of
capabilities/requirements to be incorporated into the next increment along with an
approach for implementing those capabilities/requirements. The outputs also include
any issues related to the SoS architecture that need to be addressed.
These actions are outside the control of the SoS manager and systems engineers and
will need to be negotiated with the constituent systems’ owners.
In a single system development, in the best case the systems engineer has a set of
prioritized requirements documented as a formal user capability need and validated in
Joint Capabilities Integration Development Systems (JCIDS) or the Services or agency
equivalent process. In an SoS, on the other hand, requirements evolution is often
driven by a variety of sources:
This means that the SoS systems engineer needs to look more broadly at the set of
longer-term needs and opportunistically address requirements in ways that practically
leverage ongoing system activities and remain flexible to adapt to changes in user
needs and priorities.
61
Systems Engineering Guide for Systems of Systems
These analyses for the SoS are based on trades considering cost and risk, much as
when other development decisions are made for the systems. While the changes are
being made to support SoS needs, after implementation they become part of the
system product baselines that the system owners are responsible for maintaining over
their life cycle. Consequently life-cycle costs of changes are a decision factor. Across
the SoS, different sets of solution options are considered. It may be necessary to
identify a wider range of options in an SoS because of the larger numbers of constraints
presented by the SoS environment.
Decisions about where in the SoS to address SoS requirements (allocated baseline) are
based on analysis done by both the SoS SE team and the SE teams of the constituent
systems. Working with the managers and SE teams of the constituent systems, SoS
systems engineers identify and assess approaches for updating systems to meet SoS
needs much as they do when systems changes are examined to meet a system’s user
needs. The full range of issues—to include life-cycle cost, technical and integration risk,
etc.—is assessed by systems engineers for the constituent systems and the SoS.
Upgrades to the systems consider science and technology opportunities, lessons learned
from technology explorations (e.g., Joint Capability Technology Demonstrations),
commercial-off-the-shelf (COTS) solutions, and opportunities to leverage earlier
solutions. Other resources in the area of net-centricity are the DoD Metadata Registry
(DMR) and the DoD Net-Centric Enterprise Services (NCES) Service Registry, which
allow the SE teams to leverage the developing net-centric methodologies. Approaches
to particular SoS data requirements can be found in the DMR with a registered DoD
service. These are factored into decisions about which systems changes should be
made in an increment of SoS development. The SoS SE should understand the trade
space and performance budgets allocated to individual systems to allow ongoing
measurement and evaluation of an individual system's performance on SoS objectives.
The result of Addressing Requirements and Solution Options is typically a technical plan
that triggers orchestration of new SoS upgrades. The results may also trigger updates
to the SoS architecture when the results of the core element indicate that there is no
feasible way to address the requirements within the current SoS architecture.
At the SoS-level, typically only the SoS requirements are managed and considered by
the SoS systems engineer. Constituent system requirements are typically the
responsibility of the systems. In most cases, the upgrades planned for the individual
system will not address the needs of the SoS. In Ground Combat System, for example,
plans for future integrated ground combat introduce new requirements above and
beyond the requirements posed for the individual combat systems. The SoS SE team
needs to be aware of the requirements of the systems as well as plans for funding and
scheduling changes so they may anticipate impacts of system changes on the SoS. In
addition, knowledge about system requirements and technical plans is critical for the
SoS systems engineer because this knowledge helps the systems engineer identify
options for addressing SoS requirements that may include leveraging efforts of the
individual systems. The experience of SoS shows that the needs of the SoS can differ
considerably from the aggregate needs of the systems.
Consequently it is the job of the SoS systems engineers to identify situations where
meeting needs at the SoS level may lead to potential sub-optimization of individual
systems. The subsequent resolution is often done through negotiation between the SoS
and system managers with support of the systems engineers. The tradeoffs can be
addressed through a value driven design process to weigh the alternatives in terms of
their comparative values to various users. Systems which are disadvantaged by these
decisions may be resistant to support future SoS development so it is important for the
SoS manager and systems engineers to ensure systems understand the drivers and
rationale for SoS decisions. The SoS systems engineer sometimes needs to consider
non-optimal requirements allocation options to meet cost and schedule targets. For
example, an optimal individual system may not be able to incorporate needed functions
in the current increment, but other (non-optimal) systems might be able to achieve this
goal. In an SoS it may be difficult to manage redundant capabilities in individual
systems if the systems need the redundant capability to meet their own needs when
operating separately or the needs of other SoS in which they participate.
Depending on the specific SoS, an SoS organization typically does not have the
authority to execute these activities, so arranging to implement solutions is based on
collaboration between managers of the SoS organization and the systems. New
systems/components may be developed by one of the owners of the existing systems
or by the SoS office itself. The SoS office developing a component of the SoS should be
viewed as a dual hat or additional role separate from the role of the SoS systems
engineer.
63
Systems Engineering Guide for Systems of Systems
Finally, this core element perhaps more than others may involve a great deal of
negotiation on the part of the SoS systems engineer. Even when there is analysis that a
change to one system will enable the SoS to meet a requirement and funding is
available to implement it, this does not guarantee the system’s PM, sponsor, and
systems engineer will be willing to implement the added functionality. There may be
particular issues when a system is part of multiple SoS especially if they have
competing demands for system support. Changes that satisfy the one SoS may not be
acceptable to the second SoS.
Often, the SoS systems engineer and manager must convince the systems engineer for
a constituent system that it is in the constituent system’s interest to change its
implementation to meet the SoS needs. To the degree that the SoS SE can identify
ways that the changes needed for the SoS can be done without affecting a constituent
system’s development schedule or that the changes support a system’s longer-term
development objectives, a constituent system will be more receptive to taking on added
functionality to support the SoS objectives.
As noted above, the product of this element is a technical plan for implementing the
changes for the next iteration of the SoS. In developing this plan, the SoS SE team
follows the principles for technical planning for systems, paying attention both to
defining critical event-driven reviews and to risks throughout the process. Particular
attention is paid to area of importance in an SoS including the development of an IMS,
which focuses on key integration points and links to the detailed development schedules
maintained by the systems. The plan also addresses roles and responsibilities
supported by memorandums of agreement (MOAs), which detail specific commitments
of the participant in the increment development.
In Addressing Requirements and Solution Options, the SoS systems engineer draws on
the following nine technical and technical management processes as described in table
4-6:
• Requirements Development
• Design Solution
• Decision Analysis
• Technical Planning
• Requirements Management
• Risk Management
• Configuration Management
• Data Management
• Interface Management
Systems Engineering Guide for Systems of Systems
Table 4-6. SE Processes That Support Addressing Requirements and Solution Options
Decision Analysis activities The Decision Analysis focus for Addressing Requirements and Solution Options is to address
provide the basis for two questions:
evaluating and selecting • Which of the requirements can be reasonably implemented in the next iteration?
alternatives when decisions
• What are the options for implementing them?
need to be made.
Analysis to support these decisions addresses a much broader trade space with considerably
more uncertainty and dynamics than in the typical systems engineering environment. In
this SoS SE core element, decision analysis also needs to pay attention to windows of
opportunity, identify multiple options employing different individual systems, and work
within those system constraints.
Technical Planning activities During technical planning for Addressing Requirements and Solution Options, the SoS
ensure that the systems systems engineer considers options for meeting SoS needs with respect to constituent
engineering processes are systems’ available resources, schedule, lifecycle milestones, and cost and then develops a
applied properly throughout a technical plan for the preferred option. The product of this core element is a technical plan
system's life cycle. for the iteration of SoS evolution. In an SoS, this technical plan reflects negotiations with the
systems engineers for constituent systems, since in most cases the SoS systems engineer
has no control over the plans for the constituent systems.
Requirements Management In Addressing Requirements and Solution Options the SoS systems engineer, along with the
provides traceability back to SoS manager and the systems engineers for the constituent systems, identifies the
user-defined capabilities. requirements to be addressed in the next set of iterations. It is important that the SoS
systems engineer is clear about how these requirements address the SoS objectives and
their relationship to the objectives and requirements of the constituent systems. In some
cases, the SoS may be managing/tracking lower-level system requirements, but more often
this is the responsibility of the constituent systems. In these cases, the SoS needs to link to
the constituent system processes.
Risk Management … helps To be effective, the SoS needs to consider risk as an integral part of the process of
ensure program cost, Addressing Requirements and Solution Options. In particular, given the available options
schedule, and performance the SoS systems engineer must answer these questions:
objectives are achieved at • What are the risks associated with each implementation option?
every stage in the life cycle
• What are the risks associated with the selected option?
and to communicate to all
stakeholders the process for • What are the risks of not addressing potential impacts of changing individual systems?
uncovering, determining the • What are the resources necessary to mitigate root causes of identified risks for each
scope of, and managing
65
Systems Engineering Guide for Systems of Systems
systems, who will be implementing the changes that they agreed to during the plan
development. This plan is then executed under this element.
External factors may affect the execution of this technical plan and may interrupt the
ability to implement the changes. External factors may be technical issues— such as
characteristics of the host system—that systems engineers might not have fully
understood during the planning process. These technical issues might drive up the cost
of the SoS solution, take more time to implement, or even be technically infeasible.
There might also be programmatic issues, budget cuts, or new higher-priority
development needs directed by the user of the system. In any case, these external
factors may require the systems engineer to revisit the technical plans or adjust
expectations.
As they execute the plan and complete the SoS upgrades, the SoS SE team assesses
the performance of the modified SoS. Changes made in constituent systems to support
the SoS are tested and evaluated, as are the sets of systems with changes that
contribute to SoS performance improvements. The T&E results provide feedback to the
developers during implementation and later inform the users and sponsors about
deployment decisions. As a result, the SoS systems engineer gets feedback on
problems/issues with new SoS solutions and on changes to the constituent systems and
their functional relationships resulting from the SoS upgrade as shown in figure 4-18.
Addressing
requirements
& options
Understanding
External Influences
systems &
Input: relationships
Technical plan
Output:
Problems/issues Output:
encountered with Updates to
implementation systems and
relationships
Assessing
Orchestrating performance
Upgrades to capability
To SoS Output: objectives
Input: Trigger to
Factors assess
which performance
impact the of modified
ability SoS
to execute
implementation
plans
67
Systems Engineering Guide for Systems of Systems
In Orchestrating Upgrades to SoS, negotiating and pacing the upgrades are key aspects
of the systems engineer’s role. SoS orchestration can include both deliberate, plan-
based increments and capability-driven builds. In either case, the evolving SoS needs to
accommodate the asynchronous system-development processes for multiple constituent
systems. In most cases, it is nearly impossible to align the development cycles of all
constituent systems. Consequently:
• Who does what and when will be driven by practicalities as much as technical
considerations.
• Systems engineers need to develop an incremental approach that leverages the
activities already under way in the constituent systems.
• Design must be flexible with respect to building and fielding parts of a solution,
since SoS design releases are often driven by system schedules.
• Systems engineers and the T&E community need to be creative about test and
evaluation, leveraging a variety of data and test results and venues.
Effective SoS SE assumes that the systems engineers for the constituent systems are
implementing SE for the individual systems and that the SoS systems engineer can
therefore focus on the areas that are critical across the SoS. Needed changes are
implemented in the constituent systems under their own SE process; the SoS systems
engineer coordinates across these processes, which may or may not be compatible.
Coordinating across these processes involves substantial negotiation and may result in a
reassessment of options and approaches if the logistics or technical feasibility breaks
down.
SoS SE approaches based on multiple small increments offer a more effective way to
structure SoS evolution. Big-bang implementations typically will not work in this
environment; it is not feasible with asynchronous independent programs. Specifically, a
number of SoS initiatives have adopted what could be termed a “bus stop,” spin, or
Systems Engineering Guide for Systems of Systems
Approaches such as this may have a negative impact on certification testing, especially
if the item is software related to interoperability and/or safety issues (such as Air
Worthiness Release). When synchronization is critical, considerations such as this may
require large sections of the SoS, or the entire SoS, to be tested together before any of
the pieces are fielded.
• Implementation
• Integration
• Verification
• Validation
• Transition
• Decision Analysis
• Technical Assessment
• Requirements Management
• Risk Management
• Data management
• Interface Management
69
Systems Engineering Guide for Systems of Systems
Integration is the process of Integration across the SoS is a core role of the SoS systems engineer. While the systems
incorporating the lower-level engineers of the constituent systems are responsible for implementation and integration of
system elements into a changes within their systems, the integration focus of the SoS systems engineer is the end-
higher-level system element to-end functionality and performance across the SoS. In an SoS, asynchronous system
in the physical architecture. developments may necessitate asynchronous integration. A formal integration prior to
deployment often requires an extensive System Integration Lab (SIL). For example, the
Theater Joint Tactical Network program provides an environment where developers can
bring their communications systems to assess how well they perform in an operationally
realistic environment, as shown in figure 4-19. Some SoS initiatives have created this type
of standing integration facility (e.g., TMIP, Marine Corps). In other cases, the SoS attempts
to leverage individual system integration facility resources to conduct limited integration and
testing prior to deployment of the SoS upgrades. In a number of cases, simulations are
employed, particularly to provide a ‘stand-in’ for systems unavailable for integration or not
yet developed. For SoS integration and testing, the constituent systems are often treated as
a “black box” unless the SoS behavior is particularly sensitive to the behavior of a specific
system. A key focus of the integration activities is regression testing to ensure that
constituent systems are not adversely affected by SoS changes and the SoS is not adversely
affected by individual system changes not related to the SoS. Regression testing may
piggyback on system tests of individual systems. When systems cannot be synchronized in
the development and deployment, systems may be delivered and deployed in sequence, and
later systems may need to accommodate limitations/missed opportunities of “early” systems
in the build sequence. For example, some systems may not interpret shared data
specifications as intended. If these systems are the ones that deliver and deploy early, it
may fall to the later systems to adjust their implementation to compensate for shortfalls in
the early systems.
The Verification Process SoS verification efforts build upon the individual systems’ efforts, with the SoS systems
confirms that the system engineer and/or T&E team often depending on the constituent systems to ensure that the
element meets the design-to systems have implemented changes according to plans. It is typically impossible to test the
or build-to specifications. It whole SoS; hence, the SoS systems engineer or testing team needs to identify key risks to
answers the question "Did you the SoS and concentrate on those areas. The focus is on continuous test and evaluation
build it right?”. during development, followed by operational testing. Criteria from DoD or the appropriate
Service may largely determine which courses of action are available, and depending on the
stage of testing, this activity may be conducted by a test agency rather than the systems
engineers.
The Validation Process As with verification, the validation process builds upon individual system testing. Often,
answers the question of "Did because of the expense, only limited end-to-end testing is conducted at the SoS level. Here
you build the right thing". too, criteria from DoD or the appropriate Service may largely determine which courses of
action are available. In some cases, modeling and simulation is used to support this process
on the premise that testing is used to validate simulations of part of the SoS, and then the
validated simulations can support testing of other SoS constituents. In other cases, testing
focuses on the areas with the greatest risk. In mission-critical applications, some SoS view
end-to-end validation testing as critical to success and allocate their resources to make this
possible.
Transition is the process The primary transition focus for Orchestrating Upgrades to SoS is on transition activities for
applied to move … the end- the SoS, activities that are often conducted and managed at the constituent system level.
item system, to the user. These activities focus primarily on supportability and sustainment activities and are
performed in a variety of ways by the Service that sponsors the constituent systems.
Decision Analysis activities Decision analysis for Orchestrating SoS Upgrades to the SoS involves consideration of both
provide the basis for the SoS infrastructure and the constituent systems. The decisions here are those that must
evaluating and selecting be made to ensure the successful implementation of the Technical Plan for the SoS iteration.
alternatives when decisions Decision Analysis at this point often requires balancing the needs of the SoS and each of the
need to be made. constituent systems, availability of windows of opportunity, constituent system schedules,
and cost. Often the most critical decisions relate to what can be done when upgrades do
not go as planned. When a system cannot implement changes as planned, what should be
Systems Engineering Guide for Systems of Systems
Technical Assessment In Orchestrating Upgrades to SoS, the SoS systems engineer is responsible for monitoring
activities measure technical progress of the constituent systems as they implement changes. Systems engineering
progress and the effectiveness technical reviews for SoS should follow the recommended process for technical reviews
of plans and requirements. [DAG] and should address entry/exit criteria as they apply to the SoS technical plan. The
SoS systems engineer can conduct technical reviews for areas that are critical to the SoS, or
the systems engineers for the constituent systems can report the results of their reviews.
The SoS systems engineer will be responsible for assessing technical risks through these
reviews and must be prepared to address changes when progress is not made as anticipated
in the plans.
Requirements Management In Orchestrating Upgrades to SoS, requirements management comes into play when the
provides traceability back to solutions identified as part of the technical planning are problematic to implement. When
user-defined capabilities. changes are needed to adapt to implementation realities, the SoS systems engineer must
assess the changes and ensure that they address the requirements. This also involves
updating requirements traceability information as systems engineers for constituent systems
decide how to implement SoS requirements allocated to their system.
Risk Management … helps In Orchestrating Upgrades to SoS, the SoS SE team identifies and manages risks that relate
ensure program cost, to the SoS itself and its mission and objectives. In addition, the SoS SE team monitors risks
schedule, and performance associated with the individual systems to the extent that these risks affect the overall SoS
objectives are achieved at and its success or the constituent systems. Sometimes it is difficult to get individual systems
every stage in the life cycle to participate in an SoS-level risk board because it is not their primary focus. Risks from a
and to communicate to all constituent system can affect the entire SoS, but in many cases the risks of the constituent
stakeholders the process for systems only affect their own schedule and delivery timelines. However, when system-level
uncovering, determining the risk affects the SoS schedule, it is of concern to the SoS SE team.
scope of, and managing
program uncertainties.
Data Management … Data management for Orchestrating Upgrades to SoS focuses on capturing data about the
addresses the handling of changes to constituent systems made as part of the upgrade process, because SoS systems
information necessary for or engineers must ensure the compatibility of configurations of systems across the SoS. In
associated with product addition, as implementation problems arise and plans need to be adapted, data about these
development and changes needs to be collected to support SoS decision analysis and to feed back to design
sustainment. processes.
The Interface Management Interface management in Orchestrating Upgrades to SoS is a continuation of the Interface
process ensures interface Management focus done in the planning for changes to be made to systems to support SoS
definition and compliance evolution. During execution of the plans, the key is tracking the implementation of the
among the elements that agreed upon interfaces across the SoS. Interface Management is also needed to resolve
compose the system, as well conflicts/problems identified during implementation of required SoS functionality related to
as with other systems with interfaces by the constituent systems.
which the system or system
elements must interoperate.
71
Systems Engineering Guide for Systems of Systems
20012
16
10
2009
T1:
T1: 14
14 IDirect:
IDirect: 22
8 OC-3:
OC-3: 66 LinkWays:
LinkWays: 22
2006
6
2003
Teleport/JSEC Promina:
Promina: 88 Micro
Micro LOS:
LOS: 11
4
2
2000 Fort Monmouth WiMax:
WiMax: 22 COMTECH:
COMTECH: 33
0
Years
GSM:
GSM: 11
JITC
JITC X, C, Ku, Ka
DISA
DISA
DREN, DSN, SIPRNET,
NIPRNET, JWICS, DVS JNN
JNNRegional
RegionalHub
Hub
Crypto PEO
PEOC3T
C3T
CryptoMod
Mod
CERDEC
CERDEC
JOIN
JNN
JNN
Tactical
TacticalSatellite
Satellite CERDEC
CERDEC
CERDEC
CERDEC JTF HQ
Army USMC
AF Navy
General
General Dynamics
Dynamics
Taunton,
Taunton, MA
MA
DCGS-A
DCGS-A
PEO
PEO IEW&S
IEW&S
WIN-T
WIN-T
Battle SEC
SEC
BattleCommand
Command
SEC
SEC
JNMS
JNMS Legacy
Legacy Switches
Switches JNN
JNN SOSCOE
SOSCOE Future
Future Combat
Combat
SEC
SEC MSE,
MSE, SSS,
SSS, CDS,
CDS, SMU
SMU SEC
SEC FCS
FCS Systems
Systems
SEC
SEC
Tech Planning
Config Mgmt
Tech Assess
Data Mgmt
Implement
Rqts Mgmt
Risk Mgmt
Transition
Rqts Devl
Integrate
Interface
Decision
Solution
Analysis
Analysis
Validate
Logical
Design
Verify
Mgmt
Translating Capability
X X X X X
Objectives
Assessing Performance to
X X X X X
Capability Objectives
Orchestrating Upgrades X X X X X X X X X X X
In an acknowledged SoS, requirements are developed at two levels. The SoS SE team
addresses requirements across the SoS, and the systems engineers for each system
address the system requirements from their users. The SoS SE team is primarily
concerned with the translation of SoS capabilities/needs into SoS requirements that
provide the basis for SoS design solutions that also encompass the constituent systems.
Annex A, table A-1, summarizes how this process supports these core elements of SoS
SE.
73
Systems Engineering Guide for Systems of Systems
Because an SoS typically evolves over time, requirements may change based on both
internal and external factors. As a result, requirements development may be an
ongoing SoS activity, and the SoS requirements will evolve as well. Requirements
development in an SoS often continues through SoS architecture and design
development and implementation, since the architecture in particular will generate
requirements for systems in the SoS.
During each iteration of SoS development, the SoS systems engineer reviews
requirements and seeks to address them with available solutions, factoring in the
requirements and development plans of the systems in the SoS. As solutions are
implemented, detailed designs are developed for each system that is making changes.
The development approach, timing of increments, and the tempo for revisiting the
requirements are determined by the SoS manager and SE team based on the
characteristics of the SoS.
For new acquisitions, requirements are developed and validated through a formal
requirements process (JCIDS or a comparable process in the Service Components). In
some cases, this process applies to SoS, and the SoS is handled under the auspices of
an acquisition program. In other cases, SoS capabilities are identified based on
feedback from operations, strategic direction, or other drivers with the focus on
leveraging existing or developing systems and not new acquisitions. In these cases,
individual acquisitions programs may contribute components to the SoS, but the SoS
itself is not handled as an acquisition.
on the SoS. At a minimum the SoS systems engineer needs to remain cognizant of the
changing requirements of the constituent systems.
Annex A, table A-2, summarizes how this process supports these core elements of SoS
SE.
For a completely new system, the systems engineer can begin logical analysis with a
clean sheet to allocate functionality, whereas for an acknowledged SoS, the logical
analysis must take into account the functional allocation reflected in the constituent
systems of the SoS. SoS logical analysis focuses on composition of existing
functionality to meet SoS needs. In the SoS, the systems engineer focuses the logical
analysis on identifying which systems can support the capabilities that are needed, not
on iterating the synthesis and analysis of results until a desirable solution is achieved.
To do this the SoS systems engineer must understand and assess available systems
together with their future development plans (bottom-up analysis). In addition, the SoS
systems engineer must understand the needed SoS functionality and how that
functionality might be partitioned across legacy constituent systems, systems under
development, and systems still in planning (top-down analysis). The SoS systems
engineer needs to factor in the degree of difficulty in integrating constituent systems
through structured assessments and reviews with users, focusing particularly on legacy
systems openness. Less flexible legacy systems may constrain the SoS design and final
SoS capability.
75
Systems Engineering Guide for Systems of Systems
Annex A, table A-3, summarizes how Design Solution supports these core elements of
SoS SE.
The design solution process in an SoS environment is more complex than in a single
system environment because of the challenges of multiple stakeholders, integrations,
and test timelines, and the degree of interface developments. The SoS design solution
process occurs at two levels: the SoS framework-level and the constituent-system
level. The SoS systems engineer develops an architecture for the SoS and overlays it
on the constituent systems to provide a persistent framework for evolution of the SoS.
The design solution in an SoS incorporates approaches to meet specific requirements
that typically encompass changes in the constituent systems to enable the SoS-level
capabilities. This design process is normally the responsibility of the systems engineers
of the affected systems. The results of these processes are reflected at the top level in
the allocated baseline for the SoS and in updates to the technical baselines for the
affected systems.
An important step in engineering the SoS is to sort out how to allocate the SoS-driven
requirements to individual systems. In an SoS, functional allocation is typically based on
identifying where needed functions are supported by systems and assessing how to
leverage this functionality for the SoS. Functional “mapping” might be a better way to
describe this process which involves considerations beyond the technical (including
operational, fiscal, schedule, and other programmatic considerations) and will require
coordination with component programs, and probably multiple process iterations.
When the SoS design solution is selected, the SoS design specifications are placed
under configuration control as the SoS allocated baseline. The baseline captures the
design information as well as the traceability to the constituent systems. The individual
systems are responsible for incorporating the allocated SoS design requirements and
Systems Engineering Guide for Systems of Systems
maintaining their own allocated baseline at the system level. While it is important for
the SoS SE team to have insight into the constituent system baselines and the
associated plans for implementing those baselines, the constituent system baselines
remain under the control of the individual systems.
During the SoS design solution process, the SoS systems engineer works with the SE
teams for the systems to conduct trade studies at the SoS level to assess potential
changes in current and planned systems to address SoS requirements. Iterations of the
Requirements Development and Logical Analysis processes may also be required to
achieve a feasible design solution. The best overall SoS design solution may result in
constituent systems changes that require adjudication and additional iterations of the
SoS design.
The discussion here and in the preceding section focuses on the development of the
allocated baseline (architecture of the SoS and design changes to systems) to support
the SoS objectives as reflected in the functional baseline for the SoS. For evolutionary
SoS development, the architecture is a key element crossing the SoS increments. If
well designed, the architecture, particularly the key convergence points, is persistent
across multiple increments, and user functionality can be enhanced by adding or
upgrading constituent systems without disrupting the changes made in previous
increments. The architecture may need to be reviewed and evolved as needs and
technology change. These changes will be reflected in the SoS technical baselines.
Architecture management over time and across increments is likely to become an
important part of the broader SoS SE process as our understanding of SoS grows.
4.2.4 Implementation
According to the DAG chapter 4, “Implementation is the process that actually yields the
lowest level system elements in the system hierarchy. The system element is made,
bought, or reused.”
Annex A, table A-4, summarizes how this process supports this core element of SoS SE.
77
Systems Engineering Guide for Systems of Systems
Implementation in an SoS typically takes the form of constituent system changes, which
together create new or enhanced SoS capability. The systems engineers and
developers of the constituent systems take the lead in the implementation process, and
the SoS systems engineer acts as facilitator, negotiator, technical reviewer, and,
ultimately, integrator—as discussed in the next section.
4.2.5 Integration
According to the DAG chapter 4, “Integration is the process of incorporating the lower-
level system elements into a higher-level system element in the physical architecture.”
Annex A, table A-5, summarizes how Integration supports this core element of SoS SE.
Integration across the SoS is a core role for the SoS systems engineer. While the
systems engineers of the constituent systems are responsible for implementation and
integration of changes within their systems, the SoS systems engineer is responsible for
integration of the end-to-end functionality and performance across the SoS. Because
implementation in an SoS may be asynchronous, integration may be asynchronous as
well. A primary use of modeling and simulation in SoS is the creation of “stand-in”
emulations of SoS components to support integration and test. Integration facilities are
a common tool for SoS integration and test, and networked facilities are becoming more
Systems Engineering Guide for Systems of Systems
common. These facilities provide a venue both for integration testing as the
development of different parts of an SoS are delivered and for system-level regression
testing after SoS capabilities have been added, to ensure they continue to support their
system-level applications.
4.2.6 Verification
According to the DAG chapter 4, “The Verification Process confirms that the system
element meets the design-to or build-to specifications. It answers the question, "Did
you build it right?”.
Annex A, table A-6, summarizes how Verification supports this core element of SoS SE.
As is discussed in the implementation section above, changes to the SoS are typically
implemented by the constituent systems. Changes to the systems are documented at
the top level in the SoS allocated baseline and reflected in detail in the technical
baselines for the systems. Verification is done against these baselines. Verification
involves demonstrating that the design meets the design specification. The SoS systems
engineer should be cognizant of detailed test plans developed and implemented by the
systems and should oversee the results of the testing as it applies to the SoS.
4.2.7 Validation
According to the DAG chapter 4, “The Validation Process answers the question, ‘Did you
build the right thing?’ "
Annex A, table A-7, summarizes how Validation supports these core elements of SoS
SE.
79
Systems Engineering Guide for Systems of Systems
Validation of SoS capabilities assesses whether the changes made in the SoS have the
desired end-to-end effects. This involves demonstrating that the design meets the
capability objectives (derived requirements) of the user. The SoS SE should ensure that
changes key to the SoS are included in constituent systems’ test and evaluation plans
and should leverage the results of the T&E. To the degree possible this T&E is done as
part of the SoS development process in an environment in which the SoS is tested end
to end. The goal is to ensure that the changes in constituent systems have the desired
effect on the SoS results. This may be done in an integration and test laboratory
environment or as part of an exercise or a live test. The challenge for the SoS is that
the number of systems can sometimes be large, and full live testing can be prohibitively
expensive or impossible to schedule in a reasonable time. To the degree possible, it is
advantageous to conduct end-to-end testing in conjunction with testing of the
constituent systems, leveraging their investments in time and resources. In some cases
all the constituent systems may not be available; consequently, the SoS systems
engineers may need to use simulations or emulations of unavailable ones. These
simulations/emulations can be development efforts in their own right. Such an approach
would need to be planned well before it is needed. SoS systems engineers assess risks
to determine how best to conduct validation so that live testing is focused on those
areas with the highest risk.
4.2.8 Transition
According to the DAG chapter 4, “Transition is the process applied to move … the end-
item system, to the user.”
Annex A table A-8 summarizes how Transition supports this core element of SoS SE.
SoS upgrades are transitioned to the field by the system owners based on their own
processes. Because SoS upgrades are implemented in the constituent systems, it is the
owners of those systems who have the responsibility to field and maintain the system
with the upgrades introduced to support the SoS. Planning for the life cycle support of
the enhanced systems needs to be considered at the time that solutions are being
evaluated with the total cost of options including lifecycle support, and hence need to
be addressed as part of a decision analysis (discussed in section 4.2.9, below).
Systems Engineering Guide for Systems of Systems
Once a high level set of requirements is established, decision analysis is applied across
the SOS SE core elements including:
Annex A table A-9 summarizes how Decision Analysis supports these core elements of
SoS SE.
Because SoS decisions may have implications for constituent systems, SoS decision
analysis needs to explicitly consider the perspective of affected systems, stakeholders,
81
Systems Engineering Guide for Systems of Systems
etc. However, time and resources are often at a premium for systems engineers of the
constituent system. This may limit the level of involvement by the constituent system
SE teams. Consequently, the SoS systems engineer may need to anticipate the issues
that will affect the constituent systems and include an assessment of them as part of
the SoS decision analysis.
Finally, the SoS systems engineer is challenged to develop approaches to evolve the
ensemble of systems to meet new needs while accommodating the independently
owned and funded constituent systems, which themselves are often evolving to meet
their own system users’ needs. To attain this delicate balance and support decisions
that are typically outside of the SE purview, the SoS systems engineer must understand
systems and their relationships from multiple perspectives, including technical and
organizational relationships. These decisions include analysis of options and trades for
SoS design/architecture given current characteristics and development plans of
systems; assessments to determine which requirements can be addressed in what time
frame given system objectives, funding, and development schedules; and analysis of
how internal and external changes will affect the SoS. Several activities, including the
Software Engineering Institute’s SoS Navigator initiative, are examining these needs
and approaches [Brownsword, Fisher, Morris, Smith & Kirwan, 2006].
The criticality of technical planning for the success of systems is well recognized and for
the same reasons, technical planning is critical to the success of SoS. While regulations
do not explicitly discuss SoS, program managers should apply the key tenets of the
Department’s 2004 Systems Engineering policy: develop a Systems Engineering Plan
(SEP), assign a lead systems engineer, and conduct event-driven technical reviews that
involve independent subject matter experts [OUSD, 2004(1)]. A SEP preparation guide
provides a resource for technical planning [OUSD AT&L, 2008].
Annex A, table A-10, summarizes how Technical Planning supports these core elements
of SoS SE.
In some ways technical planning is more difficult for SoS than for single systems
because the SoS SE team is required to plan the evolution of the SoS in the context of
the independent technical plans for the constituent systems. The highly asynchronous,
parallel nature of system-level engineering activities makes good planning and
coordination, and management of SE processes and products more critical at the SoS
level. Systems engineers from constituent systems are already performing technical
planning for their own systems, and SoS technical planning will need to consider and
possibly augment the plans of those constituent systems. SoS technical planning must
be adequately resourced because of the inherent competition with the individual
programs for systems engineers’ attention. To appropriately mitigate risk to the SoS
effort, SoS SE must actively engage system-level systems engineers in SoS technical
planning. In most SoS programs some form of SE council or body is formed to address
crosscutting SoS planning.
In SoS, technical assessment addresses both technical progress at the SoS and system
level. Technical assessment is applied in two SoS SE core elements:
Annex A, table A-11, summarizes how Technical Assessment supports these core
elements of SoS SE.
In SoS, technical assessment of progress addresses two areas. The first is progress
toward meeting SoS capabilities. The second is progress towards implementing
changes/upgrades to the SoS, including changes in systems and inserting new systems
into the SoS.
In the first area, because the SoS SE team typically addresses user capability needs by
adapting multiple systems and technology insertion over time, it is important to develop
83
Systems Engineering Guide for Systems of Systems
user-oriented metrics that can be applied across venues to assess progress toward
meeting these objectives and collect data to assess this progress. While in most cases
at least some of the systems in the SoS already exist at the time the SoS is recognized,
the metrics should be independent of the specific systems. This is because specific
constituent systems may change over time. This topic is discussed in more detail under
the SoS SE core element Assessing Performance to Capability Objectives.
In the second area, as plans for SoS upgrades are developed and implemented, the SoS
systems engineer needs to assess progress in defining, planning, implementing,
integrating and testing the changes made to affect the upgrade. The SoS systems
engineer conducts the assessment as part of Orchestrating Upgrades to SoS. This
assessment includes technical assessment of the changes in the individual systems that
will be planned and implemented under the auspices of the program management and
systems engineers of the constituent systems. In defining upgrades, the maturity of
technologies to be incorporated is particularly critical in an SoS environment. Indicators
of maturity include metrics such as version stability. The SoS systems engineer needs
insight into the system-level work, but ideally system-level work is planned,
implemented, and assessed as part of the constituent system’s SE process. Whether a
member of the SoS SE team participates in the system reviews or the systems engineer
for the constituent systems provides updates to the SoS systems engineer, technical
assessment is based on the resources available and the criticality of the changes to the
SoS. Good SE practice requires the SoS systems engineer to follow a disciplined
technical review process for the SoS as defined in its SEP. The SoS systems engineer is
specifically interested in system implementation progress that affects the SoS
functionality, performance, or schedule (this is akin to the importance of critical IMS
synchronization points to SoS SE) because these issues could be a source of risks for
the SoS. Assessment encompasses functionality in the systems and the interfaces
between each system and the other systems in the SoS to implement the SoS thread,
including data communications and data utilization.
The challenge in this area is planning and implementing in the context of the
asynchronous development schedules of the systems. This means that if systems a, b,
and c all make changes for an SoS improvement, changes in these three systems will
Systems Engineering Guide for Systems of Systems
Annex A, table A-12, summarizes how Requirements Management supports these core
elements of SoS SE.
The SoS systems engineer needs to recognize when there are redundant requirements
across constituent systems. In an SoS context, redundancy across individual systems
may be perfectly acceptable, desirable and even necessary when considering the roles
that individual systems play apart from the SoS. In some cases, duplicative
requirements or functionality across the constituent systems may cause SoS conflicts.
For example, when multiple systems in an SoS each have different methods of
85
Systems Engineering Guide for Systems of Systems
computing track correlation, the combined results provide poor estimates of enemy
targets. It may be important to manage and resolve any conflicts, but it may be too
costly or disruptive to attempt to back out contentious, redundant requirements or
functions.
Requirements management in the classical sense is just as critical to the success of the
SoS; SoS requirements need to be defined in terms of measures of outcome and
mission measures of effectiveness to derive SoS measures of performance that can
then be allocated to individual systems as part of the SoS process across the relevant
SoS SE elements. However, there are some unique challenges for requirements
management in an SoS. In an environment of evolving threats and an evolving concept
of operations, a critical aspect of the requirements management activity is the
identification and management of new requirements over time, and the correlation and
traceability between the desired capabilities and the configuration of the deployed SoS.
The requirements management function must support this in a flexible and agile
manner. Furthermore, although requirements management may focus on specific
functional requirements of the SoS and individual systems, it is also very important to
address and manage the communications and data exchange requirements in the
context of the SoS.
Annex A, table A-13, summarizes how Risk Management supports these core elements
of SoS SE.
Risks identified and managed by the SoS SE team are those related to the SoS itself
and its mission and objectives. SoS risks are often tied to the strength of feasibility
evidence developed during the decision analysis and design solution activities. These
risks might be related to SoS scalability, quality of service, technology maturity,
Systems Engineering Guide for Systems of Systems
coordination of SoS risk management activities across the individual systems, ability of
constituent systems to provide needed SoS functions on time, and other individual
system risks that might affect the overall SoS success or other individual systems.
Risk management for an SoS begins with the identification of SoS objectives and the
identification of the risks that threaten the achievement of those objectives. While it is
true that minor individual program risks could be major risks to the SoS, it is also true
that significant system risks may have little or no impact on the SoS functionality.
Furthermore there may be risk to a set of SoS objectives which are not risks to the
constituent systems (e.g., unwanted emergent behavior, infrastructure, integration
risks, cost risk).
Major risks associated with SoS may relate to the limited influence the SoS systems
engineer may have on the development of critical individual systems in addition to
technical risks associated with those individual systems and platforms. Independent
evolution of the individual systems can lead to unforeseen deviations from SoS program
objectives (lifecycle cost, performance, schedule). Each of the core SE management
processes can identify and support risk assessment. To address risks, as addressed in
section 4.1., Technical Assessment, the SoS manager and systems engineers must
understand each individual system’s planned evolution. In some cases, mitigation
strategies for SoS can include preplanned substitutions of individual systems, especially
if some of the systems are reaching their service life and may be retired, undergoing
Service Life Extension Programs (SLEP), remanufacture, and so on. However, in many
cases, it may not be an option to replace high-risk or problematic individual systems,
and risks associated with these systems need to be addressed in other ways.
Risk analysis includes addressing technical risks associated with each of the individual
systems throughout their life cycle as well as programmatic aspects, which include cost
and schedule. Although it may be more difficult to quantify the uncertainties for an
SoS, it may be easier to quantify risks of the legacy systems involved in the SoS.
Special care should be taken, however, in evaluating the incorporation of legacy
systems in an SoS, particularly those with incomplete technical documentation.
Although subsystem risks may not have a significant impact on the parent individual
system, they could constitute a major impact on the SoS and may require different
approaches to calculate or buy down risks accumulated across multiple systems. It is
important to not only use risk criteria already employed at the system level, but instead
to develop the impact criteria and ratings at the SoS level. These criteria should be
updated over time to reflect risk tolerance at the SoS level.
87
Systems Engineering Guide for Systems of Systems
for identifying and assessing risk to the SoS. A senior person from the SoS organization
should lead the effort to ensure necessary rank and leadership.
Since the initial articulation of SoS objectives may not support detailed requirements
development, early experimentation focused on military utility and worth can be an
important risk-reduction activity.
Annex A, table A-14, summarizes how Configuration Management supports these core
elements of SoS SE.
CM influences all the SoS SE elements, but it is in these five that the SoS SE actively
manages key aspects of the SoS configuration. That is why these five are called out
explicitly in this Guide. In other SoS SE core elements, the managed configuration is
used as a point of reference and the areas under consideration are under CM by the
systems and not the SoS. In Assessing SoS Performance, the SoS systems engineer
examines performance of the SoS in a variety of venues, but does not control any
aspect of the SoS baselines. In Orchestrating SoS Upgrades, the SoS SE team is
overseeing the implementation of the Technical Plan associated with an SoS upgrade,
then integrating, testing, and evaluating the constituent systems in the SoS
environment. The team is not, however, controlling the individual baselines of the
constituent systems.
Beyond this, in acknowledged SoS, there is management authority at both the SoS and
the system levels. For SoS, CM should be applied to the establishment and
management of the SoS technical baselines (functional, allocated, and product). It is
important to manage these baselines at the SoS level so that systems engineering can
help structure and control the SoS evolution over time. These baselines can also be
used by the constituent systems as they consider changes to their own configurations.
In an SoS, the functional baseline is developed and managed under several elements.
In Translating Capability Objectives, high level requirements are developed and updated
Systems Engineering Guide for Systems of Systems
and are then ready for further analysis and assignment to a functional baseline in
Addressing Requirements and Solution Options. In Developing and Evolving an SoS
Architecture, added requirements are identified for the SoS and specified at a level
where they can be further analyzed and assigned to a functional baseline by Addressing
Requirements and Solution Options. The allocated baseline is also established under
Addressing Requirements and Solution Options, as solutions are developed and
requirements mapped to individual systems for implementation. Additional changes to
systems may also be identified and incorporated into the baseline to improve the
performance of the SoS. Finally, the product baseline is identified and monitored under
Understanding Systems and Relationships as systems changes are implemented and
deployed.
SoS CM requires an understanding of the systems that support the SoS objectives and
their relationships. For the SoS to be successful, the SoS systems engineer needs to
have a good understanding of the constituent systems, their characteristics that are
salient to the SoS, and the way they currently work together to address the end-to-end
SoS needs. While systems engineers of the constituent systems are responsible for the
detailed CM of those systems, those characteristics that affect the SoS are mirrored in
the SoS CM and there should be the ability to track requirements between SoS CM and
the salient elements of the CM of constituent systems.
Data management is applied across all the core elements of SoS SE:
Annex A, table A-15, summarizes how Data Management supports these core elements
of SoS SE.
The SoS data include information on the development plans of the systems and their
management and funding profiles as well as other information relevant to SoS progress.
A key challenge for data management in an SoS context is gaining access to data from
constituent systems in a form that facilitates analysis of crosscutting issues. This
process can be complicated because different systems create and retain different data
and common data may not be readily available across systems. Systems may be
89
Systems Engineering Guide for Systems of Systems
reluctant to share data outside of the system context, and some needed data, may be
considered proprietary and held by developers, classified at multiple levels, or
compartmented. These challenges pose issues for crosscutting SoS decision analysis.
An MOA may be one solution to the SoS data problem. In the MOA, systems engineers
might define an approach for SoS data management that includes data access, data use
and sharing, and creation of an SoS shared repository for common data, all managed in
a way that reassures stakeholders that access to their data will be controlled.
Throughout the SoS SE process, critical data needs to be captured and understood in
the context of SoS activities. As a particular source of data critical to the SoS may
evolve or become unavailable, an understanding of critical data needs may allow the
discovery of another data source for the SoS activities. This is particularly important for
an SoS because there are more diverse participants in an SoS evolution and available
data on SoS activities will be a key to ensuring transparency in SoS processes across
participants at both the systems and SoS levels.
Data supports all of the core elements of SoS SE. The data collection process includes
information about the implementation of each core element and the results of the core
element as they inform other core elements of SoS SE. The core elements of SoS SE
are described in more detail in section 4.1.
Annex A, table A-16, summarizes how Interface Management supports these core
elements of SoS SE.
use in DoD systems are provided in the Defense Information Technology Standards
Registry (DISR).
Data and metadata harmonization are becoming the central interface issues, with the
result that the focus of interface management will be on data exposure and semantics.
In many cases the SoS SE must pay more attention to data, data interoperability, and
semantics than to interface issues. In most cases, the SoS does not “control” individual
system interfaces; rather, the interfaces are “managed” through agreements and
negotiation. It is important to consider that a given individual system may be part of
more than one SoS, and consequently interfaces and interface changes may impact
more than one SoS. Resources in this area include the DoD Metadata Registry (DMR)
and the DoD Net-Centric Enterprise Services (NCES) Service Registry. Approaches to
particular SoS data requirements can be found in the DMR with a registered DoD
service.
91
Systems Engineering Guide for Systems of Systems
There is increasing emphasis on SoS in the DoD today as the Department moves from a
platform focus to an emphasis on capabilities. Increasingly SoS are being recognized
and are the subject of management and engineering attention. DoD SoS typically are
not new-start acquisitions per se, they are modifications to ensembles of existing and
new systems which together address capability needs. An SoS is an overlay on existing
and new systems, where the systems retain their identity, and management and
engineering continue in the systems concurrently with the SoS. Rather than having full
control over the systems, SoS managers and systems engineers work collaboratively
with the managers and systems engineers of the constituent systems to leverage and
influence the development of those systems to address SoS needs.
There are seven core elements that characterize SE for systems of systems. In SoS SE,
systems engineers are key players in (1) translating SoS capability objectives into SoS
requirements and (2) assessing the extent to which these capability objectives are
being addressed, as well as (3) monitoring and assessing the impact of external
changes on the SoS. Central to SoS SE is (4) understanding the systems that
contribute to the SoS and their relationships and (5) developing an architecture for the
SoS that acts as a persistent framework for (6) evaluating SoS requirements and
solution options. Finally the SoS systems engineer (7) orchestrates enhancements to
the SoS, monitoring and integrating changes made in the systems to improve the
performance of the SoS. These core elements provide the context for the application of
SE processes. The core SE processes developed and used in the acquisition of new
systems continue to support SoS and the SoS environment affects the way that these
processes are applied.
engineers of those systems. (3) Technical management of the SoS needs to balance
the level of participation required on the part of the systems, attending to transparency
and trust coupled with focused active participation in areas specifically related to the
systems and the SoS. There is a real advantage to (4) an SoS design based on open
systems and loose coupling which impinges on the systems as little as possible,
providing systems maximum flexibility to address changing needs and technology
opportunities for their users. Finally (5) SoS design strategy and trade studies need to
begin early and continue throughout the SoS evolution, which is an ongoing process.
This version of the SoS SE Guide is an initial step toward addressing the area of SE
applied to SoS, and it begins the process of understanding SE in the broader area of
SoS. In many cases the guide identifies issues facing systems engineers in an SoS but
does not provide detailed guidance on how to address the issues. As experience with
SoS grows, more guidance will be developed and provided in updated versions of the
guide. In addition, this first step leaves a number of important issues still to be
addressed. These will form the basis for further work in this area of increasing
importance of the DoD.
First, in future versions, the guide will expand to offer additional guidance to address
the challenges raised in this version. For example, future versions may answer some of
the following questions:
• What are some options for SoS management which would facilitate SE and ensure
more predictable progress?
• What are some effective ways to accomplish SoS evolution in light of the
asynchronous development of individual systems?
• What are the strategies for developing an architecture for an SoS and its
configuration management? What are their pros and cons?
• What are the various strategies to effectively integrate constituent systems into a
viable, evolving and, in some cases, ad hoc SoS?
• What are the methods to assess composite and technical maturity across SoS
constituent systems?
• How does the DoD implement SoS with coalition partners?
Second, in parallel, more work is needed to better understand the role of SE in SoS in
areas not addressed in this guide. This understanding will enable one to better address
SE issues that go beyond the initial class of SoS addressed here. These areas include:
93
Systems Engineering Guide for Systems of Systems
Finally, as the DoD moves away from development of individual systems and begins to
explore development of net-centric enterprises, there are new challenges for SE which
need to be addressed, particularly the key characteristics of net-centric enterprise
systems and their impact on SE.
Systems Engineering Guide for Systems of Systems
REFERENCES
Boxer, P., Morris, E., Anderson, W., & Cohen, B. (2008), “Systems-of-Systems
Engineering and the Pragmatics of Demand,” Montreal, Canada: IEEE Systems
Conference, 7-10 April.
Brownsword, L., Fisher, D., Morris, E., Smith, J. & Kirwan, P. (2006), “System of
Systems Navigator: An Approach for Managing System of Systems Interoperability,”
Integration of Software-Intensive Systems Initiative, Software Engineering Institute,
http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tn019.pdf.
Chairman of the Joint Chiefs of Staff (CJCS), 2007(1), CJCS Instruction 3170.01F “Joint
Capabilities Integration and Development System,” Washington, DC: Pentagon, May 1.
Chairman of the Joint Chiefs of Staff (CJCS), 2007(2), CJCS Manual 3170.01C
“Operation of the Joint Capabilities Integration and Development System,”
Washington, DC: Pentagon, May 1.
Dahmann, Judith and Kristen Baldwin, (2008), “Understanding the Current State of US
Defense Systems of Systems and the Implications for Systems Engineering”, Montreal,
Canada: IEEE Systems Conference, 7-10 April.
Department of Defense (DoD), 2003, DoD Instruction 5000.2 “Operation of the Defense
Acquisition System, Ch. 3.5 Concept Refinement," Washington, DC: Pentagon, May 12.
Department of Defense (DoD), 2004(2), DoD Directive 8320.2 “Data Sharing in a Net-
Centric Department of Defense," Washington, DC: Pentagon, December 2.
Department of Defense (DoD), 2007, Guidance for Development of the Force (DRAFT),
Washington, DC: Pentagon.
95
Systems Engineering Guide for Systems of Systems
Joint Publication 1-02 (JP 1-02), Department of Defense Dictionary of Military and
Associated Terms, 12 April 2001.
Office of the Under Secretary of Defense for Acquisition, Technology and Logistics
(OUSD AT&L), 2004(1), Memorandum on Policy for Systems Engineering in DoD,
Washington, DC: Pentagon, February 20.
Office of the Under Secretary of Defense for Acquisition, Technology and Logistics
(OUSD AT&L), 2004(2), Memorandum on Policy Addendum for Systems Engineering,
Washington, DC: Pentagon, October 22.
Office of the Under Secretary of Defense for Acquisition, Technology and Logistics
(OUSD AT&L), 2004(3), Implementing System Engineering Plans in DoD –Interim
Guidance, Washington, DC: Pentagon, March 30.
Office of the Under Secretary of Defense for Acquisition, Technology and Logistics
(OUSD AT&L), 2007, Risk Management Guide for Acquisition Sixth Edition (Version 1.0),
Washington, DC: Pentagon, August.
Systems Engineering Guide for Systems of Systems
Office of the Under Secretary of Defense for Acquisition, Technology and Logistics
(OUSD AT&L), 2007, System of Systems System Engineering Guide: Considerations for
Systems Engineering in a System of Systems Environment V0.9, Washington, DC:
Pentagon, December 22.
Office of the Under Secretary of Defense for Acquisition, Technology and Logistics
(OUSD AT&L), 2008, Systems Engineering Plan Preparation Guide, Washington, DC:
Pentagon, April.
97
Systems Engineering Guide for Systems of Systems
Systems Engineering Guide for Systems of Systems
ANNEX A
Support of SE Processes
(Technical Management and Technical)
To System of Systems SE
99
Systems Engineering Guide for Systems of Systems
101
Systems Engineering Guide for Systems of Systems
103
Systems Engineering Guide for Systems of Systems
105
Systems Engineering Guide for Systems of Systems
107
Systems Engineering Guide for Systems of Systems
Understanding Risk management is a core function of SE at all levels. In Understanding Systems and
Systems and Relationships, the systems engineer assesses the current distribution of functionality
Relationships across the systems and identifies risks associated with either retaining the status quo
or identifying areas where changes may need to be considered. The systems
engineer also considers approaches to monitor, mitigate, or address risks. Such risks
might include:
- Unanticipated effects of different implementations of functionality needed in a
core thread for the SoS
- Changes in functionality in core systems due to new and conflicting needs of the
system users
- Limited capacity in systems in view of unknown SoS demand.
- Technical constraints within systems which impact their ability to adapt to
changes needed by SoS
Systems owners’ resistance to implementing the changes needed by SoS, because of
competing priorities for funds, development time, or technical staff
Assessing Risk Management applied to Assessing Performance to Capability Objectives identifies
Performance to and monitors those risks related to the ability to achieve performance and capability
Capability Objectives objectives. Risk management is applied in several ways. First, in this SoS SE core
element, the SoS systems engineer has the opportunity to assess if risks identified as
part of the SE process have been adequately mitigated or removed. New risks are
identified and plans are made to manage them.
In addition, there are risks inherent in the assessment process itself. Particularly in
exercises or operational environments, there is not the level of control available in
laboratory-based technical investigations of single systems. In these less controlled
venues, it is important to identify and assess risks when the observed results are due
to something other than the SoS. There are two types of risks to the validity of the
results. First, there are risks based on internal threats to validity of the results. What
else was going on within the venue which might account for the results? For
example, use of a training exercise as a venue might mean that effects of new SoS
features may not be apparent because the training audience acting as users in the
exercise are not yet proficient in use of these features. Second, there are risks due
to external threats to validity of the results. Did characteristics of the test venue
itself influence the results? For example, did the operational scenario stress the SoS
in areas where upgrades had been made? If not, a lack of performance
improvement may be due to this rather than ineffectiveness of the changes. Because
the feedback on SoS progress is important input across SoS SE core elements, it is
important to ensure that these risks are addressed and the results are appropriately
understood.
Systems Engineering Guide for Systems of Systems
109
Systems Engineering Guide for Systems of Systems
Understanding Understanding Systems and Relationships is where the CM process for the “as is” SoS
Systems and resides and is maintained as the SoS product baseline. In a system the CM process
Relationships addresses all of the ‘product’s’ features where the system itself is the product. In an
SoS, the ensemble of systems and their functionality is the product; the SoS CM
depends on the CM of the systems to maintain much of the product information,
since the system owner, PM, and system systems engineer normally retain
responsibility for their systems. The SoS CM focuses on the linkage to the system CM
and crosscutting attributes which pertain to the SoS not addressed by the CM of the
systems.
In some cases, a new version of a product created for use in the SoS may, in effect,
become a ‘new’ product (often the case with software but not exclusively). If this
new product is the responsibility of the SoS, then the SoS systems engineer assumes
CM of the product. If it stays with the owner of the original product (e.g., as part of
a ‘product line’), then the CM stays with that manager for CM, and the identifiers
which link to the new product are retained at the SoS level. In this context, ‘linked’
means a logical, not necessarily an ‘automated’, connection. When working with a
mix of legacy and new systems, cost and practicality typically make the use of
common or electronically linked systems infeasible. The important point is the SoS
maintains CM over the aspects of the SoS critical to the SoS and has access to the
information on the systems which are under CM by the systems engineer for the
system and system manager.
Developing and As the SoS architecture requirements are derived and scheduled for implementation,
Evolving an SoS they become part of the SoS functional baseline. And when the SoS architecture
Architecture requirements are allocated to the constituent systems, they become part of the SoS
allocated baseline. Maintenance and evolution of these baselines are accomplished
through CM. The architecture of the SoS defines the SoS top-level technical
characteristics and is a key component of the SoS baselines that are managed by CM.
The architecture provides the overlay to the description of systems and relationships.
Given its importance for the SoS, the architecture itself needs to be under
configuration control because the architecture should apply across iterations of SoS
changes (which may be asynchronous and concurrent). Thus, the systems engineer
will rely on CM to access and capture the impact of design changes at any time.
Ideally the architecture is ‘persistent’, but as a practical matter it too will evolve,
incorporating changes that need to be managed by the SoS systems engineer and
accessible to the systems engineers of the constituent systems.
Monitoring and One of the responsibilities of the Monitoring and Assessing Changes core element is
Assessing Changes to capture the “as is” configuration of the SoS as the constituent systems implement
and deploy their own new releases. The new releases typically contain new functions
needed to support SoS capabilities as well as new functions needed by the
constituent system users and stakeholders. Under this core element, the SoS SE
team may also (but not always) establish a formal Configuration Control Board to
review and assess how planned changes to constituent systems may affect the SoS.
Addressing As part of Addressing Requirements and Solution Options activities, the SoS SE team
Requirements and identifies the functional and allocated baselines for the next SoS iteration and places
Solution Options them under CM.
Systems Engineering Guide for Systems of Systems
Understanding As noted above, for each SoS SE element, selected data will need to be identified and
Systems and retained for SoS use in this and other elements. For Understanding Systems and
Relationships Relationships, data needs to be collected and retained about:
- Functionality in systems
- Relationships among systems, including interfaces for real-time data exchange,
organizational relationships, development plans, etc.
- Extent to which common or cross cutting attributes are present across systems
Assessing The types of data collected in this core element, Assessing Performance to Capability
Performance to Objectives, include the characteristics of the assessment venue (the players, the
Capability Objectives scenarios, the state of the systems and SoS at the time of the event), the
measurement data collected, and the analysis approach and results. By collecting
and accumulating data across venues and using common measures, the systems
engineer can develop a body of knowledge about the SoS. This body of knowledge
represents different perspectives that can provide a valuable resource to the systems
engineer as the SoS evolves. It also provides a data resource for identifying
unintended effects over time or for assessing issues later without repeated
assessments.
Developing and Given its importance for the SoS, data about the architecture and design needs to be
Evolving an SoS collected as part of Developing and Evolving an SoS Architecture. Because the
Architecture architecture is intended to apply across iterations of SoS changes (which may be
asynchronous and concurrent) and may be needed by the systems engineers of the
individual systems, ensuring that data for understanding them is continuously
accessible is an important SoS SE function. The data generated for this core element
include:
• The architecture drivers and tradeoffs
• Architecture description including CONOPS (could be multiple)
• Systems, including functionality and relationships
• SoS threads
• End-to-end behavior of SoS to meet objectives, including flow of control and
information
• Principles for behavior
• Risks
Technical plans for migration/implementation
Monitoring and The focus of risk management for Monitoring and Assessing Changes is the
Assessing Changes determination of the risks introduced by identified changes. Following are some
possible areas of concern:
• Technology maturity, especially version stability (this is a critical factor in SoS
program success)
• Inclusion of legacy systems – while this may appear to lessen SoS risk, it may in
fact complicate the SoS with a number of unknowns and hence increase risk
• Preplanned system substitutions as risk mitigation approach – sometimes viable,
other times not.
As noted earlier, changes in one aspect of an SoS may directly and indirectly affect
the entire SoS or one or more of its constituent systems. It is important that the SoS
systems engineer gain insight into the combined interactions of the SoS, to include
processes within and across systems that create the functionality, performance, and
behavior of the SoS. Further, it is critical for the SoS systems engineer to maintain
awareness of development and modernization activities and schedules of individual
systems to identify possible problematic changes as early as possible.
111
Systems Engineering Guide for Systems of Systems
113
Systems Engineering Guide for Systems of Systems
ANNEX B
115
Systems Engineering Guide for Systems of Systems
Systems Engineering Guide for Systems of Systems
117
Systems Engineering Guide for Systems of Systems
Systems Engineering Guide for Systems of Systems
119
Systems Engineering Guide for Systems of Systems
Systems Engineering Guide for Systems of Systems
121
Systems Engineering Guide for Systems of Systems
Systems Engineering Guide for Systems of Systems
123
Systems Engineering Guide for Systems of Systems
Systems Engineering Guide for Systems of Systems
125
Systems Engineering Guide for Systems of Systems
Systems Engineering Guide for Systems of Systems
127
Systems Engineering Guide for Systems of Systems
Systems Engineering Guide for Systems of Systems
129
Systems Engineering Guide for Systems of Systems
Systems Engineering Guide for Systems of Systems
131
Systems Engineering Guide for Systems of Systems
Systems Engineering Guide for Systems of Systems
133
Systems Engineering Guide for Systems of Systems
Systems Engineering Guide for Systems of Systems
135
Systems Engineering Guide
for Systems of Systems
Version 1.0
August 2008
Department of Defense
Office of the Deputy Under Secretary of Defense
for Acquisition and Technology