219
Integration in Systems Engineering Context
many ways, (3) and the desired consequences of the product or service for
people, infrastructure, and environment need to be incorporated by design
and architecture. These three considerations are of equal importance to the
systems engineer.
The product or service is the focus for the development project and with
which responsibility rests for assuring no adverse consequence accrues to
users and other future stakeholders. The product or service perspective
concentrates on the lifecycle of product lines or service(s). Recognizing a
substantial investment has been made in infrastructure, the systems engineers are keenly aware of the mandates from people and respect for the
environment that embodies the mantra “do so, but do no more harm than
it takes to do so.” This real cost of doing something should not be greater
than the benefit of what is done. The accomplishment should be greater
than the effort it takes to achieve the accomplishment. The loss to achieve a
level of performance should be kept to a minimum. The systems engineer
thinks in lifecycle issues, the net action accomplished for the total
investment.
Giving preference to the perspective of stakeholders and the product or
service results in potential carelessness with regard to lifecycle stakeholders,
collective investments, and the environment. The needs of each of these concerns must be considered in the design and architecture to place the product
or service on a presumed no-net harm path, and the actual work and materials used becomes the means of carrying out the plan of no-net harm done.
When any one of the focuses (product or service, stakeholders, infrastructure, or environment) is given preference over the others, a lifecycle issue
needs to be analyzed and resolved before development begins. What distinguishes systems engineering is that of thinking in systems, enabling by
engineering, and integration by preference. Integration is broadly considered by systems engineers as the most important aspect of systems engineering. It is through integration that all thoughts come together and result in
ideas that are different from each of the thoughts, that products and services
emerge from objects and labor, and that all disciplines can combine to tackle
complexity.
Systems engineering remains rooted in the classical formulation of reductionist theory—that which supposes a hierarchical decomposition of the
highest, most general-level conceptualization downward through successively greater detail. It is not that the hierarchical schema is inherent to systems engineering or that it is even necessary. It is a comfortable approach to
the thinking of the practitioners—one that provides a good-enough reconnoitering of the relations between objects, their functions, and the behaviors
of the eventual users of the product or service.
The descriptive formulation of systems engineering casts a summative
perspective of what systems engineering is. That pervasive is often fostered
by back office conversations centering on wasted efforts to define problems
(when it is clear what needs to be solved), iterative thinking about what
Integration in Systems Engineering Context
many ways, (3) and the desired consequences of the product or service for
people, infrastructure, and environment need to be incorporated by design
and architecture. These three considerations are of equal importance to the
systems engineer.
The product or service is the focus for the development project and with
which responsibility rests for assuring no adverse consequence accrues to
users and other future stakeholders. The product or service perspective
concentrates on the lifecycle of product lines or service(s). Recognizing a
substantial investment has been made in infrastructure, the systems engineers are keenly aware of the mandates from people and respect for the
environment that embodies the mantra “do so, but do no more harm than
it takes to do so.” This real cost of doing something should not be greater
than the benefit of what is done. The accomplishment should be greater
than the effort it takes to achieve the accomplishment. The loss to achieve a
level of performance should be kept to a minimum. The systems engineer
thinks in lifecycle issues, the net action accomplished for the total
investment.
Giving preference to the perspective of stakeholders and the product or
service results in potential carelessness with regard to lifecycle stakeholders,
collective investments, and the environment. The needs of each of these concerns must be considered in the design and architecture to place the product
or service on a presumed no-net harm path, and the actual work and materials used becomes the means of carrying out the plan of no-net harm done.
When any one of the focuses (product or service, stakeholders, infrastructure, or environment) is given preference over the others, a lifecycle issue
needs to be analyzed and resolved before development begins. What distinguishes systems engineering is that of thinking in systems, enabling by
engineering, and integration by preference. Integration is broadly considered by systems engineers as the most important aspect of systems engineering. It is through integration that all thoughts come together and result in
ideas that are different from each of the thoughts, that products and services
emerge from objects and labor, and that all disciplines can combine to tackle
complexity.
Systems engineering remains rooted in the classical formulation of reductionist theory—that which supposes a hierarchical decomposition of the
highest, most general-level conceptualization downward through successively greater detail. It is not that the hierarchical schema is inherent to systems engineering or that it is even necessary. It is a comfortable approach to
the thinking of the practitioners—one that provides a good-enough reconnoitering of the relations between objects, their functions, and the behaviors
of the eventual users of the product or service.
The descriptive formulation of systems engineering casts a summative
perspective of what systems engineering is. That pervasive is often fostered
by back office conversations centering on wasted efforts to define problems
(when it is clear what needs to be solved), iterative thinking about what