Challenges of integrating NASAs space communication networks

The transition to new technology, innovative ideas, and resistance to change is something that every industry experiences. Recent examples of this shift are changing to using robots in the assembly line construction of automobiles or the increasing use of robotics for medical procedures. Most often this is done with cost-reduction in mind, though ease of use for the customer is also a driver. All industries experience the push to increase efficiency of their systems; National Aeronautics and Space Administration (NASA) and the commercial space industry are no different. NASA space communication services are provided by three separately designed, developed, maintained, and operated communications networks known as the Deep Space Network (DSN), Near Earth Network (NEN) and Space Network (SN). The Space Communications and Navigation (SCaN) Program is pursuing integration of these networks and has performed a variety of architecture trade studies to determine what integration options would be the most effective in achieving a unified user mission support organization, and increase the use of common operational equipment and processes. The integration of multiple, legacy organizations and existing systems has challenges ranging from technical to cultural. The existing networks are the progeny of the very first communication and tracking capabilities implemented by NASA and the Jet Propulsion Laboratory (JPL) more than 50 years ago and have been customized to the needs of their respective user mission base. The technical challenges to integrating the networks are many, though not impossible to overcome. The three distinct networks provide the same types of services, with customizable data rates, bandwidth, frequencies, and so forth. The differences across the networks have occurred in effort to satisfy their user missions' needs. Each new requirement has made the networks more unique and harder to integrate. The cultural challenges, however, have proven to be a significant obstacle for integration. Over the past few decades of use, user missions and network personnel alike have grown accustomed to the processes by which services are provided by the NASA communications and navigation networks. The culture established by each network has created several challenges that need to be overcome in order to effectively integrate the networks. As with any change, there has been resistance, an apprehension to explore automation of existing processes, and a working environment that attempts to indirectly influence change without mandating compliance. Overcoming technical and cultural challenges is essential to successfully integrating the networks and although the challenges are numerous, the integration of the networks promises a more efficient space communications network for NASA and its customers, as well as potential long-term cost savings to the agency.This paper, Challenges of Integrating NASA Legacy Communications Networks, will provide a brief overview of the current NASA space communications networks as well as the an overview of the process implemented while performing the SCaN Trade Studies and an introduction to the requirements driving integration of the SCaN Networks. This paper will describe in detail the challenges experienced, both technical and cultural, while working with NASA space communications network-specific personnel. The paper will also cover lessons learned during the performance of architecture trade studies and provide recommendations for ways to improve the process.

The SN consists of a constellation of geosynchronous relays (Tracking and Data Relay Satellites (TDRS)) and associated ground systems [1]. Mission supported range in location from earth based to geosynchronous orbits, including suborbital missions. The integration of the networks may result in more use of the TDRS satellites by the user mission communities of the other networks as well. The software systems utilized by the SN were initially developed in the 1980's. Over the years, many changes have been made. The SN has recognized the need to increase the efficiency of the services they provide to the users and has begun a modernization and recapitalization project to completely renovate the hardware and software systems. The "integration readiness" of the SN relies heavily on the completion of the system updates.
The NEN consists of NASA, commercial, and partner ground stations and integration systems providing space communications and tracking services to lunar, orbital and suborbital missions [1]. In some ways the NEN is an example of integration in action; as services provided by NASA, commercial and partner ground stations are all planned by interacting with Network Integration Management Office (NIMO), and requested, and scheduled via a single NEN system. This network utilizes software that is monolithic by design and highly customized which may result in extra work by the software vendor to adapt the NEN software for integration. The NEN is comprised of several ground terminals which utilize dissimilar equipment from one another, thus making integration of process increasingly difficult.
The DSN consists of large aperture ground stations located around the world providing coverage of spacecraft from Geosynchronous Earth Orbit (GEO) to the edge of our solar system [1]. This network provides their user missions with a collaborative scheduling environment through which the user missions can collaborate with each other to schedule time on the DSN ground terminals. The DSN operational process requires the most manual operation of any of the three networks. The lack of automation in the operational process requires DSN operators to intervene and/or confirm the execution of services at different points in order for the process to proceed.
The three networks provide a variety of communications and navigation services to user missions. In order to access these services, user missions go through a service planning process. This process enables them to enter into a service agreement with NASA to provide user mission-specific communications and/or navigation services to the user mission. The service planning process is different between the networks. The SN and NEN user missions work with the NIMO to facilitate the planning of their mission, while DSN user missions work with the DSN Mission Services Planning & Management (DMSP&M) Office to fulfill their planning needs. These two organizations provide roughly the same services, though they implement these services through different processes. Integration will allow the implementation of common processes.
Most science user missions have very specific communication and navigation requirements which allow them to work with only one or occasionally two of the SCaN Networks. Often times the second network is requested to provide backup services in case of a network issue or user mission emergency situation that requires rescheduling or reallocation of network resources. To meet the various communications requirements of human space flight missions, all three of the SCaN Networks must be utilized. Integration resulting in a single process to acquire services from all three SCaN Networks would significantly reduce the level of effort exerted by human space flight missions to meet space communication and navigation requirements. This is a general description of today's space communication networks. Each network has a different assortment of user mission's utilizing the provided services. Though the networks differ in many ways, they are all an integral part of the way SCaN communications and navigation services are provided today and in the future. Integrating the networks to minimize unnecessary differences between the networks may help to reduce user mission burden and cost to NASA and the user mission in the long run. Fig. 1 shows the integrated network architecture concept that is the goal of the SCaN Network Integration Project (SNIP).

B. Integration Goals
The integration of NASA's communication and navigation capabilities began in the summer of 2006, when the NASA assigned management and Systems Engineering and Integration (SE&I) responsibilities for the Agency's space communications and navigation assets to the SCaN Office and directed the centralized management of NASA's space communications and navigation networks. The push for integration was formalized further by a Program Commitment Agreement (PCA) in 2009 that reiterated the SCaN Program's responsibility for providing communications and navigation services (including systems engineering and planning) to user missions, and maintaining and evolving the SCaN architecture to effectively and efficiently meet user missions' present and future needs. The PCA included seven objectives which have become the SCaN Program's driving requirements. The first of these driving requirements mandates the development of a unified space communications and navigation network infrastructure that meets both robotic and human exploration mission needs [2]. The remaining driving requirements could be enabled through unification if it resulted in the pooling of both technological and financial resources.
What this unified network might look like and what integration or unification means has been the subject of many debates and discussions within the NASA space communications and navigation community. The trade study team proposed that unification or integration would be achieved when there was an increase in common hardware, software and processes across the three existing SCaN Networks. The goal of integration is limited by the fact that some technological and process differences exist to meet user mission requirements.
In order to define the future vision in a quantitative manner, multiple architecture and commonality trade studies have been performed. Through the performance of these studies two themes have become clear, any efforts towards integration should increase the ease in which the user missions interact with SCaN and these changes must not inhibit the ability of SCaN to provide the variety of communications and navigations services desired by the user missions. Studies on the interactions between SCaN and user missions, such as the Service Planning Commonality Study focused on early user interaction with SCaN, and brought to light the difficulty new user missions experience in learning about SCaN services and obtaining these services. Changes in processes and tools were identified as ways to improve the working relationship between SCaN and user missions.
The quantification of this need and guidance on how to address it resulted in the creation of the SNIP which will be responsible for implementing, in a step wise manner, projects resulting in the integration of the SCaN Networks.
In parallel with the performance of trade studies, the individual space communications networks have been implementing multiple, different recapitalization projects to ensure they can continue to meet their individual user mission needs while integration efforts are being defined. The largest of these projects is the SN Ground Systems Sustainment (SGSS) Project. This project will modernize the ground segment to enable the SN to continue to deliver high quality services, meet stakeholder requirements, and significantly reduce required operations and maintenance resources [3]. The parallel performance of these recapitalization projects has presented both challenges and benefits to the integration efforts.

C. Trade Studies Processes
Trade studies provide an objective foundation for selecting one of two or more alternative approaches to solve an engineering problem and support decisions in all stages of system development, from conceptualization to deployment [4]. Trade studies can be used to determine the optimum of many technical options within a given trade space. In this case, numerous architecture options were developed and then evaluated using a systematic process.
The trade study team consisted of systems engineers and from Glenn Research Center, Goddard Space Flight Center, and JPL as well as subject matter experts from each of the three SCaN Networks. The first step in the process was the identification of the boundaries of the trade space under examination. Next, brainstorming of potential architecture solutions within that trade space took place. The various options were considered by team members to ensure there was value and no inhibiting factors that would prevent the eventual implementation of a particular option. Cost was analyzed during these steps, but was not used as a factor for elimination of any particular option.
To ensure complete understanding of the existing network architectures and to capture their similarities and differences, both system architecture and operational processes were modeled within the predefined trade space. This was the first time SCaN had implemented Model Based Systems Engineering (MBSE) practices. The learning curve experienced during this effort paid off immensely because it allowed the study team to create detailed system architecture and operational processes for the architecture options under consideration. The modeling effort facilitated the comparison of both existing architectures and proposed architectures to determine where the technical challenges in implementation may arise, as well as facilitating the estimation of implementation and operational costs associated with each proposed architecture option.
A risk assessment evaluation was performed to determine which, if any, architecture options should not be considered because of the level of risk associated with them.
Figures Of Merit (FOM) were developed to enable the quantitative evaluation of the value of each architecture and operational process option. The FOMs were developed in a way which minimized the potential skewing of the results towards one option or another whenever possible. Finally, trade study conclusions were presented to a review board for evaluation and feedback before the final conclusions were presented to the SCaN Program Management team and managers from the SCaN Networks.

II. INTEGRATION CHALLENGES
Many challenges stand in the way of integrating the three SCaN networks into one integrated network. While none of the technical challenges are "show stoppers" for the integration, they make the integration effort more difficult. Cultural challenges on the other hand could delay or even prohibit integration if not overcome.

A. Difficulties presented by legacy systems
The software liability in each of the networks is a technical challenge. Of the three networks, the DSN uses the most current code techniques and languages which can lead to increased scalability and extensibility. The SN and NEN, on the other hand, use some older software techniques that can cause problems when attempting to integrate the software into a system using the latest software techniques. Over the years since its initial implementation in the 1980's, the SN software system has been reworked many times to solve issues, bugs, apply patches, etc. The patches and code fixes were only meant to be a temporary solution. These numerous software fixes also make it increasingly more difficult for new developers to come up to speed on the software system of the SN, which could lead to increased integration timeframes. Addressing this issue is a primary focus of SGSS. The NEN software system is using some older code languages and techniques, much like the SN. The NEN has the further problem of being monolithic by design. This monolithic software could lead to difficulty when integration starts as a small change in the code may result in major changes elsewhere. A more modular software design would allow for changes to be applied to particular system while not impacting the systems which interface to it.
Of all of the networks, the DSN uses the most current software languages and techniques to implement its functionality. The recently renovated Service Scheduling Software (SSS), which was developed using modern development paradigms, provides the schedule de-confliction, schedule generation, etc. for the system. The SGSS software includes a scheduling system for the SN which may be the baseline for the integrated scheduling system. If so, that software may need to be extended to interface with SSS, or SSS will need to be replaced. Due to the currency of the SSS software, however, this should be a relatively painless task.
Over time the SCaN networks have become customized based on user mission requirements. Without a standard set of services that a user mission must choose from to acquire service, user missions have occasionally directed the networks to provide them whatever services the user mission deems necessary to enable the mission, even if most of the cost of upgrades to the network become the responsibility of the SCaN Program instead of the user mission. As discussed earlier, each network has a different user mission community based on the characteristics and capabilities of the network. As a result, the SCaN networks have become overly responsive to the needs of their user mission customers. The networks continually become less similar with every specialized service, equipment, and software code that is introduced into the system to meet user mission needs.
Although the differences in current software implementation do not directly impact whether or not the systems can be integrated, these challenges do impact the design of the integrated system. Systems and operational process options under consideration were occasionally modified as maintenance and sustainability challenges were identified to ensure a higher level of maintainability and sustainability within the future SCaN Network.

B. Current Technical Challenges
For the reasons listed above, as well as others, each of the networks has realized the need for modernizing or recapitalization of their processes, software, hardware, and operations. The SN has contracted an upgrade for their network, SGSS, which will modernize all aspects of the network. This includes brand new software and hardware systems. The operational and maintenance processes will also change due to the changes to the other systems. In fact, an additional goal of SGSS is a significant reduction in the system maintenance required. NEN has considered an upgrade to their monolithic system but due to budget constraints has not been able to modernize the network. The DSN has taken steps to upgrade their network as well. As discussed previously, DSN has built a scheduling software front-end for the new scheduling system that JPL developers have coded. The DSN is also in the process of upgrading several of the antennas at their ground station sites. While each of these modernization attempts is a step in the right direction for each network, the on-going changes make it more difficult to develop a process for the integration to occur. Integration process steps need to be developed for implementation, but the step design becomes more difficult to capture because both the existing and modernized implementations (which are still being designed) must be understood. The considerable amount of money spent on the SGSS upgrade has motivated SCaN to analyze how much of the SGSS upgrade to SN can be adapted to the NEN and DSN. The differences in the types of user missions supported and recent, independent upgrades to the DSN make the adaptation of SGSS difficult but not impossible. SGSS hardware and software at ground station sites cannot be used "as-is" for DSN and NEN ground station sites and so modifications of the software, and possibly hardware, will need to take place. This adaptation for the DSN and NEN has been a focus of the trade study efforts. The trade study has determined that the software and hardware from SGSS can be adapted to interface with DSN and NEN hardware and software. Though these adaptations will require further work from the release state, they are not a deal-breaker to the integration effort. The operational processes will also have to change due to the high level of automation SGSS provides for functions such as scheduling, planning, network asset assignment, etc.
These are only a handful of the technical challenges that must be faced in the integration of the legacy SCaN networks into a more integrated network. The networks have many different technical characteristics that need to be analyzed before any implementation can occur. Though these technical challenges do produce some difficulty for the SCaN integration effort, the technical challenges are much easier to overcome than the cultural differences between the networks and the challenges they create.

C. Cultural Challenges
Though there are many technical challenges to consider when integrating the three SCaN networks, the cultural challenges are equally difficult to resolve. Cultural differences between the networks have occurred over time as a result of the networks "growing up" separately. Separate user mission communities, different management philosophies, different software systems, and ability to adapt to a changing technical world are all contributing factors to existence of cultural differences between the networks.
When attempts to integrate similar legacy systems which were developed independently are made it is common to discover processes and modes of operation which serve the same purposes differently. Occasionally the differences are small and integration into a common process is easy, often times because the processes are well tailored to existing operations changing to a common process is unwelcome. The following are examples of network specific processes which have similar intents but different implementations.
As discussed earlier, the scheduling systems between the SCaN networks are fundamentally different. The scheduling system for the SN and the NEN use a priority-based scheduling system to determine where a user mission's access to scheduled services. If two user missions were to schedule the same service at the same time, then the user mission with the higher mission priority is scheduled. Mission priority is used to prioritize user missions. This is different than "absolute" priority (emergencies, critical events) which takes priority over mission priority. The DSN, on the other hand, uses a collaborative scheduling system for conflict resolution. If two user missions schedule the same service at the same timeframe, the SSS scheduling system contacts all user missions to inform them of the conflict. It is then up to the user missions to work together to negotiate how their services can be scheduled at a time that satisfies each of their requirements.
The user mission community of the DSN has always used this collaborative scheduling system and is understandably concerned with a possible shift to a priority scheduling system. A priority-based system could eliminate or reduce the hands-on collaboration this user mission base has developed in favor of making the scheduling process more time efficient. Integration into a single scheduling system may be a part of the integration of the SCaN networks. It will be the responsibility of each network to transition their user missions to the new scheduling system. Transitioning user missions to new systems, new processes, and standard services is a key challenge facing SCaN.
As previously discussed, automation plays a big role in the differences between the SCaN networks. DSN has a very user mission, hands-on scheduling process currently. NEN has a service execution process which involves operators setting-up control tables which correspond to equipment configurations to enable user mission services. The planning processes for each of the three networks are almost completely manual processes which require considerable documents, emails, phone calls, contacts, etc. Each network has areas where automation could help to further the efficiency of the network for the user mission. By increasing automation in the networks (throughout the mission lifecycle) it is anticipated that user missions can expect shorter turnaround times from service planning to service execution, the SCaN network can expect reduced costs from lowered personnel counts as well as labor hours, and the SCaN operators can focus on addressing emergent issues and emergencies, as opposed to nominal operations. The difficulty lies in the resistance to updating the networks to accommodate such a level of automation. Concepts such as utilizing automation to enable network operators to handle additional communications links or to minimize network operator intervention in the operations process have initially met with resistance. However, after further analysis during the trade studies, it has been found that efficiency can be gained through automation of the operational processes, and the resistance has softened. Whether the operator has to push a button to forward a process along to the next step or the software intelligence checks all parameters and approves the promotion itself, is up to the networks but one is clearly more advantageous as far as cost and efficiency is concerned. Some of the same arguments can be applied to the service planning process, as briefly mentioned above. The processes used by NIMO and DMSP&M are almost completely manual. The personnel in those organizations work with the user missions to determine the correct mission parameters to acquire service. The process results in the signing of several documents including a Service Level Agreement, a Network Operations Plan, Interface Control Documents, and others. These documents are similar but not the same between the two planning offices and thus the processes and information required from the user mission is slightly different. If a user mission requires service from more than one network, then currently, the user mission must work with both planning offices, and follow separate processes.
A potential approach to integrate these processes is the creation of a Service Planning portal, which was rrecommended by the trade studies. This portal would enable the user missions to access only one website and begin their planning process. The portal would enable the user mission to enter mission requirements and other mission parameters electronically into the system to establish the necessary documentation. The back-end portal system would generate the necessary documentation from the information the user mission has entered. While this portal does not necessarily demand the integration of the two planning offices, naturally that integration would create a more efficient process, and from the perspective of the user missions, there appears to be a single point of contact.
The portal concept and design has not been without difficulty. The two planning offices have been joined into one overarching planning office called the Mission Commitment Office. To date, only marginal progress has been made to harmonize the planning documentation at each office. Obviously the increased automation of the planning process and the merger into one planning office, from two, should result in savings to the SCaN network from a reduction in personnel costs. It should also decrease the burden placed on the user missions who wish to acquire SCaN services from multiple networks.
During the trade studies, the network control operations, at each network, were studied by the team. Network crosssupport was an option that the team looked out. As used in this context, cross-support means that an operator from the SN would temporarily be assigned operational duties on the NEN, for example. This would require the operator to be aware of the operational processes of each of the networks. Currently the operators are trained on the operational process of the network for which they are assigned. The rigorous training process takes anywhere from six months to two years to properly train a new operator. Upon further analysis, a generational difference emerged. Some hold the opinion that no operator is capable of operating more than one network; the networks are simply too complicated. Others hold the opinion that given the current integration rate of technology into everyone's lives, from a very young age, provided the appropriate level of automation, one operator may be able to operate multiple networks. Multi-tasking has become the nominal mode of operation for employees of all industries. More and more business includes international contact which means the employees are required to be fluent in several languages. Software developers are required to know several development languages in order to meet user mission needs. The younger generation is more equipped to handle multiple and diverse operational procedures and languages; they have been doing it their whole lives. This makes the younger generation more capable of handling the training and operational processes that are required to enable network operator cross-support. SCaN, like any other organization, needs to adapt to its changing environment and changing workforce in order to capitalize on the strengths that exist within the up and coming generation of employees.
In order to socialize proposed changes within the networks progress reviews with SCaN Network managers and SCaN Program management were held periodically. These reviews helped inform the persons responsible for maintaining and operating the existing networks to understand what options had been considered and which ones were being proposed as part of the architecture of the future SCaN Network. Not surprisingly these reviews presented challenges in that whenever a new or innovative idea was presented it was predictably met by resistance.
A final, and overarching, cultural challenge within the integration process has been the resistance to new ideas. There is a familiarity to "the way things have always been done"; the future and the changes it brings can be unsettling to some. The initial reaction to new integration approaches were often met with opposition. However, often, after discussion and analysis, those initially opposed would either retract their opposition or acknowledge that some of the new ideas proposed were possible. Not all of the integration ideas proposed were technically feasible, as proven during further study, but an initial opposition to new and innovative ideas seems to be prevalent. The opposition appears to be the result of ensuring a high-degree of user mission focus, and pride in a history of meeting and exceeding user mission expectations. Regardless, if SCaN desires to provide their user missions with the highest quality and most efficient service processes, than new ideas need to be encouraged and then openly considered.

III. LESSONS LEARNED
Many different challenges, both technical and cultural were experienced during the course of the trade studies. Overcoming these challenges is an on-going effort in some cases while others were conquered easily once examined through a systems engineering approach. These challenges resulted in the following lessons learned and recommendations to be followed when completing similar exercises in the future.
• Plan to achieve efficient maintainability & sustainability: Efficient maintenance of software intensive systems is significantly different than of hardware based systems. How the software systems are developed has a major impact on how easily and efficiently they can be maintained. When transitioning from a hardware based system to a software intensive system, it is important that management and maintenance engineers be made aware of the risks and challenges inherent within these systems so that proper steps can be taken to minimize the tendency patch the software in a way that does not allow for major upgrades or improvements in the future.
• Lack of source code and documentation can present long term sustainability issues: The use of small businesses or outside vendors to develop software can pose risks to the development and maintenance of software based systems. These risks can have been mitigated to an extent by taking steps such as proper software documentation (including valuable and extensive commenting and maintainable and readable code structure), and acquiring vendor source code. Although the acquisition of source code is typically a large financial commitment, being able to maintain and sustain source code in a flexible (using in-house workers or vendors) and timely manner can reduce costs in a way that justifies the up-front costs. There will always be a certain amount of risk though due to the lack of familiarity with the externally-developed system by NASA employees and operators.
• Choose integration steps wisely: When integrating legacy systems it is important to define what level of integration is technically feasible and within the budget, so that time and energy can be focused on the achievement of the most impactful integration rather than figuring out how to integrate every last detail of systems that may benefit from some level of difference.
• Implement enabling processes: Because SCaN is attempting to transition to a more service-oriented organization that offers standardized services, it is important to put into place constructs and processes which facilitate this change. Therefore, every request for a new service must be processed in a way that determines exactly what is different about the newly proposed service and if that service can be implemented in a way that it will meet the needs of multiple different user missions.
• Beware of preconceived notions and resistance to change: It is easy to have preconceived notions of what is possible and impossible, especially with respect to the level of automation that can be allowed within a system. In this respect, having intimate knowledge of one or more operational systems within a trade space can have both advantages and disadvantages. If someone has operated a given system in the as-is state, it could be difficult for that individual to envision that system becoming so automated that a particular operational role no longer consumes all of one person's attention. If the goal is to determine what the limits of potential automation are within a system, it is important to work not only with personnel who understand the legacy systems very well, but also others who lack that intimate knowledge of the system of interest and who have knowledge of cutting edge solutions that could apply.
• Balance innovation and cost: Innovation and increasing levels of automation are often very appealing to engineers who continually strive to make their system of interest more efficient and would enjoy implementing the latest and greatest technology. When dealing with systems-of-systems the desire to make the system as innovative as possible must be balanced against technical risks and implementation costs. The realization of a moderate improvement in automation and system innovation that can actually be implemented may be better than striving for the most innovative solution, particularly if that solution is too costly to implement.
• Common processes and ease of access to information can have a positive impact: The SCaN service planning process is very manual and communication intensive. There are two aspects of this process which may be improved: the interaction between SCaN and the user mission, and the interactions across the existing organizations and networks within the SCaN Program. Both interfaces could benefit from the implementation of additional tools and standardized processes. The need for interaction between SCaN personnel and user missions will never be eliminated. It may be possible, however, to make the process more efficient through the implementation of standardized processes and tools which make communication between the two parties easier, the dissemination of information more efficient, and streamline the generation of different forms of documentation. A user guide that describes all aspects of the planning process to the user missions and walks them through all the steps they must complete has been identified as an essential part of these new tools. This user guide, along with consolidation of reference information is expected to go a long way to making the service planning process more efficient from the user mission perspective.
• When in doubt, prove whether or not something is possible or impossible to do: It would be invaluable to do a process study to determine whether or not individuals could be hired and trained in the operational of multiple different networks within SCaN. This type of exercise would serve to prove out the assertions that the next generation of employees could be trained to support multiple networks as well as aid in the identification of what types of automation and innovation within the systems would make the cross support process more efficient. This study could be performed through examination of the capabilities of space communications and navigation systems outside of NASA which were implemented more recently. If no equivalent systems exist, an in-house study could be performed where potential new employees, or existing employees are given the opportunity to learn more than one system and their experiences are used to quantify the potential challenges of cross training.
• Quantifiable proof in studies is invaluable: When evaluating potential new solutions to existing challenges it is extremely important to gather quantifiable proof as to whether new and innovative solutions can or cannot be implemented. Without this vetting process, high value solutions may be discarded early on due to preconceived notions about what is possible and impossible within existing operational systems.
• Terminology and common understanding cannot be assumed or over emphasized: Even when team members all work in the same domain, understanding exactly what each other is saying is of utmost importance. Throughout the course of the trade studies there were numerous occasions where a term common to the space communications domain would be used and everyone would think that they knew what the person talking was referring to; but when the idea was driven to the next level of detail we would find out that at least two people (often more) on the team had a slightly different interpretation of that same term. The creation of a common glossary to ensure the trade study team was on the same page proved invaluable.
• Understand your team and managements so you can work with them to minimize the resistance to change: Including leaders from within the existing operational systems as decisions makers within the trade study review process is a precarious undertaking. Often times these leaders are concerned with the potential negative impacts to their system as opposed to seeing the overall benefit to the system of systems. To ensure these leaders can be productively involved in the process of making changes which impact the system-ofsystems, it is important those involved in the definition of potential options are not only fully educated in the existing systems, but educated in the user missions' needs and concerns as well. Without proving an indepth understanding of the current system, the organization's needs and their user mission needs, it may be impossible to convince leaders within an organization that change is a good thing. Quantifiable financial benefit paired with an in-depth understanding of the value provided by the existing system and the impacts of its' modification on the systems of systems is often the best way to convince leaders that major changes to the system would be beneficial.
• Collaboration and consensus doesn't always mean that everyone agrees that there is only one right answer: NASA's culture values decision making by consensus very highly. When decision makers have a vested interest in the existing system it is often impossible to bring everyone into agreement that there is one best solution to the problem. It is important to remember the consensus doesn't mean everyone agreeing to a single idea; instead it means that everyone has the opportunity to voice their opinion and understand the proposed solution well enough to stand behind it. Coming to the point where everyone, even those who prefer other solutions, can stand behind a decision is of great importance when making decisions that will take years to implement.

IV. CONCLUSION
These are just a few of the technical and cultural challenges facing SCaN's goal of integrating the networks to increase efficiency and ease of use for its user missions. The cultural challenges present are as equally daunting an obstacle as any of the technical challenges, not only because the technical challenges have been proven to be conquerable, but because the cultural differences between the networks and network personnel has been growing since the birth of the networks. These deep-seated philosophies of how the networks must be operated need to be tempered with reasoned new ideas and approaches in order to realize a maximally integrated network. The trade studies team found that applying quantitative systems engineering processes was advantageous in overcoming the resistance to change and differing perceptions on what level of change could be implemented.