SAFE ADPE PROCUREMENT ISSUE: THE VALUE OF COMPATIBILITY WITH EXISTING ODP HARDWARE/SOFTWARE

• Document Type: CREST
• Collection: General CIA Records
• Document Number (FOIA) /ESDN (CREST): CIA-RDP84-00933R000500020001-6
• Release Decision: RIPPUB
• Original Classification: K
• Document Page Count: 79
• Document Creation Date: December 12, 2016
• Document Release Date: November 26, 2001
• Sequence Number: 1
• Publication Date: October 3, 1979
• Content Type: REPORT

Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
The Value of Compatibility with Existing ODP Hardware/Software
STATINTL
CSPO/ODP
3 October 1979
DRAU~
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08: CI F 0933R000500020001-6
SAFE ADPE Procurement Issue:
0 3 O CT 1979
The Value of Compatibility with Existing ODP Hardware/Software
I. Scope
IT. Introduction
III. Overview of the Study
lV. Value of Compatibility
V. Summary and Conclusions
Vi. References
VII. Notes on Terminology
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Note to Reader
1. For an overview of the study, it is recommended that the
reader begin with Part I, "Purpose and Scope", followed by
Part V, "Summary and Conclusions."
2. It would be useful for readers to review Part VII, "Notes
on Terminology" before addressing the remainder of the study
to familiarize themselves with certain study terminology and
concepts that may be both unusual and confusing.
3. Footnotes and Appendixes are either at the end of a
Part, or in Part IV, at the end of each cost element. Footnotes
for tables are on the table page itself.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Part I: Purpose and Scope
Compatibility with existing ODP hardware/software
implies IBM compatibility. This study, however, does not
address the disadvantages or advantages of IBM architecture,
hardware or software, either in a technical or cost sense.
Technical and cost evaluation are more appropriately performed
during a formal evaluation of vendor proposals submitted in
response to an RFP. This study addresses the impact of
compatibility on ODP management and resources; the fact
that the common architecture is IBM is not significant.
This ODP internal impact is primarily due to factors such as
the greater possibility for resource sharing with a common
ODP architecture. Generally speaking, it is difficult to
structure an RFP to include these factors. (1)
It should be emphasized at the outset that this study
addresses only the compatibility of the CIA SAFE system with
ODP. A counterpart study on the value of DIA compatibility
is in progress. Since SAFE ADPE will be common to both CIA
and DIA, until the two studies are reconciled, no final
"value of compatibility" can be derived.
It is hoped that this study will serve to clarify the
value of compatibility in terms of aggregate cost savings
and other qualitative factors. This value must only be
interpreted, however, in terms of an overall assessment that
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
includes procurement issues, technical, management/administrative
and cost factors. For example, there may bean overriding
technical reason for preferring one architecture over the
others or the cost savings associated with a specific architecture
may overwhelm any cost savings associated with compatibility..
The required overall assessment should, in most cases, take
the form of a formal evaluation of vendor responses to an
RFP.
Examples of external factors explicitly excluded from
this study which are often associated with the common architecture
concept but in fact are attributes of a specific architecture
(e.-g., IBM) are: the potential for multi-sourcing and the
availability of a very large commercial software base. This
study makes no effort to evaluate the truth of these assertions
or their impact. Such an evaluation, if appropriate, should
be done as part of an overall evaluation, since the factors
described are not related to compatibility.
Finally, no effort has been made to evaluate the impact
of Federal Information Processing Standards 60-63, which
deal with I/O interface standards and have the practical
impact of restricting most future procurements to mainframes
that function with IBM-compatible peripherals. These standards,
which come into effect during FY-80, may have a profound
impact on the SAFE
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
ADPE procurement. The existence of these standards is an
external factor and not associated with compatibility. it
should be noted, however, that an IBM-compatible architecture
will in fact meet the standard. It is not known at this time
whether vendors of other mainframe architectures will have
offerings that also meet the standards.
How, in a practical sense, should the results of this
study and its DIA equivalent be used? First, a unified ODP-
CSPO-DIA position on the "value of compatibility" must be
arrived at. This value will have to be assessed as to whether
it is an overriding factor or just another factor to be
considered in the formal procurement evaluation. This decision
as to whether it is an overriding factor is a critical one.
Such a decision would be made if it were believed that the
value of compatibility was so significant that the outcome
of the procurement was, in effect, predetermined (at least
as far as architecture). The purpose of restricting the pro-
curement explicitly would be to avoid "exercising the market-
place." Of course, any restriction of the procurement would
have to be made only after the responsible individuals con-
vinced themselves that the case for the value of compatibility
was absolutely compelling and it would be unrealistic to
believe that a high score in other evaluation criteria could
overwhelm the compatibility weight. The above is definitely
not meant as an argument for restriction of the procurement.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
In fact, in a procurement such as the SAFE ADPE, which is in
the nature of a new start, a very strong case indeed would be
required to restrict the procurement. It must be remembered
that the government routinely is expected to absorb very
heavy costs in the interests of open competition in the ADPE
arena (e.g., software conversion costs, in particular assembly
language code).
If a decision is made that the value of compatibility is
not overriding, or that issues of procurement policy require
that the procurement not restrict architectures, a method must
be developed to "fold-in" the value of compatibility to the
formal proposal evaluation. This will be a part of the overall
SAFE ADPE procurement stretegy which is currently under
development.
(1) Suggestions on how to directly integrate at least some
ODP internal factors into the RFP are provided in the detailed
discussion (see Part IV).
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Part II. Introduction
ODP operates two major centers in the Headquarters
complex: the Ruffing Center and the Special Center. Both
centers are compatible in terms of hardware and system
software. It is commonly believed within ODP that this
compatibility between centers permits significant cost savings
and provides management and operational benefits. The CIA
SAFE computer center is scheduled for IOC in 1982. It is
reasonable to ask what cost savings and benefits could be
achieved if SAFE were required to be compatible with the
existing ODP centers. The purpose of this study is to examine
the issue of cost-savings and benefits associated with SAFE
compatibility. Our goal would be to quantify the value of
SAFE compatibility in dollar terms for use in the evaluation
scheme of the SAFE hardware and system software competitive
procurement. The final derived "value of compatibility"
could be, for example, added to the cost of any proposed system
that was non-compatible in an analogous manner to the handling
of software conversion costs in proposal evaluation. It is
believed that this approach is. fair to both the marketplace,
in that it permits an unrestricted procurement, and fair to
the government, in that real-world government costs and
benefits are evaluated.
In the next section, an attempt is made to arrive at a
definition of compatibility that is suitable for our purposes.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
The remainder of the study is devoted to a discussion of the
impact of compatibility and an attempt to measure this impact
in dollar terms, where possible.
Definition of Compatibility
The aspects of compatibility we are concerned with are
those that enhance the possibility that ODP Ruffing Center
and Special Center resources (staff and equipment) are shareable
by SAFE at little or no additional cost. Examples of the
support ODP resources could provide that would be facilitated
by compatibility are operating system support, processing
support and trained staff both on a regular and reserve (i.e.,
backup) basis. Another possibility for benefits is from
consolidated procurement of compatible hardware and software.
Four levels of compatibility have been identified that
would affect the opportunities for resource sharing. These
are defined below in order of increasing compatibility. It
should be noted that these four compatibility states represent
a vastly oversimplified view of a compability situation that
has a multitude of possibilities.
1. Non-Compatibility (N/C)
Non-compatibility is defined as SAFE mainframes
that are not IBM-compatible (i.e., non-compatible
mainframes are therefore those that do not utilize
the IBM 370 series instruction repertoire). With
one minor exception, ODP mainframes in the Ruffing and
ApproS' d gel tM2/01M :T( 14 Q**I9BM00M00020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
2. Hardware Compatibility (H/C)
SAFE mainframes are IBM-compatible, do utilize
the IBM 370 series instruction repertoire as ODP
mainframes in the Ruffing and Special Centers do.
3. Hardware/Software Compatibility (H/S/C)
SAFE mainframes are IBM-compatible and SAFE
operating system software is an ODP-supported
IBM operating system (currently, MVS or YM).
4. Full Compatibility ('/C)
SAFE mainframes are IBM-compatible; operating
system software is ODP-supported (i.e., currently
MVS or VIA) and the SAFE primary DBMS is an
ODP-supported DBMS (currently GIM II).
In both the system software and DBMS areas,
the requirement for ODP support is significant,
since the depth of support is a measure of the
available ODP resources that might be utilized by
SAFE. For example, if SAFE mainframes are HIS
compatible with. ODP it would be generally possible
to run the same DBMS on either. Some benefits
would accrue from this possibility (.e.g., in the
backup area). However, if ODP does not support
the particular DBMS, no in-place system programming
or system engineering expertise would routinely be
available. Thus to obtain maximum benefits from
operating system and DBMS compatibility, supported
systems are required.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
The above compatibility definitions referred to SAFE
mainframes as if they all were to have similar hardware and
software configurations. This will not necessarily be the
case. The proposed SAFE system architecture involves two
levels of processors: the so-called maxi and midi levels.
Even assuming that all hardware and software is similar and
likewise'all midi H/S is similar, compatibility questions
become very complicated. It is possible to have maxi com-
patibility with ODP mainframes and midi non-compatibility;
maxi and midi compatibility with ODP mainframes (though of
varying types -- e.g., different O/S or DBMS); or less likely,
maxi non-compatibility and midi compatibility.
In short, even in our simplified model of the compatibility
situation, there are sixteen possibilities. The most likely
possibilities are summarized below. (2)
Maxi Midi
N/C N/C
H/C H/C
H/S/C H/S/C
H/C H/S/C
H/S/C H/C
Each one of these situations presents different opportunities
for resource sharing.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Footnotes to Part II
(1) The TADS computer, an IBM 360/67, is the minor deviation
from full IBM 370-series compatibility.
(2) There are sixteen possibilities, since there are four
compatibility situations each, for both the maxi and midi.
Five states may be singled out as most likely under the
following assumptions: 1) the SAFE maxi and midi may be
required to have a homogeneous architecture to minimize the
complexity of software development. 2) full compatibility
for either the midi or maxi is unlikely due to GIM II's
apparent non-suitability for SAFE.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Part III: Overview of the Study
The Compatibility Issue
This study attempts to estimate the impact, in cost terms,
of a non-compatible CIA SAFE system. Non-compatibility, as used
herein, refers to a SAFE system that is not hardware (and there-
fore not software) compatible with the ODP Ruffing and Special
Centers. This is equivalent to a SAFE system that is not con--
figured with IBM or IBM plug-compatible mainframes. (It should
be noted that the SAFE mainframe architecture has not been
selected at this writing and it is the purpose of this study to
assist in the selection by clarifying the value of compatibility.
Part I, "Purpose and Scope" expands upon this point.)
As discussed in Part II, "Introduction," the compatibility
issue gets very complicated very quickly as there are numerous
possibilities caused by two levels of SAFE mainframe hardware
and the several possibilities in the area of operating system
software. For the purposes of this impact analysis, costs will
be derived that quantify the difference in impact to ODP between:
( Homogeneous SAFE Midi & Maxi HIS
(
HIS Compatible SAFE: ( IBM or IBM Plug-Compatible Hardware
( ODP-supported Operating System
(i.e., VM or MVS)
Non-Compatible SAFE: ( SAFE Midi & Maxi are not IBM or
IBM Plug-Compatible
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 ? Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
In order to simplify the analysis,the assumption has been
made that SAFE will fall into one of the categories above.
Mixed modes have therefore been ignored (e.g., heterogeneous
midi and maxi; non-ODP-supported 0/S, etc.). This assumption
is believed to be realistic.
The Model
In thinking about the impact of a non-compatible archi-
tecture on an organization such as ODP, we have chosen to
organize our thoughts around a specific "model." From the
viewpoint of this model, a non-compatible SAFE architecture
implies a "barrier" within ODP. This architecture barrier
impedes the transfer of resources between SAFE and other ODP
centers, as well as the related problem: the transfer of
workload. (Management can either transfer resources -- people,
hardware, software, etc. -- to the "work," or transfer the
workload to the resources -- i.e., load sharing.) Costs must
be incurred in overcoming the architecture barrier or a reduced
capability must be accepted. Examples are systems programming
support and overflow load sharing in a non-compatible environ-
ment. The former can be overcome by providing separate system
programming support in the SAFE center (i.e., for the non-IBM
O/S). The latter workload transfer problem would cause a non--
compatible ODP to, for example, live with a batch backlog
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
(i.e., a reduced capability as compared to a compatible
environment).
Table III summarizes the resource/workload categories
and the detailed areas of non-compatibility impact. Part
IV assesses the impact in each area with an attempt to develop
a cost estimate, where feasible.
The Cost Impact
Costs are derived over the systems life and not the
architecture life. The rationale behind this choice is
discussed in Appendix III. Though the use of evaluated costs
(often referred to as discounted or present value costs) is
technically correct for combining costs distributed over time,
this approach has not been followed. This decision has been
(1)
made because of the time involved in developing these costs
and our belief that the costs developed in this study are
useful as rough measures of aggregate impact only. If the
costs are to be used directly in proposal evaluation, dis-
counted costs will be required. Costs have therefore been
assumed in constant 1979 dollars. Occasionally, costs were
most conveniently developed in FY-79 dollars. For all practical
purposes, FY-79 dollars are assumed equal to 1979 dollars.
(1) Actually, the time involved in updating these costs, as it
is assumed that after discussion, revisions to the costs estimates
will 'inevitably be required.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
TABLE III
Summary Sheet: Cost of Non-Compatibility
with Existing ODP Hardware/Software
Resource/Workload Impact
Category (Cost Element No)
A. Management Expertise A-1: Increased Management Complexity and
Program Risk
B. People B-1: Impact on Personnel Management
B-2: Increased Vendor System Training
B-3: Additional Personnel Requirements
C. Hardware/Software C-l: Limitations on Reconfiguration &
Reutilization
C-2: Unavailability of Emergency and
Limited Disaster Hardware Backup
C-4: Software Exchange Limitations
( Continued)
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
TABLE III
Summary Sheet: Cost of Non-Compatibility
with Existing ODP Hardware/Software (conf.t)
Resource/Workload Impact
Category (Cost Element No.)
D: Technical Barriers to Load Sharing (see following)
D-1: Routine Production Load Sharing
D-2: Routine Development Load Sharing
D-3: Backup Load Sharing (see following)
D-3(a): Overflow Load Sharing
D-3(b): Disaster Backup
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Appendix III: Systems Life vs. Architecture Life
An important distinction can be made between systems
life and architecture life. Systems life, as conventionally
used, refers to the useful life of hardware in support of a
specific service. Architecture life goes beyond system life
and represents the estimated time until a total system
reprocurement (i.e., hardware and software) will be performed.
Typically, at the end of system life, a hardware upgrade
is performed and the replaced hardware is reutilized; soft-
ware, however, is not totally redesigned. The end of archi-
tecture life, as defined herein, implies that software requires a
"bottom-up" redesign due to system deficiencies, the increased
cost of maintenance and/or evolving requirements. A competitive
.reprocurement of the complete system opens up the possibility
of a change in architecture.
For the CIA SAFE project, a 7 year systems life beyond IOC
is assumed. For the architecture life of SAFE, a fifteen (15)
year estimate, beyond IOC, appears reasonable. In SAFE procure-
ments, the systems life estimate will be used. This is because
it is judged unrealistic to estimate most costs and benefits beyond
the limited systems. life. For example, major hardware upgrade
costs, mainframe costs, and other support costs are exceptionally
difficult to estimate in out-years. Vendors are reluctant to make
proposals over extended time periods. Systems life, however, (e.g.,
to the first major mainframe upgrade) appears a reasonable period
of ti ApprooveedvFor e easiotbb1/0 } - - - 3i @Mbogg2( V~i been
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
historically willing to bid over this limited time period.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Part IV. Value of Compatibility: Cost and Impact Breakdown
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Cost Element Increased Management Complexity and
Program Risk
Cost Qualitative Factor
Discussion
A non-compatible SAFE system would involve an architecture
unfamiliar to the majority of ODP Management. In addition to
the "new" architecture aspects, ODP would become a multi-
architecture operation which by itself increases management
complexity.
This added complexity in a multi-architecture environment
is related to what is, in effect, a barrier inherent in archi-
tecture differences. This barrier inhibits or even prevents
the transfer of resources (i.e., people and hardware/software)
between SAFE and other ODP centers. The alternative to resource
transfers, the transfer of workload, is generally speaking also
impractical in a multi-architecture environment.
These constraints make management more difficult. Resources
assignd to one architecture are generally not shared, limiting
the usefulness of any resource "slack" or "cushion" available
in the office. This requires better planning by management
than would otherwise be required. The margin for error is
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
smaller and the risks are therefore higher. These risks are
diminished capability and a resulting impact on mission
effectiveness.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
COST OF NON-COMPATIBILITY
Cost Element No: B-1
Cost Element Impact on Personnel Management
Cost Qualitative Factor
Evaluated Cost
Discussion:
SAFE non-compatibility would present both advantages and
disadvantages in the personnel management area.
o Advantages.
With a non-compatible SAFE, ODP would be supporting at
least two distinct mainframe architectures. This would provide
new challenges and opportunities for ODP personnel. Breadth
of experience is an asset for a data processing professional.
It can also be conjectured that a multi-architecture
environment expands our recruiting pool in that 1) prospective
employees with experience in either the ODP- or SAFE-supported
architecture could more quickly contribute and therefore more
easily be cost-justified and 2) the breadth of experience
available in a multi-architecture environment could be a
recruiting incentive.
o Disadvantages.
In a multi-architecture environment transfer of personnel
between SAFE and ODP Processing would be a more complicated
problem than with a single architecture:
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
a. Considerable training would be required (see Cost
Element B-2)
b. Productivity of transferred personnel would initially
be lower even after training
c. The pool of experienced people will be smaller.
d. A reluctance of management to transfer personnel to
work with a different architecture because of the drop
in productivity. This constrains utilization of personnel
resources.
e. A reluctance of personnel to transfer to a position
that requires familiarity with a different architecture
.e., "fear of the unknown").
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Roil ZQ02M CgAp @8 ,q0 33R000500020001-6
Cost Element No: B-2
Cost Element . Increased Vendor System Training
Cost . $440K
Evaluated Cost :: -
Discussion
If SAFE is non-compatible with ODP, SAFE personnel, who
will primarily come from the current ODP organization, will
require intensive training on SAFE hardware and operating
systems (i.e., the vendor system), in addition to SAFE appli-
cations training.
Table B-2 provides an estimate of minimum SAFE Government
professional/technical personnel post-IOC. The figures are
a modification of current CSPO estimates. (1)
Other personnel requiring SAFE vendor systems training
will be ODP backup personnel. These ODP personnel are cross-
trained in SAFE hardware and software and primarily have other
ODP functions but serve as SAFE backup when required. The
number of ODP backup personnel is also estimated in Table B-2.
Analysis
The Cost of Non-Compatibility is the cost of training in
the new vendor hardware and operating system(s), SAFE personnel
and ODP backup and their replacements over the systems life.
To-tal personnel to be trained pre-IOC is 60 (44 SAFE and 16
backup, from Table B-2). An estimated 10 percent or 6 new
personnel annually will require similar training throughout
Approved For Release 2002/01/08': CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
the systems life (2)
The vendor system training required is estimated as 20
days/trainee ( = 160 hours/trainee). The direct cost of this
training is further estimated as $100/day. The total direct
training cost is therefore $2000/trainee.
During training, the employee is assumed compensated at
(3)
the current FY-79 ODP average annual salary of $21.37K,
prorated over 160 hours of training (.of 2080 available annually)
(_4)
and adjusted for 40% government burden.
Employee compensation during training
($21.37K X 1.4 X 160/20801 = $2.3K
The Cost of Non-Compatibility in the area of vendor system
training is the total training cost, which is: (No. of Trainees) X
(Direct Training Cost + Employee Compensation during Training).
For Pre-IOC training, this cost is:
60 X ($2K + $2.3K) _ $258K
For training of replacements during the systems life (7 years),
the cost is:
7 X 6 X (_$2K + $2.3K)= $181K
Therefore, the estimated systems life cost for vendor systems
training is ($258K + $181K) = $439K
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
(1) Reference 2 includes an estimate of CIA SAFE personnel
requirements. It indicates that 36 CIA SAFE "operations"
personnel will be required, but excludes some (unspecified)
software and engineering support to be done jointly with DIA.
An additional 8 personnel ("Enhanced SAFE Staff") have been
included in Table B-2. The functions of these additional
personnel,though not directly addressed in Reference 2, appear
to be most suitable for performance by government personnel.
The resulting staff of 44 is considered for our purpose a
minimum government level.
It should not be inferred that the 44 personnel will be
slotted in the SAFE Operations Group or even ODP (e.g. security
personnel may be from the Office of Security). The 44 personnel,
in fact, exceed the 33 ODP slots estimated for the SAFE
Operations Group (See Reference 3) and the overall staffing
estimate in the Consolidated SAFE Requirements Document (CSRD),
Reference 1.
(2) Assumes 20 percent replacement rate of which half or
10 percent require vendor system training. It is assumed the
other 10 percent has vendor systems expertise through prior
training or experience.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
(3) From C/P&BG/MS/ODP.
(4) 26% Standard Fringe Benefit Factors with 11% (est.)
CIA G&A, see Reference 5, pages 24 & 44-49. Rounded to 40%.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Table B-2
r-----~v?o v+.vup ersonnei
avpd
possibl
ap
S
4
i
4n
~
6p
y
i
y
i
--k Yar
n
g
' ~nt
er oonnel-in-these categories
Estimated Minimum SAFE Government Personnel Requirements (Post-IOC)
Job Category
No. of Govt. Professional/Technical Personnel
Enhanced - - ~~
No. Title
SAFE Operations Group (1) ODP Backup _-+
,A;
Operations
-
-
A.1
Operations
21
5
A.2
Performance Mgmt.
1
1
A.3
Facilities/Config, Mgmt.
1
2
B.
Maintenance
-
B.l
Hardware Mnt.
1
2
B.2
Software Mnt.
-
-
a)
Systems Mnt. (Vendor)
2
0
b)
DBMS Mnt.
1
0
c)
SAFE Mnt.
2
0
C.
Administration
-
-
C.1
Project Office Admin.
4
0
C.2
Database Admin.
3
0
C.3
Security (1)
2
1
D.
Development (1)
D.l
Systems Eng. (Planning
1
1
D.2
pplications Dev.
2
3
E.
Training/Documentation(l)
-
-
E.1
User Training
2
0
E.2
System Training
0
0
TOTAL
44
16
e62 (except
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
COST OF NON-COMPATIBILITY
Cost Element No: B-3
Cost Element Additional Personnel Requirements
Cost $4090K
Discussion
In an H/S compatible environment, certain ODP Processing
personnel could provide common support to both Processing and
SAFE; these personnel are referred to as shareable. With a
non-compatible SAFE, the common support of shareable personnel
is not available and an increase in SAFE personnel requirements
would result.
Shareable Personnel resources are defined as those ODP
professional or technical personnel (staff or contractor)
supporting on-going ODP Processing activities whose work is
directly applicable to SAFE at little or no additional cost.
An example would be systems programming support in an H/S
compatible environment.
The architecture barrier present with a non-compatible
SAFE interferes with the transfer of the work product of these
Shareable Personnel. To make up for this loss, an equivalent
number of personnel must be included as part of overall SAFE
personnel requirements. It should be emphasized that these
personnel are not the full complement of SAFE staff but are
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
additional to those that would otherwise be required in an
HIS compatible environment. Additional Personnel for
Non-Compatible SAFE are therefore defined as the estimated
ODP staff or contractor personnel required to support a non-
compatible SAFE minus estimated ODP personnel required to
support an HIS compatible SAFE. In this analysis, the difference,
i.e., the number of Additional Personnel for Non-Compatibility
is assumed equal to the Shareable Personnel in an HIS compatible
environment.
Analysis
Table B-3 presents an estimate of the Additional Personnel
for Non-Compatibility (= Shareable Personnel in an HIS compatible
environment) by job category. An estimated total of 13 addi-
tional personnel are required annually in a non-compatible
environment throughout the systems life. In fact, it may be
argued that these additional personnel will be required through-
out the architecture life. (Architecture life, as used herein,
extends beyond systems life, to the time of system total re-
(1)
procurement or redesign: i.e., an estimated 15 years).
Since the goal of this analysis is to develop assessments
suitable for use in proposal evaluation, the cost estimate is
limited to the systems life (.7 years).
In Appendix B-3, an average annual cost for the 13 addi-
tional personnel is computed as $584K. This represents the
cost of funding 13 positions at an approximate average govern-
ment-contractor salary. Over the 7 year systems life, this is
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
$4090K (undiscounted). Thus the estimated cost of non-
compatibility in the area of personnel requirements is
$4090K (1979 dollars).
(1) See Appendix III, Part III: "Architecture Life vs.
Systems Life."
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Table B-3: Estimate of Additional Personnel for Non-Compatible SAFE
Additional Personnel
Job Category
for Non-Compatible SAFE
Comments
(=Shareable Personnel
(Comments below refer to difference in personnel requirements
No.
Title
w/ H/S Compatible SAFE
between Non-Compatible SAFE and H/S Compatible SAFE)
A.
Operations
A.1
Operations
2
Technical Specialists required for SPD/OD interface
A.2
Performance Mgmt.
1
(Already available for current IBM O/S's)
Additional person for new architecture.
A.3
Facilities/Confi M mt
g' g
1
(Large body of expertise in ED/SEB on IBM H/S)
.
Additional Config. Mgr. for new architecture.
_
- --'------- - -_ _- -'--^--
B.
Maintenance
B.1
Hardware Mat.
2
IBM-compatible vendor interfaces being managed by existing staff.
Additional staff required for new vendor interfaces associated w/
B.2
Software Mnt,
new architecture.
a)
Systems Mot. (Vendor)
6
SPD currently performs this function for IBM 0/S's; new
b)
DBMS ti
systems programming group would be required.
nt.
*
c)
SAFE tint.
*
C.
Administration
C.1
Project Office Admin
*
Additional person T-or new architecture. -Large To-dy of expert se n
.
ED/SEB on IBM hardware; consolidated planning/procurement possible
C.2
Database Admin.
*
in H/S Compatible environment).
C.3
Security
D.
Development
7.1
Systems Eng. (Planning)
1
D.2
Applications Dev.
*
E.
Training/Documentation
E.1
User Training
*
E.2
System Training
*
E.3
Tech. Writing
TOTAL
13
- -- -
*Compatibility is not judged to have an impact on personnel
requirements.
Approved For Release 2002/0/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 C_d% P 4-009338000500020001-6
Cost of Non-Compatibility: Cost Element B-3
APPENDIX B-3
Cost of Additional Personnel
Required to Support a Non-Compatible SAFE
TABLE 1: Computation of Average Salary of Additional Personnel
Govt. Grade
FY-79
Govt. Salary
(1)
Burdened
Govt. Salary
(2)
Contractor
Salary
(3)
Avg.
Salary
(4)
GS-11
21.8K
30.5K:
43.6K
37.1K
GS-12
26.2K
36.7K
52.4K
44.6K
GS-13
31.1K
43.5K
62.2K
52.9K
(1)
Assuming Step 5
(2)
40% burden added to FY-79 Govt.
Salary
(3)
100% burden added to FY-79 Govt.
Salary
(4)
Average of Burdened Govt. Salary and Contractor Salary
Approved For Release 2002/01/08 : CIA-RDF8400933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Cost of Non-Compatibility: Cost Element B-3
Appendix B-3 (continued)
Annual
Est.
FY-1979
Job Category
Additional
Equivalent
Avg. Salary/
Annual
Personnel
Govt. Grade
Person
Cost
F No.
Title
A.l
Operations
2
GS-11
37.1K
74.2K
A.2
Perf. Mgmt
1
GS-13
52.9K
52.9K
A.3
Facilities
1
GS-11
37.1K
37.1K
B.l
Hdwre. Mnt.
2
GS-11
37.1K
74.2K
B.2a
Softwre. Mnt.
6
3 GS-13
52.9K
158.7K
(Systems)
3 GS-12
44.6K
133.8K
D.1
Sys. Eng.
1
GS-13
52.9K
52.9K
13
GRAND TOTAL $584K (1)
(1) Annual cost of 14 additional personnel, in FY-79 dollars.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Cost Element Limitations on Reconfiguration and
Reutilization
Cost $490K
Discussion
If the SAFE Center were non-compatible with other ODP
centers, the transfer of hardware between centers would generally
be impossible. Reconfiguration between centers includes the
temporary transfer of equipment for test purposes and the per-
manent re-allocation of equipment to satisfy higher priority
requirements, improve performance and balance workload.
Reutilization occurs when the requirement in one center for
a hardware item no longer exists (i.e., equipment reaches the
end of its systems life). Opportunities for reutilization
would then be explored within ODP (and throughout CIA) prior
to release to GSA as excess to agency needs. Reutilization
is really a special form of reconfiguration in which the equip-
ment has reached the end of its systems life due to capacity
limitations or technological obsolescence.
Reconfiguration and reutilization (R/R) are currently
routine activities within ODP. R/R is distinguished from
(1)
emergency and (limited and full) disaster backup in that
R/R is for long-term service improvement or configuration test.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Analysis
A rough bound on the value of reutilization with an H/S
compatible SAFE may be computed under the following assumptions:
(1) SAFE Center hardware will not be reutilized (in another
ODP center) until the end of systems life (by definition).
(.2) Unlike the other ODP centers, the SAFE Center will
support a single high performance service; equipment that has
reached the end of its systems life in the Ruffing or Special
Centers will, generally speaking, not be suitable for SAFE
operations for performance reasons.
(3) Excluding workstations and printers, an estimate of
the purchase price of the CIA SAFE IOC configuration is
$6023K (1979 dollars). (See Appendix C-1).
At the end of the systems life, it is estimated that the
residual value of the SAFE hardware is 10% of the initial pur-
chase price: i.e., 10% of $6023K or $602K. Furthermore, it
is assumed that at the end of systems life, 50% of the SAFE
equipment (by value) can be reutilized. Therefore, a rough
estimate of the value of reutilization is 50% of $602K or
approximately $300K.
(1)
A similar approach may be used to bound the value of re-
configuration. The following assumptions are made in this
(1) SAFE being a single high priority/high performance
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
service will not divert any hardware prior to the end of
systems life for use in other ODP centers (and thereby suffer
degradation in SAFE performance).
(2) At the midpoint of systems life, SAFE hardware (ex-
cluding workstations and printers) is valued at 50% of the
purchase price or $3012K. It is furthermore assumed that 25% of
the SAFE equipment (by value) is swapped for higher performance
Ruffing or Special Center equipment. This swapping (i.e.,
reconfiguration) results in a 25% increase in SAFE equipment
capacity and no significant degradation in ODP service per-
formance (as distinguished from equipment performance).
In line with the assumptions above, at the midpoint of
systems life, reconfiguration provides a 25% increase in
equipment value for 25% of the equipment, or: .25 X .25 X
$3012K = $188K. Thus the value of reconfiguration may be
roughly estimated as $188K.
This admittedly is a crude approach that assumes no loss
of value in the ODP centers receiving presumably lower per-
(2)
formance equipment.
The net value of reconfiguration and reutilization is
$188K + $300K = $488K (1979 dollars). This figure should be
taken as a rough guide only.
(1) Theoretically, residual value is a government-wide (not
agency-specific) concept. Therefore, SAFE hardware will have
an estimated $602K residual value independent of whether
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
reutilization in ODP or the Agency is possible: i.e., the
value accrues to the government not to an agency. (for example,
in a procurement evaluation, residual value is computed for all
hardware irrespective of the real prospects for reutilization
in an agency.) However, the approach followed above, though
conceptually imperfect, does reflect the real-world benefit to
ODP and the Agency.
(2) Another major problem with this approach is that it fails
to properly account for the interaction between reconfiguration
and reutilization. A more detailed analysis was judged beyond
the scope of this study.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Appendix C-l(a)
Estimated Purchase Price of IBM-Compatible
CIA SAFE IOC Configuration (exc. Workstations
and Printers)
STATINTL
STATINTL
The IOC configuration assumes a User Terminal Support
subsystem sized for approximately 600 workstations; the cost
of these 600 workstations (.and associated printers) is
excluded from the estimate. Three approaches are available
for making this estimate:
Approach 1: Use of the Marketplace
Proposals received in response to SAFE ADPE RFP would be
examined. The lowest purchase price for a configuration that
utilized IBM-compatible hardware would be selected.
Approach II: Use of the IBM GSA Schedule
The IBM GAS ADP Schedule would be used to price out the
IOC configuration.
Approach III: Use of the Configuration STATINT
Purchase Price
Proposal (Reference 4(b)) prices out a sample
SAFE IOC configuration using ardware. Table
1, Appendix C-l(b) is the basic cost data. The CIA SAFE IOC
(1)
configuration purchase price is computed to be: $6023K.
Approach I uses competitively-derived prices and is
actually ideal. Prior to proposal evaluation, however, it is
(2)
clearly not possible.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Approach II, use of the IBM GSA ADP Schedule Price List
provides an effective "ceiling" on a true competitively-
derived cost. This approach will not be used because of the
time involved in developing an IBM-compatible configuration.
If more time were available, this could be pursued.
Approach III uses the readily available
figuration costs as an approximation of the cost for the
con- STATINTL
comparable IBM-compatible configuration. For convenience, this
approach will actually be used. Therefore,
The estimated cost of an IBM-compatible-SAFE IOC
configuration, for the purposes of this analysis is: $6023K
(1979 dollars).
(1) Ignoring the DIA subsystem costs, the workstation and
printer costs, and using only half of the User Terminal Support
subsystem (i.e., UTSC--Item 7) cost.
(2) This approach is a candidate for use in the actual RFP
evaluation if the value of IBM-compatibility is actually
"folded-in" to the evaluation.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Appendix C-1 (b)
Estimated Purchase Price and Systems Life Cost of
CIA SAFE IOC Configuration
Table 1: Purchase Price and Monthly Maintenance of CIA
SAFE IOC Configuration. (1)
SAFE
ADPE
Item
Purchase
Amount
Monthly
Maintenance
1
- SCMC
$665.2K
$ 2,523
7
- UTSC x .5
912.6K
3,682
8
- MAPC
694.3K
2,712
9
- DCM 1
3403.5K
12,662
12
- DCM 2
347.1K
1,329
TOTAL
$6023K
$22,908
The systems life cost of the CIA SAFE IOC configuration
(excluding workstations and printers) may be approximated by
assuming a seven year (84 month) systems life for the entire
IOC configuration. Therefore, the (undiscounted) systems life
cost is:
Systems Life Cost = Purchase Price + Systems Life (months)
x Monthly Maintenance
= $6023K + 84 x 22.9K
= $7947K (1979 dollars)
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 STATINTL
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Footnote to Appendex C-1(b)
STATINTL
(1) From M SAFE Cost Proposal,page 5-3 (Reference 4(a)).
hardware configuration; excludes DIA, workstations
and printers and .5 x UTSC cost (UTSC subsystem is downsized
50% to reflect contract vice proposal workstation quantities;
UTSC configuration costed will support 600 terminals.)
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
COST OF NON-COMPATIBILITY
Cost Element No: C-2
Cost Element : Unavailability of Emergency and Limited
Disaster Hardware Backup
Cost : $40K
Evaluated Cost : -
Discussion
An emergency situation for our purposes is defined as an
item of SAFE hardware rendered inoperative for a prolonged
period of time. The problem is due to a routine malfunction
and the delay is due to troubleshooting or parts supply
difficulties.
A limited disaster as used herein is defined as a small
number of SAFE hardware items rendered inoperative due to
fire, flood, explosion, physical damage, etc. Routine equipment
malfunction is excluded. The limited disaster may leave the
SAFE system operative, but in a degraded mode. The equipment
affected will generally require extensive refurbishment or
replacement. In a limited disaster situation it is possible
that hardware could be used from another ODP center. The
equipment transfer could generally be performed sooner than a
vendor replacement could be supplied.
A limited disaster is distinguished from a full disaster
where a major portion of the SAFE Center is damaged and the
SAFE system is inoperative (see Cost Element D-3(b))
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
The above definition also applies to the other ODP
centers with SAFE hardware being used for backup. A non-
compatible SAFE renders emergency and limited disaster hard-
ware backup impossible.
Analysis
The following assumptions will be made in order to
estimate the cost impact of the unavailability of emergency
and disaster backup:
(1) Because SAFE is a high priority/high performance single
service, SAFE hardware will not be available for extended
periods to provide backup for the ODP Ruffing and Special
Centers.
(2) With an H/S compatible SAFE, the extensive hardware
in the Ruffing and Special Centers would be a candidate for
SAFE emergency and limited disaster backup.
(.3) The SAFE backup is assumed required for 10% of the
IOC configuration (by value) for 5% of the systems life (4 out
of 84 months).
The value of the backup required may then be estimated as
5% of the systems life cost of the 10% of the system requiring
backup. An estimate of the IBM-compatible CIA SAFE IOC con-
figuration systems life cost is provided in Appendix C-1(b):
i.e., $7947K. The value of the backup provided by ODP Pro
cessing may be computed by pro-rating this systems life cost:
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Value of SAFE Emergency and
Limited Disaster Backup = .05 x .1 x $7947K
=.$40K (1979 dollars)
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
COST OF NON-COMPATIBILITY
Cost Element Consolidated Procurement
Cost No Cost Impact or Impact can be Evaluated
in Procurement
Discussion
An HIS compatible SAFE opens up the possibility of ODP-
wide consolidated procurement of hardware, software and main-
tenance services. Consolidated procurement E~jy permit
government cost saving through a. favorable vendor pricing
structure stemming from economies of scale. The larger single
vendor hardware/software base possible in an H/S compatible
environment increases government leverage, which may lead to
improved vendor maintenance performance. Another possible
benefit of a larger single vendor base (as compared with a
multi-vendor base that would generally occur in non-compatible
environment) is savings in the total floor space required for
maintenance support and a reduction in total vendor maintenance
personnel (with a savings in attendant security clearance pro-
cessing costs and other government administrative support costs).
Thus an H/S compatible SAFE may lead to:
1) ODP-wide consolidated hardware procurement encompassing
larger quantities of equipment than separate procurements
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
as would generally be required in a multi-architecture
environment.
2) Consolidated maintenance contracts covering larger
quantities of equipment than would be the case in a
multi-architecture environment. Miscellaneous resource
savings (space, etc.) due to the possibilities of a large
single vendor base and improved leverage over the
maintenance vendor.
3) Consolidated software procurements covering the pur-
chase, licensing and maintenance of multiple copies of
software.
Analysis
Assessing the government cost savings in the above situations
is a complex problem that is significantly related to procurement
policy and practice. ODP experience indicates that vendor
pricing has not been overly sensitive to volume except for
some hardware procurement situations and some software licensing
agreements.
Typically, vendor GSA ADP Schedules show purchase and
maintenance prices on a "per box" basis and software licensing
(1)
and maintenance on a "per CPU" basis. Furthermore, assumptions
about savings from vendor volume discounts are probably true
within a specific vendor's pricing structure; however, between
vendors, actual price comparisons are required.
(2)
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
That being the case, loss of consolidated procurement,
through non-compatibility, will have an unknown cost impact.
Assuming cost benefits to be associated with consolidated pro-
curement would be an example of "prejudging the marketplace."
The SAFE procurement itself can be used to determine vendor
pricing practices by requiring vendors to propose the hardware/
software and maintenance services required over the systems
life. No marketplace inferences need or should be made
(3)
external to the initial SAFE procurement.
In a non-compatible environment, volume discounts through
consolidated procurements and maintenance, and benefits-due
to a large single vendor base would, generally speaking, not
(4)
be possible. The impact of the loss of these savings and
benefits is assessed in more detail below:
1) Consolidated Hardware Procurements. Consolidated
hardware procurements require H/S compatibility and
common requirements. The SAFE hardware covered in
the existing SAFE contract will be procured independent
(5)
of ODP Ruffing Center and Special Center requirements.
Presuming H/S compatibility and common requirements,
subsequent procurements, as yet unspecified, could be
consolidated. These procurements would most likely
(6)
involve peripherals, primarily disks and terminals.
Currently quantities are unknown on both the SAFE
and ODP Processing sides.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
As discussed earlier, though favorable pricing for a
consolidated procurement is a reasonable assumption,
it is far from a certainty. Use of anticipated cost
saving from unspecified future consolidated procure-
ment as a factor in an RFP evaluation or procurement
(7)
STATINTL
decision would be a questionable practice.
2) Consolidated Hardware Maintenance. Consolidated
maintenance requires an additional constraint to
HIS compatibility: identical vendors. While identical
vendors are likely in the mainframe area (i.e., ODP
has several CPU's from two of the major IBM-compatible
vendors, , it is less certain in the
peripheral area. ODP currently has a policy of OEM
(8)
maintenance. OEM's have not, as mentioned earlier,
provided volume discounts, but priced on a "per box"
basis. Maintenance for the initial SAFE hardware will
be procured in the RFP. Maintenance prices will there-
(9)
fore be evaluated directly. Maintenance for equipment
subsequently procured might be less expensive if equipment
were from an in-house vendor, but as this argument woul be
questionable for restricting competition in a procurement,
it should not be considered as a factor in valuing the
impact of non-compatibility.
In a similar vein to the above, maintenance vendor space
requirements can be evaluated (i.e., costed)directly in
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
the initial SAFE RFP. Procurement practice would require
the space provided not be unduly limited, which would
result in restricting the competition to in-house vendors.
Arguments similar to the above discussion on consolidated
maintenance pricing for follow-on SAFE procurement would
dictate that hypothetical maintenance vendor space savings
in future procurements not be considered an impact of non-
compatibility. Procurement practice also requires, except
in unusual circumstances, that security clearance and
administrative support costs should not be allowed to
restrict competition.
An HIS compatible SAFE may lead to a large single vendor
base which improves government "leverage" over the vendor
and m lead to improved hardware availability. Though
the above is "logical" and "common sense," it is purely
(10)
conjectural and should not be used as a basis for govern-
ment decisions. Hardware availability requirements should
be specified directly in the RFP and vendor capabilities
evaluated, with penalties for non-performance.
3). Consolidated Software Procurement and Maintenance.
Most vendor software is priced on a "per CPU" basis except
where tightly-coupled networks are involved (e.g., JES3).
Certain types of independent vendor software, however, are
discounted when multiple copies are ordered. System soft-
ware initially procured for SAFE will probably be evaluated in
the RFP. In an HIS compatible environment, subsequent pro-
curements of software for SAFE and other ODP centers from
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
independent software vendors and from the mainframe hard-
ware vendors might reflect discounts due to copies running
on other ODP CPU's. As in the discussion of consolidated
hardware and consolidated maintenance above, the benefits
are largely hypothetical and will not be considered in
(11)
evaluating the impact of compatibility.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Footnotes for Cost Element No. C-3
(1) Tightly-coupled networks (like JES3) often are an
exception to "per CPU" licensing; the network is priced as
one CUP (though possibly containing several CPU's.
(2) That is, four units of vendor X's equipment are not
necessarily cheaper than two units of vendor X's equipment
plus two units of vendor Y's. It depends, obviously, on the
cost of vendor Y's equipment.
(3) The potential for saving on procurements subsequent'to
the initial SAFE procurement is a more complicated issue and
is discussed in the following sections.
(4) This ignores the possibility of a multi-architecture con-
solidated procurement; e.g., vendors with multi-architecture
product lines or third party maintenance or leasing firms
could respond to multi-architecture consolidated procurements.
(5) With the possible exception of CRT terminals.
(6) Note that consolidated terminal procurement may be possible
even without H/S compatibility.
(7) It should be noted that Computer System Division at NPIC
is a Univac-compatible operation. Therefore, e.g., if SAFE
were Univac-compatible, there exists the possibility of
consolidated procurements between NPIC and SAFE. (ODP has
already procured CRT terminals in a consolidated procurement
with NPIC.)
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
(8) This is currently under study within ODP Processing.
(9) The possibility of a vendor providing a maintenance price
reduction on ODP Processing hardware as well as SAFE hardware,
and therefore not subject to evaluation in the SAFE RFP is
judged small, primarily because it would be in the best interests
of the vendor to reflect all discounts in the RFP.
(10) We know of no study that demonstrates a correlation between
the size of a vendor base in an installation and equipment
availability.
(11) For example,due the H/S compatibility and a multiple copies
requirement in ODP, an independent software vendor might provide
discounts from the single copy price of the software. However,
another hardware equipment vendor might provide a similar package
free, or the vendor might provide different versions which
execute on different architectures and therefore discounts might
be available for multiple copies irrespective of architecture, etc.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
COST OF NON-COMPATIBILITY
Cost Element No: C-4
Cost Element : Software Exchange Limitations
Cost : $470K
Evaluated Cost :
Discussion
With a HIS compatible architecture, government-owned
software could be exchanged between SAFE and other ODP centers.
In a non-compatible environment software exchange would be either
(1)
impossible or require an expensive conversion. Government-
owned software suitable for exchange may be divided into two
categories:
1) Contractor-developed SAFE software for which ODP Ruffing
or Special Center requirements exist;
2) ODP-, user-, or contractor-developed software executing
in the Ruffing or Special Center that satisfies a SAFE
requirement.
An example of the former category is SAFE text search
software. ODP personnel have indicated that a DDO text search
requirement similar to SAFE's is under discussion. An example
of software in the latter category might be GIM II for structured
(2)
DBMS requirements or an econometric model developed by the
(3)
Office of Economic Research.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Analysis
In the first category, it is estimated that 3.5% of SAFE
contractor-developed software will be exchanged with other ODP
(4)
center. Introduction of this SAFE software will occur over
the seven year systems life at an estimated rate of .5% annually.
In a non-compatible environment, this software cannot simply be
exchanged but must be either independently developed or converted.
The estimated cost of independent development of the exchanged
software would be:
$313K = 3.5% of $8950K (cost of contractor-developed
(5)
software)
Assuming 50% of the exchanged software (by value) requires
development (i.e., $157K) and the remaining software is suitable
for conversion at 50% of the development cost (i.e., ..5 x .5 x
$313K = $78K), the effective value of exchanged software is:
$157K + $78K = $235K.
Considering the second category of software exchange: it
is estimated that 3.5% of the SAFE software scheduled for con-
tractor development will be available from ODP in a compatible
(4)
architecture environment. The resulting saving will occur
pre-IOC. This equates to a $235K estimated savings (see above
computation). During systems life, the hard SAFE requirement
for additional ODP-developed software is judged small. ODP
mainframes will be accessible to SAFE users.. through the SAFE-ODP
communications link. Therefore, stand-alone ODP software
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
packages (e.g., econometric models) will be available to SAFE
users independent of SAFE architecture.
The total value of software exchange is the sum of the
value in the two categories discussed above. The final estimate
is therefore $470K (1979 dollars).
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
(1) A distinction is made between licensed software and govern-
ment-owned because the former generally incurs a separate cost
when run on additional mainframes and, if available, can be
procured irrespective of arthitecture compatibility.
(2) GIM II is government-owned and therefore free; with an N/C
architecture an alternative would be procurement of a comparable
vendor DBMS package.
(3) An N/C architecture would require a conversion.
(4) The estimated 3.5% rate of software exchange is based on
1) low rate of ODP-or user-developed software exchanged between
the ODP Ruffing and Special Center, 2) historical lack of success
in fostering exchange in the federal government (e.g., poor
performance of Federal Software Exchange Program).
(5) See Appendix C-4 for the estimated cost of contractor-developed
SAFE software.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 0 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Appendix C-4: Estimated Cost of Contractor-Developed
SAFE Software
The approximate cost of contractor-developed SAFE software
is computed by first estimating the number of Lines of Source Code,
converting to Project Man-Hours and then using an estimated Dollars
per Man-Hour figure to generate the software development cost.
The stepwise procedure follows:
Step 1: Computation of the Number of Lines of Contractor-
developed Source Code (i.e., higher order language
(HOL) or assembly language (ALC)):
The contractor has provided an estimate of 445K
deliverable, executable machine instructions (DEMI's)
We assume that the DEMI's are generated 50% (222.5K)
(1)
from HOL source code and 50% (222.5K) from ALC source
code. Assuming a conservative 2 DEMI's per line of HOL
source, this implies 111.25K lines of HOL source (i.e.,
222.5K DEMI's - 2 lines HOL source/DEMI) and 222.5K
lines of ALC source for a total of 333.75K Lines of
Source Code.
Step 2: Computation of Number of Man-Hours of Total Project
Effort: Using 173.3 Man-Hours/Man-Month (i.e., 2080
Hours/Year - 12)and 150 Lines of Source Code per Man-
(2)
Month of Total Project Effort, we compute the Man-
Hours of Total Project Effort: 333.75K Lines Source
Code X (173.3 -. 150) Man-Hours/Line of Source Code
385.6K Man-Hours.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Step 3: Final Computation of Estimated Cost of Contractor-
developed Software:
Estimated Cost of
Contractor-developed
Software
385.6K Man-Hours x $23.2/Man-Hour
Total Project Effort
(3)
$8950K (1979 dollars)
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Footnotes to Appendix C-4
STATINTL
(1) estimate from Proposal, Vol. I, pages 1-19 (Reference
a ).
(2) A lower quartile total effort productivity estimate from
Walston and Felix, IBM Systems Journal, "A Method of
Programming Measurement and Estimation," 1977, (Reference
5).
(3) Derived from proprietary data:
S 'TIN TL
Total Project Labor Dollars . Total Project Labor Hours
in 1979 dollars).
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Cost Element No. : D
Cost Element Technical Barriers to Load Sharing
Cost $500K + Other Factors (see sub-elements)
Evaluated Cost
Discussion
Load Sharing may be divided into several categories. Other
cost elements are associated with the cost of transferring
resources (people, hardware/software) between non-compatible
architectures. Load Sharing is an alternate approach (i.e.,
transferring the workload) but it too is generally rendered
impractical by non-compatibility.
Several categories of load sharing may be defined:
D-l. Routine Production Load Sharing.
This category implies SAFE production software is explicitly
designed to run in the ODP Ruffing Center. Software in this
category is not.considered part of the SAFE workload (i.e.,
SAFE is not necessarily sized to process it). In fact, SAFE
may not be able to process this software at all. (This would
be the case with a non-compatible architecture.) This concept
also encompasses the reverse situation: ODP production software
designed to run in the SAFE Center.
D-2. Routine Development Load Sharing
SAFE systems and/or applications software development (post-
IOC) is routinely performed on ODP mainframes. This activity
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 11 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
is primarily prime-shift activity associated with maintenance
and enhancements.
D-3. Backup Load Sharing
Backup Load Sharing is subdivided into two major sub-
categories: Overflow and Disaster.
D-3(a) Overflow Load Sharing
Overflow load sharing implies that under peak load
conditions (e.g., backlog) workload (primarily batch)
could be shifted between SAFE and other ODP centers.
D-3(b) Disaster Backup
Disaster backup implies the capability to transfer
critical workload between ODP centers in the event of the
unavailability of a major service. Unavailability of
service as defined herein is considered to be long-term
and due to a power outage, fire, flood, etc.
The impact of SAFE non-compatibility on the various cate-
gories of load sharing is discussed in the following cost sub-
elements. The costs presented above are the aggregate costs
associated with the load sharing categories (i.e., the sum of
the load sharing sub-element costs that follow).
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 I Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
COST OF NON-COMPATIBILITY
Cost Sub-element No.: D-1
Cost Sub-element Routine Production Load Sharing
Cost No Impact
Evaluated Cost.
-
Discussion
Batch processing support of SAFE in the Ruffing Center
would be more straightforward in an HIS compatible environment.
(1)
The SAFE CSRD, however, includes only one reference to offline
batch processing requiring Ruffing Center support. This is in
the SAFE Management Information System (MIS) area. SAFE is
designed as an almost exclusively online system; e.g., database
update is on an online continuous basis. Therefore, batch pro-
cessing requirements and, in particular, offline batch require-
ments, are envisioned as small. Any benefits in the batch
processing area associated with HIS compatibility would
correspondingly be small.
Two additional factors minimize this cost sub-element:
1. The SAFE dual maxi processors in off-peak periods
(primarily night) could no doubt provide a substantial batch
processing capability within SAFE.
2. Any routine offline batch processing hard requirement
could be satisfied by applications programs specifically
designed to run on Ruffing Center mainframes. This approach
would also permit ODP applications programmers to support SAFE
without substantial special SAFE architecture training.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Because of adequate non-prime shift Ruffing Center
capability, the reverse situation (i.e., routine ODP production
assigned to the SAFE Center) should not be necessary.
(1) Consolidated SAFE Requirements Document (Reference 1)
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
COST OF NON-COMPATIBILITY
Cost Sub-element No: D-2
Cost Sub-element Routine Development Load Sharing
Cost No Impact/Impact can be Evaluated in
Procurement
Evaluated Cost -
Discussion
With an H/S compatible SAFE, ODP Ruffing Center systems
(e.g., VM) could be used for prime-shift SAFE development
post-IOC, (primarily systems and applications maintenance and
enhancements). With a non-compatible SAFE, development of
higher-order language (HOL) programs for SAFE is technically
feasible on ODP systems, though clearly inefficient.
(1)
The proposed SAFE architecture has two levels of main-
frames: so-called midi and maxi. At least one of the less
expensive midi processors will be procured for backup and
therefore could generally be used as a prime-shift development
machine. If the maxi and midi are homogeneous (i.e., compatible
in hardware and software), use of the backup midi should meet
system-wide development requirements. If the maxi and midi
are not compatible, a separate, probably scaled-down version
of the maxi might be required for prime-shift development.
If a prime-shift development machine was not available
(either through use of the midi in a homogeneous maxi-midi
environment or through use of Ruffing Center mainframes), the
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
vendor could be required to propose an additional development
mainframe, sized to support a government specified development
load. Thus this cost sub-element could be handled directly
in the procurement and not require an explicit government
estimate of the cost of a development machine.
Recent CSPO analysis has indicated a significant cost
saving associated with a homogeneous maxi-midi environment.
Assuming homogeneity, because of the availability of the
backup for development, non-compatibility is estimated in
this category as having no cost impact. If homogeneity is
not the case, this cost impact can be evaluated, as discussed
above, directly in the SAFE ADPE procurement.
(1) Development could be accomplished through the use of
emulators, cross-compilers or the ODP language most similar
to the SAFE HOL. These surrogate approaches are poor sub-
stitutes for development using a system compatible with SAFE.
Under the surrogate approach, extensive "live" SAFE time would
be required for further development, conversion, system
integration, test. etc.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Cost Sub-element No: D-3(a)
Cost Sub-element Backup Load Sharing (Overflow Load
Sharing)
Cost $250K
Evaluated Cost -
Discussion
Overflow load sharing would, in certain circumstances,
be possible with an H/S compatible SAFE; i.e., under peak load
conditions workload (primarily batch) could be shifted among
(1)
ODP centers.
In a practical sense, however, the requirement for over-
flow load sharing between SAFE and other ODP centers is judged
small. SAFE is almost exclusively an online system; its
unique system architecture (as distinguished from mainframe
architecture) would render infeasible the off-loading of SAFE
online tasks. In addition, the SAFE batch workload is very
limited. SAFE processing capacity should be more than adequate
to handle SAFE batch workload during non-prime time.
(2)
During prime-time, there will be little excess SAFE capa-
(3)
city for processing ODP overflow batch or online workload.
In non-prime time, the available capacity in the SAFE Center
should increase. However, the same is true in the Ruffing and
(4)
Special Centers, and the requirement for overflow load sharing
should be minimal. In addition, the Special Center can and
occasionally does serve as an outlet for Ruffing Center overflow.
5)
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 d Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Overflow load sharing, only possible in an H/S compatible
environment, is therefore judged of small value to ODP.
An-estimate of the value of overflow load sharing is 5%
of the systems life cost of an IBM-compatible SAFE dual maxi
processor (i.e., the Document/Catalog Management/Text Search
Management/Index Search Management Subsystem). The underlying
assumption is that 5% of an IBM-compatible dual maxi processor
would be used to process Ruffing Center overflow (e.g., 10% of
processor capacity during the non-prime shift). An estimate
of $4926K is developed in Appendix D-3(a) for the systems life
cost of the dual maxi processor configuration.
Therefore, the value of compatibility for over load-
sharing is estimated as 5% of $4926K or $246K (1979 dollars).
(1) This discussion of the potential for load sharing
intentionally ignores security issues inherent in inter-center
load sharing.
(2) The batch workload identified at this time (e.g., the SAFE
Management Information System) is not time-sensitive. SAFE will
be sized to handle prime-time online loads. During non-prime
time excess capacity for batch processing should routinely be
available.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
(3) As in the reverse situation, the routine off-loading of
Ruffing Center online overflow (e.g., selective GIMS data-
bases) would be a difficult technical task.
(4) Utilizing this non-prime time capacity might require re-
configuring ("downsizing") ODP online services; e.g., trans-
ferring VM from the IBM 3033 to the IBM 370/158.
(5) Special Center overflow is negligible.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Appendix D-3(a): Estimate of the Cost of an IBM-compatible
Dual Maxi Processor Configuration, Suitable
for Backup Load Sharing
In the SAFE System, the Document/Catalog Management/Text
Search Management/Index Search Management (DCM/TSM/ISM) Sub-
system is planned as a dual maxi processor. If it were IBM-
compatible, as are the ODP Ruffing and Special Centers, there
would be the (l)
possibility of backup load sharing. In this
appendix, an approximate systems life cost for an IBM-
compatible dual maxi processor is developed. The value of
IBM-compatibility for backup load sharing is estimated as the
percentage of an IBM-compatible dual maxi processor subsystem
resource used applied to the cost of the subsystem.
Table 1 details the dual maxi processor configuration.
Three approaches to estimating the cost of an IBM-compatible
dual maxi processor configuration are now described:
o Approach I: Use of the Marketplace.
Proposals received in response to SAFE ADPE RFP
would be examined. The dual maxi processor con-
figuration with the lowest overall evaluated cost
that utilized IBM-compatible hardware would be
selected.
o Approach II: Use of the IBM GSA Schedule
The IBM GSA ADP Schedule Price List would be used
to cost out the dual maxi processor configuration
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 STATINTL
STATINTL
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
o Approach III: Use of Univac Configuration Cost
The Univac dual maxi processor configuration is costed
out in thrCost Proposal (Reference 4(b)). Table.
1 (attached) from the proposal summarizes the Univac
configuration cost. The estimate is approximately
$3750K. The maintenance cost for the configuration is
$14K/month over the systems life (pg. 5.-3, Cost:
Proposal, Reference 4(b)). Total cost over the systems
life (7 years) is $4926K.
Approach I uses competitively-derived costs and is actually
ideal. Prior to proposal evaluation, however, it is clearly
(2)
not possible.
Approach II, use of the IBM GSA ADP Schedule Price List
provides an effective "ceiling" on a true competitively-derived
cost. This approach will not be used because of the time in-
volved in developing a complete IBM-compatible configuration.
If more time were available this could be pursued.
Approach III uses the readily available Univac configuration
costs as an approximation of the cost for the comparable IBM-
compatible configuration. For convenience, this approach will
be followed. Therefore,
The estimated cost of an IBM-compatible dual maxi processor
configuration is = $4926K (1979 dollars).
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 IUI)UJd1 1IU. -Ui II.UUJ1(
Appe ')Release 2002/01/08: CIA-RDP84-00933R000500020001-6
TABLE 1. Dual Maxi Processor Configuration and Univac
Implementation Cost *
1.1.1.1.7 DCM/ADPE MAXI, DUAL PROCESSOR, 4M BYTES
BASIS: A UNIVAC 1100/82 DUAL PROCESSOR CONFIGURATION WITH BOTH PROCESSORS SHARING 4M BYTES OF MEMORY. PLUG
COMPATIBLE DISK CONTROLLERS ARE FROM INTERSCIENCE CORPORATION AND DISKS ARE STORAGE TECI4WOLCK1y
DUAL SOON BYTE UNITS.
DESCRIPTION
ARCHITECTURE
REPORT
OTY.
TOTAL
BID
OTY.
Wes
SUe
ND.
1. PROCESSOR COMPONENTS
1 LOT
1 LOT
2. TAPE CONTROLLER
1
2(1)
4
3. TAPE DRIVES
2
2
4. CARD READER
0
1121
-3
5. LINE PRINTER
0
1(2)
6. DISK SUBSYSTEM CONTROLLERS AND
SHARED PROCESSOR I/F
4+6-10
10
-5
7. DISK SUBSYSTEM DISK DRIVES WITH
DUAL ACCESS
(1( REDUN
(28+23)-06
AT 300 MO
10 AT 2x600 MS
-5
DANT UNIT TO IMPROVE AVAILABILITY
WPS
PART NO.
NAME
VENDOR
UNIT
PRICF3) QUANTITY
EXTENDED
PRICE
111171
3032.91
PROCESSOR
UNIVAC
1,216,266
1
1
260
216
111171
3032-00
PROCESSOR EXPANSION
UNIVAC
456,0"0
1
,
,
460
040
111171
3033.119
IOU EXPANSION
UNIVAC
263,119
1
,
263
116
111171
19.23-00
10 CHANNEL EXPANSION
UNIVAC
7,905
2
,
15
810
111171
F105S-01
WORD CHANNEL MODULE
UNIVAC
40,686
4
,
162
224
111171
1
P2350-99
MEMORY EXPANSION
UNIVAC
150,000
1
,
150
000
11171
111
F3137-00
REMOTE CONTROL PANEL
UNIVAC
788
1
,
700
171
11
2525-00
SUBSYSTEM AVAILABILITY UNIT
UNIVAC
50,620
1
69
520
1171
050600
MOTOR ALTERNATOR
UNIVAC
10,500
1
,
16
500
111172
5017-00
TAPE CONTROL
UNIVAC
21,420
1
,
21
420
111172
P0509.99
SIMULTANEOUS OPERA'r10N
UNIVAC
15,604
1
,
15
984
111172
F0026-00
600 BPI
UNIVAC
4,320
2
,
0
00
111172
F0 5-00
DUAL CHANNEL
UNIVAC
3,312
2
,
0
024
111172
0602-04
TAPE DRIVE
UNIVAC
16,624
2
,
33
04.3
111172
P 1319.00
DUAL ACCESS
UNIVAC
1,836
2
,
3
072
111172
0160902
INTERFACE 6017
UNIVAC
N/C
2
,
0
111172
F0337.14
DUAL DENSITY
UNIVAC
1,838
2
3
072
111173
0718-02
CARD READER (W/CTL)
UNIVAC
11,623
1
,
11
028
111174
0776-02
PRINTER (W/CTL)
UNIVAC
35,010
1
,
35
010
111174
F221609
PRINTER CARTRIDGE
UNIVAC
1,000
1
,
1000
111175
4600
DISK CONTROL
INTERA"CI
57,850
13
570
500
1111/5
SPI
SHARED PROC INTERFACE
INTEROCI
3,530
10
,
38
300
111175
866082
DISK ORIVE (2X600M5)
S TC
42,449
15
,
636
730
111175
8604
DUALPORT
SEC
641
15
.
14,115
STATINTL
Figure 5.3 1 Traceability DCMITSM AUPE
* Fro SAFE Proposal, Vol. II, "Cost," dated 16 March 1979,
(SA -?002-3/79)
5-53
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
Footnotes to Appendix D-3(a):
(1) See Cost Element D, "Technical Barrier to Load Sharing,"
for a definition of backup load sharing.
(2) This approach is a candidate for use in the RFP evaluation
if the value of IBM-compatibility is "folded-in" to the evaluation.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
that both centers were rendered inoperative an H/S compatible
SAFE would be the only in-house backup.
During non-prime shift an H/S compatible SAFE could process
Agency batch workload in the event of a disaster. Only limited
prime-shift SAFE processing capacity, however, would be avail-
able. ODP online systems such as GIM II and VM could, in theory,
be brought up under an H/S compatible SAFE. If SAFE were not
(3)
accessible from general-purpose ODP terminals in a disaster
situation, available SAFE terminals could be used for critical
tasks.
The related problem is the use of the Buffing and Special
Centers for disaster backup to SAFE. Because of the uniqueness
of SAFE system architecture (as distinguished from mainframe
architecture), it appears technically infeasible to back up
(4)
SAFE online functions in the Buffing or Special Center.
It is possible that special purpose backup software could be
developed to provide a limited subset of SAFE capabilities
(5)
in the Buffing Center. This would require an unknown but
significant development effort. There would probably be some
advantage if the centers were H/S compatible in developing
special purpose software. However, it is probably true that
special purpose software could be developed even with different
architectures. Without the required development activity, the
value of the Ruffing Center as a significant SAFE backup is
judged small.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
COST OF NON-COMPATIBILITY
Cost Sub-element No. : D-3(b)
Cost Sub-element Backup Load Sharing (Disaster Backup)
Cost $250K
Evaluated Cost -
Discussion
Disaster backup would be possible in certain circumstances
(1)
with an HIS compatible SAFE. Under the assumption of a major
catastrophe in the Ruffing or Special Center, batch workload
could be processed by SAFE during non-prime shift. It is also
possible that with an appropriate development effort, ODP on-
line systems (e.g., GIM II, VM) could also be brought up on a
SAFE processor during non-prime shift. In the event of a
disaster, some SAFE functions could be supported in the Ruffing
Center through special purpose software. This type of backup,
however, would not be dependent on SAFE architecture.
Currently, it is generally believed that the Ruffing and
Special Center provide at least partial disaster backup for
(2)
each other, since they are HIS compatible centers. The
major drawbacks to successful backup would be the limited
processing and communications capacity in the Special Center.
The technical problem of backup for online systems would
also be formidable. An HIS compatible SAFE would provide some
"cushion" in a disaster situation where one or the other
center was damaged or destroyed; or in the unlikely occurrence
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
In an H/S compatible environment, SAFE batch work could
be supported in the Ruffing Center. The planned SAFE batch
workload is insignificant and will consist of non-critical
functions such as the SAFE Management Information System. The
value of backup for SAFE batch workload is therefore considered
minor.
The most practical automated backup for SAFE is the DIA
(6)
SAFE system. Both systems will be architecturally identical.
The practical means by which a CIA analyst could access DIA
SAFE in the event of a CIA SAFE disaster remains to be studied.
It is a function of the existence of link between CIA and DIA
and the survival of a means of access to the link after the
disaster. At a minimum, CIA analysts could be given physical
access to DIA terminals during non-prime shift.
The Ruffing and Special Centers are judged of minor
value for SAFE disaster backup. Disaster backup for the
Ruffing and Special Center would primarily be performed in
non-prime time on the SAFE dual maxi processors (i.e., the
Document/Catalog Management/Test Search Management/Index
Search Management Subsystem). An upper bound, therefore,
on the value of disaster backup is the systems life cost of
(7)
an IBM-compatible dual maxi processor configuration.
In Appendix D-3(a) an estimate of $4926K is developed for
the systems life cost of that configuration. It is further
estimated that 5% of configuration resources would be required
(8)
for disaster backup. The value of an IBM-compatible archi-
tecture for disaster backup is therefore bounded by 5% of
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
$4926K or $246K (1979 dollars) over the systems life.
(1) Security issues in a disaster backup situation will not be
addressed in this discussion.
(2) A formal ODP disaster plan is in preparation in ODP/IIS.
(SAFE will not be included at this time.)
(3) The accessibility of SAFE to general-purpose ODP terminals
depends on whether ODP has implemented a unified bus architecture.
(4) Because of its limited capacity, the Special Center is
ignored from this point on as a SAFE backup.
(5) A method for accessing incoming CIA mail from the Cable
Dissemination System (CDS) would be required. Distribution of
hardcopy is a possibility (though a primitive one). Note that
use of automated access to CDS or hardcopy distribution is
independent of SAFE architecture compatibility.
(6) This is primarily true for SAFE private files. DIA incoming
mail is not identical to CIA incoming mail. Alternate automated
approaches probably utilizing Ruffing Center capabilities with
the Cable Dissemination System (CDS) will be required to access
CIA mail. A non-automated (and primitive) backup to private
files such as microform backup could also be made available.
(7) That is, an equivalent disaster backup to the SAFE dual
maxi processor configuration could be provided by procuring an
identical configuration and installing it in a separate "disaster"
facility. Clearly, this is an extravagant solution. Such a
disaster backup configuration would require an alternate primary
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
 Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6
use to be cost-justified. The major portion of the cost of the
disaster facility could therefore be charged to the primary use.
(8) Five percent configuration resources over the 84-month
systems life is equivalent to 8.4 months use of 50% of capacity
(e.g., non-prime shift) for disaster backup. One would hope
that our current safety posture would limit ODP to, for
example, one disaster in an 84-month period with 8.4 months
required to reconstruct and re-equip the destroyed center.
Approved For Release 2002/01/08 : CIA-RDP84-00933R000500020001-6