3
Foundations in Systems Integration
Introduction
One could ask why the concept of integration has not been considered a subject requiring thorough examination of joining parts to make a whole, or
involving profound contemplation of the whole as constituent parts. The
process of joining things together in some manner that involves interfaces
and transfers of various types is perhaps the most widely talked about, least
understood subject in any discipline. Individuals not versed in systems engineering often seem unable to appreciate the befuddlements indicative of
performing systems integration, or more insidiously, system of systems integration. Systems engineers and systems integration engineers often find
integration vexing and problematic, but forge on with the work because it
appears tractable (especially given enough time and money). In general,
well-intentioned people know what they want to integrate and why. If the
technology is mature and in some form of use, then integration may seem
possible (buying into the platitudes that off-the-shelf works so why not use
it). A few of the torments of integration center on dealing with unreliably
performing technology that has been designed and architected into objects;
having rushed objects from iterative thinking that underpins development
into the processes of integration which benefit more from recursive thinking;
reducing budgets for integration tasks; and shortening schedules to delivery.
The usual desire for integration is for interoperability of objects and processes to achieve some effect in their intended operational environment.
Indeed, the typical guidance for integration planning offers such platitudes as “human factors considerations must be included in every solution”
and “do no harm.” The nuts and bolts of planning are in defining a sequence
of activities that will bring together the objects into objects, and then into
being as the system (object). Given the uncertainties of developing new
objects that will be integrated into a system, planning for integration would
seem to be problematic at the outset. Typically, the inputs to the integration
plan are the system design and architecture products, the objects that will be
developed, schedules and resources for the work tasks, and the plans for
various types and levels of testing. Systems integration planning is usually
103
Foundations in Systems Integration
Introduction
One could ask why the concept of integration has not been considered a subject requiring thorough examination of joining parts to make a whole, or
involving profound contemplation of the whole as constituent parts. The
process of joining things together in some manner that involves interfaces
and transfers of various types is perhaps the most widely talked about, least
understood subject in any discipline. Individuals not versed in systems engineering often seem unable to appreciate the befuddlements indicative of
performing systems integration, or more insidiously, system of systems integration. Systems engineers and systems integration engineers often find
integration vexing and problematic, but forge on with the work because it
appears tractable (especially given enough time and money). In general,
well-intentioned people know what they want to integrate and why. If the
technology is mature and in some form of use, then integration may seem
possible (buying into the platitudes that off-the-shelf works so why not use
it). A few of the torments of integration center on dealing with unreliably
performing technology that has been designed and architected into objects;
having rushed objects from iterative thinking that underpins development
into the processes of integration which benefit more from recursive thinking;
reducing budgets for integration tasks; and shortening schedules to delivery.
The usual desire for integration is for interoperability of objects and processes to achieve some effect in their intended operational environment.
Indeed, the typical guidance for integration planning offers such platitudes as “human factors considerations must be included in every solution”
and “do no harm.” The nuts and bolts of planning are in defining a sequence
of activities that will bring together the objects into objects, and then into
being as the system (object). Given the uncertainties of developing new
objects that will be integrated into a system, planning for integration would
seem to be problematic at the outset. Typically, the inputs to the integration
plan are the system design and architecture products, the objects that will be
developed, schedules and resources for the work tasks, and the plans for
various types and levels of testing. Systems integration planning is usually
103