313
Systems Integration Management
what needs to be fixed), and so on through the components, subassemblies,
assemblies, and subsystems. The recurring pattern is one of looking to the
objects at hand to assure they work together, knowing that if they do not
work together, then nothing will work with them later. In a recursive environment, the dominant theme would be to determine a pattern that looks to
the future objects and how those objects will work together given the lessons
learned from the existing objects. Specifically, the functional analysis in the
systems engineering process model needs to be redone to accommodate the
lessons learned from the integration of the first few objects. For example, if
two objects are integrated successfully, they represent a function or set of
functions that were called out in the functional analysis step performed as
part of the systems engineering process model. Were it to be the case that all
such functions were found to result from the integration work, there would
be no problem or concern. But that is rarely, if ever, the case for systems of a
complex nature. Instead, the functions that were agreed to during the functional analysis step were a “best match” with the physical entity, but not an
entirely best match. The iterative nature of systems engineering may not
have surfaced all of the functions and made the appropriate physical allocations. The means of finding these problems is usually left to modeling, simulation, and testing (first at the unit level, and then at the component level).
The iterative nature of systems engineering results in an integrated system
some percentage of the time. The recursive nature of systems integration
should result in an integrated system a higher percentage of the time based
on (1) having refined the set of functions from the functional analysis stage
during the integration work (thereby better preparing and configuring the
object for integration); (2) extrapolating the patterns discernable in the early
systems integration work and apply those lessons learned to subsequent
objects (thereby applying the lessons learned to subsequent integration
activities); and (3) focusing the integration effort on the end-to-end system
functionalities that are demonstrable by the concatenation of subfunctions.
The extensive use for recursive systems integration is for complex systems
and system of systems integration. The failures of iterative systems integration are revealed most notably with the most complex of systems or system
of systems. The systems integration process model fits into the systems
engineering process models in the same fashion as integration is currently
conceived and enacted. For example, the number of U.S. Department of
Defense programs that are major and complex (GAO 2011) total 98 with a
total planned investment of $1.68 trillion.* One of those programs, the U.S.
Army Future Combat System, was terminated. As with many efforts, the
major difficulties seem to be recorded during integration, but in this case, the
difficulties were determinable in the system architecture, the integration of
new systems with legacy systems, and the degree of interoperability that
* The GAO reports $174 billion for 13 programs were removed from the portfolio of major
defense acquisitions while 15 programs (est. $77 billion) were added (GAO 2011).
Systems Integration Management
what needs to be fixed), and so on through the components, subassemblies,
assemblies, and subsystems. The recurring pattern is one of looking to the
objects at hand to assure they work together, knowing that if they do not
work together, then nothing will work with them later. In a recursive environment, the dominant theme would be to determine a pattern that looks to
the future objects and how those objects will work together given the lessons
learned from the existing objects. Specifically, the functional analysis in the
systems engineering process model needs to be redone to accommodate the
lessons learned from the integration of the first few objects. For example, if
two objects are integrated successfully, they represent a function or set of
functions that were called out in the functional analysis step performed as
part of the systems engineering process model. Were it to be the case that all
such functions were found to result from the integration work, there would
be no problem or concern. But that is rarely, if ever, the case for systems of a
complex nature. Instead, the functions that were agreed to during the functional analysis step were a “best match” with the physical entity, but not an
entirely best match. The iterative nature of systems engineering may not
have surfaced all of the functions and made the appropriate physical allocations. The means of finding these problems is usually left to modeling, simulation, and testing (first at the unit level, and then at the component level).
The iterative nature of systems engineering results in an integrated system
some percentage of the time. The recursive nature of systems integration
should result in an integrated system a higher percentage of the time based
on (1) having refined the set of functions from the functional analysis stage
during the integration work (thereby better preparing and configuring the
object for integration); (2) extrapolating the patterns discernable in the early
systems integration work and apply those lessons learned to subsequent
objects (thereby applying the lessons learned to subsequent integration
activities); and (3) focusing the integration effort on the end-to-end system
functionalities that are demonstrable by the concatenation of subfunctions.
The extensive use for recursive systems integration is for complex systems
and system of systems integration. The failures of iterative systems integration are revealed most notably with the most complex of systems or system
of systems. The systems integration process model fits into the systems
engineering process models in the same fashion as integration is currently
conceived and enacted. For example, the number of U.S. Department of
Defense programs that are major and complex (GAO 2011) total 98 with a
total planned investment of $1.68 trillion.* One of those programs, the U.S.
Army Future Combat System, was terminated. As with many efforts, the
major difficulties seem to be recorded during integration, but in this case, the
difficulties were determinable in the system architecture, the integration of
new systems with legacy systems, and the degree of interoperability that
* The GAO reports $174 billion for 13 programs were removed from the portfolio of major
defense acquisitions while 15 programs (est. $77 billion) were added (GAO 2011).