REVIEW OF THE IHS ARCHITECTURAL FUNCTION IN THE AGENCY

• Document Type: CREST
• Collection: General CIA Records
• Document Number (FOIA) /ESDN (CREST): CIA-RDP84B00890R000400030010-2
• Release Decision: RIPPUB
• Original Classification: C
• Document Page Count: 20
• Document Creation Date: December 14, 2016
• Document Release Date: May 9, 2003
• Sequence Number: 10
• Publication Date: June 16, 1981
• Content Type: REPORT

Approved For Release c03mEat9r890R000400030010-2 JUN 1981
IDRky . .
I REVIEW OF THE IHS ARCHITECTURAL FUNCTION IN THE AGENCY
OBJECTIVE OF THE OFFICE OF THE IHSA
The Office of the IHSA was established in January 1981 in
accordance with the directions of the EXCOM, based on its review of
the findings and recommendations of the Information Handling Task
Force. The office was established to plan, coordinate, guide, and
approve the overall design of the Agency's information handling
systems (IRS). The objective is to achieve an integrated, non-
redundant total Agency IHS architecture that is responsive to the
totality of user needs, while maximizing the payoff for the
investment. The IHSA also is to serve as the prinicipal focal point
for community contact and top-level information concerning the status
of the Agency's IHSs. The office function is one of top-level
management and planning, and does not involve development of system
requirements or system implementation.
FOCUS OF T11IS PRESENTATION
The IHSA has been assigned the responsibility of making an annual
report to tie EXCOM on the status of IHSs in the Agency. In this
first report, the focus is on the key problems and proposed approach
of the office of the IHSA in dealing with those problems.
In the memorandum reporting the conclusion of the EXCOM, it was
stated that "The Committee agreed to adopt the proposed mission and
function statements for the time being and review them for possible
revision after the 'architect' has been in operation long enough to
evaluate them." The office has now been organized, the staff
selected, and has begun operation on the basis of the proposed mission
and function statements. Principally, these are the mission and
function statement of the Architect of Information Services that was
prepared by the DDA in response to EXCOM guidance. It is now
appropriate to review that mission and function guidance and change
and ratify it as appropriate, in accordance with EXCO-4 findings.
Clear guidance and a statement of missions and functions, from the
EXCOM to the IHSA, is needed to direct the office and establish its
acknowledged role in the Agency community.
Since discussing the entire package of findings and
recommendations would be an excessively long and generally
unproductive undertaking, this report focuses on the key problems and
the recommended approach and authorities of the IHSA to deal with
them. The concern is with key problems found by the IHSA, but for
which no recommendations were made, and with other issues found by the
IHSA to be fundamental to the execution of the general IHSA
25X1
c
, O ~ T
Approved For A-RD
R 2 CIRDP84B0
 ,Approved For Re
NJ"RDP84B00890R000400030010-2
I
responsibility. Issues and approaches which are felt to be non-
controversial are assumed to be accepted and have been omitted from
discussion for the sake of brevity.
In the following paragraphs, the key problems in accordance with
the above stated criteria, and as perceived by the IHSA are presented.
1. Approval of Systems
I believe the current top-level management involvement for IHSs to
be primarily budgeting. The Directorates operate on the philosophy
that. once the money is available, spending it on the designated
subject is at the discretion of that Directorate. In other words, it
is a local-option environment.
I do not believe that the function of the IHSA has any significant
value unless top-level management is instituted with respect to IHSs
and this office plays a key role in that management. That is the only
way IHSs can achieve interoperability as part of a larger
architecture, precious resources can be used to develop and operate
systems in an efficient and effective manner, and the planning and
environment needed to support sysems development can be created.
The extant guidance on the approvals is scant and is contained in
a DDCI memorandum of 26 July 1978 (DCI 78-8710/16). It specifies that
all projects with an annual investment cost greater than $250,000 will
be reviewed annually by the EAG (predecessor to the EXCOM). It does
not specify any initial required documentation, such as functional
requirements, development plan, or costs. There is also overlapping
guidance with respect to ODP approval of ADP systems and ADPE in HR
of 13 August 1975, which defines ODP's charter. The latter
specifies approval authorities which are redundant to those now
assigned to the II-ISA in I of 16 March 1981. Such approval
redundancy needs to be resolved, since such a layered, duplicative
process is not helpful.
Agency discretion with respect to the formulation of its top
management process has recently been somewhat limited by two recent
actions. Section 3506 of the Paperwork Reduction Act of 1980
specifies that each agency shall appoint a senior official, reporting
to the agency head, to carry out agency responsibilities under the
act. These include review, planning, budgeting, and training with
respect to IHSs. Even if the Agency receives a general waiver from
the terms of this act because its systems relate to such activities as
the collection of foreign intelligence, the intent of Congress that
there be a single, designated, agency management and control point for
Approved For Release 2 F 90R000400030010-2
 Approved For Releas 2 7AI00890R000400030010-2
IHSs is clear.
The second action derives from the Agency's request, along with
those of several other agencies, for a general delegation of authority
.for waivers from the NBS Federal Information Processing Standards
(FIPS), managed for the Governnment by the Department of Commerce. In
its letter of 6 April 1981, the Commerce has responded that it is now
coordinating action "to amend the FIPS to delegate to heads of
agencies the authority to approve waivers." It is the view of NBS
that the letter represents a statement of clear intention to delegate
the waiver authority by DOC, subject to approval by 0MB and possibly
Congress. The delegation would be made in a formal instruction that
clearly specifies the acceptable conditions for such waivers. As in
the Paperwork. Reduction Act, a senior individual reporting directly to
top-Agency management would have to be delegated the waiver management
responsibility. This individual should not also be responsible for
systems implementation, but would review the. waiver requests of
parties responsible for such systems implementation.
We thus have three factors pointing towards the necessity of
assigning the IHSA approval authority of IHSs: the basic need for
top-level., centralized management of IHSs; the agency responsibilities
under the Paperwork Reductions Act; and the DOC.delegation of waiver
authority. with respect to the FIPS. Even if the EXCOM had not
recommended such authority, it would seem to be mandatory at this
point if the Agency's top-management responsibilities are to be met.
2. Accreditation of System Requirements
The source of the problem is probably the old aphorism, "The user
is responsible for requirements." While this functional assignment
sounds logical, it is a simplistic concept that can lead to real
problems if interpreted as the delegation of an exclusive prerogative
to the user. Some of the principal sources of such problems are:
o Lack of a reconciliation of the user's requirements
with the implementation environment;
r
o Inadequate attention to adjunct user requirements;
o Lack of a consolidation and validation mechanism
for requirements derived from a community of users.
The lack of reconciliation involves an interactive process between
the user and developer. The system requirements should evolve from
the functional requirements as the consequence of an interplay between
the techniques and mechanisms of their implementation and the
CONtIDENTIAL
Approved For Release 2003/06/20 : CIA-RDP84B0089OR000400030010-2
 -NF1DENTIAL
Approved For Release 2003/06/20 : CIA-RDP84B0089OR000400030010-2
restructuring of user organizations or operations in conjunction with
the,new system. One of the worst mistakes that can be made is simply
to automate current manual procedures; the result is usually a system
several times the size and cost as would satisfy the. need. The
implications of such a direct transformation approach are not always
well understood by user organizations.
With reference to adjunct requirements, there is an increasing
functional complexity of Agency systems due to the increasing
involvement of adjunct users. Instead of a system like PERSIGN, which
is a, per4onnel management system with a homogenous set of users, we
are now developing systems like LIMS, a logistics system with many
adjunct user organizations. The problem of the definition of the
.requirements for such a system can be difficult, particularly when an
IOC date and funding constraints force compromises.
Lastly, there is the problem of requirements for general services
systems. The requirements for these systems drive their cost,
availability, and acceptance just as they do for any other. The
problem is th e'establishment of an acceptable, but not excessive, set
of requirements. The Agency history has been that the developer sets
the requirements for such systems, based on user surveys and/or
projections of historical use data. A distinct hazard with this
process once it has begun is the natural migration of management
concern to the technical issues of implementation, to the detriment of
user interest.
All of these examples reflect a strong need for accreditation of a
new systems- functional requirements. For complex systems, this can
only be done at an Agency-wide level, since the problem is an
ecumencial one. It also requires concentrated top-level attention,
since the problems are complex. They cannot be successfully dealt
with in an EXCOM-type project review unless the key issues and
tradeoffs have already been identified and analyzed.
3. Lack of Systems Development Guidance and Training
The Agency is in an almost unique position among`;major Government
agencies in providing no Agency-wide guidance for the development of
IHSs. Some formal guidance has been developed in some groups, and
there is a lot of high-powered expertise, but little of it has been
formalized, even at the group level.
This lack of guidance is a major problem because there is a
tremendous variation in the way developments are done among groups in
the Agency. Compounding the problem is the fact that because of the
constrained budget situation, experience in the development of large
or moderate-sized systems is quite limited. While Agency experience
Approved For ReleaseC23 4e6890R000400030010-2
 CONrIDENTIAL
Approved For Release 2003/06/20 : CIA-RDP84B0089OR000400030010-2
tends to be in terms of things built with just a few people, we are
now looking at the catch-up need to develop many moderate and large-
systems. Our people need guidance, training, and standards to
execute this new phase with any degree of success.
By itself, guidance will be of very limited value; it needs to be
supplemented by an effective training program. I believe that a
significant portion of the Agency's IHSs professionals have been
relatively isolated in recent years from mainstream advances in
systems development technology. Many are simply unaware of systems
design and development procedures and technologies that have been
standard within the commercial and DoD arenas for years now. Others
believe that such technologies are only appropriate if a system
involving $100M in acquisition cost is involved; since they think they
are,dealing with the development of smaller systems, they think they
do!not need,formal'procedures.
We need to develop a common culture, a common understanding. To
do that we need to put a major emphasis on training. To do the job it
has to do, that training has to be centralized. The engineer
acquiring software for MERCURY in OC should have the same approach and
contractor procedural and documentation requirements as that acquiring
the CAMS--1I in ODP, as that acquiring CRAFT in IMS. If they do not
the problem of making these systems interoperate is made immeasurably
more difficult.
There are two types of training required:. skills and
disciplinary. We have a comprehensive course structure for the
former, generally, dispensed throughout the Agency. ODP now does
Agency-wide skills training relevant to, the use of ODP systems.
Because this program was established as component training, however,
there are substantial waiting periods to get into most courses. The
waiting period for the Basic VM course, for example, is about six
months.
The Agency handles disciplinary training on an ad hoc basis.
.Sometimes Agency personnel teach a course under a university's
auspices, and frequently staff members attend the numerous three or
five-day short courses sponsored by professional societies,
universities or other groups. But we do not present such courses
internally in the manner that the Information Services's program in
OT&E offer courses in analytic tools to the intelligence community.
Our ability to develop a common IHS culture, in my judgement, requires
that we offer internally, from a centralized source, a full curriculum
of skills and disciplinary training.
OT&E was recently tasked by the DDA at the IHSA's request to
perform a study of Agency training requirements for IHSs. A report of
C
0
NACDEMAL'
Approved For Release 2003/06/20 : CIA-RDP84B0089OR000400030010-2
 Approved For Release UTi&890R000400030010-2
the study is appended (Appendix B). Precise results were not
available because components, for the most part, had not begun to
think specifically about and plan for the problem. Basically,
however, it shows that a very substantial jump in the Agency-wide IHS
training requirements is imminent. This is compounded by the fact
that we are not even keeping up with our current training requirement.
To bound the problem, OT&E estimated the resources required if all
the training, including component-unique training which is normally
done by the components, were done centrally. They found that their
resources in terms of people, space, and equipment dedicated to the
purpose, would approximately have to triple. This estimate also was
based'on the assumption of totally scheduled training, that is no ad
hoc training. Actually there is ad hoc training, and the more
aist'ributed it is, the higher the proportion of the total it
represents. Ad hoc training significantly decreases the efficiency of
training; These would also be component-unique training done by the
components, again decreasing efficiency.
Very clearly, if this IHS training requirement is not centrally
managed, there will be a substantial growth in component training.
Each of the Directorates would shortly have IHS training centers and
dedicated resources several times that currently existing in OT&E. I
would estimate that such a distributed training approach would be no
better than about half as efficient as a centralized one.
A greater concern, however, is the development of a common IHS
culture. Distributed IHS training would destroy any possibility of
developing such a common IHS culture within the Agency. Developing a
training program that will meet all the needs of the Agency will
require top-level guidance and support.
The other part of the environment problem is the development of
standards. We need standards in three areas relative to IHS
development:
o :Management procedures and development processes standards
o Data item specifications (e.g., per CDRL)
Examples of documents in each category. exist, some of them excellent.
But these are not standards or guidances even at the Directorate
level. A moderate or large-sized systems development can readily
require the adherence to or production of 20 different documents. For
the project personnel to figure all that out de novo is an
unreasonable requirement, and it certainly is not going to produce a
CONH DENflAL
Approved For Release 2003/06/20 : CIA-RDP84B00890R000400030010-2
 Approved For Release&A I
ffl~DFb890R000400030010-2
homogenous environment. It is, however, our current situation. The
ability of systems to interoperate in a unified architecture is
probably as much a function of how they are built as what interface
requirements are levied upon them.
In.order to have a single set, of standards and have them for the
entire Agency we need centralized development and promulgation of such
standards.
Over the past five to ten years, I believe the impact of the
tightly+constrained Agency budgets has been to force the IHSs into an
increasingly cost-effective posture. Unfortunately, this increased
cost-effectiveness has been achieved at the expense of robustness. As
a consequence, we now have highly fragile data processing and
communications systems architectures. User availability of the
central systems is significantly below expectations, point failures
tend to cascade through the systems, and the ability to respond to
contingencies is not adequate for an Agency that is to support
contingency and wartime operations.
Robustness, like security, costs money and contributes little, if
anything, to performance. Working our way out of the fragility corner
requires reordered priorities and an advocate--the user's concern
tends to be with solving his immediate problems and the supplier of
the service with meeting the user's needs. Robustness is an
architectural concern and one that needs concentrated attention in the
near term future.
As our user base expands rapidly, we need to develop "user
friendly systems." We have made a very substantial investment in
developing our central systems and have now, as a consequence, some
unique and remarkable capabilities. We also have a system that
requires high degree of expertise to use in many areas. Expertise,
unfortunately, can also be correlated directly with the amount of
training required.
User friendly systems involve both the simpler' 'interfaces, as seen
by users on their visual display terminals (VDT), and simpler
facilities. This greater use of menu-driven functionalities is needed
so that users will not have to become experts in the instruction sets,
operational structure and syllogism of particular functionalities,
such as a data base management system. We also need simple
functionalities for the facile implementation of small-scale
applications. Users become frustrated when they have to learn how to
use complex functionalities in order to perform a simple task.
Approved For Release 2003/, 6 ,g:rdl
C9~OR000400030010-2
 V890R000400030010-2
Approved For Release( (mod M A
M
Development of "user friendly" systems requires priority and
investment. The user payoff is diffuse and hard to measure. As a
consequence, I believe achieving it requires an advocate to guide and
support it.
5. Scientific Programming
Scietitific programming to support intelligence analysis is a
particular problem area at the present time. The Agency used to have
a group dedicated to scientific programming, but there were a series
of reorganization moves involving it, and gradually, its members
either left the Agency or joined user groups. We no longer have a
scientific programming group and I believe this to be a major concern.
We have some. highly skilled individuals in analytic user
organizations, but not many. We are plagued by the problem that such
individuals can command high salaries in the commercial market place
where their promotability is not hampered by a need to move into
management, as it tends to be here. Here their careers'cap out fairly
quickly if' they -are in an intelligence analysis career path, and the
only option they have to continue to advance their career is to leave.
Because we have lost the scientific programming group and cannot
retain highly skilled scientific programmers in user organizations,
the Agency now primarily depends on contractors for scientific
programming support. Using contractors is certainly not a problem,
but depending on them is. I understand the impact on our program was
severe when one contractor recently had to be terminated because of
security violations. When we lack a solid in-house scientific
programming resource base, we are in a very tenuous position. In
addition, I believe the demand for scientific programming is likely to
be rapidly increasing. It is typically what happens next after
analysts learn how to operate on a terminal and get word processing
and analyst file functions under their belts.
Rebuilding a scientific programming capability`,is going to take
top-management attention. I believe that we need to develop a
"critical mass" of such people in a coherent organization with a clear
career path. They need to see SIS-level scientific programmers in
leadership positions and an appropriate GS grade-level profile.
Obtaining these conditions implies organizational changes in both
implementing and user organizations to achieve an environment
attractive to such highly skilled people. Only with the Agency career
attractiveness could we afford to hire and make the substantial
continuing education investments that such personnel require.
6. Efficient Utilization of the IHS Resources
Approved For Release 2003/06/20 : tIA-RDP84B00890R000400030010-2
 Approved For Release 2003/06/20 : CIA-RDP84B00890R000400030010-2
CONFIDENTIAL
My perception is that there has been a tremendous shift in
attitude within the Agency regarding IHSs just within the past several
years. A few years ago, most professionals with analytic or
operational responsibilities seemed to view IHSs as an arcane
technology that was the province of highly trained specialists. Today
I believe the current perception to be that an ability to utilize IHSs
is important to all professionals if they are to develop and apply
their skills at a level of effectiveness reflecting the contemporary
environment.
This very rapid growth of interest has produced an explosion of
demand. Very clearly, our IHS user community is going to expand by an
order of magnitude in just a few years. Managing that explosion of
demand to provide efficient use of the IHS resources is a major
concern. Given our budget constraints, the penalty for not
effectively managing that demand is going to be falling badly behind
in terms of processing, storage, and applications development.
The provision of IHS resources in the Agency has been based on a.
top-management review and budgeting process. The guiding philosophy
for this process is understood to have been the provision of whatever
is needed to get the job done. A primary objective has been
identified as "encouraging innovation" and the use of "computer
resources, as opposed to human resources, by making them free" to the
user.
I believe we have passed through the era where we need to
encourage the use of IHSs and are now approaching one in which the
emphasis should fall on managing it for efficient utilization. We
have a limited amount of time to prepare for a certainly predictable
future. If we do not use this time effectively to develop needed
procedures and implement functionalities, then we are going to find
ourselves "behind the power curve." It is a very difficult position
from which to extract an organization in an environment of rapidly
advancing demand and technology. %
There are two areas of IHS use that, I believe,, need attention:
on-line data storage and processing. (There are also problems in this
context relevant to applications development of which the need for
"user friendly systems" was discussed.)
While the current information/data generation rate is high, it is
going to increase substantially. The exploitation processes
associated with overhead collection systems are generating data at an
astonishing rate and are due to increase by a factor of maybe four in
just a few years. There is also the steadily increasing influx of
cable traffic from a variety of sources for analysis by intelligence
analysts. In addition we are acquiring powerful word processing
Approved For Release
D)ET
WE.
 Approved For Release 2003/06/20 : CIA-RDP84B00890R000400030010-2
CONFIDENTIAL"
equipment to be broadly distributed throughout the Agency and operate
off the central systems. This type of equipment approximately doubles
.the productivity of a typical staff..
All of these sources produce data that is being retained on disk
for real time retrieval. The Ruffing Center disk farm, for example,
now almost totally fills its allocated first floor space and is still
growing. A large part of this data could be eliminated by tape
.storage, archival, and purging. There usually is no justification for
keeping special applications programs, data or allocated space on-line
when, there has been no activity regarding it for months. Much of the
data, particularly-that generated in the WP context, is simply the
detritus 'of the daily work of the Agency's professionals and should be
disposed of.
The other efficiency issue is the use of our processing resources.
There are several key dimensions to this concern. We need to:
o Establish an effective priority system that enduces
users with lower priority processing to accept longer job
turnarounds, offloading peal: hours.
o Focus on using the most efficient program that will
meet the needs of the instant problem, and the latest most
efficient analytic technology in developing analytic tools.
o Provide motivation for the management of operational
systems to invest more of their enhancement resources in
improving the applications system efficiency.
Our processing resources are sized very much like electrical power
generation systems--offloading the peak hours reduces that
requirement. We need to motivate users in similar manner to use off-
prime time hours. For example, can an interoffice message
appropriately be processed in batch at night for del.4very the next
day, or must it go to the addressees immediately; can a sequence of
fourier analyses of missile data be packaged for a night time batch
run, or must they be done one at a time in prime time as they are
analyzed?
In developing on-line systems, the primary emphasis is on meeting
the functional specifications instead of efficiency. After they
become operational, however, the enhancement process begins. In
environments where there are dedicated resources supporting the system
and they are saturated, there is no shortage of motivation for
efficiency. Users annoyed by slow system response provide plenty of
it. In shared processing resource environments, however, motivation
is needed. Otherwise the user is naturally inclined to want all the
Approved For Release 2
 Approved For Release 003/06/20 : CIA-RDP84B0089OR000400030010-2
CONFIDENTIAL
enhancement resources to be invested in new functionalities.
Hardware technology continues to advance rapidly in the data
processing environment. More powerful processors and higher density
on-line storage devices are continuously being offered, and assuredly
we will continue to take advantage of them. We are talking, however,
about going from 300 to 3000 on-line users in three years. That is an
explosion of demand that I do not believe technological replacement
alone caari keep up with. It is certainly the history of the data
processing industry that users develop new applications at a pace that
outstrips technology. I see no basis for assuming that will change;
rather, that our planned explosion in demand will only exaccerbate it.
;Overall, there do not appear to be adequate forcing functions or
motivators to control the distribution of data, limit its retention,
use processing resources in the most efficient manner, and develop
efficient applications packages. We rely on a few administrative
procedures and ad hoc reviews by ODP. We also have our data disposal
problem compounded by the archaic regulations of the National Archives
Record Service (NARS). While we need to refine our administrative
controls `rid get relief from the archaic NARS regulations which deal
in "records" and not "data," neither is likely to be adequate to deal
with the problem. We need a coordinated and centralized approach to
efficient'use of IHS resources. Better control functionalities
resident in the central system, and greater motivation for the users
to use the resources efficiently are needed.
It takes time and priority sponsorship to develop the needed
system utilization control tools. Relief from the archaic NARS
regulations I believe requires that we take a constructive approach
and define regulations that we believe will work and make sense in our
environment. If our data control environment has not changed
substantially two years from now, I believe we will find our ability
to advance our IHS capabilities absorbed by wasteful and non--.-
productive service and administrator requirements.
RECOMMENDED ACTIONS CONCERNING THE IHSA
My specific recommendations in approximate order are as follows.
1. IHSA Accredit System Requirements and Approve Systems at Major
Milestone Reviews
To define a managerially practical environment, it is recommended
that there be three categories of systems: Class I (large), Class II
(medium), and Class III (small). The two thresholds defining the
boundaries are acquisition cost values. It is recommended that the
top-management, responsibility for the smaller two be delegated to the
11
Approved For Release 20 6 ld R000400030010-2
 . Approved For Release 2003/06/20 : CIA-RDP84B0089OR000400030010-2
CONFIDENTIAL
Directorates, and that the Directorates delegate that for the smallest
to the constituent offices. An exception to all such delegations is
systems with multiple user components, viewed from the next higher
level.
The recommended top-management review process consists of three
milestones: the planning milestone, which is a budgetary milestone
and which should interface with periodic budgetary processes; the
system specification milestone, which is a management milestone; and
the .preliminary design review milestone, which is a management
milestone. The scheduling of the last two are determined by the
characteristics of the project, and are not synchronized with any
periodic-process. This basic management review process would apply to
all three categories of systems, and there should be documentation
requirements for each milestone. Review of the conformance of
developments with documentation requirements for delegated
responsibilities would be done by the Inspector General's office as
part of their regular periodic management audit of offices.
A fo.met for such a top-management process for managing the
development of systems is attached as Appendix A. This format was
prepared because it became clear that it was important to clarify the
mechanism of the intended approval authority for the EXCOM to be able
to make a knowledgeable judgment.
It is recommended that the IHSA be authorized to develop a DCI
Directive concerning accreditation of requirements and approval of
systems based on this format as it may be modified by the EXCOM.
It is recommended that the system approval responsibilities
currently assigned to ODP be assigned to the IHSA, per the approved
25X1 format, in the update of 0 and a new HR defining the
responsibilities of the IHSA. In this context it is the intent-of the
IHSA to delegate responsibility to ODP for review of all ADPE embedded
in new systems for compliance with FIPS, and conformity with our
central environment where appropriate. ADPE not embedded in new
systems would remain the direct responsibility of ODP. The interest
of this structure is to assure that developers of new systems have
only one review point, and that the review that is provided is as
thorough as is the current process.
2. IHSA Prepare and Promulgate Agency-wide Procedures and Standards
Pursuant to the IHSA responsibilities under ODP has 25X1
passed responsibility for the Agency Standards Committee to this
office. It is recommended that the IHSA's chairmanship of this
committee and responsibility for promulgating the Agency's procedures
and standards,. supported by this committee, be affirmed.
Approved For Release,20AWQ6I
 Approved For Release 2003/06/20 : CIA-RDP84B00890R000400030010-2
C NFlDENJ
3. IHSA Plan and Guide IHS Training
It is recommended that the IHSA provide the top-management
guidance and support needed to establish a centralized IHSs training
program. This program would focus on non-component-unique IHS
training and be implemented within OT&E.
The process should proceed along three paths simultaneously:
there should be a follow-on to the training requirements study
(Appendix B) with all of the Directorates tasked to work with OT&E in
developing a comprehensive and specific statement of IHS training
requirements for the fiscal year 1982 through 1985; OT&E should
evaluate the implications to the organization staffing and regular
requirements of the Information Science Center of the cost of
centralized training requirements identified in Appendix B; and
contractor provided training should be procured by OT&E to respond to
the immediate training needs of the Agency. A hold should be put on
the expansion of component IHS training and by both indigenous and
contractor personnel until the definitive study is complete and
decisions made. The IHSA will guide the two study efforts and the
contractor-based quick-response training.
4. ITISA Guide Resource Allocations with Respect to Long Range
Architectural Investment Planning
It is recommended that the IHSA have authority to task various
Agency offices responsible for the provision of IHS services to
perform studies of system architecture alternatives relevant to their
systems. The studies would be designed to support both the strategic
planning responsibilities of the IHSA and more immediate concerns
relevant to robustness and provisions of "user friendly" systems.
The objective of these evaluations will be to achieve through as
an adjacent of new investments, rather.than to restructure the
existing system--in other words, to take the more economical approach
of "working our way out." On the basis of the studies,. the IHSA
should review the office resource allocations, and adjust priorities,
where appropriate, to begin achieving robustness and "user friendly"
system objectives.
5. IHSA Guide and Direct the Establishment of a Scientific
Pro ramming Capability
It is recommended that a scientific programming capability be
established within ODP to support scientific programming requirements,
Agency-wide. The group would be relatively senior, compared to the
data processing applications development staff. Initially the group
Approved For Release
1~$90R000400030010-2
 Approved For Rel a fF8;4B00890R000400030010-2
would have twenty mathematical programmer slots, the majority drawn
from ODP's 1983 programmer increase of 35.
The IHSA should be tasked to direct a joint study with NFAC and
ODP to determine the organization, placement and method of operation
of this group. The objective of the study is to determine the best
way. to provide thrust of an environment needed to make an Agency
career attractive to such personnel, while meeting the operational
requirements of NFAC and the management requirements of ODP. The
study report will be made to the EXCOM.
6. IHSA Chair a Committee to Examine Methods for Improving
,E ic.iency of Utilizations of IHSA Resources
It is recommended that the IHSA be tasked to develop a set of
recommended techniques for controlling the efficiency of utilization
of IHS services. It is recommended that a committee with Agency-wide
representation be appointed to advise the IHSA in the development of
this package. To be specifically included are user monitoring
systems, developing an Agency proposal for a revised NARS regulation
governing records disposal, and chargeback. A report will be made to
the EXCOM of the evaluations made and recommended actions.
7. Publication of a Revised Headquarters Notice Signed by
e C
It is recommended that a revised Headquarters Notice be prepared
and promulgated, pursuant to the findings and direction of this EXCOM.
In order to avoid lengthy staffing delays, it is recommended that that
notice be part of the findings documentation.
ILLEGIB
Approved For Release 2 0 F 49kV90R000400030010-2
 Approved For Release 2003/06/20 : CIA-RDP84B0089OR000400030010-2
NONFIDFNTIAL'
Policy and Procedures for Management for Information Systems
A. PURPOSE
This document is to set forth Agency policy regarding
management responsibilities for the acquisition of new or
enhanced Information System capabilities.
B. APPLICABILITY AND SCOPE
The provisions of this document apply to automated or other
clearly identifiable processes used for creation, movement,
use; storage, retrieval, or dissemination of intelligence and
management information. Included are ADP hardware and
software systems, communications sytems, terminals, word-
proces'sing, printers and copiers, image processing and
,display, and collection systems.
C. POLICY
1. General
Information System acquisitions shall be reviewed and
approved at decision milestones by appropriate management
levels. Systems of extraordinary cost, risk, or interest
shall be reviewed by the EXCOM; the Information Handling
Systems Architect (IHSA) and the Program Management -.-
Component shall support the EXCOM review process.
Information Systems falling below the EXCOMeview
threshold, but nevertheless important in the. context of
Agency Information Systems Architecture and Planning, may
be reviewed by the IHSA at decision milestones.
2. Specific
For purposes of management and coordination there are
three classes of information systems, determined by
investment cost thresholds. Class I and II systems shall
comply with the procedures, standards, and documentation
requirements for major programs. Class III programs
shall comply with the procedures, standards and
documentation requirements for minor programs.
Approved For Release 20p3/,q/, 0, ? cIA-RDP84B04,$?90R000400030010-2
10 NITY A -V'
 Approved For Release 2 3 /20 : CIA-RDP84B00890R000400030010-2
5FIDENTIAU
a) Class I Informations Systems shall be reviewed and
approved at decision milestones by the EXCOM. Any
Information System, or any significant revision of an
existing Information System, meeting any one of the
following criteria shall be designated a Class I
.Information System:
i) Has anticipated acquisition costs in excess of
$8 million during the span from program
initiation to the time the system becomes
operational; or
ii) Has estimated costs in excess of $2 million in
any year; or
iii) Is designated as being of special interest.
.iv) Information Systems which do not meet the
criteria for Class I Information System
designation, but which are considered to have
Agency-wide or community importance shall be
reviewed and approved by the IHSA. In
particular, a number of information systems of
similar character, but less than Class. I
threshold, may be aggregated and considered as
a Class I system. Review procedures used for
such Class I systems will be tailored as
appropriate by the IHSA.
b) Class II Information'Systems shall he reviewed and
approved at decision milestones by the Deputy
Director responsible for the system. Any Information
System, or any significant revision of an existing
Information System, meeting any of the following
criteria shall be designated a Class II`tlnformation
System:
i) Has anticipated acquisition costs in excess of
$1 million during the year from program
initiation to the time the system becomes
operational; or
ii) Has estimated acquisition costs in excess of
$250,000 in any year; or
iii) Is designated as being of special interest.
c) Class III Information Systems shall be reviewed and
Approved For Release
 Approved For Releases,a3 ,26~NRDP84B0089OR000400030010-2
TIAL
approved as the responsible Deputy Director may
direct. In general, it is anticipated that he will
delegate that authority-to the next lower level of
management. Any information system, or any
significant revision of an information system which
is in cost or importance less than Class II is a
Class III system.
d) For the purpose of estimating acquisition costs the
value of one person-year of professional effort will
be $100,000 regardless of the sources.
Milestone Decisions
Three milestone decisions are defined for acquisition of
Major Information Systems.
o Milestone 0 Decision -- Approval of Mission Need
Statement approval of the budget and schedule,
and authorization to proceed to the next program
phase. The Mission Need Statement shall define
the need for the system, and shall be
accompanied by Preliminary System Requirements,
acquisition strategy, schedule goals, and the
total and annual investment of resources
estimated. The next program phase for a simple
package (no program development investment,
e.g., a computer with standard support software)
is the actual procurement, or for a complex
system development. The next phase is the
Concept Development Phase.
o Milestone 1 Decision -- Approval of the System
Design Concept, System Requirements, and Program
Development Plan; and authorization to proceed
with the next program phase. Forllarge complex
systems, alternate concepts are to be explored
and evaluated before settling on a chosen
concept, the reasons for a particular selection
are to be presented. Documentation at this
stage shall include baseline System
Requirements, System Design Concept, and a
Program Development Plan. System requirements
will be accredited by the IHSA. Cost and
schedule goals are reassessed. Equipment plans
are presented for approval, and acquisition of
fully designed, commercial hardware will
normally be executed pursuant to this approval
Approved For Release 200
4ll JOR000400030010-2
 . Approved For Release 2(!Of4PI MR1TX890R000400030010-2
or direction. Approved programs then proceed to
the Preliminary Design Phase.
o Milestone 2 Decision -- Approval of the
Preliminary Design and Revised Program
Development. All acquisition programs, however
phased, will have a single Preliminary Design
Review (PDR) covering the entire program. This
review is coordinated with the program's
internal PDR so that issues arising as a result
of the PDR process can be evaluated. At this
milestone review the program cost,
functionality, and schedule objectives,
primarily as defined and determined at the PDR,
are reassessed. Approved programs then proceed
to full-scale development.
At each decision milestone, guidance and direction to
the program are documented.
At any point at which a program deviation in cost or
schedule goals of more than 15 percent is estimated,
the IHSA will be notified. He may, at his discretion
convene an ad hoc review of the project status.
4. Procedures
At least six months prior to Milestone 1 or 2 review of
Class I and II systems the program sponsor will notify
the IHSA. For Class I systems, the IHSA will coordinate
and schedule an EXCOM review.
The IHSA will appoint a member of his staff to
coordinate with the program office concerning
preparation for the.Milestone review. The program
office will brief the IHSA office with respect?to the
program status for Class I and II systems.''Questions
which the office of the IHSA has with the project will
be addressed to the project management. The intent is
to resolve all the questions that pertain to such
matters as the project formulation, completeness of
planning and design, interoperability, conformity with
standards, and supportability prior to the Milestone
review.
Shortly prior to the review, the IHSA will prepare brief
point papers covering any points of concern or
disagreement relative to the information system's
Approved For Release
867 O~ V JP8 4BOO89OR000400030010-2
 Approved For Releas 0890R000400030010-2
development. Approximately one week prior to the EXCOM
Milestone review of Class I systems, the IHSA will
prebrief the EXCOM concerning unresolved issues and
concerns. The project management will then brief the
EXCOM on the system at the Milestone review. The IHSA
will then prepare a decision coordinating paper
documenting the EXCOM guidance and direction to the
project.
For Class II systems, if the IHSA feels that there are
significant architectural concerns, he may join the
Milestone review. If those concerns still remain
following the review, the IHSA may schedule an EXCOM
review.
5. IHSA Responsibilities
The Information System review process is the management
compliment to the budgeting process. Information System
decisions must fit into the affordability framework of
the budget, and further, must fit into the Agency
architecture and planning framework for Information
Systems. In that context specific IHSA responsibilities
include:
a) Formulating overall architecture tenets for
Information Systems
b) Conducting formal reviews of proposed
Information Systems to:
o Accredit requirements
o Determine compliance with architecture
tenets
o Validate Functional Requirements
o Validate System Concept
o Ensure that relevant interfaces are
considered
o Validate information security of proposed
design
c) Advising on relative priorities of Information
Approved For Relea?e 0 IT;QJ
EWX6 00890R000400030010-2
 Approved For Release 2003/06/20 : CIA-RDP84B0089OR000400030010-2
CONFIDENTIAL'
Systems
d) Focusing the issues for EXCOM reviews
e) Making an annual report to the EXCOM on the
status of IHSs in the Agency and advising EXCOM
on Information Systems decisions
f) Designated individual for the Agency assuring
compliance with government-wide standards and
procedures. Included is assuring Agency
compliance with Federal Information Processing
Standards, or granting waivers these to in
accordance with delegated authorities and
specified procedures.
ILLEGIB
CONP
Approved For Release 2003/06/20 : C17.-DP841300890R000400030010-2