4
Engineering Systems Integration
power of hindsight is often too critical of the progress from one stage to the
next. By the knowledge of the results of the project work or by ignorance of
what actually transpired, lessons taken from these cases can be extracted
and applied to similar, representative examples of current work studied.
After a bit of review and introspection, patterns of behavior or events may
develop that suggest a commonly occurring set of variables and outcomes.
At some point, a behavioral model might be constructed that represents a
more detailed examination of a portion of the lessons, grounded in a set of
perspectives, measurement theory, and the objective actions. We refer to
such a set as a case study. A more formal discussion of case studies, from the
point of view of what is misunderstood about case study research, is written
by Flyvbjerg (2006) wherein he points out, “Forget the conventional wisdom,
go ahead and do a case study.” There is valuable information to be gleaned
from case studies: they can be useful for formulating hypotheses, hypotheses
testing, theory construction, and developing general theories (Eisenhardt
1989). Yet, the ultimate learning comes from practice. Systems engineering
is a discipline of employing practices that have proven useful in various
situations. Learning to integrate, to prepare the engineered objects for integration (systems engineering), and to manage integration (systems integration management) are steeped in practice without much theory to guide
improvements. Knowing the limits of what one can do is just as important as
knowing what to do. Stated bluntly, following a set of practices (or best practices) neither guarantees nor implies your project will be better or as good as
those from the retinue of projects from which the practices were derived.
Rather, it is knowing how to satisfice the perfect product or service and know
how to deal with the constraints of development time and budget as well as
meeting the lifecycle costs that defines what the best practice should be.
Perfect products or services are difficult to come by—often unachievable due
to negotiations or compromises to cope with key stakeholders, sundry problems caused by applying inappropriate or inadequate skills to the engineering activities, and ineffectual management discipline or knowledge to do or
know what needs to be done. Regardless of the historical precedence, the
application of best practices, or the systems engineering and management
skills, products, and services (perfect or not so perfect) embody the key principles of systems integration. Examining these principles (that are evident in
one or more case studies) exposes the actions and circumstances that have
major influence on the outcomes of system integration. Perhaps the most one
should expect from a case study is to observe the aftermath of principles
being followed. A method founded on an appropriate set of principles provides managers, systems engineers, and engineers with a practical guide for
action and a set of heuristics that should be a stalwart guide.
When attempting to integrate two objects where one or a combination of
both objects requires an amount of rework that is more constrained by cost
or time than starting anew, the result is a failure to integrate. Failure to integrate objects may have several root causes. But integration failures can be
Engineering Systems Integration
power of hindsight is often too critical of the progress from one stage to the
next. By the knowledge of the results of the project work or by ignorance of
what actually transpired, lessons taken from these cases can be extracted
and applied to similar, representative examples of current work studied.
After a bit of review and introspection, patterns of behavior or events may
develop that suggest a commonly occurring set of variables and outcomes.
At some point, a behavioral model might be constructed that represents a
more detailed examination of a portion of the lessons, grounded in a set of
perspectives, measurement theory, and the objective actions. We refer to
such a set as a case study. A more formal discussion of case studies, from the
point of view of what is misunderstood about case study research, is written
by Flyvbjerg (2006) wherein he points out, “Forget the conventional wisdom,
go ahead and do a case study.” There is valuable information to be gleaned
from case studies: they can be useful for formulating hypotheses, hypotheses
testing, theory construction, and developing general theories (Eisenhardt
1989). Yet, the ultimate learning comes from practice. Systems engineering
is a discipline of employing practices that have proven useful in various
situations. Learning to integrate, to prepare the engineered objects for integration (systems engineering), and to manage integration (systems integration management) are steeped in practice without much theory to guide
improvements. Knowing the limits of what one can do is just as important as
knowing what to do. Stated bluntly, following a set of practices (or best practices) neither guarantees nor implies your project will be better or as good as
those from the retinue of projects from which the practices were derived.
Rather, it is knowing how to satisfice the perfect product or service and know
how to deal with the constraints of development time and budget as well as
meeting the lifecycle costs that defines what the best practice should be.
Perfect products or services are difficult to come by—often unachievable due
to negotiations or compromises to cope with key stakeholders, sundry problems caused by applying inappropriate or inadequate skills to the engineering activities, and ineffectual management discipline or knowledge to do or
know what needs to be done. Regardless of the historical precedence, the
application of best practices, or the systems engineering and management
skills, products, and services (perfect or not so perfect) embody the key principles of systems integration. Examining these principles (that are evident in
one or more case studies) exposes the actions and circumstances that have
major influence on the outcomes of system integration. Perhaps the most one
should expect from a case study is to observe the aftermath of principles
being followed. A method founded on an appropriate set of principles provides managers, systems engineers, and engineers with a practical guide for
action and a set of heuristics that should be a stalwart guide.
When attempting to integrate two objects where one or a combination of
both objects requires an amount of rework that is more constrained by cost
or time than starting anew, the result is a failure to integrate. Failure to integrate objects may have several root causes. But integration failures can be