230
Engineering Systems Integration
unreliable demonstrations of functionalities. For software systems that are
considered very large, the lifecycle cost of the system is nearly equal to the
combined integration, rework, and maintenance expenditures. These are
estimated to be greater than 90% of the total cost of ownership (Jones 1994;
Donaldson and Siegel 1997). Regardless of the size of the project, a significant portion of the systems engineering costs and the lifecycle costs are
wrapped up in integration work.
Systems engineers promote structure for processes, functions, and physical domains, and as such, integration is formally inculcated into systems
engineering processes. The nature of integration changes over the lifecycle
of the product, beginning with the bringing together of ideas to form a concept, moving through development object by object: by aggregating parts
into units, units into components, into subassemblies, assemblies, and subsystems, then into operations with other systems, and finally eventual disposal. Each stage of the lifecycle brings about integration.
Of importance to the systems engineer is that domain-specific knowledge
needs to be integrated with systems thinking (Troncale 1977). Both domain
knowledge (e.g., engineering) and systems reasoning are essential to establishing a means from which to appreciate systems engineering processes, as
these processes are reflective of both. Yet, thinking in systems is not found
naturally in domain knowledge. The specifics of the domain knowledge can
be all consuming without having to consider issues that seem to be beyond
the immediacy of dealing with a particular issue. However, it is sometimes
exactly those issues that seem to be beyond the defined boundary of the
problem that become problematic over the lifecycle of the new product or
service. It is not enough to just design and build a product or service. The
consequences of the product or service must be considered and incorporated
into the systems engineer’s work.
No human-built product or service is without interactions with another
object. Many products and services do not have a great number of interactions with other objects and thereby lend themselves well to some degree of
insularity. The boundaries of these insular objects are not complicated with
interactions from other objects, and if their interactions are not integrative
with other objects, their independence is maintained. Insular products and
services do not face the encumbrances and difficulties of large-scale or otherwise complex systems whose interactions may have grievous and deleterious
effects on systems that impact on our survival or goodwill. Systems engineering and its equivalent thinking* in other disciplines and fields are well
equipped to deal with boundaries and interactions. It is the abstraction of
thinking across domains that distinguishes the systems engineer from the
engineer or domain specialist; the systems biologist who manages to unravel
seemingly disparate processes in living systems by enigmatic patterns, the
* That of bringing about the conceptualization and actualization of structures of thought,
equipment, or notions.
Engineering Systems Integration
unreliable demonstrations of functionalities. For software systems that are
considered very large, the lifecycle cost of the system is nearly equal to the
combined integration, rework, and maintenance expenditures. These are
estimated to be greater than 90% of the total cost of ownership (Jones 1994;
Donaldson and Siegel 1997). Regardless of the size of the project, a significant portion of the systems engineering costs and the lifecycle costs are
wrapped up in integration work.
Systems engineers promote structure for processes, functions, and physical domains, and as such, integration is formally inculcated into systems
engineering processes. The nature of integration changes over the lifecycle
of the product, beginning with the bringing together of ideas to form a concept, moving through development object by object: by aggregating parts
into units, units into components, into subassemblies, assemblies, and subsystems, then into operations with other systems, and finally eventual disposal. Each stage of the lifecycle brings about integration.
Of importance to the systems engineer is that domain-specific knowledge
needs to be integrated with systems thinking (Troncale 1977). Both domain
knowledge (e.g., engineering) and systems reasoning are essential to establishing a means from which to appreciate systems engineering processes, as
these processes are reflective of both. Yet, thinking in systems is not found
naturally in domain knowledge. The specifics of the domain knowledge can
be all consuming without having to consider issues that seem to be beyond
the immediacy of dealing with a particular issue. However, it is sometimes
exactly those issues that seem to be beyond the defined boundary of the
problem that become problematic over the lifecycle of the new product or
service. It is not enough to just design and build a product or service. The
consequences of the product or service must be considered and incorporated
into the systems engineer’s work.
No human-built product or service is without interactions with another
object. Many products and services do not have a great number of interactions with other objects and thereby lend themselves well to some degree of
insularity. The boundaries of these insular objects are not complicated with
interactions from other objects, and if their interactions are not integrative
with other objects, their independence is maintained. Insular products and
services do not face the encumbrances and difficulties of large-scale or otherwise complex systems whose interactions may have grievous and deleterious
effects on systems that impact on our survival or goodwill. Systems engineering and its equivalent thinking* in other disciplines and fields are well
equipped to deal with boundaries and interactions. It is the abstraction of
thinking across domains that distinguishes the systems engineer from the
engineer or domain specialist; the systems biologist who manages to unravel
seemingly disparate processes in living systems by enigmatic patterns, the
* That of bringing about the conceptualization and actualization of structures of thought,
equipment, or notions.