288
Engineering Systems Integration
For ease of integration, the goal of granularity is to partition objects so that
each is composed of simple, independent groupings (Stevens et al. 1974).
However, the initial emphasis needs to be placed on the design of the objects
(i.e., a system that is being built from scratch), while second best is to orchestrate the design through interoperability of objects that have strong similarities across systems (i.e., a system of systems). Managing the interoperability
for integration requires clear partitioning in objects that can be considered
both as a whole (resultant output is reflective of a single unit of functional
operation) and as a part (required input is reflective of a single unit of functional operation). The object’s roles of a whole and a part are focused on the
aggregate performance of a set of mechanisms that enable a single function.
These roles can be represented in a hierarchical view with the subfunctions
aggregating into a function (e.g., Figure 6.1). To simplify integration, to provide
the requisite interoperability, and to achieve lowest possible expenditures of
labor necessary to realize the deliverable product or service, engineering
efforts need to focus on (1) simple, independent objects, (2) a minimum number of interfaces, (3) a minimum number of connections across the interfaces,
and (4) achieving the set of object behaviors that are required. Managing the
integration efforts needs to focus on this engineering thinking in addition to
the systems engineering thinking that is associated with recursion. The two
challenges of managing integration are to first, recognize and manage to
achieve the easiest path to integration and second, to provide the necessary
resources and leadership to stay on that path.
Abstraction
A close second, and similar, abstraction to a higher level than is necessary
may mask the detail needed for a mechanism to be effective in transforming
input EMMI into an output. At a higher level of abstraction, the existence of
lower-level details may be acknowledged, and if they are, then an additional
exchange of EMMI will be necessary to extract what is necessary for the
mechanism to complete its transformation. If the lower-level details are not
acknowledged, not known, or obscured, then several additional exchanges
of EMMI may be needed. In both these cases, granularity and abstraction
interfere with the efficient transformation needed to present the requisite
functions. Here, abstractions are referred to constructions of varying degrees
of details shown “. . . by taking an exemplary case or instance and removing
detail” (Machamer et al. 2000). Abstraction is the result of redefining a previously constructed schema into a new set of schemas—by extracting common
features from specific instances, merging, and replacing with another that
has less detail, but yet embodies the general notion of what is missing along
with what remains.
Engineering Systems Integration
For ease of integration, the goal of granularity is to partition objects so that
each is composed of simple, independent groupings (Stevens et al. 1974).
However, the initial emphasis needs to be placed on the design of the objects
(i.e., a system that is being built from scratch), while second best is to orchestrate the design through interoperability of objects that have strong similarities across systems (i.e., a system of systems). Managing the interoperability
for integration requires clear partitioning in objects that can be considered
both as a whole (resultant output is reflective of a single unit of functional
operation) and as a part (required input is reflective of a single unit of functional operation). The object’s roles of a whole and a part are focused on the
aggregate performance of a set of mechanisms that enable a single function.
These roles can be represented in a hierarchical view with the subfunctions
aggregating into a function (e.g., Figure 6.1). To simplify integration, to provide
the requisite interoperability, and to achieve lowest possible expenditures of
labor necessary to realize the deliverable product or service, engineering
efforts need to focus on (1) simple, independent objects, (2) a minimum number of interfaces, (3) a minimum number of connections across the interfaces,
and (4) achieving the set of object behaviors that are required. Managing the
integration efforts needs to focus on this engineering thinking in addition to
the systems engineering thinking that is associated with recursion. The two
challenges of managing integration are to first, recognize and manage to
achieve the easiest path to integration and second, to provide the necessary
resources and leadership to stay on that path.
Abstraction
A close second, and similar, abstraction to a higher level than is necessary
may mask the detail needed for a mechanism to be effective in transforming
input EMMI into an output. At a higher level of abstraction, the existence of
lower-level details may be acknowledged, and if they are, then an additional
exchange of EMMI will be necessary to extract what is necessary for the
mechanism to complete its transformation. If the lower-level details are not
acknowledged, not known, or obscured, then several additional exchanges
of EMMI may be needed. In both these cases, granularity and abstraction
interfere with the efficient transformation needed to present the requisite
functions. Here, abstractions are referred to constructions of varying degrees
of details shown “. . . by taking an exemplary case or instance and removing
detail” (Machamer et al. 2000). Abstraction is the result of redefining a previously constructed schema into a new set of schemas—by extracting common
features from specific instances, merging, and replacing with another that
has less detail, but yet embodies the general notion of what is missing along
with what remains.