172
Engineering Systems Integration
of components and their roles in the business process activities. Change a
function, add a function, change a business process, and the characteristics
of the components change. Changes in characteristics at the component level
change the interfaces or data or both. Moreover, the NIST report further stipulates there must be technical and stakeholder agreement on the (1) form, fit,
and function of information; (2) interpretation of data to be consistent with the
business processes; (3) rules signifying the business process enactments to be
represented fully by the components and their behaviors; and (4) combined
effects on integration of increased time, costs, and reduced performances.
Some of the notable recent failures in integration (reference the U.S. Army’s
Future Combat System, and other GAO referenced failures) suggest that technical integration may not encompass a sufficiency of integration theory to offer
a favorable guide for systems engineering. Consistent with the view that system integration is operative at both the system level as well as through its elements, the Systems Engineering Handbook published by the International
Council on Systems Engineering (INCOSE) states that integration is performed
on the system, its elements, and external systems (INCOSE 2008), and the
Institute for Telecommunications, U.S. Department of Commerce states that
integration is defined as the progressive linking of system components to
merge functional characteristics into an interoperable system.
Most effective Strategy for Integration
After investing in systems engineering and systems integration and improvements in the effectiveness of skills and efficiencies for work, arguably the
most effective strategy for planning to integrate a human-built system is first
to represent the totality of the system’s uses through its system-level functionalities, that is, in terms of a simulation model of what the system will do and
how the system will operate when completed. The fundamental difference
between the strategies of object-to-object versus object-to-system model integration is the inherent inaccuracies of piecewise continuous structures. The
effectiveness of object-to-object integration assumes that the objects can in
fact be integrated and further that the interfaces and data exchanges can be
identified and characterized before the onset of the integration work. Were this
assumption of piecewise continuity untrue, the individual tasks involved in
the integration effort would need to deal with an unknown set of interfaces,
undetermined data types and characteristics, and perhaps different protocols
for the data transfers. If the interfaces are known, the data types determined,
and the protocols specified, then the effectiveness of object-to-object integration simply rests with no changes being made during development. However,
very few (if any) development projects are completely, precisely, and accurately defined before planning for integration (typically begun in the first few
months of the development project); very few (if any) development projects
experience no changes once integration has begun; and very few (if any)
development projects find no errors with the objects or in their EMMI before
Engineering Systems Integration
of components and their roles in the business process activities. Change a
function, add a function, change a business process, and the characteristics
of the components change. Changes in characteristics at the component level
change the interfaces or data or both. Moreover, the NIST report further stipulates there must be technical and stakeholder agreement on the (1) form, fit,
and function of information; (2) interpretation of data to be consistent with the
business processes; (3) rules signifying the business process enactments to be
represented fully by the components and their behaviors; and (4) combined
effects on integration of increased time, costs, and reduced performances.
Some of the notable recent failures in integration (reference the U.S. Army’s
Future Combat System, and other GAO referenced failures) suggest that technical integration may not encompass a sufficiency of integration theory to offer
a favorable guide for systems engineering. Consistent with the view that system integration is operative at both the system level as well as through its elements, the Systems Engineering Handbook published by the International
Council on Systems Engineering (INCOSE) states that integration is performed
on the system, its elements, and external systems (INCOSE 2008), and the
Institute for Telecommunications, U.S. Department of Commerce states that
integration is defined as the progressive linking of system components to
merge functional characteristics into an interoperable system.
Most effective Strategy for Integration
After investing in systems engineering and systems integration and improvements in the effectiveness of skills and efficiencies for work, arguably the
most effective strategy for planning to integrate a human-built system is first
to represent the totality of the system’s uses through its system-level functionalities, that is, in terms of a simulation model of what the system will do and
how the system will operate when completed. The fundamental difference
between the strategies of object-to-object versus object-to-system model integration is the inherent inaccuracies of piecewise continuous structures. The
effectiveness of object-to-object integration assumes that the objects can in
fact be integrated and further that the interfaces and data exchanges can be
identified and characterized before the onset of the integration work. Were this
assumption of piecewise continuity untrue, the individual tasks involved in
the integration effort would need to deal with an unknown set of interfaces,
undetermined data types and characteristics, and perhaps different protocols
for the data transfers. If the interfaces are known, the data types determined,
and the protocols specified, then the effectiveness of object-to-object integration simply rests with no changes being made during development. However,
very few (if any) development projects are completely, precisely, and accurately defined before planning for integration (typically begun in the first few
months of the development project); very few (if any) development projects
experience no changes once integration has begun; and very few (if any)
development projects find no errors with the objects or in their EMMI before