Systems Engineering Life-Cycle Processes as Applied to Systems of Systems

Definition: Systems of systems life cycle is evolution with time of a system of systems

Keywords: life cycle, system of systems, wave model

MITRE SE Roles and Expectations. MITRE is often asked to support the development of a broad capability that depends on multiple organizations, activities, and systems that are not under the direct control of the sponsor. Accomplishing this requires an understanding of the broad capability, organizations, activities, and systems that contribute to this capability, a structured approach to understanding the status of the systems, and the capability to assess options for improvements and to orchestrate changes across multiple independents systems to evolve the capability.


Systems of systems represent a type of system with a particular set of characteristics. The managerial and operational independence of constituent systems in an SoS and the evolutionary nature of SoS development all affect the typical life cycle of an SoS.

First, in recognition of the role of the constituents in an SoS, SoS development is depicted as a two-tiered development in a "double V" type of approach (Figure 1), with systems engineering occurring for the constituent systems in parallel with systems engineering for the SoS, and evolution in the SoS is based on changes in the systems through their own development cycles.

Figure 1. "Double V" Representation of Systems Engineering for an SoS (Click image to enlarge)

This view implies a single-pass development of an SoS; however, in practice, systems of systems are often long lived and persistent, and evolve over time based on changes in the constituent systems. The result is that most systems of systems do not follow a typical systems engineering process from a statement of need through requirements and design to implementation, validation and delivery, and eventual disposal, but rather they evolve over time. One conceptual representation of this SoS life cycle is the "SoS Implementer’s View" (also known as the SoS Wave Model) shown in Figure 2. This model views SoS development as an evolutionary, incremental, and iterative process, based on an understanding of the SoS objectives, the evolving state of the constituent systems, and an incremental approach to adapting systems to improve SoS performance.

Figure 2. Systems Engineering Life Cycle for an SoS [1] (Click image to enlarge)

It is not uncommon to consider SoS development as a one-time activity and to focus only on a single wave of development, expecting that integration across a set of systems can be done in a single development and fielding, as we often do with systems. However, it is often not possible to effect changes in all the constituent systems in one development cycle, so an incremental approach is common. And once an initial SoS implementation has been established, changes can occur in the constituents independent of the SoS, and over time the changes can erode or disrupt the SoS. So where SoS objectives are important over time, continued engineering attention to the evolution of the SoS becomes important, if only to maintain SoS capability. Finally, changes in the environment, technology, and needs of the SoS and systems all point to the need for the SoS to adapt to new and changing circumstances; hence this adaptive, interactive, agile approach to development and evolution.

This depiction of the SoSE life cycle represents SoSE as steps that are implemented in an iterative fashion, with each step providing feedback into the ongoing, evolutionary process. The major steps in the life cycle are:

  • Initiate SoS: Provides foundational information to initiate the SoS.
  • Conduct SoS Analysis: Provides analysis of the "as is" SoS and basis for its evolution.
  • Develop SoS Architecture: Develops/evolves the persistent technical framework for SoS evolution and a migration plan identifying risks and mitigations.
  • Plan SoS Update: Evaluates SoS priorities, backlog of SoS changes, and options to define plans for the next SoS upgrade cycle.
  • Implement SoS Update: Oversees system implementations and plans/conducts SoS-level testing, resulting in a new SoS product baseline.
  • Continue SoS Analysis: Revisits the state of and plans for the SoS as the basis for SoS evolution.

This is just one way to represent the SoSE life cycle, which reflects a growing understanding of SoS life cycle implementation. Figure 3 shows another representation, developed by the European Commission project Designing for Adaptability and EvolutioN in Systems of Systems Engineering (DANSE).

Figure 3. SoS Life Cycle as Depicted by DANSE [2] (Click image to enlarge)

Although this DANSE depiction is different in some ways, it shares essential characteristics of the SoSE life-cycle process. As described in the original paper on the SoS implementer's view model (Dahmann et al., 2011), the key features of this life-cycle model reflect the nature of systems of systems and its impact on systems engineering:

  • Multiple Overlapping Iterations of Evolution reflect the fact that most systems of systems leverage developments of their constituent systems, and consequently, systems of systems are characterized by incremental development.
  • Ongoing Analysis provides an analytic basis for each iteration of SoS evolution. Unlike traditional systems engineering in which upfront analysis drives development, engineering of systems of systems requires continuous analysis to address the dynamic nature of the SoS and its context.
  • Continuous Input from External Environment is key for SoSE, since any manager or engineer of an SoS has control over only a small part of the environment that affects the SoS.
  • Architecture Evolution is also important. While the architecture of an SoS ideally provides a persistent framework for the SoS evolution over time, the planned SoS architecture is typically implemented incrementally and may itself evolve.
  • Forward Movement with Feedback drives the evolution of an SoS, which typically adopts a "battle rhythm" driven by elements in the SoS context (e.g., the development plans of a key constituent system or the unit fielding schedule) that are not under the control of the SoS. These external driving events effectively "pace" the SoS evolution. While there may be feedback within an evolution, many systems of systems adopt a "bus stop" approach, where they deliver those changes that can be implemented during an iteration and defer the rest to subsequent evolutions (or the next time the bus stops.)

The Major Steps in the Life Cycle

Initiate SoS

An SoS activity is typically initiated in response to some type of trigger event or new need that cannot be addressed by a single system. In most cases, most of the constituents are in service, and some action is required to work with these existing systems to affect some new capability or meet a new user need.

An effective SoS has several fundamental starting points that provide the foundation for engineering for the new capability. At this first step, it is important to address a set of basic questions. Each question has a corresponding engineering artifact. These artifacts are shown in brackets after each question following Table 1. Table 1 compares SoSE artifacts and system artifacts.

Table 1. SoSE Artifacts Compared to System Artifacts [3]




Capability Objectives

Focused on capabilities at the SoS level. Solution(s) typically require multiple constituent systems, not all of which may be known in advance. Scope typically initially defined in the charter for the SoS.

Addresses a gap in a user capability as defined by formal process (Joint Capabilities Development System or component equivalent process); may provide functionality that supports SoS capability objectives.

Concept of Operation (CONOPS)

Multiple system focus. Often developed after constituent systems have been fielded; evolves over time, sometimes substantially.

Single-system focus. Defined when systems acquisition begins.

Systems Information

Focus is on system-level information that impacts SoS-level capability objectives. Extends beyond technical issues to include operational, fiscal, organizational, and planning issues.

Focus is on interfaces and inputs/outputs with external systems and how they support or inhibit single-system performance. Focus is usually on technical issues.


Requirements "space" versus set of specific requirements. Defined at a level of detail that enables trades among potential and actual constituent systems and interfacing external systems.

Defined by needs of the operational users of the system and by the threat. Usually articulated as detailed operational requirements or specified technical requirements.

Performance Measures and Methods

Focus is on performance of SoS solution. As independent as possible of the specific systems to allow for assessment of alternative implementation approaches.

Focus is on performance of the specific system and connections with external interfaces.

Performance Data

Often collected in operational environment. Used to support continuous improvement of the SoS.

Predominantly collected in traditional acquisition life-cycle test and evaluation, including simulation/modeling. Used to support fielding decisions.

Systems Engineering Planning Elements

Focus is on determining rhythm, organizational structure, technical reviews, and decision processes across SoS evolution. Ability and willingness of constituent systems to support SoS plans is an important consideration.

Focus is on an individual system, typically part of the acquisition process; takes the form of a Systems Engineering Plan.


Risks and Mitigations

Focus is on desired capabilities and undesirable emergent behaviors of the SoS. Includes single-system risks or dependencies essential to SoS capabilities and plans.

Focus is on system issues and potential problems. Includes external dependencies that pose special risks.

Master Plan

Focus is on SoS-level view across multiple increments and touch points for constituent systems. Reflects the SoS evolution strategy. Focus is often on continuous improvement versus achieving a defined end state.

Focus is typically on individual system and approach to achieve defined end state.

Reflects the system acquisition strategy.



Focus is on managing relationships among multiple organizations. Agreements support SoS evolution, including specific commitments to execute SoS increment development.

Focus is on defining specific system dependencies (e.g., commitments to provide components to a system through government-furnished equipment or commercial off-the-shelf components).


A shared framework primarily aimed at informing analysis and decisions for developing or evolving SoS capabilities. A context for understanding the relationships among constituent systems and developing implementation options for meeting capability requirements. Includes key constituent systems information, connectors and protocols used to communicate and/or synchronize processing across the constituents, key data elements/structures that cross interfaces, and key data conversions to facilitate data sharing and communications between constituents.

A framework for analyzing and making decisions on system development and interfaces with external systems.

For the single system, includes information about system's top-level components, connectors between the components, protocols used to communicate between the components and synchronize processing across the components, and key data elements/structures that cross interfaces between the components and any interfacing external systems.

Technical Baselines

Focus is on SoS-level description plus identification of constituent system baselines that are part of the SoS baseline.

System detailed artifacts/components that comprise the system baseline.

Technical plan(s)

Focus is on planning the implementation of changes to constituent systems to execute an SoS increment.

Focus is on implementation of changes to the system, including those required for the system to interface with external elements.

Integrated Master Schedule

Set of SoSE activities and milestones plus key single-system activities and milestones that are driving SoS critical path. Focus is on key synchronization points among SoS constituents and pointers to development schedules of constituent systems for the current SoS increment.

Detailed list of development activities, milestones, and associated schedule for the system.

Key questions for the initiation of an SoS include:

  • What is the top-level objective of the SoS? What need is being addressed that the current systems do not satisfy? [SoS capability objectives]
  • What is the CONOPS or business process for how the systems in the SoS will be used to meet the new needs? How does this differ from the current situation? [SoS CONOPS]
  • What are the major systems that will form the basis for the SoS? What are the key technical and programmatic characteristics of the systems (e.g., who owns and operates the systems, who are the primary users, what servces do they provide)? What are the key technical characteristics of the system? [Systems information]
  • What are the initial areas of risk for executing the efforts? What issues may arise that will limit or inhibit the development of the SoS to meet the user needs? [SoS risks]

The answers to these questions provide the starting point for developing the SoS capability.

Conduct SoS Analysis

Systems engineering for an SoS begins with analysis of the SoS needs and objectives in light of the current state of the constituent systems. In most cases, the core constituent systems are in service, and the role of systems engineering for the SoS is to develop an approach to meet the SoS needs using the functions or services of the current systems, augmenting them or working with their owners to adapt them to meet the new needs while continuing to support current users. If this is the first time the SoS has been treated as a "system of interest," compiling the data for this analysis may be a large task, since there may be no one place to find the information. This task should not be underestimated, and it may be done incrementally, with the first pass-through, that is, the first wave, representing the SoS at a higher level, with increased levels of detail in subsequent waves.

In doing this analysis, the SE starts with understanding the user objectives and CONOPS, and addresses the following questions:

  • What is the current status of the systems that are expected to support these new objectives? How do the capabilities of these systems map to the functionality needed to implement the CONOPS? [SoS technical baselines]
  • How can I measure how well the systems are addressing user needs (and meeting the capability objectives)? [SoS performance measures and methods, a basis for overall SoS performance and continuous SoS improvement]
  • What data do I have or can I develop to assess how well the current systems are meeting these objectives? [SoS performance data to assess progress toward SoS capability objectives]
  • How well are the current systems meeting SoS user needs? Where are the gaps? What is the source of those gaps? [SoS requirements space, first order SoS user needs and functions to provide the capability in various environments]
  • What are the key SoS risks and mitigations, especially those that emanate from outside the SoS, including changes to constituent systems of the SoS? [SoS risks]

The activities associated with each of these questions are illustrated in Figure 4. The results of the analysis provide the basis for key decisions in the engineering of the SoS.

Figure 4. Key Elements of SoS Analysis [4] (Click image to enlarge)

In addition, the results of this analysis of the SoS provide the basis for developing the initial plans for the SoS engineering, in particular the following questions:

  • How will the systems engineering process be structured and implemented? What is the right pacing of SoS waves or development increments, how will the systems engineering team be organized, what are the key decision points and supporting processes, when will the technical reviews be conducted to inform these decisions? [SoS planning elements]
  • What is the long-term plan for incrementally moving toward meeting the capability objectives and satisfying the user needs? [SoS master plan, the SoS analog to a systems acquisition strategy]
  • What are the roles and responsibilities of the various SoS participants, including the constituent systems and their specific commitments in a development increment? [Agreements]

These questions are typically answered based on the initial analysis and reviewed and updated based on the results of successive waves. In general, keeping these plans very focused and lean has great advantages. There is a temptation to start with these systems engineering plans before beginning the analysis. Experience has shown that doing the systems engineering planning based on an understanding of what needs to be done to achieve the objectives has the benefit of being closely tied to the specific technical issues and hence can be more streamlined and focused on the particular needs of the SoS.

Develop SoS Architecture

Probably the most important technical element in the engineering of an SoS is SoS architecture, the persistent technical framework for the SoS and its evolution.

The architecture development bulds on the results of the SoS analysis. Developing the SoS architecture includes addressing the following questions:

  • What are the end-to-end SoS actions defined in the CONOPS?
  • How do current systems align with these activities?
  • What are the gaps in ability to meet SoS objectives?
  • What are alternative architectures that could improve SoS performance and other attributes, including SoS resilience in light of the inevitable changes in systems and the SoS environment that could disrupt SoS operations?
  • What are the trades among these factors, particularly given the costs and constraints to changing the current systems to support a new architecture?

The activities associated with each of these questions are illustrated in Figure 5. The results of the architecture development may lead to an improved understanding the SoS risks, the structure, organization, and pacing of the SoSE processes [SE planning elements], roles and responsibilities of participants [agreements], and the long-term plans for SoS evolution [master plan].

Figure 5. Key Elements of SoS Architecture Development [4] (Click image to enlarge)

The architecture [SoS architecture] provides a representation of the SoS technical framework that is shared across the SoS participants and is used to inform SoS development and evolution. The architecture includes systems, key SoS functions, relationships and dependencies, as well as end-to-end functionality, data flow, and communications protocols. It addresses possible changes in functionality, performance, or interfaces. There is typically some type of migration plan for updating the systems to implement the new architectures that identifies risks and mitigations.

In this step, the current architecture of the SoS is reviewed and alternative architectures are proposed and analyzed, to develop a recommended way ahead for the SoS. The drivers for changes may be improving performance or functional capability of the SoS, or they may be added flexibility or robustness to inevitable changes. The archiecture trades are driven by the specific circumstances of the SoS. The result of this step is a recommend architecture for the way ahead for the SoS.

Plan SoS Update

The SE for the SoS is responsible for planning for changes needed to evolve the SoS toward the user capability objectives, using the recommended SoS architecture as the technical framework for working with the constituents. This includes addressing the following questions:

  • What the SoS priorities? What are the key needs or gaps?
  • What are the options for addressing these gaps? An analysis of the current SoS architecture and supporting systems is conducted to identify options for making changes in the SoS to address the need.
  • What is the backlog of SoS changes from subsequent development increments (or waves)?
  • What is the plan for the next SoS upgrade cycle?

The major activities typically implemented in the Plan SoS Update step are shown in Figure 6. These activities are done in close cooperation with the constituent systems, since they will be implementing any changes and they know the technical and programmatic considerations for the various options as they affect their systems. Based on this collaborative analysis, a plan for the SoS update is formulated and coordinated.

Figure 6. Key Elements of Planning the SoS Update [4] (Click image to enlarge)

Implementation and test plans are created for each update, including an updated description of the SoS [SoS baselines]. Risks and mitigation are updated [SoS risks], as are agreements among the participants on their roles and responsibilities [agreements]. A schedule of key convergence events is created [integrated master schedule], and long-term plans may be updated [SoS master plans].

Implement SoS Update

The SoS is updated through changes in the constituents that are implemented and tested by the systems as part of their systems development and engineering processes. The SoS SE monitors the constituent system implementation progress and leads SoS integration and test, developing data on SoS performance and any unanticipated factors encountered. These activities are illustrated in Figure 7.

Figure 7. Implementation of SoS Update [4] (Click image to enlarge)

At the completion of the wave, information about the changes in the SoS and their impact on the plans is developed and used to feed the ongoing SoS analysis.

Continue SoS Analysis

Looking back at Figure 2, note that this is an ongoing process and that there are regular feedback loops among the life-cycle steps in what is essentially an agile, adaptive systems engineering process. This approach reflects the understanding that most systems of systems are subject to multiple independent changes that can affect their performance and evolution, and effective approaches to systems engineering in this type of environment require mechanisms to incrementally review, assess, and adapt to dynamics and uncertainties.

References and Resources

  1. The concept of Wave Planning was developed by David Dombkins; see Dombkins, D., 2007, Complex Project Management, North Charleston, SC: Booksurge Publishing.
  2. Honour, E., October 2013, "Designing for Adaptability and evolutioN in System of systems Engineering," presented at National Defense Industry Association Systems Engineering Conference, Arlington, Va., Accessed November 21, 2017.
  3. Dahmann J., G. Rebovich, J. Lane, R. Lowry, and K. Baldwin, 2011, An Implementers' View of Systems Engineering for Systems of Systems, Proceedings of the IEEE Systems Conference, Montreal, QC, Canada, April 4–7.
  4. Lane, J., et al., October 2010, "Key System of Systems Engineering Artifacts to Guide Engineering Activities," Presentation at NDIA Systems Engineering Conference, San Diego, Calif.


Download the SEG

MITRE's Systems Engineering Guide

Download for EPUB
Download for Amazon Kindle
Download a PDF

Contact the SEG Team