4.1.3. Systems Level Considerations

Topic

Previous and Next Page arrows

DEFENSE ACQUISITION GUIDEBOOK
Chapter 4 -- Systems Engineering

4.1.3. Systems Level Considerations

A system should not be acquired in isolation from other systems with which it associates in the operational environment. The Program Manager and Systems Engineer should understand how their system fills the needs for which it was designed and the enterprise context within which it operates. This includes understanding the diverse or dissimilar mix of other systems (hardware, software, and human) with which the system needs to exchange information. To that end, the Program Manager and Systems Engineer should define intersystem interfaces using a systems engineering (SE) document, i.e., the interface control document(s). In addition to interface control documents, the Program Manager and Systems Engineer, should also actively pursue Memoranda of Agreement or Memoranda of Understanding (MOA/MOU) with companion programs regarding interfaces, data exchanges, and advance notices of changes interdependencies and schedule (timing) that may affect either program. These agreements are a professional courtesy and a means of mitigating the inherent risk in planning to deliver a capability to an anticipated future technical baseline when there is uncertainty that the other programs are able to maintain schedule and have adequate resources to deploy the capabilities as planned.

SE is increasingly recognized as key to addressing the evolution of complex systems of systems. SE principles and tools can be used to apply systems thinking and engineering to the enterprise levels. An enterprise in this usage is understood to be the organization or cross-organizational entity supporting a defined business scope and mission, and includes the interdependent resources (people, organizations, and technology) to coordinate functions and share information in support of a common mission or set of related missions, (reference "Federal Enterprise Architecture Framework (FEAF)," September 1999).

This application of SE to address enterprises as complex systems builds on traditional SE activities and expands them to address enterprise challenges. The Systems Engineer can also assist with enterprise strategic planning and enterprise investment analysis. These two additional roles for Systems Engineers at the enterprise level are "shared with the organization’s senior line management, and tend to be more entrepreneurial, business-driven, and economic in nature in comparison to the more technical nature of classical systems engineering," (reference Carlock, P.G., and R.E. Fenton, "System-of-Systems (SoS) Enterprise Systems for Information-Intensive Organizations," Systems Engineering, Vol. 4, No. 4 (2001), pages 242-261).

Each DoD Service and Agency, and the Department itself, are examples of enterprises as systems. Such organizations have the challenge of integrating and evolving multiple portfolios of systems often with conflicting sets of objectives, constraints, stakeholders, and demands for resources.

The Systems Engineer should be cognizant of the enterprise context and constraints for the system in development and should factor these enterprise considerations into acquisition technical decisions from the outset. Mission areas, for example, can be viewed as cross-organizational enterprises and also provide critical context for system acquisition. Controlled interfaces with enabling systems in the SoS architecture drive system design. In some cases, enterprise considerations have been articulated as standards and certification requirements. In other cases, system decisions need to be made in the context of the larger Service portfolio of systems and mission area needs.

Most DoD capabilities today are provided by an aggregation of systems often referred to as systems of systems (SoS). A SoS is described as a set or arrangement of systems that results when independent and useful systems are integrated into a larger system that delivers unique capabilities. For complex SoS, the interdependencies that exist or are developed between and/or among the individual systems being integrated are significantly important and need to be tracked. Each SoS may consist of varying technologies that matured decades apart, designed for different purposes but now used to meet new objectives that may not have been defined at the time the systems were fielded.

Both individual systems and SoS conform to the accepted definition of a system in that each consists of parts, relationships, and a whole that is greater than the sum of its parts; however, not all systems are SoS. There are distinct differences between systems and SoS that should be taken into account in the application of SE to SoS (see Table 4.1.3.T1, adapted from DoD Systems Engineering Guide for Systems of Systems, page 11).

Table 4.1.3.T1. Comparing Systems and Systems of Systems

	System	System of Systems (SoS)
Management & Oversight
Stakeholder Involvement	Clearer set of stakeholders	Two levels of stakeholders with mixed, possibly competing interests. The two levels of stakeholders represent: 1. the independent and useful systems 2. the aggregation of the independent and useful systems
Governance	Aligned PM and funding. Higher levels of governance such as PEO and AT&L (internal and external governance)	Added levels of complexity due to management and funding for both SoS and systems; No single manager controls all constituent systems in the SoS
Operational Environment
Operational Focus	Designed and developed to meet operational objectives	Called upon to provide integrated capabilities using systems whose objectives have not been directly derived from current SoS system’s objectives
Implementation
Acquisition	Aligned to established acquisition process	Multiple system life cycles across acquisition programs, involving legacy systems, systems under development, new developments, and technology insertion; Stated capability objectives but may not have formal requirements
Test & Evaluation	Test and evaluation of the system is possible	Testing more challenging due to system’s asynchronous life cycles and given the complexity of all the moving parts
Engineering & Design Considerations
Boundaries & Interfaces	Focuses on boundaries and interfaces	Focus on identifying systems contributing to SoS objectives and enabling flow of data, control, and functionality across and/or between the SoS while balancing needs of systems. The boundaries and interfaces between systems become very important, since they serve as a conduit for data transfer
Performance & Behavior	Ability of the system to meet performance objectives	Performance across the SoS that satisfies SoS user capability needs while balancing needs of the systems

Application of Systems Engineering to Systems of Systems

Systems of systems (SoS) systems engineering (SE) deals with planning, analyzing, organizing, and integrating the capabilities of new and existing systems into a SoS capability greater than the sum of the capabilities of its constituent parts. Consistent with the DoD transformation vision and enabling net-centric operations, SoS may deliver capabilities by combining multiple collaborative and independent-yet-interacting systems. The mix of systems may include existing, partially developed, and yet-to-be-designed independent systems.

The DoD Guide to Systems Engineering for Systems of Systems addresses the application of SE to SoS. The guide defines four types of SoS (see Table 4.1.3.T2). When a SoS is recognized as a "directed," "acknowledged," or "collaborative" SoS, SE is applied across the constituent systems and is tailored to the characteristics and context of the SoS. Due to increased efforts to network systems to facilitate information sharing across the battle space, most DoD systems also may be viewed as components of a "virtual" SoS. For virtual SoS, DoD net-centric policies and strategies, such as, Department of Defense Net-Centric Services Strategy provide SE guidance regarding SoS contexts where there is an absence of explicit shared objectives or central management.

Table 4.1.3.T2. Four Types of Systems of Systems

Type	Definition
Directed	Directed SoS are those in which the SoS is engineered 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 centrally managed purpose.
Acknowledged	Acknowledged SoS have recognized objectives, a designated manager, and resources for the SoS; however, the constituent systems retain their independent ownership, objectives, funding, development, and sustainment approaches. Changes in the systems are based on cooperative agreements between the SoS and the system.
Collaborative	In collaborative SoS, the component systems interact more or less voluntarily to fulfill agreed-upon central purposes.
Virtual	Virtual SoS lacks a central management authority and a centrally agreed-upon purpose for the system of systems. Large-scale behavior emerges—and may be desirable—but this type of SoS relies upon relatively invisible, self-organizing mechanisms to maintain it.