Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 17
III. CENTRALIZATION OF MANAGEMENT FUNCTIONS As indicated earlier, the Committee believes that the Office of Space Science and Applications (OSSA) recognizes the extreme importance of infor- mation management to its mission, as well as the need for considering pos- sib~e changes to the way information systems are managed. Key personnel in OSSA are aware of studies indicating that the management of information systems will become much more complex in the future, as interdisciplinary and multidisciplinary missions increase in frequency and importance. A number of steps have already been taken to provide a more centralized focus on OSSA's information systems management, including the establish- ment and subsequent growth in responsibilities of the Information Systems Office (ISO). While the Committee and most NASA personnel with whom it met favored some further degree of centralization, no one (as yet) has determined how much more should be sought. Therefore, the Committee believes OSSA should strive to answer the fo1 lowing: Issue #1. To what degree should information systems management and planning be further centralized? The Committee does not subscribe to the notion that if "some" is good, then "more" must be better. Overcentralization of information systems management functions could lead to serious problems; much depends on the actua reaui ~ functions to be centralized. The development of data systems res an ongoing interaction between users and members of a project responsible for the mission data system. Major issues concerning scope and cost need continuous review by all those involved. Certainly, OSSA would want to avoid a management system in which systems solutions are promulgated from above without the appropriate level of user input. A proper balance is needed, to ensure the information systems function does not become a barrier between the scientists and the mission data systems people. The Committee does not know what the proper balance is, nor does it expect OSSA to be able to define it without considerable review and perhaps trial and error. In the discussion that follows, the Committee offers, for OSSA management consideration, those observations believed to be pertinent to this management issue. 17
OCR for page 18
The Present Role of the ISO. The ISO is one of the functions depicted in Figure 2, Chapter ~ that has advisory functions but no line authority. NASA Management Instruction 8030.3A, Policy Concerning Data Obtained from Soace Science Flight Investigations, identifies the ISO as responsible for establishing policies for management of space science data and for management of the NASA Space Science Data Center (NSSDC) at the Goddard Space Flight Center (GSFC). It is also responsible for coordinating infor- mation systems program activities across the NASA organizational structure with offices that are involved in OSSA mission flight programs. Several years ago it was assigned the responsibility for providing the pilot data systems mentioned earlier, and more recently it was assigned management responsibilities for information systems in support of the Earth Observing System (EOS) program. However, the bulk of program funding authority and responsibility for information systems rests with the program management offices for the particular disciplines. The ISO exercises little influ- ence over the activities of these program offices and is neither author- ized nor equipped to carry out the management obligations necessary to the success of the integrated earth sciences information systems program. The ISO can advise the program offices on development of their information sys- tems but it has no authority to invoke common design features that could result in economies of scale or commonality of characteristics across dif- ferent mission programs. Nor can it exercise line authority to ensure use of the latest technologies in flight-mission ground information systems, even if those technologies are proven and could produce greater efficiency of processing at lower cost. More than half of the ISO annual budget is devoted to management and operation of the NSSDC, with the balance spread over a variety of studies and consulting bodies. Little time is put into the actual management of information systems, nor can it be with the ISO's small staff. It is difficult to imagine how the ISO could accept the assignment of additional responsibilities or greater authority without a concomitant increase in personnel and financial resources. Philosophical Focus. Traditionally, information has been considered as a cost of doing business and is generally regarded as a subservient but necessary line item to be tolerated. This was largely because the data- bases making up these systems were diverse and originated from a variety of sources and formats, and because computer processing was required for the large quantities of raw data generated by the space platform. Digital cartographic and image database development, coupled with existing digital data sources and the computational capability to organize and manage them, has elevated information systems from a disparate aggregate of independent data to a highly organized, independent resource that can stand on its own as a management function. Recognizing information as a manageable resource in its own right is a philosophical step necessary to establish a favorable climate for any structural changes that might be required. At the field centers the Committee has seen an awareness of the need for such management development. The EOS project office at the GSFC has indicated recognition of some aspects of this, and at the jet Propulsion Laboratory (JPL) a set of standard performance requirements for science information systems has been promulgated. But OSSA has not, thus far, provided an organized thrust that might bring a unified management focus to science 18
OCR for page 19
information systems, ensuring commonality of design approaches sufficient to achieve the objectives of integration (interoperabiJity) across the scientific discipline projects and programs within the OSSA. The Need for a NASA Information Systems Focal Point. NASA, the National Oceanographic and Atmospheric Administration (NOAA), and the National Science Foundation (NSF) are jointly engaged with the interna- tional community in a program of integrated earth systems science to enhance understanding of how the component parts of the Earth system function, interact, and may be expected to evolve. Understanding depends on the development of information, which in turn depends on the gathering and processing of data that, in the context of integrated earth systems science, is increasingly interdisciplinary. Al though these joint activi- ties are being conducted as shared responsibilities among the participa- ting agencies, the watchwords are "integration" and "interoperability." Within each participating agency, as well as across agencies, the infor- mation systems of the component scientific disciplines must be able to cope not only with rapidly increasing requirements for storage of and access to data, but also with probe ems of compatibility or interopera- bility among diverse data bases and information processing systems. NASA's very successful experience over the years in working with NOAA on the weather and climate program could well be used as a mode] by OSSA to establish sound, continuing interagency relationships in its (multidis- ciplinary) information systems programs. We understand that memoranda of understanding with other agencies are already in preparation, and are pleased to see this initiative toward good, interagency working relation- ships in information systems. The Committee believes it is critical to the success of the program that, within each agency, top-1eve] management authority and responsibility be established for that agency's integrated (earth science) information systems, and that the agency manage those integrated information systems as comprising a program in its own right. This suggests that each agency will need to have a strong, ably staffed, and adequately funded program office to manage the information systems program as a service or resource to the mission offices, responsive to their requirements. In this context, the logical choice for the NASA focal point would be the OSSA focal point for information systems management. Structural Focus. A common approach to secure management control over a particular set of functional activities is to focus on organizational structures. In this instance, the goal would be to establish a structure that would facilitate the changes needed to achieve interoperabiJity or compatibility among OSSA' s di sci pl i ne and mission information systems. The approach favored by a majority of committee members is establishment of a program organization for information systems. That is, pi acing the information systems management function at a senior management level co- equal with the program Directors, with line responsibilities and budget authority derived in part from them and in part independent. If such an approach were to be taken, a statement of commitment will have been made as to the relative importance of information resources within the organ,- zation, and at a J eve] understood by all. This might also tend to insu1- ate the activity from interdepartmental mergers such as have been proposed 19
OCR for page 20
from time to time, and which would tend to dilute the function of this organization, if not render it ineffective. A strong, semi-independent, information systems office could provide the information resource focal point having management responsibility for: System engineering plans, including studies to achieve optimum compatibility or interoperabiJity among information systems, and systems that meet the needs of OSSA s science mission; A work breakdown structure showing the interfaces needed to achieve the requisite compatibility or interoperabi~ity among the various information systems; A milestone schedule for achievement of that compatibility or interoperabiJity across the designated interfaces, An integrated test bed for simulation, modeling, and early design and prototype testing to accelerate procurement and acquisition cycles and to prove out performance, and A research and development (R&D) plan to ensure, with operation of the test bed, that fielded systems evolve with state-of-the-art technologies to meet projected needs. The Committee doubts that any existing program or project office can do this. Nor does there appear to be a single NASA focal point that attempts to integrate information systems programs while addressing a work breakdown structure approach to the issue of interoperabiJity. Long-Range Planning for Information Systems Activities. An important question related to the centralization issue is that of planning. That is, how can the planning best be managed, and who can best manage it? The Jong-range planning activity involves establishing a realistic planning horizon commensurate with organizational and functional mandates (usually 5-10 years, depending on the systems being supported). Management's perception of the organization at the end of the planning period, set against the current situation, provides the framework for goal-setting and objective statements, but this is not enough. Action plans to achieve the goals and objectives, and to identify tasks, schedules' benchmarks, milestones, resources required, and comparative costs wild expose the goals and objectives to the realities of practical accomplishment. The Committee suggests that program plans be developed to address four areas: The design and development of future space program data and infor- mation systems to provide the level and degree of interoperability required by mu~ti-discipline investigations; Transformation and integration of OSSA's present data and informa- tion systems to support an acceptable level of interoperability; 20
OCR for page 21
Determining what reformatting or further documentation and archiving of existing historical scientific data and information is required to support future multi-discip~ine investigations; and Transformation of the separate networks into a common OSSA network. Perhaps a logical pi ace to start would be the pilot and EOS programs, for which general goals already have been established. A capability to measure progress could be provided by defining an action plan that identi- fies intermediate milestones and the schedule for each program or project. To monitor actual performance, forma] periodic reviews should be held to assess the status of the program or projects as redated to the plan. These reviews would also serve as a feedback mechanism to redefine require- ments, assess responses to pre-defined user requirements, and identify the need for future special projects or systems research requirements. A hiatus of two or more years in NASA launches presents both problems and opportunities for OSSA data and information systems planning. The most recent announcement puts the next shuttle launch in 1988. It is unlikely that NASA will have an expendable launch vehicle (ELV) ready before that time. During at J east the first year of resumed shuttle operations the Department of Defense (DoD) wild have priority on payload space. Therefore, the earliest possible new OSSA sensor will not operate for at least two years, and most of the planned instruments are not likely to be in orbit until between two and six years from now. During the hiatus the ongoing OSSA programs will have data available only from exist- ing databases and existing, orbiting, U.S. and foreign sensors. This presents an opportunity not only to enhance the utility of existing infor- mation systems, which certainly should be done, but also to use the poten- tial networking of existing U.S. and foreign systems as a building block for future EOS information. Further, there is time available to plan, design, and implement information systems that will be required for future sensor suites. Information Systems Research and Development (R&D). Another logical - question to be addressed when considering centra~ized management is: does OSSA need an information systems R&D focal point? A mature management structure typically allocates a portion of its resources to R&D. OSSA has three options available for R&D: perform it in-house, obtain support from other NASA activities, and obtain support from outside NASA. The reJation- ship between the NASA's Office of Aeronautics and Space Technology (OAST) and OSSA is one in which the basic technology development is conducted by OAST and then transferred to OSSA for application in flight missions. This relationship ostensibly applies to the information systems function as well as others, but it is not apparent that the necessary programmatic coordination to effect that transfer is taking place. Currently, the Office of Space Tracking and Data Systems (OSTDS) addresses space-based data systems and software engineering methodologies but has no active program in ground-based data and information systems technology. In its current ground data and information systems function, OSSA evaluates 21
OCR for page 22
prototypes of commercially developed technologies but does not identify and carry out any advanced technology developments on its own. Clearly, there is an interest in OSSA R&D that should be considered, especially in the area of information management systems. Evaluation, fo1]ow-up and procurement from the commercial marketplace may be more appropriate in some cases and become more important as commercial development of these systems expands. Management of Information Systems "Build-or-Buy" Decisions. A related question is: how can OSSA best decide whether to build its own informa- tion systems or to buy them? Decisions dealing with al] elements of tech- nology are needed from time to time on whether to build or buy. Someone has to develop and clearly articulate criteria to facilitate "build-or- buy" decisions in information systems technologies, or, in the case of a "buy" decision, criteria dealing with vendor selection. The Committee believes that much "technology rediscovery" and its concomitant additional costs can be avoided through the judicious use of vendors and value-added service companies. Requiring data users to bid competitively for data services would permit use of commercial~y-avaiJabJe technology more efficiently and at its lowest cost. It would also highlight to the user the question of data services and cost, the impact of such costs on resources available for other aspects of the investigation, and the trade- off decisions to be made. In light of the present Administration's stated policy of maximizing privatization and commercialization, this question deserves immediate focus. Procurement, Acquisition and Evaluation of Information Systems. Once the decision has been made to buy rather than to build, another question arises that certainly would involve the information systems manager or managers: can OSSA inprove its procurement and acquisition cycles and the timeliness of its testing to ensure effective and current technology and more timely and cost-effective life-cycles for its information systems? Many sensor platforms and information systems are being developed indepen- dently to satisfy the needs of the science community. Many of these systems are developed on a project-by-project basis. Others are integra- ted into a program with projects as components, such as the EOS program. Independently developed pilot or testbed systems support some of the project activities. Such independent systems need special attention to integrate them into the projects they support. The effort required can be reduced through the use of two techniques widely used in industry to shorten procurement and acquisition times--rapid prototyping and integrated testbeds. Rapid prototyping involves simulation and modeling techniques for establishing operational concepts and performance characteristics of proposed systems and for validating them before the systems are designed and built. Rapid prototyping can be done in software laboratories. It does not necessarily require large, integrated testbeds to arrive at system procurement specifications, but it should include user participa- tion through simulation and modeling of user interfaces with the proposed system models. Its technology involves three elements: (1) processes to 22
OCR for page 23
understand users' cognition and work styles, determine tasks and work scenarios, and define driving functions of the system design; (2) a set of (software) tools for rapid building of prototype simulation models for iteration with users; and (3) a reconfigurable (software) laboratory for prototyping and user validation. The primary focus of rapid prototyping is a dramatic reduction in the risk of building user-interactive systems with radically shortened procurement and acquisition times through iterative simulation, modeling, and verification processes. The integrated testbed is a collection of some real prototype elements of a proposed or developing system together with simulations of remaining elements, that exhibits characteristics of the intended operational system. Some thought would be required to define how major projects such as EOS could be supported with an integrated testbed. Consideration might also be given to an OSSA space sciences integrated teethed, to provide a comprehensive capability to demonstrate and evaluate archectectures and key technologies in accordance with an overall program plan. The integrated testbed might encompass additional rapid prototyping capabilities, simulations, and models with a hierarchy of fidelities to address the specific program at hand; hardware and software in the loop; and testing capabilities necessary to validate requirements, system elements, simulations, and models. With such capabilities, the testbed could be used to: (~) simulate the overall architecture; (2) support ful]-scaJe development decisions; (3) identify technology drivers; (4) identify crunch points; (~) measure the added value of new components, component changes, and technology insertion; (6) pinpoint software re-use elements; and (7) evaluate mission management schemes. Since many pi~ot/testbed programs are in existence, one could consider a federated approach for existing programs, while building a mode] testbed program around EOS. Such an integrated testbed could also support rapid development of a prototype for users' evaluation, using the required performance to shorten the procurement cycle and enhance the opportunity to use and insert state-of-the-art technology. But the Committee empha- sizes that much rapid prototyping can also be done early in concept and systems definition activities, prior to the acquisition of the integrated testbed. A similar approach has been taken by the DoD's Strategic Defense Initiative Office. Additional thoughts on procurement and acquisition approaches are provided in the next chapter. DeveJoPment of Information SYstems Software. A fine] question that . . might influence decisions redated to the further centralization of infor- mation systems management function is: how can OSSA best manage a unified approach to the creation and control of its software? The information systems that NASA/OSSA needs to develop to meet the requirements of the Space Station and EOS wi]] require the development of software on a much larger scale than is being undertaken currently. In order to meet this challenge, OSSA may want to consider implementing a software development plan that includes rapid-prototyping capabilities. The information systems that will support the Space Station and EOS 23
OCR for page 24
will have long lifetimes, and they must improve and evolve in compatible ways over the long lifetimes of the Space Station and the EOS space platform. In addition, new projects and procedures must be installed in a smooth, compatible fashion. There has been substantial pragmatic progress made in software development technology as well as in modular language and operating-system structures. The Committee suggests that OSSA collaborate with the commercial sector on the evaluation of available technologies and the integration of these technologies into the OSSA software creation and control mechanisms. ~ Rapid-prototyping approaches to software development warrant further investigation to determine their applicability to OSSA. Whereas rapid prototyping of hardware systems is weld understood and is becoming a widely adopted concept in the high-technoJogy industries, rapid proto- typing of software systems is a complex undertaking that does not have a broad base of experience. However, concepts and methodologies for rapid protoLyping of software systems are beginning to emerge and OSSA may find it useful to develop a plan for monitoring and applying these concepts. 24
Representative terms from entire chapter: