25
Importance of Integration
DoD 5000.2-R to transform the required operational need into an integrated system design, but does not specify whether the degree of linkage between the system design and the concept of operations. As such, the acquirer presents the
designated systems engineering and integration contractor with toplevel requirements and a concept of operations that reasonably reflects the consensus view of
what is to be built. The specifics of the system design are left to the systems engineering development work to determine, explicate, or refine.
However, contrast this style of acquisition with one in which the top-level
requirements and a concept of operations are the starting points for systems
engineering development. The range of outcomes for the product or service
may vary considerably from that resulting from an upfront limitation on the
resultant system design. The trade spaces for the constraints of cost, schedule,
and functional performances, the interaction to further define the end product
or service, and the degree to which more creativity can cast new thoughts to
solve the problem of the customer(s) and uses is broader reaching. The overall
difference between greater or few limitations is perhaps a bit more time spent
on upfront design and architecture, but the development and integration may
be significantly less problematic.
The basis for this optimism for reducing costs for systems engineering development and integration work is that by adding more thinkers upfront deals directly
with one of the primary reasons (if not the primary reason) why systems engineering was initially conceived as the means to solving increasingly complex problems. There are two issues that premise this discussion: First, the system design
represents the consensus view of what the stakeholders need to solve their problem. Getting to the system design takes considerable analysis and thought.
Without due consideration by many, varied thinkers, the right objects that makeup the system (system components) will not be identified and the architecture
will not be optimized to provide what is needed. Second, “The first need for systems engineering was felt when it was discovered that satisfactory components
do not necessarily combine to produce a satisfactory system” (Schlager 1956).
The solution to the customer and user needs requires integrating the right
components in the right way. Integration requires a sound system design and a
sound architecture as a minimum to provide the requisite product or service.
Allowing systems engineers to assist in the upfront work of assessing the current
and future trends in capabilities (explicitly determining what the problems are
that need to be solved), determining the need for the system, analyzing the gaps
in future systems or system of systems, identifying the top-level requirements,
specifying the initial capabilities, developing the key performance parameters,
and posing a system of systems architecture that shows the fit of a future capability into the trend line of current, soon to be concurrently interoperable, systems.
References
Allen, L. Commission. 1990. The Hubble Space Telescope Optical Systems Failure Report.
National Aeronautics and Space Administration.
Importance of Integration
DoD 5000.2-R to transform the required operational need into an integrated system design, but does not specify whether the degree of linkage between the system design and the concept of operations. As such, the acquirer presents the
designated systems engineering and integration contractor with toplevel requirements and a concept of operations that reasonably reflects the consensus view of
what is to be built. The specifics of the system design are left to the systems engineering development work to determine, explicate, or refine.
However, contrast this style of acquisition with one in which the top-level
requirements and a concept of operations are the starting points for systems
engineering development. The range of outcomes for the product or service
may vary considerably from that resulting from an upfront limitation on the
resultant system design. The trade spaces for the constraints of cost, schedule,
and functional performances, the interaction to further define the end product
or service, and the degree to which more creativity can cast new thoughts to
solve the problem of the customer(s) and uses is broader reaching. The overall
difference between greater or few limitations is perhaps a bit more time spent
on upfront design and architecture, but the development and integration may
be significantly less problematic.
The basis for this optimism for reducing costs for systems engineering development and integration work is that by adding more thinkers upfront deals directly
with one of the primary reasons (if not the primary reason) why systems engineering was initially conceived as the means to solving increasingly complex problems. There are two issues that premise this discussion: First, the system design
represents the consensus view of what the stakeholders need to solve their problem. Getting to the system design takes considerable analysis and thought.
Without due consideration by many, varied thinkers, the right objects that makeup the system (system components) will not be identified and the architecture
will not be optimized to provide what is needed. Second, “The first need for systems engineering was felt when it was discovered that satisfactory components
do not necessarily combine to produce a satisfactory system” (Schlager 1956).
The solution to the customer and user needs requires integrating the right
components in the right way. Integration requires a sound system design and a
sound architecture as a minimum to provide the requisite product or service.
Allowing systems engineers to assist in the upfront work of assessing the current
and future trends in capabilities (explicitly determining what the problems are
that need to be solved), determining the need for the system, analyzing the gaps
in future systems or system of systems, identifying the top-level requirements,
specifying the initial capabilities, developing the key performance parameters,
and posing a system of systems architecture that shows the fit of a future capability into the trend line of current, soon to be concurrently interoperable, systems.
References
Allen, L. Commission. 1990. The Hubble Space Telescope Optical Systems Failure Report.
National Aeronautics and Space Administration.