Complexity of the Systems Integration

Sergey Tozik, Gordon Center for Systems Engineering, Technion http://www.gordon-se.technion.ac.il/ Summary
Systems Integration is one of the important stages of the life cycle of any man-made system.During this stage, realized instances of the system's components are combined to create a complete system. Despite

widespread recognition that during the Integration the discovery of the problems is most frequent, this phase in the lifecycle has not received much attention in comparison with other stages such as Requirement Elicitation or System Architecture. The research that does deal with the
Integration focuses primarily on the planning processes and optimization, or on case studies that describe the development of the integration facilities. This paper uses the information gathered during the meetings of Systems Integration Working Group organized by the Israeli chapter of INCOSE (INCOSE_IL) as well as several papers that are published on the subject to gain an insight into the peculiarities of the Systems Integration. As may be expected, companies and organizations use a variety of engineering and managerial techniques and approaches to perform integration during the projects and other activities. The mere existence of such variety points that there cannot be found "the winning method" of Systems Integration but rather that there is a "toolbox" of methods and techniques. The effectiveness and efficiency of application of these techniques are highly dependent on their suitability to both the nature of the products and projects of each organization and the culture prevailing in these organizations. Systems Integration is a complex process. This complexity emerges from the interdependencies between the components inside the system, between the components and their developers, and most of all between the multitude of people involved in the development and integration of the system, everyone with her own experience, training, engineering disciplines and the technologies. More than that, there is never-ending mutual adaptation of the evolving system, the supporting organization, the users and their organizational processes. The Integration happens on multiple levels of hierarchy. Essentially, three types of integration may be discerned - the Product Integration that focuses on the integration of the artificial elements of the system and of the system with other artificial systems, the Human Integration that is focused on the mutual adaptation of the system and its ultimate users and the Operational Integration that is focused on the incorporation of the system (and its users) into the fabric of the operational processes in the acquiring organization and beyond it. Research community offers many solutions for dealing with the complexity of the systems,and the processes of the development and integration. But this community focuses elsewhere and doesn't look too deep into the human side of the "integration business" and doing so leaves much room for new interesting research. Adaptability of people may certainly be the "missing ingredient" in the coping with the

complexities of the development projects especially during the integration, in the attempts to reduce the complexity of the project in its last stages and thus reduce costs, shorten development time and increase the likelihood that the system will succeed in the complex operational environment.

Introduction
Despite widespread recognition that during the Integration the discovery of the problems is most frequent, this phase in the lifecycle has not received much attention in comparison with other stages such as Requirement Elicitation or System Architecture. The research that does deal with the Integration focuses primarily on the planning processes and optimization, or on case studies that describe the development of the integration facilities. Deep interest in Systems Integration in the community of the practitioners led to the establishment of Systems Integration Working group by the Israeli chapter of INCOSE (INCOSE_IL) with the representation of various companies and organization in both commercial and government sector. As part of the Work Group activities the representatives of several organizations presented their Systems Integration processes and techniques, among them Rafael, the Israel Electric Company, ECI, Motorola, Phillips Healthcare, Biosense Webster, Orbotech, Israeli Air Force, HP and others. The presentations and discussions revealed a lot of information about how the Systems Integration process is actually performed in these organizations. This paper uses the information gathered during the meetings of Systems Integration Working Group organized by the Israeli chapter of INCOSE (INCOSE_IL) as well as relevant publications to gain an insight into the peculiarities of the Systems Integration and point out promising research topics.

Characteristics of the integration process

In one of the meetings, the Work Group endeavored to list activities that are relevant to the Systems Integration. As expected, in the center of the Integration stand engineering activities of preparing and performing the integration testing events - writing integration plans, establishing integration facilities, development of the tools including the tools for modeling and simulation, conducting the tests and writing the reports. In addition it became clear that the implementation of the integration process requires other activities as well that are as important to the success of the whole process. Organization of integration events requires considerable logistical support including acquisition, transportation and installation of the system's components and supporting equipment, configuration management of both integration laboratories and the interim configurations of the system, establishing an

infrastructure of communication between the participants and transportation of people between the different integration sites. Management of the integration process includes planning, measurement of the progress, preparation for design and managements reviews, organization of integration and test readiness reviews, establishing of the integration teams, management of these teams including encouragement and appreciation of the team members. The integration process is a resource-intensive process but not always perceived as such during project planning stages. Part of the responsibilities of the integration leader is to secure and manage the resources, including the preparation of budgets, justification of need for resources, fighting for preservation of the allocation of resources and also reporting on resource utilization. During the integration process there exist quite a few activities identified with the systems engineering including analysis of the changes in the needs and demands of stakeholders that take place during the project, systems analysis, and problems investigation, design of remedial actions and system's improvements and the management of their implementation. The integration process is characterized by the flow of information and knowledge among the project participants, sometimes the increased information flow during integration compensates for the inadequate information exchange and documentation at the earlier stages of the project. Accordingly, the integrators must manage the flow of knowledge and information within and without the project and to manage information flow to the various stakeholders, including the use of techniques borrowed from the public relations.

Variety of processes and approaches

As more members of the Work Group presented their integration processes in their companies, it became apparent that there is a very wide variety of integration processes used by different companies and there are even differences between the different divisions of the same company. In some companies (especially in the defense sector) there are highly structured processes and procedures to perform the integration that even serve as a "skeleton" for planning the entire project not just the integration stages. In other companies the integration processes were tailored separately for each project and in other companies the integration "just happened" in pure ad-hoc fashion. The variety of the integration processes was as large as the variety of systems engineering processes in particular and organizational cultures in general.

Overall consensus was reached that the process of integration starts early in the project (when there are at least two components to integrate) and finishes very late in the project (when the product are transferred to the customers and even far beyond the project end, during production and support). As the participants presented their technical approaches to design and execution of the integration, the wide variety emerged as well. The systems were integrated functionally, hierarchically, by user-visible features, by the leading engineering disciplines (software, physical, mechanical, electrical, electronic etc) or by user types. Although in most companies, the concept of internal and external is the element that defines the approach to integration (and expressed in formal interface specifications) some of the companies didn't emphasize interfaces but rather used terms like "fitting components to each other", without documenting specific pair wise interfaces but rather documenting the overall design that shows how the components "fit together". Diversity of approaches to integration also includes a variety of approaches to organizing the teams involved in the integration. Although the topic of organizing integration teams was not the focus of the of companies' presentations, but during the discussions it became clear that there is a range of options for teams structure starting with the organic integration teams, through task teams led by systems engineers, to the ad-hoc integration team consisting of representatives of various development teams without an official manager (integration was led by the representative from the team which has more responsibility for the success of the integration event). In the companies that emphasized the need for the professionalism in the integration by organizaing dedicated integration departments, these departments may be assigned additional responsibility for the customer support, field engineering or detailed design of the interfaces. On the one hand the above responsibilities are not usually identified with the systems integration and on the other hand this is a sign that there is a strong association between these areas and the systems integration. From the aforementioned findings one can assume that the quality, the effectiveness and the efficiency of the integration process do not depend on the choice of the universal best practices on the amalgam of the approaches and adapted to the type of products and organizational culture in the company. There may well be a "toolbox" of methods and approaches to choose from but not the "best-of-breed" comprehensive methodology.

Systems Integration as part of Risk Management

There is an inherent difference between the activities of System Integration and those of Systems Design. During the integration the physical artifacts are interconnected to form larger assemblies, whether in design one works primarily with information artifacts and abstractions. The interaction between realworld artifacts is always richer than what are predicted using abstract descriptions or models. During the integration the unexpected assembly-level properties and behaviors gradually emerge. These behaviors may still appear exhibited in the final configuration of the system or many disappear or change. The latter "false attributes" may further complicate the integration process but can't be avoided due to incompleteness of the integration configurations and the low fidelity of the representation of the operating environment. Gerrit Muller states in his (Muller 2007) that "The goal of integration is to reduce the project risk of being late or the risk of creating an ill performing system". He argues that the integration plays a major role in risk reduction because the integrators are focused on finding unforeseen problems and solve them as early as possible. There is no way to avoid integration challenges - in course of building any sufficiently complicated system there is always aomebody that has to assume responsibility for the proper functioning of the systems and for solving the problems during the assembly, installation, transition to use and the actual operation. Couper, Emes and Smith (Couper et al 2005) point out that when no one consciously accepts the responsibility for integration, the responsibility will by default be assigned to the end users or on the engineers that represent the users making them "by-default Systems Integrators". These "by-default Systems Integrators" will bear the risk that the system will be inadequate for the operational use either due to exhibition of unacceptable emergent properties, or due to change in user's needs, or due to low reliability. Most projects reach the stage of integration both with depleted resources and with a host of unsolved proplems .Since during the integration the actual physical configurations are assembled and activated for the first time, it's impossible to deny those problems and the need to solve them becomes more tangible for the development team, and what is more important, to the management and for the customers. According to the article (Sheard 2000) by Sarah A. Sheard the Systems Engineer has to perform the role she called "the Glue" - the role of active problem seeker and solver. She didn't use the term "Systems Integrator" in order to prevent the confusion with the "Lead Systems Integrator" definition used in the contracts.

She emphasized that the Systems Engineer in her "Glue" role has to be "proactive troubleshooter, looking for the problems and arranging to prevent them". She emphasizes that the designers of the subsystems are focused on making "their subsystems do what they are supposed to do, while the systems integrator has to focus on the interfaces and the interrelationships between the subsystems, looking for the mutual interference.

Three levels of system integration complexity

Systems Integration is a complex process. It is not apparent when one considers only the integration between artificial components of the system, so I would like to distinguish between three levels of Systems Integration - Artifact or Product Integration, System Integration and Operational Integration. In the course of the Artifact Integration the artificial components of the system is brought together to form partial configurations, the interfaces are mated and the configurations are stimulated to elecitate responses. The actual responses are judged against the expected ones documented as system's requirements. Artifact Integration is probably what most engineers imagine when they think about systems integration. For most purposes the Systems Integration and the Artefact Integration are considered synonymous. Most systems cannot function by themselves without the interaction with humans. In most cases, the operators or users are considered a part of the system's environment integration with the machines through human-machine interfaces that are treated as external. On the other hand in order to put the machines to use, the users and the machines has to adapt to each other. This mutual adaptation is the second level of the Systems Integration - the Human-Machine Integration. Humans are not components that may be produced according to specifications (even when one talks about training) and therefore free to change their behavior depending on personal preferences, accumulated experience in operating similar systems and a gradual adaptation to the new system they work with. People are complex creatures and their integration with the artificial components of the system raises the level of the complexity that are not considered during the Artifact Integration. Still another level of integration increases the complexity even more - the Operational Integration. During the Operational Integration the artificial systems and its users are integrated into the their organization's business or operational processes and into the "enterprise ecosystem". Operational Integration is seldom identified as Systems Integration but those that are involved in putting the systems into operational use may testify that this process has many characteristics of integration. In the light of the above one could consider the Operational Integration as the third and the most complex level of Systems Integration. 6

When looking at the integration process in the various organizations it can be seen that the organizations that represent the ultimate users focus more on Operational Integration and the companies that are suppliers of systems focus more on Artifacts Integration. The Human-Machine Integration is frequently under-emphasized and is allocated to be a part of the training. There are also companies that create a partnership with clients and take responsibility for all three levels of integration, bridging the gaps between them. It's interesting thet the companies involved in all three levels of integration have more influence on customers' requirements specification and thus have more control of the costs and profits.

The human side of the systemic integration

Much of the complexity in the integration process is due to interactions between people that participate in this process. According to the opinion of the Working Group participants the Systems Integration is characterized by intense social dynamics, that emerges from the encounters (sometimes for the first time) between the representatives of the different development teams thas has worked fairly independently on the system components right until the start of the integration. Despite the importance of human aspect to the success of the integration process it is not getting much attention in the publications or discourse between the practitioners who rather prefer to focus on the engineering and managerial side of their work. One can find references to the human aspect of the integration edge in the papers that deal with other aspects of the integration, such as the article by Scott A. Hyer (Hyer, 1997) that writes:

"When defining integration, the human side must also be considered. The development of any complex system involves many specialists and at least a few coordinators (managers and systems engineers) ... The activity's principle drivers are communication among the development team members and advance planning ... The only way to achieve this is through effective communication which comes from strong leadership and coordination ... Thus, at a very basic level, integration can be viewed from at least two perspectives: (1) as a technical challenge to system designers and (2) as a team coordination activity to managers. It must be a distributed effort which influences every project team member but, at the same time, remains centrally monitored and controlled. Simply stated, this is the challenge "
Not only communication and cooperation between the people is important to the success of integration, but also the ways of each person that participates in the process. In his article (Ring 2007) on the subject of "intelligent enterprises" Jack Ring states that the need for "interpersonal integration derives from the inherent limitations of the human mind:

"... People are the key ingredient, A minimum of two are required because the single brain cannot discriminate illusion from reality. Each person in or associated with the enterprise has a mental model of a) purpose and intended outcomes, b) what behaviors are and are not acceptable and c) ways their enterprise can pursue purpose. In the intelligent enterprise, these mental models are coherent. In the intelligent enterprise with a high mode of intelligence, the mental models reinforce and amplify one another. Likewise, each person has a sufficient level of enthusiasm to help one another overcome fear, ideally transforming that energy into more enthusiasm thus innovation. " Summary
Systems Integration is a complex process. Complexity of the integration process is greater than that of the Systems Design of the development of system components and that for a number of reasons: when implemented, the components and their interactions are more complex than any description or specification, the systems are used by people that adapt to the systems they operate, the changes in the operational processes that the use of the new systems triggers. The complexity of the integration process makes it a major source of risks in projects, with significant impact on the schedule, costs and performance of the systems. Research community offers many solutions for dealing with the complexity of the systems, the development and integration processes. On the other hand this community does not focus on the impact of the human side of the integration on its success and thus leaves much room for new research on this topic. Adaptability of people may certainly be the "missing ingredient" in the coping with the complexities of the development projects especially during the integration, in the attempts to reduce the complexity of the project in its last stages and thus reduce costs, shorten time and increase the likelihood that the system will succeed in the complex operational environment. Control of complexity may be based on regulation of diversity by implementation of standards and procedures or by giving "free rein" to the creative integration teams, by regulation of adaptation by training of the users and the preparation of the business environment to the absorption of new systems and by regulation of interdependence by controlling the flow of information and knowledge between the participants by means of facilitating or even prevention or disruption of communication.

Sources:

Cowper, D., Emes, M. and Smith, A, "... is en in Heaven or in hell is en That Illusive Systems Integrator - Who's Looking After Your Systems Integration", INCOSE Publication Database (
Https://www.incose.org/ipub/ ), 2005

Hyer, Scott, A, "An Effective Approach To System Integration: A Comprehensive Checklist", INCOSE Publication Database, 1997 Muller, Gerrit, "Coping with System Integration Challenges in Large Complex Environment", INCOSE Publication Database), 2007 Ring, Jack, "About Intelligent Enterprises: A Collection of Knowledge Claims", INCOSE Technical Document, INCOSE-TD-2007-001-01, 2007 Sheard, Sarah A., "Twelve Systems Engineering Roles", INCOSE Publication Database, 1996