System Integration - Enabling Capability Through Connectivity
Eugene A. Razzetti
In the past, I have written about program management and stressed the need for:
- Risk management and gap analysis
- Operator and/or warfighter participation in the program
- Meaningful feedback, follow-up and accountability
- Modeling and simulation, including tabletop exercises and/or wargames
This article adds “System Integration” to the discussion, as both a component and a byproduct of successful program management. System integration is not rocket science, but it is a challenge and, according to certain studies, up to 70 percent of system integration projects fail or fall short in some part. When program managers stay focused on system integration throughout the program, and not as an end-of-pipe activity, successful integration of subsystems into a finalized system is almost certain. The “System Integration Plan” will write, revise and continually improve itself.
Successful system integration employs the principles and practices of successful program management—you have to do all this stuff anyway.
System Integration and Program Management
System Integration is the process of bringing together the component subsystems into one system. It is an aggregation of subsystems cooperating so that the resultant system is able to deliver an overarching functionality or capability by ensuring that the subsystems function together as one system. In information technology, this is the process of linking together different computing systems and software applications physically or functionally, to act as a coordinated whole. An integrated system streamlines processes, reduces costs and increases efficiency.
System integration connects multiple separate components—often from different sources—to work as one. Some subsystems are old, some are new. Program managers usually find that putting the subsystems together as early as possible in the program’s development improves mission effectiveness and helps to ensure seamless connectivity, enabling commanders at the front and at the rear to better execute and assess strategic and tactical accomplishment.
Connectivity refers to a program’s or device’s ability to link with other programs or devices. For example, a program that can import data from a wide variety of sources and can export data in many different formats is said to have “good connectivity,” especially when connecting to or communicating with another computer or computer system. The finest subsystems are useless (or at least fall short) if they cannot effectively connect with each other and form the system. Connectivity in decision making means harnessing information from many information generators (or sensors) into one total picture—often called the Commander’s Dashboard.
System integration employs all the principles and practices of successful program management; there is virtually nothing that should be considered new, unique or over and above. Table 1 summarizes and compares the requirements of system integration with those of successful program management. The requirements are identical
Please note especially the inclusion of “warfighter involvement,” “technological yield,” and “connectivity.” These requirements, often neglected in a program’s early stages, are essential not only for managing the program but for ensuring that subsystems and components successfully address the mission and integrate into a viable end product (e.g., a weapons system, with all hardware, software, training simulators, and supply support).
Research and Development—Another Way to Look at It
Past usage of the familiar and perhaps archaic term “Research and Development” or “R&D” has often suggested its detachment, and/or inclusion as an end product at the beginning of the design. “Acceptance testing” (an equally archaic term) often is thought to be at end of the development pipeline. Taking these approaches invites programmatic disaster.
The alternative approach shown in Figure 1 depicts potential gain from a robust and ongoing integration/connectivity strategy in the R&D processes, where subsystems are measured continuously against system requirements. Acceptance testing is constant and actionable feedback is immediate. Quality testing throughout development replaces quantity testing at the end; and proactive configuration management replaces recalls and retrofits.
Subsystems are validated and tested. Test engineers, detecting any problems, can initiate corrective action. The subsystem again undergoes operational (acceptance) testing, to ensure that the subsystems come as close as possible to errorless performance.
Modeling and Simulation
I have written of the importance of modeling and simulation in wargames and/or tabletop exercises and as replacements for case studies. I have tried to stress two points:
- Modeling and simulation should take place throughout the program.
- Warfighters/operators should participate throughout the program.
In Table 1, we see that these points are just as necessary (if not more so) in system integration. Manufacturing and developmental process outcomes can be gamed—especially when dealing with the inevitable potential for reconfiguration and/or a change in operational requirements. Simulations can optimize projected human interactions, information collection, artificial intelligence, and data analyses. Modeling and simulation across all systems integration processes provide the timely feedback and alternative approaches for informed decision making. The greater the integration, the greater and more dynamic are the ability and effectiveness of the decisions.
With regard to warfighter/operator involvement, we need only remember that Department of Defense (DoD) programs, especially those involving our nation’s offensive and defensive weapons systems, leave the most compelling risks to in-theater operators, and not program managers. Warfighter/operators need to be involved in the system integration.
Personnel
System integration requires dedicated, focused, professionals with exceptional expertise. Excellent technology is not enough if the required integration expertise is not there to implement it. Organizations may struggle to find and retain employees with the required skill sets for system integration. Contractors may advertise having expertise even if it does not yet exist, hoping to pick it up on the fly. An external or “third-party” specialist/consultant may bring needed integration expertise to the table more expeditiously.
Technological “Yield”—Potential Into Performance
For our purposes, technological “yield” refers to how measurably successful the essential technologies are integrated into the overall product architecture, application and user environment. The yield, as described in performance metrics such as miles per hour, target acquisition range, or mean time between failures, is a measure of how close actual performance comes to theoretical performance. A high yield suggests a successful integration of the technology. That said, technological yield findings are not always immediate, accurate or predictive. Subsequent testing and re-testing may produce lower values, suggesting that the technology may not yet be mature and, therefore not ready for production and/or implementation.
System Integration Process
There is no such thing as a standard system integration. Every system uses different subsystems to achieve different goals. The System Integrator (or team) must understand all the current and predicted program requirements. Translating program requirements into needs, and continuously improving communication between program management and the system integration team, connect the visions of the designers with the program managers’ realities.
Figure 2 describes how the system integration process fits in the big picture of program management. Again, nothing in the process is beyond the requirements of effective program management.
The task of integrating legacy or already existing subsystems into new systems or capabilities can require much research and effort. Only in recent years have systems been deployed that can interconnect innovative and existing subsystems. However, many systems and subsystems were “stovepipe” designs with no thought about future connectivity. Depending on their number and size, connecting several independent systems and subsystems into one while ensuring uninterrupted connectivity will take time and meticulousness. Successful system integration in the private sector helps forward-thinking companies to grow and prosper by automating many business processes and providing accurate decision-making data throughout.
The longest and the most challenging phase of the program can be where the actual integration is performed. Based on a logical architecture design, a physical equivalent is developed. If all previous steps have been followed with a close attention to detail, a system integrator should perform system integration successfully and easily, without losing valuable time, funding or data.
The threat of cyber-attack will be with us always, and DoD programs must function in a cyber-secure environment—from preliminary design through the entire life cycle. Lives may depend on it.
Design, Architecture and Maintainability
System integrators/teams must design the architecture to create strong foundations and to minimize risk as much as possible, in order to ensure that multiple subsystems and components function as one. Only then will the system meet (or exceed) mission requirements. Blueprints of the integration components will help to visualize the process(es). The goal is enhanced efficiency and seamless data connectivity.
Program managers should consider having subsystems integrated by professional integrators, rather than buying “off-the-shelf” solutions implemented by unqualified contractors. If a system or subsystem is difficult to operate or deficient, the integrator should initiate corrective action immediately. If and when a mission evolves, the system must evolve with it. Also, there may be no need to acquire a new product, as it can be more beneficial to upgrade the system you already know and find easy to use.
System Security
DoD programs (now and forever) will depend on the most accurate and actionable information, securely collected, stored and displayed. DoD security systems must protect data, information and the knowledge acquired therefrom from theft, sabotage, accidents, misuse and ignorance. The greater that amount of data—the greater the security challenge. The threat of cyber-attack will be with us always, and DoD programs must function in a cyber-secure environment—from preliminary design through the entire life cycle. Lives may depend on it.
How is information networked? The Internet may seem an obvious answer, but it is increasingly vulnerable to denial of service, hacking and physical destruction of the key “hubs.” A dedicated military communication system is the default solution, although bandwidth allocation and management create additional challenges for program managers.
Organizational “Inertia” and Lack of Accountability
System integration always involves multiple players as well as multiple subsystems. Accountability for the success (or failure) of the integration becomes blurred very easily when integrating many different subsystems. There can be multiple stakeholders (e.g., vendors, users, system owners, etc.), none of them ultimately responsible for the entire system integration. Each may only handle or care at most about one piece of the integration and be unlikely to appreciate the big picture or have a sense of urgency for it. When something goes wrong, the situation turns almost immediately to finger pointing and blaming other parties instead of someone “owning” the integration. When a single party manages the system integration project, he or she is (often contractually) responsible and accountable for integration success, and there is no longer any ambiguity. Accountability replaces ambiguity.
Some decision makers elect to acquire new or off-the-shelf packages instead of integrating already existing subsystems. Contractors often procure only the components that they actually need at the moment or to solve an immediate problem. This way may be faster and cheaper in the beginning, and thus seem more profitable and efficient. But the practice can very quickly become counterproductive, as the new additions become obsolete or create interoperability problems down the road. As the program evolves, it may start using more and more independent, free-standing, tools, possibly resulting in productivity decline and inaccurate/inconsistent data analyses. The longer the project takes, the more significant this issue becomes. Records become confusing and incapable of audit. Funds are used faster or are prematurely exhausted. Problem correction is funded from other finding lines or kicked to the next fiscal year. Keeping the integration projects as short as possible can improve program success. Furthermore, an agile working methodology that can address changing requirements along the way and also after the project is essential for systems integration success.
The “good” news, remember, is that system integration is program management; and with DoD contracts, the program manager is in charge. He or she controls the funds, owns the integration and establishes subordinate responsibility and accountability accordingly. The challenge to program managers is the time-consuming and complicated nature of integrating various subsystems.
Problem-Solving and Continual Improvement
We cannot discuss day-in, day-out program management and system integration without discussing two indispensable “mindsets.” A problem-solving mindset accepts the fact that problems are inevitable but that any problem can be corrected—and, if not corrected entirely, in some way mitigated. “Don’t fix the blame, fix the problem” should be the reaction; appreciating that a problem, once identified, is half solved. International Quality Management Standards such as ISO 9001:2015 instruct that corrective actions should be realistic and measurable, and that follow-up must ensure that the corrective actions produced the desired results.
Closely related is the continual improvement mindset that reminds program managers that any system or process, however efficient, can always be made better. The program managers must always be on the lookout for opportunities to improve a system, process or situation. Outside auditors measure the continual improvement mindset in an organization by assessing:
- Adherence to policies and objectives
- Analysis of data and effectiveness or recurring reports
- Effectiveness of following up previous corrective and preventive actions
- Structured program reviews, with actionable findings, conclusions and recommendations
Summary
There are essentially no more stand-alone operations or weapons. DoD programs, especially those involving our nation’s offensive and defensive weapons systems, leave the most compelling risks and decisions to in-theater operators, not to stateside program managers or contractors. Connectivity in decision making means harnessing information from many information generators (or sensors) into one total picture.
Successful system integration and the need to streamline processes for more effective program management and warfighting is more important now than ever, due to the increasing advances in warfighting technology among major powers and the pernicious adventurism of a few thug nations.
Comprehensive program management creates, in its execution, successful system integration. Program managers need to stay focused on system integration throughout a program, and not as an end-of-pipe activity. Only then will integration of subsystems into a finalized system be possible.
Read the full issue of
Defense Acquisition magazine
RAZZETTI, a retired U.S. Navy captain, is a management consultant, auditor, military analyst, and frequent contributor to Defense Acquisition and Defense AT&L magazine. He is the author of five management books, including Fixes that Last–The Executive’s Guide to Fix It or Lose It Management.
The author can be reached at [email protected].
The views expressed in this article are those of the author alone and not the Department of Defense. Reproduction or reposting of articles from Defense Acquisition magazine should credit the authors and the magazine.
