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:
integrated testbed
