168
Engineering Systems Integration
changed or modified* over the course and execution of the development
work. Systems engineering is held to a higher standard than just satisfying
the need for providing value through the constituent parts of the product or
service. Systems engineering is presupposed to be a redaction of engineering. This view was held by the formulators of systems engineering at Bell
Laboratories (Schlager 1956), reinforced by the widespread use by the U.S.
DoD beginning in the 1950s with the U.S. Air Force and into the late 1960s
with the first U.S. military standards for systems engineering. Even in the
near past (Stem et al. 2006) systems engineering has earned the entrusted
means of engineering and providing large, enigmatic systems. The problems
faced by systems engineering can involve incongruous technologies, components, and systems, each with various intricacies and confounding multidisciplinary problems. The mischievous whole exemplified by hundreds of
millions of interacting elements is not amenable to simple reductionist methods. Inductive and illative thinking is mandatory. The strategy of systems
integration is a second cousin to these discussions. Systems integrators are
faced with two problems: first, unraveling the domain parameters as indicated in the objective and subjective frames (objects and process), and second, once partitioned into tasks, these parameterized pieces of work enabled
by processes and focused on objects need to come together in an integrated
way to provide a network of reliably interacting elements. The elements are
the three parts of the subjective domain (cognitive, procedure, and model)
and the three parts of the objective domain (objects, functions, and behaviors). The nature of integration is relegated to instance of interactions for
objects and processes, humans and products, or humans and services.
Detailing the combined objective and subjective frames spells integration.
Integration is deliciously detailed—a method in which an insidious mistake
is made more distressing by its own consequence.
Differentiation implies power and change. Strategies of integration rely on
power—the ability to do what you have sufficient force to do. The result of
power is change or status quo. The detectability of change in the inherent
traits, attributes, and peculiarities (i.e., properties) of objects or processes is
determinable within the context of the classes and domains of integration.
That there are objective causalities, objective and subjective measures, metrics, and measurement frames determines that change or status quo can be
detected. That there is a sufficiency of power needs to be ascertained. Andy
Sage suggested a three-level perspective on applying systems engineering to
engineer systems (Sage and Armstrong 2000). Carrying forward with our
interpretation of integration through the mereology of processes and objects
is strongly suggestive that the drivers for change are judicious use of power.
In the social sciences, the requirement to separate the experimenter from the
* Changes and modification come from key stakeholders, including customers, users, and
project team. Changes are a natural and expected part of systems engineering. However,
changes are neither desirable nor acceptable for integration.
Engineering Systems Integration
changed or modified* over the course and execution of the development
work. Systems engineering is held to a higher standard than just satisfying
the need for providing value through the constituent parts of the product or
service. Systems engineering is presupposed to be a redaction of engineering. This view was held by the formulators of systems engineering at Bell
Laboratories (Schlager 1956), reinforced by the widespread use by the U.S.
DoD beginning in the 1950s with the U.S. Air Force and into the late 1960s
with the first U.S. military standards for systems engineering. Even in the
near past (Stem et al. 2006) systems engineering has earned the entrusted
means of engineering and providing large, enigmatic systems. The problems
faced by systems engineering can involve incongruous technologies, components, and systems, each with various intricacies and confounding multidisciplinary problems. The mischievous whole exemplified by hundreds of
millions of interacting elements is not amenable to simple reductionist methods. Inductive and illative thinking is mandatory. The strategy of systems
integration is a second cousin to these discussions. Systems integrators are
faced with two problems: first, unraveling the domain parameters as indicated in the objective and subjective frames (objects and process), and second, once partitioned into tasks, these parameterized pieces of work enabled
by processes and focused on objects need to come together in an integrated
way to provide a network of reliably interacting elements. The elements are
the three parts of the subjective domain (cognitive, procedure, and model)
and the three parts of the objective domain (objects, functions, and behaviors). The nature of integration is relegated to instance of interactions for
objects and processes, humans and products, or humans and services.
Detailing the combined objective and subjective frames spells integration.
Integration is deliciously detailed—a method in which an insidious mistake
is made more distressing by its own consequence.
Differentiation implies power and change. Strategies of integration rely on
power—the ability to do what you have sufficient force to do. The result of
power is change or status quo. The detectability of change in the inherent
traits, attributes, and peculiarities (i.e., properties) of objects or processes is
determinable within the context of the classes and domains of integration.
That there are objective causalities, objective and subjective measures, metrics, and measurement frames determines that change or status quo can be
detected. That there is a sufficiency of power needs to be ascertained. Andy
Sage suggested a three-level perspective on applying systems engineering to
engineer systems (Sage and Armstrong 2000). Carrying forward with our
interpretation of integration through the mereology of processes and objects
is strongly suggestive that the drivers for change are judicious use of power.
In the social sciences, the requirement to separate the experimenter from the
* Changes and modification come from key stakeholders, including customers, users, and
project team. Changes are a natural and expected part of systems engineering. However,
changes are neither desirable nor acceptable for integration.