MISCELLANEOUS NOTES ON THE OCS/ORD RELATIONSHIP (VINTAGE, SPRING 1968)

• Document Type: CREST
• Collection: General CIA Records
• Document Number (FOIA) /ESDN (CREST): CIA-RDP85B00803R000200080059-1
• Release Decision: RIPPUB
• Original Classification: K
• Document Page Count: 4
• Document Creation Date: December 15, 2016
• Document Release Date: December 16, 2003
• Sequence Number: 59
• Publication Date: July 14, 1969
• Content Type: MFR

IMEMORANDUM FOR THE RECORD
Approved For Release 2004/05/05 : CIA-RDP85B00803R000200080059-1
14 July 1969
SUBJECT: Miscellaneous Notes on the OCS/ORD
(Vintage, Spring i96.8)
1. The same problems we had in 1965 are still with us.
remain skeptical that more formal r echanisms will improve
communications. While this is cited. as the basic problem by
IPRD. It is only a manifestation of a deeper' problem: "What do
we have to talk. about"? There 13 a fundamental barrier between
us that is a function of the people involved on both sides, profes-
aional jealousies and interests, and organizational responsibilities
(int. that order of significance,-but the irony is that the degree we
can do something to change this is probably the reverse order).
2, nd others in IPRD express their frustration as a
communications problem, but I think it boils down to the fact that
they want us to agree with them-"If OCS doesn't agree with us,
they aren't listening. "t I can support this with evidence of ORD
withdrawal to "we'll see" or other platitudes when we get down to
nuts and bolts. We seem to get sucked Into one of those games
people play called' s, but.11 Not withstanding these bleak realities,
I don't think the situation is hopeless, hence I won't stop here:
3. > A simple way to express our division wf responsibilitKes
(and like all attempts to simplify, this one has its pitfalls) is to say
that ORD should fill In technological gaps- in. OCS, not users' service
gaps. Putting it another -way. GR]C) should pick up not where our
available time leaves off, but where our knowledge leaves off.
Unfortunately, in our iiew they have not complemented our efforts
in this fashion. Some believe it is because they don't know, how to
extend the technology and at best they can try to keen yap by following
a our wake, but striking out laterally, encroaching on our domain
-,pith a technique that is interesting to our customers--which. we
Approved For Release 2004/05/05 : CIA-RDP85B00803R000200080059-1
elationship
 Approved For Release 2004/05/05 : CIA-RDP85B00803R000200080059-1
probably built, or considered and rejected. in the first place. Maybe
our reaction is similar to that of the teacher who has mixed emotions
about his success with a. student who then turns cocky. In summary,
I think we can use the idea stated in the first sentence as a basic test.
4.. As .1 said before, another source of problems is the IPRD
emphasis on moving the project directly and smoothly into useful
operation. The nature of R&D is such that this preoccupation can be
destructive.
--It shifts the emphasis away from the problems that warrant?'.
calling the project R&D in the first place.
--It provides -few opportunities to learn frees mistake
results.
--It discourages experimentation or thoughtful evaluati
convinces them we should be able to do.
satisfying customer requests with the ease that ORD
--It often forces OCS into an embarrassing position of not :
When we suggest that their orientation may be wrong, they mention
the directives to use live data and to have customer involvement.
These two requirements do not necessarily imply operational goals,.
but how can they be convinced of this? In any event, there are easier,
cheaper ways to get things going that are within the state-of-the-art--
without the insertion of a ponderous facade of pseudo R&D.
. 'Anothear point here is wcsrth focusing on.- the implications-.
of an operational goal seem to occur to ORD only after the project
afiarts..-long after the usual questions of economic feasibility should
be raised. They must either give attention to theses questions . earlier
(as we normally do) or continue to ignore therms and not be so intent
on making the project go (the latter option being preferred).
6. Another negative point: I believe that R&D people should stay
.out of the systems building area, that is.,-building something new from
L1dividual well-established techniques and facilities. Information f,.
~fstems building now its a crude art that is best practiced outside the
R&D area. By my definition then, building information iysteezxzs, no
Approved For Release 2004/05/05: CIA-RDP85B008O3R000'20.0&80059-1,
 l
Approved For Release 2004/05/05 : CIA-RDP85B00803R000200080059-1
matter h9w, ex tie ,froxn existing tested techniques, is not R&D, 1
This, of course, may not be the case outside the information
processing world. What is needed is R&D in new or improved
techniques, includina a better systems analysis methodology.
ORD`s reply to this would be that they must have .a system to test
the techniques, but it seems that system building costs overshadow
those related to technique development. You don't need to design
and 00214 4 new car firom scratch to test anew steering wheel.
This is ano .er source of OCS: "poor. coxnlsunications_ How do you
get ouar people interested In helping debex or Improve a need ocreer,
g
error-ridden operating system that they Say is n :tided to test an
tt
i
d
a
ract
ve i
ea? Why is it necessary for o reinvent se-rere.
programs and hardware packages to test the concept of an analyst's
7. This leads to another point. regarding hardware versus
techniques in R&D projects: which has the primary influence on
the other at IPRD? Unfortunately, most of us think that hardware
is the =dominant factor. I concede that in many cases this must be,
but only when hardware Urnita t ions are to be considered. it i s
wrong to force the projeect to mushroom so that it fills every nook
and cranny of the hardware's capability and then perhaps wonder
why getting an application going is so expensive.
: irec or o Computer Services
STAT
Approved For Release 2004/05/05 : CIA-RDP85B00803R000200080059-1
 Approved For Release 2004/05/05 : CIA-RDP85B00803R000200080059-1
Approved For Release 2004/05/05 : CIA-RDP85B00803R000200080059-1