222
Engineering Systems Integration
While these problems are addressable in multiple ways (such as training,
following best practices (as defined in this book), and education), the issues
and compounding factors may reflect a more general problem that potentially
overwhelms the ability of the systems engineer to deal with the many conflicting interests. In keeping with the reasoning of the U.S. Government
Accountability Office (GAO 2009a), established dogma has failed to achieve
desired results because many government acquisitions “lack early and disciplined systems engineering analysis” and allow “new requirements to be
added well into the acquisition cycle.” These two issues are indicative of a
mind-set by the acquirers that there are more important factors than simply
following what is known to work reasonably well. Systems engineering is
coopted by the dictates of pushing forward with little regard for neither engineering logic nor systems engineering reason. Whereas it is the purview of
systems engineering to (1) translate needs into requirements, (2) build a solution that is responsive to those requirements, and (3) deliver a product or
service that solves the problem, systems engineering cannot solve problems
associated with human frailties. Most specifically, it is the determinable trait
of inflexibility in those that make demands on systems engineering and quite
explicitly engineering systems integration to provide more system functionality, performance, and quality for less (time and money). When viable system
solutions exists that meet most of the stakeholder needs, or all of the requirements, the quest for new technologies in a “would be production or manufacturing environment” is wishful thinking. Wishful is making a decision when
you know better; wanting is making a decision when you do not know any
better. Need is quite a different matter. Such wishful thinking should not be
regarded as statistical reasoning and incorporated into a risk analysis and
shown as a risk item. Regardless of the acquisition mentality that precedes
buying a product or service, if the intended outcome is a production or manufacturing environment, pushing immature technologies into a development
environment should most likely not be thought of as risky from the outset,
but rather as problematic from the outset, bordering deterministically, as a
failure. However, it is pure folly to insert those same immature technologies
into objects that are integrated when neither the existence of functionality
nor the reliability of performance has been reasonably demonstrated during
development. Integration cannot shed new insights that were not previously
known by the developers. Neither does the integration process even pretend
to show developers their possible options to rectify problems. Integration is
not the “work around” or “rescuer” of the development problems that will
somewhat mask or ameliorate the conditions under which those problems
persist. Pushing ahead and integrating with the hope that the new technology will emerge in an acceptable implementation is wasteful of resources
(time, talent, money, facilities, and equipment).
But there are mitigating factors that underlie the wishful thinking.
Sometimes, there is thought to be no choice. For the entrepreneur, there is no
choice. To do what others can do is failure before start-up. No investor will