4.1.3. Systems Level Considerations

DEFENSE ACQUISITION GUIDEBOOK
Chapter 4 -- Systems Engineering

4.1.3. Systems Level Considerations

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

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

Top of page