&EPA
United States
Environmental Protection
Agency
Office of Planning
and Management
Management Information
and Data Systems Division
Washington DC 20460
2nd Annual
ADP Conference
November 29, 30 and
December 1, 1977
-------
This document is available from:
U.S. Department of Commerce
National Technical Information Service
5285 Port Royal Road
Springfield, Virginia 22161
DISCLAIMER
This report has been reviewed by the Office of Planning and Management U S Environmental
Protection Agency, and approved for publication. Mention of trade names or P™ Envir°lnme"tal
does not constitute endorsement or recommendation for use commeraal products
-------
2nd Annual ADP Conference
November 29, 30 and
December 1, 1977
Sponsored By
Management Information and Data System Division
Office of Planning and Management
U. S. Environmental Protection Agency
Washington DC 20460
-------
TABLE OF CONTENTS
Page
Number
FOREWORD ............................. iii
AGENDA .............................. v
GENERAL SESSION I
Welcome ............................ GS-1
Lee Johnson ........................... GS-2
Willis Greenstreet ......................... GS-6
David Morin ........................... GS-6
Questions and Answers .................... GS-1 6
PANEL A: DISTRIBUTIVE PROCESSING
Overview of Distributive Processing in EPA
Theodore Harris ....................... A-l
Cincinnati Test Site Experience
Bruce Almich ........................ A-4
Questions and Answers .................... A-6
The EPA Telecommunications Network
Fred Kastner ......................... A -7
Questions and Answers .................... A -9
Project Independence: Data Processing Capability
D. M. Cline ......................... A-10
Air Quality Tracking System/PDP
Steve Goranson ........................ A-12
Mini-Computer Success
Curtis Lackey ........................ A- 14
Questions and Answers .................... A- 16
Distributing Processing Issues at EPA Region V
Joel Brandon ......................... A- 17
Region X Mini- Computer Experience
Dennis Schur ......................... A- 19
Questions and Answers .................... A-21
Systems: Distributed — Centralized- -Independent
Jim Hammerle ........ ................ A-22
The Mini-Computer and National Systems
Jim Susha ......................... A-25
Questions and Answers .................... A-27
-------
Page
Number
PANEL B: EFFLUENT DATA SYSTEMS
Introductory Remarks
Jack Sweeney ........................ B-l
EPA's Needs and Uses of Effluent Data
Chuck Evans ......................... B ~2
Planned Effluent Data Systems
Bill Milligan ......................... B ~7
Introduction—The Region II Effluent Data Systems
Purposes and Goals
Cliff Lundin ......................... B -9
Region II: Summary and Future Systems Usage
Cliff Lundin ......................... B-ll
Questions and Answers .................... B-13
Administrative Efficiency Report
Pete Gattuso ......................... B-16
Phil Taylor ......................... B-19
Questions and Answers .................... B-22
PANEL C: EXCHANGE AND STANDARDIZATION
Overview
Ted Standish ......................... C - 1
Software and Documentation Standards
Maureen Johnson ....................... C -4
Data Integration
Gail Huguet ......................... C -7
Questions and Answers .................... C-10
Standard Terminal Contract
Jim Flatten ......................... C-ll
Work Processing Standards
Cathie Tittle. . .. -
Summary Remarks
Ted Standish ......................... C-18
Questions and Answers .... ................ C-20
*"
PANEL D: SYSTEM DEVELOPMENT CYCLE
*•-
Overview
Morris Yaguda ........ ............. D -1
-------
Page
Number
Upgrade
Lance Wallace D -2
The Chemical Information System
Stephen Heller D -5
Comments
Morris Yaguda D-12
Planning for the 1980's
Morris Yaguda & Theodore R. Harris D-13
Theodore R. Harris D-16
Questions and Answers D-18
Feasibility Studies
Don Fitzpatrick D-21
PANEL E: ADMINISTRATIVE SYSTEMS
Introductory Remarks
Neil Haley E -1
The Financial Management System
Alan M. Kaplan E -2
Questions and Answers E -7
Resource Management Information System
C. Tom Wolz E-10
Questions and Answers E-13
The Personnel Management Information System
Michael Platt E-14
Questions and Answers E-18
Contracts Information System
Edward McLean E-22
Questions and Answers E-25
Personal Property Systems
Cariton Woodeli E-28
Questions and Answers E-31
Paul Wagner E-33
Comments E-36
PANEL F: WATER SUPPLY
Overview
Fredrick T. Martin F -1
-------
Legislative Direction and
Decentralization of the Model State
Information System
Dan Barber
Meeting the Requirements
of the Safe Drinking Water Act
and the Needs of the States and EPA
Bruce O. Keith
Test and Acceptance of a System
for a User Other than EPA
Donald Worley ........................ F-19
Questions and Answers .................... F-22
PANEL G: ADP MANAGEMENT
Introductory Remarks
Kenneth Byram ........................ G--1
Questions and Answers .................... G -3
MIDSD: Coordination and Integration
George Lehnert ....................... G -7
ADP Management and Organization
Bruce Rothrock ....................... G -8
Questions and Answers ................ .... G- 11
Comments .......................... G-12
ADP Problems From a Manager's Perspective ............ G-14
Questions and Answers .................... G-19
Centralization
Joel Brandon ......................... G-20
Comments .......................... G-25
PANEL H: TOXIC SUBSTANCES
Overview
Ken Olsen .......................... H -I
The Inter- Agency Regulatory Liaison Group
Warren Muir ......................... H -6
Feasibility Study on Information Systems
Morris Yaguda ........................ _ _<
Inventory Information in the
Chemical Abstract Service
Frederick H. Siff .................... H-ll
The Informatics Contract
Ernest Stalder „ ..
-------
Page
Number
Confidentiality
Denise Swink H-16
Questions and Answers H-18
CONCLUDING REMARKS/PANEL SUMMARIES
Willis Greenstreet P5-1
GENERAL SESSION II: PANEL SUMMARIES
Distributive Processing Summary
Theodore R. Harris PS-2
Effluent Data Systems Summary
Jack Sweeney PS-3
Exchange and Standardization Summary
Ted Standish PS-5
System Development Cycle Summary
Morris Yaguda PS-7
Administrative Systems Summary
Neil Haley PS-9
Water Supply Summary
Tom Martin PS-1 0
ADP Management Summary
Kenneth Byram PS-1 1
Toxic Substances Summary
Ken Olsen PS-1 3
-------
PRODUCTION NOTES
The proceedings of the Second Annual ADP Conference were captured on tape and
transferred, by transcription, into written form. Due to occasional difficulty in getting
good sound quality, changing of tape reels, or other intervening factors, certain portions
of the text were deemed unintelligible and have been marked as such.
Contract limitations and poor graphic quality have limited the number of illustrations in
this document. Wherever possible, however, textual references to specific illustrations
are tied to that graphic with a "figure X' designation.
The document's pagination employs the following system: Each individual panel session is
individually numbered, with the panel session's identifying letter followed by the page
number itself (for example, within Panel Session A the pages are designated A-l, A-2, A-
3, etc.; Panel Summaries are designated PS-1, PS-2, PS-3, etc.).
-------
FOREWORD
The Second Annual ADP Conference was held November 29, 30 and December 1, 1977 at
the Annapolis Hilton, Annapolis, Maryland. The objective of the Conference was to
inform conference attendees about the Agency's major ADP activities, as well as other
areas of general concern. Panels were formed consisting of key managers who presented
talks on their activities. Question and answer periods were held at the end of each Panel
Session.
Luther Garrett
Conference Program Coordinator
-------
AGENDA
2nd ANNUAL ADP CONFERENCE
NOVEMBER 29-30, DECEMBER 1, 1977
ANNAPOLIS, MARYLAND
General Session
WELCOME
Willis E. Greenstreet, Director
Management Information and Data Systems Division
GUEST SPEAKERS:
Lee Johnson, President
Computer Network Corporation (COM NET)
David Morin
International Data Corporation
-------
Distributive Processing
Panel Member
Theodore R. Harris, Chirperson
Bruce Almich
Fred Kastner
Mickey Cline
Curtis Lackey
Joel Brandon
Dennis Schur
Steve Gorensen
Jim Hammerle
Jim Susha
Willis E. Greenstreet
Organization
Management Information and Data Systems
Division - Hq.
Computer Service and Systems Division -
Cinicinnati
Management Information and Data Systems
Division - Research Triangle Park
Environmental Research Laboratory-Athens
Region IV - Atlanta
Region V - Chicago
Region X - Seattle
Region V - Chicago
Office of Air Quality Planning and Standards
Research Triangle Park
Municipal Construction Division - Hq.
Management Information and Data Systems
Division - Hq.
-------
Effluent Data Systems
Panel Members
Jack Sweeney, Chairperson
David Lyons
Clifford Lundin
Howard Hein
Peter Pattuso
Marty Halper
Organization
Region II - NewYork
Enforcement Division - Hq.
Region II - New York
Region II - New York
Region II - New York
Effluent Guidelines Division - Hq.
vu
-------
Exchange and Standardization
Panei Members
Ted Standish, Chairperson
Maureen Johnson
Gail Huguet
Catherine Tittle
James Flatten
Organization
Region III - Philadelphia
National Computer Center - Research
Triangle Park
Delaware Valley Regional Planning
Commission
Management and Organization Division -
Hq.
Management Information and Data Systems
Division - Hq.
via
-------
System Development Cycle
Panel Members
Organization
Morris Yaguda, Chairperson
Lance Wallace
Norman Cottrell
Donald W. Fitzpatrick
Stephen Heller
Management Information and Data Systems
Division - Hq.
Office of Research and Development - Hq.
Management Information and Data Systems
Division - Hq.
Arthur Young and Company
Management Information and Data Systems
Division - Hq.
IX
-------
Administrative Systems
Panel Members
Neil Haley, Chairperson
Systems Managers;
Alan M. Kaplan
Edward S. McLean
Michael H. Platt
Paul F. Wagner
Carlton Woodell
Charles T. Wolz
Systems Users;
Mary Blakeslee
Leo C. Cox
Albert Pines
Dennis Schur
Organization
Management Information and Data Systems
Division - Hq.
Financial Management Division - Hq.
Contracts Management Division - Hq.
Personnel Management Division - Hq.
Grants Administration Division - Hq.
Facilities and Support Services Division - Hq.
Budget Operations Division - Hq.
Office of Air and Waste Management - Hq.
Office of Water and Hazardous Materials -
Hq.
Office of Research and Development - Hq.
Region X - Seattle
-------
Water Supply
Panel Members
Frederick T, Martin, Chairperson
Robert D. Barber
Bruce O. Keith
Donald L. Worley
Organization
Office of Water Supply - Hq.
Region IV - Atlanta
Office of Water Supply - Hq.
Management Information and Data Systems
Division - Research Triangle Park
XI
-------
ADP Management
Panel Members
Organization
Kenneth Byram, Chairperson
Joel Brandon
George Lehnert
Bruce Rothrock
Douglas W. Shape
Michael Steinacher
Management Information and Data Systems
Division - Hq.
Region V - Chicago
Office of Water and Hazardous Materials -
Hq.
Office of Enforcement - Hq.
Region IV - Atlanta
Management Information and Data Systems
Division - Research Triangle Park
xu
-------
GENERAL SESSION I
K
Welcome
I want to welcome you to the Second ADP Conference. I hope we are able to
provide a forum for you to talk to each other; that is the purpose of the meeting. We're
here to provide a meeting place, to give you some interesting and educational topics, but
primarily the purpose is for the user community and systems managers to talk to each
other. The genesis of this meeting occurred at the zero-based budget ranking for ADP
last summer, when it became perfectly obvious to me, sitting in on that session, that the
users and the managers were not talking to each other about what their plans were for the
future. We're available to assist you but basically the success or failure of this
conference, at least to my mind, is how well you talk to each other and find out what each
other's plans are. A lot is going on in EPA. I can attest to that. I set a personal goal of
visiting all of the regional offices in a year; it took me a year and a half and I have been
to all of them now. It does no good for me to stand here and tell you all the things I have
found, heard, or seen. I think you need to discover this for yourselves. In this vein, I hope,
during the coming year to year and a half, to be involved in a series of meetings in a
specific area such as laboratory instruments, where people can get together to talk. I'd
like all of you to keep this in mind during the sessions.
Our first topic will be the ADP world-at-large, more particularly, the commercial
sector and the vendors. Our speaker knows more about this than any other human being
outside the Federal Government.
Now Lee and I have had a standing joke for the last few days. I told him that if he
did not give me a biographical sketch, I was going to tell you what I knew about him. He
got worried and this morning he gave me a few notes which I will share with you. First,
though, I would like to say that Lee is a man of great energy. More than that, Lee
Johnson has done something that I have always wanted to do. The thing that I admire
most about Lee Johnson is that one night he had the audacity to throw a printer that did
not work out on the street. I have always wanted to do that, and he did.
But seriously speaking, Lee is one of the pioneers in the data processing industry.
He started with General Electric Corporation in a management training program in 1953;
his first task was to evaluate Univac I. Then he joined Remington Rand, or its successor
corporation, working there from 1956 to 1967. He moved into the communications aspect
of computers, specializing in airline reservation systems. He was also involved with the
Federal Systems Division of Univac in 1961, when they had 69 employees and $4.5 million
in business. When he left, they had 3100 employees and $241 million in business. He left
in 1967 and formed two companies, COMNET (Computer Network Corporation) and one
called COMTEN, which makes communications front-end computers. Over the years,
COMNET has grown from a small company in 1971 to a corporation of 200 employees and
$16 million in revenue. With that, I would like to introduce Lee Johnson.
GS-1
-------
GUEST ADDRESS
Lee Johnson
I'd like to tell you a bit about where COMNET has been where we are today, and
where we are going. COMNET was started with $11,667.20. In 1967, we had the
important task of trying to decide which Thursday we were going to the courthouse to
declare bankruptcy. Those were days when, in essence, commercial companies would sign
five or six different types of contracts. It was not necessarily their intent to use any one
of those companies. If they used your service, it only determined how your bill would be
computed. We were an industry where a 30-day contract, with good intent behind it, was
great!
The industry almost did not make it through the 1970-71 crunch of the economy,
recession, tight money market, etc. If you had the name "time-sharing", attached to the
company, it was worth between 10 and 30 points on the stock; it did not matter whether
you had any business or were doing anything. Wall Street would loan you great sums of
money. COMNET went public on November 9, 1967 at $2.25 a share for all of 200,000
shares. In the subsequent four years, 185 of the companies of our type went down the
tubes. It was a very difficult, competitive environment in which the industry grew up in.
COMNET is an independent. Other independent corporations are Computer Science
Corporation, Boeing Computer Service, Litton, etc. As an independent, our business is
basically the computer service industry. The objective was to find a way to improve
software capability, computer capability, and communications capability. The key, from
our point of view, is the Federal Government; 76 percent of our revenues, six months into
our fiscal year, are U.S. Government. Approximately seven or eight perecent are from
quasi-government sources such as the U.S. Postal Service and the U.S. Railway
Association.
I think we are finished with the era of contracts that assured you nothing. Our
guarantee was $100 a month. On November 8, 1971, GSA moved into the arena for
computer services awarding a contract to the Computer Science Corporation. That first
contract has remained with that company and accounts for $30 to $35 million in annual
revenues from the Government. There were, however, exclusions. There were
restrictions on the type of services they could provide. These restrictions allowed
companies, such as ours, to carve out a remaining niche in the Federal Government. In
1972-73, the initial contract had to be re-competed. The people at GSA were basically
going out to re-compete that same contract. The longest contracts that COMNET has had
in the Government are of two types. The first type, like our EPA contract, is a multi-year
facilities contract. The other type of contract is with the Department of Transportation
(DOT). They basically re-compete the contract every two years. They do not pick a
single company, but pick approximately eight or ten from the industry which furnish both
IBM and non-IBM services. Our company has had a contract with DOT for almost seven
years now. The theory behind this was that GSA would go out and re-compete that CSC
contract on a single-company basis. We started to work with GSA, along with other
companies. We concentrated on GSA to pick a national company, a regional company, a
multi-regional company, and a local company; the differences among these companies
would represent the communication capability. If you did not have hard-wired lines across
the country, you were not a nationwide company. There was a little company called Tym-
Share, which is, I think, the largest independent in this business that had a communication
network service they put up with mini-computers; they were getting ready to tariff that
GS-2
-------
service. We managed to get a standard contract with two minor changes. One was that
we can not disclose that we are a user; second, we can not indicate by our traffic analysis
where our customers are. We signed that document. It never occured to this company
that a competitor would sign the contract for which they put the network up initially for
themselves and subsequently had gone out to sell that service. They sold it to about 19
Fortune 500-type companies. I guess there was considerable gnashing of the teeth. But
they had one basic decision to make: would they get out of business with those 19 other
companies, or accept this one with COMNET? Well, they made the right decision.
COMNET became a national company under the system we are trying to sell to GSA. We
had a communication network, and were one node larger than Tym-Share. We kept
pushing the concept of the multi-vendor approach to GSA. In that system, there would be
at least 15 or 20 companies offering IBM service. At least two or more offering UNIVAC
service, CSC and University Computing; two or more companies offering CDC equipment.
There would be many companies offering DEC 10; Compu-Serve, On-Line Systems and
First Data in Boston. In essence, there would be competition within the product lines of
manufacturers. In addition, one company could hardly service the entire needs of the
Federal Government. Over a period of about a year and a half, GSA accepted this idea.
GSA's acceptance of the multi-vendor concept came on Friday, April 18, 1975, as I recall.
We had an all-day conference with about 100 people at GSA to discuss a draft of some 400
pages which represented GSA's request for the industry's opinion about teleprocessing.
COMNET wanted that first contract, and, in fact on November 11, 1976, COMNET was
awarded the first contract for GSA teleprocessing services. We were unhappy with the
situation, however, because GSA did not make it mandatory. It was made mandatory on
August 1, 1977. At the time of the initial announcement by GSA, the government segment
of the market was reported by GSA to be between $60 and $80 million annually. That
amount is projected to grow in the 1980's to between $300 to $400 million. Now there
were, and still are, exemptions to that basic program. Facilities management, where you
provide an entire system or service are exempt from the GSA-TSP; batch services are also
exempt from that program. The multi-vendor philosophy, however, will turn the
Government business into a substantially greater amount of annual revenues than have
been predicted by some of the people at GSA. But I would like now to talk about some
changing elements. To my knowledge, the EPA contract is the largest Government
contract for services of this type in the country. The GSA-TSP has basic segments, one of
which is called the BA, the Basic Agreement, and the other is the multiple award
schedule. We received a $5 1/2 million contract from GSA, under the BA section, to
provide the Federal Trade Commission, for the next 60 months, with their entire data
processing for that agency. In this case, it is dedicated resources, not a dedicated system.
We find that the Government and the industry is maturing considerably. In the past, there
have been a lot of protests by losing vendors; we have done it a couple of times to check
out the system to see if it worked or to check out the new Freedom of Information Act. I
find that that works two ways, if you win the contract it works very well; the Government
agency works with you to protect your private information. If you lose a contract,
however, the Government works very well with your competitors to provide information.
This has been the subject of several court cases. The courts have ruled both for and
against private industry. There is no particular trend that has been established.
I think the government is trying to clean up the procurement process, and I think our
industry is trying to clean up its act, too. We do not really want to protest just for kicks.
We want to protest when we honestly feel it has not been a fair procurement. I think that
you will find that most of the protests are by incumbents who attempt to prolong the
amount of revenue by tying up the government. We do talk in the industry about trying to
GS-3
-------
eliminate this protest process because it takes a year to be solve. GSA, or GAO,
generally comes back and says, "You have a valid protest, and we think that you were
troubled in certain areas. However, because of the large amount of costs involved in
cancelling for the inconvenience of the Government, we are going to let the incumbent
continue."
In the future, I think the Government will move into more cost-plus contracts. I
believe the fees will be close to 10-12 percent. There will be more of this type of
contract, and there will be more contracts which require dedicated resources. This is the
reason why the BA portion of the GSA schedule was established, in order to negotiate the
requirements for what is needed for the services, other than the standard price list.
Basically, we have two different types of computers, DEC computers and IBM computers,
but we have eight computer systems. We have not been dealing with peripheral
equipment; we are moving more into an era of non-compatible or compatible IBM, but
non-IBM main-frames.
I am sure that your are familiar with the AMDAHL system, a very powerful system,
quite compatible to IBM and the ITEL system. COMNET has a 158-Mod Three and sitting
alongside is a 158-Mod Three equivalent. It is built by ITEL, and is about two to three
percent faster in throughput. And this is something we will see more and more. Several
of the service companies have already shifted and are using non-IBM main-frames. But I
think as we move into the late part of the 1970's and early part of the 1980's, we are going
to find that the industry will change the entire spectrum of services. We will get away
from what I call facilities management or dedicated resources, and go into total systems,
where we provide a service. That service contract for example, (our Navy contract is 36
months long) is a far cry from 30-day contract for a $100-a-amonth guarantee with
contracts signed by six other companies. Our EPA contract began as a 48-month
agreement, and by the 1980's should stretch out a bit. Our HEW contract is 42 months,
and our Federal Trade Commission contract is 60 months. We are talking about a
capability and a service that is totally different from what we have today, and one that
will go out ten years. We will be spanning the technology in communications, software,
peripheral equipment, mainframes, etc. and they will have to provide contractual
solutions. We are headed for long-term contract capability that provides a broad
spectrum of services.
I do not think the industry will change any more in the coming five to seven years
than in the last five to seven years; at the same time, the number of companies will shake
out considerably. Previously, I indicated that there are now some 32 companies that have
signed contracts with GSA; that is a fictitious number, if you look at it more seriously.
Not more than five to seven companies are seriously involved in competing for
Government contracts. One of those companies has six employers and a PDT 11/70. The
company President developed the software and works on the software part-time. We go
all the way from small companies of that type to very large companies. In the case of
our organization, however, we compete with about five to seven different companies.
There are exceptions, of course, but these are rare. All of a sudden some new company
will show up, but in the last 5 years, you can guess on any procurement who your
competitors will be. Looking at the RFP, you will say that Boeing will bid, AMS will bid,
PRC will bid, and so on down the line. This is changing. We are currently involved in a
procurement with a Government agency that is scheduled to be awarded by Christmas. It
is a three-year contract, but the companies are not the traditional ones. We have
companies like Rapid Data in New Jersey, Federal CSS in Stamford, Connecticut, Martin
Marietta in Orlando, Florida, etc. Basically we have always been involved in competing
GS-4
-------
with companies that are IBM. But we have CDC equipment and have CSC involved with
Univac equipment. We also have IBM compatible equipment. I think we will come into a
new era where you will find five to seven companies competing, but these will be different
types of companies. Then we will move into an era where the Government says, "We want
solutions. Do not tell us about hardware. Do not tell us about software. This is what we
consider as our data services requirement. We want you to respond to an RFP. We want
solutions. Do not tell us about feeds and speeds and hardware capacities."
Basically, that is where we are going in the service industry. By 1982, 1983, or 1984
we estimate no more than 10 suvivors as independents. Certainly, General Electric,
McDonnell Automation, Boeing (they are not considered independents) will be survivors.
Of the independents, there will certainly be not more than 10.
I think that the EPA-type contract has been questioned more than anything else by
the people with whom we now do business. Let me give you a couple of examples. HEW
paraphrased your Privacy Act requirements, word for word, paragraph by paragraph. You
will find that many agencies are simply trying to move toward the cost-plus contract,
toward the language you have in your contract in order to emulate your process. I don't
say this because COMNET is the winner. I am one of the guys who has been around town
since 1953 and did not really know the purpose of the blue-ribbon panel until after it was
over. I think the integrity of the process was given a big lift. No one likes to work on a
project where you know who the winners are, or you suspect you know who the winners
are. In the case of EPA, we, in the industry, felt that the procurement was totally
honest.
A typical procurement, if you really go out to win, takes about a $100,000
investment. Our company put in excess of $1 million into EPA procurement. We put that
money in the procurement because it was a very tightly controlled procurement of which
we would like to see more. Many agencies have asked us how EPA kept the process so
tight. We have explained all that we know about it, and we find them emulating that
process.
There is one other element coming into fruition in the government; namely,
algorithms. I was on a panel in New Orleans about a month ago, and a company for which
I used to work said that they had an algorithm consisting of 43 pages. It was so complex
that it was not important to pass out, or explain to the Government or the potential users,
because no one individual knew it. It was broken down into six different categories with
an individual heading up each of the categories. I was sitting next to a young lady who had
Category III. She had 13 pages in which she specialized. This brings up, I think, serious
problems and we have been addressing them in the Government. It's almost like trying to
determine a price by throwing a dart at a dart board. We sometimes have a diffucult time
coming up with a price and interpretation of an algorithm. We have been advocating
another element of pricing which has been adopted on two occasions. We think it removes
the subjectivity in pricing. The new approach has been, go to the vendor, talk to him. We
say, "This is how we have intrepreted your price; we have filled out the schedules, etc.
We want your confirmation that our number is your number." Then we get a letter saying,
"Yes, you have correctly interpreted my algorithm," or "no you did not, here are the
changes." Then re-run your model and come up with a number. I think that this approach
will be used more and more in the Government because it will at least give the industry
and the Government the confidence that they agree on each other's numbers. Thank you.
GS-5
-------
INTRODUCTORY COMMENTS
Willis Greenstreet
Our next speaker is David Morin, who is the manager of The Information Systems
Planning Service, International Data Corporation (IDC). IDC primarily does market
research for the industry itself, and also publishes Computerworld. Mr. Morin has been in
the business about 18 years and has a great deal of data processing experience. Before
IDC, he was employed by the world's largest manufacturer of costume jewelry. The most
interesting part of his bio is, however, the fact that he is in daily contact with the user
community who are IDC clients. With that I give you David Morin.
GUEST ADDRESS
David Morin, International Data Corporation
Thank you. I thank you for the opportunity to spread the word about distributed
processing. I also hope that you will not accost me as I leave the room because some of
the opinions that I will present will probably be a little bit different than what you have
envisioned as distributed processing.
Let me just briefly describe IDC. Basically, it is a 13-year-old firm who primarily
provides services to the vendor community. The company began by establishing data files
of just about all the computer installations in the country, along with what hardware was
contained in those installations, what size core was used, who the key people were, what
peripherals were used, etc. From that data base, we are able to conduct many surveys,
often with the Computerworld name associated with the surveys. Initially, we gathered
information for the vendors, then recently we found that the same information is of value
to the users who want to know what other users are doing in the same areas. In the past,
we have given the topic of distributed processing a great deal of attention. In fact, we
have sponsored two four-day conferences on the topic. Obviously, I am going to have
some difficulty condensing four days of material into a one-hour presentation. I might
also add, that Fortune magazine asked IDC to write a special article dealing with
distributed processing, for their March issue. The article was so popular that reprints are
no longer available. If you can get to a library, and look at the March issue of Fortune
magazine, there is additional material on distributed processing that you might find
interesting. I might also add that the November issue of Fortune carries a special report
on information networks in the office of tomorrow. It is not exactly distributed
processing, but it is a very fascinating article.
Well, let me get right into distributed processing. What is distributive processing?
Basically, it is buzz words. There are many, many buzz words. The computer industry is
the greatest generator of buzz words. Unfortunately, buzz words cannot really be
defined. The problem with a buzz word is that, for example, the vendors go to a user and
say, "What are you doing? What are your plans for the next three or four years." The user
will say, "Well I am going to install distributed processing." The vendor then sits down
with the user and talks a little about what distributed processing is, and what the user is
going to do with it. The user explains the plans clearly and concisely and then goes away
to talk to the next user. That next user tells him that he is going to install distribued
processing in the next year or two. He goes on, to describe how he is going to use it, and
the vendor gets an entirely different story. In fact, he goes away shaking his head, saying
GS-6
-------
one of those users does not know what he is talking about. Computerworld spends a lot of
time writing about what distributed processing is all about. In fact, IDC publishes a entire
newsletter on the subject. All in all, buzz words cause a lot of confusion. As I mentioned,
the users are planning to get involved in distributed processing, and they may have an
entirely different idea of what it is, than the vendor envisions. That is unfortunate for the
vendor because he is running back to his shop trying to design a piece of hardware or
software to serve the needs of distributed processing applications, and he is going around
in circles. IDC was asked to define distributed processing; and basically broke it down
into four basic definitions. First is distributed load processing; second, distributed data
entry; third, distributed data-based processing; and the fourth is distributed dedicated
processing.
Distributed processing by itself is very difficult to define, but these terms, we feel,
can be defined. Load balancing is a situation where you have a computer network. Today
you feed a job into any port in the network. The software or scheduler decides that the
job should be run on a computer located in Florida. Tomorrow, because of scheduling, or a
different set of criteria, the same job might be run in your own installation; the following
day it might be run in Chicago. You never really know exactly where the job is going to
be run.
The second definition deals with what we call distributed intelligent data entry.
This is where we provide enough intelligence at each remote location to 'provide
essentially error-free data entry. This includes involved table look-ups, a series of codes,
additional information, skeleton master file information and allows us to determine that
the data coming in is valid. It is corrected at the point of entry.
The third type of distributed processing is what we call distributed data-base
processing. This is where the data base is actually split up. A good example of this might
be Sears and Roebuck stores. They are located all over the country but the average
customer goes into the same store 99 percent of the time. Once or twice in the course of
a year, he might be traveling and might go into a different store. In that case, the
network allows the information from the primary store to be transferred over the wire on
that one-exception type of situation. Basically, however, all of the processing necessary
for that customer can be done in one store or at one location.
The fourth type of distributed processing is similar to the first, except that in this
case we may have different types of computers attached in the same network. Some of
them are large number crunchers, scientific types of computers; others have other
features allowing for business applications. Here the job is fed at any one of the remote
locations and is funneled to whichever computer is capable of handling that particular job.
In this situation, the same job will most probably be handled on the same computer every
time unless there is a duplication of computer systems throughout the network.
Out of the four types of distributed processing we have identified, there is one area
which we feel is most likely to be expanding, and that is the distributed data-base
processing. This is the situation in which you have your data base split into many
different regional locations where the processing is performed the majority of the time.
Thus, you have a network of processing nodes which are either functionally or
geographically distributed, but all inter-connected via some communication link or media
transfer arrangement. Now the data, as I mentioned, is spread among the nodes, and there
is minimal redundancy. The user at any node has access to the information stored at
another node. This is the Sears Roebuck example where someone travels to Florida and
GS-7
-------
wants to buy something, and they need to do a credit check. The regional center
processing the Florida application can access the information in Boston and transfer it
over the wire in this one-exception situation. One of the key advantages to this approach
is that you eliminate the majority of the communciation costs where the expenses are
rather high. If you have all this information at the location where roughly 80 percent of
the processing is done, that information never has to travel over the wire. Thus,
communication costs are reduced. You still retain the ability to send the information over
the wire, if necessary. The next element of this type of processing is a central control of
the system, and the development or acquisition of components. The key point to make
here is coordination. It is necessary to have this central coordination. Some of the users
with whom we have talked have had varying degrees of central control. Generally,
however, there has to be some sort of central control, otherwise payroll applications will
be redeveloped at each of the nodes and will not be compatible with one another. You will
have equipment acquired at each of the nodes that may or may not be compatible with
other equipment in the total network. It is more feasible to have central control to assure
that all these pieces fit together.
We have found that there are two general types of network configurations within
distributed installations. The first is what we call the ring network. From a hardware
standpoint, you have your computers located around the ring. You may have one computer
attached to the ring that is a little larger than some of the others for specialized
processing. It may house specialized software that may be needed occasionally, but
basically you have spearate and distinct processing nodes located at several areas with
access to all. The second configuration is what we call the star network. Here, you have
a large, central host computer performing the same functions as the large computer listed
in the ring nework, but all communication has to go out through the central host
computer. The satellite processes are disc mini-computers of one type of another. They
can do a great deal of processing on their own without very much interface with the host
computer.
There is another viewpoint to mention here. Management concepts are forever
going through cycles; one of the cyles is to question whether to centralize or decentralize.
Those that have their data processing totally centralized may find many of the
disadvantages that exist in that kind of arrangement. They may start drifting away from
the centralized approach and gradually convert to the decentralized approach. The grass
always seems greener on the other side of the fence. In any case, we are finding that not
only does management go through centralized and decentralized cyles, but the distributed
data processing environment does as well.
To go through the evolution of data processing within the industry for the last few
years, I will start with the second generation of equipment in the early 1960's. The trend
was toward a decentralized type of environment with stand-alone non-compatible systems,
located in major operating units of a company. During the third generation in the late
1960's, some locations started upgrading, and there was a move toward centralization. In
the early 1970's, we had a major effort to centralize the processing in these large
computer systems. The remote computers were replaced by telecommunications or
remote job entry terminals which interfaced with the large installations at central
locations.
Now, we are getting into the beginnings of distributed processing. We have gone
through the centralized approach; now, we are starting to get back into the cycle of
decentralization. A good example of the systems being decentralized are transaction-
driven applications. These are applications (for example the airline industry) where data
GS-8
-------
is taken at separate locations, and the whole operation is dependent on these transaction-
driven systems. If you have ever gone up to an airline reservations counter and been told
that their computer is down, you are very aware of the chaos which occurs. Many of the
companies having these large central systems are starting to find out how dependent they
are on the system, and how their company cannot function if anything happens to that one
central system. The trend, therefore, is going towards the decentralized approach,
although you still have a problem because your node can go down. In this situation,
however, at least the whole company isn't out of business as a result of it.
To carry this one step further, into the 1980's, we see the broader use of distributed
processing elements, a redistribution of the previously centralized applications. To
speculate further, we see computer networks where one organization will probably
interface with another organization, possibly a supplier with a customer, a customer with
his vendors, etc. Now, the advantages and disadvantages of centralization are just about
the opposite of the advantages and disadvantages of decentralization. Briefly, with
centralization, you have the economy of scale and processing; you have bigger and bigger
CPU's that process more efficiently and for less cost. You have lower total manpower on
certain tasks, and you have vastly better negotiating power as far as central buying is
concerned. You also have concentrations of vendor selection expertise, and you can
encourage uniformity and standardization within the centralized approach. Among the
disadvantages are that, sometimes a relatively simple task takes three days of debate and
three months of paperwork and red tape. Because of the large size of some installations,
they almost become non-responsive to the users' needs. With decentralization, you have a
high degree of local flexibility and maximum responsiveness to your users' problems.
Some of the disadvantages are the reinvention of basics, similar personnel at each
decentralized site rather than one person specializing in that task or function at a central
site. However, no matter whether you are in a centralized or decentralized approach,
there will be advantages or disadvantages. What we are working towards is balancing the
advantages and disadvantages of both. We have been both decentralized and centralized;
now we are starting to balance our approach.
When we get into distributed processing, we are going to need a lot of vendor
support. Mini-computers are a large part of distributed processing. We are going to need
new types of peripherals, primarily disc systems, to attach to these minis. There will be
different types of disks, namely, cartridges, floppies, and new disks that are not yet on
the market. Work stations, CRT's, and input units are other types of equipment that will
become a part of this new distributed approach. There will be a need for other peripherals
instead of the large, high-speed printers. We are going to need a lot of smaller printers
attached to the minis in order to be economical for the volumes produced on the minis,
but these will be different types of printers, then we are currently familiar with.
Software is another major area that needs to be addressed. The software for this
new distributed concept is different in the area of communication. You need specialized
software for the host computer as well as the network nodes, and new types 01 file
management software, and data-base management systems. The languages are also going
to play a key part. The mini-computers, for the most part, do not have extensive COBOL
usage; vendors will have to supply other, more usable languages. Each of the vendors has
the capabilities of providing these services, and they are currently working on them. They
are, however, running around in circles to some extent, because there is no generally
accepted standard throughout the industry as to what exactly distributed processing is. A
lot of people are concerned. They are hearing about distributed processing, and want to
GS-9
-------
know what it is all about. They feel that-if they are not involved with it, they will be left
behind. Frankly, distributed processing has to be a perfect fit or its not woth considering.
You need to know all the features that are key parts of distributed processing.
IBM is a key factor in anything that happens in the computer industry. It is
worthwhile to mention briefly what IBM's strategy is, or what their feelings are about
distributed processing. Are they for or against it? Well, basically they are for it.
Distributed processing means more computer power; there will be new application and new
transaction processing. IBM does not want to pass up any sizable business areas. IBM does
see the processing nodes, the mini-computers as being a threat to them to some extent.
There is a lot of revenue out there being spent on mini-computers, and they are not IBM
mini-computers for the most part. IBM is somewhat late in the development of mini-
computers and mini-computer software. In fact, the Series One announcement was
somewhat of a defensive move on the part of IBM to save sales that were going to smaller,
mini-computer companies. Within IBM, there are struggles to determine to whom the
responsibility for distributed processing belongs. Most of you have probably been dealing
with representatives from the Data Processing Division in your large central sites. You
will find, as you get more into distributed processing, that you will have to start dealing
with the General Systems Division of IBM if you are going to be obtaining the smaller
machines.
It is difficult to say at this time which division will provide the major thrust into
distributed processing, but you can believe that IBM is going to get their act together soon
and start pushing distributed processing.
Now, I would like to talk about some of the environmental needs of the distributed
system. The leasing, for example, of mini-computers is a new concept. Most of the mini-
computers in the past were sold for $25,000 to $50,000, or maybe a little more depending
on your definition of a mini-computer. Generally, they've been sold outright. Now if you
are putting together a large distributed processing network, and you are going to have a
dozen mini-computers or more distributed around the country, you are talking about a
large total expenditure, and you need to think about leasing or other methods of obtaining
this equipment.
Maintenance at varied remote sites is another problem. One of the companies with
whom we have dealt most heavily in our investigation of distributed processing was a
railroad. Railroad yards were scattered all over the country. The yards were dusty and
had extreme temperatures. Some of the yards were quite remote; as a result, the mini-
computer companies had to service capabilities at these remote locations. And
furthermore, there is the requirement of training personnel.
Now, another topic that has been mentioned is the capability of interconnecting all
of this non-IBM equipment to central CPU.
These are a few of the things that have to be considered when you go to distributed
processing. I mentioned earlier, a high-level language, like COBOL is not readily available
on the mini-computers, if you start implementing a distributed system now, you must
consider what languages people have to be trained in.
Now I will talk a little about what we have discovered about the actual
implementation of some of the systems. These are just beginning to emerge as
operational distributed processing systems. It represents a significant departure from the
GS-10
-------
typical data processing techniques with which we are all familiar. We have likened the
distributed processing concept to the industrial revolution of the past. There the focus
was on mass production; the key was transportation, and the result was greater product
availability. With distributed processing, the focus is on information handling. The key is
communcation; the result is greater information available to various managerial levels,
although it is only in its embryonic stages.
Distributed processing is an evolutionary outgrowth of telecommunications applica-
tions. Within the airlines, for example, they went from reservations to seat assignments
and fleet management. Within retail, they went from credit authorization to point of sale
and merchandise control. In manufacturing, they started with order entry, went to
warehousing control operations, and then finally ended up with plant and material
requirements planning. Thus, it is a phased approach that grows out of the recently
acquired teleprocessing expertise.
Now I would like to give you a little more information on how I obtained my
information. Basically, there were 30 user and 12 vendors interviews. Our research
library contains just about every article that was ever written on distributed processing,
and we have zeroed in on it, primarily because it is such a hot issue. I also mentioned
earlier our publications, such as the EDP Industry Report, the Distributed Processing
Newsletter, and Auto Transaction Report. In order to report effectively the news we
have had to address this topic in-depth. It is well in excess of 30 users that have been
interviewed at this point. Those 30 users were people who claimed that they had a
distributed processing system up and running or very close to running. Our biggest
discovery is that the users are very, very slow to jump to new concepts. There has to be a
significant, clear reason to go with distributive processing. Today's users, who are
considering distributive processing, are pioneers. They have to do a lot of work
themselves. They must have an in-depth knowledge of what mini-computers can do and
how they do it. Generally, they are large organizations with lots of money because it
takes a lot of money to get a distributed processing system up and running. It requires a
very significant commitment in dollars and time. There is a level of risk involved. The
whole system could be conceived and developed, and end up costing more and performing
worse than your present concept. Thus, there are warnings to be considered. The pay off
must be clear. It has to be very obvious that there will be a big payoff in this application
because there are a number of pitfalls along the way. If there is not a clear economical
advantage our warning is: "Don't proceed with D.D.P. just for the sake of being one of the
leaders in this area."
Today, there are pockets of experimentation in distributed processing. Not many
organizations have a true distributed processing system that is operational. There are a
few pioneers who are making attempts. They are benefitting and spreading the word. It
has taken these pioneers the better part of 10 years to get their systems planned,
designed, and implemented. The pioneers are generally those in naturally distributed
industries; namely retail, transportation, some manufacturing, the computer servicing
industry, etc. The insurance industry has been through a program of centralization. Now,
they find themselves at the point of starting to decentralize.
Quite often, distributive processing requires a major expansion of existing computer
facilities. That consideration is part of the justification of going to a distributive
processing system. If you have to expand your computer facility, you have to buy new
equipment in order to handle new applications. This is a good time to consider the cost
advantages of the distributive processing approach.
GS-11
-------
Lastly, but most importantly, is what we call the 80-20 Rule. This is a situation
where 80 percent of the processing is done at the distributed site, the remote site. Only
20 percent of the processing involves interaction with the central computer. Some of the
largest savings involved with distributed processing is the elimination or avoidance of
communcation costs. Communication costs seem to be rising steadily, and the distributive
approach takes advantage of that by avoiding the need to transmit data over
communcations lines from one computer to another. Some appropriate applications have
occured within transportation, in the retail industry, banking and manufacturing. The key
is that there must be very little interaction with the central site. Other ingredients are
new operational application requirements, generally not traditional applications (like
payrolls, general ledgers, or accounts receivable), expansion of your computer facility, and
the 80-20 rule. Then too a pioneering individual is required, someone willing to fight the
non-IBM arguments, someone who knows enough about mini-computers to go with the non-
IBM vendors who buck the general trend to stick strictly with IBM. Furthermore, a
significant commitment is required. Development costs are very high. For example, we
found the railroad had budgeted $45 million to their distributed processing system. A bank
to whom we talked had budgeted $30 million to the development and implementation of
their distributed processing system. There is a long time-frame, usually a phased
approach, a great deal of organizational involvement, and a significant amount of
interaction between managerial personnel at the remote and at the central site. There is
also a lot of coordination necessary to make all pieces fit together. Many of these
commitments will be reduced as more experience is gathered, but, at present it is still a
formidable task. In the future, we hope that the right hadware and software will be
available, and that it will be a much easier task to complete.
Elements involved in the implementation are, first, a study phase which for the
pioneers have covered a three-to five-year period. The selection and evaluation phases
take another year or more. Here it involves optimizing the price, size, and breadth of the
products that will be required. Pilot implementation takes at least six months, and total
system development, two to three years. Testing can take up to a year, and training and
installation can extend up to three years.
Why does it take so long? First there is the internal political environment, including
the non-IBM approach. Then there are software shortcomings, one of which is its
availability. In terms of personnel, there are not many people who are knowledgeable in
both mini-computers and larger business computers. There are definite geographic
shortages of mini-computer experts. You are also talking about implementing these
systems at remote sites. In Washington, there may be an abundant supply of mini-
computer talent, but in that railroad yard in some godforsaken place you may have a little
more diffuculty finding computer specialists. Lastly, there is a definite need for an
understanding of the overall operational aspects of distributed processing applications.
Now, I'll just touch briefly on some other areas of concern. First, the vendor
hardware is different than what you have probably been dealing with in the past. The
financing of that equipment, whether you rent it, lease it, or purchase it, also has to be
addressed. The D-P personnel costs of operations are different. In the past, you might
have had an operator who ran a console or mounted tapes. You are talking about someone
who is going to run a mini-computer at some remote location; he will be the D-P manager,
the operator, the programmer, the punch operator, and everything else, in one. He is,
most likely, a different kind of individual than you have had at your facilities with the
larger, centralized approach. Then there is inter-organizationl management time and
overhead. There's a lot of travel involved, a lot of calling back and forth, a lot of
interaction required in order to make all these pieces fit together. Probably, you will
GS-12
-------
need some outside consulting assistance, both in the software and the communications
area. You also have to consider the impact of new distributed applications on your
current existing applications. These distributed systems are not going to run by
themselves, without interfaces with existing applications. The more existing applications
that you have the more interfaces you will have to plan. Salaries are another
consideration. That guy or gal who is the sole data-processing department probably has a
different salary structure than those people you had in the traditional environment. You
may also have to consider some of your own service people in remote locations. For
example, you obtain a piece of equipment at a remote site but the vendor just does not
supply service. Some companies have actually trained their own service people to
maintain equipment instead of having the vendor do it.
Next, I will touch on two or three case studies. The railroad, as I mentioned, was
the prime example of distributed processing. Their application was for yard operations.
They had 90 railroad yards; 20 of them were to be automated fully. Their application
involved assembling and disassembing railroad trains. A block of trains would come in
from another yard, and it would be necessary to break the train up and send the various
cars in the right direction to build new trains. They were also involved with rate
calculations. The programs that calculate the rate structure for railroads are just
phenomenal. The amount of time that the car is on a particular track, how long it sits at
a siding, how many miles of track it traveled, the nature of the cargo, and hundreds of
other factors all affect it. Much of this information can be calculated at these remote
yards and does not require more than minimal information from the central site. Their
alternative to automating these jobs would require the expansion of their computer
facilities. They had to be on line 24 hours a day, because the railroad operated around the
clock. They met the 80-20 Rule, because 80 percent of the processing was done at the
yards. In this case, they did have what we call a pioneering director of MIS. He had to
fight the non-IBM equipment battle with management. But he also understood what minis
could do and how to make them function for him.
The host system that he had was an IBM 370/168 with three mega-bites, with the
second 168 primarily for back-up. He had to get car history information from the central
data base, but that information was passed along from node to node. Then he had to do
the car block assignments. He put in distributed processing at 20 of the 90 yards, using
Deck PDP-1145's. He used it for these block-to-track assignments. The data-base
information included tonnage, flags for dangerous cargoes, etc. The work was scheduled
over three shifts, and he had to keep track of industry zones through which the car moved.
Some of the other network elements included inquiry points which consisted of 3270's to
access the car history. Some of the freight stations had INCO-TERM terminals. Data was
entered on these terminals for centralized rate calculations. These were in the yards that
were not fully automated. Incremental cost trade-offs for the centralized alternative
were negligible as far as equipment was concerned, but as far as communications were
concerned, this application would have been four times more costly on a central, rather
than a distributed approach. His total one-time cost for distributed processing ran
$415,000 whereas the tele-processing approach was at $1 million. On a monthly basis, the
distributed processing approach ran $83,000 versus $150,000 for the tele-processing
approach. He used the 80-20 rule for his primarily communications cost to justify the
entire application. Computer-room expansion was going to be required; system
survivability was also a key factor. If a central site went down, the entire railroad was
out of operation, whereas if just one node went down, he was in a much better position to
continue to operate the remainder of the railroad.
GS-13
-------
The system survivability problems that we mentioned earlier were the maintenance
availability at remote locations; unfavorable physical environment for computers-
temperature, dust, and humidity. The power requirements were not always adequate, and
administrative control was a problem. A lot of that control had to be handled centrally.
At some of the remote sites, he had no console operator; and they had to do a lot of their
diagnostics via communications lines from these remote mini-computers. They also had to
write a lot of the software in the Basic language.
At this railroad, they committed $45 million, and have spent $35 million to date. As
I mentioned earlier, they were implementing this program in a phased approach, so that
there are still segments that will eat up that additional $10 million in the next two years.
With them, it was a 13-year time frame from study to the end. Approximately 260 people
had to go out and train 6,000 others in a 60-day period. Now, the future extensions that
will eat up the additional $10 million by 1979 are the complete automation of empty car
assignments and total car scheduling from dock to dock.
Another example is a paper manufacturing company that we observed doing a pretty
good job as far as distributed processing is concerned. Here, 30 out of 65 of their plants
were to be automated, using Four-phase computers, System 3's. Their centralized
applications were primarily financial; decentralized applications involved marketing and
production. In this company, the key factor in the justification of the distributed
approach was management's philosophy that if you give a guy his own computer, he will
run it and manage it more efficiently and use it more effectively than he will if he has to
use one at a central location. That was their philosophy. Their distributed data base, in
this case, involved payroll. The gross pay was calculated locally, but Federal reporting
requirements were handled at the central facility. Incidentally, they kept their summary
files locally in this application update, or summary, transactions were fed to the central
site for statistical purposes and other reasons. Their justification was primarily the
management philosophy that each location would make more effective use of their own
equipment and make better decisions based on use. The majority of their communications
were handled overnight, using voice-grade WATS lines. Very little of their communication
was necessary during the day. Also, they were required to expand their existing facility if
they were to consider the new applications; that was another factor in making them
decide to go with the distributed approach. Because this company's application was
relatively simple it was a comparably shorter implementation period. The study took four
years, the vendor selection three months, the implementation three months, and the
installation two years. In this particular company they did not keep accurate records of
the costs strictly related to distributed processing; I cannot tell you exactly what it cost
them to put in their system.
My last example is an automotive assembly division. Here they were primarily
interested in controlling their material requirements planning. Their justification was
accuracy and the communications costs. They felt that it was a negligible increase in cost
by using the distributed processing system. In fact, a cost analysis showed that they saved
$250,000 a year over the central approach, particularly on communications costs.
In summary, the underlying threads to a distributed processing system involve
transaction-oriented applications, not the conventional batch data-processing applications.
Generally, the development of a distributed processing system is an expensive, political,
cumbersome thing to implement. It is very slow to evolve. It has to be justified in detail,
with users looking at all of the alternatives, .because of potential pitfalls. It requires an
in-depth study of all the alternatives to be sure that you're not walking down the wrong
GS-1*
-------
road blindly, and it has to be implemented with minis for data entry, inquiry, local
processing, terminal handling, file handling, and communications with the existing
network. Specific industries which seem to be most appropriate for distributed processing
are railroads; retail applications primarily involved with point of sale; banking, with some
unique situations; and the insurance industry, where distributed processing is in the
thinking stages. The computer services industry offers many advantages to distributed
processing, and many of the computer services industries are taking the lead at developing
applications to make use of distributed processing. In many cases communication service
bureau applications are being considered for minis; in order to not lose the kind of
businesses, that are implementing the minis themselve. Some service bureaus are putting
together the software and the applications necessary to continue servicing the small users
with a mini-computer on-site, with heavier processing power available back at the central
site. Within manufacturing, the application area is somewhat mixed, although materials
requirement planning seems to be the primary area.
That concludes the material that I have to present to you. If there are any
questions, I will be glad to try and answer them.
GS-15
-------
QUESTIONS AND ANSWERS
Question: How about something like social security?
Answer: Yes, social security would seem to be distributive. In fact, they are
doing a lot of processing in regional centers; I am not sure just how much
interaction they would need to have with the central site. I do know,
however, that almost everything involved with social security does go
into the central site at one time or another. Government agencies are
large, have much computer power, and are distributed all over the
country; it seems as though they fall into a distributed prospect
category.
Question: Wouldn't there be military applications, like intelligence-gathering,
satellite-tracking, etc.?
Answer: Well, I'm sure that there are many applications that are appropriate
within the Government. I am sure that the Government is definitely ripe
for distributive applications. I just do not know which of any agencies
are doing what at this point.
Question: I was wondering what the mini-computer companies were doing in regard
to the software standarization problem?
Answer: It has been my experience that the vendor himself is not doing all that
much, as far as the software is concerned, he's leaving it up to the user,
the OEM companies, or the software houses to develop software. I would
think that it would be in the best interests of some of those vendors to
attack certain kinds of software, at least the software typically involved
with distributed processing.
Question: Could you raise the issue of centralized versus de-centralized manage-
ment orientation? What are your thoughts on the compatibility of the
centralized management orientation?
Answer: / feel that there has to be central control, otherwise all the pieces will
not fit together. The development of that software or of the system can
be performed at distributed locations. It has to be controlled, however,
by some central site in order to insure the compatibility and the
uniformity of all the interfaces.
GS-16
-------
PANEL A: DISTRIBUTIVE PROCESSING
Chairman: Theodore R. Harris MIDSD, Washington, D.C.
Panelists: Bruce Almich CSSD, Cincinnati, Ohio
Fred Kastner NCC, Research Triangle Park
Mickey Cline ORD, Athens, GA
Curtis Lackey Region IV, Atlanta, GA
Joel Brandon Region V, Chicago, Illinois
Dennis Schur Region X, Seattle, WA
Steve Goransen Region V, Chicago, Illinois
Jim Hammerle OAQPS, Research Triangle Park
Jim Susha WPO, Washington, D.C.
OVERVIEW OF DISTRIBUTIVE PROCESSING IN EPA
Theodore Harris, MIDSD, Washington, D.C.
I have assembled eleven people who will be making presentations on their views,
actions and plans for distributive processing in EPA. The goal for today is to share what
we are doing, who is doing it, where we need to go, and what major issues we need to
resolve. First, I would like to give you my view of what we're doing.
I do not like to use the words distributive processing; it is against my anti-buzz word
philosphy. The way I visualize it is as a hierarchical set-up with the host computers
playing major data-base roles. Using a map of the U.S. which shows EPA's organizational
structure, one can see that we are greatly geographically dispersed. This is one of two
charts I have on the host computers. I think it is dated May. It is a complex environment
with hardware, software and many people.
This is a similar configuration chart with Univac equipment for our National
Computer Center (NCC) in North Carolina. This shows the four by two configuration for
the Univac 1110. It will soon go to a four by three. It is also very large and complicated
with a lot of equipment and people. This is a better descriptive chart which shows the
flow of the data automation up through the hierarchy. You can look at this several ways.
From top to bottom is the way we are currently looking at it, from headquarters with the
national systems running from large computer centers, gathering data either through this
mechanism or places in between. If you look at it as you go down, the different
responsibilities and authorities in the agency change as you go down to the field level. I
would like to show the lab view because the more that I learn about the agency, the more
important role I understand that they play in what we are doing and where we are going.
The direction that EPA is leaning—maybe already there—is to automate fully from source
data, through automation control to the locals, i.e., local mini-computers, then to the
National Data Base Systems.
There are two mini-computers identified on the chart. The PDF 11-70 was selected
via the EPA standard terminal contract that was competitively procured two years ago.
A-l
-------
The Data General Mini-computers was a similar procurement for laboratory automation. I
will talk about the PDF 11/70's and their particular role in distributive decentralized
computing. This chart shows the goal and the purpose of what we are doing. The
procurement did was entitled called mini-computers: it was called a remote job entry
(RJE) Terminals with concurrent local processing. The goals and the purpose were to
support distributive processing, distributed in the terms of local data entry, local data
management, and a decentralized data base management. The justifications for sites have
been mainly on data entry and some small processing at the local level. Goals of lower
cost to the agency and the provision of an agency-wide procurement mechanism were
identified in this presentation. We have accomplished, these goals by providing an agency-
wide contract. We currently have five mini-computers installed and one on order. This
chart shows that all, except one, are connected to both computer centers. The chart is in
color showing how they are connected and the speeds. There may have been one or two
changes since the slide was prepared; The changes would have been instead of two 4800
band lines, one line at 9600 would be going to either place. Starting at the lefthand
corner, the Cincinnati system in our EPA test support site. The others are installed in
Athens, which is a research lab; Atlanta, Chicago and Seattle, which are regional offices;
and another in Gulf Breeze. The little arrows pointing in are dial-up lines into the mini,
however, most of the terminals are locally-connected. They are hard-wired. You can also
dial into the mini-computer to give flexibility.
The concurrent functional activities were defined in functional terms. They were
remote job entry (RJE) to support both IBM and UNIVAC. IBM - HASP is the facility that
allows you to do multiple things simultaneously while connected to the central computer.
You may check status to find out where your jobs are. The UNIVAC 100^ emulator is
currently being replaced by the Nine Thousand Remote (NTR), but when this procurement
was done, these were the requirements. In addition, we required some FORTRAN and/or
BASIC to do some statistical calculations for small one-time modeling.
Our third requirement was for data management. Data management and data-based
management are buzz-words that have different meanings to different people. I will give
you mine. A Data Management System (DMS), it has three aspects: data entry, on a
screen or a CRT that provides for formating and validating of data entered; a storage
facility to keep up with the files; and the data elements within the files to provide for
sorting, searching, some manipulating of data, and a high level language for a report
generation. This facility was a desirable option in our recent procurement; however, the
winner did not provide it. EPA then went out with another procurement for a Data
Management System (DMS) for the agency. We awarded this competitive contract to
United Computing Systems, Inc. They have been successful in having a Data Management
System running on Control Data computers. A year and a half ago, they decided to
implement on the PDP 11/70. It is the same exact language. The chart shown is to give
you a better definition of what it is supposed to be, how data-based management is a part
of it as opposed to the other way around. The data is in the middle with the data elements
identified. You can either enter data in or take it out. You can manage it by backing it
up, moving it around, or you can manipulate it, and then produce reports. One copy of
the data can be accessed in multiple ways. It is not something as complicated as DBMS-
1100, or System 2000, but something simple, quick, and easy. The Digital Equipment
Corp. contract allows us to buy most of what equipment that they sell. We have
determined a standard configuration, so that we can share software, have the same
standard operating systems, and experience most of the startup problems at our test site.
To put in a complete package consisting of hardware and software, is our goal for all
future sites.
A-2
-------
This chart shows the software pieces involved. This chart gives an indication of the
software side. Looking from the top down, (of the pyramid). At the top is the operating
system, IAS, underneath are the two remote job entry (RJE) emulators that talk to the
central sites either one at a time or at the same time, or to multiple sites at the same
time, depending on communication lines. The next level of interfaces of software are the
user-related pieces. The point here is that it is a complicated computer, but simplified
down to a smaller scale.
Everybody in the field has their own buzz words and even though the title of this
talk is called decentralized computing, I would like to call it Balanced Computing. EPA
needs to look at each of its applications on an individual basis and decide which
application pieces or total application go on which computer. This is the idea of Balanced
Computing: allowing that flexibility. I think the way we are going, the data entry pieces
are working out very well on the mini-computers. I would like to raise the issue of
distributed data bases and how EPA should keep them in sync with the National Data
Bases.
We want to be sure that we do not duplicate applications. Since the equipment and
software are the same, there is no problem in taking modules and running them on other
systems. We are working in the area of a standard development approach, and a systems
analysis attack. We are also looking at standards for documentation for minis common at
an EPA mini-computer managers' meeting about a month ago, we came up with the
concept of a Documentation and Distribution Center. The center is to document
programs, have it at one location for all of the other centers and publish abstracts of the
programs.
Before I call on the next speaker, I have some information for those people that do
not know what mini-computers are. The first part is for those who have never dealt with
laboratory automation. Then I will discuss some instruments and some automation
interfaces.
A-3
-------
CINCINNATI TEST SITE EXPERIENCE
Bruce Almich, CSSD, Cincinnati, Ohio
I would like to say a word about
Digital Equipment Company's IAS and how
EPA selected it. How do you come up
with an operating system for the hottest
mini-computer architecture? We ended
up with IAS, because of its concurrent
capabilities of real time and batch pro-
cessing. That is very difficult to do in a
single CPU. Luckily, the hardware archi-
tecture lends itself to that. Further, IAS
seems to fall out mostly because it was
the only system for which we could buy
off-the-shelf communication software.
When we got IAS, we realized that it was
very easy and quite necessary to learn
quite a bit more about the internals of the
operating system. We realized one of the
points addressed in relation to mini-com-
puters is that one is not dealing with IBM.
You have to hold your own hand. We
found that it is as complex as any
operating system, running on any other
machine in the agency, with the exception
that there is not quite as much parallelism
going on. As far as the types of systems
work that needs to be done, it's in the
same ball park with the larger systems.
Our machines showed up about a
year ago and we brought up the release of
IAS, Version 1.1. Apparently One Point
Zero was unusable or unworkable. One
Point One was a much better system; it
worked quite well.
In January 1977 it was generally
revealed to my group through Ted Harris
that DEC would be willing to let us test
site release Version 2.0, which was the
next revision. We seized the opportunity
mostly because we saw some bugs in One
Point One. The plan was twofold: First,
to try to plan for conversion and find out
what types of things we should not write
to maintain state-of-the-art with the
operating system; and second to help DEC
find bugs in their own system by partici-
pating in their test site activities where
you send in quality assurance reports on
their software. It was about February
when Two Point Zero came in and we got
it running. At the present time we have
put up the release version which has come
to all sites within the last couple of weeks
and it is a very stable operating system.
I am certain that all of the regions
have much more accurate data than we do
on the uptime of their system, but I do not
know of any site that has an uptime that
is available to all users of less than 90 to
95 percent during the work day or after
hours. The Two Point Zero test site
experience was very positive for us.
We do agency-wide support, mostly
in helping people get started. When a site
gets started, either they have come from
laboratory types of mini-computers and do
not know a whole lot about ADP, or they
have come from larger systems and do not
have that much expertise in ADP mini-
computers. They are finding that the
personnel skills required are condensed
into a smaller number of people than at a
central site. Usually at a site, you have a
systems technical manager, a telecommu-
nications head/systems programming
head, who puts in the patches to the
operating system and maintains liaison
with other sites in an effort to find bugs
in the system, even in the application
software. Mostly, our efforts have been
geared toward pre-delivery training and
bringing people up to speed on the operat-
ing system. There are some variations in
the configuration that some of the sites
have come up with, mostly because they
have different volumes of processing re-
quirements like tape drives.
Other types of agency support that
we've been providing is also along the line
of trying to develop transportable utilities
in the system-level software. At this
-------
point we are developing a telecommunica-
tions software processor which interfaces
with the communications emulators.
Hopefully we will provide a high degree of
automatic communication between the
PDP-11 systems and the agency-wide
large systems and between PDP-lls and
laboratory automation computers. Our
operator is going to retire in a few more
weeks, and we are trying to replace
between 20 and 50 percent of what she
does with the automatic capability within
the PDP 11. We are dialing the R3E data
phone automatically, and answer it auto-
matically. We want to send files to and
from the host without having to order
them individually, or involve the operator
and user.
As far as our plans go we have
installed, are de-bugging and testing the
Data Management System called
INFORM-11. Test time is now available
to anyone who wants to get an account
and try it out. Some previous knowledge
at the user level of IAS is necessary.
Most folks who have been using it are
those who have either ordered it or will
order it shortly. They want to get a good
feel for the size of the application with
which they can get by. on a PDP 11. We
also attempted to evaluate INFORM in
terms of fitting it into the environment of
concurrent remote job entry. We need to
know how many users we can support, and
how big the application can get before any
one user begins to take over most of the
system. The final released version of
INFORM, at least the one that will be
delivered to all the sites, is in Cincinnati
now. It resolves most of the bugs on our
bug list. Next week, we are having a
training session in Cincinnati to kick off
the applications development. At present,
most of the INFORM applications being
worked on are not things that are being
stored locally, but rather are data entry
and reduction systems for the large hosts.
I am really excited by future
prospects of this project. I look forward
to the time, about a year from now, when
it will be technically possible to put a
dedicated mini anywhere for a data base
of a certain type. One case that comes to
mind is the Federal Reserve Bank in New
York. They have the world gold supply
data base on one mini. I understand that
ERDA is looking into that type of
approach for the plutonium supply or
other nuclear products processing. To me,
it is very exciting because reliability of
hardware no longer becomes that much of
an issue. People fighting for resources on
a large central machine no longer
becomes an issue when you get down to
the matter of using the machine to meet
Agency needs as the main idea. I will now
respond to questions you may have.
A-5
-------
QUESTIONS AND ANSWERS
Question: I don't understand transportability.
Answer: What we have been doing is, as we are developing something or before we
we start to write down something about it which describes, we see if
there is interest at the other sites. In one case, there was a magnetic
tape utility. Now everyone seems to want to take magnetic tapes of
various types and formats and put them in PDP-11 format, play with
them, and send them off to NCC or WCC or read an NCC tape. To
develop a transportability or a truly versatile mag tape usually takes a
while. We try to identify these areas. The way it proceeded up until the
first mini computer conference was that someone would say, "I think I
am going to do this. Does anybody object?" or " This is a functional
description of what I am going to do. WouZd you use it? " If a couple of
places say they will use it, then they say, I will do all the documentation,
all the comments and make this usable by everybody At the applications
level, the mini-computer managers' meeting will put all of the
applications that are more than two to three person-months of indicated
effort up on a blackboard, and pick them off and identify a given site, a
given person, usually a given site with various applications. My
application, at this point, is to work a laboratory sample management
program for the regional laboratories. There are various administrative
systems that have been dealt with in the same way.
Question: Do you support any training activities?
Answer: We consult with you on what you should take from DEC before you get
your system. We have a two- to three-day training course in Cincinnati,
where we teach your system manager how to supervise the installation of
the system, do his system manager duties, and how to train the end users.
Basically, it is an orientation, a three-day course where the system
manager and operations chief will overlap during the second day.
Most of the training is available at DEC, but DEC has extremely limited
hardware and system availability in their training sessions. People who
have had this before take the lead and try all the new things they want to
try. People who have not seen it before generally get scared and do not
try anything. In the lab sessions and the lecture, you do not get that
much hands-on experience; you do get free training with five person-
weeks of training credits, with your systems, plus a week of on-site
training for a dozen people who are presumably your best users. We try
to picfc up all the loose ends with that training and try to make it a good
package, tailored toEPA.
A-6
-------
THE EPA TELECOMMUNICATIONS NETWORK
Fred Kastner, NCC, Research Triangle Park
The communications portion of the
COMNET contract was awarded last
December and called for a single nation-
wide telecommunications network to
replace and combine the services provided
by Optimum Systems, Inc. (OSI) and the
National Computer Center. OSI services
have been replaced and COMNET is still
working on completing the access to the
Univac system at NCC. When we got
ready to install the network, we took the
latest statistical data from OSI and the
National Computer Center, combined it,
looked at it, and then decided where we
wanted to put in dedicated facilities. We
took the COMNET proposal and imple-
mented the network based on three nodes:
COMTEN communications processors in
Denver, the Computer Center at
COMNET headquarters, Washington, D.C.,
and the National Computer Center down
at RTF. The network has two phases; one
for high speed batch work, and one for low
speed access. Presently, the COMTEN in
Denver and in Washington are connected
over a 56 KB DDS circuit (Digital Data
Service). The circuit from Denver to RTP
is not yet installed, although we expect it
to be operational at the end of January
1978. It will also probably be a 56 KB
DDS. The circuit between the Washington
Computer Center and the National Com-
puter Center will also be DDS; it is not
yet installed. Currently, in its place, are
six 9600 BPS dedicated circuits. What we
have now is the three COMTENS
connected by just the two circuits from
Denver to Washington, from Washington
to RTP.
The remote sites have batch
terminals, Data 100s, but also some of the
sites have mini-computers, the DEC
machines. In most of these cases, for the
high speed network, there are 9600 band
lines, using split stream data sets to use
half of the lines for Washington access,
and the other half of the lines for access
to the Univac system using the 1004
protocol. That portion of the network
software is not yet available. COMNET is
testing it and they indicate that it will be
ready by the first of the year.
The interactive portion of the net-
work is a little more complex due to the
large number of users in the field. There
are things that we can do with low speed
communications that we can not with high
speed. Basically each remote site has a
multiplexer that will take a number of
low-speed terminal sites reached by a
local dial up within that city, and concen-
trate, combine it onto a higher speed
circuit, and send it along the way. Some
of the circuits are rather complex in that
they have more than one drop, and will
eventually terminate at one of the
COMTENS. We can reduce circuit costs
and also provide local availability in this
multiplex concept. COMNET is having
some problems with Timeplex equipment.
When you think about all the vendors
involved with this, Timeplex, as well as
General Data Comm and virtually a
different telephone company for every
site, I can sympathize with them, but they
proposed the system. They believe it will
work; they are convinced that it works
now. One of the priorities that we have
established with the contract is that even
though the services may work as far as
the COMNET's concerned, if the user can
not get the job done, then it is worthless
to us. We have started several programs
at COMNET to make sure the users are
satisfied. Hopefully these things will
clear up. With the amount of equipment
involved, I think it will take a little time
to stablize. Basically though, it is a good
network, and I think it will provide the
services we require.
As I indicated, each remote site has
a multiplexer with local dial capability.
We did this for availability in order to
A-7
-------
enable the user to dial a local telecommu-
nications access number, and get on the
network, not only for the EPA office, but
for any other state, contractor groups
within the city, or any groups that can
access the local number. For those people
who do not have dedicated equipment, and
this is true for the batch services also,
COMNET provides WATS lines, all homed
in Washington that enable the user to get
on the system. Once you get the data
tone, the user merely indicates with which
system he wants to process, then the
logical connection is made. As of last
Monday, 30 CPS or interactive usage low
speed is available to both centers. We
brought up Univac last Monday, and found
some minor problems with it. There are
some isolated cases where Timeplexers do
not work, but, we are working on this. All
in all, I was pleased with the way it did
come up last Monday. COMNET is pre-
sently working on 1200 bps access. They
will support the new Bell 212 full duplex
1200 band modem.
COMNET is also working on the
Univac 1004 software, and expect it to be
ready the first of the year. As soon as
they get that done, we are going to ask
them to support NTR which is Univac's
new RJE protocol. All this is working
towards what we eventually hope to have
as common protocol. The remote user at
the RJE terminal will load in one emmula-
tor deck and will be able to get on at both
centers. It will probably be an ASC 11
protocol; we are not exactly how to get
there, but NTR is certainly a step in that
direction.
Another item, within the next 6
months, is the request from COMNET
about the recommendations and feasibility
on intercomputer communications; i.e.,
being able to move data and data files
directly from one host to the other.
Bruce's mini-computer in Cincinnati
offers a way of doing this. You sign on to
the IBM system and unload files, then sign
on to Univac and send them down to us.
We would, however, like to see a way to
do it directly; it is one of the items on
which we will be working next year.
We have also prepared an EPA, NCC
WCC Interim Telecomunications Users
Guide. The NCC user should have this
booklet and the WCC users will receive it
shortly. It briefly describes the network,
lists the phone numbers of the multi-
plexers in the remote cities and the WATS
lines for the different speeds of access. It
talks about sign-on cards, site I.D.'s, user
I.D.'s, who to call if you have problems,
and what certain messages mean coming
out of the COMTENS. This is an interim
guide and will be replaced with a formal,
more sophisticated document probably in
February. It will come out as part of the
WCC users guidebook. The communica-
tions section will be independent so that
we can take it out and make it available
to the NCC user community as well. The
WCC user community should be getting
their copies probably next week. This
booklet should help considerably in letting
you know what the network is all about
and what we are trying to do with it. If
you are having problems with the
COMNET network, the best thing to do is
to see me after the session. One of the
problems we have had is that COMNET
assumes that things are working when
they are not. The only way that they can
find out about about the problem is for
you to call and let them know.
A-8
-------
QUESTIONS AND ANSWERS
Question: Did you look into using a commercially available network, like Telenet
and Tymshare instead of inventing your own network, protocol, etc.?
Answer: This is what COMNET proposed, and we went with it. Their back-up
system or alternate system, actually does use one of the existing
interactive systems. We are trying to get the users off of it, because we
would like to use the primary network, the dedicated facilities, in order
to pinpoint workloads and find out for sure where the requirements are
and where we need to make changes in the network.
A-9"
-------
PROJECT INDEPENDENCE: DATA PROCESSING CAPABILITY
D. M. Cline, ERL, Athens, GA
Back in November 1976, President
Nixon proclaimed his Project Indepen-
dence to deal with the energy crisis. The
very same day, I stood up and proclaimed
Project Independence for data processing
capability in Athens. The reason I did
that was because I was using OSI and the
General Time Sharing Utility (GTSU) that
we have had all along. I didn't like it
because the response time was very poor.
Turnaround times for jobs that required
large memory requirements were always
over my response. You could not use the
system after midnight, or on Sundays, and
some people work at those hours. They
also did not have a plotter; everybody
needs a plotter and they had a poorly
supported, interactive development
system, TSO.
We did a little feasibility study, and
the adoption of Standard Terminal IVB
was justified on cost because we are cost
effective. We did not look or explore the
intangible effects of having our own
facility, because evidently you can not do
that in the feasibility study. You had to
justify all the dollars, and we did just
that. We finally got our mini ordered in
September of 1976 with MIDSD's consider-
able help. It was delivered in late
February, 1977. It took a few weeks for
the manufacturer to come out to install
the system, and as soon as they did, we
started using the system.
How do we use that system? First
of all, we started converting every appli-
cation that we had at OSI to a local
system. As it turned out, it is quite easy
to do, using one of the Agency's approved
languages.
Some of the things we do on our
system, I think, are pretty nice. We can
reconstruct a gas chromatogram from a
GC/IR system. This means that, in the
past, the scientist could only acquire data,
or analyze data, but not both at the same
time. Now, I can acquire the data, bring a
tape, and while he is acquiring more data I
could be doing the analysis on the mini-
computer. We couldn't do that analysis at
COMNET because it takes approximately
9 million bytes of data to do that. That
means we would have to sign on COMNET
and hope that COMNET did not go down,
the communication facility did not go
down or our remote job entry terminal did
not go down. We have also done all our
mathematical modeling. We have a large
environmental chamber in our facility,
where we control all the environmental
parameters. We have developed models of
that system, all running on the PD 11/70.
We can acquire data from the environ-
mental chamber and from a mathematical
model with simulated data and plot both
on the same graph. We have several
interactive programs that do that.
We have also re-evented the wheel a
little, by implementing some of the
graphic techniques available on
Mathematical Modeling Labs on our mini-
computer. We have a comprehensive set
of graphic routines which support our
programs in the terminals. The benefits
of the system are manifold, because our
program analysts have really increased
the productivity as opposed to doing
batched program development. People
consider it a terminal and operate it down
to a 60 character a second, as opposed to
the 30 character a second, system we
have at OSI, where we could edit a job,
wait for it to come back and better it.
This way you find out immediately if you
have a mistake or not. On the IAS
system, we do have the batch capability
and we develop our programs
interactively. We then select the job for
batch processing. The turnaround is very
good because there are a few people in
the Athens lab and there is a lot of time
left over from the program development
A-10
-------
activities. Graphics are great. All our
graphics are done at 9600 BAUD as
opposed to the 300 BAUD at COMNET. A
month before our mini was installed, we
were spending $6,000 or $7,000 a month,
with a high of about $9,000 or $10,000. If
you look at September, we're down to
about $87 at COMNET. That is quite a
savings in money.
In our Zero-Based Budget (ZBB) for
1978, $276,000 was allocated in our labo-
ratory; once these savings were known,
however, it decreased to $72,000.
One disadvantage of our mini-
computer is that we are running on a 16-
bit mini-computer. When you have that,
you are limited to a 32K word address
base. This means once you start working
on large problems, you continually have to
contend with overlay systems. With
modern technology, there are at least
three mini-computers which support a 32-
bit word line. If we had that, it would
eliminate many of the problems that we
are encountering on a daily basis, both in
terms of the instruction set and the
overlay problem . And there's one huge
software gap in our system. We do not
have a local statistical analysis package,
like SAS and SPSS. Other than this we
love the new mini.
We are doing a little something in
the area of distributive processing. First,
we are trying to tie all of our dedicated
mini-computer system into our mini-com-
puter for report generation, data analysis
and program storage, in order to load
programs on PDP-8's or our POP ll's.
Second, in January, we are doubling our
memory requirement. We will be able to
prepare some of our data locally, transmit
it to WCC for processing and then get the
information back. The only thing that we
do at WCC, by the way, is FMD.
In summary, Standard Terminal IVB
has done more for giving our laboratory a
hardware-software capability than any-
thing else. MIDSD should not drag its feet
now. During the 1980's, they should
include 32-bit mini-computers in their
distributive processing network; on the
more immediate front, they need to rally
and get a staff package. I am very happy
to be a part of the Standard Terminal 4B
adventure; I believe that my Project
Independence policy has provided a good
hardware-software capability, as well as a
cost effective measure.
A-ll
-------
12,00.
10.50_
WCC EXPENDITURES
QC
CC
Q
9.00 _
7,50 _
..00 _
4.50
3.00 _
1 ,50
o.oc
11
I I ':
I ' '•
' 1 I .
OCT
NG-/ ' -DEC JflN ' FEB
MINI INSTRLLED
$87
i— —r
MRR flFR MflT JUN
JUL RUG
-------
AIR QUALITY TRACKING SYSTEM
PDF
Steve Goranson
This is a road show that I gave
several times in a couple other places. I
am going to talk about the PDF world.
This series of programs is very simple.
The reason that it is successful is that it
is simple; it uses simple language and it is
compatible with other systems. It is
somewhat transaction driven, because I
deal with input records that are at a base
level. The PDF also provides quick
turnarounds and analysis. Mostly we will
be dealing with small data sets.
Air quality data is handled by NADB
in its entirety. The problem is that the
regions took over the editing cabilities
and handling procedures from the state
and local agencies. We are required to
give NADB a clean data set. The first
purpose for this "system or series of
programs" was to create a clean data set.
It was initially designed on the Univac,
and then on our PDF. Basically, we
jumped in at the basic edit level and tried
to provide trunaround to the states and
local agencies as quickly as they gave us
the tape. We hope we are at a point
where one man can bring up a magnetic
tape with his quarterly report. Attend a
meeting in the morning, and we can return
a summary by noon. To reiterate the
needs of the system: initially, we wanted
a quick response on special projects. The
analysis includes some complex
summaries, air quality standards requiring
non-overlapping periods of analysis. Pri-
marily, it is designed as a regional
tracking mechanism, whereby I can
interact with (unintelligible), and to a
lesser extent, management. I am in
surveillance and analysis, and we pri-
marily handle the data and supply report;
it was really out of their request that I
designed this particular series of
programs. Trend analysis is something
that was built in somewhat latter. Jerry
Miller designed a program which operates
on the Univac, and does trend analysis on
the air quality information. At present, it
is not usable on the PDF, because it is a
COBOL-driven program. It is, however,
available on the Univac; In fact, all these
programs are available on the Univac.
By turning around the data the same
day, there is no question as to what they
had submitted to us. Grant funding
required us to submit a certain number of
sites and a certain quantity of data.
Validation of verification is very, very
important. The region is responsible to
NADB for following up bad data;
hopefully, we have arrived at a point
where we can nip it in the bud. I will
show you how that works. As these
summaries operate on Univac, they also
will provide a reigonal summary of all our
data from the NADB files, if requested.
There is a mechanism for generating input
from NADB to this program, but primarily
my goal is to get the data clean before it
gets to NADB. It is also important to get
it back to the states, so they know what
they have submitted, and we know what
they have submitted and where they are
deficient. In developing the system, I
tried to get the key points that enforce-
ment errand hazardous surveillance
wanted to know. Mainly, we want the
linkage between where the monitoring site
was located, what county what AQCR,
what state, what region, and now what
SMSA. Within urban areas, we have the
capabilities of strippling off industrial,
commerical, and residential remote sites,
summarizing by county or by state. In
this package, we developed a state area
file an AQCR file. Summary statistics is
the other main program, with the number
cruncher taking the input records and
summarizing them. The area file contains
information relevant statistics, the
A-12
-------
population of the counties, urban areas,
and SMSAs. This provides the linkage as a
direct access file loaded on the PDF. The
AQCR file basically contains require-
ments. This will be altered somewhat in
prospective (unintelligible) recommenda-
tions, namely instead of what we call the
(unintelligible), minimum required, will
now be called the (unintelligible) sites. It
is however, different references, different
ball games; the same mechanism, will hold
the same structure.
The minimum sampling site file is
again (unintelligible) specific. It contains
merely a specification of whether, know
what it monitors at those specific sites,
and whether it is a required site or a
federal required or part of the sub-
network that will probably be equipment
specific, especially quality assurance
guidelines and equivalency. The rest of it
is basically linkage to this road code,
basic information also containing UTM
coordinance of the site, sampling site
address, station type, and the information
keyed for request purposes.
Basically what we provide is a site
summary. This would be a summary for
the criteria standards, of what
information is available for that site, and
for what given time period. If they
submit a quarterly report, it'll give you
the number of observations for the site.
AQCR summary is the summary for all
the sites with the AQCR. Violation
summary gives all the accessions of the
standards, tracks them, and prints them
out. It lists the site, the site address, the
observation, the number of observations
over the standard and highest value, and
whether it is a required site or sub-site.
This is a detailed listing of all the
violations that occurred at that site, at a
given time period, on the tape. The
AQCR summary lists the number of sites
required for that AQCR number sites
reporting. It is a tracking mechanism
showing whether they are in compliance
with what they are supposed to be submit-
ting. It also shows the number of mini-
mum sites and the maximum values for
those AQCRs.
There is also an 5O2 standard. They
have multiple standards, 24-hour stan-
dards, 3-hour standards, and also when
they occurred.
We also have a meteorology program
going, it is actually a Univac. It is not
there on the PDF, but I hope that there is
a plotter that we can share that perspec-
tive.
A-13
-------
MINI-COMPUTER SUCCESS
Curtis Lackey, Chief
ADP Management Branch Region IV, Atlanta, GA
I am amazed at how far we have
come in nine months. By we, I mean
everybody involved in the mini-computer
effort. I underestimated the savings both
tangible and intangible when we did the
feasibility study two years ago. The
reasons for our success--! think we can
call what we have done so far a success--
are due to several factors. One is that
the competitive procurement resulted in
an award for a good hardware and soft-
ware. It was better than what I had
expected with more processing power than
I expected; that is one of the reasons for
our success. Another reason for our
success is that we are sharing software.
Region IV has shared software with all
sites and has received software from
other sites. The third reason for our
success is the availability of a test site,
for technical assistance, for information,
and just for help. I do not know who had
the idea for that, but whoever did should
be commended. Then there is another
reason, Ted Harris. Ted has lead us
through the contractual maze on this
project, and he has been a good point man
for us. In truth, we probably would not
have had a successful mini-computer
effort without Ted.
In my opinion, the mini-computer
project is the leading edge of ADP devel-
opment in EPA and those of us that are
involved in it or are excited about it.
Those of you who will be involved in it,
will enjoy the increased support capability
you have for your users. Since March or
April of this year, we have learned a lot.
We have learned that good operational
procedure is extremely important in run-
ning a mini-computer or any computer.
We also learned that the system requires
support. It takes, one person-year in
addition to the operator. Therefore, it
really requires two people. You can get
by with less, but it will probably depend
on your workload. System tuning can have
a big payoff. We nave not changed any
system software but we have tuned it
some with significant increase in through-
out. We are also using disc-to-disc backup
over disc-to-tape backup, which saves
hours everyday. I would like to empha-
size, sharing software just can not be
beat. The regions are somewhat similar.
There are a lot of cases when we just use
a piece of software without change. A
good operator is really needed, and we
have one in Region IV. Also, someone in
the office should know a little about
communications because it really comes
in handy. Management is slow to recog-
nize the impact and the potential benefits
of the mini-computers, but maybe the
reason for this is that they have been
oversold in the past, and now they are
-waiting to see results. They are reserving
judgment on this one.
Our approach in Region IV was to
move the systems we could quickly to the
mini-computer. We did not undertake any
big development efforts, but the systems
that we tried to move very quickly were
relatively simple systems. We have 16
systems operational now on the mini and
six utilities that we developed, or con-
verted to the mini. Region X developed a
gneralized update capability that was on
the IBM system. We have converted that
to run on the POP 11/70. That was one of
the reasons we were able to move several
of these other applications quickly to the
mini-computer. The biggest application
area that we tackled so far has been in
data entry of the Grants and the Finance
systems. Those systems utilize one
terminal; in the future, there will
probable be another one added. That one
is in the program area. The users are
entering the data at the source from
A-14
-------
turnaround documents, coding sheets, and
actual source documents, eliminating the
coding process. In many instances, also
eliminating a big backlog in keypunch that
is a waiting turnaround for keypunching.
Another area, just implemented two
weeks ago, was finance. The financial
management branch was directly entering
data in a screen, in their office from
source documents and avoiding a lot of
their coding. Another area is the water
and air modelers which come down and
use our system daily. This has had
negligible impact on us so far, and it has
been a real responsive tool for them.
What are our plans? Our plans
depend a lot on what kind of package
INFORM is. I will identify some areas in
which we are interested. The regional
Formal Reporting System is something
that we want to put up that will interface
with the headquarters system. A Docu-
ment Control Register System, a budget
system, a project reporting system, a
STORET input data editing system, the
Region X water quality index system, and
a version of the sample file controller.
We want to move some local enforcement
systems that feed PCS. We would like to
move our little positon management sys-
tem, and there is also another area called
grant data management that we would
like to get into sometime in the future.
I want to emphasize we are not
jumping out into any of these on our own.
We will be sharing in the systems develop-
ment process with all sites. The extent of
our success, in the future, depends on how
much we share with each other and plan
together. Something I've learned: sharing
is easy to say, but it is work to do it. You
have got to be considerate of other
people, think about their needs, communi-
cate with them, fix bugs, send them
updates to your system, and you have got
to be committed to it. So, the idea of the
software clearinghouse is something that
came out of our meeting in Cincinnati.
It's a really good idea and something we
will support in Region IV.
There's a phrase that I have thought
up, in the past, amd had jokingly said that
some of our Headquarter systems
managers were saying, "Hey guys wait up,
we want to lead." That is really unfair to
say because they do have some legitimate
concerns, and as some people in this room
have some legitimate concerns. One
concern is that the Regions not develope
ten duplicate, individual systems. I share
that concern. We are going to try to do
the best we can in preventing that from
happening.
In summary, we have made a lot of
progress, but the big payoff is yet to
come. To achieve maximum benefit, the
mini-computer application development
must work; it is sharing and not
duplicating. The Regions must involve
Headquarters in planning, and Head-
quarters must take an interest now, rather
than be surprised later.
A-15
-------
QUESTIONS AND ANSWERS
Question: When you actually transform an application program or data from one
region to another, what actual physical mechanism do you use?
Answer: Magtape.
Question: Are you doing any documenting now?
Answer: Yes, we are making a consciencous effort to document. We are trying to
share everything that we do. Region IV sends out a monthly activity
report to all regions and several headquarter offices.
A-16
-------
DISTRIBUTING PROCESSING ISSUES AT EPA REGION V
Joel Brandon, Chief
Data Processing Branch
Region V, Chicago
There are two concepts I would like
to address: distributive processing and
mini-computers. They are somewhat
related in this context. Distributive
Processing, indicates that somebody has
distributed something, or has taken
something that was central or
nonexistent and deliberately spread it out.
Clearly, this is not going on in EPA.
There is no managed effort to distribute
any application system in this agency.
This is because, in fact, there is not any
particular managed ADP effort in the
agency. In other words, there is no
central ADP organization responsible for
all our ADP applications. That means
that there is no planning and no manage-
ment. There is no oversight review or
overall coordination. MIDSD, inter-
regional cooperation, etc. provide these,
but they really do not substitute for
actual planning. Without it, you can not
have a distributive system.
Decentralized responsibility has
always existed; this is a decentralized
agency. The regions have always had
their own say in what they do. In the case
of the minis, it is just a matter of the
equipment following that logical function.
The second concept is the mini-
computer, itself. Although they are
called minis, they have 16-bit word struc-
ture, but they are not small. Their
processing capabilities are rather exten-
sive, a couple of examples have been
made here which are fair judges of how
these things can support enormous opera-
tions. Since these things are not "mini's",
and since we do not have any distributive
effort, the question is what are these real
computers doing in the little regions?
Why are they there? Why did we want
them? Those of us, who have had
experience on large machines, were
frightened of the prospect of getting this
thing under our control and having to
deliver something with it. In fact, the
only reason is that we were completely
unable to get our work done without them.
The only thing we could see as an alterna-
tive to having our own computer was
having the stuff done right at Head-
quarters and that it was not being done.
We could not produce an interactive sys-
tem in the regions the using Headquarters
equipment. It was rather unfortunate. In
many cases, what we are doing could be
done by Headquarters.
We have considerable cooperation
between the regions. At the Cincinnati
meeting of the mini managers, we more or
less agreed that we would develop appli-
cations for ourselves, make such compro-
mises as we could and let them be
installed in other regions. However, we
would not keep daily contact in their
development. The reason for that
decision is that it would be impossible to
do it. We can get by with that decision
since the entire concept of systems
development has changed with the imple-
mentation of these machines. It is this
point that I would like to stress. It is
having this type of machine and more
important, having a data management
system (DMS) on the machine. We are no
longer locked into the old-fashioned tech-
nique of extensive analysis, extensive
design, feasability studies, and the pro-
duction of a system expected to last a
specific life cycle. That is not the way
application development is going to work
in the future. I think we ought to
recognize this. It is very easy, using the
Data Management System to set up a
system. Bruce Almicn did not go into the
application side of the Cincinnati effort,
A-17
-------
but when they bought up INFORM 11, they
bought up a personnel system with it, just
as a demonstration. It took them only two
weeks to generate an adequate personnel
system. This was at the same time as
learning INFORM, so that an experienced
INFORM user might expect to do even
better. That means that if a new report is
needed, it is a matter of, say, an after-
noon, instead of a week, two weeks, or
even a month. Having that capability, the
requirement to analyze and document
becomes considerably lessened. In fact, it
almost disappears when you also consider
the fact that Data Management Systems
(DMS) are largely self-documenting. They
are also a lot easier to understand, than
COBOL or PL/1. What we look for in
Region V is bringing up a series of
systems. They are planned; they are in
our feasibility study. We will talk to the
other regions in the development of these
applications. In fact, we will throw an
initial package at them. For instance,
Region V is responsible for one of the
finance systems, but I would be very
surprised if those systems were not com-
pletely modified within several months of
delivery. Because the regions do, have
separate and completely diverse activi-
ties. I do not know what will happen to
these systems if and when they strike
Headquarters, but the same thing can take
place there. The old constraints are now
largely gone. As long as we do not flood
these machines with things that they
should not be doing, we are assured of our
ability to support our individual locations.
The last point I would like to make
has to do with RJE management and
output productivity. One of the things we
have noticed about the mini is how much
it has helped us in managing the enormous
volumes of output. We generate four or
five million print lines a month, and we
can not really leave the thing up after
hours. We have several different tech-
niques for getting print output and
gathering it, the technical details are
unimportant. The net effect is that we
can print twice as many lines as we could
on the Data 100 equipment. Even though
we had two RJE's and one of the minis.
That is a side benefit that was not
envisioned, but it certainly worked out
very well. All the other experiences that
we have had at Region V have either been
covered or will be covered by Dennis
Schur when we get to Region X. In the
interest of time, I will stop now.
A-18
-------
REGION X MINI-COMPUTER EXPERIENCE
Dennis Schur, Chief
Data Processing Branch
Region X, Seattle
I took the time to prepare a paper
for this conference that I hope would be
published in the proceedings. Because of
that, I^do not think that I really want to
spend too much time going over that
paper. If you have an interest, you can
secure a copy of the proceedings and read
it. What I attempted to do in the paper
was to take a chronological approach to
our experiences, from the initial decision
to be a part of the procurement of the
mini-computer, through the assistance
that we provided to MIDSD, through the
installation of our machine and our subse-
quent experience. We had our machine
installed in January of this year; and this
have not had it for a full year yet. I
would have to agree with Curt, however,
that over the past 12 to 18 months, we
have come a long way. One thing that I
would like to stress—I am not sure that it
was adequately addressed by the earlier
speakers—is the impact of the decision to
move towards something like a mini-
computer on a local staff. I am a Branch
Chief, I have eight positions in my branch
that support data processing for our
region. That does not mean that there are
only eight people involved in data process-
ing. In the program areas, I would
imagine there are probably twice as many
people as there are in our branch that
actively use data processing on a day-to-
day basis. One of the things I think that
all of us envisioned was that our own
staff, program people would be turned on
to this new thing called mini-computer. I
was disappointed it did not have more
flashing lights than it has.
I would like to mention some of the
problems in implementation that relates
to people's attitudes about changes and
management problems in trying to get
people to accept these changes in FY 76.
We had in our region probably the only
IBM 2780 in the whole agency. From that
piece of equipment, we moved to the
more standardized Data 100 equipment,
that I think everyone else has. We in
Region X think we are one of the pioneers
and, in pushing for mini-computers, we
were, in fact, the first regional office to
accept the mini-computer and have it
installed. We have had some problems. It
takes more expertise on the part of your
staff to manage and operate effectively
the POP 11/70 than it does the Data 100
remote terminal. I think you all have an
appreciation for the fact that, within
EPA, we seem to be able to find ways
somehow or another to secure funding, for
a contract, hardware, or whatever, but we
have a strange difficulty in trying to
secure positions to support equipment
expansion once the decision is made. I
tried, in vain, to get two additional
positions within my branch to support this
new ADP equipment. Earlier, I think Curt
made a point that it takes at least two
people full-time just to keep this ADP
equipment operating. That is certainly
true. The two people that we generally
had in mind to do this were the two best
people on our staff. At least in my
situation that was the case. I would
caution those regions or laboratories that
are anticipating the installation of a mini-
computer, like the PDP 11/70. In your
feasibility studies, I think you should take
a hard and long look at the implication of
that decision for your staff resources. In
many cases, I think you will find that you
do not have the right people on your staff
now. You will need a top notch technical
person to be your PDP 11/70 systems
manager. That individual is not the ADP
Branch Chief; this is a full-time job. To
go out and hire someone like that is going
to take some recruiting. I do not know
A-19
-------
what other regional situations would be,
with respect to position management and
classification, but, in my opinion, we had
some real pains trying to get the ADP-
type position within our branch adequately
classified. Your staff may not quite fit
the kind of people that one needs for a
ADP 11/70 operation. Also, users
perceive the system differently. Some of
the more ADP-oriented users, the staff of
our S&A Division, look upon the PDF
11/70 as something that really gets their
job done, and is very responsive; they see
it as a tool to them, just like their
telephone. They use it, they really do,
and it is amazing to me to observe from a
distance the kinds of applications that
these individuals with very little
assistance can get going. I think the POP
11/70 is truly a programmer's—I hate to
use the word programmer's—machine. For
the experienced ADP user or for a person
with some technical background, it can be
a real benefit. For those individuals,
however who are not ADP -orinented, but
do ADP work—people who do data entry,
coding, and routinely request administra-
tive reports—the POP 11/70 is not really
going to make their job very much easier.
It has the potential to do that, but the
hardware and software configurations as
we procured them will not directly allow
us to place a terminal at a non-ADP-
oriented user's work station. My point is
that there is a fair amount of training
that has to be factored into the installa-
tion of the POP 11/70 system. I had
several other points that will come out in
the paper that I have prepared, so I think
that in the interest of trying to provide
some time for the other speakers, I will
just conclude here.
A-20
-------
QUESTIONS AND ANSWERS
Question: What level person would you need for a systems manager for a PDF
11/70?
Answer: I think all of the regional ADP Branch Chiefs would agree that a GS-12
computer specialist level position is the absolute minimum. We would
like very much to see that position be a GS-13, at least I would. There is
a tremendous amount of technical expertise that has to be absorbed and
retained in that individual; I think we have to do everything that we
possibly can to retain that person in that position. There is a lot of
competition out there. As these mini-computer systems are excepted in
industry, there will be much more competition for those people that have
those skills.
A-21
-------
SYSTEMS: DISTRIBUTED - CENTRALIZED - INDEPENDENT
Jim Hammerle, Chief
National Air Data Branch
Research Triangle Park, NC
Hammerle: My first question is why
are we talking about distributed vs. cen-
tralized processing? I think that we have
heard explanations for what it may or may
not mean, what it means to individual
people and ways of going about it, etc.,
but why are we talking about it?
Secondly, what is distributive processing?
I think we had a number of definitions this
morning, and a couple this afternoon, and
I will contribute to the confusion of that
second question, myself.
I think I have at least probably a
partial answer to the first question.
Morris Yaguda, I think it was about a year
ago that you were using a slide, I did not
know where you got it, but I had used the
same slide myself previously. It showed
four stages of ADP growth. The fourth
stage was the phase at which initial
explosive growth is over; there is a
moratorium on new applicaitons and an
emphasis on control with fewer resources.
What bothered me the most when I saw
those four stages of ADP growth was the
last stage. I saw it a couple years ago,
and at that time, there were a few people
moving into that fourth stage. I think
certainly we fall into that stage at this
time. I have not seen that bright soul
whoever he was who dreamed up those
four stages, but now that we are in the
fourth stage, and some others have been
in it for awhile, what is the fifth stage?
We may be on the verge of discovering
that now, because I will suggest what the
fifth stage might actually be.
People usually associate centraliza-
tion with higher efficiency, and decentra-
lization with more effectiveness and more
responsiveness (that is-closer to the
users). Efficiency has to do with bigger
machines, higher specialized people, etc.
These are the kinds of things about which
people think when they talk about centra-
lized vs. decentralized. The American
Management Association talks about
separate machines transmitting data
among themselves. They are machine
oriented. We had a speaker this morning
who addressed additonal things besides
machines; namely, input, data processing,
etc. He expanded that beyond just taking
a look at machines talking to each other
and he looked at other aspects.
Willis Greenstreet mentioned his G2
activities. He ran one of those on us a
couple of years ago, called the Index
Systems study of our data systems. Where
was the data base? They had three
different bases about which they talked in
their draft report. The final report talks
about utility, hybrid and the current sys-
tem. As it turns out, the utility was a
totally centralized operation. Hybrid has
a centralized component and a decentra-
lized component with the centralized
component a subset of the decentralized.
In other words, you had a number of major
data bases scattered around, and you had
little pieces of them all gathered together
into one centralized data base. Then what
they actually had was a totally centra-
lized and totally decentralized data base.
That was where each state had all their
air data; headquarters also had all their
air data. If that is the way you look at it,
what do you call the situation where you
have a centralized data base where each
little piece is decentralized? There are
actually five of these permutations of
data base locations and I am proposing
that probably what most people have been
talking about today as decentralized sys-
tems, I would tend to think of as the first
sign of a totally decentralized system.
A-22
-------
Centralized and decentralized are a
matter of degree. I do not think there is
anyone who would take a look at air data
systems and say it is centralized or it is
decentralized. It is a matter of degree.
You need to look at all the components.
Some are centralized, some are decentra-
lized. Therefore, the concept of a centra-
lized system or a decentralized system is
really not very good in itself. It is a
matter of degree. How much is centra-
lized and how much is decentralized?
That will depend on the current situation.
What do we have for computer
resources in the agency as far as
machines? What do we have In terms of
personnel? in terms of communications
lines and policies, etc.? This will be a
dynamic situation in which something that
was centralized last year will be decen-
tralized this year. Something decentra-
lized this year will be centralized next
year. It is a dynamic situation. We do not
have centralized or decentralized sys-
tems, but we have a new stage, perhaps
the fifth stage in ADP, and that is
independence: total independence with
mini-computers not tried to any other
machines, devoted to servicing one sys-
tem. I would also like to mention that
besides looking where the system is
decentralized or centralized or looking
where the data base is and saying it is
decentralized or centralized, you could
look elsewhere like where are the people?
Are they centralized or decentralized? I
am very much concerned about the matter
of the people. I think each of us has to
look at that very carefully. Where are the
people located with whom we have to
deal? Where are our users, where is our
management?
I have a checklist here. On the left
side is a D for decentralized and on the
right side is a C_ for centralized. If you
consider auditability and visibility, I am
sure you will agree that if you have your
operation centralized you have a lot of
visibility and a lot of auditability. This
means that others can see what you are
doing; you can catch a lot of arrows. It
depends on whether you are centralized or
decentralized as to whether that is a plus
or a minus. I will give credit on both
sides. With management concentration,
again, you may like to operate indepently.
It may be best for the agency that you do
not. This is a matter of consideration and
again I don't think we can say that the
best way is to be centralized or the best
way is to be decentralized. I will give a
plus for each one of them. The next is
one with which I am particularly con-
cerned. It is a very touchy subject with
me. This is data base and integrity. I will
not put any mark down, because my
personal opinion is that in my context of
centralized, decentralized, and indepen-
dent systems, I believe you do have more
data base integrity with a centralized
system. Regarding personnel competence,
I think, even though it may hurt a little
bit, you have to admit that in a centra-
lized operation, you can afford higher-
graded people. You will have a higher
competence level in the people. With
personnel specialization, I will say that
decentralized and centralized can share.
You have people who are very specialized
in a centralized operation and you have
people who are very specialized in a
decentralized operation. Those people
who are in the decentralized operation are
very specialized towards the users.
They're close to the data users, so they
are very attuned to those people. In a
centralized operation, you can afford
somebody who spends all their time on a
small subject. A decentralized operation
just could not afford that kind of an
overhead. Next is standard of operation.
It is easier to set up standards of opera-
tions in a centralized facility as opposed
to a decentralized facility. That is not to
say you can not do it with a decentralized
facility, but it is easier to do in a
centralized one. Functionalization of
duties and responsibilities is also easier in
a centralized than in a decentralized, but
it's not impossible in decentralized. It
takes a little more time, a little more
effort. In a decentralized operation you
have a greater probability of success in
the area of data application and integrity.
A-23
-------
Documentation standards again are easier
to have in a centralized operation. With
programming techniques, the centralized
system has a little more edge over the
decentralized system. Redundancy, there
is a good possibility for redundance in a
decentralized operation. Project control
is usually a little bit on the side of a
centralized operation. With upward
mobility of people, there are advantages
in a centralized operation that you do not
have in a decentralized one. There are
more opportunities to move within your
specialty field in a centralized operation.
I would like to give our data systems
a report card. First of all I have tried to
list some, though not all, of the compo-
nents making a data system. Starting at
the top, data collection is a decentralized
responsibility as far as air data systems is
concerned. ADP management I am con-
sidering as MIDSD, a centralized activity.
Data collection is toally dencentralized;
pre-input processing is totally decentra-
lized at this time. In spring of 1972, there
was a meeting of S&A directors at Crystal
Mall. At that time, every item on this list
would have had a C^ on it for centralized,
as far as air data was concerned—every
item, except data collection. At that
time, I specifically stated that we would
work toward decentralization, and we
have accomplished decentralization. Pre-
input processing is one of our examples of
decentralization in which the Regional
Office and state and local agencies do all
the pre-input processing. Data base
integrity at this time is a response of the
NADB; it is centralized. Data base and
system maintenance is our responsibility;
it is centralized. Output processing is
totally decentralized. The Regional
Offices access the data bank and use
retrieval programs. They make all their
own retrievals. Data use is as decentra-
lized as it can be. I have campaigned a
long time saying that. There is no one
person or one group who is responsible for
data use or data analysis. All users should
be considered equal. Data system users
assistance is centralized and, obviously,
should be centralized. Data system
development is a centralized function.
Special applications, though, are decen-
tralized. As you well know, if you ask us
for a special program, we do not have the
resources to do that. Therefore, that is
decentralized. The hardware utilities
communications are centralized because
it is the computer center's responsibility.
The one thing that I previously
mentioned that I will bring up now is the
matter of input processing. Currently, it
is a centralized responsibility as far as air
data is concerned. Through past
experiences and a lot of problems, both
with ours and others' data systems, we
believe that it should, at least for the
time being, remain a centralized responsi-
bility. That is not to say that sometime in
the future it will not become a decentra-
lized responsibility. In fact, it is the next
logical candidate for decentralization.
What I am getting at is that we have, over
a period of five years, moved to a
situation where we do have some decen-
tralization and some centralization, and
we will continue to move toward further
decentralization, keeping in mind the dif-
ference between centralization, decentra-
lization, and total independence.
-------
THE MINI-COMPUTER AND NATIONAL SYSTEMS
Jim Susha, ChiefSystems Support Staff
Office of Water Program Operations, Washington, D.C.
What I would like to do is share with
you my perspective from Washington and
some of the concerns that I have watching
the emergence of the mini-computer on
the scene. First, I'd like to give you a
little bit of background. I am in the
construction grants program. A little
over two years ago, we conducted a study
to determine what the national require-
ments for managing the construction
grants programs would be; this means
what the regions would need to manage
the program. At the time we conducted
the study, there were no mini-computers
in any of the regions. The only thing we
had at that time was a contract with
Optimum Systems, Inc. (OSI). The com-
puter system that supported us then and
now is because GIGS supports all the grant
programs. We went through a study GIGS,
requirements, and subjecting those
requirements to review by all the regions
before establishing a system. In March of
this year, we installed that system, at
least the computer end of it, in the 10
regional offices. We still had to develop,
region-by-region, data collection pro-
cedures, reporting packages, training pro-
grams and all the other requirements of
implementing a system. Now we also
went through the COMNET conversion
over the summer. It was a setback for us
in terms of the system. Having come out
of that, we now face credibility problems
in the regions in terms of the central
system being able to support the regional
offices.
Well, at the time we did the initial
study, we recognized that we were really
in a hierarchical situation. We had
requirements out there, some which we
felt could be met in a short timeframe;
others, we felt could be met in a long
timeframe. We divided our system study
into two phases; short and a long range.
The short range, we defined as project
level management. In grant programs,
this is really a project within a grant. We
have also defined a long-range study that
includes state requirements. It also
includes the Corps of Engineers a level
that we have not supported which is a
contract level requirement. We still are
not planning to support that, but there
seems to be a contract level requirement
in the regions. We went ahead with the
short-range system and implemented it to
satisfy what we felt was the immediate
need. When that was done we became
engaged in this longer-range study to
define what our long-range requirements
are. This long-range study will address
data base management. Again, when we
started the minis were not there; we did
talk of decentralization, distributed net-
works, and distributed master files to
support the heirarchical requirement. We
are involved in the long range study now.
Since the minis have gone in our approach
and thinking has had to adjust. I have
seen some evidence that the mini-com-
puter could be the solution to our
problems if utilized properly.
First, the front end processing is
terrific, as far as editing data and this
data entry is responsive to the user. I
think that stuff is great. The package
that I understand Region X has developed
and passed on to the regions has real
merit. But, there is a problem in
supporting the regions requirements from
Washington that would exist in any cen-
tralized system, particularly where you
have regional offices spread nationally.
We have a staff and there is no way that
we could ever justify a staff large enough
to meet the needs of ten regional offices.
It is just too great. There fore there is a
necessity to decentralize the maintenance
and possibly the development, but it must
A-25
-------
be accomplished under controlled condi-
tions. I do see some other problems even
in a controlled environment.
We come to the question of the
master files and where do they reside -
how will they be decentralized? I have
seen evidence of what I will call a major
attitude change in the regional offices by
the users. Those regions that have minis,
they seem to be excited by the fact that
those minis are in their regions and that
they will be independent. They will not
have to rely on central processing; they
will be able to have their data processing
group respond to their needs almost
immediately. It remains to be seen just
how that works out. Region V is
embarking on an effort to develop a
redundant file maintenance system, if
that is correct.
As I mentioned earlier, we have
acurrent redundancy problem; we have to
interface with certain State systems.
Programs were delegated to certain
states, and many of the states have their
own computer systems. We have to
decide how we will interface with these
State systems. I have defined two major
alternatives: what I call a transaction-
driven interface, and the other is file
replacement. I am drawing an analogy
between the mini-computer in the regions
and the problems we have to face in the
states. First we were working at an
interface between the central system and
the states. Now I see an interface
developing between the central system
and the regional systems. The first
alternative to these common problems is a
transaction-driven interface where you
have two master-file systems being main-
tained. One would be in a state system;
the other in the national system. In
Washington, we would have what we have,
that is, a regional construction grants
management system which is supported by
GIGS. The transaction-driven interface
would generate transactions from the
state system, transmit them to ours, and
we would process them into our files. In
other words, transactions would be pro-
cessed twice but in separate files. The
problems that I see with that one is that
you really do have to maintain two sys-
tems, because you have to work your
errors off on both systems. You must also
reconcile those systems on a regular basis.
I do not believe there is anyone in the
world who could keep two independent
master file systems in sync. There would
be timing problems. One system goes
down, the other up. The resources
required to maintain two systems are
expensive, both in reconciliation and any
error corrections in maintenance of the
two systems. Those are some of the
major problems. There is another
alternative, however, which I call file
replacement. This actually has two sub
options: file replacement and record
replacement. Under a file replacement
system the state only has to transmit
their file (full file replacement) or
portions thereof (record replacement) to
Washington on a weekly basis. This means
only a single file system has to be
maintained. In interfacing two systems
like that, it is far less complex than the
software required for a transaction-driven
interface in which you not only have to
reconcile, but you will also have to main-
tain the transaction programs that inter-
face. These same alternatives apply
where the region would be maintaining a
master file system on the mini.
A-26
-------
QUESTIONS AND ANSWERS
Question: For clarification, you are saying that you take the tape system and send
send it over to GIGS. You are replacing the GIGS file with the state file,
or is it the other way around?
Answer: The movement of the file is from the state or the region into
Washington. The advantages to that is that it maintains a single system.
There are no reconciliation problems, and it is a less complex update.
The software maintenance under this situation is minimal, so I think that
in the two options, I favor file replacement. That, however, is an
immediate problem, because I do not know of any way that we can
prevent Region V from developing data maintenance systems in their
region to support their construction grants operation. So this is an
immediate problem. I also see some long-range problems. I suppose that
it comes in part, from the fact that I have come up very traditional lines,
where control, efficiency, and responsiveness were important. The real
questions that I have are: in the regions or in a decentralized
environment, if there is not any control over development, there is not
any control over system growth or direction. Traditional things that you
go through when you bring up a system—analysis, definition, pro-
gramming implementation—if you do not have that control, then from my
standpoint in Washington, it looks very chaotic. If the regions develop,
implement, and change at will, then I cannot see anything but a chaotic
situation developing. I do not know exactly how we can control that type
of environment because communication, cooperation, and coordination is
very difficult with the long distances involved. I guess I am here looking
for answers to this, because the minis are out there. We are studying and
looking at our long-range system requirements. I do not see any easy or
planned solution to the problems.
Another thing that will complicate it, I think, is the construction grants
program. That is only one system, but in a study that we are conducting
now, we are also addressing an integrated environment. In that, we will
try to draw three or four Headquarter systems together, maybe into a
data base system. Incidentally, I see come problems in that because to
me there is a dichotomy between decentralized processing and data base
management systems. DBMS is a centralized approach. I have some
notes taken out of some articles that I have read concerning some other
problems. They say that the file structures between the host and the
minis should be the same, because in the truly distributed environment,
the logical relationships between those files should be compatible. If
not, you can create some horrendous problems in moving data from one
site to another. If we move Washington to a data base management
system that integrates three or four major systems, then somehow that
needs to be kept in line with the activity going on in our regions over
which we have no control. I am here not to answer questions, but to ask
questions. I would really appreciate it if anyone could spell out what is
being done or what is going to be done to solve some of these things I see
as problems. If there are not any problems, I would like to know that
also.
A-27
-------
Response:
Question:
Answer:
One thing about control—I do not think things are really out of control.
Anything done in the regions will be done, I am sure, in concert with the
users in the region. It is his needs that are primarily in the mini-
computer effort. I do not think there is any intent to go a separate way,
without having control or the reconciliation problem solved. I do not
share your opinion that it is impossible to have two files reconciled daily
by a proper system design. I appreciate the problems you have about the
long-range goals. What I see here is requirements. Who really needs the
data? Do the regions need the data or daily management of construction
grant programs? Does Headquarters need the data for the outside role?
That is a major issue: who really needs the data on a firsthand basis?
I have not been an active component of the issue in the forefront about
the GIGS data base, with respect to the mini-computer site. I have to
admit that I like your proposed alternative very much. I think it is great
and am really glad you proposed it. I think it is entirely workable to have
a system configuration where the regional offices maintain local copies
of the master file, and in fact, forward that master file copy to
Headquarters on some kind of a timely basis. I think one of the biggest
complaints that we hear in the regional offices is that the GIGS system,
as it now exists, is simply not responsive. It is not responsive in the
sense that things are out of your control. If the COMNET facility is not
working properly, and you miss an update, our users miss their reporting
requirements. One concern I have to come back to again is that those of
us managing ADP in the regions have to be aware of some of the more
subtle implications of your proposals. It sounds very attractive on the
surface, but what it really means is that my system is more reliable than
the central system. The software that would be developed to perform
the update is as reliable as the software that you have in Headquarters.
What I would propose is that we work together on this. I would like
nothing better than to see you find the development of the regional
software to maintain a regional file that we could transmit. I think if
you would consider that, in additon to the one you suggested, it may in
fact relieve some of the anxiety you have over the possible chaotic
situation that could develop. Quite frankly, we do not have the resources
locally to duplicate the GIGS, the Arrow System, and who knows what
other systems people may like to have. We do, however, have these
machines in the regions that can provide very responsive interactive
capabilities to users. If we adopt the position of working together on it,
we could certainly use your resources to exploit some of the potential of
the machines.
The study that we are conducting now will take a look at those
alternatives. The situation that I was describing was one under which we
had no control, because as you know, it will take some time for us to
define the relationships among several file systems, and even longer to
develop software, implementation and training. The situation I was
describing was one that exists immediately. I do not know how long it
will take us to get there, I do not know how much it will cost us in
resources, whether the resources will be available at the time. I do know
the situation I used in the charts exists today; the states do have their
own computer systems. It is a problem that we have to solve today,
A-28
-------
there has to be an effective interface between state systems and a
centralized system. One of the options, and to me the best option, is file
replacement. It requires changes to GICS, because it is not in their
normal procedure. Theirs is a transaction-driven system. If we have
minis out there and we have three (I understand that a fourth is coming
up), one region develops a data base system using INFORM 11 and it is
completely redundant with the data elements that we have to carry in a
centraZized system plus some regional ones. We would then have the
same situation in the region that we have in the state except that there
is no control; there is no way we have the resources now to get out there
and help you develop the mini because they just are not in-house. They
would have to be bought. It is a long-term issue that we are trying to
address, and yet the issue is right in front of us today. This is the one
problem about which I am concerned.
A-29
-------
PANEL B: EFFLUENT DATA SYSTEMS
Chairman: Jack Sweeney
Panelists: Chuck Evans
William Milligan
Cliff Lundin
Phil Taylor
Howard Hein
Pete Gattuso
INTRODUCTORY REMARKS
Jacfc Sweeney
Effluent data has been around for a long time. It has been used for many decades in
the field of environmental engineering for design and planning of sewage treatment plants
and other industrial processes. It has been used for water quality analysis and, more
recently in EPA, it has become a very important aspect of the development of guidelines
and the NPDES enforcement program. There seems to be a lot of usage of effluent data,
once you start looking around, but you do not see too much sharing of this data. Everyone
seems to be off doing their own thing and one of the things we would like to do here today
is to get people together and start discussing effluent data as a group, hoping that in time
it will lead to greater sharing of data. When you start talking about sharing of effluent
data, this is where you start getting into the area of using data processing to support that
effort. The first speakers are Chuck Evans and Bill Milligan from the Compliance Branch
of the Office of Enforcement, who will be making a joint presentation on the use of
effluent data from a national enforcement perspective. The second presentation will be
given by three gentlemen from Region II. They will be addressing the usage of effluent
data at the regional level and the data processing system that has been developed in their
region to support that effort. The first speaker will be Cliff Lundin from the Status of
Compliance Branch, which is the prime user of the system. The second speaker will be
Howard Hein, from the Data Systems Branch. He is the Systems Manager and the third
speaker will be Pete Gattuso, who is also in the Compliance Branch. The third
presentation will be from Phil Taylor, who is from the Water Quality Analysis Branch of
the Office of Water and Hazardous Materials. Phil will be giving us some insight into
branch activities in terms of using effluent data for water quality analysis, particularly
toxic-related effluent data.
B-l
-------
ERA'S NEEDS AND USES OF EFFLUENT DATA
Chuck Evans
Today in most regional situations, a
sophisticated means of handling informa-
tion in general, and specifically the
handling of effluent data, is not in opera-
tion. Almost an army of clerks manually
treat everything that comes into the
Agency from all sources.
Before I get underway, I would like
to ask, how many of you have worked on
water enforcement or have some
experience with water compliance, the
permit program, compliance monitoring or
handle effluent data on a routine basis?
Okay, so there are no strangers in the
audience. Before we get into the system
that Water Compliance is using to handle
effluent data and why effluent data is so
important to us that we need some kind of
system to handle it, it is appropriate to
take a few minutes to reach back into the
recent past to understand why we are
dealing with the national situation we
have. The most appropriate historical
milestone is the enactment of the Federal
Water Pollution Control Act; or, as we
would like to abbreviate it—the Act. The
Act resulted in something called the
National Pollutant Discharge System
(NPDS). It is a network of investigators,
information handlers, and decision-makers
that has been set up to translate compli-
ance information or raw effluent data into
enforcement decisions, resulting in
compliance with general rules of water
waste treatment. The net result is
cleaner water. This system also called for
development of a permit program. The
permit program led to the development of
a Federal order requiring everyone to
apply for a Federal permit prior to
discharging into any receiving stream
anywhere in the country. All U.S. waters
are liable for this kind of regulation. The
Agency was flooded with applications for
these Federal permits to discharge. The
system for the issuance of permits was
developed on the same basis that IRS uses
to collect taxes, i.e., a voluntary system
to gain the most cooperation in the public
and private sectors with the law, When
you pay your taxes, if you sign a
statement in good faith verifying that
everything contained therein is true and
accurate to the best of your knowledge.
This is consistent with the current Federal
philosophy that we will achieve greater
public compliance and reach the goal of
cleaner water with the least amount of
resistance from the public. The permit
program is established in the Act within
the National Pollutant Discharge
Elimination System.
Voluntary compliance is our operating
philosophy. The voluntary compliance
with Federal regulations is in effect in 29
state jurisdictions where the state govern-
ments have enacted environmental laws
with codes for water treatment that are
acceptable to the Agency. The Agency
does not have primary jurisdiction in these
areas. In the other states, EPA has
primary jurisdiction. There, all discharges
in both public and private sector must
apply, fill out an application and comply
with the permit. For those of you
familiar with it, a lot of this is very
elementary. But, I am leading up to a
situation with which you are also familiar-
-paper and information on paper. We are
talking about the 50,000 issues permits
and almost as many applications in
existence today; that is a lot of paper
with which to deal. If we handle about
100 information BITS with each permit
application, that is a lot of information
for relatively few clerks, a handful in
comparison to the amount of information
that they have to handle nationwide.
Effluent data is our chief handle on
exactly what is going into receiving
streams across the country. If dischargers
B-2
-------
comply voluntarily, we will get a pretty
accurate reading of what is going on; we
will be able to access pollutant loads.
That way, we will be able to assess what
is being taken out in time. Perhaps in 15
to 20 years we may have some kind of
yardstick for measuring how fast we are
cleaning our water. That is why effluent
data is key to us. We do not have enough
people to sit at the end of a pipe in every
out-fall in the country; we do not even
know where all the outfalls are. That is
why voluntary compliance is key; that is
why attention to this paper is key; and
that is why effluent data is key.
A permit is composed of three
sections. There is a compliance schedule
which is nothing more than a reasonable
forecast of when that facility can plan
and build the level of treatment that is
required by regulation. It begins with the
development of engineering specifica-
tions; goes all the way to the award of
contract; goes to the start of construc-
tion, progress reports, completion of the
construction; its operation; and final
limits. The reason that the permit
compliance schedule is so complex is that
the applications from industries require us
to determine what the range of the
operation is in terms of input and output
so that we can determine what the pollu-
tant load is likely to be under full opera-
tion, below capacity and between opera-
tions. From all of the various inputs into
the industrial process, we learn exactly
how much is coming out of the end of that
pipe, and how it affects the stream in
comparison with other pipes contributing
to that stream.
In addition to the effluent data we
have a lot of milestone events to track
(for the construction of this waste water
treatment). The permits require the
facility to meet certain effluent limita-
tions once the construction is completed.
In most cases, the number of limitations is
probably under 10 for different chemical
units. (If you multiply that by 50,000
permits, you have a lot of information to
track.) The third element of the permit is
the requirement to monitor and report the
discharge. Again, this traces back to the
concept of voluntary compliance with the
law. Like paying your taxes is voluntary
as long as you report in good faith, in
Federally permitted discharges you moni-
tor according to the requirement of the
permit, sample it at the required intervals
and with the right equipment, and analyze
it according to the laboratory analytical
techniques recommended and appropriate
for that type of discharge, everything is
fine. There are, however, a lot of critical
if's and but's in there. If you sample well
and analyze poorly, the data is no good.
We will not know what is going into the
stream, this warps the whole national
picture. Our only method of quality
assurance is to verify all data through an
inspection program. The amount of infor-
mation coming to us based on the need for
effluent data is tremendous; we have to
track everything that goes on for our
permit application, the construction of
treatment facilities, the attempt to find
tune the plumbing, so that it will have a
final limit. There is a lot of overview
required to see that the appropriate tech-
niques are used to analyze the data
gathered by the floor measurement
devices, that people who use the devices
know how to use them. That is a big job
for roughly 60 positions in the United
States for 60,000 permits multiplied by all
their requirements within each permit—
the construction schedule, the effluent
limits themselves, and the reporting and
monitoring requirements. All of this has
to be handled some way and has to be
immediately accessible to decision-
makers within Enforcement, not only in
the Headquarters office, but also within
the regions.
Before we get into that system, I
would like to touch on some of the1
operating philosophy that Enforcement
has had and with which it is currently
operating. In the beginning, with the
NPDES program, we sat around
Headquarters trying to figure out how to
cope with 10 of the regulations, with the
billions of dollars we were appropriated to
B-3
-------
get the job done, and with the handful of
people we had to do it. A lot of effort
was devoted to trying to coordinate the
people disbursing funds to municipalities
for treatment of facilities with the people
that were actually writing the permits.
We need management information sys-
tems, forms, ADP systems, etc., that can
be converted or that integrated nicely.
Back in the days when things were getting
underway, it was a matter of showing
permits so that people could be awarded
grants to build. Then they could get the
construction started. If construction
started on those facilities which achieved
the best practical technologies, whose
standards would result in the most pollu-
tion abatement, then the Agency would be
leapfrogging ahead in time, given its
management problems. So we come to a
point in time where a lot of money has
been spent, people have permits, facilities
are nearly completed or, in most cases, at
least able to operate on routine basis.
Still the problem in the Agency is whether
the water is getting any cleaner. We have
now reached a phase in our Enforcement
central philosophy where we no longer
worry so much about getting money out
and getting permits written as we are
about enforcing the schedules of those
permits. You can achieve clean water
faster by building treatment facilities,
and treating water than you can by suing
people over and over again and dragging it
out through the courts.
We have reached the phase of
attempting to achieve compliance by
technical support, by guidance, and by
follow-up. We follow-up based on what
we read. We read a lot of numbers that
are the results of the requirements to
report effluent data, to describe
discharges in chemical currents.
At this point, we can start to look at
what this means to the human beings in
the regions whose job it is on a day-to-day
basis to deal with all of this information.
What is key effluent data? The emphasis
was on getting construction of treatment
completed. Now, however, we are going
to take enforcement action not only for
violations of construction requirements
but especially for not meeting the
effluent limits contained in Federal
permit. Individual firms and EPA agreed
upon their own permit requirements.
About 80 to 85 percent of all industrial
major permits—about 5,500 out of 50,000
permits we have issued for which EPA has
jurisdiction—do have construction com-
pleted and are able to achieve operational
limits; they are meeting the permit
requirements in terms of effluent limits.
Less than half of the roughly 22,000
municipal facilities meet their require-
ments because they cannot get construc-
tion completed either because of lack of
state approval, delays, or funding delays
with grants or tie-ins to other systems.
This is what regional auditors live with on
a day-to-day basis. They get effluent
data in the mail and they have to
interpret it; they have to be able to
determine whether the numbers make any
sense, whether all of the needed informa-
tion was reported for the permit under
audit, and whether any more data can be
used in subsequent technical evaluations.
If we are not shrewd in our part in
arriving at treatment technologies that
make it easier for someone to monitor,
sample, analyze and report data, we really
cannot do our job at the Agency to
expedite the water cleanup. These
reports come into the Agency usually on a
quarterly basis. Given the number of
major permits that are in effect right
now—for the facilities that we have to
pay attention to more closely—we have
about 100,000 pieces of paper just for the
majors alone. This is exactly the situation
that forced our division to rethink the
process of handling it all in the regions.
Two to three years ago, when Mr. Quarles
made his annual visit to all the regions, he
noticed cardboard boxes on top of
cardboard boxes, full of progress reports.
This is exactly what caused Mr. Quarles to
pull his lieutenants together and say that
the regions do not have a system for
handling reports. The dischargers spend a
lot of money having it analyzed and
-------
sampled; we do not know what is going
into the receiving streams. Somebody has
got to come up with a system for handling
it. Effluent data is key; but a more
automatic way of handling it is absolutely
imperative, not only because of the sacks
of mail, but because of the situation here.
Human beings just cannot read the
reports, interpret them, and make good
decisions about them because we do not
have enough of them. It is not cost
effective to hire any more. It takes about
60 positions nationwide to handle about
100,000 permits. Imagine the data
problems when you add to that 300,000 of
those PMR's that come from minor
facilities where we do not have the time
to look, but must if we do our job as
public servants according to the Act. A
half million pieces of paper a year—all of
which have at least, half a dozen chemical
parameters—have to be reported on a
quarterly basis. You just keep adding the
time sign and another number and you are
talking about 60 people having to cope
with an amount of information that just is
not feasible. But, they are hacking away
at it right now.
I do not think that we need to spend
any more time verifying that effluent
data is key. We cannot do our job without
effluent data and we are getting it now on
the DMR form. The real kicker is that we
are going to continue to depend on that
handwritten form, voluntarily filled-out,
in the future. The Agency stuff, like IRS,
comes with returns every quarter. We get
these DMR returns, discharge mo>v taring
reports; and the number of permits to be
issued will increase tenfold. Thus, the
number that we will be getting in the mail
will increase, but the position that we
appropriated to handle them will not
increase. This is a good time to get into
what we call the Enforcement Manage-
ment System. When Mr. Quarles sees the
piled boxes of the DMR's and
Congressional reports in the offices, he,
from his experiences as an attorney,
knows that if the Agency is going to do
anything, figures that this will probably go
through the courts, at least to establish
some kind of national credibility. Any
case depends on good evidence. If all of
our evidance is unread, unopened, and in
cardboard boxes lining the halls of
regional offices, we are just going to fail.
Our track record in court can somewhat
back up that statement. Several task
forces in the Agency were convened over
the summers of 74 and 75. They met and
tried to devise some fancy way for
handling all this information. Since the
people on these task forces were high-
level managers, they designed elements of
an Enforcement Management System that
was so huge that ordinary people working
at the regional level could not possible get
a job with them. They took the philosophy
again, hung it at the door, and got down to
paper work. Out came a simple routine
for handling paper that contains effluent
information as well as other information.
It was called "compliance information."
This enables the 60 positions we have
nationwide to translate most of the criti-
cal stuff to decisions of whether or not to
act.
The slide tells the whole story of the
business about the law, voluntary com-
pliance, commercial or in-house analysis
of sample effluent and recorded informa-
tion, it shows the step of mailing informa-
tion to regional EPA offices, the audits
there. The question mark in the middle is
an attempt to lead you through the
various tasks by sorting, according to
priority-determining, what you have in
terms of major discharge information so
that you can focus on that right away,
moving right through to whether or not it
is adequate to evaluate on factor
enforcement procedures, and to determine
which ones are actionable—where we have
good chances of taking an action and
accomplishing compliance. This technical
evaluation results in that enforcement
decision which automatically leads into an
action. This is all written into guidance
that has been sent out as a directive from
the AA for enforcement. Following up on
that, we tracked the results of that action
arid store the result. When the action is
retrieved, it is not done purely to fill in
the squares for a Headquarters
commitment, but also for national water
B-5
-------
qualities studies, and for public same routine again and again. We find
information. One of the major reasons analytical techniques so that when we
that this effluent data needs to be pick up that effluent data, we see a trend.
collected accurately and handled properly If we keep collecting it over a period of
is for use as a factor in decision-making time, we will have a good idea whether
patterns. Every quarter we go into the anything we are doing is resulting in
cleaner water.
B-6
-------
PLANNED EFFLUENT DATA SYSTEMS
Bill Milligan
For some time we have been looking
at effluent data from an agency
standpoint. We realize there is a
tremendous problem out there; it is very
large, and we do not quite know how to
handle it. In the spring of 1977, we
commissioned a feasibility study by
Arthur Young and finished it in 3une. The
results of that study went out to the
Regions. The next thing that we saw was
a violent reaction from the Regions
because the study aroused a multitude of
problems. When we talked to the Regions,
we tried to find out what were the real
problems. We have come to the
conclusion that maybe there were not as
many problems as the Regions thought. I
know that Sam Conger of MDSD is here
and I would like to bring up one point. We
have heard that we are trying to resurrect
GPSF and that is not correct. We are not
trying to do anything like that at all. The
results of the Arthur Young Study pointed
out five system phases based on require-
ments which Arthur Young thought were
necessary. The first, Option 1, was pretty
much where we are today. The checkered
in-boxes represent automated functions
within the system. Now, as you walk
through these, boxes, you will find that we
have DMR forecasting. Under Option 2,
Arthur Young is saying DMR issuance.
This would involve preprinting DMR
forms, forecast and track the DMR: the
initial screening will be automated.
Under Option 3, they have added substan-
tive screening to the DMR processing.
Under Option 4, they have entered
violation history. Under Option 5, they
have entered action tracking. Now in our
discussions with the Regions and among
our own people in Permits and
Compliance, the consensus is that Option
5 is probably the best system. As you can
see, it has quite a bit more in it than what
we currently have. We do not want to
resurrect a new type of system that will
do all of these things. We looked around
when we first completed this study. We
indicated which systems were available
that could accomplish this and the only
system that had all of these things was in
Mississippi. They have a very good system
and it is written in COBOL. It is an easy
system to operate. They did not have
action tracking or the violation history,
but it was the only system around that
would satisfy our needs. He sent the
feasibility study out to all Regions. It
went to three people in each Region;
namely, the Administrator, the Enforce-
ment Director, and the ADP Branch
Chief. With each study we sent a letter
requesting to have combined responses
about the system. We did not get many
combined replies. We have received two
or three Regional responses with the
Administrator signing a combined reply.
The other responses came either from
Enforcement or ADP. Region HI sent in
two of them one from ADP and one from
Enforcement. They wanted to be doubly
sure that we received their message.
Since that time we have been working
with Region II. They seem to have found
the key to putting the system together.
They have all the functions that we
require. They do not have a combined
report writer. This is what we would like
to add to their system. We would like to
take their basic LEDS system and add a
report writer on it. Essentially this would
provide us Option 5 but we do not want to
store actual effluent data in our system.
The only things that we would like to
store are the actual violations. We would
like to store effluent data in STORET.
Recently we have been working with the
STORET people. MDSD has agreed to
have their people work with us to help
coordinate any problems. The primary
benefit of phase one is preprinting the
DMR form. It is one of the major benefits
that we have heard from both Region II
and Region VII who have it. Preprinted
DMR forms will usually come back on
B-7
-------
time. In most cases, they will come back
completed. We think that this is one of
the biggest advantages of the system.
The Region II LEDS system provides the
capability for DMR violation/action
tracking as well. I will let them discuss
that later. Our main concern is preprint-
ing DMR forms, tracking the receipt of
DMRs when they arrive, initially
screening the form to see whether they
have violated their limitations, and sub-
stantive screening to identify the level of
violation. Now, suppose we have a
permittee that is marginally in violation,
just a fraction, for a period of three
months. There are some marginal viola-
tions that are going to take a substantive
type of screening. We want to look at
them on a long term basis to figure
whether they are in or out of compliance.
The feasibility study's Option 4 is really a
phase one system. Arthur Young proposed
a two phase system approach for us.
Phase one is a basic system similar to
what LEDS has in it. A phase two system
is a day-to-day management system. We
have had MRI Corporation come in and do
an evaluation of EDS vs. PCS. We felt
that Data Base was just a little ahead of
us at this time. We feel that there is not
enough data in PCS to warrant a Data
Base. My personal opinion is that we are
talking about a billion bytes. We are
currently at three hundred million.
Projected costs for system development
of phase one are: $58,000 for design and
programming, $27,000 for support pro-
cedures and training, and $158,367 for
enterining permit limitations. Phase one
is for majors only, if I failed to mention
that, I am sorry. For phase one, the
operations cost is $262,542 a year. We
feel that although this is high, it is
reasonable. If you are looking at costs
and trying to equate what these costs are
going to give us, I can say that in the past
month there have been at least fifty
phone calls from industry, congress, and
all over the country from people looking
for effluent data. There is a definite need
for effluent information throughout the
country. As Chuck pointed out, to do our
job in Enforcement we must have this
information. The Quarterly Noncom-
pliance Report is being changed right now
to contain more than just compliance
schedule violations. In the future it will
contain effluent violations and without an
ADP system I find it hard to believe that
there can be any other method to manage
effluent data.
Phase two is a day-to-day system.
It is considerably more expensive. If you
are going to have a complex day-to-day
system then you'd better have some sharp
people to maintain the system. It is not
just buying the software to maintain the
system, you need people who understand
the data, the system itself, and the
relationships of the data. We do not have
that capability right now and don't plan on
getting it for a few years. We do not
want to tie the Regions into a system
when we cannot handle it.
A development system under phase
one gives you several benefits as
previously mentioned. I feel that in
twelve months we can develop a phase one
system utilizing the Region II system.
Right now we have talked to Region VI
and VII and they have agreed to pilot the
system. At the end of the 12-months the
Regions would make the go ahead
decision. We would try to cater it to their
needs. We would also try to have Region
II oversee the whole operation, allowing
three Regions to be involved. The total
time of bring the system up would be 27
months. That inlcudes bringing all the
Regions on board and purifying the data.
This is not going to be an overnight
operation; it will not be cheap. It will
take time.
B-8
-------
INTRODUCTION - THE REGION II EFFLUENT DATA SYSTEM PURPOSES AND GOALS
Cliff Lundin
What my colleagues and I from
Region II are going to try to present to
you today, is an example or demonstration
of how one region has taken the problem
of what to do with effluent data and how
we have handled it. I just want to point
out that we are not here to sell our
specific system to anybody; we are here
to point out the concepts which we used
and some of the directions in which we
have gone in developing our system. I
think that you will see from our
experiences that we have proved that an
ADP system can be used effectively in the
EPA Water Enforcement program.
In the next few years, the emphasis
within EPA in the Water Enforcement
program will be on effluent data. That is,
to see whether or not the equipment
which has been installed can meet the
effluent limits which were set in the
permit guidelines. To do that, we
designed our LEDS systems.
We started our design back in March
1976. Our prime purpose in designing the
system was to enhance and streamline the
Region II efforts on Discharge Monitoring
Report (DMR) violations. In doing that,
we wanted to meet the criteria of the
Enforcement Management System (the
EMS) of which Chuck Evans and Bill
Milligan, just spoke. Another one of our
goals was to utilize manpower more
effectively. Previously under our manual
review system, only major DMRs were
reviewed. The data was entered manually
on a summary sheet; at times the backlog
ran from one to two months. Using our
LEDS system all permitees are reviewed
and only those that are in violation are
looked at by our technical staff. The
system also provided us with a historical
summary of effluent data.
Our third purpose was to improve
our response time. DMR's are constantly
coming in. In Region II, this approaches a
rate of 900 per month. Under our manual
system, we at times had a backlog of one
to two months in review. EMS calls for a
minimum response time. We have made a
commitment to thirty days or under. With
our system, we are meeting that commit-
ment and in addition, all DMR's (not just
majors) are being reviewed.
A fourth goal was to provide for
action violation tracking. What we have
done in our various outputs is provide a
past history, so that you can tell instantly
by looking at the report, how long a
permitee has been in violation, or whether
or not this is a one-time occurrence.
Another purpose was to provide a control
file from which summary date could be
obtained. Again, with the summary we
would have the data, right there at our
finger tips without having to research
back into the files. Another important
goal was to aid the permittee in fulfilling
his reporting requirements. Especially on
the minors, there was a great deal of
confusion on the part of the permittee
about what exactly was his permit
requirements, what had to be reported,
and when it had to be reported to us. The
uses of the preprinted DMR gives the
permittee guidance as to what we expect
from him. It also gives him a better
understanding of what his limitations are.
Our seventh purpose was to
eliminate administrative errors. A large
number of DMR's were coming in off-
cycle or with the wrong parameters.
These were relatively minor violations,
that were taking up a large part of our
enforcement time. With the use of the
DMR preprint, we practically eliminated
the administrative deficiencies.
B-9
-------
Finally, our last purpose was to
enhance our decision-making process so as
to see where we were going and what we
could do with the effluent data. In going
about this, we set up a number of design
goals. Specifically, we wanted to have a
system which was implementable in a
relatively short time with relatively few
changes to our existing set-up of
reviewing the DMR's. We felt that going
to a new form might confuse the
permittee; we wanted to use our existing
system with few administrative changes.
Our second goal was to have enough
flexibility in the system in order to adjust
it to our regional needs. At that time,
EMS was only a proposed system. We did
not know what the final version would be.
So we had to build enought flexibility into
LEDS so that we could adapt it later for
the various Headquarters requirements.
Our third goal in designing the system was
to be able to coordinate it with other
aspects of our regional system and the
various national systems. In Region II we
have a multi-tiered level of permit data
computer files. We wanted to be able to
relate this, by the permit number to the
other facility level data available. We
also wanted to be able to relate it to
national systems, such as STORET, so that
it would be compatible for future
comparison. Hopefully, utilizing our
system, we will be able to have an
objective evaluation of the permit
program and its effectiveness.
B-10
-------
REGION II: SUMMARY AND FUTURE SYSTEMS USAGE
Cliff Lundin
So you have just seen how, in a little
over a year and eight months, we have
been able to design a system which meets
our purposes and goals, which implements
the basic requirements of EMS, and which
provides a significant data base for our
use in EPA. I would now like to go into
some of the future intended uses.
The first use is our Suspects Report.
This should be in operation within the next
month to six weeks. Its functions will be
to look at the DMR's and determine
whether or not the permittee is possibly
lying to us. In completing the DMR he is
signing a statement that he is telling the
truth. The Act provides criminal
penalities for any purposeful false mis-
statements. One of the things this pro-
gram will do is to look at the DMRs for
whether or not the permittee is reporting
the same thing, consistently, without vari-
ation. We recently turned up one case
where the permittee had reported the
exact same values to us, for four
quarterly periods in a row. He will pop up
on the Suspects Report for this
consistency. The second criteria utilized
in this program would be whether or not
the value reported for the parameter is
outside the normal expected range. For
instance, a primary sewage treatment
plant may report a BOD of 2 miligrams
per liter. This is beyond its capability.
Our system will be programed to isolate
these facilities.
The second future prospect, for our
system is its use in our state overview
program. We have two states, New York
and the Virgin Islands which have been
delegated responsibility over the NPDES
program. New York has their own data
system. What we will be doing is
designing a conversion program. Once a
month we will get a tape of the reported
data and run it through our system. We
are going to establish a separate limit file
for the major discharges only so that we
can use our system for overview.
The third possible future report is in
"candidates for inspection". This would
somewhat combine the criteria of the
Dirty Dozen Report, plus the Suspect
Report to help us and the permit
engineers prepare a list of which facilities
need to be inspected.
Another application, which we are
using already to a limited degree is with
the "208" planning program. In our Status
of Permit Development (SPD) file, we
have a field called "208" Region. When
the 208 interim plans come in
inventorying the facilities in their area we
enter them into the system. We can then
sort on the SPD system to see the total
number of dischargers in the 208 Region.
Another possible future area is an
interaction with the Toxics program.
There is also the possibility of special
sorts, i.e. by parameter. We also are in
the process now of entering the latitude
and longitude for each discharges into our
system, so that we can do specialized
sorts by lat/iong, by counties, by major-
minor sub-basin, or even by SIC codes.
Finally we have talked about
depositing this data into STORET, or
interacting it with STORET ambient data
base, to see the effectiveness of the
NPDES program, to see whether or not as
total effluent loading goes down, river
quality improves. This is the basic
question, the effectiveness of EPA. We
may also get into some plotting and other
sophisticated techniques, particularly,
trend analysis in order to be able to
predict if a facility, based on past six
compliance factors, is getting nearer and
nearer to his limit, and when he will go
over it. We would also look at whether or
not there is too much room between what
he is reporting and what his limitations
actually are.
-------
To sum up, effluent data is a key
part of EPA's enforcement posture in
enforcing the Federal Water Pollution
Control Act amendments. Effluent data
can and is being used primarily for
enforcement. But I think that we have
shown that it can be used for many other
purposes particularly the 208 Planning
Program. Through a coordinated effort of
the technical, enforcement, and ADP
people, I think that we have come up with
an efficient and effective ADP system,
which has enabled us to get better use of
our manpower resources. It has enabled
us to gauge our effectiveness in enforcing
the NPDES program and allowed us to do
a timely review of effluent reports.
Finally, I think a system like this,
combined with our other systems, helps us
pull all the aspects of our enforcement
program together in order to advance our
goal of cleaning the nation's waters.
Thank you.
B-12
-------
QUESTIONS AND ANSWERS
Question:
Howard Hein:
Question:
John Sweeney:
Question:
Cliff Lundin:
How will OE Headquarters' recent initiatives along the lines of
implementing CAS effect your program? Do you plan to adopt CAS?
I guess it depends on what the final structure of CAS will look like; I am
inclined to take full advantage of whatever is available on the national
level. One of the things that CAS will have that the regional system
does not have is a report writer that will enable the system to be used by
the engineers out in the technical areas and perhaps also by the states. I
think that the system will be opening up to more people. A report
writer is a big advantage. One major difference between what Bill
Milligan was presenting and what we have in ours is that we do want to
keep all the data for six reporting periods because we think that is
important for the engineers and attorneys. Mainly the engineers use it in
reviewing what has been going on with the discharge before they make an
enforcement decision. Maybe if that problem is cleared up then there
would be no inconsistency between CAS and what our system does right
now.
I would like to ask a question of the enforcement people. Jack, I would
like to find out when you folks are going to go to the mini-computer and
whether or not you are looking at this application as something with
which you may want to concern yourself on the computer?
Well we are about ready to issue a statement of work. Arthur Young has
been contracted to do a feasibility study for the mini in Region II. That
is one of the systems at which we will ask them to look. It really
depends on what they find in the feasibility study. The system has
COBOL programs. Apparently COBOL is not available on the mini. That
is an obstacle. I cannot see us converting this system to a mini if there
is going to be a big conversion effort.
The second question that should be addressed to the enforcement folks in
the region is: Could you give us a description of the analysis done before
you went into the system. Then, what kind of impact has the system,
now that it is operational, had? Has the nature of the workload, not just
the quantity, changed?
Before the implementation of the system, we had and still have about
800-900 DMR's coming in each month. Approximately 400 of those had
to be reviewed manually. With this system, it has taken the load off New
Jersey and Puerto Rico. Prior to that, we had two people, temporary,
but full-time para-professionals, evaluating them. Three other people
from the staff also pitched in and helped on a time available basis. We
still had a backlog. With the implementation of the system, we again
B-13
-------
have two positions, again they are para-professional temps who review
the DMR's part-time. Their responsibility is split, half time with manual
review of New York DMR's and half with review of the LEDS reports put
out by the system. Three other people pitch in on a part-time basis for
the LEDS system reports. The nature of their work has changed.
Previously, all they would do is detect the violation, make a cover sheet
or a violation report form, list the violations, and forward them on to the
engineering staff. What is being done now is that para-technicals review
the exception report, then they consult the DMR for keypunch errors;
they review the permit itself to be sure that there were no notices of
non-compliance or anything in the permit file to indicate the nature of
the violation. As a third step, they review our compliance print-out
which is a mini-history of the permit, to determine whether or not they
have an adjudicatory hearing or an active request for modification. They
then come up with an enforcement recommendation. Their work is a
little bit more technical than it was before i.e., they detect the
violations and then they come up with an enforcement recommendation
which then goes to one of the specialists, who either okays or modifies
the recommendation. It has changed the nature of their workload. It is a
little bit more technical; it involves a little more research work, it will
eliminate a lot of the drudgery of sitting there and just manually
reviewing numbers. The nature of their work has definitely changed. We
have the same number of people, but we are getting a lot more
effectiveness out of them.
Chuck Evans: / do not know if I can really add a great deal to what Cliff just said but
there are some interesting sidelights to the question you posed. One that
I have observed in some of my original research in Chicago, relates to
the old system of leaving the job of the massive organization, filing, and
ranking of all of the effluent data. When you left it up to the clerks,
administrative assistants, environmental protection assistants, or
compliance technicians, or whomever handles this data at the first crack,
it is such a ponderous job that we were able to measure their workload as
well as their attitude during the peak, the shock loading as it came to be
known in the region. When this stuff fell on them at peak Monday
mornings in the cycle, we noticed that the technicians were calling in
sick more often and were taking more and longer breaks. As time went
on they were getting less and less work done per day in terms of actual
cases that they were able to complete. This was not just something
about which we had a hunch; it was dramatic enough so you could see it.
T*eir whoZe attitude changed. I do not know if this is something that
occurs across the country, but it occurred there. This stuff would just
fall in their laps in such amounts that they had no way to cope with it
except to stack it up and start at the top of the stack, take one DMR at
a time, and go through it. Since they never saw the stack getting
shorter, their whole job orientation, their attitude, everything just went
into a tailspin. In support of what Cliff has already said about the
accuracy with pre-printed DMRs, the fact is that a lot of the work is now
secretarial. The screener's job, or whatever you want to call it, it is a
lot more professional; they are encouraged to be more professional and
do it a little bit better. It lets them pay more attention to what the
numbers really mean rather than whether the decimal point is in the
right place or not. I do not know if this adds to your understanding of the
situation but it is something I thought was incredibly interesting when I
was doing research out there.
-------
Question: When you implement CAS, do you visualize having a total headquarters
file of all 10 regions or 10 separate implementations for each region that
would like to have it?
Bill Milligan: When / implement CAS, what / see is having one master file, sequential
in nature, and probably just the way STORET is being updated today.
What I see coming is that we will take that file and we will segregate all
the compliance schedules, the effluent data, the inspections, and
violations in separate files. They will be indexed and these will key our
facility file. We will get a permit number in which you win find a match
for the record we want. We will go into the other files, pull the data out,
and set it up for printing. For reporting purposes they will be indexed for
updating purposes, at least sequentially.
B-15
-------
ADMINISTRATIVE EFFICIENCY REPORT
Pete Gattuso
Clifford mentioned some of the
goals we had in developing our effluent
data system; I would like to show that we
have achieved those goals to a great
extent. In order to see how our system
operates, we looked at some of the
reports or outputs that we get from the
computer and how we use them. In doing
so there are two fundamental points which
really show the value of an effluent data
system. First of all as the data comes in,
it is screened against permit limits and it
is permanently stored on a computer file.
The fact that we store the data means
that we can go in at any time and retrieve
data from previous months and display it
in a form which gives a discharge history
for that permit. Storing the data has
other benefits which we will talk about a
little later. The second point is the
benefit common to all computer systems,
the ability to obtain a multiplicity of
copies of the output. This is especially
valuable in an agency like EPA where you
have several different groups with
different functions all working towards
the same goal. For example, in our
situation we have five different groups
intimately involved with these discharge
permits. We have the compliance branch
which is responsible for the initial detec-
tion and inquiry into the violations; we
have the engineers responsible for techni-
cal input both to EPA personnel and to the
permitee; we have the attorneys
responsible for the follow-up enforcement
actions, the Surveillance and Analysis
Division which goes out and samples the
facilities, and the state agency which
contributes to all these different areas.
And the point I want to make is that all of
these five groups really benefit from
having at hand the kind of reports at
which we can look. Consequently, the
Agency's response as a whole is greatly
enhanced.
The first thing we will look at is the
pre-printed DMR form. Basically, this is
the main source of our data. It is
generated from two basic files, the
facility level file, for most of the heading
information, and the permit limit file for
each parameter and corresponding
effluent limit. We generate this every
quarter, and send a three-month supply to
the permitee. When we send it to them
we include a notice which explains it to
the permitee. Of course, this tells the
permitee exactly what he has to report,
and it reminds him of his effluent limits.
It really imporves the quality of his
reporting to us. It is returned to us in the
mail and there is no loading involved,
because our keypunchers are trained to
take the form and keypunch directly from
it.
At this point I want to mention
something about accuracy of the data.
When these forms come in we have to
trust that what the permitee is telling us
is true. He does in fact sign a statement
indicating that he is telling the truth
under penalty of law. We do suspect,
however, that there may be some
permitees who are falsifying this type of
information, though probably not too
many. There are a number of ways that
we can deal with this. First of all, we can
go out and sample the facilities ourselves
and compare that data to what is being
reported. This is something we do
periodically for each discharger. We can
also run a computer program with this
data which can determine if a permitee is
possibly falsifying his report. Another
thing that really contributes to the
accuracy of the data is that we use it on a
day-to-day basis as a working tool, so we
have the opportunity to observe obvious
errors in the input and to correct them.
One tool is the effluent violation report.
B-16
-------
This is generated whenever a DMR is
reviewed by the computer and a violation
is detected. It tells us what parameters
were in violation and if there were any
administrative deficiencies on the report,
such as a failure to report an item. It also
gives somewhat of a discharge history for
those parameters in the form of the past
six reported values. In planning this
report we could have done it two ways:
First of all, we could have had only those
parameters that were in violation printed
out or we could have printed all the
parameters as long as there was at least
one violation. We chose the latter method
because in reviewing effluent violations
we have found that it is many times very
valuable to have other parameters which
may have a distinct relationship to the
violated parameter in a way that would
effect our judgment. Looking at the
report on the left-hand margin, we have a
single asterisk which indicates an effluent
violation, a double asterisk indicates an
administrative deficiency and a triple
asterisk would indicate both cases for that
parameter. Then we have the effluent
limits for each parameter, the reported
value, the frequency of analysis required
by the permit and reported by the
permitee, likewise for the sample type
and then we have the compliance factor.
Now this compliance factor is a ratio of
the reported value to the limit, or in the
case of a minimum reuqirement such as
dissolved oxygen, it is the inverse, such
that, in either case, a compliance factor
greater than one indicates an effluent
violation. The only exceptions to this are
p_h, temperature, and percent removal
where we felt a ratio would not
accurately indicate the extent of the
violation. In those cases we have the
acutal reported value as the compliance
factor. Then we have the most recent six
compliance factors for those parameters.
We could have just as easily put the
reported values there, but we chose the
compliance factors because it is much
easier to see at a glance how the permitee
has been doing rather than having to
compare all those reported values to the
limit. This report is sent to a number of
different places. It is sent to the engineer
for his technical input. If the violations
are very serious, it is sent to the attorney,
a copy is sent to the state agency, and a
copy is sent to one more very important
place, to the permitee himself, the com-
pany. Now it is a requirement of these
permits that if a violation occurs the
permitee should tell us why it happened
and what he is doing about it. If he fails
to do that, we send him what my boss ~
calls a nastygram. Basically this is a
violation letter telling him he had a
violation which was not explained to us.
He has 14 days in which to do so. The
letter refers him to an attachment for the
violations that we are citing. We simply
take this computer sheet, circle the viola-
tions and staple it to the letter. We also
include an explanation sheet. This
package constitutes our initial enforce-
ment action. We have had a great deal of
success with this; the permitees really do
respond to it. Of course, if we were
reviewing these monitoring reports
manually, it would take us a long time just
to discover those reports that have a
violation. With this system, we only look
at those that have violations. We can
respond to the violations sometimes
within a week after receipt of the DMR
and usually never more than 30 days. This
is for both majors and minors. We are
very satisfied with the way that it is
working out for us.
The next report is the total
summary report which contains all the
data we have, all the limits and the
reported data for those facilities. Again,
it is a very simple report. There is basic
heading information on top, and each
parameter is in the left-hand column.
These include the effluent limit, the units,
and the six most recent values. These are
not compliance factors, but the actual
reported values. As Howard mentioned,
this report would take up about 4,000 plus
pages on printout, so instead we get it on
microfiche. It turns out to be a very
convenient tool because all the different
B-17
-------
groups who are involved with these
permits have access to microfiche reader
or reader-printers. We get the microfiche
in five copies and distribute them. In a
very easy way, we have supplied all the
people who are involved with these
permits with all the data in our system.
Of course, if you save the old copies of
the microfiche, you will always have the
complete historical record of the
permitees1 discharge. Now this is of
obvious benefit for anybody who is at all
involved in these permits. Just one
example would be the S&A Division who,
when they go out to sample a facility,
would like to see exactly what is in the
discharge and what are the problem areas.
We had a case in the region just recently
where a permitee was found to be
falsifying his DMR. The permitee did
admit to falsification. The interesting
thing about it,is that we would have
caught him over a year ago because at
that time the S&A division went out to
sample the facility, except that they
failed to sample for that one parameter
that was being falsified. With this kind of
data, readily available to them, I think
that this type of oversight would not
occur very often. Now just briefly I want
to go into the remaining two reports, the
statistical report which simply tells us
how many DMRs were reviewed. The
total broken down into all the various
classes is located on the bottom. On top,
the classes are pretty clear. In the left-
hand column, we have the State and an
"F" for final limit; the "I" is for internal
limit. This report is of value to us for our
report to Washington.
Next is the administrative deficien-
cies report. This is generated whenever
DMRs are reviewed and no violations are
found but there are some administrative
deficiencies. We can use it in the same
fashion as the effluent violation report
although it is not of such great
importance.
Now, I want to go briefly into cost.
We have broken down the monthly cost of
our system. Computer and time-sharing
costs of $200 month includes all the edit
programs, inputs, reports, retrievals; it
also includes the microfiches. We feel
this is a very modest cost to pay. Key-
punching at 6,000 cards per month costs
about 10 cents a card. Then, we print
95,000 lines at $1.20 per line. Costs, then
amount to a total of $942.00 a month. As
indicated, the total is for 1200 permits.
This may be a little deceiving because
many of the permits report monthly, but
many report on a less frequent basis.
Thus, we are actually getting about 500
DMRs per month. In judging the cost,
however, the total has to be taken into
consideration wherever file size would
affect the cost. One final thing that I
would like to mention is that anybody who
is at all involved in getting effluent data
will soon discover that there is an awful
lot of it. The files grow quite large, so
the cost goes up. Some kind of archiving
is necessary. We plan to archive the data
in the near future, keeping six records for
each parameter on the file. We are not
sure just how we are going to archive it,
but STORET has been mentioned as a
possibility.
B-18
-------
Phil Taylor
I am with the Office of Water
Planning and Standards, Monitoring and
Data Support Division. Most of the work
in our division is associated with the
consent decree from which the 129
priority pollutants evolved. We do inter-
relate (Figure 1) with some key divisions
in Headquarters. CSD, the Criteria Stan-
dards Division, works on water quality,
criteria, and toxicology. We work with
the Effluent Guideline Division regarding
treatment technology and permits. We
interface with the economic areas of
OA&E. All these put together are in
concert with what is coming out of the
S&A Programs in the regions. We have
four major contracts associated with
environmental study areas shown in Figure
2. These deal with sources of pollutants
and an industrial inventory. We are
looking at the fate of water pollutants
after they have been discharged. We are
concerned with their relationships, with
their physical, chemical, and biological
behaviors in waters, and how they pass
through the food chains. We are con-
cerned with levels of the water pollutants
in the environment. With our contractors,
we will be monitoring along with the
regional S&A programs, ambiant waters,
fish tissue, water supply, and some
effluents. We will have some exposure
studies; our main interest in exposure is
regarding the human population in those
areas where there are drinking water
supplies contaminated or potential for
contamination. All of these keyed
together provide for risk assessment,
which will be going on for the next 12-24
months.
Figure 3 is one example of a risk
assessment approach that has a number of
modules. Modules may be entered at a
different point depending on the amount
of data available. As you can see, we are
very interested in animals, humans, fish
and aquatic life and the exposure levels
and how we can assess the environment
regarding the 129 water pollutants. The
use of our toxic studies will be quite
varied. The first level is in response to
the regulatory process and best available
treatment guidelines. We will be con-
cerned with ranking of industries, the sub-
categories, and the environmental
significance of the water pollutants. We
are going to assist in helping the Agency
in its position in legal challenges and with
control alternatives, particularly in
section 208, 307 and 311. In those areas
we know that there are some toxic
problems. We are going to indicate to
such programs as Air, Solid Waste and
Toxic Substances, that there are problems
that we cannot manage under PL 92-500.
For example, we have to assess fish tissue-
data, we are expanding that program with
the Fish and Wildlife Service. Environ-
mental mapping (Figure 4) of water
quality data shows at a glance mercury
levels in the United States. This area will
be expanded each year for example to
include information on fish tissue levels
averaging the 129 water pollutants. This
map indicates four different levels of
mercury present in the environment and
also shows us those areas where we do not
have any data. So, in working with the
regions and the contractors, we use this as
our first level to assess where we are
missing data, where we have data and
what the levels are. In this case, we had
10 years worth of data we can tell what is
happening in the environment such as
mercury concentrations are getting lower
in some geographic areas and in some
areas they are getting higher. As in
Figure 5, nationally it is about 50 percent
of the areas samples are getting better
and 50 percent are getting worse. It did
not show us anything significant except in
some area we do see trends of clean up.
Regarding the industrial inventory
project, we are using two types of data
bases. One is referred to as the EDS Data
Base which is similar to PCS data. The
other data base is Dunn and Bradstreet
(Figure 6) shows the industrial concentra-
tion for one of organic chemical SIC
category throughout the United States.
B-19
-------
REGULATORY DECISION
REGULATORY DECISION
[REGIONAL N&NITORING
AT ION
EFFLUENT GUIDELINE PROP.
VOMI t libr t
% 208/NATER QUALITY MANAGEMENT
S 302
S 307(a)d)
S 307(a)(2)
WATER QUALITY STANDARDS
Figure 1
-------
to
LU
I—t
o
g
LU
(N
Dp
£
EXPOSURE
MATERIALS
BALANCES
DISTRIBUTION
&
TRENDS
AMBIENT
RISK
ASSESSMENTS
HUMAN
TOXICITY
HUMAN
TOXICITY
-------
EMISSIONS
ENVIRONMENTAL]
FATE
( MODULE 1 J
GEOGRAPHIC
DISTRIBUTION
MODULE 2
FISH & WILDLIFE
EXPOSURE
C
MODULE 3
RISK TO
FISH & WILDLIFE
EXPOSURE
ROUTES
FISH & WILDLIFE
BIOACCUMULATION
HUMAN
BIOACCUMULATION
HUMAN
TOXICITY
FISH & WILDLIFE
TOXICITY
LABORATORY
ANIMAL TOXICITY
FOOD
CONTAMINATION
WATER
SUPPLY
Figure 3
METHODOLOGY FOR RISK ASSESSMENT
-------
Figure 4 Environmental Protection Agency
System
UXZMD
Cone. t of
Shading Range (ug/1) Covered Area I of US
No Data
0
.0001-.29
.30-.60
.61-19.9
All 1577 Cells
33
21
24
22
100
47
17
11
13
12
53
-------
Figure 5
Bivixcmental Protection Agency
CTOHET System
blank
t
4
O
No Data
Mora than 25% Inproveroent
Between 101 and 25* Inprovarent
l£88 than lot Change
Between lot and 25% Vtorsenlng
More than 25% Worsening
Area Coveredi 17 Percent of US
249 Cells
7 Cells
17 CellB
6 CellB
222 Cells
SOI Cells
-------
\ W^
flU T
C ~~ r* O IT T C V w i -• r'\
u i U t\ C ! o T O ; L. i !
CRGRNIC CHEilICRL MRNUF _^ ,
S.I -C.2869 FROM VA
D 4 B JULY/77
A CRG CHEn rrs
-------
The Dunn and Bradstreet data file has a
data base of 300,000 records as contrasted
to the EDS data base of about 55,000
records, so geographically, there would be
a much different picture of industrial
concenttrations. We do environmental
mapping and analysis of industrial data
the state levels.
I think the most interesting project
of the four contract areas is what we
refer to as industrial facilities profile
project. It is an inventory of industrial
facilities in the United States. We are
going to inventory industries at the
facility level for only the 21 industrial
categories identified in the settlement
agreement. This covers about 700 sub-
categories which will be quite an effort.
There are two major parts of the indus-
trial environment in which we are
interested. One is direct dischargs gen-
erally represented by the PCS data base.
The area which we will have the most
work to do is what we refer to as a
indirect discharge—those industrial facili-
ties that discharge into muncipal sewer
systems. For example, the direct dis-
chargers recorded are about 45,000
permits out of some 65,000 applications.
The indirects are unknown until we get
involved with actually inventorying those
facilities. When we consider 700 sub-
categories for 21 industrial groups, Dun
and Bradstreet files showed 300,000 faci-
lities. One sub-category alone has 55,000.
Thus, we can see that we have a very
formidable task ahead.
One of the steps that is involved is:
agreeing to the definition, the type of
data we want to collect at the facility
level. Figure 7 identified the first cut of
those data items that we are going to
collect at the facility level. In many
instances, it is generally agreed that the
SIC codes are in error and it will be a lot
of work to get them corrected. The other
situation is that we do not have good
location information on industries, parti-
cularly their latitude and longitude. We
are going to look at PCS data, our EPA
data base, Dunn and Bradstreet, municipal
needs files, trade associations, regional
files and state files. Before we go to the
regions we are going to take these differ-
ent data bases and, where we can, match
them and merge them together and make
assessment of which data we can
ascertain as being most accurate. After
that step, we will then plan to go to each
region. Our present plan is to do Region II
first. We plan to get to Region II about
the middle of January. We are going to
depend on the PCS data first, then (unin-
telligible) for the direct discharges. We
are talking with Enforcement and are
concerned with coordination of their work
and their data files so that we can
minimize duplication. Any data we have,
anybody is welcome to it. If anybody has
some data that will make our job easier,
we will be happy to work with them. We
are glad to hear that everybody is doing a
good job here because we will have to
depend on those regions that have data.
For the next cycle, we will probably be
able to develop a better strategy. We are
going to be using the industrial facility
data for material balances and distribu-
tion trends in the environment to assist in
the risk analysis. We will be concerned
with the geographic distribution covering
the 21 categories of industries, and the
special analysis concerning some of the
sub-categories. The profiles and analysis
of this data will be supportive of the EGD
program. We have a small contract over
the next 30 days for a special study on
municipal waste treatment to study the
129 priority pollutants. We will be work-
ing with industrial ranking to make an
assessment of which industries may be the
biggest problem and which types of indus-
tries have the biggest problems; We will
also be looking at point source versus non-
point source problems. In the coming
year, we have some other data bases that
we will be using to assist in analyzing
water quality and industrial facilities. We
have a digital data base of streams in the
United States which we refer to as a
reach file. It consists of stream which are
shown as a 1:2,500,000 scale map and was
digitized in 1976. This file contains
22,000 river segments. Each segment
B-20
-------
Figure 7
PROPOSED DATA ELEMENTS
TOR
INDUSTRIAL PROFILE STUDY
NPDES Number
EPA Region
State Code
City Code
D&B Number
County Code
Name of Facility, Business, etc.
Address
Area Code & Telephone Number
River Basin Code - Major
River Basin Code - Minor
208 Planning Area
Facility (Utility) Owner: Public,
Private, etc.
1972 SIC Oode(s)
D&B Number
River Mile Index
Industry Group
NPDES Permit Authority Natie
NPDES Permit Issue Date
NPDES Permit Expiration Date
Major Discharge Indicator
Effluent Discharge Receiving Type
(stream, land, ocean, etc.)
Discharge Flow to Municipality
Discharge Flow to Surface Waters
Discharge Waters Name
Dischage Point Location, Lat. & Long.
Discharge Number
Multiple Point Discharges
Compliance Schedule Date
-------
averages about 16 miles, and covers about
350,000 miles which is about one-tenth of
the estimated total miles of streams in
Figure 8 is a digital plot of stream
segment data for one portion of the U.S.
We are working with the Water Research
Council and USGS with this data base. We
are interested in identifying industrial
facilities along these streams. This data
base has many other uses of which differ-
ent people can take advantage. The data
base can be used for example to supply
water resource statistics, water manage-
ment statistics, miles of stream with
improved water quality miles of stream
not meeting standards, and modeling.
Also data on industries by stream
segments, which industries would be under
permit, which industries are discharging
toxic pollutants, which industries have
water quality data. It would provide a
variety of different things that people ask
regarding river basins and segments. For
modeling, there will be macro-type
modeling, such as mass balances for con-
servative substances. We will be able to
know what is going into the water envi-
ronment by individual streams. At the
level of 20,000 stream segments, there
are many things that we will be working
on, keeping in mind we are talking about
one-tenth of the streams in the United
States.
B-21
-------
Plot Of All Streams '.ngitized
In Portion Of U..S.
Figure 8
-------
QUESTIONS AND ANSWERS
Question:
Answer:
Question:
Answer:
Question:
Answer:
What are your plans for the (unintelligible) data that would be collected
via your contractor or with the compliance inspection program that
would be carried out by the regional S&A people?
First of all, the inventory that we win be making is at the facility level,
it is not at the pipe level. In cases of direct discharges that can be
transferred to their use; the question of the effluent data there is three
sources of data: regarding the 129 water pollutants one is guidelines
Division. Our contract and the one in the Effluent Guidelines Division,
there is our contractors and the S&A programs in the regions. Regarding
those effluent data we plan to put those in the water quality file. We
will have pointers to relate to those effluent listing in the inventory.
How are you going to keep your data up-to-date through the years?
At the moment, we are not planning to update the data other than do the
first cycle with the contract. At the end of the contract we will assess
what our position is and what our next step will be.
Phil, the basic issue is how many independent kinds of efforts we are
going to have going on within the Agency? I am wondering if there is
anyway we can take (unintelligible) particular subject at this point. It
concerns me that we have regional systems that are being developed; two
national inventories of effluent or discharging facilities, one in Water
Enforcement and one in Water Programs. We do not have a lot of overall
coordination in the development of these systems. It is a hierarchial
type of problem. At the top you have two major offices. The Office of
Enforcement and the Office of Water Hazards. It seems to me those are
the two offices at Headquarters are the most involved with effluent
data. Over on one side, we get into the program enforcement. Then, we
run into another hierarchy with 10 regional offices being at different
places in terms of implementation. Each region has its different
priorities, different personnel, different capabilities. It is hard to reach
agreement even among them as to whether there is a need for an
effluent data system. Even if there is, what is the time frame in
implementing such a system. I think the CAS study is going to be a
mechanism that eventually hammers out some kind of resolution. I think
that the mechanism is there. I think that study has to be implemented
with the Office of Water Hazards Materials. That was one reason why I
asked Bill the question of whether that would be considered in the CAS
feasibility study. To me, that seems to be the mechansim to carry it
about. What other alternatives do we have for getting people together
and trying to resolve this question of sharing effluent data?
We know our contractors cannot do everything. We will be going to each
one of the 10 regions. We will physically go out to each one of the
regions and sit down and figure out the best way to identify and work on
the industrial facility profile problem. Some regions are in better shape
than others, and some have less resources than others. All we are trying
to do is to get a list of those industries at the facility level. We know
B-22
-------
Question:
Answer:
Question:
Answer:
that there are a lot of errors in that. It is a lot of work to do that but we
are anxious to get it done because we need to make an assessment to
support work related to the consent decree and make an assessment of
the toxic substances in the water. We will work cooperatively with
anybody who wants to so we can get this thing on its way. I think part of
the file can be very helpful to the different programs to come to some
agreement that there is a facility out there, and yes it is still producing
pollutants whatever its number. I think there are a lot of things that
could be accomplished cooperatively over the next few months. This file
can be used by a variety of people, and at the same time, we will be
taking advantage of different software packages and analysis packages to
better assess what the data means. I think that another area that we
have not talked about here is analysis, and how to make use of it. We
need to use the data we have, even if it is limited, or at least try to get a
better handle on what is out there in the environment. Is the water
getting better or is it getting worse? Which industries are cleaner than
others?
Who was going to coordinate this whole overall effort in EPA in terms of
working together on effluent data?
It seems to me that Enforcement plays an important role in that respect
because of the bulk of the effluent data that is being generated by the
Agency through the EPA permit program. Perhaps, we can use the CAS
vehicle to bring about this coordination. I do not think you can look to
the regions to bring about this kind of coordination. I think it has to
come down from Headquarters. It seems to me this kind of effort should
be left to Headquarters, not just to coordinate, but to pull the regions
together so that they can become actively involved. I think that there is
a reluctance on the part of the Office of Water Enforcement to take the
leadership role in managing the effluent data. They are looking at it
strictly from the standpoint of reporting. The data will be made
available to other people in the Agency.
I have a question, Ted. We talk about trying to get a uniform agreement
on the (unintelligible) that we mentioned to get involved with effluent
data within one program area Enforcement. There is still not really a
general agreement as to where we are going with effluent data. Maybe
you could elaborate, Ted, on how your region would feel, how you react
to that CAS study? Are the regions so dead set against effluent data
that it does not want to get i nvolved with any type of study along these
lines?
As you are aware, the situation that the regions faced two or three years
ago was that we were trying to define what the regions, as a group,
needed in the way of an effluent data system. We had a meeting of the
10 regional ADPs about two or three years ago. We attempted to sit
down and hash out our basic needs. At that meeting, the 10 of us could
not come to any agreement whatsoever as to what the basic set of needs
was. Headquarters then went on to pursue the development of a
compliance analysis sytem. I suggested to them, when I was down at
Headquarters earlier this year, that in order to insure the development of
the sytem, we needed to justify the future uses of that system. They had
B-23
-------
to obtain the concurrence of the Regional Administrator on the system.
Now, I think it was pointed out earlier here, that Region III had two
different responses to CAS. We are not against automating the effluent
data per se. But the problem we are having is that CAS as originally
proposed has some very significant weaknesses in it. One that has
already been mentioned is involved with the initial data collection
efforts. I believe Arthur Young estimated that it would take 10 man-
months to collect the permit data for all 10 regions. I believe your
estimate alone said 9-man months to do one region. It looks as though
the data from the regions is grossly different from that which Arthur
Young has submitted. The second is that Arthur Young had indicated, I
believe, in their feasibility studies that one of the justifications for going
to CAS was the manpower savings. Again, it has been pointed out that
here you really do not save manpower. What you do is shift the kind of
work that is going on. If the Agency believes that you save 40 positions
by automating DMR's I think they are in a sad surprise when the system
actually comes off, Especially if the regions are then told that we now
have to eliminate 40 positions from the Enforcement Program. I think
there will be some adverse reactionsfrom most regions. The third
problem that we had with the system as it was proposed was that we are
having problems getting the state data into the system, and we are
running into questions about how are we going to require the states to do
this?
So, we are not opposed to automation. In fact, we still see that there is
a need to have this data somewhere available for use for water planning
for toxicology and for overall environmental monitoring efforts to help
us develop the environmental quality indices that we are moving toward
as an agency. The problem that we have right now is the mechansim that
is being proposed to do that. I would urge OE that they should come out
with a new feasibility study that addresses, in detail, the resources that
are going to be required to implement CAS. As discussed in all of our
previous zero-base budgeting meetings, part of that feasibility study
must include the operational costs for the regions for at least the first
two years. I hope that OE is aware that they must include those costs
because that does add a significant change to the impact of their cost
projections for CAS. We had some reservations on the (unintelligible) as
to what was required to implement CAS. We found a manpower savings.
What happened was the time, the position saved in the actual manpower
screening of DMR's was put to use in more enforcement follow-ups. So,
it allowed them to re-invest those positions in some priority stuff, really
getting into what they should be doing. The one concern voiced by the
enforcement director in our region was that if you start to include all of
the minors in this system, you are going to have a list of violations that
he is never going to be able to handle. He is concerned about the data
problem itself and is against putting minors into the system. How can we
deal with minors' reports if we do not have the resources to follow-up on
the violations? We have been asking that question of headquarters and
even of our Enforcement Division. Why have the data come in, in the
first place, if we are not going to do anything with it? I can perceive
two main points coming out of' the discussion that we have had today.
The first is that the CAS feasibility study really needs to be looked at
again, more legwork has got to be done, with each of the regional offices
B-24
-------
in terms of trying to explain the purposes of using an automated data
processing system for screening DMR's. We are trying to pin down the
resource requirements and projected cost savings. The second item is
that some effort above the EPA, whether it be a task force or some type
of steering committee, should address the question of the agency's need
for effluent data. How that would actually come about, I do not know,
but that would be one of the recommendations that would come out of
this seminar here today. Is there anybody that would like to elaborate on
this or are there any major points that should be brought out?
Answer: I think one thing that we could do with the CAS response is to distinguish
between two issues; one is the automation of DMR's and one is the need
for effluent data. They are not necessarily coincidental. One of the
basic problems that law enforcement people have with the CAS study is
not an effluent data collection per se, it was an automated DMR system
which, in a sense, was to make the data effort more efficient. The law
enforcement people felt that they could deal with violations without the
automation of DMR's even though they would still like to have effluent
data available to them for various analysis, etc. How would they know if
you did not automate the DMR function? How wouZd you collect the
effluent data? Do not confuse me, I am not saying that we take the
DMR data and put it back into an automated system, what we are really
talking about, is taking (unintellibible) and putting it under the
microscope, detecting the violation, and throwing the rest into (unintel-
ligible). You have a whole series of clerks, engineers, and programmers
involved in this whole process. What our enforcement people are saying
is that they do not think that whole enforcement procedure is necessary.
They can see a procedure for somehow getting hold of selective,
accurate, valuable effluent data, i.e., having a system that can
manipulate the data for various analysis,- but not necessarily taking
automation of DMR's as a mandatory procedure. They are very opposed
to that idea. I think the new CAS study could make that distinction
because I think that it is an important one for the Regional Enforcement
Officers.
B-25
-------
(MONENTARY TAPE FAILURE: SESSION RESUMES WITH...)
We are finding that many of the questions they had were already
answered. I think Dallas was one region—they started checking back into
it and tried to come up with a different view that it might not be as bad
as they had originally thought. They felt that our cost was not justified.
We cannot justify our cost resources in the study. We ahd a subsequent
meeting with MIDSD and PRO and we specifically said where are your
problems? Arthur Young was there. The answer we got at MIDSD was
that they had no problems with our resources and cost.
The third group that we have to go through is Program Reporting. They
want us to do an impact study on how the system will affect the regions.
I was talking with Arthur Young yesterday. We have our outline from
Program Reporting and now we are trying to accomplish that. We have
already begun on it, and we will h ave it done in about three weeks. Does
that answer your quesiton?
Answer: Yes, basically.
Question: Our region has initially taken a look at the various systems which were
proposed. There seems to be no concensus that we really wanted to get
involved in tracking and handling an effluent data system. With the
Region II presentation, however, we see that there were more nuts and
bolts. I think my regional management would have a lot easier time
swallowing it and understanding what it is. I am hoping that you were
going to do that in one way or another. Is that the case? You are going
to come back and say that here is what we are focusing on?
What we are focusing on is the complexity of the data. I felt this all
along. It is a monstrous job. Region II has done the groundwork for us.
Arthur Young laid our the structure for a system that (unintelligible) for
detail data only. Region II has already accomplished that. We could use
a systme like EPA to get a report writer, I think we are going to end up
in a very good position for all these reasons. But again, it is only going
to be what you put into it.
Bill Milligan: / want to ask a question and hope to get some response from some of the
other regions. If you had the capability of the Region II system available
from a national system would you use it?
Answer: Ted Standish from Region III. As I understand it, the current regional
comments coming in from the Regional Administrators is that we are
against automation as it is currently proposed. We are willing to look at
any pre-proposal by Headquarters. We are primarily concerned that OE
and OWHM talk to each other and make sure that there is coordination.
We are also very much concerned about the problem of our delegated
states who have to fall to the permanent use their own DMR's. We have
problems under OMB where we cannot force any state to use Agency
software. We are going to have problems in trying to get them to
convert their data into our format. Now you have addressed it by saying
that you are willing to talk to someone at Headquarters to underwrite all
B-26
Bill Milligan:
-------
the conversion programs, but that is assumming that the states are going
to go along with that, and that the regions' (unintelligible) is willing to
condition the grants. So, as of right now, the general consensus seems to
be: we can handle the situation manually, for the foreseeable future
unless we see a better proposal out of Headquarters, this will be our
conclusion. I would think what Mike was getting at from Region I is that
if you did come back to the hard proposal, the description of the Region
II system, I think it would simplify our review within the reigon to have
something specific at which to look, something specific on which to
comment. That would give us the resource impact.
Question: Ted, could you shed any light on what kind of discussions you have had
using STORE! or fitting STORET into (unintelligible) information data.
Answer: / presented our implementation plan to Sam and he is on his way out here
right now. I have somebody in my office right now that is going o work
with us on data retrieval for three ot four months. We have been very
scared. I think it is extremely complex; it will take a ot of people with
experence that we just do not have on board. I am relying on Sam's
service to help us out in this area. We got some very good input from
him already. The plan we have is to take the data and load it in the
retrievals. Once we get our system up and running we are operational.
We plan to have a combined retrieval using a PCS-type of format, select
retrieval which would go into both STORET and NCAS, retrieve the data,
and set it up for printing. I have not had a chance to sit down and talk
with Sam much about that. Most people know about it. The only
objection I made to Bill was the fact that (unintelligible). Why don't we
use some intermediate system? Why don't we just go ahead and use
STORET directly? We got into the politics and discussion and all that
sort of stuff. I do not know who that one is going to come out. The fact
that we are going to wind up somehwere in concert with each other, I
think it is a reZativeZy giant step if you ask me, and maybe we can solve
the other one, too.
Is that going to built into our final CAS feasibility study?
Yes, I guess it would be.
We have already gone ahead with you guys on a pilot on this deaZ to see
how it is going to roZZ. I am pretty sure Region VI has gone ahead to give
it a shot. If we do not like the way it operates, we will probably wind up
doing our own, just Zifce we have done with our other systems. That is
basically where we are going to be, as part of our implementation
procedure. We go ahead with this thing nationally, Region VI and VIII are
going to have to sign off on it. We are not going to shove this thing down
anybody's throat.
Question: I would like to address this question to Region II. How do you resolve the
inconsistent manner in which permits are written to obtain the pearly
conditions utilizing summer students? That came up earlier in our lonely
efforts. The permits in (unintelligible) are very wacky to say the least.
Question:
Answer:
Bill Milligan:
B-27
-------
Howard Hein:
Question:
Bill Milligan:
Question:
Bill Milligan:
Question:
Jack Sweeney:
How we resolved it was that we appointed one person, Cliff, as a
technical coordinator to interpret the permit conditions. When any
question came up, if necessary they went and tracked down the person
who actually wrote the permit to get the interpretation. That would be
documented in each file by something in writing such as a written memo.
But we had one person who was responsible overall for seeing how the
conditions were interpreted. It worked out pretty well. We tried to
bring that out in the implementation, i.e., that filling out data bases is a
big job; you technical people have got to get involved with spearheading
and interpreting the data. I think in the original CAS, one of the
proposals was to do it by contract. The problem was that you have to get
regional involvement, you have got to get the people that actually wrote
the permit to interpret them. Another thing that come up with the
permits is that they were confusing to summer students; they were also
confusing to the permit engineer. A number of permits were revised, or
at least a permit was clarified to what the permit acutally meant.
You mentioned the requirements of the NPDES Program to obtain
information form the states for Headquarters requirements. Many of the
states have programs, but in all probability they would not have all the
data elements in the system which you would require. From where would
you get this informaiton?
We have already started using CAS as a contract to fill in any loose data
we do not have. Region V is doing it now at CAS and we are going to
start doing it with everybody at CAS. Computer Science is going to fill
out our missing data.
Are you going to go out to the states and find their BMS also?
That's right.
Does the same thing hold true with the development of programs for the
states who do not have their own computerized system?
The ultimate responsibility for the system lies with the regions.
Somehow the regions are going to have to get that data. There is a
conversion problem between the states and the regions computerized
data-wise. CSC can handle that I think. That information has to flow
into the regions, now it goes directly to the states and we do not get
copies of them. We have to figure out some type of a mechanism to get
it out. It will not be a simple one-two-step combination. We are talking
about a very complex system. Headquarters must put out some type of
guidelines along these lines then. Or is it going to be a volunteer type of
thing like everything else? It is a tremendous problem, I admit that. We
cannot just sit down and listen on the phone and request the information
we need. It is amazing what people want to see and what we are
supposed to have as an Agency. I do not think it will stop just because
there might be problems. We just have to find a way around it. There is
a need for the states to have personnel who can obtain this information,
through the burden lies within the regions to obtain this information. Of
course, we are saddled with the need for additional people, money, and
B-28
-------
Question:
Bill Milligan:
Question:
Bill Milligan:
what have you. In the case of New York State, a good case in point, they
have their program, their own system, and their own DMR. Yet, we have
determined that the adequacy of this list is not acceptable and we are
going to be loading the permits into our own file and getting the
reporting data on cards or tape and writing conversion programs
ourselves so that the data can be screened by our programmer. That is
what we are deciding. I think we are getting involved.
My impression is that for Region VI and VIII, being in the pilot study
seems to be based on the fact that they volunteered. I would wonder if
Headquarters had given any thought to the criteria of Region VI and VII
based on say, Region III, IV and V? What the compatibility would be with
their being different programs? Along these same lines Dave Write
alluded that if he did not like it he would build his own. Bill you
mentioned the fact that the two regions would sign off on it once Region
VI and VII had signed off on it. It is going to be mandatory for the other
regions to accept it? If it reaches this point, I think we come again to
the question of: how do we require delegated states within the regions to
pick up on the program from an unfortunate standpoint?
Number one, Region VI and VIII sign off, Region II will also. Region II
will be overseeing the whole operation with Headquarters so three
regions will be doing it. It will be mandatory if they go with it. I was
told that the regions are responsible for the state's data. It will be your
responsibility eventually to (unintelligible). If there is no conversion
program, things like that are possible. If they do not have a system, that
is the only way to do it.
All right, let us go back to the one aspect of the question I asked. Where
it seems like VI and VIII volunteered the pilots in this instance, did your
office, in fact, take a look as to how they would compare against some of
the other more heavily permeated regions and that the impact would be
credible in this instance?
All right, look at what Region II has already done. For I, II, and III, we
are assuming that these regions are pretty similar. We want to get the
West involved. Region VII already had a system set up using information
data. We thought we could probably use their data to convert over.
Region VI will be the real test, because they have a tremendous number
of permit applications down there.
B-29
-------
PANEL C: EXCHANGE AND STANDARDIZATION
Chairman: Ted Standish
Panelists: Maureen Johnson
Gail Huguet
Catherine Tittle
3ames Flatten
OVERVIEW
Ted Standish
What I would like to do to begin is to go through some of the background explaining
why this issue has come up at this time. Back in 1972 or 1973, data processing credibility
was very low in this Agency. I think that there were several reasons for that. First, we
had problems with the General Point Source File. We had problems with the conversion to
OSI, and we had problems with the Research Triangle Park 360-50 Computer Center and
the attendant problems with the air systems. In addition, we had several problems with
Congress and OMB. I would say overall, in that period, there was a general inability of
data processing to meet the user and management needs of the Agency. There was a
general lack of faith on the part of the Agency in data processing ability to serve any
useful purpose. In addition, there was a great deal of duplicate effort because of the
fragmentation of data processing, both within the regions, among Headquarters units here
in Washington and in all of the R & D installations. During that period, 1972-73, I believe
all of the organizations that were involved in data processing started trying to regain the
credibility of data processing by developing basic tracking systems. Rather than going for
the grand design of GPSF, we all started looking at the individual needs of basic programs
such as the NPDES Permits Program, just to track whether or not we had issued a permit,
not what the effluent limitations were in that permit. To a large extent, their efforts
were individualized and they were not coordinated, especially among the regions. This
resulted, for example, in the permits area, in 10 different management information
systems that handled whether or not a permit was issued. During the same period,
Headquarters, in trying to establish their credibility, started to develop a very limited
capability system, which is the Permit Compliance System. It was successful in that it
met the needs defined by managers, and it was developed within a reasonable period of
time. However, there were problems in that there were still Headquarters and regional
efforts going on in diverse areas. Few regions adopted PCS as their system within the
region.
I think it is generally agreed that the reigons are viewed as microcosms of the
Agency. Each region has all the programs that are going on in Headquarters. It becomes
apparent to all of us in the regions that we need to coordinate our efforts in order to
reduce our duplicative work, and enable the transfer of systems, among ourselves. The
problems that we faced, however, were the following: first of all, we had no mechanism
for coordination; secondly, we had no documentation standards; thirdly, we: had no
software design standards, in terms of structure and compilers. The hardest problem with
which we had to deal with the regions was that specific data was included in the software
C-l
-------
itself rather than being in tables. If any other region wanted to pick up another region's
software, you had to go in and physically modify the source code itself. The last problem
we faced was that there were no equipment standards. The software developed by one
region to operate on their equipment might not operate on the equipment maintained by
another region. It was also apparent to the regions that we need to modify Headquarters
software in order to meet regional conditions.
In the 1973-1975 period, one of the things going on was that centralization of the
data processing activities in several regions made it much more apparent that, in addition
to dealing with individual programs, there was a need to coordinate and integrate data
across programmatic lines, including the Assistant Administrator lines in Headquarters. I
think those of you who attended the Effluent Data Systems session yesterday got a flavor
of that when we started talking about the fact that there were at least three offices
currently involved in effluent data: namely, the Office of Enforcement; the Office of
Water and Hazardous Materials, and the Office of Toxic Substances. The regions began
discussions of standardization about two years ago. Again, the reason that we started
bringing it up was because we were interested in trying to transfer software among
ourselves. The other problem we had was that we knew that the documentation problems
were preventing some of this transfer. The third thing we faced was that we were
discovering that we had the one-man or the "indispensable-man" problem. We had one
person who had written the software or we had one person who knew that software. When
that person left, that software essentially became useless. Concurrent with the effort the
regions started in standardization methodology, there was a presentation at last year's
conference on structured programming. There was a subsequent proposal by the
Management Information and Data Systems Division this last summer concerning the
adoption of some methodology for structured programming. There was also the
development of the Model State Information System for the Water Supply Program. This
was done using the HIPO method developed by IBM for structured programming.
I believe that there are several factors forcing us to look at standardization and get
it under control. First of ail from the technical side, one of the driving forces, at least
from my reigon, is the proposal by MIDSD to come out some time during this fiscal year to
review our regional operations, particularly whether or not we have documentation for our
software. I have problems in that area and I will have to do something about that before
that review occurs. The second thing that we are all faced with is that we have the
Development, Maintenance and Operations contract, where we have Computer Sciences
Corporation developing software for anyone who puts in a task order. The unfortunate
problem is that we have no standards under which the contractor is to operate. Any
software that comes out is essentially at the design requirements of the originating
organization. Thirdly, we are faced with the situation of regional mini-computers being
installed with at least three regions currently having minis, and several more in the
process of looking at the feasibility of installing minis. We have the laboratory
automation efforts going on which could standardize the methodology for automating the
S&A laboratories within the regions, and all of the methodology for automating the labs in
the R&D sector. We are also faced with the word processing data processing interface. It
is not very clear where word processing and data processing begin. The most important
aspect that is pressing us right now is the 1981 procurement where we are required to go
out on a fully competitive procurement, which could result in non-IBM- or UNIVAC-
compatible equipment. To the extent that we are not standardized, I would hate to see
the problems that we will have trying to convert to that system. It is all fresh in our
minds right now, the problems that we had converting from OSI to COMNET, and that was
IBM to IBM. One other thing that became apparent reading the 1981 study is, as I
understand the GSA rules, that the contractor who is awarded the new data-center
*
C-2 ,
-------
contract is not responsible for converting any software that is not documented. That
means a little bit to me too, in that if I have a non-IBM or non-UNIVAC system, and I have
some undocumented software, I am faced with having to convert it myself.
From the management standpoint, we are seeing that data processing has grown in
credibility. We are also seeing that there are significant manpower, or person power,
constraints within the Agency so that more programs are relying on data processing to aid
their activities. I think Water Supply is a very good example of that. In addition to the
new programs that are coming up, we have existing programs which are rapidly expanding
in their usage. The continuing discussions on Effluent Data Systems is one of those areas.
In view of this increased reliance on data processing, without significant increase in
manpower, there is a much greater need now for us to coordinate our development efforts
to relieve the manpower shortages. In addition, because of the installation of the regional
mini-computers, there will be the need to transfer programs between those centers. We
have to get away from the idea that quick and dirty programming efforts, which can be
easily done on a mini-computer, are going to be acceptable without documentation. That
is what the Agency has faced all along. If you look back at every system we have ever
developed, the idea in the beginning was that it was going to be a quick and dirty system.
We did not need to document it; subsequently, we have ended up with a lot of software, no
documentation, and no one who really understands how it works.
There is also going to be a greater need to integrate data among the programs. The
208 area-wide study was one of the first to indicate that there were problems in trying to
tie the data bases together. The 1981 study that was developed by Informatics stresses
the need of the toxic program to tie different programs together. There is also the
current emphasis of the agencies to develop environmental quality indices which will
require us to start tying our data together. I believe the last area, forcing us into greater
coordination, is that management is relying to a greater and greater extent on the data
for decision-making and strategic planning purposes. We are getting into the position
where we have to avoid conflicting actions between programs. For example, it is
ludicrous, in my opinion, for enforcement to issue a violation against a discharger, if, in
fact, the problem is that we have not awarded that discharger, in the case of a
municipality, his construction grant. Right now that coordination effort is being done
somewhat on an ad-hoc basis manually, but it is something that could be done through
automation, since all of that data is currently in existence somewhere in systems.
I would like to go through the members of the panel now, introduce them, and briefly
say what they will be discussing.
Maureen Johnson is with the Management Information and Data Systems Division at
the National Computer Center in Research Triangle Park. She will be discussing the
software and documentation standards that are going to be proposed. Next is Gail Huguet
from the Delaware Valley Regional Planning Commission, which handled the Philadelphia
208 Study for Region III; she will be discussing the integration of data across programs.
Next is Jim Flatten from the Management Information and Data Systems Division in
Headquarters, who will discuss the data processing equipment standards. Finally is Cathy
Tittle from the Management and Organization Division in Headquarters, who will discuss
the proposed word processing standards that are coming out.
C-3
-------
SOFTWARE AND DOCUMENTATION STANDARDS
Maureen Johnson
One advantage of having standards,
both through the design and the documen-
tation of software, is to help in the
evaluation of the final product. If you
know what to look for and if you convey
to the developer what your criteria are,
chances are that those are going to match
up a lot better. It should also reduce
redundance as far as developing programs
are concerned and avoid two regional
offices doing essentially the same thing.
In North Carolina, I am sure there have
been occasions where offices right next
door to another one, but in different
divisions, may well have been working on
the same sort of problem. Certainly in
the design phase, if standards are applied,
there are reliability factors. The confi-
dence level that we can have in the
software being developed will be greatly
increased. It simplifies costing and staff
projections. If essentially the same things
are being done in the same length of time
and about the same level of effort, it will
reduce the dependency on individuals. It
is human nature to assume that good ole
Maureen will always be around. If her
program needed to be modified, she would
take care of it; if it needed to be run just
a little bit different with different
parameters, she would take care of it; she
always did. But who is it that develops
the software under contract? Where is
the person in a month? A year? Two
years? Certainly they have changed
companies three times. Just try finding
out why a particular switch was set, or
why when you think it is there, it sprouts
up somewhere else.
Standardization does provide a
method of getting things done the way you
want them done without day-to-day con-
trol. It reduces petty decision-making
time. In terms of coding, for instance,
the coder may spend some time deciding
which way to code a loop, which way to do
a very minor detail. If there is a standard
established, there is no decision; it is just
done that way. It might not be the most
artistic way of doing it, but it works, it
has been proven to work. One other
aspect of standardizing programming is
that it will eliminate some of the known
pitfalls into which many programmers
fall. It will also reduce the life cycle cost
of a system. The front end cost will be
reduced, because programming efficiency
should increase the effectiveness of the
software that should be enhanced.
Certainly, maintenance will be reduced.
In fact, we may hav6 contract money for
development, but what about
maintenance? When you need it done will
you have support? It certainly turns your
stomach when you have paid a certain
amount for software development, and
you find it must be modified, and the cost
of modification is twice the original
development cost because it is not docu-
mented, nor can it be converted if it is
not documented.
Bottom line, what does standardiza-
tion do? It enables us to communicate
with one another. There is a writer's
golden rule: write unto others as you will
be written unto. Readability in and of
itself is reason enough for standardizing
our documentation and the way our coding
is written on the page. Naming conven-
tions is another area that must be
addressed. Data elements. Data element
dictionaries. What are dictionaries? They
define terms. If someone's getting into an
argument, maybe they will have the
foresight to define terms. If you are
going to transport a program, or if you are
going to use data from one program from
one system in another system, and the
same term is used to mean something
different, or if the same data element has
a different name in the two systems, you
have a lot more work, a lot more time,
and a lot more effort than if those had, in
the first place, been consistent. If one
person is talking about a system flow
chart, another talking about structure
-------
flow, and someone else talking about
schematic logic, are they really talking
about the same thing, or are they
different? Just what is required in a
documentation package? We will also be
addressing style and coding conventions.
What do I mean by coding conventions?
Perhaps limiting the number of "ifs"
nested in a COBOL program. Did you
know that if you nested too many "ifs" in
a COBOL program that the code might
fall in on itslef and create a black hole?
That was to see if you are listening!
In the area of program and system
design, we will be advocating modular
construction and requiring, hoping, and
praying for top down design. We will not
be stating a specific methodology;
however, we will be teaching the Jackson
Method after the first of the year. What I
have seen so far is that those people who
have studied and used that method
become converts. In other words, it
seems to sell itself. At this point, I think
we have realized, that any method is
better than none. If it is a structured top
down approach, it will be better than
bottom up. How are we going to do this?
These standards should be applied to all
new software development, especially,
that done under contract. It is easy.
Once the standards are written and have a
place in a manual with a chapter and
verse page to reference, what does it take
to put them in a contract? The documen-
tation standards should be applied to any
documentation written even if the pro-
gram already exists. Ted mentioned that
somebody's going to come looking and see
if you have documentation. Chances are
you are going to start rolling up your
sleeves and doing some documentation in
the near future. Would it not be nice to
have some standards? First of all, within
your own office, you are going to have to
come up with some sort of format from
which your people can work. With
agency-wide standards, everyone will be
doing it in the same basic format, with
the same requirements. Low and behold,
we may be able to read what someone else
has written, and know where to look for
something in a documentation package.
Certainly the documentation standards
should be applied to any documentation
being prepared as part of the conversion
effort.
Goals that we have set for ourselves
include: easy to use standards. If they are
cumbersome, no one will use them. You
will get so much grief from contractors,
that you will finally give in. They have
got to be easy to use and they have to
make sense. They need to be clearly
stated. Maybe we can adhere our own
golden rule of writing.
What is the status on all this? What
is being done? We had a survey done by
CSC of the techniques currently being
used within the agency, both programming
techniques and documentation standards.
We wanted to know how much had already
been invested in one set of standards or
one technology, and our decisions then
would be tempered by that knowledge. If
there was a close advantage between two
different ways of doing something,
certainly that heavy investment on the
part of one might weight that decision.
We certainly wanted to avoid throwing
something away that was already
established and proven; we also wanted to
solicit copies of existing standards. We
received the final report last week. I was
a little disappointed in its lack of
thoroughness. All the regional offices and
laboratories had been contacted, but as so
often happens, the right people were not
involved in the survey. It did not do
anything for my credibility feeling to
know of some fairly elaborate documenta-
tion standards which were not reflected in
the survey. It also bothered me a little
that they had talked to some program
managers, and one of the first questions in
the survey was: "Do you know of any
development work being done in your
area?" The answer was no. That is one
way to get through the survey in a hurry,
for sure. But I knew that there was
development work being done. We have
received some copies of documentation
standards. If you have any, or if you feel
C-5
-------
that something is very near and dear to
you, please get in touch with either Gene
Lowrimore or myself. In the area of Data
Element Standards, Frank Bullock is the
Contract Officer on a contract to Arthur
Young; they will be developing data
element standards for the Agency. I am
sure Frank will be glad to provide you
with a copy of the scope of work on that
contract. Gene Lowrimore and I are
working on Agency standards for pro-
gramming, documentation, and design.
We have set up targets for ourselves.
Hopefully, by early January, we will have
a draft of the documentation standards;
by February, programming standards, and
in March, design standards.
I want to hear from you. We will be
distributing these drafts for review,
comments, and suggestions. Somebody
had to do it. We are all going to have to
live with them and we are going to have
to use them. This is your chance to get
your two cents in. Certainly, they are not
going to be something that are carved in
granite and can not be modified. We will
all learn in the process. After the review,
there will be final acceptance, and they
will be incorporated as part of the EPA
ADP manual. ADP is a vital and costly
tool used in working towards the Agency's
mission. I challenge each of you to raise
your own consciousness about the
necessity and advantages of standardizing
our ADP efforts—not only your own
awareness, but the awareness of those
around you. Whether you are a branch
chief, a programmer, or a contract
officer, each one of us can do our part.
C-6
-------
DATA INTEGRATION
Gail Hu.gu.et
EPA has computerized a tremendous
amount of information in the last few
years, and is about to computerize more.
The problem with much of the work done
is their single purpose data bases. There
are air quality inventory, enforcement
files, large supply sampling, etc. They are
all single purpose. It is very difficult to
take information, for example, for a
single industry, from all of these separate
files and compare it. This is one of the
things that EPA will have to face in the
future, if they are not facing it already.
We, at the Delaware Valley Regional
Planning Commission, got a sample of
that program when we got a 208 grant.
We felt that we had to have a wide array
of information. The sampling informa-
tion, discharging data., land use data,
centers' information, population projec-
tions, we wanted to put all of this
together and use it across the board. The
problem was: how do we do it? Our
consultant, Chester Beth Engineers,
approached it from a rather interesting
point of view. They decided rather than
trying to put everything into one system
they would try to organize what was
existing; they would do this through a
geographic code and standardized identi-
fiers. Let me get some charts and show
you what the system looks like. DVRPC is
a regional planning commission with 9
counties and 353 municipalities that we
represent to states. We found we had a
tremendous task because every one of
these municipalities and states had a
different (unintelligible). We began by
trying to pull things together geographi-
cally. We developed what we call the
demand center. A demand center is like a
(unintelligible). It is about the same size,
but it is based on a watershed; it is a
hydrologic unit. This graphic explains it.
Imagine this red line as a municipality.
These blue lines are streams, the black
lines represent the demand center we
developed. What we did was say that the
municipality in our region is extremely
important; that will always be the border
of our geographic system. The streams
will be divided up into sub-watershed
areas. The red lines are the municipali-
ties, you put the streams over the top, and
then you put on the demand centers,
dividing them up into separate areas.
We started putting information to
these systems, and we found that census
information was impossible hydrologically.
We decided to use a census block, a very
small city unit, actually a city block.
Then we could develop a correspondence
table between the census block and these
demand centers, these hydrologic units
and this information could be fed in; we
are using computerized tables, and we
found that this worked much better.
DVRPC also had land use information
stored by these centers, blocks, and em-
ployment data. All of that information
was fed into the hydrologic unit.
The next problem was to get dis-
charger data into this hydrologic unit. It
had to be done by mapping the dischargers
and coding them. This, however, was not
really enough for the system. We wanted
to be able to say—for example, if we were
sampling data down in the stream some-
where and we found a toxic waste—which
dischargers could possibly contribute to
this problem. We borrowed a stream
coding system from the State of Pennsyl-
vania. (We can go to the next chart.)
This system was based on using Delaware
River in the beginning; the code for the
river would be an 01. (unintelligible)
which was 109th river from the mouth of
the Delaware was 01109; the 162nd
stream the West Branch, upstream from
this river, would have the entire number
01109162. This was a very cumbersome
system; however, we were able to trace
problems from a tributary, that we may
have found in the (unintelligible) river.
C-7
-------
We could trace them using this computer-
ized system. We could say, we have
sampling problems here, what are all the
dischargers above on a certain point on
the system? We could then trace it all
the way back. (Let me go to the next
one.)
The third part of this system had to
be a river mile index. We wanted to have
relative distance to find a stream, so we
borrowed a river mile index system from
the Delaware River Basin Commission,
and implemented throughout our entire
system. We actually measured all of the
streams, put mile ticket points on them,
and coded all of the information to river
mile points, to the stream code, and to
the demand center. Now we had an
integrated system that had a geographic
unit identifier. We were able to compare
the land use information which is stored
by demand center, to population, which
was also stored in the demand center, and
to discharge data that had a stream code
and river mile index. We could then
compare all of these different kinds of
information. Solid waste data could be
coded to the demand center, and we also
coded our demand centers to stream and
to river mile indices. We could say on any
given river, where are the solid waste
disposal sites that might contribute to the
problems we are seeing? Where is the
agricultural land that might contribute to
this problem? We had a broad range of
information coded on all three of these
systems; then it was comparable. This
chart gives a little bit of an example.
These numbers are discharger numbers.
This is a stick diagram of the stream, and
these are discharger numbers—non-muni-
cipal, industrial municipal, etc.—they
were all mapped and coded, and then put
into the system. Here is a so-called
typical watershed area and the various
demand centers. Here are discharger
points, diversions, water quality stations;
all of them are coded to the system and
could be compared. These are the various
files put into the data base system, i.e.,
industrial point sources and municipal
point sources. In some of these others, we
never put them into the systems actually.
They were coded, though, to the system.
Thus, we were able to say when we
wanted to find out about something, like a
water supply diversion, because it was
coded. In other words not all of these
pieces have to be on the same system,
because the geographic codes are the
same, you are able to compare them even
if they are not on the same system, or not
computerized at all.
The second part of this system was
to use codes that already existed.
Nothing is worse than creating your own
code, and then not having anyone else
understand it and not being able to trans-
fer data between one agency or the other.
We investigated all the codes that we
could find in the region, and there were
many of them. For example, the State of
Pennsylvania had a county and minor civil
division code and coding system. We used
that in the number that identified the
demand center. This was different from
the census code, unfortunately, so we also
put that in the file in order to do
retrievals by census codes, or by the State
of Pennsylvania codes. When we finish
with our study, we can transfer data right
to the Pennsylvania system; the codes are
the same. We also used our sub-basin
code and our stream code. When it came
to the river mile index, we used the river
mile codes of the Delaware River Basin
Commission which is also the same coding
system used by the (unintelligible). We
used (unintelligible). We tried everywhere
along the line to use something that
already existed. We tried not to create
things, and when we did, we also put other
numbers on the system. This was the case
with the MPDS permit number. We put
that on our system, in order to relate the
two. (unintelligible) number is the State
of Pennsylvania enforcement code num-
ber for each discharger. We also put that
under systems so that we could communi-
cate. Pennsylvania permit numbers, pro-
cess numbers that we use and units of
production for all of these things, we tried
to use already existing codes. We used
standard SIC codes. Again, we were not
C-8
-------
trying to create new codes. This is table you develop, the harder you make
something EPA has to start doing; i.e. to your task. It is much easier if you use the
develop the same coding system, or keep same code, or, at least, keep the same
similar codes on whatever files they use. codes on your files, even though you
For example, if you have an enforcement lengthen the file, it is very important to
code, an enforcement file for water be able to put that code in and get the
quality, some kind of code that will get information out in the format in which
you into the air quality inventory for the you need it.
same industry should be on one of those
files. There has to be some kind of
transferability; the more correspondence
C-9
-------
QUESTION AND ANSWER
Question: Do you have any of the map digitized? Do you have any graphic display
of any of these maps?
Answer: We have graphic displays of several of the maps. The river mile index
and stream code work were done on maps; the demand centers were all
mapped. We do not have it digitized, per se; however, the census data is
digitized using a geographic base file. We have some of the units
digitized at various levels. It will take a data transfer to make the
system work.
C-10
-------
STANDARD TERMINAL CONTRACT
Jim Flatten
Any standards you develop have to
be written to meet the job that can be
done.
I would like to get into a brief
history of why we came up with the
standard terminal contract. We must
provide a standard interface for our tele-
communications network. As most of you
know, we have the UNIVAC computer at
RTF. We have the IBM 37160 at
COMNET. Both could interface different
terminal standards; however, those of you
who have requirements to go to both can
use just one terminal. It allows us to have
a single telecommunications network, re-
ducing cost and providing better and more
efficient service to everyone. By stan-
dardization we are trying to make the
equipment reliable and cost effecitve,
while providing a vendor offering you
rapid service and maintenance repair for
your equipment in order to prevent down-
time and interference with your opera-
tions. By having standard terminal con-
tract, we were able to have one interface
with each vendor. For problems, such as
non-responsiveness of maintenance or
non-responsiveness for delivery, it made it
much easier to work with the supplier. I
do not know how many of you have been
with this Agency since its inception. We
went through many horror stories of the
DATEL/HARRIS Communications ter-
minal days. When Harris Communications
walked in one day, they walked out with
every terminal because there had been a
long period of non-payment; the users had
failed to renew their lease agreements at
the end of the fiscal year. Some of the
renewals were not done for several years.
Now the Harris Communications terminals
have been out of the Agency for
approximately three years. Just last
week, we were still trying to resolve one
of the old invoices. This has been time
consuming and has created many pro-
blems; it has created an enormous expense
to the Agency. There was hope that the
new standard terminal contract would
avoid this. Anyone using Anderson/Jacob-
son terminals knows that we did not solve
that problem completely.
In the past, if you required a termi-
nal for your use, each of you would have
to go out and evaluate the available
vendors, research what was available in
the market, find out the vendor's
responsiveness, and his ability to meet
your need. There was duplication of
effort, that the standard terminal con-
tract eliminated. The present standard
terminal contract is not the answer to all
problems. I would, however, like to
review some of the problems that we were
having. We have gone back and talked to
our present standard terminal contractors,
and they have indicated that the volume
of our procurement has been so minimal
that they would not be interested in
having it continue after the present
contract period. We are still having the
lease payment problem with some
vendors. I have on my desk right now,
after a year and a half of resolving 500
and some odd invoices that were mis-
billed or mis-invoiced, 150 still
unresolved. This has created thousands of
hours of wasted effort on the part of EPA
employees trying to resolve whether the
invoices were valid, against which
purchase order they were supposed to be
billed, and arranging for payment. The
vendor has outstanding against EPA, at
the last count, over $200,000 worth of
invoices that are still unresolved or un-
paid. They are getting quite perturbed
with a situation, mostly of their own
creation. Some of the invoices that we
had from this particular vendor, were
invoiced against purchase orders that ex-
pired at the end of FY 1974. They have
'never updated their records to reflect new
purchase orders.
C-ll
-------
Another problem is beginning to
appear in price discrepancies between
GSA schedules and our standard terminal
contracts. Now there are reasons for this.
We require 30-day delivery for interactive
terminals under EPA contracts. GSA
contract requirements are about double
what our requirements are. When we have
30 days, they have 60. When we have 60
days, they have 120. We have to weigh
that against the fact that the Texas
Instruments terminals, under the GSA
contract, model 7^5's and 743's are practi-
cally $400 each less to purchase than they
are under our contract. The same holds
true for the (unintelligible) terminal. The
standards and criteria we have as
additional items in our specifications, are
being evaluated in relation to the increase
in price we pay for a terminal to deter-
mine if it is cost effective. To justify a
new standard terminal contract, after the
present one expires, we would have to
have a larger volume of new terminals to
be purchased, or leased than past usage
has indicated. On July 17 of this year, we
sent a memo out to all known EPA ADP
users asking, what equipment they
presently had? How long they intended to
keep it? What their intent was for
additional equipment in the next three
years? They said that everything they had
is fine, they work great, they do not need
anything additionally. One person would
like a standard terminal contract to buy
one item, another person wanted tractor
forms, on the Class IA, of which we have
about six in the whole agency. It began to
appear that we could not justify the man
hours, time, and effort to develop a
standard terminal contract for the period
1978-1981 to meet a limited requirement
for additional equipment. Maintenance
and service on presently owned equipment
would be available under the GSA con-
tract at an almost identical price.
Another problem is adding new
equipment. As most of you know, Texas
Instruments has come out with a new
portable terminal, model 765, which is a
bubble memory machine, that can be used
off-line, has limited text editing
capabilities. You can search a file, create
a file in memory, edit it, change it,
replace it, segment it, and you can turn
the machine off without losing data. You
can turn it on later and start from where
you stopped. You can go "on-line" at any
time and transmit the data directly from
memory. This machine costs about $2900
for a machine with a 20K bubble memory.
In talks with Texas Instruments, they
stated they would not place this machine
on our standard terminal contract. Their
reasoning was that the volume was too
low and they could not meet our delivery
schedule. I do not know if anybody has a
requirement for that type of terminal, but
that is one of the problems which we have
experienced. How we can get the latest
equipment meeting our basic standards
specifications under our standard terminal
contract has been a problem. We have
reviewed our available options, and I
would like to give you our thinking and the
way we plan to go in the furture.
We want to eliminate the problem of
carry-over leasing from one year to the
next; we would like to suggest that all
leased terminals be purchased. The
break-even point on all terminals—I am
speaking now of only low speed
interactive terminals—is between 18 and
21 months. If you are going to keep a
terminal over 18 months, it becomes
economically feasible to buy it. In the
past, people have desired to lease; as they
feel the vendor will provide better service
since it is his machine. This has not been
our experience over the past several
years. Most reliable vendors with
equipment meeting our specifications and
standards, provide equal service for leased
and owned equipment. Purchasing hard-
ware would eliminate one of the major
problems we have had, that of users not
renewing leases at the end of each fiscal
year. Terminal maintenance agreement
renewals at the end of the year is not a
serious problem. Even if a maintenance
agreement is not in being maintenance
can be obtained fairly quickly under a
one-time purchase order. This would
alleviate the problem of trying to resolve
C-12
-------
bills going back three to four years. We
suggest that any equipment that can be
justified for lease, be leased with a
termination date specified. The terminal
will be taken out at that time. If
requirements develop late for longer use,
you should exercise purchase option
credits and buy it. We have spoken with
our procurement people about obtaining
terminals under the GSA schedule con-
tracts. It is not a great deviation from
what we have done now. Develop your
specifications, one or two paragraphs will
usually suffice, a short evaluation of three
or four alternatives (if any) and reason for
selection along with a purchase request
will then be forwarded to procurement.
We hope to issue specifications for you to
obtain terminals. It will in most cases be
a small purchase under a GSA contract. It
is a very simple procurement procedure.
One item we have not enjoyed under our
EPA schedule is the Government-wide
discounts being offered by vendors under
the GSA standard terminal requirements
contracts.
My remarks, to this point, have only
been for the low speed interactive
terminals, not for our present Data 100
terminals or the mini computers. These
are high cost items. They do not have the
short pay out time for lease versus
purchase considerations and they require
more detailed specifications and procure-
ment analysis. We are hoping to upgrade
our specifications to include more
capabilities if you need them. If anybody
has any additional requirements they feel
might be beneficial in the Data 100 RJE
area, I would appreciate receiving them.
We will continue to look at the standards,
requiring that any terminals procured
meet our specifications and standards.
C-13
-------
WORD PROCESSING STANDARDS
Cathie Tittle
I imagine that some of you may be
wondering why I am here today talking
about word procesinig when we have just
split the responsibilities for word pro-
cessing and data processing and placed the
responsibility in the Management and Or-
ganization Division. We did that, I think,
for some very good reasons, I would like
to explain those to you this morning, give
you a little bit of an idea what we have
been doing in Headquarters as far as word
processing is concerned, what we plan to
do to assist regions in the laboratories and
how we look at standardization of word
processing equipment.
There is a Federal Property Manage-
ment Regulation, put out by the National
Archives Record Service, which requires
every agency to establish a focal point for
word processing. That responsibility is
not only a Headquarter's responsibility,
but is also a responsibility for the Regions
and laboratories. As an Agency, we
recently have been studied by National
Archives and Records and we also are
currently undergoing a GAO audit on word
processing. The focus of these surveys is
what are you doing with word processing?
Are you controlling your equipment?
What kind of equipment do you have? Is it
cost effective? Do you have any idea why
you have it and what you are using it for?
When we established the focal point
within Management and Organization, we
determined that it was best to start our
surveys with Headquarters, get an idea of
what kind of equipment we had and what
it was being used for, and make recom-
mendations for the programs on how they
could improve their use of the equipment
to make their operations more cost
effective on these lines.
We found that we were spending
about $2 million a year on the rental of
word processing equipment in Head-
quarters, that we owned an additional half
million dollars worth of word processing
equipment, and that we were spending
anywhere from $600,000 to $800,000 a
year on Bowne. That is an awful lot of
money, especially when we had no idea
what it was being used for.
We initiated a contractor-assisted
study in Headquarters and went out, not
to change our organizational structures,
but to look at equipment and make equip-
ment recommendations. We have just
completed that study now, and are just
about to go out into the Regions. We have
found that by making simple recommenda-
tions—eliminating some equipment,
changing some equipment, reassigning
equipment—we have been able to recom-
mend configurations that will save Head-
quarters about $250,000 a year in rental,
and an additional $200,000 to $300,000 in
Bowne charges. We are trying to bring
things under some sort of control. We are
proposing, through an over-target request,
to take our contractors out on the road to
8 of the 10 regions initially and to
Cincinnati and to RTP, to provide the
same sort of study that we have done at
Headquarters. The idea is to develop
base-line data on what equipment the
Regions and labs have and its uses. From
there, program managers can look at the
equipment they have, reassign it, and
develop systems while slowing escalation
of expenditures in word processing.
If you are trying to define what we
consider to be word processing, many of
you will think of Bowne Time-Sharing, the
contract for computerized word
processing which MIDSD was responsible
for. When the agency was founded that
was almost the only alternative available
to people to do large document text
editing. In that case, large documents
were 10-page reports. IBM had some
equipment, the MAG CARD equipment,
with which many of you are familiar,
which had very limited capability. So our
C-14
-------
use of Bowne Time Sharing as an Agency
snowballed and grew to the extent that
last year, we spent over $700,000 with
very little control over what the applica-
tions really were.
We are no longer defining word
processing as computerized word
processing through a time shared system.
We feel that there are many, many alter-
natives to that approach, that are more
cost effective. Stand-alone word
processing devices and mini-computer sys-
tems are coming out on the market almost
on a daily basis. They have capabilities
parallel to what has been available
through time shared word processing in
the past, but at a much lower cost. The
cost is lower not only on a month-to-
month rental basis, but also from the
standpoint that what you are getting is a
fixed price resource, unlike a time shared
system with no control. With Bowne it
was very hard to determine for future
months what your costs could be. With no
supervision of the uses of that system, a
secretary could spend $700, $800, $900 or
thousands of dollars, doing fairly simple
word processing applications. What we
have done in our recommendations in
Headquarters is to show people where
they have off-line alternatives. In doing
that we, as I said before, are predicting
about $250,000 savings.
The Agency contract for time
shared word processing is currently being
completed. The Management Organiza-
tion Division will be the project officer
for that contract once it has been
awarded. The funds used to pay for that
system will no longer come from the ADP
funds as they have in the past. They will
now come from program funds. I would
like to relate this to our concept of
standardization and control of word pro-
cessing. The reason we did this is that we
felt that it was time that managers in the
Agency began to be aware of what word
processing was and be responsible for the
decisions relative to the acquisition of
word processing systems and word pro-
cessing equipment. Bowne was almost a
free resource to a number of people. If
you had extra ADP funds, why not use
them? On the other hand, people who had
a requirement to do large document text
editing, to do photocomposition or to do
some of the applications that are only
available on a time shared word
processing system, could not do them
because there were not enough ADP
funds. They could not or would not
reprogram funds from somewhere else
into ADP to be able to use that system.
We wanted to make the situation a
little more equitable. We wanted to say
to people, word processing is everywhere
from the typewriter all the way to com-
puterized word processing. Consider all
of your alternatives when you are looking
for a word processing system. Do not
segment, putting ADP word processing
over here, in a totally different box. We
will be requiring some of the larger users
of computerized word processing to
conduct feasibility studies in FY '79. We
believe that the alternative to time
shared word processing for some of the
large users are mini-computers (shared
logic) which can be more cost effective.
Region IV is a good example of this. We
do not have the resources to support
sophisticated shared logic system within
some of our Headquarters programs. We
do not have the set-up that you have in
the Regions where you already have an
ADP ship operating a mini-computer for
other reasons. You can bring in a mini-
computer for word processing and begin to
support that for the users as well. To
take an Effluent Guideline Division in
Headquarters and ask them to staff up to
support a word processing mini will take a
lot more time and consideration than
perhaps it would be to bring one in to a
Region or a laboratory that currently has
a POP 11/70.
We have developed, and are about to
circulate for comment, an order that will
control word processing both in Head-
quarters and in the Regions and labora-
tories. It assigns the responsibility to you
for approval of requests for equipment; in
C-15
-------
Headquarters to the Management Organi-
zation Division; in the Regions to the
Management Division Director; in the
laboratories, to the Administrative
Officers; and in the case of Cincinnati and
RTF, to the Office of Administration.
The main reason that we are doing this is
that we are required to do it by the
FPMR; secondly, we feel that Agency
program managers should not be required
to have to take the time to muddle
through the 30 to W odd word processing
vendors out there, and try to become
experts. They should not have to have
that burden along with all the other
burdens they have. Somewhere in the
agency, within the regions and the labora-
tories, there ought to be a resident
expert, who can provide that guidance and
assistance and who can say—for this appli-
cation you should be looking at this type
of equipment. The order, first of all, will
assign the responsibility, not so that we
can be ogres and say "No" to people, but
so that people will know that there is a
central point to which they can come for
guidance and assistance. If people are
really moving in the wrong direction, we
can steer them back on the right course.
The second thing that we will be doing is
providing a technical manual to give
guidance to the programs for making the
initial decisions such as where they want
to go with word processing equipment.
There are industry standards that say if
you are doing certain types of applica-
tions, you should be looking at certain
types of equipment. CRT equipment can
. produce a certain number of lines a day
and is geared to do large document text
editing. IBM Mag Card equipment, or
other mag card type of equipment, is
geared more for correspondence. We will
be providing that kind of information to
the offices, so that, by the time the
request comes into the reviewing office,
this information will have been applied
and we will expect the request to be right
in line with what they should be.
We will be requiring, in Head-
quarters, feasibility studies on a periodic
basis, for any office that wants to
significantly change their equipment. We
are not planning to standardize word
processing equipment within the Agency.
We are not moving along the lines of a
standard procurement for equipment. We
are finding that the cycle of changes--
significant changes to word processing
equipment—seems to be a two-year cycle.
About every two years for the last six or
eight years there has been a fairly signifi-
cant new announcement or development
within word processing. First, there were
card machines and then came machines
with memory. Next came CRT's applied
to word processing, but hard-wired. Now
it is software-based CRTs. These things
change rapidly enough that we feel as new
vendors come on the market with very
good new improvements to their equip-
ment, standardization, would prevent us
from keeping up with it.
We are also not recommending pur-
chases. Right now at Headquarters, we
have a moratorium on purchase of word
processing equipment. The reason we are
doing this—we do not intend for it to go
on forever—is that while the prices are
starting to drop, they have not dropped as
drastically as they have for data process-
ing terminals. We are still seeing $15,000
and $20,000 CRT word processors. The
payoff for those is 36 months, at best; in
many cases, it is more than that. With a
two-year cycle of major technological
changes in word processing equipment, it
does not make sense to buy something
that you have to keep for three or more
years before you can pay it off. We will
also have a moratorium on the purchase of
equipment that has been around the
agency for awhile. IBM is pushing very
hard to get us to buy all the equipment
that we have had for the last three to five
years. This gets to the point of the 1981
situation and equipment standardization.
The communications capability protocol
on the IBM equipment will not be com-
patible with all the potential computer
systems with which we may end up with.
Communicating Mag Cards now are 15
CPS or 14.8 correspondence. They can
only be used to go into the Bowne system.
C-16
-------
I guess they can go into COMNET, but,
from what I understand, that may very
well may be ended soon. There is new
technology available for the same price,
but that can do an awful lot more. Thus,
we are not recommending purchases of
anything on which you have rental credits
at this point. We are not recommending,
for the time being, that you purchase any
new equipment. We have started to see
the $10,000 CRT, just the last couple of
months. Perhaps, within the next 9
months to 12 months, those prices will
come down a little farther; then , it may
become cost effective to purchase this
equipment.
I think the thing which we should be
aware of is that by putting word process-
ing responsibility in Management Divisions
in the Regions, and in Headquarters in
Management Organization, we are not
saying that we now think that it is totally
separate from ADP. I think we would be
fooling ourselves if we tried to totally
separate the data being processed on our
computer systems from that prepared on
word processing equipment. I firmly
believe that we as an Agency have many
applications (ADP and word processing)
that use the same data and that we waste
significant resources duplicating that
data.
It is important that you become
aware and stay on top of it as much as you
possibly can, to integrate those two sys-
tems and to eliminate the duplication of
effort. The technology in word processing
is moving rather rapidly toward data
processing. It is moving away from the
Mag Card, and getting closer and closer to
the word processing mini-computer. Any-
one who wants to volunteer to help us to
look into where we should be going with
word processing minis is welcome. I am
not a data processing person, myself; I am
much more geared toward typewriters and
typists, so I can use your assistance.
The last thing I would like to say is
that I am a staff of one at Headquarters.
I will be, as we go out to the regions and
laboratories, asking each of the organiza-
tions to assign someone to responsibility
of word processing, much like the current
ADP coordinators, so that we can develop
a network for keeping communications
going between headquarters and the field.
As I have time, and my time will be
limited, I will be more than happy to
provide guidance and assistance to any of
you. We are going to be developing
training programs to give you the back-
ground you need to be able to deal with
word processing in your organization. Do
not hesitate to call on me.
C-17
-------
SUMMARY REMARKS
Ted Standish
I have a few closing comments I
would like to make, concerning the
coordination effort going on with people
within the Agency. As far as current
efforts are concerned, this Conference is
obviously an example of our effort to
bring data processing under some kind of
coordinated control within the Agency.
We have also seen such things as the
STORE! and AEROS conferences. The
meeting tonight of the Regional ADP
Branch Chiefs is another example. One
example, or interesting example of this
Conference and the issues in this it
addresses came from the zero-based
budgeting process we went through last
year and this year. We also have commit-
tees now on regional mini-computers and
on the laboratory automation projects. I
think however, that there are also needs
for expanded efforts. I believe that we
have to look at the detailed resource
impact and trade-offs of those systems. I
think in a lot of cases, we are overlooking
what it takes to bring a system up, and
what it takes to maintain that system
over time. We are also asking, at least
within our region, that all systems must
be approved by the Regional Administra-
tor; division level approval or below is not
acceptable for the acceptance of the new
system. We are also going to see, or need
to see, greater inter-program coordina-
tion. Again, I bring up the Effluent Data
System discussion of yesterday, where we
have, the Office of Enforcement, Water
and Hazardous Materials, Toxic Sub-
stances, and Research and Development
involved. Then, you throw in the 10
regions on top of that, and you have a
fairly complicated mess with which to
deal. We are also going to need to see
greater intersystem coordination, or if
you wish, intermedia coordination. For
example, on the media side, we need to
see coordination, say between grants and
water enforcement. We are going to need
to see coordination for air and water, for
example. I think some of us probably have
examples of water people saying, "It is
okay so long as you do not dump it into
the water," and the air people saying, "It
is okay so long as you do not dump it into
the air." Of course, if you put the two of
those people in the same room at the
same time, they end up in a fist fight.
Each one is just incredulous that the other
would have the gall to say something like
that.
One other thing I would suggest we
look at as an Agency is to review the
success of the Model State Information
System experience. Has the use of
structured programming really made it
easier for us to install that system in the
umpteen thousand states that we have to
install it, and is it, in fact, easier for us to
maintain and modify that software as we
use it? As far as the issues arising from
this panel, I guess there are several that I
see coming. The first is that we are faced
with the imminent issuance of software
design, programming and documentation
standards. In January, we will be faced
with the documentation proposal; in
February, the program proposal; and in
March, the design proposal. Now we have
to read those, review them, and send
comments back to MIDSD on them. We
are going to see the continuation of the
hardware specification and the continua-
tion of the standard Agency contract for
the remote job entry terminals and for the
mini computers. We should be looking at
the purchase of low speed terminals to get
them off the leases, and secondly, we
should be submitting to MIDSD, any R3E
or mini-computer needs not currently in
the list of requirements. Cathy brought
up the issuance, in the near future, of the
word processing order and the guidelines
for the use of word processing equipment.
We are also faced with the contract for
the standardization of data elements.
This is the first that I have learned of it
and I would certainly be interested in
seeing what the contract has to say. The
C-18
-------
last thing that we will be doing in Region
III is that, because of the experience that
we had with the Philadelphia 208 efforts
in trying to coordinate the data within
that area, we are going to perform a
feasibility study in the beginning of
calendar year 1978 to put that data base
system itself up on the Washington Com-
puter Center, which would then make it
available for use by any 208 region that
wishes to use it. Our intention is to put
the data up that already exists for the
Philadelphia area so that we can examine
within the reigon how useful it is to EPA
itself, assuming that we find that it is a
viable means of tying together our
programs. We would then start looking at
the expansion of the system to include
other areas within the region on a priority
basis.
C-19
-------
QUESTIONS AND ANSWERS
Question:
Answer:
Question:
Answer:
I am Curt Lackey. I have already gotten my answers, but I will repeat
the question for everybody else. My question is directed to Gail. What is
the status of the system? What computers does it own? Is it
documented, and can you get me copies of the documentation?
Yes. The system has been up and running for about two years. It is on a
National CSS Time Sharing System which uses IBM equipment. They
have a special language, that is a report writer and data base storage
system. It is called NOMAD. But that is not crucial to the system; in
fact, we are going to take it off that system and put it on ours, using it
in a different system. It should not give us any problem. Yes, we can
send you some generalized documentation. I also wanted to say that this
is a fairly inexpensive way of organizing our information. We spent
about five months doing the mapping, the coding and entering the data
into the system and the design. The consultant spent about $20,000 and
DVRPC spent about another $20,000. This was for a 208 grant program.
I think it was a fairly inexpensive way of organizing the data. This does
not include data gathering, just setting up the system.
I have two questions that are related. They are related because of the
need to look at data across media lines. The first question concerns the
need to establish data element standards. A reference was made earlier
this morning to the contract of Arthur Young, but, as I understand that
contract and the statement of work, it is not going to do what is needed
in the Agency. What I think is needed here, is that we need to have an
Agency-wide definition or standard definitions of data elements. We
need to have standard attributes for all these data elements, and we need
to have standardized values or accepted values for each of the data
items that have some kind of unique coding structure or accepted coded
values. There are so many different systems in this Agency. What each
programmer in each office defines as his own data elements, even if they
were software compatible, you could not transfer the data from one
system to another very easily because of the attributes and the data
element definition. The other question, or the other thing, pertains to an
issue that has already caused some problems within the Agency that are
worse than just the data element standards. It is going to be severe in
the years to come unless we do something immediately about it, and that
is the facility I.D. number. We have a NEDS facility I.D. number and, we
have an NPDES facility I.D. number. We have a municipal facility I.D.
number, and we are going to have a water supply I.D. number. We are
going to have a toxic I.D. number, and we will not know how to relate
information from each of these data systems, because there will not be a
key record that will translate this.
Mr. Burning from the Office of Enforcement is quite concerned about
looking at compliance status and the enforcement history across media
lines. He is not interested in going to a water file and looking at water
facilities. He wants to know in the steel industry for instance, what is
the compliance status in the air, toxics and the water areas. Right now,
we can not get to that at all. The biggest problem is the fact that we do
C-20
-------
Answer:
Question:
not have a common facility I.D. number within this Agency. / am
wondering if a recommendation can come out of this particular panel
from this Conference about establishing a task force to work on that to
begin this calendar year.
Gail and I talked about that problem at lunch on Monday. One of the
proposals we might use so that we do not have to develop our own new
numbering system is to take the Dun & Bradstreet numbers which have
I.D. numbers for every industrial facility in the country, or try to find
some other source similar to that and use them as the common identifier.
I will include it in my summary remarks tomorrow as one of the action
items that should come out of this panel. It is definitely something that
is needed, because it will become more and more difficult to tie the data
together without common identifiers. As Gail pointed out, the number of
cross-referencing tables is growing astronomically and is causing us
considerable problems.
I am Bill Serovy from Region I. We thought about trying to use the Duns
number as a universal facility I.D. a couple of years ago. Then the Duns
file went away. We were told that we better not use the Duns number
because that was part of the Duns file for which we had stopped paying.
We were told that we would be in big trouble if we used it and that it
might mean having to buy back the rights to the Duns file. I think it
would be a good idea anyway, but I am just pointing that situation out as
a possible problem.
I have three questions or concerns about the standardization of
programming and documentation. The first thing is that I do not think
that standards necessarily replace skills. Good programmers tend to
write good programs; bad programmers tend to write bad programs,
regardless of standards or anything else that you try to impose from the
top. As Maureen said, a good programmer or any programmer for that
matter, assumes that he or she will be around for some time and can
always maintain the program. Maureen says that sometimes that means
that they write sloppy programs because they figure they will be there to
patch it up. On the other hand, some of us figure that we may be around
to pay for our sins, and if we write bad programs, it will come right back
in another year. Somebody will want a thing modified, and I probably
will not remember what I did a year ago, so I had better do it right the
first time. A good programmer will look at the long term and will look
at the problem from the top down. A bad programmer will not.
The second issue here is the threshold at which these standards will be
applied. There are a lot of quick and dirty programs being written in the
Agency, and chances are that there will continue to be. At some point it
becomes counter productive to try to apply documentation standards to a
program that will be used one or two times. It ends up taking you more
time to write up comprehensive documentation than it would to write the
program, to run it, and to throw it in the trash barrel. We have to be
careful in applying this threshold; otherwise, everyone will try to sneak
in under it and say I want to use this program once, and then continue to
use it a thousand times over the next five years. It will be a
management problem to decide where these standards apply and where
they do not.
C-21
-------
Answer:
Answer:
The third thing is that, to some extent, the quick and dirty programming
problem is a result of quick and dirty management. That is something
that we cannot directly address in the ADP, but some users, some
program managers, will refuse to define their requirements for you or to
write them down on paper. How do we assist them in doing that? Or do
we compel them to do it?
/ will say something about alteration. This may be a cop out, but I
believe that standards will make the good programmer, a better
programmer. It will also make the poor programmer, a better
programmer. It was interesting to me, in the hallway just outside, that
several people came up to me who either are in programming, or have
been in programming. They stated that, at one point, they were in a
situation where standards were being applied. They are not now in a
situation where standards are applied. There are no standards whatever,
and it is very uncomfortable for them. We sometimes generalize that
programmers resist standards and documentation. It is a fair generaliza-
tion, but it is well to remember that once you have either enforced or
self-enforced standards and documentation requirements, you can either
do it within yourself if no one else is beating on you, or if it comes from
the top down, which it should, if you are ever removed from that
situation, it becomes very uncomfortable because you see the chaos. As
far as top-down management is concerned, perhaps we can make some
progress if a threshold is established. For certain systems, given certain
size requirements, there are documentation requirements and require-
ments for design.
As far as that last comment on the problem of management, I think all of
us face that issue, and we have all had to try and deal with the various
problems that management is having and to find what it is that they
need. There are any number of reasons why they cannot define
requirements. In one case, they may not know what Headquarters is
doing, or where Headquarters is going, and, for that matter, Head-
quarters may not know where it is going. Another problem has been that
the managers may not understand data processing at all, so that they
really do not know how they should define what it is that they want. The
third case is that their needs are changing rapidly over time. What we
have tried to do in the region is to take a firmer and firmer stand where
necessary, and not to start the development of the system until we have
gotten concurrence and written requirements from the division directors.
It is painful to go through that; you will get some arrows and a few other
things thrown at you, while you are trying to do so, but I think, in the
long run, it tends to pay off. As the divisions become accustomed to the
idea that they need to specify their needs, then they begin to think more
about what they are doing. They begin to do a better job of writing down
their requirements. The other technique that we have started to use in
the region, which is probably going to endear us to Headquarters no end,
is to send down our proposals to Headquarters for their concurrence on
our writing the software. For example, we are working on the
automation of the violation summary required by the Enforcement
Management System. We are not going to proceed with developing or
finalizing that until we have gotten OE to sign that that is the format
%%yn Wffl1' f Now+ L£ IWy* %e tour years from now that we have an
acceptable format, but that is the way we are heading now.
C-22
-------
Question:
Answer:
Answer:
Question:
Answer:
Question:
Question:
I am Carl Worster from Region VIII. I would like to ask Maureen what
languages do you see being standardized in the future? The bottom line
concern we have in Region VIII is where does PL1 stand relative to the
1981 effort? After you respond to that, I would like anyone who is
knowledgeable to respond to this question: Would someone please
elaborate on the Arthur Young contract on data elements and data
standardization? Thank you.
The languages we will initially address will be COBOL and FORTRAN,
and the PL1 question comes up. I am not sure on the current status on it.
Gene can correct me if fm wrong. I think that this will eventually
become one of the three standard languages in EPA. When it does, the
standards will go along with that. Gene and I have kicked around among
ourselves, APL and BASIC. We have not arrived at an answer to it as
yet; we would be interested in hearing your input, particularly from the
reigonal offices with the minis. I think the basic question there is much
more vital.
The Arthur Young contract is just in the Statement of Work phase, and is
just being drafted, or re-drafted, in its final form. The intent is only to
look at files from the various systems—the key system and the larger
systems—to see if there are any elements within these files that would
be candidates for standardization. Then, get a list of these candidates
for standardization, and suggest that these could be standardized. At the
same time, also suggest some means, whereby a committee could handle
standardization of data elements. All that this contract would do at the
present time is to point out where there are areas that could be
standardized.
Could you refer to some specifics, what files or systems are you looking
at?
We are looking mostly at STORET, GICS, and PCS.
know yet. We also have to define these systems.
We really do not
Just as a follow-up to my intent in asking for this information, I came to
the U.S. Environmental Protection Agency from the U.S. Bureau of Land
Management. BLM has a computerized system, used not only in design
but in programming documentation and in system documentation. It can
also be used as a means for standardization for data elements both in
systems and across systems. If this could actually become a nucleus of a
data element dictionary concept, I would like to describe briefly the
system. It utilizes the concept of defining a data element—describing
what it means, and how it is used, and how it ties to virtually every
computer system using that data element. It creates a cross reference.
It provides automated documentation for each master file in which that
data element is used. I would offer this for consideration to anyone who
would be in the position of having a need to do this.
I am Curt Lackey from Region IV. Everybody is talking about data
elements, systems, and so forth. There is another area that I hope
somebody looks at and that is using instruction techniques, or some kind
C-23
-------
of technique in writing and also documenting models. Just last week,
somebody in my staff spent 10 hours finding the data problem that should
have been caught by some kind of edit or something. When we start
looking at documentation and techniques, let us include the models all
over the Agency.
Question: I am Linda Tucker, Data Branch Chief of the Mobile Source Program in
Ann Arbor. I am interested, Maureen, in any Agency-level work that
may be underway regarding data security standards. We have had a
particular problem recently in Ann Arbor. Because we are a compliance
program, we have proprietary information from the automobile manu-
facturers in their dire concern about our information protection. In
attending to all those concerned, we recently undertook an evaluation of
our data security practices. In order to do that and to come up with an
acceptable measure by which we could be evaluated from an audit
standpoint, we had a great deal of difficulty using the ADP Manual or the
Security Manual to deal with specific ADP-related questions. Conse-
quently, I had the contractor actually prepare data security standards,
particular to our program and particular to the level of sensitivity of the
information that we handle. I would be very interested in making that
available to anyone who would be interested in that type of approach or
in participating in Agency-level discussions regarding the data security
issue. Is there such an effort underway?
Answer: I cannot comment on the status of that, bat I am sure that we will
welcome your input.
Question: Over the day and a half of this Conference, there have been a number of
comments made regarding concerns about redundant efforts in terms of
software development between the region and Headquarter's activities.
We have also recently looked into the software availability and exchange
question, initiated by the auto manufacturers interest in getting the rules
of the game by which we evaluate their compliance. In doing that, we
are coming up with two already-established, formal means by which
software can be exchanged, and a couple of informal possibilities. We
are also finding that dealing with the baisc question of software
availability, that the Freedom of Information Act does not cover
software. Both GSA and DOD have taken positions that software is
considered an exploitable resource property, having a tangible value and
therefore not publicly available through the Freedom of Information Act
channels. I have raised this with MIDSD. I think that MIDSD will be
taking an official Agency policy on this, but there is still the question of:
if we get such a request, if there is an interest region to region, or region
to Headquarters for an exchange or even for basic information what
might be available government-wide? There is a recently established,
infant program called the Federal Software Exchange Program, which is
mandatory in GSA terminology. Yet, it is undefined or unclear in terms
of the interpretation of what it is to cover, even if they came out with
guidelines requesting Agencies and government entities to submit
"common use" programs fully documented. The Program, itself, actually
calls for the submission of abstracts, rather than full complete packages.
They have a catalogue service for which there is a charge of less than
C-24
-------
$100. If a request is received, it is referred back to the submitter. The
submitter is actually asked, at that point, to produce the software
package complete with documentation. The implication of the FSEP
program is that documentaiton is available or that there is some plan
conscious and timely by which that documentation is to be prepared.
There is also a slight cost for participating in the program. The
alternative to the Federal Software Exchange Program is the National
Technical Information Service (NTIS) mechanism. Some of you have
probably already used that activity. NTIS is voluntary. It is more
expensive than FSEP. You do turn over a complete package and they
attempt to recover some of their reproduction cost in making that
package available. It does have a broader distribution potential, outside
of the government sector, with industry or private corporation. At this
point, the Mobile Source Program has not taken an official stand on this.
We are still debating the policy issues. We do have some research and
some information. If there is interest, I can also make that available.
Question: I would like to make a comment on the software information exchange.
We have seen a couple of the catalogues. There have been two
published. I question how they put a price tag on the software. Some of
the things that, at least according to the abstract, seem to be a very
small item, have $1,800 to $2,000 price tags on them. This does not
quite seem to be fulfilling the mission or the goal intended if it is going
to be such a cost incumbent system.
Answer: If I could react to that, I would raise the question with the GSA
coordinator in charge of that program. The answer that I received was
that the cost is determined according to an algorithm that considers such
things as processing time, lines of code, etc. It is not in direct
proportion to the development effort.
Question: I am John Green, from Narragansett, Rhode Island, at the laboratory.
There are a couple of things I would like to say with respect to
standardization. One of them is that one of the panel members talked
about the different data bases that exist in the EPA. Then there was a
session yesterday on Distributive Processing. I think the situaiton that
exists is that we already have distributive data bases within EPA. In
fact, they are all over the place. What would be a good idea is to try and
integrate the data bases, and the only way that I can really see making it
work would be implementing a real computer network. Now one problem
with computer networks is that computer networks mean something
different to different people. What I mean by computer network is
something like the (unintelligible) that is a real network. We are not just
telephone wires strung across the country from one computer to another
computer, or teletypes hanging off a remote site. In regard to the other
things that the panel members were bringing out, If we had a computer
network, I would sit down at my terminal and I would say what is the
latest thing on documentation of software standards. I would be able to
put that in and get the latest report from Maureen on what the current
status of that thing is, because she is entering that in our computer
terminal. I would be able to say I could have ready access to that. The
same thing goes for word processing. I would like to thank Cathy Tittle
C-25
-------
for her efforts in keeping abreast of what is going on in word processing.
We just ordered a word processing system for rental, at Narragansett. I
started looking at that business and saw about 30 to 50 manufacturers. I
knew a few companies. I knew IBM. What they had is real expensive; it
was really lousy. But a phone call to Cathy from our lab, and she looked
at what we were going to be doing. She gave about four manufacturers,
and we went out and scoped them out. I think we made a good selection
based on the information we had, because she has been keeping abreast
of that. She is worth your while, if she does nothing besides that, as a
clearinghouse. Another thing regarding program documentation. There
, is something that I try to enforce, in the program development at
Narragansett. One thing that I thought about, half tongue in cheek, is
writing a spec for a compiler that said it would not compile unless there
is about 10 lines of documentation in the front of it, and at least 20
percent of our code is source documentation. That is the kind of thing
that might be a simple kind of standard to implement. With regard to
the language, my feelings on that is that I believe that the new
FORTRAN standards, when they come out, will have character (unintel-
ligible) in their places, and some control structured in it. I hope that the
Agency adopts that standard very quickly. With regards to PL1, APL,
and BASIC, I view those as minor languages. I think that it would be too
helter skelter to try to coordinate any kind of documentation on it. I just
want to say one more thing. With regard to the standard terminal
contract, I also had occasion to stumble across that document while
looking for our word processing equipment. It seems to me that for
relatively low cost items, like word processing or data terminals, that
the business changes too fast to get out any kind of up-to-date
documentation. I would think that a clearinghouse like what Cathy does,
for standard terminals is in order. I can call her up and say, "Hey, I saw
this bubble memory, (unintelligible) flashy graphics terminal, can I talk
to an Agency computer with this?" There would be somebody there that
would say, "Yes, we know about that. We have tried to document it." He
could have something on this network into which I could key it in, I can
ask information on this, because he is entering that into his own disk file
and I have access to it. That is the kind of thing to which I would like to
see the Agency go. I would like to see it go to a real network, and try to
develop software interfaces to the different data bases. In other words,
the data bases all exist; they will all have their own entry, language, and
verfication procedures. They will have their own inquiry procedures.
What I would like to see with regard to the Agency is come up with a
standard inquiry language for people who want to gain access to this, for
graphics information for example.
Question: I am Sherman B. Arthur from Region IX, San Francisco. I have a
comment with regard to programming standardization. I would think
that standardization of programming should be applicable regardless of
languages that are used. I would think that the application of
standardization to the few languages that Maureen mentioned would
restrict the value of this standardization too much, because in EPA, we
use many different languages. For instance, we use PL1 and IRS. Then,
in Region IX, we do a great deal of computer programming on the Data
100 key-batch system. Also standardization should be applicable to JCL
C-26
-------
Answer:
Question:
Answer:
Question:
and ECL statements. All of the programming statements should have a
clear identification of the purpose of the program and what files in
access are applicable, what variables involved, and what procedures are
used. I would like to see the standardization of programming be
developed as language free as possible.
/ could not agree with you more. Hopefully, we will put together a
standard with overall concepts that are applicable across languages,
although we do intend also to go into some details specific to certain
languages. It has also been our observation that the documentation, used
when a program is being modified, very often is just the source listing.
That is what it often comes down to. The more information that can be
included in that source listing, done in such a fashion that is readable,
concise, etc., is helpful. The purpose of the program does not have to be
stated six different ways on 10 different pages, but up front, including all
modifications and a history of what has happened to that program. I
would love to have a couple of quick and dirty program listings up here
that miraculously had a history of the modifications that had been made
to them and how often they had been used. I think it would prove a
point, too.
Bill Serovy again from Region I. I would like to make a point about PL1
and other languages. About 10 years ago, I started college and took my
first freshman FORTRAN course. At that time, all the upper classmen
thought FORTRAN was a very funny thing; they thought that it was a
great joke that anyone would be still using FORTRAN. At that time,
PL1 and APL were around and thought to be far superior languages. Now
we see that at long last, there is an American National Standard either
existing or very close to existing for PL1. If you talk to people who are
doing advanced work, PL1 is a funny language. Government standards
have this way of becoming stone age or the lowest common denomina-
tors. I am very concerned that we have some provisions, preferably
formalized for allowing exceptions to these standards. For us to stick
with FORTRAN, COBOL, or even PL1 through the 1980's would be a big
disaster for this Agency. It cuts down on productivity. I think, it is
really not in the long-term, best interests of the Agency.
I think we have to build in a certain amount of flexibility, if for no other
reason, than who knows what next language is over the horizon.
About the ANSI standard on PL1, it does exist now and is totally
unreadable, not because it is incorrect or sloppily done, but because it is
done so formally that I cannot read it. The Department of Defense has
accepted it; I do not think that GSA and the National Bureau of
Standards can hold out too much longer. It is true, however, that, to the
extent that something is standardized, it can not long be state-of-the-
art. That is a very real danger that you have to watch. Telephone
companies are still doing things in archaic ways, so they can be
compatible to devices that were invented in 1912. We really have to
watch that.
C-27
-------
Question: Marge Adler from Cincinnati. I do not necessarily have a question, but
more of a concern. In regards to the standardization of program design
and documentation: with the advent of the minis, and data base
management, INFORM, I would like to see the kind of documentation and
the kind of standards that could be applicable across even the mini-
development, because the quick and dirty programs, as we have termed
it, can all of a sudden become a de-standard if we are not careful. I feel
it is very important, particularly with the INFORM and the experience
that some of us have already had.
Question: Bruce Rothrock, again. I would like to get back to this data element
standard issue again, and the proposed Arthur Young study. I would
characterize that study as being one of whether or not standards can be
developed in certain areas in the Agency. As a result, it begs the real
question. I think we already know that standards can be developed and
need to be developed. I am wondering if more meat can be put into that
particular contract, not to assess whether we can, but to lay our specific
areas where we want standards created.
Question: I see no reason why it could not be put in there, at this point in time. As
I said it is into the final copy, but there is nothing wrong with changing
that if you have some suggestions to add. I would appreciate your
delivering it to me, and we will put it in there. That document was
circulated. I do not know how many of you saw it. It was sent out to all
ADP Branch Chiefs and Coordinators back in July and August. The
comments I received, I incorporated into the current version; if there are
more, this is a good time to put them in.
Question: One question that I have on standardization, special programming
languages and the approach to system design is, are there any suggestions
on how these things can be enforced?
Answer: / suppose ideally they -would be easy to use. They would be so much
better than the alternative chaos that they would sell themselves. Now
that is really an ideal situation. One thing I mentioned before that
makes it a little easier to enforce is that it is very easy to reference a
set of standards in a contract. It is a lot easier than enforcing it upon
your own people in your own office. You do not have to hear the gripes,
you just tell them to do it. That is one of the acceptance criteria when
you get that back. As far as enforcing it within programming groups,
such as EPA, and Agency groups it will be done very carefully and with
great difficulty.
Question: Curt Lackey, Atlanta. I used to be in DOD, and we had a team that
came around. I mentioned this to Willis. At that time, he was more
concerned with the general systems study and he had some reservations.
Not too long ago, he said he might get around to the idea that I talked
about earlier, but the question of an audit group or an audit function in
MIDSD or in the audit part of EPA is probably the enforcement. It
would take some resources to do that and it may be time consuming but
that is one approach.
C-28
-------
Answer:
Question:
Answer:
Answer:
Question:
As / mentioned earlier, Willis is proposing, if we can get around to it, to
come into the reigons and review each of the ADP operations. One of
the things at which he will be looking is documentation. It would seem to
me that it is a rather easy extension to go from that review of
documentation to a review of our software, and to enforce it in that way.
I am sure that in MIDSD's wisdom, they can come up with suitable
sanctions to those of us who transgress the standard, such as removal of
our ADP suballowance or other nifty things. It would seem to me that in
addition to the enforcement role MIDSD could play, each data processing
manager would ensure that the standards are followed. It is in our
interest to make sure that we adhere to them. The ADP Branch Chiefs
from the regions have been talking about this for several years. I believe
we feel it is in our interest to have those standards, and as far as I am
concerned, I will enforce them in my region. I would assume that the
other regions will do the same.
One problem that we do not seem to address here, that came out quite
strongly a couple of years ago when we got the 1110 in North Carolina, is
the problem of inter-language compatibility, file compatibility. I think
we will probably have to accept, for some time, some difficulty in
transferring files from one machine architecture to another. Everyone
would like to see that fixed up. There are some efforts underway, but it
is even worse when you create a file on one mahccne, using FORTRAN,
and you cannot read it using COBOL. Is the Agency in a position or do
we have leverage in the RFP for the 1981 machine or machines to make
a hard requirement? If we cannot make it a hard requirement, what can
we do to encourage that sort of compatibility?
Fou would not buy the thing if you could not read it in one language or
another. There is a lot of work being done with standards interchange.
By referencing those standards that have been established since the
UNIVAC contract, Univac, itself, is having to adhere to those standards.
I assume that the other vendors are doing the same towards that goal of
transportability between vendors using a standard interchange code, file
format, tape labels, etc.
It seems to me that that could be part of the 1981 RFP. I do not see why
it should not be~in there. I would imagine we will bring it up, and ask
that it be entered as part of the requirement. If there are any problems,
we will discuss it at that point.
Marge Adler, from Cincinnati. I want to direct this to Jim regarding the
standard terminals. We had run into a situation several times where the
vendors have contacted us directly in regards to nonpayment of invoices.
I am not so very sure where to direct them to get the answers to their
questions. I have told them to go to accounting, but they said they have
already talked to them. I have said go talk to MIDSD, and they have
already talked to them. It almost becomes a witch hunt because of the
money involved. There have been cases where a year has gone by since
they have even received payment. The second concern is in regard to the
purchase of the terminals and the maintenance to be performed on these
things. I had run into the situation just recently where we could call the
vendor and give them an oral purchase order. They would then respond,
C-29
-------
Answer:
Question:
almost come out that same day or at least the next day, to correct
whatever happened to be wrong with the terminal. 3ust the past month,
however, two of the vendors are requiring a written purchase order,
which is causing quite a delay in getting the terminal up and operational
again. In a situation where we, as a service group, are trying to provide
equipment for the EPA people in Cincinnati, it means that that terminal
is going to be down for a period of, perhaps, days before we can get the
repair in there. I am wondering if there is not something that could be
done, in regards to this, without having to go on a maintenance contract.
Most of these terminals are not broken that often enough to make a
maintenance contract cost effective.
On the witch hunt for payment of past due invoices, that is about where
it is. The vendor sent the invoice to Financial Management, either at the
beginning or the end of each month, depending on the practices of that
vendor. Financial Management looks at the purchase request, and sees
whose authorization is there and to whom the equipment was directed.
They mailed the invoice to that person with a slip on the front to be
signed and returned to Financial Management for payment. Those have
been disappearing in the mails, they have been directed to people who no
longer exist. I do not know how to get around that. I really do not. This
is what I said in my talk about having spent thousands of hours trying to
review invoices that have been misbilled and misdirected. It takes the
phone calls to you, the user, to ask if you received it and phone calls to
Financial Management to ask if they have received and paid it. We have
had to ask the vendor to submit a second invoice, and sometimes a third
and fourth invoice. Vendors have billed against purchase orders that
have died at the end of the fiscal year, and they continue to bill into the
next fiscal year, trying to find the new order in the new fiscal year that
relates to the old order, of the old fiscal year. Physical, manual labor of
going in and trying to find out who has it and whether an order has been
issued is huge, and the time delay is horrible. At this point, Marge, I
really do not know any answers. The answer of having a vendor come in
and provide service prior to cutting the purchase order has two problems.
First, if you have issued a purchase order before the person comes, how
do you know for what amount to make it out. You do not know how many
hours he is going to be there; you do not know what parts are going to be
replaced. The other problem is the Federal policy and law that you
cannot have any work committed to be done prior to the issuance of a
purchase order. It is strictly illegal. Some of the vendors have been
kind-hearted enough to go in and provide emergency service in the past
to severaZ of our locations. Some places, they still have not been paid. I
think that is probably part of the problem. I do not know how to get
around the legality of asking the vendor to come in and perform work
before the purchase order is cut.
In Cincinnati we had a mechanism where an oral purchase order could be
given to the vendor. Procurement would call the vendor, and assign a
purchase order at that time. We did have something to charge against,
and it was not a fact of asking for the service before a purchase order.
Basically, however, what has happened now is that I guess the vendors do
not want to go that way. They actually want to have the written order in
C-30
-------
Answer:
Answer:
their hands before they come out and do the work. I was not necessarily
referring to the fact of not a purchase order being assigned at all.
If that is the vendor's policy, I do not know any way around it. They are
perfectly 'within their rights. They have written purchase orders, prior to
performing their required service. You might have your people issue a
purchase order at the beginning of the fiscal year upon which you can
draw. That is one possibility. As far as the invoice problem goes, I am
surprised. As far as I understand my region, the situation is that the
invoices come directly to us first. We sign off a receipt of services, and
send them up to Finance. It makes our life a lot easier, and the purchase
order number is on the invoice so that we know what we have received
and what we have not. I am surprised that the invoices are being sent to
Finance first.
It would seem to me that it is an easy change to make to a purchase
order. If you can get Financial Management to give their work out to the
regions, I would gladly have them go out there. Any other questions? In
coming up with this idea of the panel, or what to do with this panel, I had
to struggle with whether to keep it internal to this Agency, or go full-
blown efforts in looking at it across the Government. I decided to keep
it within the Agency but you should keep in mind that there are a number
of task forces that are currently in operation. I think the number will
probably grow over time. We have them, CEQ has them. They have
started up five monitoring task forces now to look at the monitoring
acitvities in five different areas. We have a group that is looking at the
relationship between EPA and the Consumer Products Safety Commis-
sion, and a few others. They are looking at how we are interacting with
them. I think then, in the future, what we are going to see is the
requirement coming to us from Congress and elsewhere to start, not only
coordinating among ourselves within the Agency, but among the other
agencies in the Government. That will enhance our problems many times
over. Thank you for attending; I appreciate your being here.
C-31
-------
PANEL D: SYSTEM DEVELOPMENT CYCLE
Chairman: Morris Yaguda
Panelists: Lance Wallace
Donald W. Fitzpatrick
Stephen Heller
Ted Harris
OVERVIEW
Morris Yaguda
Good morning, ladies and gentlemen. My name is Morris Yaguda, and I am with the
Management Information and Data Systems Division. I would like to welcome you here
this morning to our panel. The title of the panel is Systems Development Cycle, which is
a real mystery word. It reminds me of some of the items that I have seen on menus, a
chef's selection or something like that. Let me tell you what we will be doing. We will
have four presentations this morning, and two terminal-oriented demonstrations will be
available outside in the hall afterwards. Lance Wallace will talk to us about the
UPGRADE system developed by CEQ and which OR&D is interested in bringing into EPA.
Steve Heller will then talk about the Chemical Information System. The Chemical
Information System is a joint EPA-NIH development involving an additional half-dozen
other agencies. For these two systems, after our presentations, there will be
demonstrations in the foyer. We will then have a bit of theory. Don Fitzpatrick from
Arthur Young, which does feasibility studies, will talk about how he has been doing
feasibility studies in EPA, what their theory is, their approach, and the philosophy behind
it. The fourth presentation will be the briefing that we are giving senior management on
the 1980 ADP systems procurement. Some of you sit on the steering group for that
planning activity, many of you do not. I think it is important that as many people as
possible become aware of the plans to buy computers for the 1980s.
D-l
-------
UPGRADE
Lance Wallace
The Office of Research and Devel-
opment of which I am a part, has recently
entered into an Inter-agency Agreement
(IAG) with the President's Council on
Environmental Quality, concerning the
evaluation of an automated interactive
graphic and statistical analysis system
called UPGRADE. UPGRADE is a source
for user-prompted, graphic and data eval-
uation. It has been developed by CEQ to
analyze information from a variety of
environmental monitoring sources, as well
as economic, demographic, and health
data. The system includes an integrated
data base developed to study the relation-
ships between environmental pollutants
and health.
The objectives of the IAG are to
determine how UPGRADE may best be
implemented within EPA. As part of this,
it is important that all the potential users
in EPA, whether in the laboratories, the
regions, or in Headquarters, be notified of
the existence of the IAG and be given the
opportunity to evaluate the usefulness of
the system for their own program. The
intent of this presentation is to give you a
chance to increase your familiarity with
UPGRADE and introduce you to the
nature and the scope of the system, as
well as its related data bases. We have
here with us the project leader for the
creation of UPGRADE, Larry Milask. He
will be available to answer any technical
questions you have about UPGRADE.
UPGRADE has been developed over
the past two-and-a-half years at an
approximate cost of $500,000. The initial
CEQ design requirements dictated a sys-
tem that could provide statistical analysis
and graphic display of environmental
trends and interdisciplinary relationships.
The system also had to be accessible to
the Council's professional staff. Some of
them did not possess specialized computer
training. CEQ's needs led to the creation
of UPGRADE, which has several notable
features:
One feature is interdisciplinary
cross-media analysis of data from water,
air, health, demographic, and related
information. These data have been
selected, and screened from the highest
quality monitoring data that could be
found; they satisfy a set of strict criteria
put out by CEQ for their various studies.
The second feature that UPGRADE
has is that it is English language
prompted. A knowledge of computer
systems language is not necessary to use
the system. It is accessible to managers
and analysts who do not have specialized
training.
A third feature is that it is inter-
active and graphics oriented. It gives the
users immediate feedback through online
computing which allows them to evaluate
and manipulate this statistical data. This
capability allows almost instant produc-
tion of bar charts, graphs, polygons, etc.;
in addition, it can produce maps of the
country shaded to users' specification on
an off-line basis.
Finally, its fourth feature is that it
has access to advanced statistics. The
Statistical Analysis System (SAS), is being
interfaced with it now, and it will add a
wide variety of advanced statistical pro-
cedures. UPGRADE has been used for the
last couple of years for a variety of
environmental and health studies by the
Council on Environmental Quality, and has
produced some sections in the 1977
Annual Report to Congress.
EPA's interest in UPGRADE stems
from the Agency's perception of several
basic needs, the first being the need for
linking health and environmental data.
Many recent reports, including that of the
D-2
-------
National Academy of Science have com-
mented on the inability of the agency to
relate environment quality to health
effects. UPGRADE can provide a rapid
determination of correlations between the
mortality rate, the main health variable
available at this point, and environmental
variables. In a relatively mechanical way,
one can run through a large number of
possible correlations, and use UPGRADE
as a hypothesis generator.
The second basic Agency need is for
increased analysis of this environmental
data. The same reports have pointed out
the imbalance between the Agency's col-
lection of data and its analysis of that
data. By making analysis available to a
wide variety of users, including those
without computer training, UPGRADE has
a potential for increasing data analysis.
The danger that has been pointed out, and
of which we are well aware, is that
untrained personnel will use the data to
create correlations that are, in fact, more
far-reaching than the data can bear.
Finally, there is a need for the rapid
investigation of available monitoring data
and rapid turnaround time for informa-
tion. You still have the pollutant-of-the-
month syndrome and congressional
inquiries, and other request for fast turna-
round analyses, maps, charts, graphs, and
other information aids; the rapid graphics
capabilities of this system can help in this
regard.
These are three needs that I have
selected. I think there are many, many
more specific sorts of needs, but that is
the sort of thing we hope some of you in
this room would let us know and how
UPGRADE might be modified to satisfy
your needs. I am the Project Officer for
the evaluation. My phone number is 426-
4657- That is at EPA headquarters,
Washington, D.C. I welcome any com-
ments or requests for information that
you have. Dr. James Reisa is the CEQ
representative on the IAG.
I will just briefly mention that the
IAG is broken into five tasks. The first is
the System Installation Survey. Presently,
UPGRADE is supported on the NIH sys-
tem. The question arises, can it be
supported? The second task is the User
Needs Survey. We must find the prospec-
tive users and give them time to
familiarize themselves with UPGRADE so
that they can arrive at recommendations
concerning whether UPGRADE would be
useful in satisfying their needs, or
whether it would be useful if proper
modifications were made. This will
require an information campaign about
UPGRADE; this is one of the first shots--
others will include demonstrations at the
regions and the laboratories. There is a
questionnaire that will be developed and
circulated to prospective users concerning
their needs. The third task is Systems
Design Analysis which will depend on the
findings of the first two tasks. Depending
on the detailed design specification devel-
oped, it will be tailored to the results
from those tasks. The fourth task is the
management requirement, i.e., what is
needed for the optimum maintenance and
operation of the system, including a data
base management system to be developed
for UPGRADE. Those will be determined
based on the findings of the first three
tasks and based on the recommendations
of MIDSD. Finally, the documentation of
UPGRADE will result in a user's manual.
Figure D-l illustrates the kind of
statistical analysis at which the user can
look after he has selected the variables he
wants to study in the integrated data
base. Some of these variables (the first
eight) are water quality variables, the
next six are health variables, and the last
is a demographic variable. You can check
this table and decide whether any of these
variables have data points in which you
are interested. The number of data
points, refers to counties, because the
National Center for Health Statistics
(NCHS) system has county-based
mortality rates.
Figure D-2 shows a sample correla-
tion. The figure runs heart disease morta-
lity rates on the Y-axis against percent of
the county population living in urban areas
D-3
-------
Figure 1
£3,157?
HARDNESS, TOTAL
MAX- 695.P
HIM- 3.SOO
HEAM- 131.7
STDU- 130.9
NDP- 246.
BASIC STATISTICAL REPORT
* 1970 ENUlROHflENTAL/HEALTH DATA *
NATIONAL HEALTH TRENDS
02
CALCJUN.DISS
MAX- 760.8
urn- .8000
MEAN- 55.a?
STDU- 64.10
NDP- 183.
03
flAGNESIUfl.DXSS
MAX- 148.7
MIN- .3608E-81
I1EAN- 17.09
STDU- 16.98
HDP- 171.
84
NITRATE TOTAL
MAX- 83.8®
C1IN- .0
MEAN- 2.973
STDU- 4.283
NDP- 141.
OS
soDiuri.Diss
nAX- 4-M.9
MIN- .e
MEAH- 47.11
STDU- 71.30
NDP- 194.
*£
ARSENIC,D1SS
RAX- 2809.
MSN- .0
OEAN- 71.28
STDU- 370.5
NDP- 98.
87
CADniun,Diss
MAX- 1200.
niN- .e
WEAN- 19.33
STDU- 129.9
NDP- 85.
88
ZINC.DISS
MAX- .4400E+86
P11N- .8
riEAN- 9311.
STDU- .S18GE+8S
NDP- 84.
CANCER OF STOMACH
MAX- 241.3
HIN- 15.40
flEAN- 97.51
STDU- 35.83
NDP- 298.
CANCER OF BLADDER
MAX* 153.0
WIN- .8
MEAN- 69.59
STDU- 28.78
NDP- 298.
11
ACUTE ISCWEMIC HEART DIS
MAX- 4S37.
HIN- 1632.
MEAN- 2860.
STDU- 534.2
NDP* 298.
12
CHRONIC ISCHEH1C HEART
MAX- 3234.
HIN- 465.8
MEAN- 1644.
STDU- 468.9
NDP- 290.
13
CEREBROUASCULAR DISEASE
flAX- 3131.
MIN- 718.7
MEAN- 1156.
STDU- E33.9
NDP- S98.
14
MAJOR CU DISEASES
HAX- 8488.
fllN- 4085.
MEAN- 648S.
STDU- 762.9
NDP- 298.
15
X URBAN
MAX- 188.8
RIH- 22.68
MEAN- 67.27
STDU- 18.26
NDP- 290.
-------
4836.SO r
g 41S3.S3
U
T
E 3872.36
I
C 3550.88
H
E
S 2264.96
1943.48
1622.60
22.60
Figure 2 1970 EKUiRONnENTAL/HEALTH DATA
NATIONAL HEALTH TRENDS
(1ST ORDER LEAST SQUARES FIT)
SIGNIFICANT AT THE 9SX CONFIDENCE LEVEL
V INT • 3263.SIS
II • -5.99931
F • 12.647
R - -.205
T • -3.556
NDP • 299
-k
35.50 48.40 61.30
X URBAN
74.20
87.10
ICO.CO
NOVEMBER 28.1977
-------
Figure 3
- * NATIONAL HEALTH TRENDS
Y-AXIS« CANCER OF STOMACH
X-flXISl NITRATE TOTAL
THE SOLUTION POLYNOMIAL OF ORDER 1 FOLLOUSl
Y • 1.0114D+02
+ C-8.7860D-01)tXm
ANALYSIS OF VARIANCE FOR POLYNOMIALS
SOURCE OF
VARIANCE
TOTAL
DUE TO NTH
DEGREE POLY
UNADJUSTED
(N-DTH POLY
ADJUSTED FOR
NTH TERM OF
NTH DEG POLY
ERROR
DEGREES OF
FREEDOM
141
2
1
1
139
sun
SQUARES
0.1577990+07
0.1371400+07
0.13S890D+07
0.2492660+04
0.8065910+06
MEAN
sun SORS.
0.3493660+04
0.1486260+64
F
VALUE
0.167713D+01
THE FIT IS NOT SIGNIFICANT AT THE 95* CONFIDENCE LEVEL
TAKE A HARD COPY FOR THIS CASE. IF YOU UI5H.
THEN PRESS RETURN TO CONTINUE.
-------
on the X-axis. The numbers on the right- shows a trend, a five-day biological
hand side are the statistical analysis oxygen demand at a certain station. The
which is automatically run by the system. X-axis is years. Figure D-5 is an example
of a polygon plotting feature. These are
Figure D-3 is a table of the analysis the total suspended particulate measures
of variance for polynomial regression. from a 24-hour sample, taken every six
Figure D-4 is a sample of a bar chart. It days.
-------
Figure
12SCTYS.EASTERN
RIVER MILE 5-1.94
L
fl
I
T
S
0
e
3.84
3.3? ,45.00
3.0?
1
•
2
A 0
u e
E 5
R T
A 0 D
G A
n
G
a.93
a.
B a.so
0
D
2.71
a.ea
a. 53
a.
L 2.3S
a.27
a.is
45.00
e.sa
a.45
19.09
a.5i
as.ee
a.se
16.09
a.44
ai.ee
a.ia
18.00
63.80 71.00 73.00
70.04 7a.ee 74.09
SAMPLE DATE YEAR/MONTH
UPPER LiniT OF INTERVAL
75.00
77.00
76.60
TOP BAR STATISTIC •
AUERftCE
BOTTOfl 3AR STATISTIC «
NO. OF DATA POINTS
IN IMTERVAt
1ST Y-AXIS PARTITION
IS PLOTTED
NOVEMBER 38,1977
-------
Figure 5
io.ee
CEO.SflROAD.NEP.COAL.CNTYSaa
!5ii35oeiHoa EAST CHICAGO
AP KA JN JU AU SE OC NO DE JA
JA FE fIR
1975
CftTE
NOVEMBER 33,1977
-------
THE CHEMICAL INFORMATION SYSTEM
Stephen Heller
I'm going to be describing a rather
unorthodox computer system being devel-
oped jointly between our agency and the
National Institutes of Health. It is more
of a bottoms-up system development, than
a top down, simply in that there are a few
people who believe there was a need for
the things I will describe. When the
system got so big, it became clear that we
had to become a little more orthodox.
This first slide gives an outline of
the way in which the system has been
developed. The Chemical Information
System (CIS) is a series of numeric data
bases and a family of interactive pro-
grams with which to search these data
bases. Tw.o main areas with which the
user can interact are literature and
normal bibliographic services. Within the
Chemical Information System directly,
there are only a very few related specifi-
cally to the data banks of bibliographic
data available. There are, however, addi-
tional links to other literature references.
On the right-hand side, there is a data and
analysis section. This comprises the bulk
of the Chemical Information System data
banks, mostly spectral and more recently,
toxicology data banks. The analysis por-
tion involves a program called MLAB,
Math Lab. In the center of the whole
system is something called sub-structure
search. This is the part of the CIS about
which I will talk. It requires some
explanation and perhaps a little bit of a
background. Each chemical substance
that the agency has in its files and its
data banks, that we regulate or that we
are trying to regulate, that we know or do
not yet know in terms of being toxic or
pollutants—is being assigned a unique
identification number similar to a social
security number for a person. It is called
a registry number. The Chemical
Abstracts Service (CAS), a division of the
American Chemical Society, has been
doing this registration work for EPA since
1974. At present, there are about four
million of these chemicals which have
been assigned numbers. These are pretty
much the known public chemicals. There
is probably an equal number of private
chemicals that have been developed at
universities or within industries which
have not been reported, patented, or ever
used. From this enormous bank of four
million, we have been going through the
Agency files of chemicals, STORET, the
pesticide data bank, TSCA candidate list,
etc., and coming up with sub-sets from
the four million. First, we have an
administrative list indicating the different
data banks which can be organized and
linked together through this registration
number, (e.g. you could find how many
data banks have something on benzene in
it, and so forth. ) We also have, asso-
ciated with this registration number, a
computer readable representation of the
chemical structure. For any mathemati-
cian who knows something about graph
theory, it is simply a graph of the
chemical. Most of you, I am sure, are not
chemists, but probably have seen one or
two chemical diagrams in your life.
Fortunately, they are nothing more than
just lines drawn together with some funny
little characters. Primarily, they are just
simple graphs, (simple pictures), enhanced
very readily and adaptable within a com-
puter, (which does not understand the first
thing about chemistry), but knows about
points and space and connections between
points. The sub-structure search software
system allows one to search for these
graphs, for these chemicals, within the
data bank or data banks, as would be the
case when you have more than one file, as
with the multitude of agency files. You
can search for the complete structure of a
specific chemical or you can in fact, look
for parts of chemicals. The pesticide
people seem to feel that any time you find
a chlorine in a molecule, it will probably
be a pesticide or a related pesticide. It
D-5
-------
will also probably be toxic. If it happens
to be attached to a benzene, it will likely
be even more toxic. Thus, you can look
for all benzene compounds with chlorine,
for example. The result of such a search
would be a list of the chemicals that meet
this criteria. Obviously, benzene and
chlorine are found in many, many
chemicals. So, you are likely to get a long
list of answers. Also, besides getting a
list of the chemicals that meet the query
in terms of retrieval, you will find out
which data banks in the Agency have
information of these chemicals. They
may very well just be reported, or have a
regulation pending on it. In the case of
STORET, where there are a few hundred,
mostly inorganic, but some organic chemi-
cals, you; will discover that there is a
great deal cf water quality data asso-
ciated with that chemical. There is no
sense in going to STORET to look for a
particular dichlor benzene if that is not
one of the elements on which STORET
collects data. This is a link, a way to tell
you whether or not it is worth going to
this other data bank for information. You
can tell very quickly which data banks
within the agency, and to some extent
outside the agency, may have some useful
information on the chemical in which you
are interested. It does not, however,
generally tell you what the information is,
and it does not tell you whether the
information is good or bad. It does tell
you what there is in terms of the gross
answer. This next slide gives some indica-
tion about the groups that are working on
the joint development. This is a fairly
large project in scope. Besides NIH and
EPA, we have the Bureau of Standards,
the Food and Drug Administration, and
the Department of Energy. The National
Cancer Institute is also providing funding
and support for the system. Outside the
government, we have a variety of
contractors, and collaborators. In some
cases, we are not even paying some poeple
for the work they are doing. There is also
a variety of foreign organizations and
governments, the British and Dutch
governments, working in connection and
collaboration with the development of the
system. One of the main reasons for
doing the collaboration is that besides the
expense of the project, the expertise in
many of these areas lies outside either the
Government or, in fact, the United States.
Since the problems are essentially
universal in nature, the pollutant found in
Siberia turns out to be about the same as
you will find here in Annapolis or in
Chicago. It is much easier to work
together to put together this information
and have the computer systems retrieve it
than it is to work separately. The
collaboration between these organizations
indicates that obviously we are not the
only ones who feel this way. (The next
slide please.)
We have a number of users in the
testing and evaluation stage of the sub-
structure search system. We had about 81
groups here in the United States from the
Government, universities, and industry,
who were using the system and evaluating
it. After we felt the system was working
well enough and the people were actually
willing to pay for its use, it was then
transferred to a commercial system. In
May, 1977, the demonstration network
testing and evaluating ended, and went on
to the Tymshare computer network, where
it is available to anyone who wants an
account. In the demonstration here this
morning, we can show you exactly how it
works and provide you with the accounts.
The data files, as I indicated before, are
primarily these CAS registration numbers.
There are the structural diagrams of the
various names of the chemicals, the
approved index name, the standard name,
and the technical name that chemists use.
In addition, there are usually a lot of
synonyms and practical names. DDT is
not the proper name for the pesticide, but
if you don't call it DDT, nobody knows
about what in the world you are talking.
You need to have these various synonyms,
trade names, and commercial names asso-
ciated with it. At the time this slide was
put together, we had about 50 files in the
process, we now have about 100 files of
which 40 or 50 have already been
completed. There are roughly 400,000
D-6
-------
references and a little over 250,000
different chemicals. These various files
are pesticides, TSCA, STORET, and files
from other Government data banks, from,
for example, the Consumer Products
Safety Commission, the Cancer Institute,
and so forth. The entire data bank that is
being searched is being put together right
now with EPA funds, mostly MIDSD, and
the data-searchable elements from the
Chemical Abstracts Service. There is
nothing more than these names, the regis-
tration numbers, and the computer-
readable representation. That is what we
are doing. We are now linking them to
other files but the other files are not
physically on the same computers.
STORET is still where it always has been
but we can tell you whether or not a
particular chemical is in the STORET data
bank, and whether or not you should go
there to look up information about it. The
next slide is analagous to this and refers
to the various data banks that are tech-
nical- and instrument-oriented, and
scientific instrument-oriented. In this
case, our users number close to 300
laboratories in the United States, Canada,
Western Europe, and even someone in
Eastern Europe now. All of the regional
labs, ORD, the pesticide office, Enforce-
ment, and the Water and Hazardous
Material labs all are using this system in
normal everyday routine identification of
unknown pollutants of toxic substances.
The input information is normally the
measurement from a lab instrument in the
case of mass spectrometry, which is the
primary toll of identification of the
agency labs. In addition, you can put in
toxicology data, such as LD50 data, for
example, (the dose to kill half the popula-
tion), along with other parameters such as
whether it has to be orally injected, and
whether it is a mouse or rat or whatever.
Then get out the chemicals that meet that
criteria. Of course, in the identification
of pollutants, the ideal answer is to get
out the pollutant that is being identified.
We now will link that answer with the
toxicology data so that we will know if we
have made an identification; you will also
know if this chemical that you have
identified is toxic. If so, it will be a likely
way to tag it as being something about
which to be concerned. If you identify a
lot of pollutants that are not toxic, then it
may be useful to know this. It may be
necessary to check with the permit pro-
gram to ensure that these chemicals could
be, in fact, discharged. When you start
finding large concentrations of toxic
chemicals, then you have more than a
permit problem. You may have a very
serious health problem. So we will be
linking the toxicology data to the spectral
data.
The files vary in size, from a
hundred in the infrared data bank, which
the data bank is just being started,
through as many as 30,000 X-ray spectra;
The mass spectrometry data bank is the
responsibility of the Department of
Industry in the Mass Spectrometry Data
Center in England. The Carbon-13 data
bank is the responsibility of the Dutch
Chemical Society through the Netherlands
Information Combine. The X-ray system
is being run through the Department of
Energy at the Brookhaven National
Laboratory. The contributors of the data
come from the Agency as well as from the
outside, both in the United States and in
many countries overseas. (The next slide)
There are a few slides like this, and
the purpose is to try and give you an idea
of how the system is being developed. It
is somewhat of an unorthodox way of
doing it, but it seems to be working. We
seem to have a lot of users, a lot of
pleased users, even to the point that they
are paying money on commercial systems
to use it. This is in addition to the
Agency group users or to others outside of
the Agency who are users. In the case of
the mass spectrometry, where we have
about 300 laboratories, less than 10 per-
cent of those are EPA labs. In this case
of the sub-structure search, the system is
being developed on a government com-
puter. It is not an Agency computer, but
a NIH computer, a POP 10. The POP 10 is
a large-scale time sharing computer;
being exclusively time sharing it has
D-7
-------
really no batch capabilities. Once the
system is complete, in the sense that we
believe that it is a viable working system,
having been tested by the users, the
system is then transferred to commercial
vendors, where it is made available to the
Agency and others. It is maintained by a
particular contractor or collaborator,
responsible for the operational aspects of
the system. At present, we do not pay for
the storage of the data banks. The
storage of all these data banks comes
from the usage of the system. So, there is
some economic incentive for us to get this
thing out and used by the public. We can
reduce our expenses in the sense of data
bank storage. We only pay for the usage.
The user interacts directly with the
operational version of the system, in the
sense of getting a commercial computer
account and directing his questions and
day-to-day problems to the organization
responsible for maintenance. All of the
software has been developed by the
Government, starting at NIH and now
under contracts through EPA funding.
The software is in the public domain as
well as in the data banks themselves,
having been purchased completely by the
Government.
Once you take the 80 or some users
who are not paying anything and ask them
to pay money, the usage falls off a bit.
We are down now to about 23 users,
although these groups are growing as time
goes on. There is a minor subscription
fee, and then the average costs of search-
ing; the connect time plus the computer
time right now is averaging about $75 an
hour at commercial rates. We are in the
process of putting up all these data banks,
but we now have only five of them
available which are being used on a daily
basis by some two dozen groups. Three of
these are EPA files; two of these are the
spectral data banks. The TSCA candidate
list was the largest and the first that was
put up. This was related to the Toxic
Substance Control Act inventory program.
This is the candidate list for which the
reporting, I believe, will begin in January
in support of Section 8 of the legislation.
We have the list of active pesticide
ingredients. We also have the spectral
files. The mass spectrometry and Carbon
13 round out the other two. The next slide
is probably a little bit more representa-
tive of what is going on. The reason we
only had five up is that we have been
making some changes to the software and
enhancing the capabilities of the system
to have something a lot more useful. This
is the list of 32 files that are being
processed and will be up very shortly, by
the end of the year, I think. They are now
beginning to link together the various
agency data banks, and other data banks
outside the agency of interest. Again, if
you go with this pollutant of the month
philosophy, you want to know, are there
any definitive studies on these chemicals?
There are about a thousand of them. You
can look them up and say, "Aha, there is a
definitive monograph. Let me go over to
the Consumer Products Safety Com-
mission and find out where I can get a
copy of it." That is to what that file
refers. The registry of toxic effects of
chemical substances is a long list of
toxicology data associated with about
20,000 chemicals. That is actually being
linked directly to the system. The second
one is a national occupational hazard
survey which went into a variety of
industrial organizations to find out the
chemicals being used in these various
laboratories and factories. The NSF
chemical list is a list of priority toxic
chemicals. The National Cancer Institute,
Public Health Service 149 list is a list of
chemicals which have been tested for
carcinogenicity. It does not tell you
whether the results are positive or nega-
tive, it just tells you that the chemical
has been tested. It is not as good and as
useful as it can be, but it helps. It turns
out that the book itself that the Cancer
Institute published does not tell you
whether or not it is positive or negative,
it just tells you what has been tested. It
can give you the actual reference to it.
(You discover very quickly in putting
together data banks, how little informa-
tion it turns out to be in most cases, but
that is another story.)
D-8
-------
The National Institute of Mental
Health has a file on drugs; if you want
some information on LSD you can go into
that file. There is an X-ray file that
came from the Cambridge Crystal Data
Center in England, the World Health
Organization drug list, the International
Trade Commission, commercial organic
chemicals, etc. These are, again, a list of
bibliographic chemicals that have been
tested for mutogenicity. It just tells you
that somebody has tested for it. This
would be a useful piece of information,
knowing whether or not to even bother
calling up Oakridge and asking them for
their references. There is a pesticide
index to the number of pesticides that
have been put together by a private firm.
The index is a very popular handbook of
about 10,000 chemicals of very common
chemicals with properties associated with
them. There is a list of chemicals being
studied by the common market and a
toxicology center that EPA is putting
together with TSCA. In Italy, there are
about 3,500 chemicals on which they are
collecting toxicology data, and we have a
link into their first go-around list they are
establishing. We have a National Fire
Association list of hazardous chemicals
and flammability information associated
with them. There are literally hundreds
of other files that we have not yet seen.
We are trying to process these things as
quickly as possible. It turns out that
because this had never been done before
in any sort of organized fashion, the
backlog is enormous. We know of at least
160,000 or 170,000 that we have not yet
processed and suspect there is probably
two or three times that number which we
have not found. We are slowly but surely
trying to do this. We have a contractor
now, someone working full-time, just try-
ing to find these files. In theory, all of
these things should have been processed in
the past. Our office had implemented a
regulation, an EPA order (2800.2), which
required the tagging of all chemical data
banks in the Agency with these registra-
tion numbers. People, however, have been
slow to find the regulation and implement
it, and we have been more or less working
with people who wanted to cooperate
rather than running around batting every-
body over the head in the Agency,
demanding that they register their chemi-
cals. In turns out it is probably a good
idea, because we could not handle it if
everybody decided to cooperate. (Next
slide).
This just gives a little bit of the
background for the TSCA file. There is a
reference for anyone who is interested in
the details of this computer system. The
structure search requires the user to have
the picture of the chemical. We are also
adding the capability of search for names,
but it is primarily viewed as a structure
system. It is useful only for discrete
chemicals. Many of the chemicals on this
TSCA list, and in the final inventory list,
will not be discrete, but generic chemi-
cals. When you search the TSCA list you
get the registry number, the TSCA
clerical code designation number. You do
get out the various names, even though
you cannot search for them immediately
right now, and you get, if you want the
structural diagram. You can actually
figure out what that name means by
looking at the picture. (Next slide.)
If anyone is interested in using this
system, they just contact the contractor,
Fein-Marguart Associates; they have been
providing computer accounts to people in
the Agency. Actually, this slide was used
for a public meeting where people outside
the agency have to contact Tymshare
directly. (Next slide)
This is just a very brief idea on how
the system works. I want to give one
example. This slide shows very simple
commands being put together. These can
be put together at an ordinary terminal
with, say an IBM Selectric, or any other
kind of terminals you have in the labs or
offices. These commands take about a
half hour to figure out exactly how to use.
From there, you go full speed doing
whatever kind of searches you want.
The next slide show an example of
one of the searches. At the top, by
D-9
-------
generating the command's ring, alter-
nating bonds, adding branches, and substi-
tuting atoms, we come up with that
structure. We then go in and using that
structure search, identify a compound. In
the future, you will be linked directly to
the spectroscopic or toxicology data or
the plants and production data, so you can
actually print out this information
directly. In some cases, like the STORET
data, we will not take it all and put it into
this computer; we'll link it directly. In
the case of small data banks we will be
able to have the information printed out
directly. That is the way the search
works. It takes a few seconds to generate
the theory; with the system interactive,
you get the immediate response. (Next
slide please).
This is a search using the TSCA list
looking for a long chain compound. This is
an exact match for this chemical and the
bottom shows the chemical structure, the
registry number, and the other TSCA
information associated with it.
The next slide is for those people
who have something a little fancier than a
teletype; this is actually a $400,000
graphics terminal that NIH has. If you
don't like those teletype outputs, you can
get a much nicer looking chemical dia-
gram drawn out with the space-filling
model. These are the fancy ones you can
get and anyone who would like to have a
chemical structure drawn with that termi-
nal, we would be delighted to provide it.
Our next two slides give an example
of getting out some toxicology data where
you are going into the NIOSH RTECS file
asking for oral rat LD 50 data and it
comes up and says there are 111 com-
pounds that have oral rat LD 50 data from
this set that we are using. The next slide
is an example of what the output would
look like. There is oral rat LD 50 260
milligrams per kilo and the literature
reference and the name of the compound
associated with it. This is the sort of
toxic data that you would get from doing
a data search. The next slide is again an
overview of how the X-ray system works.
The Government as well as Case Western
are developing the X-ray and the
informational analysis programs. Brook-
haven is acting as the responsible party
for making it available and maintaining
the program. This case is available on
another commercial network. With the
CAMSEQ program the substructure
search works on a two-dimensional picture
of the molecule, of a two-dimensional
graph. The fancy picture I have with the
color of that one molecule is actually
generated from three-dimensional coordi-
nates, the X, Y, Z positions in space, not
just X and Y. The question is how do you
get between two and three dimensions.
The answer is you use this CAMSEQ
program which takes the two-dimensional
picture, using a variety of mechancial and
similar techniques. It comes up with an
approximation, which is very, very close
to the actual real structure; it enables you
to draw out the three-dimensional struc-
ture of the molecule. This is going to turn
out, I think, to be very important in the
future when you talk about structure-
activity correlations for making predic-
tions, and so forth. Molecules have three
dimensions. The property of molecules
are dependent upon their actual three-
dimensional structure. This sort of infor-
mation will be a necessary extension of
what has been going on in the past.
After the X-ray system, I have a
slide that tries to describe the evolution
of the GCMS instrumentation technique,
and how it relates to some of the laws
that have been going on in the past and
are being implemented. The use of
computers in this instrumentation area
started about 10 years ago. It first
started being used in EPA labs about six
years when essentially this project of data
banking and identification got started.
One of the first things that came out of it
was the chemicals, found in New Orleans
and the other water systems. Suppose
carcinogens were all identified using this
data bank and using this type of instru-
mentation. There are people who believe
that the Safe Drinking Water Act of 1974
D-10
-------
was passed because of the scare tactics of
these cancer chemicals in all the waters
around the country. Again, the identifica-
tion and proof came from this system.
The Toxic Substances Control Act calls
for the identification of these chemicals
and their monitoring. The Agency relies
primarily on these spectroscopic finger-
prints, these identification tools. The
need for this data bank is readily available
for ourselves and industry. We think it is
extremely important. (The next slide).
This is now an overview of the mass
spectrometry system being developed by
the Government. The operational version
is the responsibility of the Mass Spectro-
metry Data Center in England which is
funded by the British government. Again,
in this case, it is made available by the
ADP Corporation on their international
PDPlO's; there is a minor subscription fee
and various use charges associated with it.
(Next slide).
As of last month, there were about
280 labs using it, what amounts to 4,000
searches a month. There is a subscription
fee of $300; prices vary from $1 to $15
for searches.
There are something like 30
different options to search the data bank.
Different labs have different approaches
and different needs for looking up infor-
mation, depending upon the individual
viewpoints of the people in the labs. We
have developed a variety of software
options to search the data bank. The
answers normally come out the same, but
some people happen to like to do things
one way, as opposed to another, and as
long as we can provide this without any
real difficulty we continue to make as
much of the system available in as many
ways as possible. We feel that trying to
lock people into one particular approach is
self-defeating; they will just go up and do
it some other way. It is much easier to
try and offer the flexibility within the one
system.
D-ll
-------
COMMENTS
Morris Yaguda
Those of you that have heard me
talk on previous occasions have probably
heard me refer to the Dick Nolan Stage
Hypothesis. It has been one of my
favorite discussion topics in terms of
understanding what data processing can do
for people and also what it is doing to
them. I would just like to make a point
here that, in the hypothesis, you go from
Stage Three, which is a period of gaining
control over your data processing to Stage
Four, which is involved with integration of
systems. Hopefully, agencies are now
moving from Stage Three to Stage Four.
One of the things that you can expect is
to see systems like UPGRADE, where you
are trying to integrate information from
various data bases and not just processing
a particular application. I think you have
seen this in the Chemical Information
System. There is an attempt to integrate
a lot of information and to try to gain
superior control over agency missions. I
would also like to point out that the
Office of Toxic Substances, during the
last year, commissioned MITRE to do a
very basic informational requirement ana-
lysis to support the Toxic Substances
Control Act. That study tries to under-
stand what the needs of regulatory
agencies are to control toxic substances.
It also asks what information is needed,
what information sources are available,
and what systems need to be developed.
It sets out a ten-year blueprint for infor-
mation systems development and planning
activity. The Chemical Information Sys-
tem is one of the key elements in that
plan. I think you have gotten a feel from
the presentation today as to what sort of
capabilities are offered. I think if you
have the time to see that MITRE study,
you will understand it in the greater
context of regulatory agencies trying to
gain control over toxic substances. Since
I have mentioned theory, our first two
presentations have really been practical
examples. The first two talks have been
living examples of systems that are at-
taining maturity and working through
their early evolutionary stages. Within
MIDSD, we have a task order contract to
perform system studies that require some
rather unique skills. At the present time,
Arthur Young is the incumbent on that
contract. Don Fitzpatrick is the Arthur
Young Project Manager for the contract.
He will now give us a presentation on his
approach for doing a feasibility study.
D-12
-------
PLANNING FOR THE 1980's
Morris Yaguda and Theodore R. Harris
Ted and I have been making this
presentation around the agency. We are
at the point in planning for the 1980's
where we are talking to a lot of EPA
senior managers. This is the briefing that
we give to them. We try to bring to their
attention the fact that we are talking
about an agency-wide ADP support for a
10-year timeframe; it has to follow some-
thing called OMB Circular A-109, which is
an OMB management circular for major-
systems acquisition. It is rather an
expensive item for which we are planning.
Estimates vary between $300 and $450
million at this time. We talk in the
background about our management control
of data processing. We talk about a
driving function that is making us do this
planning, namely, that our present service
contracts and capabilities are expiring.
We also go into some details on the plans.
I think many of you are aware that
the two major, central, data management
resources are used in just about every part
of the Agency. They serve many, many
applications throughout the Agency. That
is the point of this chart. The manage-
ment of the ADP operation in EPA and
ADP applications system is split between
a central office of the Management Infor-
mation Data Systems, which is responsible
for providing the central computing
centers as well as general oversight and
coordination. The Program Management
Office is responsible for determining the
need for planning, implementing, and
operating their own individual applications
as well as providing for whatever local
people, contract and equipment are
needed. You have seen in your experience
with EPA what kinds of control mech-
anisms we use. These are, in my
judgment, the state-of-the-art tools for
controlling ADP. They are consistent
with the paper that we have often talked
about before, the Nolan Stage Hypothesis.
I think many of you are familiar with our
Zero-based Budgeting Program. We have
full charge back of utilization of the
central computer and make them an
accountable resource. Additionally we
require feasibility studies for all new
applications. Most of you are aware that
we have in EPA two major sources of
central computing resources. One of
them is the COMNET contract awarded in
1976, and expiring in 1980. That contract,
as you know, provides the communications
network which links all of you out in the
field—in the regional offices, labora-
tories, State and local governments—with
the Headquarters' computing facility. In
North Carolina, we have the UNIVAC
equipment which is government-owned,
for the most part, in a government-
furnished building, but which is managed
by a facility management contractor.
That contract was recently awarded in
September, 1977 and will expire, also, in
1980. Obviously, we are at a point where
in the beginning of the 1980 period, we
will be out of sources of supply; something
needs to be done. Let us go into what it is
that we are going to plan for replacing
these basic service contracts. This dis-
cussion I would like to present will be
organized on these four points. We will
talk a bit about what the constraints are
in our planning. We will go into a little
detail on the A-109 process which is a new
process. We will talk about what we have
done in EPA and what our next steps are.
The first constraint is that new
kinds of services we buy have to fit into
our management concepts. We have been
beaten extensively about the head and
shoulders and urged to gain greater and
greater control of our data processing
costs. We have gained that at a con-
siderable investment in learning. You just
can not lose control of data processing.
We also have considerable organizational
and staff investment in learning. You just
can not lose control of data processing.
We also have organizational and staff
considerations that have to be consistent
D-13
-------
with approach about which we are talking.
We have decentralized systems responsi-
bility. We do have nation-wide require-
ments and severe limitations on what
positions are available to support data
processing applications. This means we
are very heavily dependent on con-
tractors. Solutions that might call for a
great number of in-house positions are
really not feasible.
The second constraint is a
scheduling one. The new service capa-
bility must be in place in time for an
orderly conversion before the current ser-
vice contracts expire. We have been
planning on this basic kind of a milestone.
We have been saying we need one year for
planning and justification of our require-
ment, six months to develop a solicitation
document, eighteen months to have a fully
competitive procurement, and at least one
year for an orderly conversion period. A
four-year period may seem like an awful
long time. I should tell you that this is
believed by many people to be a very
optimistic schedule. I think if we can do
this in this timeframe, we should be very
proud of ourselves. I'd like to make one
point. If you look at this set of milestones
and if you look at the fact that our
COMNET contract expires in 1980, it
means that we must be done with the first
year of planning by December, 1977; we
are just about there.
The third constraint is that we must
use a policy issued by OMB last year, OMB
circular A-109, which governs large-
sytems acquisitions whether they be ADP
or non-ADP. This is really a new
approach for civilian agencies. The
military agencies have had experience
with this sort of thing. When the military
buys a new weapon, they will very often
have a large number of offerers that are
doing design, and multiple companies
building a prototype before they finally
select one which is to go into operation.
This new process looks something like
that. The circular said that agencies
could accept their own dollar level which
would trigger the requirements for this
process. Most of the smaller or medium
civilian agencies accept the figure of $10
million. That is what EPA did. We are
talking about $450 million, so we are
clearly above this dollar threshold. There
are also very few applications of system
acquisitions in EPA that would excuse
that $10 million figure. If we ever build a
large building, it might exceed that, but
pretty much this is the only EPA A-109
activity I think you will every see. There
are two key features of this process. One
of them is that the agency head retains
certain key decisions in the process; the
second one is that there is a single
program manager who is set up with a
project manager's responsibility for this
entire procurement activity. This
provides point of contact.
The fourth constraint is flexibility.
There is just very little you can do to see
and know definitely what the future is
going to hold. Whatever we buy, whatever
contract we try to set up will have to be
one that has a great deal of flexibility
built into it.
Let me just talk now about what
we've done to date, to how we have gone
about this process. One of the things we
did was to gather together all of the
people who were thought to have been
interested. We set up an agency-wide
ADP planning group. We have 15 division
directors from the Agency serving as the
management arm of this steering group.
We have 35 or so senior technical people
supporting the 15 managers. We also have
extensive liaison with oversight agencies
to make sure that they know what we are
doing and we know what their concerns
are. Unfortunately, their concerns vary
through time, so we have to keep in
contact with them. Most of the agencies
to whom we have talked and made our
pitch have said, "Fine, we are very happy
to know what you are doing, but you must
realize that we can not give you any kind
of advanced approval. We will always
reserve our right to find fault with what
you are doing, but nonetheless, we feel it
is essential to maintain the liaison." The
-------
size of the job about which we are talking
is a tremendous amount of data collection
analysis and report writing that justifies a
procurement of this type. We have
contracted out for this because our in-
house positions are very, very limited. We
have had a contract with Informatics Inc.,
and our workload studies are planned to be
completed in December. I think we will
make that deadline. How do we project
the workload for the future? How can we
see it? The basic approach that we use is
a multiple scenario approach. We have
tried to isolate an expected kind of
growth rate, one that might correspond to
increased activity for the Agency. We
also project a very pessimistic scenario
that might follow if monies or interest for
environmental activities were reduced
drastically. We have also noted, in terms
of an individual ADP activity in the
Agency, that the system managers have a
good feel for how it will grow up through
1979. We have identified all ADP activi-
ties by our zero-based budget processing.
Up through 1979, we have our advance
budget performed and it is being reviewed
by OMB. Beyond that, it is really very
difficult for an individual system manager
to know what will happen. Generally, the
feeling is, "I really don't know, that
depends on too many variables. Go see
my top manager." In fact, that is what we
have done. We have gone to the top
managers in EPA, and they do not know
anything about the system. We could not
ask them questions. They really do not
know. We can ask them, how do you see
the amount of money coming in EPA?
How do you see our budget? How do you
see EPA being funded? How do you see
your particular activity getting a bigger
chunk or a smaller chunk of that money?
How do you see your various sub-elements
being given additional funding incre-
ments? We use this top-down approach to
get a feel for how much activity, how
much interest we have flowing down from
the top. We have used those factors to
project workloads for the future.
I would like to mention on this slide,
what it is that A-I09 is talking about. The
basic point I would like to show is that
there are some activities that need to be
done in the mission; in this particular
case, it is data processing and mission
components in the Agency. We have to
develop a workload requirement. We have
to get those approved. Now we jump up
to the Agency head. We have to have the
Agency head approve them. Then we go
on and we explore alternative ways of
satisfying the requirements. Once we get
to the point where we have picked out
some promising ones, and we have a few
that we want to demonstrate, we have to
go and get the Agency head's approval
once again. At the end of the prototype
stage, after the demonstration and evalu-
ation, we want to pick one for full
production. At that point, we go once
again and get Agency head approval. That
is interaction at those various points. At
this time, I would like to ask Ted to talk a
while more about that.
D-15
-------
Theodore JR. Harris
I am going to talk about ADP system
acquisition. I will talk about it in the six
different areas which the circular ad-
dresses. Informatics Inc., is currently
producing our feasibility study and work-
load analysis. The study is divided into
three distinct groupings.
The first is the consolidated-systems
study. Many people in EPA are probably
familiar with the forms and surveys that
we send out. The survey details the
workload for 1977 and projects it through
the different years. The telecommunica-
tions workload was also surveyed at the
same time for the ADP activities we had.
It had been massaged and put into a
detailed workload by location and then
projected by the location. We have also
addressed the conversion study, which is
in final draft now. The final report will
be summarized in a final document, which
will be produced December 15, 1977, and
distributed to the ADP Planning Panel.
A-109 describes in detail a function
called program management. It describes
it as an individual who is totally respon-
sible for the acquisition project. It
requires a charter which is in effect a
contract between the individual and the
Agency stating responsibilities, authori-
ties, and resources. The charter would
also delineate staff that would assist in
the particular functions. I will come back
to the staff in a few minutes.
There are three specific documents
that are produced. The program manage-
ment plan describes how the team
operates, what methods they use, how
they will control the contractors that
interface the Agency, both the planning
panel and the rest of the approval oversite
agencies. The system acquisition plan
describes the procurement methodology.
Also, a request for proposal (RFP) will be
developed. All of the proposals that come
in will be evaluated. The team will also
monitor, review, and evaluate the con-
tractors involved.
The first phase is called alternative
system design. We currently envision
multiple award contracts which will be
fixed price contracts. Any vendor may
submit proposals at this time. They
should address the workload requirements,
the design, and approach to EPA's work-
load. It is projected that we will select
five contractors, at least two for each
concept. If there are three concepts, I
guess we will have six contractors. The
selection criteria at this time is really
important because of the narrowing con-
cept of this procurement. The first stage
would select from the world. The second
stage would select from those that are in
the alternative system design phase. The
next would select from those, and further
narrow it down. At this point, all of the
EPA computer documentation will be
made available to the contractors in a
controlled manner so that they all have
the same information. All of our systems
need to be documented by the time these
contracts are awarded. This phase would
produce a concept to demonstrate the risk
of conversion, and include a conversion
methodology.
The system demonstration concept
is also envisioned as multiple award,
fixed-priced contracts. This phase would
only be open to those contractors that
were selected in the system-design phase.
The proposals at this phase would address
the workload requirements and conver-
sion. We would select probably two
contractors for this demonstration. The
purpose is to determine and evaluate the
risk. We would probably pick several EPA
computer activities that would be opera-
tional at the time. The contractors would
install and operate these activities. I
have used the word "prototype", it is the
closest word I can use to describe for
what we are looking for in a demonstra-
tion. This phase would produce the final
contract.
The next slide shows after the
award, the start-up and conversion. We
D-16
-------
have included this because past experi-
ences has taught us that we need to
include this as part of the procurement
cycle, and the need to monitor it very
closely. My next slide shows the goals of
this procurement.
The goals are very simple: We want
a system life of 10 years. That means that
we require that expansion of hardware to
be provided, depending on our flexible
requirements. We want growth of soft-
ware as technology changes, but we do not
want any major conversions.
The next slide is our current
approach for the acquisition staffing. I
will briefly describe the functions; the
four bodies identified are two computer
services and two telecommunications.
This is to evaluate, monitor, and analyze
proposals and contractors for those parti-
cular categories. In EPA, we consider
those categories divided into hardware,
software, with people in both. Next, we
have the two procurement officials; the
contracting officer, who would handle all
of the appropriate rules and regulations;
and the financial officer, who would be
concerned with the cost analysis.
We envision the final contract to be
one of our cost-plus-award-fee (CPAF)
types, and this involves a great deal of
cost analysis throughout the whole acuqi-
sition cycle and evaluation. The last
person I term the Program Control
Officer. You might want to look at him
or her as the person who coordinates the
multiple contractors with the acquisition
staff within the team and the ADP
planning panel. To the rest of the
Agency, the person would provide
librarian type duties for computer docu-
mentation. I feel that this would be a
very difficult job to handle.
The next slide shows timing and
start-up phase-in of the individuals. The
letters and circles refer to the next slide,
which is a flow chart of the acquisition
process. The concept here is that we have
broken it down into a phased in step-by-
step requirements.
We are at the point today of getting
the final mission needs and we will go to
the assistant administrators and the
regional administrators for their approval
before it goes to the EPA Administrator.
Once it goes to the EPA agency head, he
will designate the program manager,
authorize the charter, and provide for the
resources. Our current schedule for RFP
development has the first draft due
December 9th. We will provide a draft of
the RFP in January to be sent out to the
ADP Planning Panel. We then project a
two-month review cycle. Thank you.
D-17
-------
QUESTIONS AND ANSWERS
Question: Larry Weiner from MIDSD. I am rather concerned about the life cycle
cost determination over a 10 year period. If we look back 10-years, we
sec that costs have gone down. In a lot of ways we really have not been
able to predict the technological development that has taken place. We
are moving into a very new environment with the 1980's. How can you
possibly predict cost over a 10-year period, when we do not know what we
will have 5 years from now?
Answer: What we are trying to do is provide a system. We are looking at system
life that will probably be 10 years, regardless of whether we can cost it
or not. In terms of the feasibility, we need to provide enough flexibility
for that kind of a time frame because you probably will not go through
another feasibility study for that timeframe. We are projecting. The
best that we have been able to do on a constructive basis, given
technology and the A-109 procurement, is projecting more than 3 or 4
years out. I think it is productive for us to do that, rather than not do it.
Anything more than 3 years out is, as you say, is a real guess, but I think
it is just like everything else, unless you put your best estimate down,
you are ignoring the fact that those costs will be there. You will at least
want to try and do those trade-offs. I will not say it will be perfect.
Answer: I would like to also add one point. In the 1980 study, we have had to look
at those same questions. We are making an assumption which we think
we can support to a great degree, i.e., that technological development
and inflation will pretty much balance. For planning purposes, we can
make that assumption. The support we can find for this is the NIH data
center billing rates. After some initial fluctuations or initial cost
reductions, as they reached an economy of scale, their rates for jobs are
remaining pretty much constant.
Question: You mention that there will be two vendors that will be selected for a
parallel operation. I was wondering who will conduct the parallel
operation? Will EPA people be required to do that or will that be the
vendor's responsibility?
Answer: The vendors will be providing the demonstrations that we, and the EPA
panel, will be observing and in which we will be cooperating. We will
fund that.
Question: I want to focus on two fairly major issues, one of which is a group of past
failures and systems study. These are not directed at Arthur Young.
They are directed at the Agency and how it handles its business. The
first one is failure to consider the scope of the project. I think Arthur
Young has learned its lesson , but I am afraid programs may not have. I
will go through that in detail because you have not covered it. Failure to
consider data sources and cost of gathering data, both clerical and
dollars, you did cover that. Failure to consider the states and how they
are organized, is something that you did not consider. The first factor
about the states that is important is that there are 50. I have seen that
D-18
-------
ignored constantly in our study. Someone says we will do so-and-so at
the states level without realizing that there are a gross number of them
that makes that particular operation difficult. Delivery of the systems
to the states is one example. It takes a week to deliver the system. You
have a whole year involved in delivery unless you use multiple teams.
The fact that the states are not Federal Government is largely ignored.
A State's ADP organization is not central, especially when one deals with
environmental agencies. Often the environmental agency uses some
other part of the State government for ADP resources. Also, the
approval systems for state systems are often more complicated or more
rigid than the Federal Government systems with the possible exception
of A109. Even the smaller systems in some states require, say,
gubernatorial or legislative approval. Also, the existence of OMB A90 is
sometime ignored. This is a circular which restricts what we do to the
states and demands that they perform certain ADP functions. What I am
concerned with here is our failure in the system study to go beyond the
scope of ADP. Most of the system study is highly technical and ADP-
oriented. We should be making recommendations and changing the entire
way in which we are doing business in some areas. In other words, Arthur
Young may step in, or someone else, and find that they have got a
situation that they can not manage. You can not recommend an ADP
system for us because the way they have already started to do their
business is wrong. That is something that has to be addressed. Another
point, and I am afraid I have to address Arthur Young, is the failure to
address all alternatives. In other words, it seems to me to be true of
everyone who does a feasibility study, but Arthur Young, from some of
the recent ones, they have one thing that they think ought to be done,
then they turn around and invent several more, or at least it looks that
way. Some of them are ludicrous. There is not any reason, for instance,
to include in a feasibility study the alternative of using mini-computer
systems in the regions, when all the regious do not have them. You
might as well just leave it out. Last, failure to consider stop-gap
planning. We notice, in this process, that we are talking about a year to
do a feasibility study. Certainly in a major system that would be almost
a minimal period of time, and yet the requirements of the programs are
such that we have to deliver something. I very seldom have seen any
planning. I don't think this is Arthur Young's responsibility. This ADP
organization does not exist in EPA now, but you have to have some way
to satisfy the needs of the programs. That means doing something quick
and dirty, using somebody else's software, writing something with a data
management system that will not eventually be in the data management
system, but getting something moving. This has two clear-cut
advantages. The first one is that we do something and satisfy the
requirements; the second one is that it gives us experience upon which to
draw something to evaluate when we are doing the real feasibility study.
If we go ahead and plan the system in a vacuum, write it a year later,
and so forth, we could end up with a (unintelligible) for the most careful
study. I would like to recommend that. The last thing is the alteration
in our traditional way of looking at systems development when we
include data independent software systems, and I do not mean DBMS.
DBMS is inclined to be, in its complexities, somewhat similar to the
systems we are using. You can go out, make a lot of mistakes, and
correct them very quickly so that the formality of the effort—the
D-19
-------
planning, implementing, and then reevaluating—is not necessarily some-
thing that we want to carry through in our next generation of software.
We do not have a whole lot of it now, but we may in the future. This
may destroy both the traditional methods of analysis and design and also
Nolan's Hypothesis of how systems are developed. Largely we do
planning evaluation because a mistake is quite expensive. Correcting it,
maintenance on it, is expensive, and this may not carry over the next
five or six years, when we consider systems development cycle.
D-20
-------
FEASIBILITY STUDIES
Don Fitzpatrick
What I'd like to talk about is the
feasibility study in the EPA system life
cycle. It is perceived that EPA is moving
into what is known as Phase Four of
Nolan's hypothesis—hopefully, an integra-
tion and stabilization of some of its
systems. I think MIDSD, and EPA as a
whole, have emphasized the feasibility
study to accomplish this, carefully making
sure that we study the system's full life
cycle. I do not pretend, at this point, to
present EPA policy and feasibility study
orientation, but rather our interpretation
of that. I think you will find a recent
document, published by MIDSD,
establishes that policy fairly clearly.
What we are looking at is the entire
systems development life cycle; every-
body has their own version. This is the
Arthur Young and Company version which
has eleven phases. We have been involved
in several projects in EPA involving the
first three phases, i.e., the requirements
analysis, conceptual design and detailed
systems design; and also in operational
systems evaluation.
Actually, the first two phases,
Phases One and Two, are normally incor-
porated into what is called a feasibility
study. It is the thing you need to do to
get the system signed off by MIDSD so
you can proceed with implementation.
Our experience, not necessarily only in
EPA but everywhere throughout our com-
mercial and Government experience, is
that if you do not perform these phases
properly, you get a very expensive system
that doesn't meet your requirements.
Experience and academic studies indicate
that if you do not go through the process
properly, you can get huge operational
costs. A particular emphasis in the
current EPA feasibility study is the incor-
poration of what is called, "total systems
life cycle costing", with this you can
properly weigh your alternatives in terms
of the cost of development and implemen-
tation vs. the operational cost going
forward. Many systems in the Govern-
ment and elsewhere are being eaten alive
with operational costs, and for very good
reasons—the importance of these studies
has been overlooked in the past.
What the feasibility study does is
that it is the beginning point of what is, in
effect, a process of change in the organi-
zation. Anytime we get into a system
development cycle, you have already initi-
ated or expressed the desire to change
something. You have either gone through
an operational system evaluation and
decided that you have a real problem, or
you have a new application that is coming
forward. You need to institute change in
the organization to accept that new pro-
gram or new systems requirements, a new
mission or whatever. In many ways, the
systems that you are implementing are
agents of change, i.e., they are the
vehicle to change your organization, to
respond to a mission requirement. Change
is a difficult process in the large organi-
zation. You have to open up and make the
organization itself responsive and accep-
table to change. It is getting everybody
on board, bringing consensus to all the
players in order to begin the implementa-
tion process. Execution of the change can
be very simple if you have a consensus; it
is very difficult if you have people running
around in different directions. The litera-
ture and our experience is littered with
great systems that never actually got
there. It is not because they were not the
best technical or the most sophisticated,
but because the organization, itself, did
not accept the change that was repre-
sented by that system, i.e., you never sold
it in the first place to everybody. You
never got everybody together. No matter
how pretty the system was, if it was
imposed from the outside, it never got
embedded in the organization. Maybe it
worked for a year, but the data was
terrible, nobody supported it, nobody used
it, so nobody ever completed that change
D-21
-------
process; nobody ever embedded it into the
organization. The feasibility study is
intended to create the environment for
change to happen properly, and to get a
system that meets your requirements.
If we can summarize the objectives
of a feasibility study, they are roughly the
following:
o What we would like to do is
make sure that system with
which we are proceeding
meets the requirements in
terms of EPA's mission and
priorities. It really has to do
something for you.
o We want to select a system, or
a set of system alternatives,
which are cost effective over
the entire life cycle. That is a
difficult thing to get across
because there is really a
trade-off in designing and se-
lecting systems between the
cost and care you put into
implementing and the ongoing
operational cost. Of course,
there are counter examples,
too.
o Some things are valid and
technically nice, but the risk
involved to the organization
can be substantial. DBMS and
mini's are a part of that risk.
o The other thing you want to do
is ensure the feasibility study
is a system which is robust
over changes, needs, and
growth, it must be flexible.
Most system life cycles extend
over ten years. From the start
of a feasibility study, it will
take you probably a year to
accomplish the study; to pro-
ceed with the design and im-
plementation will probably
take another year. You are
probably talking about two
years before you have an
operational system in a major
systems effort. That system
will probably be around for six
to eight years. The designer's
system must then be respon-
sive to what EPA looks like
ten years from now. What you
need to do is build into the
system some things that allow
that flexibility over time.
o The final thing is to ensure
effective transition to the de-
tailed design. This is what we
are talking about in terms of
effecting the change. Some-
thing that we have learned
fairly recently in EPA is that
we have to have management
involvement throughout the
feasibility study process. We
attempt to actively solicit
management involvement of
all the people concerned with
these systems, because these
systems cross just about all
your organizations. Anytime
you touch one, it affects
everybody. We have con-
sciously built into the feasi-
bility study process some guid-
ance and experience from
MIDSD to ensure that those
participants who should be
concerned are, and that that is
at minimum effort on their
part.
Task Plan
If you have dealt with this before,
you have seen one of these. This is the
definition of our feasibility study process,
it is really our standard task plan for the
requirements specification stage, i.e.,
Phase One. You will note that it is fairly
classic. It involves, first of all the
definition of system objectives, of func-
tional requirements. We go out and talk
to everybody and try to figure what you
actually need. I will not bother you with
all the detail. The basic products of that
effort are: A summary of the objectives,
D-22
-------
a summary of the information require-
ments, the functional requirements that
are related to that information, and the
information issues.
The second task is typically a review
of current operations and functions of
existing systems, where appropriate.
There are systems built that have no
existing systems to begin with. But even
in those cases, there are parallel systems
in existence that might be of use in
implementing the new program. The final
task in that effort is a specification of
issues, requirements, and evaluation
criteria. We have found that it is
extremely valuable to identify to manage-
ment and to each of the people concerned
the specific issues we intend to address.
Why did we get to a feasibility study in
the first place? What is the issue? What
is the problem? Those issues result in the
design criteria and the functional defini-
tion of requirements. This is incorporated
into a "requirements briefing". This
occurs probably within the first two
months of a typical feasibility study. The
requirements briefing is often given to
anyone who is willing to listen. Before we
go on in trying to define the system, we
must understand what you are thinking,
and ensure that we are going after the
direction you want. It is, in effect, a
working briefing intended to get feedback
from you.
This process is a response to the
characteristics of what we found in the
EPA systems environment. It is not to say
that all systems have these characteris-
tics. In the established programs, what
you are typically dealing with is an
extremely varied user-community. No
matter what system you touch, it affects
each of the programs of each of the
regions in a very dynamic way. There are
complex organizational relationships
which reflect the same thing. There is a
variety of data and data sources and
numerous systems with various pieces of
data reflecting the evolution from Phase
One to Phase Two to Phase Three to
Phase Four of the broader system
evolution process. Existing capabilities
are frequently incomplete or incom-
patible.
The emerging programs have very
different problems, such as the toxic
substances, hazardous waste, or other
programs that are evolving now. It is a
complex regulatory development process.
Programs are being initiated, there is a
time pressure to coordinate the regula-
tions with system operability, i.e., you
sometimes need systems defined before
you even have the regulations defined, you
realize you need something to implement
those regulations since the system's life
cycle is long, and is a complex process.
By definition, in that kind of environment
the user-community is undefined and the
data sources are both untested and
undefined. When we begin a study in this
environment, we are developing something
that has to be accepted by everybody. It
has to be broadly based or it will not be
successful.
To accomplish this, we have
established a very formalized data
gathering process. This is, in effect, a
reaction to our studies in EPA in the past.
The characteristics include, first of all, a
thorough plan of study and identification
of the organizational documents, the mis-
sion statements and plans, and the current
system's documentation. What we are
trying to do here is, before we go out and
talk to you, we want to get as smart as we
possibly can in relation to the system
scope, or to whom and to what might be
impacted. We present you with a prelimi-
nary plan, a work plan and interview plan
to make sure every base is touched.
Interview guides are fairly formal and
standardized, but will be particularized to
your organization. These interview guides
go in two directions, one for requirements
and the other for the kinds of systems
documentation. The requirements are the
most complex, and often ill-structured.
By definition, we want to get to your
basic underlying mission and function, and
identify the real objective. Further, we
want to make sure that when we talk to
D-23
-------
you, we identify your plans, remembering
that this will need to respond to you over
the next 10 years. Based on that, we
traditionally gather interview notes alto-
gether and we do an analysis. I wish that
analysis were a science. I will not pretend
that it is. It is an art developed over time
although people are claiming to be making
it a science. After that analysis phase,
we go through a synthesis and brief
management as we discussed before. The
synthesis consists of three pieces; namely,
functional definition of requirements, and
overview of the current system, and issues
in design criteria.
Once we have communicated what
we believe are the requirements, we then
begin the conceptual design stage.
At this point in time, we start
developing something that looks like a
system, and it goes through three careful
steps. The first is a development of
alternative system concepts. The second
is evaluation of cost and effectiveness of
the alternatives we have identified.
Finally, there is the development of the
recommended systems concept. Task one
is probably the most critical. It is a broad
scope look at what alternatives are
available to us in bringing the system up
to meet the requirements. The alterna-
tives are not just what hardware we will
put the thing on, or whether we will use
DBMS. It has to start with management
or operational reporting that meets the
requirements, or identifies the alterna-
tives for meeting it. How will we get the
data collection, data entry, and data
validation put together because in a
decentralized environment such as EPA,
that is typically the Achilles Heel of your
systems. Alternative system data struc-
ture: Potentially DBMS, potentially con-
ventional, potentially file management
are alternatives for the systems environ-
ment. If you are going mini: WCC, NCC,
or some alternative. Organizational
alternatives: Where you place the system
and how you manage it, who will have
charge of what pieces? What are the
alternatives for that? Finally, we bring
all these together in a structured form.
The alternatives we put together are
packages. You think of the number of
ways you can organize, the number of
ways you can do the hardware, the number
of ways you can do the data entry. You
get a combination of things that is just
unmanageable. What we have been doing
is packaging those alternatives based upon
what appears to be reasonable. The whole
analytical package, before we get into
costing, is presented again to everyone
who will listen before we go forward with
the conceptual design. There is a
briefing, a very key briefing, at that point
in time to make sure that the alternatives
are properly identified and the trade-off
criteria for the trade-offs are well
thought-out.
We then get into the formal analysis
of cost effectiveness. I think the key
thing here is the emphasis on full costing,
i.e., the full cost of whatever system is
going to be implemented or is attempted
to be identified. The other thing is not
only the inclusiveness of cost, but the full
system's life cycle cost, i.e., you are then
looking over 10 years at both the imple-
mentation and the operational costs of
those systems. What we want to do is
portray the full picture.
Once we have developed a recom-
mended system through that analysis pro-
cess, we will take the one that appears
most viable to us. We will develop it in
more detail so that management is fully
aware of what it is we are recommending.
That again is a draft and a management
briefing, and a final feasibility report only
after we have gone through a fairly
extensive review process. By the end, you
have a feasibility study report that goes
forward to the detailed design. You
should have no interface problem; you
should have MIDSD, and all the programs
and regions concerned on board.
That process responds to what the
major issues in the conceptual design
process are. These are the numerous
hardware/software support alternatives.
-------
Each region has its own way of doing it.
It is not only regions, but also states with
what you are trying to work and interface.
You have the hardware alternatives avail-
able to you both in North Carolina and
here in Washington. Each of those has to
be considered, along with the data alter-
natives you have. Finally, you have to be
very careful about who will do what in the
system. There is state and regional
delegation, as well as other delegation of
responsibility. There is the centralized
vs. decentralized considerations which are
paramount in the concept and the alterna-
tives definition. It is not only what is
efficient in that sense, it is what is
effective, because there are very careful
trade-offs in this environment as to who
has the incentive to maintain the data
properly, make sure that it is edited,
validated, and processed to ensure the
validity of the overall data base. We have
also experienced different styles, both in
hardware and in operations. The inter-
relationships of organizationally distinct
programs relates more to Headquarters.
Each program has an interest; just about
any system you touch has many interested
parties. You have to be concerned that
everybody is fully aware of what is hap-
pening, that their needs are met from that
system. You do not want to institute a
system with new data, and go through an
expensive systems development cycle
without making sure that everybody's in-
terests are involved—programmatic, en-
forcement, etc.
EPA systems are also starting to get
into decision-support systems, which
means that systems are not classic ad-
ministrative or stable systems. They are
systems in which the data changes rapidly.
I think the previous presentation on up-
date is example of a decision-support
system. There is the first presentation,
which does not necessarily define the data
that will exist, but rather the process that
goes around. As Congress continues to
ask new questions, those systems evolve in
terms of data, rather than function.
I also think you are ail aware now of
the need to evaluate external reporting
burden. We are aware of the need to
evaluate fully the impact of these systems
on the sources from which the data
comes. Every time you impose a new
reporting burden on the public, we have to
incorporate an estimate of what that
impact will be; different systems alterna-
tives will have different impacts on the
public. Not only does the cost include
EPA, but the whole U.S. public. How far
and how deep you go in the external-
reporting burden estimates is still a pro-
cess to be decided, to evolve. The
question is—how reliable are the esti-
mates that we are going to have to do
there in order to get a credible response
to EPA requirements? One could do a full
study going into a whole reporting impact
study on the economy if you are not
careful. I guess the final major issue is
the growing impact of DBMS. One DBMS
is not necessarily good everwhere. It is a
great technology, but there are a lot of
concerns with it. We are continually
asked to evaluate it to make sure that it
is appropriate, which part of that techno-
logy is appropriate to a particular system.
Hopefully, what finally gets done is
the development of the systems concept,
the integration of three pieces: A projec-
tion of requirements, and technical and
management alternatives that are avail-
able to us with some very distinct analysis
methodologies, including the mehtods of
specifying alternatives so they are clear
and concise; life-cycle costing methodo-
logy and also A76-type costing relations
which utilize evaluation approaches which
allow us to look at benefits, qualitative as
well as quantitatively, and the input-
output process, the hypo-type documenta-
tion of the concept to ensure the design
transition is appropriate.
The final thing with which I would
like to leave you is the feasibility study's
whole purpose: To open up the organiza-
tion to change, to effect change with
minimal hassle, and to make sure the
system gets to a conclusion, the final end
product. This is the beginning of a final
end product that is responsive to your
requirement. Thank you.
D-25
-------
PANEL E: ADMINISTRATIVE SYSTEMS
Chairman: Neil Haley
Panelists:
Alan M. Kaplan
Edward S. McLean
Michael H. Platt
Paul F. Wagner
Carlton Woodell
Charles T. Wolz
Mary Blakeslee
Leo C. Cox
Albert Pines
Dennis Schur
INTRODUCTORY REMARKS
Neil Haley
This panel will be handled a little bit differently than some of the prior ones in that
we have on the panel various systems managers, as well as system users. The systems
managers will discuss their systems, talking about current operations and plans they might
have for future use, and the direction in which their systems will be going. After each of
the managers have discussed their systems, the users will have an opportunity to comment
on the system from their point of view, and give observations on any problems they might
have with these systems, or how they use the systems. Let me just introduce the systems
managers who are here: Mike Kaplan from Financial Management, Ed McLean from the
Contracts Management Division, Mike Platt from the Personnel Management, Paul Wagner
from the Grants Administration Division; Carlton Woodell from the the Facilities and
Support Services Division, and Tom Wolz from Budget Operations. System users are Mary
Blakeslee from the Office of Air and Waste Management, Leo Cox from Water and
Hazardous Materials, Al Pines from the Office of Research and Development, and Dennis
Schur who is the ADP Chief from Seattle.
E-l
-------
THE FINANCIAL MANAGEMENT SYSTEM
Alan M. Kaplan
The Financial Management System
(FMS) evolved from a small update and
reporting process which existed in one of
our predecessor agencies, the Environ-
mental Health Service. The process, at
that time, consisted of a few software
applications operating at the Parklawn
computer facility. During the period
1969-1971, FMS supported a centralized
accounting operation whereby obligation
and payment documents were mailed to
Headquarters to be processed, key-
punched, and entered into the computer.
During the year 1971, after the
Agency received its Determination order,
we established accounting offices in the
field, decentralized the payment function,
and initiated a two-phased approach
toward the mechanical decentralization of
the accounting system. The first phase
consisted of a card-to-tape transmission
to the central computer facility. The
second phase was initiated some months
later when we were assured of proper
controls in the accounting offices. This
phase consisted of the decentralized "file
management" concept. Under this
arrangement, each office updated and
maintained its own master file. Reports,
however, were still being mailed to the
field, since master files had to be merged,
messages, and combined with other cen-
tralized accounting activity (payroll,
budget authorizations, etc.) in order to
generate "Fund Status" reports.
In the succeeding months, we devel-
oped a process which would provide for
decentralized reporting on a one-for-one
basis, i.e., each standard FMD report
would be accessed through a single
COBOL or IRS program on a report-by-
report basis. An important aspect of each
report generator, tiowever, was the con-
solidation of all types of financial
activity, nationwide, that impacted on an
allowance holders' funds.
Eventually, a front-end report
generator was developed which permitted
one or more reports to be accessed in a
single job submission. All reports,
however, were standard agency reports
designed to answer most of the informa-
tional requirements of Headquarters' man-
agement, but only limited requirements of
our managers in the field. In responding
to the latter, we developed various IRS
computer programs on a first-serve basis
using contractor support for the more
complex reports. In-house support was
applied toward file maintenance applica-
tions, systems development efforts, and
smaller report generators. At the end of
1972, we were a relatively small, but
integrated, accounting system, serving
management and responding to the
internal and external reporting require-
ments of Headquarters. Our data
consisted primarily of the Agency's annual
work plan, plus obligation and payment
data. In an effort to determine the
direction we should pursue toward
providing Agency accounting, a contract
was established with Booz-Allen, Inc., to
take a look at EPA's needs and provide us
with additional insight.
During the period 1973-1974, the
accounting system was greatly improved
to provide greater management tools to
the Agency. During this period the
accounting system grew to become a
large, complex, and highly integrated Fi-
nancial Management System. We began to
take a closer look at fund control prac-
tices within the Agency and also began
analyzing the reporting requirements of
management in the field. The culmination
of our analyses was to install commitment
accounting agency-wide, and develop and
implement what we call our Software
Package for Unique Reports (SPUR).
SPUR was to supplement our standard
library of reports and would permit a
layman in the field to produce any array
-------
of financial data he desired. To accom-
plish this, fewer than six control cards
would be required. They would consist of
specific statements and data elements
described in our SPUR manual. This
manual is now in the hands of all Financial
Management Officers nationwide.
Today, FMS is an almost totally
decentralized input/output process. Four-
teen accounting offices nationwide are
entering data and spontaneously updating
master files. (See Figure 1.) Hardcopy
reports are accessible over medium-speed
terminals to the 1* accounting offices,
plus many satellite laboratories.
All payroll data is entered by Head-
quarters and made accessible to each of
the appropriate offices. This is accom-
plished through an interface with the
Department of Interior for bi-weekly civi-
lian pay, an interface with DHEW for
monthly Commissioned Officers' payroll,
and supplemental pay and redistributed
labor costs from FMD's payroll section. In
additon, FMD will commit salaries on a
quarterly basis for each allowance holder.
These are automatically liquidated by the
accounting offices as the charges are
introduced into the system.
Also entered into the system by
Headquarters are the Agency's budget and
planning dollars. Lower-level budget allo-
cations are entered at the local level and
monitored accordingly. The Agency's
budget and planning authorizations are
introduced into the system by interfacing
with the RMIS process maintained in the
Budget Operations Division.
The FMS will accomodate updating
and reporting on a demand basis. Most
updating is done as a weekly cycle plus an
additional cycle at month-end for correct-
ing remaining errors. Standard monthly
reports may be processed at month-end or
on an as-needed basis. Most local
informational requirements may be
satisfied through the SPUR package and
accessed on demand. Detailed payroll
data is also accessible through SPUR on
an as-needed basis. Although payroll
disbursements are entered at month-end,
commitment and obligation (accrual) data
provide up-to-date financial status.
Each accounting office maintains its
own file and is totally responsible for
accounting data entered into that file. At
month-end, all 14 files are merged to-
gether by FMD. Agency-level data is then
provided for internal management and for
external reporting. Figure 2 illustrates a
simplified flow of financial data.
Much of our reporting to local man-
agement is in the form of "Status" report-
ing. Status reports may be likened to
bank statements that we receive at the
end of each month. For example, at the
beginning of the month we have a "pot" of
money in our checking account upon which
we draw each time a check is written.
At the end of the month, we receive a
statement that reflects each transaction
(check) which has transpired, deposits
entered during the month, and a remaining
balance (known as "fund availability" in
FMS) to be spent the following month.
Transactions in the FMS are known as
commitments, obligations, and payments.
Every commitment will automatically re-
duce fund availability. Every obligation
not previously committed will also reduce
fund availability. The FMS, therefore,
tracks each commitment and/or obliga-
tion, such as purchase orders, travel,
contracts, etc., initiated by a program
office. Eventually, all payments which
have been made by the accounting office
in support of an obligation are also
entered into the system. Payments do not
necessarily reduce fund availability since
they are always entered after the
obligation. Fund status reports, there-
fore, would reflect, in the aggregate, all
commitments and obligations which have
had an effect on those funds, which have
reduced the pots of money allocated to an
allowance holder or subordinate organiza-
tions. The reports would also reflect the
remaining balance of funds available for
the rest of that quarter or for the rest of
the year, depending on the report.
E-3
-------
EXHIBIT A
Figure 1
PROTECTION
BKUVTCTNO ACCOUtmNO OFFICE!]
n
E
^v^ I
0
11
G
COMHJTUl
CKiTEll
IBM 370
w
A
8
H.
DC
L
A
B
n
HOT'S
ATI, iH ACCCKJHTina OFF10KO AIlE UNKEH 'W 'J!IB COHK1THI Cni'POKT CENTER THRCDail IllMOTK
TLUMIIJAIfl FOll IIIHJT, UIDATE, AUU nrailliVAI, OF FJHAIKJTAI, RKCX)UDS AIID REIOWTD.
-------
Figure 2 SCOPS 0? ^FA'S ACCCOSTEIG SYSTEM
SUJPCST
LS7EZ2
330C3S3
DCCU3-E2TS
JU3DS
MA3AG2SIT
MWBKMMM*
J
4
•
/*»
<-».
MHMV^BM*
X
>-»
^
PROGRAM
HZPCHTS
| X, *" -^ ^-<-Vl
1 irA ! 1 —"A |
I CCinr.i.CTS ! i GHAZT^S • ;
i sTST7*-! i i s^sr^* i
n *^ * **
^
T* •-
~rc
» ^— ^-
./I
I
?:£:E-3!
-------
FMS will accommodate many dif-
ferent "pots" of money. In the aggregate,
all commitments and obligations are
tracked against the allowance holders'
funds to provide status reporting at that
level. However, an allowance holder, such
as a Regional Administrator, may elect to
sub-allocate his funds down to Division
level, or even lower to, say, project level.
These types of sub-allocations are all
entered through the local finance office.
The SPUR package could then pro-
vide reporting of fund availability at any
designated level, whether it be organiza-
tional or project-based.
All spending transactions which oc-
cur in the agency must utilize "account"
numbers assigned to each organization.
Each individual in the Agency must also
be assigned an account number. The
account number is a 10-character classifi-
cation code assigned to a document which,
through a table look-up, will proliferate
into various types of accounting data.
Other accounting information is also
coded on the documents and entered into
the system, but it is the account code that
determines who and what will be charged.
Figure 3 shows the basic structure of the
account number.
It is the account number that pro-
vides the link between the organizational
structure in the Agency and the program-
budget structure. Spending actions not
only impact against an organization's
funds, (e.g., allowance holder, division,
branch) but most provide data identifiable
to the Agency's programs. In this way, we
can ascertain the total monies spent on a
particular program element, such as
wastewater treatment facility construc-
tion or in the aggregate for a media, such
as water. The account number will
uniquely contain the last three positions
of a program element. This provides for a
direct link with the Agency's six-charac-
ter program/budget code; it is this six-
character code which is seen in most
financial reports. Figure 4 provides a look
at the relationship between the account
number and the program/budget and or-
ganizational structure of the Agency.
Also depicted is the Document Control
Number (DCN). This may be thought of as
an extension of the Account Number and
provides the link between the commit-
ment and obligation of funds.
In addition to the program, organiza-
tion, and accounting codes identified on
reports, our SPUR package provides
almost all the descriptive information
associated with these codes. This is
accomplished through table look-up which
relates the proper nomenclature to the
data elements in the master files. This
table, known as our Master Code Descrip-
tor File (MCDF), serves as an edit to
ensure that all account numbers and
object class codes are entered properly
into the system. The MCDF is comprised
of many tables which serve many pur-
poses. Figure 5 illustrates this table.
Generally, financial reporting may be
accomplished in two ways; the first is
through our standard reports library. The
second is through the mechanism of the
SPUR package. The former is accom-
plished by merely inserting one or more
control cards in the job control deck
provided to each office. Each card would
contain the type of report desired such as
FMO-3, AHM-1, etc. All of the specified
reports would follow, one after the other,
using only one job submission. SPUR, on
the other hand, would be used when a
specific local reporting need could not be
accommodated through the standard
library. For these reports, one would
determine information desired, sequence
of the report, totals, title, organization
type, and key in the specifications (state-
ments), as illustrated in the SPUR manual.
These SPUR "statements" are also
inserted into a job control deck which has
been provided to the accounting office.
There are basically three types of
reports which are most commonly
retrieved from the system; namely, Ac-
count Office reports, Organizational (Di-
visional level, Allowance Holder level)
-------
Figure 3 ENVIRONMENTAL PROTECTION AOEHCY
ACCOUNTING SYSTEMS D123IGN
ACCOUNT NUMBER
LOCAL
COMMON CODING
2
" "
-i
0
10
RECORD W) OH nOCUMQITU AMD CONTAINED III COMIUTER LOOKUP TABLES
PROGRAM ELEMENT CODE -DUJCRKET 3 DIGIT CODE vniicii TIEO ACCOUNT HUHBER TO AdENCY'o PROCJUA?!
IUDG&T
DOCUMEIIT CO'ITROL NUMBER - tti-ii upfco-ic spuioiira ACTIONS TO nit: AII/RC DOCHMKMT coniwoi, RicnTan
OOLIGATIOi! POCUMENT NUMBER - nmmvi w IIIOJECIB IN aim CCUS'IIUJCTEOH aRAuaa
-------
Figured UXill JUT i>
iLUmTlATIOH OF HOW THE AOClXHl'fTHd flYOTFl.| "ntlliai" THE OIUIAIUSSATIOH IWUCWIIR MI 111 TUB rilUlUAJI uv.
THROUGH THE HUHDEirnitl HYI5'"
(
A
D
M
I
H
I
T
l\
A
T
0
H
f
ORGANIZATION
u
T
A
V
F
0
F
F
1
C
E
3
"F
0
S
T
A
D
M
B
E
P
A
B
0
T
A
D
H
{fj^
A
B
0
HOLDERS
DIVIS10II, JAJJ,
fil'Ef.TAr, OFFICE/
JJUli-OHdAMTZATION
(BRANCH, ETC)
li-
ft
a
i
0
N
B
=»=
=^
/
/
A
/
^
/,
/ ^
^^^
JC^-
/
/
/
-cy-l^
POU.
1
2
3
If
ACCOUNT "\^<^x=
NUMIH'31 $Lc=«^
B. 'f
IDENHFIEa
FISCAL YEAH
PROCJRAM
ELEHMJT V
8l'3i£AL \
miMER \
i) ALI/)WANCE
6 -^ HOLDFJl \
/RE3POHSIBIMTJT \
•^ ' CENTLM
yf LEGISLATIVE
/ AU'illORIZATIOH
10 ,\
IJOCAL OPTION v
^ A-TA
/ 1) |K
DOCUMI'JIT CONTROL NO.
y
2^
it
5
6
^ INITEATING
1 ORC5ANTZATION
CPECIAL IDEWTIFIERU
SHU AT,
NUMBER
— ,_ /•i/'\i i f i > n r'ti
COUIi TL.I\
FOR 1-JAC'H
flOfSRAM/iHjnr.ia1\
r.TRUCTUItH )
1 APPROPRIATION
o
JDC
iET
AOTJ VI' TV
,, f.Un- ACTIVITY
3
^ UNIQUE
5 TO EACH
V6 HIOGIIAH
ELEMENT
E
L
H
E
N
T
\J
7 ALTX3WANCE
0 HOLD1CH
S
U
E
L
E
M
E
N
T
RIOJECT
(ACCOUNT HUMDER)
-------
Figure 5
MASTER CODP: DESCRIPTOR FILE
EXHIUIT E
1)1 (IK BTORAriE
DEVICE
ACCT.
01 NO.
do)
APPRO.
SYMBOL
(10)
PROGRAM
ELEMtHT
(6)
01
ORAI
COD!
3~
IIC
(11)
NATIONAL
PROGRAM
MANAGER (2)
PROGRAM
IDENT
(3)
ALLOW-
ANCE
(5)
A'M
TITLE
(23)
02
ALLOWAHCB
ALLfMANCE HOiDHl
TI'IT.E(29)
03
BUDGET
ACTIV['i"/(3)
ACTIVITY
T['fLE(3l)
PROGRAM ELl'3-IKtlT
SERIAL NUMBER(3)
1HOG3A-M
PROflRAM
ELfcMEHT
6 j MAJOR AND a
OBJECT
OBJECT CIAS3
ACCOUNT! H«
roi»T(2)___
ACCD'-JHTIHG POIHT
l'tTr.E(2b)'
00
APIMOPRIATfOH
APPROPRIATION
09
NATIONAL
IlfiTlOUAI,
_MA]i AG131 TITI.E(3Q)
10
GEIJERAL LHXIHl
ACCOUWT IJUMHI'IH
('')
GKNtRAL LI-JDGFJl
ACCOUNT TITLE(30)
PROGRAM" ELiilJEIlT
TITI,E(32)
-------
reports, and Agency level reports. There
are, however, many reports which are
generated on a recurring basis which do
not necessarily fall into the types men-
tioned above. These could fall into the
category of Detail Payroll reports,
General Ledger reports, Subsidiary Ac-
counting reports, or selective reports
which may cross organizational lines.
This discussion will concentrate only on
the first three types.
Accounting Office Reports reflect
only that data which is entered by a
particular accounting office. If that
accounting office happens to be Region I
and they entered transactions that
affectedthe funds of another Region, that
data would still be reflected as a
transaction of Region I. Normally,
accounting office reports are separate job
submissions; however, input and diagnostic
reporting is spontaneously generated
during the update cycle.
Organizational Reports generators
automatically consolidate several
separate files in order to provide total
inforamtion relative to a particular orga-
nization. Let us assume the Allowance
Holder in Region I desired a report
reflecting all charges (nationwide) affect-
ing his funds. The report generator would
then provide payroll information and
selected data from each Region pertaining
to those accounts assigned to Region I.
Since the system must accommodate any
office charging against the funds of
another office, this is a crucial feature of
organization reporting.
Agency-Level reports are generated
by Headquarters for Agency management
and for external reporting requirements.
On a monthly basis, all accounting office
master files, payroll files, plus budget and
planning data are merged and summarized
for this purpose.
There is a lot of planning that we
have to do in finance. I would like to
highlight a few areas that I thought would
be appropriate to this. The first is GAO
Systems Design Implimentaiton. The
Financial Management Division has
received formal approval of its Account-
ing Systems Design from the General
Accounting Office. There are parts of
that design package which must be imple-
mented in the near future. Cost and
Accrual Accounting will have the greatest
impact on FMS. At present, this Agency
is not involved in cost accounting as such
either on the input side or on the report-
ing side. Determining management needs
in this area, planning the guidelines for
input, determining reporting require-
ments, designing, programming, and im-
plementing this facet of our financial
management process may in itself require
two to three man-years of effort.
A second area deals with improve-
ments in the SPUR package. We are
presently loking at a two-phased enhance-
ment of SPUR capabilities. This will be
accomplished by two contracts. The
present contract will provide for the
batching of SPUR requests, a finer break-
down of data element fields, greater
select capabilities of the "LIMIT" state-
ment, and some cosmetic changes. The
second contract will primarily provide for
the ability to calculate percentages. In
addition to improving SPUR, we intend to
make it available to the Agency and
publicize its applicability government-
wide. SPUR can be geared toward any
type of file through the proper application
of the SPUR dictionary.
FMD will be incorporating on-line
techniques into the FMS. One of our on-
line applications will be to provide for
automatic generation of payment
schedules related to grants. Payment
schedules are now typed on OCR sheets
and forwarded to Treasury. With the
assignment of an IRS identification num-
ber to each grantee, on-line retrieval of
the grantees' address and other indicative
data is possible. The data would be
generated on Magtape and forwarded to
the proper Treasury Disbursing Center.
We will also be analyzing on-line tech-
niques for other uses in the FMS, such as
job submissions, analysis of documents,
etc.
E-5
-------
FMD will also be looking at distribu-
tive processing techniques for the regions
and labs. Providing "pre-edits" in the
field would be a probability. Transmission
of accounting data from the mini's to the
Headquarter's facility would be a by-
product of this process.
Presently under consideration is a
training session to provide an analysis of
the FMS and the accounting office master
files. There have been numerous requests
for "obligation" tapes by managers in both
regions and labs. We are presently explor-
ing the feasibility of providing this data.
However, until there is a complete under-
standing as to the structure and data
elements contained in your master files,
this "obligaiton" data could be meaning-
less. Many managers have raised the issue
of Agency systems' integration. This
office is well aware of the many benefits
which may be derived with systems inte-
gration. There are, however, stipulations
which cannot be ignored: common input
with common edits would be one; striving
for consistency of prior year data is
another; and timing requirements of the
various systems is a third. We are
presently looking at some type of an
interface between CICS and FMS for
year-end reporting of commitment and
obligation data. The issues raised above,
however, must be resolved before
managers could begin merging data in the
field even if FMS tapes were provided for
this purpose.
Regarding Zero-Base Budgeting
techniques, there will probably be new
structures emerging in the very near
future which would consolidate the pres-
ent program, budgeting and accounting
structure into "Decision Units". FMD
must participate in the formulation of this
structure and equip the FMS to handle it
accordingly.
Lastly is the development of
methodology to reduce manpower aspects
of the financial management workload.
The FMS must continually be in a
development mode in order to provide new
and better techniques through automation
which would reduce the operational work-
load in the accounting offices. Payment
vouchers of all types have been on the
rise. The Agency will be looking more and
more at contracting out. Each contract
can produce a multitude of payment
vouchers. It is important, therefore, that
automation play a key role in controlling
the ever-increasing workload of the
finance office.
E-6
-------
QUESTIONS AND ANSWERS
Dennis Schur:
Alan Kaplan:
Al Pines:
I have a few comments. I would agree with Mike that the capabilities
that are available to us in SPUR has made a world of difference in the
utility of the Financial Management System. Our only gripe, if you can
call it a gripe, is that we would like very much to see the Financial
Management System moved to a computer utility such as WCC or,
perhaps, NCC. This would alleviate a lot of frustration that we have in
the field. I did not hear that mentioned in your long-range plan, but I
understand it is being arranged.
Presently we are negotiating such an arrangement, but I cannot and will
not commit to a time frame. Kent is our representative. He is working
with COMNET and Willis, and is looking at what will be a phased-in
arrangement of certain of our subsystems.
You spoke a lot about the accessibility of this system to the field. From
ORD's point of view, it is of considerable interest to us that the field, in
this case, does not include ORD laboratories. This question of
accessibility is one which has been of considerable interest to us. We
made a large commitment about a year ago to use the ADP finance
system as our own internal management system for our finances, our
program managers, laboratories directors, etc. We have done a lot of
work and it has been very, very productive. We designed special reports
and developed special mechanisms to allow our labs to receive those
reports. We have even experimented with our laboratory inputing data
for this system. Most everything has gone along very nicely. We are at a
point right now where we are, for all practical purposes, completely
dependent on the Agency finance system for all of our finance
information. Any decisions made in ORD are based on the information in
that system. We still have limited accessibility, particularly since you
people are not on COMNET. That is a very serious consideraiton as far
as we are concerned. Also, we have some serious concerns in terms of
the last item you mentioned, the ability of the finance system to interact
with other agency systems. One thing which has aZways been very
troublesome to us is the fact that we go through a great deal of effort to
rectify information that we have located in various agency systems. The
fact is that we very rarely find that the information from the agency
systems agree. Since the finance system is the starting point for almost
every action that takes place, we always try to make the information in
the finance system as accurate as possible. Then we just hope that, with
a little bit of good luck, the same transactions eventually show up in the
other systems, whether it be GICS, or the Contracts Management
System. The ability of these systems to interact, to check against one
another in some automated fashion is something that is of concern to us,
because we spend a tremendous number of man-hours doing that
manually ourselves right now. Another comment is that you talk about
the ability to track dollars at a lower level than what is issued by the
Agency. That creates some problems for us. We would like very much to
do that. We take advantage of the ability to track our program plan in
terms of what we call the Accomplishment Plan, the basic building block
in our planning process. Because we used that flexibility for tracking
E-7
-------
program plan, it has prohibited us from using that flexibility to also
break down our budget according to our organizational structure below
the laboratory level. To have some additonal flexibility in that area
would be of considerable benefit to us, because it is important to do
both. I must comment that Mike's group has just been fantastic the past
year. Kent Smith has put in a tremendous amount of time and effort for
us. We are exceptionally pleased about how the system is operating. It
is amazing what you can do with a little bit of cooperation and
coordination between offices. Our laboratories have managed to
eliminate a lot of independent systems that they themselves have
developed for internally tracking their money. We hope within the next
year, with a little more progress to be able to eliminate all of them. The
few things I have mentioned are areas of some concern.
Question: The only thing about which I have a question is what is the source of your
commitment for travel?
Answer: Most offices really do not commit travel. They merely obligate it
because travel is something that occurs reasonably soon. Most offices
will commit grants and contracts because of the lag between the
commitment and the obligation. This produces a more accurate picture
of their funds status.
Question: Then, perhaps, what I wanted to ask is the source of obligation rather
than commitment?
Answer: The R.E. initiates the obligation and the Accounting Office writes it into
the system.
Question: I guess my question is not clear. Last year, we asked for an increase in
travel ceiling. In our justification, it said what we had spent. We were
not supported by what the report said. There was some lag there. At the
time, travel money was not obligated until the voucher came through,
rather than on the travel order itself. This is at Headquarters.
Answer: I would say that you may be right. Headquarters has to support many
program offices. Like every other organization in the Agency, their
resources are limited. / guess / understand your point, because I hear it
continuously. Our actions are not getting committed; our items were not
obligated. It is a problem. It may be a problem on both parts. On our
part, perhaps we can organize a little better in our operations office and
with our priorities. Or, it may be a problem in terms of the agency
providing the resources for us to handle all the paper work. The
documentation handled in the office, are not in the same proportion as
the paperwork handled in the regions. The Finance Office really should
have more resources in our operations shop, in terms of the proportion of
individuals supporting Headquarters decisions.
Question: It is a shortcut then not to use travel order?
E-8
-------
Answer:
Question:
Answer:
Many times they win, but that is not necessarily true. They do obligate
travel. In many cases the obligating document or the travel authoriza-
tion is hung up somewhere or never even reaches the Finance Office. I
will say this: we have found that in many cases the program neglected to
forward the travel authorization, but yet the voucher comes through with
no problem. There is money involved there. They will obligate and pay
at the same time. Here again, in defense of our operations shop, there is
a balance that you really have to look at here.
It comes through quickly if the expenses exceed the advance.
Absolutely. It is there right after the trip.
Mary Blakeslee: I have one question. I am concerned about the lack of integration in all
of these management systems, because they all come together. What
kinds of studies have you done? What kinds of coordination among
yourselves are you planning to do to make the process more integrative
than it has been in the past?
Answer:
Well, we have done some analysis, specifically in terms of the GICS and
the Contracts Management systems. There is an awful lot of
inconsistency of data; documents may be coded differently in the
different systems. They may be keypunched differently. The different
systems have different edit criteria. Consequently, the transaction will
fall out of one system but be accepted by another system. We have
homed in on grants in attempt to examine inconsistencies in the manner
in which documents were being coded in the process. What we have done
is attempted time and time again, particularly in the area of construc-
tion grants, to stress the necessity for consistency in coding these
documents. There is a standardized way of coding documents in the
Agency. There is a standard way for coding construction grants. I am
talking about the document number itself. We have written memo after
memo, year after year. We have made strides recently. We have just
recently done an analysis and I believe there was something like 90
percent consistency between our system and the GICS process, in terms
of construction grants. We have not looked at other program grants yet,
but we will. There should be consistency, but there is a lot involved.
There is the time of entry into our system, and the time that the GICS
process has to accept their data. Also, what kinds of edits does GICS
have; What edits do we have? What edits does Contract Management
have? You need standardization of edit criteria, standardization of
input. We are working on it, because this has been a problem since the
beginning, particularly at the end of the year, when Budget is trying to
reconcile commitments from contracts, grants, and financial manage-
ment in order to determine carry-over allowances.
E-9
-------
Resource Management Information System
C. Tom Wolz
Mike told you a little about the
Budget Office. The purpose of the Re-
sources Management Information System
is to support the budget planning and
execution function in Headquarters. It
contains all of the data on the planned
positions and funding, except the funds for
waste treatment construction grants.
During the fiscal year, we cover many
phases of the process. For example,
during Fiscal Year 1978, we will be
updating monthly the 1978 operating plans
and issuing advice of allowances. This
information is also fed into the financial
management system. It provides a basis
for authorizations in the accounting sys-
tem. At the same time, back in
September, we submitted the 1979 budget
to OMB. About two weeks ago, we
received the pass back, the mark-up from
OMB, which is in the process of being
appealed because of some switches in
funds from one area to another. Once the
appeals are resolved, the President's
Budget will be developed. Then we will
have House and Senate actions and final
action. Along about February or March,
we will develop a target for the 1979
operating plan. The operating plans are
then prepared on an allowance holder
basis, undergo reviews, and hopefully, will
be approved in September or earlier. Also
along about February or March, we will be
issuing the targets for the 1980 budget.
One of the objectives of the planning
system this next year is to have the
allowance holder develop their 1979
operating plan and the 1980 budget plan
simultaneously. These have been separate
in the past. Of course, as most everybody
knows, the past 1979 Agency budget was
developed on the zero-based budgeting
process, which gives us another crosswalk.
Over the past several years, we have
changed program structure to some extent
almost every year. This creates the need
for crosswalking program elements from
one year to the next, splitting them,
consolidating, and so on. Now we have a
decision unit structure under the zero-
based budget. The program budget
structure provides the framework for dis-
tribution of resources. We have structure
codes for sources of funds which identify
the year in which the funds were appro-
priated, such as the new obligation
authority for the current year, or carry-
over funds. A single character appropria-
tion code, a single character media code,
and a single character sub-activity code,
define the budget structure. We have a
three digit program element code, which
is a unique number. We started with 001
and are up to about 770. At the end of
Fiscal year 1977, last September, there
were about 250 of these elements in use;
about 100 of them were used by regions.
The next break is an organization break by
allowance holder. Then we have the
appropriation authorization code which
identifies the section of law that limits
the funds that can be appropriated or
used. We identify data by object class
groups in the resource management infor-
mation system. The chart on the program
structure covers the basic tables. We also
have some edit tables, description tables,
report titles and so forth. These tables
are updated manually. The master data
file is updated through a batch transaction
edit and update program. When the file is
updated, all of the update transactions go
into a master transaction history tape
which allows us to produce reports
showing the changes by allowance holder,
by appropriation, or by summary of
changes between media. This is somewhat
similar to that first bar chart that I had,
except it is laid out a little differently.
We start with the zero base and appropri-
ation budget plan, we develop the phases
as indicated, and we produce the target.
The targets are given to the allowance
holders and the assistant administrators.
They submit their proposed plans which
are input into the computer. Comparison
reports are made of the proposed plans
with the targets. These are reviewed by
E-10
-------
the program analysis division and the
Assistant Administrator for their
respected program area. As we move
toward the operating plan again, the
targets for the operating plan are sent out
and the proposed plan is sent in. Reports
comparing these with the targets are
made and go through the review of the
operating plan. When the plan is
approved, we go into the monthly main-
tenance of the operating plan. We also
produce various comparisons, such as
comparisions of distribution of resources
between regions and within regions. We
also produce the Federal pay raise calcu-
lations based on the positions that are in
the plan, so it is important that the
allowance holders maintain plans.
We tie into DIPS to obtain personnel
costs and staffing plans. Mike mentioned
that personnel actions are supposed to
have a fixed account number. We use the
fixed account number to identify where
the person is located in the program
structure. Through this, we produce
reports to back up budget submission to
OMB and the Congress. The Deputy
Assistant Administrator for Resources
Management plans to combine the devel-
opment of the 1979 operating plan and the
1980 budget plan and to resolve a lot of
the differences in the structure between
the zero-based budget and the program
element structure. In the past, the
resource management information system
has been exclusively a Headquarters
operation. I think in this next go-around,
the regions will be inputting the data into
the computer and we will pick it up that
way.
E-ll
-------
QUESTIONS AND ANSWERS
Comment: / do not have any real questions but I do have one comment. Having
worked on the ZBB process at Headquarters and knowing how it wiZZ be
implemented in the future, I want to stress that the RMIS is one system
upon which we really depend to provide us with accurate data on the
Agency's resources and where they are. It is used for projecting the
budget.
f
Question: I do have one question, something about which I am curious more than
anything else, and that is, why is it necessary that we update the
information in the agencies RMIS system by object class every single
month? If it is supposed to be a plan, why can it not stand as a plan and
be compared at points and time, during the year maybe twice, three, or
four times and in each quarter—to actual expenditure? Our maintenance
with the RMIS system is nothing more than an attempt to keep our plan
chasing after our actual so that the two match one another when we get
to the end of the fiscal year. We have now gone through some efforts
with the financial management division. We are using separate target
tracking in their system so that we can compare plans against the
changes that we make in those plans during the course of the year. We
find this to be very helpful; we know how well we are actually planning.
I myself, personally, do not understand the necessities of actually
updating the RMIS every single month by object class.
Comment: / think a Zot of money is saved by having an Agency Financial
Management System. It has come a long way in the years that I have
been with the Agency. We need some type of ZBB system. It ought to be
number one priority. Number two priority should be distributive
processing techniques. Number three, if we have the record lay-outs, we
can get by without SPUR.
E-12
-------
THE PERSONNEL MANAGEMENT INFORMATION SYSTEM
Michael Platt
The time allowance is 20 minutes to
discuss a problem in this Agency that is
very large in magnitude. Rather than talk
about the construction of the past system,
the current system, and what we have
planned for the personnel system, I will
discuss basic features within the past
system prior to March of this year. I will
also discuss what actions we have taken to
modify this system to its current state as
of this week. It has been in tremendous
flux for the last 11 months. Additionally,
I will discuss the actions that we have
taken during this year to try and improve
the system by coming up with a new
design. The problems concern things like
whether or not an organization may be
moved from one place to another. As
systems manager of this system, we have
not been able to have various parties
address themselves to some of the pro-
blems. We are finally getting some of
those problems addressed. I will also talk
about the components of your system in
terms of the computer system. Most of
the people in this room are not direct
users of the personnel system. Many of
the people in the room, however, support
the direct users of the personnel system.
Prior to March of 1977, for approximately
3& years, the system was basically a
reporting system, consisting of approxi-
mately 35 or 40 programs which ran
against sequential files that were supplied
to the system on a bi-weekly basis from
the DIPS payroll personnel system at
Department of Interior. Additionally, the
edit portion of the personnel and,
partially, payroll transactions were pro-
cessed not at the Department of Interior,
but off-site at the same installation where
the personnel system was being processed
at Optimum Systems. Every two weeks at
the end of the pay period, tapes
mysteriously did not make it to Interior.
Eventually by Thursday morning, they
would finally get there, either intact, or
not intact. Transacitons would then go
into the system. Studies found that the
object programs to do edits were approxi-
mately 9 to 12 months behind the object
program which was actually running
against accepted transactions when they
finally got to Interior. Software problems
were enormous. The accountability within
the OSI edit process was impossible, and
due to that fact, the agency recognized an
effort to directly input, through 1C
remotes, into Interior, transactions, then
do the physical edits with the programs
that physically resided in Interior. Let
the DIPS people maintain their own pro-
grams. That, in fact, did happen this
year.
One of the major problems with this
system in the past has been the fact that
the individual that administered this sys-
tem, was not a systems person. He was a
personnel individual. When requests came
for data, various reports, various statis-
tics, the answer was generally, "It is not
available in the system." Unfortunately,
it was available in many cases. The
Number One problem faced when I came
into this job was getting back user confi-
dence in the capabilities of the group that
was running that system. That has not
been an easy task. We feel, however, that
it has occurred to a reasonable degree. I
will explain the specifics. Last year, the
general attitude of most of the users was
that the data was no good. These users
included personnel officers in the field
who, in fact, were responsible for
maintaining the data. They did not want
to use the personnel system. It was too
restrictive. Consequently, most of the
regions wrote their own. Many dollars
have been spent agency-wide on manual
systems that are personnel in nature;
many dollars have been spent and much
duplication of effort has gone into writing
personnel computer systems. The main
thrust of what we have attempted to do in
the last year is to clean up our act, to get
E-13
-------
user support, to have users' confidence
restored, and to create a better edit
process so that transactions are updated
on a timely basis. Those actions include
the following: On a three- to four-week
basis, we have met with Interior since
January 4th and discussed every problem
that existed with the direct input process
and any other report, output, or process-
ing that they performed as part of the
payroll system. Second, we have reviewed
all testing of modifications to any of
those processes. To this point, we have
managed to get all of the training runs
modified; the microfiche in order; we
have cut out approximately 35 percent of
the unused reports and added several that
were required to get our jobs done, within
PMD. We have also informed Interior of
the various items that we would like to
see as additional improvements to the
system. As an example of that type of
improvement, the common account num-
ber was not an editable item, per se, at
the Department of Interior until last
week. It is now a mandatory edit item on
any new accession into the system or any
change to that account number. Conse-
quently, within three to four pay periods
after financial management cleans up all
of the bad account numbers, we anticipate
having no bad common account numbers
ever entering the system. Therefore, that
problem will go away. That type of a
problem has been extremely time-con-
suming in terms of trying to find out
where the basic problem occurs. We have
got many problems of that nature which
we have solved. While they are very
minor in nature, they are very time-
consuming. They did, in fact, as a group,
effect the performance of the system in
terms of report accuracy, in terms of
understanding the data by a person or a
coding clerk in the field, and in terms of
effectiveness of a personnel officer
understanding a report. Those are the
types of things that we regret. In April
1977, we did an implementation on a
three division basis, with MIDSD,
Financial Management, and the Personnel
Management Division, the T and A
process, payroll EOD's and also personnel
edit as direct input into Interior. These
included training sessions, not only for
personnel coding clerks because they had
not had enough training in the past, but
also for those within data processing in
each of the locations so that the personnel
people had someone to whom they could
go to help run the edit for them, know
how to interface with Interior, etc. This
was a main requirement as far as the
system was concerned. The types of
benefits that we have derived from the
direct input process is that we have no
duplicate records now going into the
Interior process. We have managed to get
rid of approximately 95 percent of the
major software and tape handling pro-
blems. We have, in fact, given the
regional personnel offices 10 opportunities
to edit their data against four in the old
system. The interface with the personnel
input and the financial data is much more
significant and much more accurate.
We have edit criteria being checked.
We have point of entry edits being per-
formed on the transactions. Because of
the fact that we now have real editing
being performed on the data on a daily
basis with direct feedback back to each
regional office that next morning, the
accuracy of the data going in is much
better than it has ever been. The main
point is we do not have more than about
five or six percent of the transaction not
making it within a pay period. This has
caused a great deal of grief to be taken
off of the personnel offices. By no means
do I stand up here and tell you that
everything is perfect with the direct-input
process. It is not. We feel that the
necessity of discussing how things are
going with Interior will continue on an
ongoing basis. We are still asking for
modifications and corrections to be made
to that process. The other types of steps
to be taken this year include going
through all 1600 data sets that were the
results of seven years of programming,
examining them, finding out what they
were really attempting to count and list,
etc. We narrowed it down to 250
convertible data sets, then corrected,
E-14
-------
modified, and replaced many of the pro-
grams. As an example of what I mean,
there were 27 turnover reports, none of
which counted the items the same way.
All 27 went to different users. None of
them were correct either. They forgot to
take into account that separations were
physically taken off the file from Interior
at the beginning of the year. We have
now modified all of the reports in such a
way that they are now correctly counting
the information as stated on the report.
There will no longer be any turnover
reports going to OMB showing eight per-
cent. It happens to be about 26 percent
EPA-wide. In that conversion process at
COMNET, we did, in fact, put up alpha
procedures. Every field office has the
ability to access through very simple
instructions which have supplied to them.
They may run any of the nine national
reports, and many other reports as well.
We have supplied a two-inch thick docu-
ment of all the documentation within this
system that is available to the reigons
with file lay-outs, with an understanding
of what the various procedures mean, and
an easy-to-use selection and reporter
capability that they may or may not want
to use. All of these books were supplied
to personnel offices and the systems'
offices in order to promote better
discussion or rapport between the two.
This has seemed to have been a problem in
the past. Additionally, we looked at the
bi-weekly, monthly, quarterly, and year-
end processes. We discussed the reports
that were going to various users as to
context, i.e., whether they needed them
or not. We had revamped the entire
production cycle and gotten rid of most of
the waste. Where we have not gotten ride
of waste, it is because somebody still
wants to hang on to a report that they do
not really need. All minority EEO Affir-
mative Action reports have been reviewed
and are in the process of being rewritten.
They are approximately 50 percent com-
plete. Once they are completely rewrit-
ten they will be made available to all
regional offices, through the same
mechanism or a similar mechanism as all
of the national reports. Additionally, we
have satisfied approximately 700 ad hoc
reporting requests within the last 11
months. The ad hoc reporting request
requirements are absolutely astronomical
at this time. They have been for the last
several years. The key problem with most
of the ad hoc report requests is that they
were always required yesterday.
Fortunately, we have a little larger staff
than we did a year ago, and we have most
of the requirements fairly well planned.
Unfortunately, it is a tremendous drain on
personnel and manpower. One of the
things that we are stressing and have
stressed is a need for a new system,
because the fact that 700 and some odd
report requests in a given year indicate
that the current system is not in fact
doing what the users want it to do. It is
not meeting the requirements.
Additionally, the current system is not
designed to do anything but provide
rosters of people on your payroll. It is not
a management information tool, not a
trend analysis tool, not a training tool.
The training system is inherent within the
DIPS system. It has nothing to do with
the personnel system as of this moment.
An Index Systems Study produced in
February indicated a definite need for
management information reports and a
training system included in an excutive
development system. We have not taken
everything in the Index System Study as
the verbatim requirements of the new
Personnel Management Information Sys-
tem currently under design. What we
have done instead is look reasonably at
resources and the scope of the job we
intend to do. We have interviewed all but
two regions or labs. We have interviewed
a minimum of 75 other officials and users
within this system, within Headquarters,
and in the field. We have looked at every
regional system of which we could get our
hands on the specs. We have looked at the
thrust, the requirements, and what the
agency really needs for an agency-wide
Personnel Management Informat:on
System. The basic answer keeps coming
back: we need a position control system.
We need to be able to track vacancies. If
you are not a personnel type, you may not
E-15
-------
know what all that means. The personnel
people do know what it means, and they
are vehement about having a system that
will give them information that their
managers can use. The current system
does not do that. There are time lag
problems. There are transaction pro-
blems. There are no vacancy records
maintained in the current system. The
new system which has, at this moment, a
preliminary design draft has been sent out
to many people in the agency for review.
It is approximately four and one half
inches thick, but does not cover all of the
areas in the system that we anticipate
covering. The design draft does, in fact,
show the user what type of output will be
available in the new system. It asks the
user to comment on what he would like to
have, what he wants. A portion of the
design draft, for any of you who may have
read it or are in the process of reading it,
is not the design draft on purpose. It
happens to be about the software we will
use, the method we will use, the program-
ming techniques we will use, and the
computer we will use. The reason it is not
in the design draft is that we are still in
the process of studying those questions. A
very, very comprehensive job has been
done by NCC and Univac in order to
benchmark DBM 1100, a data base
management system, to see the relative
cost of that system using a live personnel
file from Interior and get real cost
figures. At the moment, a comparison is
being done of DBM 1100 vs. System 2000.
That does not necessarily mean that we
will, in fact, put the personnel manage-
ment system up under a data base
management system. We are looking at
it, however, very strongly. The only thing
that I can tell you about the draft and
about the new system is to bear with us
for the several months. If you have any
input that we have not yet heard, please
give us a call. We are very interested in
your needs, if they have not been met
within the preliminary draft. Some areas
will not be done in the initial system. We
are not putting an executive development
system on the air, although there are
some people in Headquarters that feel
that is an extremely important thing. We
do not feel that agency-wide it is an
important thing for 400 or 500 people to
be tracked. We are not putting it on the
air because of that. We are, in fact,
looking at a reasonable implementation
time of approximately a year for getting
it on the air. Once it is on the air, we can
build on it and add to it. We are
attempting to take an open-ended file
approach, and an open-ended program
approach.
E-16
-------
QUESTIONS AND ANSWERS
Question: Mike, I think you and your staff have come a long way in a very short
time, but I still think you have a long way to go in establishing credibility
in the national personnel system. Most all of us have, over the course of
time, devleoped some kind of system, be it automated or manual, to
perform the position management function and some other related
functions. I think that at each installation there is terrific inertia to
continue to do things the way we have been doing it. You will have to
overcome that. I think you are taking the right approach. They are out
there talking to us. They are finding out what kind of feasibilities we
currently have. They are proposing a very flexible new system. I think
the success or failure of that system will most likely hinge on how it will
be done. The part that you really have not yet addressed. I think that
everybody would, in fact, support the concept of a centralized personnel
system that would provide position management capability, but again, I
think the credibility of the system is going to hinge on training the users
on how the system is implemented and subsequently operated. I would
hope that you would not stop with the design considerations. This is all
the flexibility that we could possibly give you. The same level of the
effort ought to be extended into how you will do it.
Answer: Would you like me to respond to that? Based upon what you have heard
of what we have managed to accomplish in a year, you may realize that
we are very pragmatically motivated towards solving various problems.
The most significant problem is the credibility of the system. Unfortu-
nately, when we embarked on attempting to improve this system it was
not at ground zero. It was about 500 percent below ground zero. We
have seen significant changes of attitudes by your region. We are now
discussing the system instead of being at each other's throat. In terms of
being rational in what we are attempting to create, I think we are. The
reason why that portion is not in the preliminary draft, is not because we
do not want comments and not because we are not interested in your
input. It was because it was not ready within the timeframe to be
delivered. A tremendous push was made in order to get those design
drafts to them in the same conference, so that we could present them
individually with the packages and explain what made up that design
draft. Everyone will have further opportunity to discuss and comment on
the hows, as we perceive them. Just because we perceive them does not
necessarily mean they will be the way we will go. There are many
factors involved in how we implement a system. Many of them have
nothing to do with the right way. In terms of the history, we are going to
attempt to do it the right way. We will attempt all of the things we said
we were going to attempt. I do not know if we will be successful, but we
are going to try.
Question: First of all, I would like to wish you the best of luck. You know there
have been, and I know I have often heard, many comments made about
the Office of Research and Development maintaining systems of its own
which duplicate other systems in the Agency. I thought I might take this
opportunity to make the statement that that really is not true. It is true
that many of our laboratories maintain systems of various kinds for the
E-17
-------
Answer:
Question:
Answer:
Question:
purposes of extracting projects, people, equipment, and so forth and so
on, down the line. To meet the kind of individual requirements of the
laboratory managers, and it may be true that some of those systems are
duplicative, we could, in some areas, depend on other agency-wide
systems to do some of these things for us. In that regard, we have
created a position which I now hold, Managmeent Information Systems
Coordinator for R and D. I now have an MIS coordinator in every one of
the laboratories. We are making some efforts in reviewing all of our
needs to try to see where we can use Agency systems, how we can
interact, how we can eliminate the duplication, within our laboratories,
of devleopmental efforts in these areas. The reason I take this moment
to make that comment is because: First, Mike, I would like to invite you,
urge you and myself to one day get together, discuss your efforts, what
you are planning to do, and come up with the admission that at this point
in time, wide basis is one of personnel position management system. We
have basically done it in order to monitor where our position are and
where the vacancies lie. We also have it for descriptive information. We
certainly are very hopeful that if there is any chance that your system
has what we need or will be able to make it available to our managers on
a timely basis, we would be able to retire the last of our own independent
system.
The only comment to that is that we have recieved a great deal of input
from R&.D, all of the documentation of your current personnel system,
and a great deal of data on types of reports. Yes, we will get together
further.
Is there now a workable file of minority classification coded requests by
Civil Service Commission?
There is a minority code attached to every individual's record. There are
access rights to the data base which was not the case as of March of this
year. All of the minority reports that the civil rights people have
authorized will, in fact, be available to any user for their individual AA
region, lab, or whatever. They have lists of each individual and that
individual's minority file. We can, with the cooperation of civil rights,
print that for any appropriate individual in any reigon, AA, or whatever.
One of the difficult things in trying to administer this system has not
been the software involved, but people making decisions about things
like, can the regions have the minority code because they are asked to
produce all these reports, and they cannot see them? They are not
allowed access to the code, therefore, how are they going to produce the
report? They are supposed to go around and do head counts when they
have a system that can do the job for them. That particular question
took approximately eight weeks. Finally, civil rights authorized
personnel officers to see those minority codes. We are still working on
those types of problems. Mary.
I have two questions for you. One is, who are the current users of your
system in terms of general categories, people or organizations? Along
that line, what kind of information do you provide them now? You have
described the how's of implementing the system. Since I am not a
E-18
-------
Answer:
Question:
Answer:
computer person, I have heard the question asked in computer terms and
answered in computer terms. What do you mean by how that system will
be implemented?
Let me take the first one. The universe of our users are the 14 personnel
officers in the field, along with Headquarters, which we now consider a
personnel office. We do not consider Headquarters vs. the regions. One
of the primary problems had been that, Headquarters was Headquarters
and the regions were somebody else. We are still doing the operations.
The only difference is the volume of data they maintain. Those
personnel officers through directions from management division
directors—from RA's deputy RA's, lab directors, etc.—are requesting
information out of their system of rosters of organization, code runs,
breakdowns of numbers of people in various class series jobs, statistical
information, such as the turnover for permanent individuals and others in
permanent full-time. They want to see things like, who were their
separations for the prior quarter. They want to see a computer-
generated form for performance appraisals. That data is available to
every one of the personnel officers in the field and to Headquarters
personnel offices. It is easily accessible to a non-programmer who, in
fact, has the knowledge to get on the COMNET alpha system.
Additionally, we have approximately 750 special requests a year. These
requests run the gamut from the National Science Foundation doing the
study of the pesticides area which entails approximately 45 various
production runs generated for almost aproximately a year and a half.
Period of time: Every quarter, to Personnel Management Division in
Headquarters. We have approximately eight other systems that take
data from our system on a continuing basis, such as the programs
reporting system, the resources management information system, etc.
The users, by-and-large, can be characterized as anybody who happens to
be a manager in EPA that has a need to know about his personnel, about
the Agency's personnel, about Headquarters' personnel, or a given
region's personnel, or a lab's personnel. The key under which we have
been operating is that we will refuse no one. We will attempt to satisfy
everybody's needs. So far we think that on an ad hoc basis, we have done
that for this year. I do not know if we can continue because the number
of requests keep increasing. As far as the "how" in the design, what we
mean by "how" instead of the "what" is that the "what" is the various
reports. The "how" is techniques, the type of software and programming
that will be done in the new personnel management information system.
The methodology by which we plan on implementing the system, all of
that is not in writing. All of that has not yet been completed. That is
the part of the design draft which is missing. It is also the part upon
which we intend to get further concurrence. In fact, we have to get
further concurrence on the entire design draft, once we have included all
of the comments from everybody in that draft.
Why can we not get a copy of the training file from Interior and put it up
so we can access it?
Because they can not find it half the time to be quite honest with you.
That file is approximately 75,000 records at this time. It has not been
E-19
-------
examined very closeZy as to accuracy. / would venture to say that it is
probably 60 percent accurate. It is probably 80 percent accurate for this
year, but for prior years, it is very inaccurate. It will not get better
unless we do something, and we will in the new system. It is planned as
one of the areas of the new system that will cover each individual's
record. Now we are going to do whatever conversion we need in order to
get that file brought up to the new system.
Question: Let me make a point. Up to this quarter, training data by individual
regions, in terms of reports, was not possible. They were manually put
together. What happened approximately three months ago, Interior
agreed to revamp all of the training reports. You will get your own
reports within three weeks. They are still trying to assimilate 18 boxes
of paper. I was wondering if you could tell me what kind of efforts you
need so far. Where are you planning to go relative to integrating your
system requirements with what is currently available with PMIS and the
Financial Management System? It is of some concern in our region, and I
think it might be in other regions. Systems of this type had to be
developed in a data vacuum when in reality all phases have been
interrelated. To ignore those data bases and the tremendous cost that go
into developing that data seems to be ridiculous. I wonder if you could
just tell me what is going on?
Answer: Basically, we are taking the premise that we have not had anything up to
now. The system which this agency had for six and one half years was in
shambles for all intents and purposes. The systems which you have right
now is only a stopgap method so that we can implement a new system. In
terms of interfacing with that RMIS system, which is in a state of flux
concerning how the ZBB effort will effect it, we are, in fact, interfacing
with it at this moment, in terms of trying to get account numbers
correct in everybody's files. What we are doing is trying to take care of
our area, first, with the knowledge that we interface with other systems,
that we do have an effect on other systems. In terms of input from other
systems, there is none in the personnel system, itself. Where we need to
get input, we will, in fact, build whatever criteria we need to get that
input. Interrelating these systems is a major problem that I would not
tackle as an individual systems manager. I am aware of the problem. I
think the other system managers are as well. I do not think that one
systems manager, or three or four together, could thrust the Agency to
an integrated data base concept. That is a major Agency effort.
Question: Is it worth it, though?
Answer: It may be worth it, but I do not know if we have enough computer power
to handle it all at one time.
E-20
-------
CONTRACTS INFORMATION SYSTEM
Edward McLean
I inherited a system about a year
and a half ago. I don't know anything
about ADP, but my system was designed
by ADP people who did not know a damn
thing about contracts. When the system
was designed, we asked that it be designed
in self-defense, because we have used
these daily calls from the administrator
who wanted to know how many contracts
were issued in the 3rd Congressional
District of Mass. Then we put every
secretary and every contracting officer
looking in the file drawers. We decided
that this was not very good. We got a lot
of people working that way, but not much
information. So, we did ask that a system
be designed; the designer of the system
felt that they had to make the system
meet some criteria. For example, they
decided that they would not leave any
room in our file for more than 10 contract
modifications. We got fixed length files
so that any contracts with more than 10
modifications will not show up. They
decided that we could only have five lines
of financial data. We have as much as 20
lines of DCN's and can numbers, but we
can only show five. As a result, the
largest dollar which shows on our report
may have 15 to 20 lines for counting data
combined in there. This system was
designed basically as a defensive move
and as a management tool for contracts
only. We do over 3,000 contracts a year;
these are not purchase orders, they are
contracts. Any action over $10,000 has to
be a contract, it cannot be a purchase
order. We do 3,000 of those. In each
contract, there are 8 to 10 steps that we
call milestones which must be detailed so
that the manager can look and see how his
contracting officers are doing. What we
do is we produce a report for each
contracting officer showing each action
that he had. When I say each action,
every time one of you sends in a PR for
contract action, it is assigned a number,
an RFP number, no matter whether it
goes out into the street. The number
tracks it. We have 82 data elements that
go into this. We have 1728 characters in
each contract record available to us.
Some of them we never use; in some, we
need more, but every milestone is tracked
until an award is made. Once the award is
made, it (the contract) goes into limbo,
because our job is to issue contracts and
not to do anything else. We do have some
sub-systems such as the CAS, a system
where all the contracts, after they are
awarded go in and sit. If anything happens
to them, we can put some data entries in.
Like if we ever make final payment, we
can put a data entry in our system and
show that the contract has been finished
and paid off. We issue around 100 stan-
dard reports a month; that is 100 standard
reports a month, plus an average of 60
individual ad hoc requests. We do have
enough data elements to give a lot of
contract information to a lot of people.
We can tell any Congressman how many
contracts were issued in his district in
each year, quarter, or at any time, or how
many contracts were awarded in any
region. Anything that we have in the
system we can get out. Now, we did
decide that the system badly needed
overhauling, but the present system could
not be fixed economically, so we had a
feasibility study done to see whether we
could get a new system and mount it on
the mini-computer. The feasibility study
showed that we could mount this complete
system on a mini-computer and have the
mini-computer dedicated to us where we
could get good turnaround. This may have
been one of the few times in a feasibility
study where we decided not to go with it.
There were two reasons. One was the
OPM-ADP action plan which said that we
should move our system to North
Carolina. The other is that I, myself,
knowing nothing about computers, did not
want to be responsible for a POP 11-70,
which is, I think, what they recommended
for our system. I wanted to be able to
blame somebody else when this thing
E-21
-------
broke down. What I have done is get a
system development done by Sigma Data
which developed this new system. Unfor-
tunately, Sigma Data was not awarded the
f ollowon contract. When our CIS contract
came up, they did not make it. Now we
have a new vendor, VITROLABS, a
division of Automation Industries, who
will be the implementer. The new system
will be completely implemented in the
Univac at NCC. I have a target date for
May. I am not saying which year, but my
boss thinks it is this coming May. I have
been learning with this ADP thing that
you never make any definite statements
because they can really get you. My plan
is, before I have this thing running in
North Carolina, I will run it three months
parallel operation. The present system
may be screwed up a bit, but it is running.
Once we can see our way clear that the
system is going, we will swap over. The
system will be variable in length. We did
get a lot of input to it, and we are going
to make a lot of changes. We update the
present system every two weeks. We have
a pre-edit prior to update, then update,
using batch entry. We can inquire of the
system now through alpha and IRS: most
of our minor programs are IRS. We have
four major COBOL programs and 50 IRS
programs, but we can make on-line
inquiries, because we only have two weeks
behind, or maybe even a month behind if
the information does not get into the
system right at update. If it comes in the
next day, it could be a month. One of the
other things we do besides the standard
report, is that when we put out a report
on NSF case studies on R&D contracts, we
direct it on keypunch cards and transfer it
to them. We have an active contracts list
that we publish every six months. It lists
every active contract in the Agency. We
are probably the only outfit in the Agency
that makes any money, because we charge
$25 a throw for the active contract list.
For you all, we have reduced it to $5.
When we get individual requests, we
put them out at remotes; some of our
standard reports are off-line at remotes.
I made the mistake, when I first got into
this job, of seeing if we could eliminate
some of these reports. I sent out a
request to all managers that were getting
reports, asking which ones I could
eliminate, I got back requests for 15 more,
and finally decided that there was no use
in doing that. What I do periodically is
have my people that make the report
distribution not send a report for about
five reporting periods. If I do not hear
anything from them, I just cut it off, and
they do not get any more. I found that
some of our bosses have piles of readouts
on the back of their desks, so that they
can impress people when they come in. I
figure, hell, they could use the same one
for a year; it will not hurt them. It has
been an education for me. I still do not
know much about ADP, but I do know how
the Agency feels about it. I have heard
people stand up here and say that they are
working on assigning numbers to every-
body with whom they do a grant. We have
assigned 3,000 numbers. Every contractor
we have ever contracted has a number,
but no one ever came to me to ask if they
could use our number. I would be glad to
do that. There are six or eight managers
here and there is not one or three of us
who could get together and decide what
information could be in one system. We
all know that there is a heck of a lot of
this information that should be in one
system in order to be able to retrieve it
from us. The fellows who know more
about ADP themselves could put their
finger on it. We all know each problem,
yet we keep going our own ways because
it appears that there is no Agency move-
ment to centralize or, at least, to get a
data base to which all of us can contri-
bute. We do not do nearly as much money
in contracts as we do in grants, but we are
just a drop in the bucket. We did $220
million in contracts last year. It is an
awfully political thing. Everybody wants
to know something about it. It is the type
of information that we give out every day.
I will say that there was a reason
that I was put in charge of this system.
One was because I was its biggest critic as
E-22
-------
a contracting officer. The contracting to do is make it easier. I am still a
officers did all of the input in to it. The contracting officer. My job description,
people who did the input got absolutely though, is manager of the system. I have
nothing from it, so they are reluctant to to input, so I know myself on a daily basis,
input. One of the jobs I have been trying how it is to input to the system.
E-23
-------
QUESTIONS AND ANSWERS
Question:
Answer:
Question:
Answer:
Question:
Answer:
First of all, is the contracts planning system part of the contract
management system?
You hit me in a sore place with that. We have so many planning systems
in this Agency that it is incredible. The contract planning system gets
its information from the Contracts Information System. In other words,
the input we put in is extracted to ran the contracts planning system.
What you are basically saying is that there is very little relationship
between what we put into the system every year for planning purposes
and your system. When will that change and why should we, as managers,
put anything into that system? It does not help us.
Let me say this. One of the reasons I am in the job of managing the
Contract Information System is because -when I was head of the special
projects section for CMD, I criticized the contracts planning system,
because it could not cross feed with your system. Our new system should
be compatible with Financial Managements.
I think the system is, from our point of view, something that
(unintelligible). It means that something has fallen through the cracks
getting to you. We know some of it is not your fault; it is not our fault
either. One observation that some of our people have made is that, in
the tracking system if they could have a date for when it is expected to
hit the (unintelligible). That may be helpful to us. Otherwise, it could
change significantly and it would not show any differently on the report.
There is a couple of things. One is the broad time where nothing is
happening because generally nothing is happening. I trust I am among
friends here. As you know, if you send in a procurement requirement (we
do 3,000 a year and we have roughly 75 people doing this through the
Agency), you can see that each person has a hell of a lot of action, when
it comes in. They do have in contracts a milestone system for all actions
over 100,000. They are now supposed to prepare a milestone chart to go
to each project officer which will give you the milestone. In other
words, if he gets the procurement on November 1st and he expects to
have an RFP out on November 30, he should not have that on the
milestone chart. We talked about having some kind of a milestone chart
within the CIS, but I put the nix on it because it is so hard to get them to
put the basic information in it that I did not think something that could
be used to shoot them down would ever get in there. On that basis, we
can not give you that information, but if you get a report, and it shows
that nothing has happened, you can be sure that nothing has happened, or
the guy that is doing it has not put it in. Since this system is a defensive
system for the contracting officer, it behooves him to get every bit of
information that he does in the milestone because his boss is going to use
it to shoot him if it is not in there. So this is how this system works. If
you do not put it in, the boss takes pot shots.
-------
Question:
Answer:
I think the development of this contract system, probably more than any
other in recent years, has pointed out some of the problems in the
Agency in terms of the lack of coordination in the management system.
It may be a long time—in fact, it may never come about—before the
Agency decides to integrate this management system. Maybe it is not
the right thing to do, maybe it is just too costly. I do not know. A lot of
problems could be resolved, I think, if there was simply more attention
paid in the beginning when the systems are developed. On the part of the
managers, they could coordinate more with one another in terms of
making sure things, such as common terminology is used. There are
people who have tried to use the same kinds of coding in their system.
There has always been a problem between Finance and Budget. They use
slightly different categories in their two systems. We have gone through
a lot of manipulation with financial management to get the reports out
of their systems that are in the same categories as the information that
you put into the MRI5 system. In your system, you had a definition for
commitments which was distinctly different from the definition used in
the Financial Management System. It caused a great deal of concern on
our part in terms of how we interpret that data. Also, you mentioned
that your system was principally one that was put up by contracts
management for their own internal management purposes. That is all
well and good; in fact, I might say that often, if that is your real desire,
you might be better off not giving other people outside your office
information on your system. If you are going to do that, you have to
expect that they will start looking at your system as one to service them.
When they get information from it, they become critical of the
information. We have gone through a lot of man-hours doing manual
comparisons of information in the Contracts Management Information
System and the Financial System. We have found that the two disagree
greatly. That concerns us. If all these systems are not, at one point in
time, combined into one gigantic data base, there could, at least, be
some mechanism to provide some means for these systems to check
against one another automatically. This would see to it that the
information in them, where it is comparable, is consistent. I think is
really something to which you, as managers, ought to try to give some
more consideration. I think it could be done on some automated basis. It
would save a lot of the program offices a lot of time and effort.
/ can't say that I agree with you more. Here again is a point where the
managers can talk among themselves. There has to be, however, a
central coordinator. We use a lot of the same data that the other
systems use; we use a common accounting number. We use the DCN's .
A lot of that type of information is the same. Some of the discrepancies
in dollars occur because the Contract Information System does not track
committed dollars as such. We have them in there, but committed
dollars fluctuate. What our system tracks—/ win go 98 percent
accuracy on this or better—is obligated dollar. I would say that for the
fiscal year 1977 data, we had 86 percent or higher accuracy in obligated
dollars. I expect to see near 100 percent accuracy in obligated dollars for
fiscal 1978. That is for the present system. We were having our
problems with matters of input. Of course, it was a crossfeeding of the
systems' everybody speaks in a little bit different language. The thing
E-25
-------
that really counts in the end is how many dollars have been obligated.
All of you who send your money forward as commitment to us would like
to have it reconciled after our obligation has been made. A good
percentage of the time we obligate less money than we commit. I
wanted Mike Platt to tell me how he reconciles that and puts that
unobligated part of the commitment back to the users. I think that is a
problem. I do think it will be continuing problem until there is some type
of integration and understanding in what obligation, commitment, and
these different terms are among each of us.
Question: Our particular Region never seems to have very many funds for
contracts, so I do not think I can comment about the contracts
management system. I would like, however, to tell you, Ed, that you are
picking up the ADP job very fast. Good luck to you with your new
system.
E-26
-------
PERSONAL PROPERTY SYSTEMS
Carlton Woodell
I am not an ADP person, either. I
believe I was selected because the system
is simple, I was probably the biggest
simpleton available at the time. That is
why they gave it to me. I would like to
begin with a little synopsis of the back-
ground on this system.
The Personal Property Accounting
System is mandated by Sec 202(b), the
Federal Property and Administrative Ser-
vices Act of 1949, as amended (10 USC
483) and Sec 2, Public Law 84-863 (31 USC
66a(c)). The system is decentralized to
the 10 EPA Regions; O.A., Cincinnati;
O.A., Research Triangle Park; ERL, Ada;
MVEL, Ann Arbor; ERL, Corvallis;
N.E.I.C., Denver; EMSL, Las Vegas,
Nevada; and Headquarters, Washington,
D.C. EPA-MIDSD is also a user. All of
these users may input or retrieve data
simultaneously. Additionally, each user
may edit his input data at any time.
The system originally was installed
by Sigma Data on the NIH computer at a
total cost of slightly over $14,000, which
is unbelievable at today's prices. A record
of that is still on file in Frank Bullock's
office in ADP. Originally, the entire file
at NCC was written in IRS, with source
language and retrieval language. We were
selected to be the guinea pigs to transfer
over to the Optimum Systems Incor-
porated IBM 370E. We did convert
virtually all the retrieval to IRS; the
source programs were put in COBOL.
Along about the early part of this
year, they were looking for a simpleton
again, and guess who they found. I was
approached and asked if I would volunteer
to put this system on the NCC UNIVAC. I
will be serious and make one statement. I
think it was the smartest thing we could
do. On July 1, 1977, the EPA Personal
Property Accounting System was con-
verted from an IBM 370 Computer con-
tracted from Optimum Systems, Inc.,
Rockville, Maryland, to the Government-
owned UNIVAC 1110 located at the
National Computer Center, Research
Triangle Park, North Carolina. The file
definitions, per COBOL requirements, are:
Recording mode is SDF; block contains 50
records; each record contains 340
characters. Files, except for tape files
and PPS-backup files, reside on a dis-
mountable disk pack. Working files, e.g.,
special reports programs, are assigned to
"free" space. All files are catalogued.
The system, at present, contains
approximately 70,000 records, including
owned and leased property. It is updated
after 4:30 p.m. on the third working
Wednesday of each month. This run
collects the transactions from the user's
input files into a single input file and
passes that data through an edit program.
The valid output data from the edit
program is used to update the master file
on disk and tapes. Error reports gen-
erated by the program are identified by
user and forwarded for correction and re-
submission. This program also produces
the required property management reports
plus a summary of dollar balances of
owned personal property "charged to"
each user for monthly posting in the
general ledger maintained by the EPA
Financial Management Division. Concur-
rently a "split" program is executed which
divides the 70,000 records into four files,
consisting of data relating to specific
users. Thus, users only "read" about
15,000-20,000 records instead of the entire
70,000 in the master file. The Property
and Supply Management Section does pro-
duce reports on an Agency-wide basis
using the entire 70,000 records data base.
We have had bugs.
Initially, after conversion to the
UNIVAC 1110, all reports were generated
by the use of "canned" SCORE modules.
This served well enough for basic routine
E-27
-------
reports, but severely limited our flexi-
bility for retrieving multiple data without
requiring a special programming effort by
the contractor which, in turn, was time
consuming and not entirely satisfactory.
Several conferences were held with NCC
and contractor personnel which resulted in
our being permitted to use the Inquiry and
Reporting System for data retrieval. It
was made clear, however, that this
language was not completely "debugged"
in the UNIVAC 1110.
There are several versions of IRS
available viathe UNIVAC. The latest
being TSSMS*IRSSYS/V1RO. We are using
version 7 (IRSSYS7) and, except for cer-
tain functions, have found it acceptable.
Any "bugs" are reported to the User
Support Service, NCC, to be corrected.
There are 27 data elements entered
into the personal property master file.
Each data element ranges in size from 1
to 44 characters. A data element is
merely one piece of information needed
by managers at various levels for
different reasons. Reports may be
produced for any or all of these data
elements. For example, the Report to
Congress by the Comptroller General of
the United States, dated May 3, 1976, on
"the Need for Better Management and
Control over Scientific Equipment" was
critical of the need for better equipment
use through "pooling and sharing." As a
result, a new two -character data element
was added to the system entitled
"USAGE". Data entered into this data
element indicates to managers the fre-
quency of use by a numeric entry plus an
alphabetical character explaining why the
item is/is not idle. Thus, an entry of 4D
would mean that the item is used only
once a month and that it is sophisticated
instrumentation requiring highly skilled
operators, 7K would mean that the item
has been used one time only and is being
held for priority use in field studies, but
can be used in the interim.
Another report useful for personnel
in the budgeting area is a listing of all
items scheduled for replacement during a
specific fiscal year. This data is, of
course, generated by the computer based
upon the acquisition date and life
expectancy tables derived from D.O.D.;
V.A.; DHEW; Coast Guard; GSA; etc. In
the same manner, the system will provide
data concerning dollar amounts expended
by cost accounting codes during a specific
fiscal year for specific types of equip-
ment. Staying in the budgeting field, a
listing of all EPA excess equipment is
available to all users at any time at no
cost. This listing is updated monthly and
should be reviewed by property procure-
ment and other managerial personnel prior
to purchasing new equipment.
The reports mentioned above are
only a few of these available from the
Personal Property Accounting System. To
repeat, information may be retrieved in
any desired format by any of the data
elements, including both owned and leased
property. Here in the Washington area,
we have, at times, been asked by various
police jurisdictions to determine whether
or not a stolen item might belong to EPA.
Usually only the manufacturer, model, and
serial number of the item is known. The
master file is searched by serial number
and the result is telephoned to the police
in a matter of minutes.
In summary, the 27 data elements in
the master file include a variety of data
useful to managers at all levels as well as
those in non-managerial positions. This
data includes the name of the item, cost,
location, identity of the acquisition docu-
ment, status, and the name of the person
to whom the equipment is "loaned".
Our experience indicates that
virtually all programs executed on an
overnight (D/R) priority vary from 10 to
60 percent cheaper using the UNIVAC 1110
vis-a-vis the IBM 370. We have had no
experience on priority-run cost compari-
sons, as such priorities are not available
at NCC without special concurrence of
management. In our opinion, using
UNIVAC edit processor for text editing is
E-28
-------
far more expensive than using WYLBUR
on the IBM to include connect charges,
etc. This has resulted in our discontinuing
the use of several highly desirable 123
character "working files". We are coordi-
nating with EPA-MIDSD personnel to uti-
lize a Data 100 keybatch remote entry
terminal for text editing and subsequent
transmittal to the UNIVAC 1110 of the 123
character files. We are also in the initial
stages of using the University of Maryland
edit processing procedure which, we
understand, is somewhat cheaper than the
Exec 8.
For future planning, it is our belief
that, in compliance with the Accounting
Principles and Standards for Federal
Agencies issued by the Comptroller Gen-
eral of the United States and Part II,
Section VIII, Property Accounting, EPA
Order 2550.1, Accounting and Finance, the
requirement for the EPA Financial
Management Division to reconcile per-
sonal property assets with the general
ledger sub-accounts plus the requirement
to maintain depreciation values of
individual items could be accomplished by
an "interface" with the life expectancy
table and the individual item record
stored in the personal property accounting
system. We do not feel that the Exec 8
software is as simple or as powerful as
WYLBUR; however, this is greatly offset
by new capabilities available via Exec 8.,
e.g., the "(aSORTF" command and the
"(gFAC" command. Turnaround time is
normally overnight with virtually no-run
priorities available, although the use of
the "@ADD" command will permit
immediate job execution, with output data
printing on the R3E terminal.
E-29
-------
QUESTIONS AND ANSWERS
Question: I would like to thank Woody for volunteering to go to NCC for us, to do
the ground work, because I had heard some horrendous things. I figure if
he could live through it we would be all right.
Answer: I would like to reassure you. We have people that take inventories based
on nomenclature. Bear in mind that when we installed this system in
1972, we amalgamated a force in roughly eight different data based
systems, i.e., the Atomic Energy Commission was on cards, some came
to us on tapes, and some were manuals. Therefore, the starting position
on the format of the master files still does not appear on the starting
position on which it should appear. We will say that the Department of
Interior transferred an item to us in which the model of an item was part
of the nomenclature. We allowed 44 characters for the nomenclature on
any item. We have a block size of 340, and we are actually using about
380. Within the system, there is a slight interface of a sub-system with
EPA-MIDSD, in which an annual report is generated based partly on data
that they store and partly on data that we store. This produces a final
report that goes into GSA on ADP equipment, both leased and owned.
Relative to the interface with financial management that we have been
attempting this for the last six years. We have the can number. The
regulation supplementing the law requires that the assets maintained on
the record of finance be depreciated. We have brought into the system a
life expectancy table for each item which could readily be used as a
straight line depreciation table. It also requires that the dollar amount
of the fiscal records be reconciled with the personal property account.
Question: You said that the development cost of PPS was approximately $14,000.
Does anyone know what the conversion cost was to get the thing up and
running at NCC? In comparison to that, second of all, I think we know
how Mike Kaplan feels about moving FMS to another IBM system, how
would he feel about moving it to NCC? Most people seem to agree that
it would be really nice if we could integrate all the OPM systems in some
way, whether they go into a common data base or whether they are all
separate, data bases, but simply linked. Might it be more productive for
the Agency to attempt to do that rather than spend its resources trying
to transport all these systems and convert them to run on the 1110?
Answer: May / offer a reply to that. This was my really third experience with
these conversions. I am sort of a guinea pig to this. This is the
smoothest one yet. I asked whom it cost. I am a taxpayer, too; I realize
that cost is very imperative. I believe that the learning process,
developed by NCC personnel, by contractor personnel, and certainly by
me was well worth it. I believe if you do convert and you do use—I am
sure many of you use COBOL and IRS—the packages will be even easier
for them.
Question: Just one quick question. I have tried in a couple of cases—it could be
cause we do not know how to do it—to get a word processing listing of
property for the region, and a combination lease purchase just for the
region. Is there something else available that I probably do not know
about, especially for the word processing?
E-30
-------
Answer: I am not exactly sure what you mean. I think I know what you mean.
Normally, word processing would be retrieved by a data element called
category either for owned or leased properties. This consists of a three
character code assigned by MIDSD, EPA, or you go to the first two digits
of the national stock number, which in this particular case, I believe, is
70. If you pulled 292 for the length of 2 equal to 70 for 24 for the length
of two equals 11 (unintelligible), you would come up with all of your ADP
equipment. On the leased property, if you would just put down less than
100, you would come up with all of the leased property.
E-31
-------
Paul Wagner
Basically, I would like to run over
what the system is, and let the questions
lead us to wherever they may. First of
all, there are two basic delineations of the
kinds of data in the Grants Information
and Control System (See Figure E-l). On
the one hand, there are state and local
assistance grants data bases, which are
divided into two parts; namely, regional
construction grants and other regionally
administered programs. These are made
up principally of grants data related to
state and local governmental support pro-
grams. On the other hand is the Head-
quarters grant data base which consists of
the research, training, fellowship, and
demonstration grant applications, active
projects, that type of thing. These grant
programs are managed through Head-
quarters rather than regions. The state
and local assistance data base has all the
data that relates to grants in the regional
offices, including component systems, the
regional construction grants MIS; and the
water quality's 208 Management Informa-
tion System. Headquarters' data base
includes the small Clean Lakes System
and also are ORD sub-system which tracks
grant applications during the review pro-
cess. The general types of information we
carry in the system—and this varies
depending upon the grants program—from
pre-application data in construction
grants which starts with state planning
lists, the so-called state project priority
lists. Some of the other programs do not
come in until application time. Basically,
this includes information to identify
grant, the project, or the application;
information to identify the applicant,
geographic location of the applicant or
project, a description of the project, and
the money awarded to the successful
applicant. In some programs, there is
general summary data and outlay informa-
tion and, particularly in construction, pro-
jection information. The construction
grants program is far more vast, than all
of the other grant programs put together.
In 1971, there was an RFP out on the
street; we received some 18 proposals
from industry to do a system analysis,
design, and implementation of a combined
grants and contracts management infor-
mation system. For reasons only known to
people who have long since left EPA for
better things, that effort was abandoned
in 1972. We went our separate ways.
When that effort was abandoned, we
started building a small system to track
grant applications. At that time, that was
a major problem in EPA. Everybody had
heard about EPA and all the money they
had for research and training. Applica-
tions were actually piled in stacks four or
five feet high. In those days we had to
find out from who we had applications
from so when a Congressman wrote and
asked what we were doing with one, we
knew we had it. That was the big thing in
1972. We expanded the system in 1973
and started taking up pre- and post-
application data. We started getting the
regions involved and started working with
the Municipal Construction Division and
the Management Information Data Sys-
tems Division. They had grown from
branch to division status by then. We
implemented a regional program princi-
pally in the Wastewater Treatment Con-
struction Grant Program. In 1974, we got
more concerned with trying to establish a
quality control program on these data; in
1975, the Office of Water Program Opera-
tions had a contract with Arthur Young,
Inc., to do a major construction grants
systems study. That study resulted in a
significant modification and expansion of
GIGS. In 1976, the expanded system, GIGS
II, was implemented. Last year, we
picked up the 208 area-wide planning
grant water quality information system
and a small clean lake system. Also, GICS
was extended to include the State of
California's Wastewater Treatment
Construction activities performed under
EPA delegation of authority from Region
IX.
E-32
-------
GICS's objectives are to make avail-
able grant activity information to project
officers and regional and program
management on a weekly basis; provide
rapid response to special information re-
quests from grant applicants, Congress,
and EPA senior managers; provide rapid
response to project officers, program
staff, and grants specialists in solving
daily operational problems; permit mana-
gers to discontinue unnecessary manual
recordkeeping and reporting procedures,
both in the regions and Headquarters; and
provide a system design module that can
supply standard management information
on an Agency-wide basis and still be
modified to meet special operational re-
quirements of the respective regional and
grant program managers.
GIC5 uses the computer and national
communications facilities of EPA's Wash-
ington, D.C. computer center which are
operated and maintained under contract
by Computer Network Corporation
(COMNET). GICS is a transaction-
oriented batch update computer system
for collecting, editing, and storing
information which is relevant to EPA
grant programs. The system includes
information on grant re-applications,
including projects on Wastewater
Treatment (WWT), State Project Priority
Lists; applications in process; funded
(active) projects; and completed projects
through the time of final audit and close-
out.
GICS operates on a weekly schedule
in which the transactions that take place
Monday through Friday are collected by
regional, State, and Headquarters' offices
for entry into the system during a national
update after 19:30 Eastern time on Friday
night. The offices (meaning region, State,
and EPA Headquarters offices) receive
the results of the Friday night update on
Monday morning. If an office has entered
all of its Monday through Friday
transactions and has made no errors,
weekly management reports can be run on
Monday, however, a clean-up update is run
every Tuesday night to collect any
transactions an office has missed and to
allow correction of any errors which
might have been made on the transactions
processed on the Friday night update.
Offices receive the results from the Tues-
day night update each Wednesday morn-
ing. This semi-weekly update should
assure users a complete data base each
Wednesday morning.
Each office, including regional
offices, the State of California, and Head-
quarters Grants Operations Branch (GOB),
regularly collects transactions data, such
as award transactions, and enters them
into a "holding" file in the computer.
Twice weekly, Tuesday and Friday nights,
the Grants Information System and
Reports Branch (GISAR) initiates the
computer update cycle. This series of
programs compiles the transaction collec-
tions and processes them against the
master file. In this way new records are
created and changes and corrections to
existing records are processed. These
combined records, created and maintained
by the 10 regional offices, California, and
GOB, constitute the total EPA-GICS data
base and reside in the GICS master file.
The master file, a system file, is acces-
sible only to GISAR. The updated master
file is read to create the subordinate data
bases (also referred to as sub-data bases).
Each organization then has a current sub-
data base from which to run outputs, such
as reports and lists, until the next semi-
weekly update cycle.
The regions are unique. They range
in the grants area from Region V, a
monster in terms of its volume of activity
and its amount of dollars, to Region II
which normally has lots of dollar activity,
but only two states and Puerto Rico.
Therefore, they have a limited volume of
activity. Region VIII, which has less
populated areas, has, perhaps, a fair num-
ber of smaller projects, but very few large
projects, fewer universities and less re-
search. Region III is a region with
additional grant related informational
needs, that are accomodated with a
national system and a local system
E-33
-------
maintained parallel to the national sys-
tem. As we move along and regions get
more ADP staff, mini-computers, and
more activities, as grants projects
increase, we get into a process whereby
the region is able to update any day they
want. Or, they could update two or three
times a day on a regional option basis.
The region could still be maintaining its
own local data if they want different data
elements, peculiar to their regional needs.
In the future, perhaps, we will move on if
it is feasible. There may be regions with
mini-computers that will capture their
own data, process it in their mini-com-
puter and dump it into the national system
on a regular basis. Then, rather than
receiving information from the national
update, the process would be reversed.
Early next year, we will actively discuss
this.
We have had some discussions on the
interface with various so-called admini-
strative systems. More often than not, at
least in the grants area, administrative
systems seem to be in an organizational
box. We do have an on-going relationship
between grants and contracts in that, on a
regularly scheduled basis, we do pull
together research grants and contracts
into a common listing made available
throughout the Agency in the EPA library
and other users. We do have some
prospective contracts information in
GIGS. Along with grant applications, all
unsolicited proposals are received in the
grants administration division and entered
into GIGS. Once the determiniation is
made that an unsolicited proposal is going
to be routed to contracts as a prospective
contract, it is dropped and transferred
from GIGS, from the grants process to the
Contracts Management Division. They
pick it up in their system, and we retire
the record from GIGS. We do get a tape
from them on a quarterly basis and pro-
duce, for those people interested in re-
search, a joint listing of all research
grants and contracts active at that time.
We have very little redundancy with the
Financial Management System. I think we
have three data elements in GIGS which
are also in the Financial Management
System. It has been our practice to avoid
duplication of the data carred in the
Financial Management System. For that
reason, we do carry only summary outlay
information, and things of that sort.
Any EPA organization or state,
following initial clearance, which has
access to a terminal or other computer
facility and has a registered current
account at COM NET may run computer
programs and retrieve data from the GIGS
data base. There are 18 organizations
authorized to enter and maintain their
respective grants data in GIGS. These
are: Region I through X, Headquarters
Grants Operations Branch (GOB), ORD-
Project Processing System (PPS), ORD-
Office of Health & Ecological Effects
(OHEE), ORD-Office of Energy, Minerals
& Industry (OEMI), ORD-Office of Moni-
toring & Technical Support (OMTS), ORD-
Office of Air, Land & Water (OALW),
California State Water Resources Control
Board, and Grants Information System and
Reports Branch (GISAR). GIGS is also the
host system for several other EPA sys-
tems. As mentioned earlier, GICS sup-
ports: The Office of Water and Hazardous
Materials, Regional Construction Grants
Management Information System
(RCGMIS), Water Quality Management
Information System (WQMIS), and Clean
Lakes Management Information System,
as well as The Office of Research and
Development's Project Processing System.
GICS can be linked to other EPA
computer systems that operate on the
COMNET facility or for which a computer
tape of the data base is available. Sys-
tems are linked together through a com-
mon field of information, such as zip
codes or grant ID code numbers.
E-34
-------
COMMENTS
Comment: I would like to mention that, being from a region that has many computer
capabilities, -we certainly would like to see you keep an open mind about
the potential for maintaining the regional data base.
Comment: One comment. They will be having an Information Data Management
Training Course next week in Cincinnati; then there will be training
courses in Atlanta, Seattle, and Chicago. I am sure that you will be
welcome.
Comment: Headquarters needs are not always our needs. In fact, sometimes they do
not have anything to do with our needs. Sometimes we help you and you
can help us.
It has been hard dealing with all the regions and I know you have been
through a lot of headaches, but, in the end, it comes out to a much better
product because it is visible, it does meet our needs. Along the same
lines, the other thing to keep in mind is that at the bottom of all of this
are the people that input the data. You say you input data you never
used, I think that is deplorable. If the people who input data do not get
benefits from it, I do not see how they are interested in its
correctiveness or use. It is a bad situation, but I think it is one you have
to realize exists.
E-35
-------
PANEL F: WATER SUPPLY
Chairman: Fredrick T. Martin
Panelists: Dan Barber
Bruce Keith
Donald Worley
OVERVIEW
Fredrick T. Martin
I would like to welcome all of you to the Water Supply Panel of EPA's Second Annual
ADP Conference. We would like to address that aspect of the Water Supply Program that
deals with the supervision of public water supplies. From an ADP perspective, this means
the Model State Information System (MSIS) and its follow-on system, the Federal
Reporting Data System. Our primary thrust today will be to discuss the decentralized
design of the MSIS system, any unique problems associated with system implementation,
and ways in which MSIS meets the needs of the States, Regions, and EPA Headquarters.
I have with me today three pioneers in MSIS development and implementation, each
of whom represents a different perspective. Dan Barber, the MSIS Coordinator for Region
IV from its Water Division, serves as the interface between the Water Supply and the ADP
Branches in that Region. He represents the regional perspective. Bruce Keith has a most
unique position in that he was the Area Systems Manager for the Southwestern Ohio
Regional Computer Center, better known as SWORCC, which developed the system. Mr.
Keith had held both technical and managerial positions at SWORCC before coming to EPA
Headquarters, Office of Water Supply. He represents Headquarters' perspective on this
system. Don Worley, from EPA's Plans, Analysis, and Research Branch, National
Computer Center, Research Triangle Park, North Carolina, will bring to the panel the
Agency perspective.
We have three presentations, the first of which, by Dan Barber, will address "The
Legislative Direction and Decentralization of the Model State Information System." He
will give us the legislative background of this program, explain decentralization, and
discuss MSIS installation considerations, as well as the system preparation and follow-up.
Bruce Keith, whose presentation is entitled, "Meeting the Requirements of the Safe
Drinking Water Act and the Needs of the States in EPA," will speak on the Safe Drinking
Water Act, the needs of the States and EPA, and how MSIS meets requirements and needs.
Lastly, Don Worley will present, "The Test and Acceptance of the System to be Delivered
to a User Other Than EPA."
Before the papers, I would like to give an overview of MSIS, for those of you who are
unfamiliar with the Model State Information System.
MSIS, a large-scale decentralized management information system, is designed to
assist the States and territories in meeting their data information handling and reporting
requirements, mandated by the Safe Drinking Water Act. The system was developed under
contract by SWORCC and delivered to EPA in May of this year. It went through
F-l
-------
comprehensive 30 to 45-day acceptance test which Don will talk about. Then we launched
an intensive installation and training program for the States and regions, all of which will
be covered in detail today.
Specifically, MSIS consists of eight primary subsystems whose major functions are as
follows:
(1) The Inventory Subsystem stores records of each public water supply and
contains information such as the name, address, population served, number of
service connections, source of water, treatment techniques, etc.
(2) The Water Quality Compliance Subsystem, by far the largest and most
comprehensive and complex of the eight primary subsystems, determines
compliance with the regulations. The system also maintains records of
samples in laboratory reports and gives us detailed and summary reports of
regulation violations.
(3) The Regulation Subsystem stores the Federal and/or State regulations that the
Compliance Subsystem accesses in order to determine compliance.
(4) The Federal Reporting Subsystem provides compliance data to EPA in a
computer comparable form for the follow-on Federal Reporting Data System.
This is an annual report required under the Safe Drinking Water Act. Using the
output of the Federal Reporting Subsystem of MSIS, a State can fulfill all of
its annual Federal reporting requirements.
(5) The Variances and Exemptions Subsystem maintains records of compliance
schedules, variances, and exemptions, and produces compliance reports that
are appropriately scheduled milestones.
(6) The Sanitary Survey Subsystem schedules the periodic sanitary survey based on
State-defined priority factors, such as the population served.
(7) The Enforcement Action Subsystem maintains records of specific enforcement
actions in order to assist in case-tracking and compliance-monitoring require-
ments of the Act.
(8) The Operator and Mailing Subsystem manages data on certified operators and
produces appropriate mailing lists.
As you can see, the Model State Information System is a very complex,
decentralized, batch-oriented system that meets the annual reporting requirements under
the Act as well as providing the State with a lot of latitude in meeting its own needs.
There are over 50 standard reports available from MSIS, and literally hundreds of tailor-
made reports that are available or possible from this system.
I just want to mention briefly the implementation plan, i.e., the training and
installation program, that the Office of Water Supply uses. The first step is a Pre-
Installation Management Conference to make certain that all parties share a mutual set of
expectations about training, installation, and follow-on services. Then we have week-long,
formal classroom training in each State, where people are trained in all aspects of the
system. We then install the system for those States using the computer on their own
F-2
-------
facilities. Both the training and installation phases together generally take 12 days. We
then offer on-the-job training, which consists of four days of additional assistance. This
allows them to take care of requirements that must be done after installation and training
are completed, but before the system can become truly operational. In addition, three
items are included in our post-installation support package to a State. The first is an
actual contract with SWORCC, assistance similar to a year's warranty on the system,
which can range from a simple phone call about a question on the documentation to an
actual return visit to the State. The second item is the MSIS User Support Group, which is
now being formed. This will serve as an information gathering and reporting forum, and as
the focal point for all MSIS-related matters, such as the coordination and dissemination of
system updates. A steering committee has already been formed and a meeting will be
scheduled shortly. Finally, we offer a modification contract which addresses two phases;
namely input from the User Support Group, and any mandated changes that may be
necessary. Thus, through the Modification Contract, the Post-Installation Support
contracts and our User Support Group, we have a package of support to keep the system
afloat after the SWORCC teams leave the States.
We have been involved in 15 States and, six States have actually signed off. These
are Oklahoma, Kentucky, Illinois, Minnesota, New Mexico, and Alabama. Some 34 States
are expected to take MSIS, and I expect installation and training to be completed by April
or May of next year.
Let us now turn to the presentations.
F-3
-------
PANELIST STATEMENTS
Legislative Direction and
Decentralization of the Model State Information System
Dan Barber
Introduction
The Model State Information System
(MSIS) was developed by the Southwestern
Ohio Regional Computer Center
(SWORCC) under contract to the Office
of Water Supply (OWS) at Environmental
Protection Agency (EPA) Headquarters in
Washington, D.C. It is a tool to be
utilized by the States in support of the
requirements of the Safe Drinking Water
Act (PL 93-523) of 1974. The system was
designed under a decentralized concept
and will be operated by most States on
their own computer systems. (Two States
will utilize WCC.) The legislative man-
date for the Drinking Water Program is
Public Law 93-523 which specifically
emphasizes the role of the States. In
addition, the general thrust of the Agency
is to encourage more State involvement.
Therefore, the decision to provide a
decentralized system was based on a
desire to insure the autonomous operation
of each State program. A decentralized
data management system would, in effect,
assure each State more complete control
of all aspects of their own program.
This paper will discuss the legisla-
tive background of EPA/State relation-
ships regarding EPA program activities in
general. It will then discuss the Safe
Drinking Water Program and show that
the decentralized concept for MSIS is in
agreement with the mandates of the Safe
Drinking Water Act, as well as with the
spirit of other EPA Water Program legi-
slation. Once the legislative background
for decentralization is established, the
concept is discussed briefly in comparison
with centralization. In conclusion, some
difficulties experienced in the installation
process for MSIS are discussed and the
methods used to deal with them are
explained.
EPA/State Agency Relationships
Legislative Background
It has been the policy of the Federal
Government to involve the States in pol-
lution abatement activities as much as
possible. A basic requirement has been
that the State regulations controlling the
affected activity must be at least as
stringent as the Federal regulations. This
is true of the delegation of the National
Permit Discharge Elimination System
(NPDES), as well as the assumption of
primacy by the States under PL 93-523.
However, the importance of State
involvement in Federal water pollution
abatement activities is obvious from
existing laws and regulations. It is on this
premise that the decision to decentralize
MSIS was based. The following is a
discussion of some Federal programs and
the legislative emphasis for State involve-
ment in each program. It concludes with
a discussion of the Safe Drinking Water
Act.
Water Quality Surveillance System
In order to develop a data base of
essential water quality data and to
provide for continuing surveillance of
water quality in order to detect water
pollution as it develops, the Administrator
of EPA is required to establish national
programs to control water pollution.
Under Section 104(a)(5) of PL 92-500 the
Administrator is required to:
-------
"...establish national programs
for the prevention, reduction,
and elimination of pollution
and as part of such programs
shall—in cooperation with the
States...equip and maintain a
water quality surveillance sys-
tem for the purpose of moni-
toring the quality of navigable
waters and ground waters..."
The establishment and maintenance
of these programs is generally funded in
part through a State Program Grant pro-
vided to the States under Section 106 of
PL 92-500. In addition, Attachment A to
the Section 106 Regulations requires that
the water quality data collected under the
requirements of Section 104 of PL 92-500
be provided to EPA in a manner agreed
upon between the Regional Administrator
and the State Director. The FY 76
Regional Guidance required that data
handling agreements be established bet-
ween EPA and the States to accomplish
the data transfer. For most of the States
in Region IV, Water Quality Data is
entered directly into STORET by the
State. This fulfills the requirement to
transfer the data to EPA. STORET is an
example of a centralized Environmental
Protection Agency ADP System used by
the States.
Construction Grants
The Municipal Wastewater Treat-
ment Works Construction Grants Program
is by far the Agency's largest grant
program. It encompasses all phases of
wastewater treatment works design and
construction, from the planning and design
of the facility through the completion of
construction. The total amount of pro-
gram funds disbursed to local governments
nationally in FY 77 was approximately
$2.7 billion. In addition, approximately
$6.7 billion was obligated for future pro-
jects. Some facets of the Construction
Grants Program have been delegated to
State agencies for several years. The
legislative justification for this delegation
is contained in the Construction Grant
Regulation, 40 CFR Part 35.912, which
states in part:
"...optimum use will be made
of available State and Federal
resources to eliminate unnec-
essary duplicative reviews of
documents required in proces-
sing of construction grants
awards. Accordingly, the Re-
gional Administrator may
enter into a written agree-
ment, where appropriate, with
a State agency to authorize
certification by the State
agency of technical and/or ad-
ministrative adequacy of spe-
cifically required documents."
In the past, this has referred pri-
marily to the review of the technical
aspects of the so-called Step 2 grants, the
Plans and Specifications Review, any
changes requiring additional commitment
of Federal funds, and the technical review
of the Operations and Maintenance Man-
ual required for each plant constructed
under the program. For the most part,
the State role in the Step 1 grant process
(the planning of the project under Section
201 of the Act) and the Step 3 grant (the
physical construction) has been limited.
However, Region IX has delegated the
entire program to the State of California
with the Region involved only where the
Regulations required, or for program
monitoring. In addition, proposed legisla-
tion currently before Congress (HR 3199)
would provide for much more State in-
volvement in the Construction Grants
Program through the amendment of PL
92-500 to include a section 214 entitled
"Certification". The so-called "Cleve-
land-Write Amendment" reads in part:
F-5
-------
"The Administrator may carry
out any of his responsibilities
for actions, determinations or
approvals under sections
201(g)(2) and (3)...with respect
to projects...for treatment
works by accepting a certifi-
cation by the State water
pollution control agency of its
performance of such responsi-
bilities."
This will provide for the eventual
delegation of most aspects of the Con-
struction Grants Program to the States.
The result will likely increase the neces-
sity for EPA to work together with the
State agencies in order to insure that the
goals of the Act are met.
The data management system used
to support the Construction Grants Pro-
gram is the Grants Information Control
System (GICS). It is a centralized system
used only by EPA and the State of
California. As the States become more
involved in the program, the problem of
an ADP System to be used by the States
will have to be addressed. Current plans
call for the delegation to include the
operation and maintenance of GICS.
The Safe Drinking Water Act—State Role
The Safe Drinking Water Act (PL
93-523) is not unlike other legislation
governing EPA activities and responsibili-
ties in the area of EPA/State relation-
ships. It specifically gives the States
primary enforcement responsibility for
public water systems if the State meets
certain conditions. Section 1413(a) states
in part:
"...a State has primary en-
forcement responsibility for
public water systems during
any period for which the Ad-
ministrator determines...that
such State (meets primacy re-
quirements)."
The National Safe Drinking Water
Strategy is more explicit in its outline of
the State role in carrying out the require-
ments necessary to meet the goals of the
law. The following statements is found in
the Executive Summary-Strategy Over-
view Section:
"EPA desires to certify all
States for primary enforce-
ment responsibilities..."
The Program Statement In Chapter II
reads:
"(PL 93-523) requires the Ad-
ministrator to encourage max-
imum (emphasis added) levels
of State involvement in the
promulgation, implementation,
and enforcement of regula-
tions and programs developed
under this Act."
In addition, the Program Statement of the
Strategy states:
"The State governments, to
the maximum extent feasible
(emphasis added), are responsi-
ble for supervising the public
water systems, implementing
the provisions of the National
Primary Drinking Water Regu-
lations..."
In Chapter HI, the Strategy lists as one of
the program objectives:
"To insure an effective Fed-
eral-State partnership (empha-
sis added) in the implementa-
tion of the Act."
And finally the Strategy indicates that:
"EPA is working with the
States to develop workable
ADP Systems."
F-6
-------
Summary
It is clear that the law, as well as
the program strategy, strongly emphasize
State involvement in the Drinking Water
Program. In fact, the basic thrust of the
Act, regulations, and drinking water stra-
tegy are to provide primary authority to
the States to oversee the accomplishment
of the legislative goals. This is in line
with other major agency programs such as
water pollution abatement and construc-
tion grants. The most current legislative
changes proposed for the Construction
Grants Program will increase the involve-
ment of many States in that program.
The MSIS was developed primarily
for State use because of the clear legisla-
tive mandate for State involvement as
well as the obvious need for data manage-
ment. The sheer volume of monitoring
data alone is staggering. When this is
combined with the complexity of the
regulations regarding compliance (espe-
cially when violations occur), the need for
a comprehensive data management system
becomes evident. A system was also
necessary to meet the annual reporting
requirement (Section 1450(h) of PL 93-
523) to Congress. Since heavy emphasis is
placed on the State role, it was felt that
an ADP System should be developed that
could be specifically responsive to State
data management requirements, as well as
provide for automated input to the annual
report to Congress. The determination to
decentralize the system was the result of
a desire to provide for, as completely as
possible, the autonomy of each State
program and encourage the State to
accept primacy.
Decentralization—What It Means
Just as systems designed under the
centralized concept have certain limita-
tions which inhibit State use, the MSIS
designed under the decentralized concept
has, by necessity, aspects which limit its
flexibility. For instance, MSIS was writ-
ten to be machine independent so that it
could be installed on various State com-
puters. The nine subsystems are indepen-
dent modules with little direct interface
except through the use of tables contain-
ing common information. Of the nine
subsystems, five are required for system
operation. The remaining four are
optional although some elements are
required for the annual Federal Report.
Processing cost of MSIS is the
responsibility of each State and is an
allowable item to be charged against the
Federal grant to support Water Supply
Program activity. If desired, MSIS can be
installed at WCC for State use. Two
States will use the COMNET facility and
pay for their usage through an Interagency
Agreement with EPA. The funds to cover
this usage may also come from Federal
grant funds.
MSIS is a batch, after-the-fact
system primarily designed to aid the
States in record keeping, and projecting
and monitoring the complex compliance
schedule information based on a routine
sampling program required by the regula-
tions. One of its major purposes is to
automate the Federal reporting process.
Once a year, tape output from MSIS will
be used as input to the Federal Reporting
System which will then process the data
into the proper format for the Report to
Congress.
Another well-known system,
STORET, was developed from the
centralized concept and is different in
many ways from MSIS. These differences
are the heart of the centralized/decentra-
lized issue. The STORET Water Quality
File contains water quality data collected
from the Water Quality Surveillance Sys-
tem of the States. It is the largest water
quality data base in the country and also
contains data collected by EPA and other
Federal agencies including U.S.G.S: In
Region IV, it is used as the mechanism for
the required surveillance system data
transfer from the States to EPA.
F-7
-------
STORE! is IBM dependent and located at
WCC. It is accessed through RJE and low
speed terminals throughout the country
and operates similar to an interactive
system with powerful and comprehensive
retrieval capabilities. State usage is
funded through the EPA ADP Sub-
allowance in the amount of $600,000
annually. This essentially provides a
dependable ADP System, cost free to the
States. The benefit is that the States are
encouraged to use STORET to store their
Water Quality data and in so doing, aid in
the establishing of a comprehensive
national data base of water quality data.
Since the amount of funds available to
support State usage is limited, some
States have established Interagency
Agreements to cover any additional usage
above their ceiling amount. This
mechanism will also be used to fund State
use of the WCC facility for the MSIS in
the two States whose systems will be at
COMNET.
The advantages of a centralized
system over a decentralized system
include:
o Operational flexibility
o Ease of maintenance of sup-
port (sophisticated ADP exper-
tise not required in State)
o Reduce installation cost
o EPA access to data base.
However, the above advantages
must be balanced against advantages of
decentralization which include:
o Complete system control by
State
o Encouragement of States' pro-
gram independence
o Freedom from effects of EPA
policy changes
o Inability of some States to
utilize computer facilities out-
side of State government.
Any decentralized system, the size
of complexity of MSIS, is costly to make
operational since the system must be
installed independently in each State.
However, the long-term advantages can
outweigh the disadvantages. This will, in
the end, depend on the applicability of
MSIS to each State program, the ability of
OWS to provide adequate system support
to the States, and the overall effective-
ness of the system to meet the require-
ments for which it was designed. We are
now in the installation phase, and have
encountered various situations which have
required a great deal of creative throught,
diplomacy, and ingenuity. The following
section outlines some problems that can
occur.
MSIS Installation
Considerations
MSIS is a complex system being
installed in 35 States by the Southwestern
Ohio Regional Computer Center. There is
a deadline for installation since the
system should be installed and operational
in time for the 1978 annual report to
Congress. Some difficulties have resulted
from the necessarily tight schedule and
EPA contractor personnel working within
the State bureaucratic structure. In some
instances, State organizational structure
has caused unexpected delays. The
following is a summary of some considera-
tion linked to the installation of any
decentralized system:
o Tight installation schedule can
produce a domino effect if
installation drags on in one
State.
F-8
-------
o Various facilities have dif-
ferent text editors, system
procedures, levels of com-
pilers, operating systems, etc.
o Many States have the ADP
function consolidated in one
area while program functions
are completely removed. Con-
flicts and misunderstandings
can develop (or exist already)
between the two groups.
o Many State programs have
little exposure to ADP and do
not understand the impact of a
large data system.
o When a program element, such
as Drinking Water, attempts to
hire ADP personnel for MSIS,
conflicts can develop between
the program and ADP func-
tions over that position.
o Organization and personnel
shifts within a State can cause
problems.
o Internal State politics on
State/EPA political situations
can affect system installation.
Because of this, it is impera-
tive that the Region be very
much involved in the process.
Installation Preparation and Follow-Up
In an attempt to minimize the po-
tential for these situations to develop,
several steps have been taken to insure
that proper coordination has taken place
with representatives from the Water Sup-
ply and Data Processing functions. This
involves the completion of various forms
and checklists and face-to-face meetings
between the State, EPA, and SWORCC.
The preparation can be broken into three
distinct areas.
Background Information Packages (BIP)
The purpose of. the BIP's was to
gather basic information about the State
Water Supply and ADP personnel and
facilities. They identify the State coordi-
nators and provide information about the
computer facilities, including type of
computer, configuration, terminal access,
etc. The information was gathered for all
States accepting MSIS in meetings bet-
ween Regional Water Supply and ADP
personnel and their State counterparts
approximately one year ago. This infor-
mation was compiled by SWORCC and the
national installation strategy was
developed from them.
Checklists
In the BIP Meetings, the basic infor-
mation is gathered through the use of two
checklists, one for the ADP and one for
the Water Supply Program. In addition,
the States are asked to complete another
checklist, called "State Checklist of MSIS
Training and Installation Requirements",
shortly before the installation is scheduled
to begin. This checklist provides updates
to the earlier ADP Checklist as well as
more specific information about the train-
ing facilities. The final checklist is called
"Management Checklist for Implementing
MSIS in States after Installation", and
contains information and instructions to
facilitate the development of State MSIS
usage once the system is installed.
Pre-Installation Management Conference
The Pre-Installation Management
Conference is scheduled approximately
two weeks before the Water Training is to
begin. It generally consists of representa-
tives of the State ADP and Water Supply
functions; EPA Regional ADP and Water
Supply personnel; the contractor,
SWORCC; and Tom Martin from Office of
Water Supply, Headquarters. In this
meeting, a quick overview of MSIS and its
current status is provided, the completed
Checklist for MSIS Training and Installa-
tion Requirements is reviewed by
SWORCC, and any State questions are
answered. The training and installation
schedule is reviewed and an attempt is
made to coordinate management level
people who will be involved in the
installation.
F-9
-------
Once the system is installed, addi-
tional and follow-up actions are planned
to help the State develop its usage and
solve any difficulties they may encounter.
These actions include:
Post-Installation Training
After the MSIS has been installed,
the State may request up to four days of
additional on-site, user-oriented training.
The training is provided by SWORCC and
allows State Water Supply personnel to
resolve any difficulties experienced with
MSIS usage.
User Support Group
OWS is now establishing a user
support group. It will consist of represen-
tatives from EPA Headquarters, Regions,
and the States. Its purpose is to gather
and disseminate information concerning
the implementation and usage of MSIS. It
will essentially be the focal point for all
MSIS related activities. In addition, a
user support group will be provided by
SWORCC for technical support to the
States and Regions as needed.
It would appear that the above
coordination efforts would be sufficient to
insure that State personnel were ade-
quately prepared for the installation.
This, however, is not always the case. In
one State, the ADP coordinator for envi-
ronmental programs who had the responsi-
bility for the MSIS installation left his job
after the BIP meeting. When the Pre-
Installation Management Conference was
held, his replacement attended the meet-
ing as well as a representative from the
State Computer Center (SCC). By the
time SWORCC arrived for installation,
the new coordinator had left and no
replacement had been named. The SCC
was apparently not aware that the
installation was to take place since the
SCC representative who attended the Pre-
Installation Management Conference had
also changed jobs and apparently told no
one about the installation. As a result of
the musical chairs in positions, a
requirement had been established that the
Commissioner's signature was necessary
to accomplish even routine tasks such as
the reservation of disk space. This,
needless to say, added to the confusion.
The above may be an extreme
example, but there will certainly be other
complications, usually unexpected, which
continue to occur in other areas of the
installation process. One of the best
evaluations of MSIS installation was given
by Region IV's ADP Management Branch
Chief, Curt Lackey, in one of his monthly
reports. In discussing the problems exper-
ienced in one of our States, he offered the
following comments concerning lessons
learned:
o Take minutes of the Pre-In-
stallation Management Con-
ference.
o Send copies to all participants.
o Ask the State to follow up one
week before installation with
calls to all participants.
o Assume Murphy's Law will pre-
vail.
There is little doubt as to which of
the four is most appropriate.
F-10
-------
Meeting the Requirements of the Safe Drinking Water Act
and
The Needs of the States and EPA
Bruce O. Keith
Introduction
The Safe Drinking Water Act of
1974 greatly expanded the U.S. Environ-
mental Protection Agency's responsibili-
ties in insuring the quality of drinking
water in the United States. Under the
authority invested in EPA by the Act, a
set of drinking water regulations was
established to facilitate meeting the
intent of the new law. Since the legisla-
tive desire is to increase the role of the
States in the enforcement of Federal
programs, we can understand how the
duties and responsibilities of the States
have been, likewise, greatly expanded.
The remainder of this report is
intended to accomplish two major goals.
First, the major provisions of the Safe
Drinking Water Act are briefly discussed.
The water systems which are covered, as
well as the monitoring and reporting
requirements as established under the
National Interim Primary Drinking Water
Regulations, will clearly demonstrate the
scope of responsibility placed upon the
States which assume primary enforcement
responsibility (primacy), or upon EPA in
situations where a State does not assume
primacy. Secondly, in consideration for
the additional burdens placed upon the
States and EPA, the development of a
computerized State information system,
the Model State Information System
(MSIS), and a Federal information system,
the Federal Reporting Data System
(FRDS), are discussed insofar as they
relate to the manner in which the
additional burdens are reduced by a
mechanized approach. Emphasis is placed
on state-of-the-art techniques utilized in
the design and programing of the Model
State Information System as they relate
to the system's implementation on a de-
centralized basis.
The Safe Drinking Water Act of 1974
On December 16, 1974, the Public
Health Service Act was amended by the
Safe Drinking Water Act (PL 93-523) to
assure that the public is provided with
safe drinking water. The Act gave EPA
the responsibility of setting minimal
national standards for all public water
systems in the United States. The
regulations are of two distinct types;
Primary regulations which are aimed at
protecting public health and take cost into
consideration, and secondary regulations,
designed to protect public welfare.
In the case of the primary regulations,
maximum allowable limits of permitted
contamination in drinking water are
established, as well as the frequency at
which water samples are to be taken and
analyzed. The States are to take the lead
role in enforcing these regulations. In the
case of the secondary regulations,
maximum allowable contaminant levels
and monitoring frequencies are also estab-
lished. However, these regulations are
not enforceable from a Federal viewpoint
and will only be enforced when an
individual State chooses to do so.
Provisions of the Act
Some of the major provisions of the
Safe Drinking Water Act of 1974 are as
follows:
o Establishment of primary regu-
lations for the protection of the
public health; National Interim
Primary Drinking Water Regula-
tions, promulgated on December
24, 1975, and on July 9, 1976,
became effective on June 24,
1977;
F-ll
-------
Establishment of secondary re-
gulations which relate to the
taste, odor, and general ap-
pearance of drinking water;
proposed secondary regula-
tions, published in the Federal
Register on March 31, 1977,
are intended as guidelines only
for States that choose to en-
force the secondary standards;
Measures are to be established
to protect underground drink-
ing water sources;
Research is to be conducted
which relates to health, econo-
mic, and technological pro-
blems of drinking water sup-
plies;
Technical aid, training, and
grant support is to be given to
the States to improve •tu~:-
drinking water program;
their
o Citizen suits are permitted
against any party in violation
of the requirements of the
Act; and
o Variances and exemptions may
be granted from a required
contaminant level, or treat-
ment process established under
the regulations, but only when
it can be demonstrated that
there is not an unreasonable
risk to the public health.
Water Supplies Covered
A public water system is defined as
a water system which provides piped
water for human consumption to the
public, if such a system has at least 15
service connections or regularly serves at
least 25 persons on a daily basis at least
60 days out of the year. The definition of
a public water system includes the
following:
o Collection, treatment, storage,
and distribution facilities which
are under the control of an
operator and which are used
primarily in connection with the
water system; and
o Collection and pre-treatment
storage facilities which are not
under operator control, but are
used primarily in connection with
the water system.
A public water system is further
classfied as being a community water
system or a non-community water system.
If the public water system serves year-
round residents, it is identified as a
community water system. Any public
water system which is not a community
water system is identified as a non-
community water system.
Quantifying this structure of classifi-
cation clearly demonstrates the extent to
which the regulations apply. In considera-
tion thereof, the following represents the
best estimates of the public water sys-
tems covered by the National Interim
Primary Drinking Water regulations:
o Total public water systems
(PWS's) covered - 250,000
o Community PWS's — 50,000
o Non-community PWS's ~ 200,000
Of the 250,000 PWS's estimated to be
covered by the regulations, 35,500 of
them serve 85 percent of the nation's
population, and 222,500 serve 15 percent
of the nation's population. Furthermore,
as near as can be determined, 50 percent
of the nation's population is served by
public water systems which obtain their
water in whole or in part from surface
water sources (e.g., lakes, streams, etc.).
The impact of this factor will be more
clearly understood when the monitoring
F-12
-------
requirements contained within the follow-
ing section of this report are examined.
Monitoring Requirements
The monitoring and analytical re-
quirements, as set forth in the National
Interim Primary Drinking Water Regula-
tions, are applied to public water systems
in a manner which is dependent upon one
of four classifications. These classifica-
tions are based upon whether the PWS is
community or non-community, and
whether the PWS obtains its water from
surface or ground sources.
The regulations require monitoring
of six groupings of contaminants; namely
microbiological, physical, inorganic
chemicals, organic chemicals, man-made
radionuclides (gross beta and photon
radioactivity); and naturally ocurring
radionuclides (RA-226, RA-228, and gross
alpha radioactivity). However, which
PWS's must be monitored for the contami-
nant groupings depend upon the classifica-
tion of public water systems. To under-
stand the overall impact of the monitoring
requirements, table F-l is presented for
review. After reviewing the table, we can
see that the community PWS's are
required to perform the majority of the
sampling and analysis, and even more so
when the community PWS obtains its
water in whole or in part from a surface
water source. The largest responsibility
lies with the analyses of samples for
microbiological and physical types of
contamination; however, analyses for
inorganic chemicals (arsenic, barium,
cadmium, chromium, lead, mercury,
selenium, silver, and flouride), organic
chemicals (endrin, lindane, methoxychlor,
toxaphene, 2-4-D, and 2,4,5-TP), man-
made radionuclides (primarily gross beta,
SR-90, H-3, and 1-131), and natural
occuring radionuclides (gross alpha, Ra-
226, and RA-228), although required to be
performed less frequently, are just as
important as the other analyses.
Federal Reporting Requirements
The National Interim Primary Drinking
Water Regulations set forth the following
Federal reporting requirements:
Each state maintaining primary
enforcement responsibility shall submit to
the administrator...
1. Additions or corrections to the
State's inventory of public water
systems;
2. A summary of violations which
occurred during the reporting
period;
3. A summary of variances and
exemptions which were in effect
during the reporting period; and
4. A summary of enforcement
actions undertaken during the
reporting period.
Items one through four must be reported
to EPA on or before January 1 of each
year, and cover the previous Federal
fiscal year, October 1st to September
30th. Additionally, the State must give
prompt notification to the administrator
of any variance or exemption granted.
Needs of the States and EPA
It has been the intent of the previous
section of this report to exemplify the
extent to which the responsibilities of
EPA and the States have been expanded
by the requirements of the Safe Drinking
Water Act. Since Congress intended the
State to play the major role in the
regulations enforcement, they are
impacted the most. It is important to
remember, however, that in cases where a
State does not assume primary enforce-
ment responsibility, EPA acts in the role
of the State. EPA is additionally charged
with the ultimate responsibility of
F-13
-------
safeguarding the drinking water quality of
the nation and annually reporting to Con-
gress on implementation effectiveness.
The States, under their expanded
responsibilities, clearly needed a method
by which the mass of information required
to be collected and reported could be
effectively managed. Also, for them to
monitor successfully the quality of
drinking water in their State, a
mechanism had to exist to keep track of
whether the water systems in their State
were performing the required analysis, for
the required contaminants, within the
regulated period of time.
EPA needs to manage the tremen-
dous flow of information in cases where
they assume the primary enforcement
role, as well as accumulate the informa-
tion reported under the auspices of the
Federal requirements. As has been the
case with EPA's National Inventory of
Public Water Systems, frequent requests
are received from independent organiza-
tions for information. With this factor in
mind, it is apparent that future requests
will be greatly expanded by the additional
data that EPA will have available as a
result of the new Federal reporting re-
quirements. These independent requests,
as well as the internal research needs of
EPA, place an overall expanded responsi-
bility on the Agency alone. But, it cannot
be disputed that EPA's major need still
lies in the ability to produce the annual
report to Congress more easily and
accurately.
How the Requirements and Needs Were
Met
EPA's Office of Drinking Water
(ODW) was made responsible for imple-
menting the provisions of the Safe Drink-
ing Water Act. In this capacity, ODW
acquired contractual assistance from
American Management Systems, Inc., to
study the program requirements, con-
cepts, and plans for the successful imple-
mentation of the Safe Drinking Water
Act. The remainder of this section
discusses the steps which were taken
subsequent to this initial contractual task.
Model State Information System
Developmental History
The initial task performed by
American Management Systems, Inc.,
establishes that a capability by which the
States and EPA could fulfill their basic
responsibilities was openly evident. In
response to this finding, ODW entered into
a second contract with American Manage-
ment Systems Inc., to study the feasibility
of developing a computer-based system.
This effort resulted in the concept for a
model of a computerized state informa-
tion system, or as we now know it, the
Model State Information System. The key
recommendation made was to develop a
decentralized computer system. Overall,
the effort resulted in the general systems
design of MSIS.
ODW continued in their endeavor by
concluding that the decentralized
approach was, indeed, most in line with
Congressional intent, and computerization
would provide significant benefits. ODW
then entered into a series of contracts
with the University of Cincinnati's South-
western Ohio Regional Computer Center,
which subsequently performed the initial
methodology planning utilized in the
detailed systems design, programming,
testing, and documentation of MSIS;
implemented that plan; developed a plan
involving State and EPA regional needs
for installation aid and training, and
actually developed the training programs.
The Southwestern Ohio Regional
Computer Center (SWORCC) continues to
play an important role in the implementa-
tion of the Model State Information
Systems through contractual support to
EPA in the following ways:
o Training in the areas of MSIS
operation and functions for
State and EPA regional per-
sonnel in classroom and on-
the-job environments;
F-lf
-------
o Installation of MSIS on com-
puter facilities of the State's
choice;
o Post-installation and system
maintenance support to the
States and EPA.
In order to grasp the size and com-
plexity of MSIS, the following MSIS statis-
tics are presented:
o«
9 Subsystems
73 ANS COBOL Programs
200,000 Lines of Source Pro-
gram Code (approximate)
32 Catalogued
(Run Streams)
Procedures
o 70 Input Forms
o 78 Output Reports Available
o 12 Volumes of Documentation
contained with 28 physical
binders and consisting of ap-
proximately 8,600 pages
Major Functions Provided
While the Model State Information
System is designed primarily for those
States that do not currently have an
automated system for managing the
increased volume of water quality and
related data, it is also designed to provide
enhanced capabilities to those States that
do have an automated system. States
choosing to install the MSIS are required
to implement five of the nine subsystems.
The remaining four subsystems provide
features which are optional for State and
EPA regional use, depending upon the
volume of data and individual preferences.
Overall, MSIS possesses the following
major features:
o Maintains records of each pub-
lic water system in the
State/region;
Maintains records on certified
laboratories, samples taken,
and sample analysis results,
and provides detail and sum-
mary reports on violations;
Facilitates scheduling of water
quality sampling and analysis;
Maintains records of State and
Federal regulations;
Facilitates submission of Fed-
eral reporting requirements to
EPA in a format suitable for
direct entry into Federal
Reporting Data System;
Maintains records of
compliance schedules esta-
blished via variance and ex-
emption procedures;
Maintains records of specific
enforcement actions to assist
in case tracking and com-
pliance monitoring;
Facilitates scheduling
sanitary surveys; and
of
o Maintains records on certified
public water system operators
and other target populations
for communication.
Impact of a Decentralized Approach on
System Design and Programing
Many factors must be taken into
consideration before a decision can be
reached regarding the use of a computer
system on a centralized or decentralized
basis. The development of the Model
State Information System is an excellent
example of how a system design and
programming effort can be impacted by
the decision to develop a decentralized
system. However, it is important to
realize that the extent to which the
development efforts are impacted is
largely dependent on who the users are.
For example, if a computerized payroll
F-15
-------
system was being developed for use by an
individual State on a decentralized basis,
the design and programming would not be
necessarily impacted to a great extent
since the payroll procedures would be
basically the same regardless of where the
system was installed. On the other hand,
development of a computerized payroll
system for use by all the States would be
extremely difficult, if not totally
impossible, due to the variations in orga-
nizations, procedures, etc.
Since MSIS was designed primarily
for use by a large number of independent
organizations, i.e., the States, it was
immediately clear that the system could
not necessarily meet or satisfy all the
specific desires of each and every user.
However, the States did share a common
responsibility for enforcing the quality of
drinking water. It was this factor that
served as a determining characteristic for
the ultimate design of MSIS. To address
further the unique requirements of indivi-
dual users, MSIS was developed to present
some- degree of variability in an extremely
modular fashion. By so doing, the flexibi-
lity existed for enhancing or adapting
MSIS functions for any State's specific
needs. Also, since the available computer
hardware and software differed from
State to State, MSIS was developed to be
machine independent. This, of course,
implied that a number of design alterna-
tives, as well as some programming tech-
niques, had to be eliminated from
consideration during the initial phases of
the development effort. Because of this
restriction, for example, MSIS was
designed to be a sequentially oriented,
batch-computer system which makes
extensive use of run-time parameters
through control cards. Although sequen-
tially oriented batch computer systems
are commonplace, no other alternative
could really be considered because the
system was to be installed on a variety of
computer mainframes. Other alternatives
which may have proven to be feasible and
possibly more efficient, rely on
capabilities which are not consistently
implemented on all computer mainframes.
Therefore, these alternatives were
avoided.
Although certain design approaches
were mandated by the intended usage of
MSIS on a decentralized basis, the system
'was designed and implemented using the
most current state-of-the-art technology.
Specifically, the following techniques
were utilized throughout the development
effort:
o Hierarchy plus input/pro-
cess/output diagrams
o Top-down structured program-
ming in ANS COBOL
o Chief programmer teams
o Development support library
o Structured walkthroughs of
design and programming.
The specific benefits of each technique
are too numerous to discuss in this
context, but the overall technological
application accomplished the following:
o Permitted design and program-
ming of diverse portions of
MSIS to proceed concurrently;
o Insure conformance to the
general systems design;
o Insure conformance to rigid
design and programming stan-
dards therefore improving the
overall system;
o Insure the modularity and
flexibility of the total system,
the subsystems, the programs,
and the documentation;
o Enable the production of a
reliable, understandable, and
easily maintainable system;
and
F-16
-------
o Enable the production of high
quality documentation in a
timely fashion.
During the programming phase of
MSIS, extensive efforts were applied to
insure that the system would be portable
to Honeywell, Univac, Burroughs, and
CDC mainframes. (The target mainframe
was chosen to be an IBM computer
because the majority of States indicating
a desire to acquire MSIS had that equip-
ment). This was accomplished primarily
through the utilization of the COBOL
copy facility. By placing program source
code which typically varies from main-
frame to mainframe in a COBOL copy
library, necessary modifications at instal-
lation time can be facilitated in a much
more effective and timely manner.
In summary, the decision to design a
computer system for use on a decentra-
lized basis does have an impact on a
system's development, and the extent to
which it is impacted is largely dependent
on who the users will be. Certain design
alternatives could not be considered in the
case of MSIS development; however, the
latest state-of-the-art techniques were
utilized to enhance the system's usability.
Finally, extensive efforts were applied
during the programing of MSIS to insure
its portability to mainframes other than
IBM.
Federal Reporting Data System
Developmental History
During 1976, EPA entered into a
contract with Index Systems, Inc., to
conduct a feasibility study of the design
alternatives for the development of a
computerized federal information system,
which is now known as the Federal
Reporting Data System (FRDS). The
analysis recommended implementation of
a sequential system, as well as outlined
the general systems design of uhe Federal
Reporting Data System. EPA continued in
its endeavor to develop a Federal
information system by entering into a
contract with the Computer Sciences
Corporation for the purpose of performing
the detailed systems design, programming,
testing, and documentation. As of the
date of this report, Computer Sciences
Corporation is in the process of
completing the design phase and preparing
to initiate programming of the system.
Major Functions Provided
Unlike the Model State Information
System, the Federal Reporting Data Sys-
tem is to be implemented in a centralized
manner at EPA's National Computer Cen-
ter (NCC), Research Triangle Park, North
Carolina. Also, the system is intended to
be utilized solely by EPA headquarters
and the regional offices, and not by the
States. Overall, the Federal reporting
Data System possesses the following capa-
bilities:
o Maintains records (inventory
data) on each public water
system in the nation;
o Maintains records on all viola-
tions of the National Interim
Primary Drinking Water Regu-
lations from the previous Fed-
eral Fiscal Year;
o Maintains records on all vari-
ances and exemptions;
o Maintains records on all
enforcement actions initiated
because of failure to comply
with the regulations;
o Maintains summary statistics
for each public water system,
as well as for each State;
o Facilitates production of the
annual report to Congress;
o Facilitates production of com-
pliance statistics to enable
EPA to monitor the perfor-
mance of a State's primary
enforcement responsibility;
and
F-17
-------
o Facilitates response to re-
search inquiries from within
EPA, as well as from indepen-
dent organizations.
Decision to Utilize a Data Base Manage-
ment System
Although, Index Systems, Inc., re-
commended the development of a sequen-
tial system, EPA, after conducting an in-
depth investigation, concluded that a Data
Base Management System (System 2000)
approach would more closely meet the
needs of the Agency, and would facilitate
report production from ad hoc require-
ments in a more timely manner. Index
Systems, Inc., reviewed the DBMS
alternative utilizing System 2000, and
found it very desirable from the viewpoint
of developmental and on-going operations
cost, as well as from its ability to produce
"special" reports in a timely manner. The
decision was based on the fact'that the
DBMS approach involved the maximum
technical risk in comparison with the
other alternatives. Technical risk was
defined as system sensitivity to changes in
the operating environment.
F-18
-------
Test and Acceptance of a System
for a User Other Than EPA
Donald Worley
The Objectives of a Test and Acceptance
The first objective of a test and
acceptance is normally to determine
whether to pay a contractor. This is
especially true in an organization, such as
EPA, where the majority of systems are
developed from an outside source.
Secondly, a test and acceptance
determines whether or not the system is
adequate for release. This is especially
true if the system is released to an
organization other than the system's
developer. As a matter of fact, test and
acceptance is very seldom used in a
situation where a system has been
developed and will be used by the same
organization.
Lastly, utilizing the system in either
a real or demonstration situation will
allow you to round off the jagged edges,
these edges are not a reflection of major
problems in the system, but rather natural
results of a program development cycle.
The Situation at the Time of Action
A test and acceptance will almost
always be done after a late software
delivery has delayed the schedule. Very
seldom do we have the privilege of staying
exactly on schedule. Frequently, the
political commitments for delivery apply
pressure to the test and acceptance of the
system, causing the Project Manager, to
shorten the test and acceptance time. In
other words, in any schedule if there is a
push, the people who get pushed first will
be the test and acceptance team.
Also the developmental contractor
will be in a very defensive position. He
must assist you in a test and acceptance
of the system, but each time you find a
problem it is a black mark on him.
Test and Acceptance Considerations
Inasmuch as you are delivering a
total package (programs, documentation,
methods, forms etc.) to a State or local
Agency, the total system must be tested.
Aspects of the total system include:
o System design
o Program design
o Operating Procedures
o Training facility
o System delivery
o Follow-up support
Furthermore, a proper test and
acceptance of a system requires a two-
part test. First, a "zero installation"
should be accomplished on a Federally
controlled computer. The full team which
will go to the first customer site needs to
be involved, but at this point no user of
the system should participate. Part II of
the test and acceptance is the first
delivery of a system to a user
environment.
The Phases of System Checkout
Let us now discuss the technique or
the phases of software checkout. The
Phase I checkout or acceptance deter-
mines whether or not the system is ready
to begin test and acceptance. It also
determines whether the basic building
blocks of the system work. Do all the
programs function? Can I get in all the
input forms? Can I produce all the output
forms? At the end of Phase I, I have not
determined that the system can do any-
thing for anybody, but I have determined
that the system is ready for checkout.
F-19
-------
Phase II is an individual checkout of
each input and each output form of the
system. The basic goal of Phase II is to
answer two questions: Can I get into the
system everything that has been required?
and can I get out of the system all things
required? At the end of Phase II, I will
have determined that all the transactions
can be entered and that all the reports
can be retrieved, but I will not have
determined whether or not the internal
working of the data over a period of time
is accurate.
Phase III of the test and acceptance
is by far the most difficult, time-con-
suming, and costly of any of the phases.
Phase III defines the reason why a system
is never fully debugged. Nobody has ever
had the time to do the thorough test and
acceptance that Phase III would require;
that is, to check out and test the internal
working of every data item. We must test
to determine whether the data value
which comes in as input is not only printed
out correctly, but that it also gets stored
properly. It is probably better in a true
test and acceptance to divide Phase III
into two parts. In the first stage, Phase
HI-A, we would, at least, test and check
each individual file which is built and go
through at least two or three iterations of
master file updates. This activity will
determine in limited manner whether or
not the data is being maintained properly.
The second stage of Phase III which very
few organizations would ever attempt to
do, would be an extremely detailed,
thorough tracing and checking, to deter-
mine whether the system is doing what it
should do. By the time Phase III-A is
completed, you are at the magical 99.9
percent of being debugged. You can
simply depend upon the use of the system
over a period of years to replace a Phase
III-B test.
The Test and Evaluation of MSIS
Let's now begin to talk specifically
about the Model State Implementation
System test and acceptance. The test and
acceptance team was a highly qualified,
well-organized, properly managed organi-
zation. It consisted of Bill Long, a Denver
consultant. Bill was very qualified to be
the user's representative of the test and
acceptance team. Secondly, I represented
the MIDSD organization as the profes-
sional expert on this system. We had
support from the ISI organization, which is
owned by Systems Development Corpora-
tion, the user services group of COMNET.
We also had considerable amount of sup-
port from the Office of Water Supply.
We followed the two-part process
already described. MSIS had been deve-
loped on the SWORCC system in
Cincinnati; and while there were some
problems encountered in the initial trans-
fer, COMNET was an excellent "zero"
installation. The Part II test was a
delivery to Oklahoma where they knew
they were in a test environment. I think a
good deal of the success MSIS has had was
due to the considerable amount of effort
in Oklahoma.
In the test and acceptance we con-
ducted at COMNET, we followed the
Phase I, Phase II, Phase III process. The
Phase I process occurred without pro-
blems. At times, we had to wait for
certain subsystems. The contractor,
SWORCC, was very reliable and let us
know when various subsystems were or
were not working. There was one subsys-
tem for which we had to wait and some of
the test and acceptance just slipped.
There was pressure to get the system out
into the field, and we did have to do a
fairly rapid test and acceptance. The
Phase II did uncover some source
problems, which required the SWORCC
team to do some program modifications.
The Phase III testing has continued at
COMNET.
Summary and Conclusions
In conclusion, I think it would be fair
to say that I have tried to convince you
that you cannot depend upon the
F-20
-------
developer of a system to do test and the test and acceptance approach, and
acceptance for you. You, must be willing that is to go ahead, install the system, and
to put the effort forward to find out accept the consequences. My recommen-
whether the system does, in fact, work. dation is to use the test and acceptance
Has he done for you what you wanted him process. Thank you very much.
to do? I suppose there is an alternative to
F-21
-------
QUESTIONS AND ANSWERS
Question: In Region IV, most states have installed or are in the process of installing
MSIS. What State procedures have had to change to permit the States to
use MSIS most effectively?
Answer: First of all, we have not had all the States installed. We have three
States that are now operational with the system; they are just beginning
to develop their own usage. As far as the installation is concerned,
however, we did have one situation where we had to hand-carry the
entire installation through the overall management in the State. We had
to circumvent some procedures there that made it very difficult to work
with the system and get it installed. Beyond that, the usage of the
system is still in the "feeling-its-way-through" phase; and we have not
established anything along those lines.
Question: Would MSIS have been designed differently if all the subsystems were
mandatory rather than having five mandatory and four optional subsys-
tems? (Addressed to all panelists.)
Answer: It is important to point out that of the nine MSIS subsystems, five of
them are mandatory and four are at the discretion of the State. In the
four optional subsystems, there is only one, the Variances and Exemp-
tions Subsystem, that would need to communicate with the others.
Possibly it could have been used as input into the Water Quality
Compliance Subsystem. So, yes, there would have been slight changes;
but no major changes would have been made.
CHAIR: I would like to add two things to that. First when I reviewed the MSIS
subsystems, I only mentioned eight primary subsystems; you are referring
to nine. The ninth subsystem, which is non-primary from a management
point of view, but certainly essential from a technical point of view, is
the MSIS subsystem, which performs interactions and various house-
keeping functions. Secondly, in practice, all the States have taken all
nine subsystems. We have no State that has wanted only the basic
mandatory set.
Question: I have a question related to State reporting requirements. Where a State
has not assumed primacy by the end of this December, are we still
required to submit Federal reporting data by January 1 of 1978?
Answer: Yes. For FY 77, if the States do not have primacy by the end of the
year, then you must submit the data acting as a surrogate State. EPA
has responsibility for implementing the Act, and we want the States to
accept that responsibility. When they assume primacy then they are
bound by the requirements of the Act. If a State does not now have
primacy and will not have assumed primacy by the end of the year, the
FY '77 Report would be the responsibility of the Region.
Question: What mechanism is available or planned, for checking the accuracy and
completeness of the data that is submitted by the States?
F-22
-------
Answer:
Question:
Answer:
Question:
Answer:
Question:
Answer:
We are now establishing a very comprehensive procedure. Essentially,
the data will be submitted to the Region in order to check accuracy and
completeness. We have selected the National Computer Center for
installation of the follow-on system, and the types -will go directly there.
We will be able to use their facilities management contract for accepting
the data, entering it into the system, and then updating the System 2000
Data Base Management System, once the Region has certified that the
data is accurate. The data is really submitted through you, but
physically it will go to NCC. You will then access it, do your checks, and
certify it as all right. Once we get that certification from you, the
System 2000 Data Base will be updated.
Do you anticipate maintaining a speciai contract for auditing, or going to
the sources to cross-check samples of the survey data against what is
reported to the system within the region?
No, that would be your responsibility. We will assume that the data is
accurate. We, in fact, will not update the data base until you authorize
it. Through the Federal Reporting System which you will access, there is
a complete set of 26 reports and all of System 2000's capability for
getting the kinds of reports that you will use to make that determination.
You will have, through the Federal System, the capability to perform
those checks. We will do some checks in preparation of our report to
Congress. If we notice anything, we will work through the Region to
correct that; we will also be depending upon you. The responsibility lies
with the Region, but we all share the responsibility and can work
together.
I say a program is never de-bugged. "De-bugged" means that the
frequency of faults is so low that none have been observed in a
reasonably long time. I also want to take issue with saying that STORET
is a centralized system. I would like to say that it is quasi-centralized.
The fact is that the access of data entry, data editing, and responsibility
for data is highly decentralized. We just maintain the system centrally
and provide it as a utility. The system costs nothing in terms of actual
cash, but it needs a definite manpower commitment, which is not free. I
would like to ask one question. What is the total investment in MSIS in
terms of dollars, both in-house and contracts?
$2 million, not counting salaries and OWS staff.
How do you, candidly, feel about the decentralized versus centralized
decision that was made? And if you had to make it again how would you
make it? (Addressed to all panelists.)
The legislative thrust was to involve the States more and more in the
program. If we had centralized, we would not have received as much
State cooperation. If I had to make the decision for MSIS, I would still
decentralize. Currently, we are doing a feasibility study for an ADP
system to service the Underground Injection Control Program, and we
will be faced with that decision. Should there be a decentralized or a
centralized system, to serve the needs of the underground program?
F-23
-------
Answer:
Question:
Answer:
Answer:
With the emphasis on the States' needs and State involvement, we may
decentralize again.
The situation with MSIS may be unique, in that there was a very strong
need to establish primacy, or to have the States accept primacy, because
the Safe Drinking Water Act does rely heavily on the States to do the
job. It is not clear to me, though, that the decentralized system is much
more beneficial over a centralized system, as far as the State is
concerned. We may have to wait and see what happens with MSIS. If
MSIS becomes another CDHS, then there is no question in my mind that
we should have gone with the centralized concept. However if, in fact,
it works beautifully the States use it, assume authority and more
responsibility for their own programs, establish their independence, and
use grant funds wisely for the Safe Drinking Water Act—then maybe it
was better to decentralize. My own personal feeling is that it would
have been cheaper to develop a centralized system. We would have had
to install it in 35 states, and we would have a more powerful state-of-
the-art-type system than what we have now. But I think the jury is still
out, so to speak; we'll see in the future what will be the best way to go.
Having been involved, throughout the system's development on a detailed
basis, I have mixed feelings. From a technological viewpoint, I can agree
in that more state-of-the-art techniques could have been utilized had it
been placed on a centralized basis. No doubt the design, to some extent,
as well as the programing suffered, from the decentralized approach. On
the other hand, having been intimately involved in all the meetings with
State, Regional and Headquarters personnel, practically since the
inception of MSIS, I know for a fact that the States would have outrightly
rejected the use of the system in many cases. It is very difficult now to
get a lot of them to cooperate by simply submitting the requirements
that are in the system that they are receiving, let alone saying that they
have to give the information to the Federal government. That was their
primary complaint. Arguments persisted literally for hours on whether
or not a phone number should be reported. If the system had been
established on a Federal level, many of the States would have just packed
their bags and gone home. And that is why my feelings are mixed.
My feeling is that unless we are fortunate, the Federal Data Reporting
System may have severe troubles over the next couple of years, because
of the lack of reporting requirements. This is a situation where the
concepts were good, but somewhere the power was not strong enough for
good implementation.
I would like to add one thing. In Region IV, we have fairly active
STORET participation. Seven or eight States use the system on a daily
basis. The reason for that, more than anything, is that we, in the Region,
have actively pursued their usage for some years now. I do not
necessarily agree that the States would have outright rejected the
system. If they wanted primacy and if there was a system available, I
feel pretty strongly that most of them would take it, and most of them
would use it, rather than develop their own things, particularly if there
were no grant funds available. The key issue is the funding of such a
-------
system. There are some States that just cannot go outside the State and
pay for usage of a computer or a computer facility. Some states have a
law that prohibits it. If the funding issue could have been resolved,
similar to the STORET sub-allowance, I think that would have been a
strong point, definitely, to have centralized.
CHAIR: Well, if there are no other comments or questions, that concludes our
presentation. Thank you.
F-25
-------
PANEL G: ADP MANAGEMENT
Chairman: Kenneth Byram
Panelists: Joel Brandon
George Lehnert
Bruce Rothrock
Douglas W. Shape
Michael Steinacher
INTRODUCTORY REMARKS
Kenneth. Byram
The idea for this panel came out of, as ideas for most of the panels did, the zero-
based budgeting committee or the zero-based budgeting process that went on this summer.
Without trying to embarrass him, I think the idea for this panel came from George Lehnert
and assisting him was Bruce Rothrock, at that time, they suggested that it might be
healthy to debate or to discuss how data processing ought to be managed in EPA, and how
or where functions ought to exist. What should be done in a central way, or maybe what
should not be done in a central way. In the charter to the panel members, I asked them to
be aware of either specific kinds of suggestions such as whether MIDSD should be
abolished, or general kinds of suggestions, such as ADP should not be centralized within
EPA. On the panel are people with varying perspectives about this thing. Two of us on
the panel are from MIDSD, two from regional offices, and two are Headquarters ADP
coordinators. Let me introduce them for those of you who don't know everyone here. On
my immediate left is George Lehnert, who is in the Office of Program Management,
Office of Water and Hazardous Materials. Douglas Shape is Management Division
Director from Region 4 in Atlanta. Bruce Rothrock is the Agency Coordinator in the
Office of Enforcement and is also in the Program Management and Operations area. Mike
Steinacher recently changed jobs and is now working for the National Computer Center.
Finally, there is 3oel Brandon who is no long with EPA. As a short-timer, he can say
anything he pleases and probably will.
G-l
-------
"Those of us involved in Automatic Data Processing in the Environ-
mental Protection Agency lost a valued source of advice and forcefulness
when Dr. George Lehnert died in May, 1978. We are sure that many of
George's thoughts as reflected in the panel seminar on ADP Management will
provide guidance in the events and years to come in EPA ADP Management."
MIDSD: Coordination and Integration
George Lehnert
I find it awfully unfair to blame this
whole ugly mess on me. As a frame of
reference for my introductory remark, I
go back to the functional statement for
the office, for MIDSD, as a reference. I
think we can look at this as two different
kinds of functions. The first of these has
to do with the development of a manage-
ment information system. I do not know
whether that means a management infor-
mation system in the strictest sense, or
whether that encompasses all data pro-
cessing systems within EPA. Subsets
under that would be things like formu-
lating policies and objectives and develop-
ing guidelines and standards for admin-
istering a comprehensive agency data pro-
cessing program. I guess the word "com-
prehensive" here is up for grabs because I
am not sure what that means, in terms of
what it is MIDSD would like to be doing.
The second function is providing the
Agency a focal point in the integration.
Information systems can cross functional,
geographic, media and technical lines. On
that item, I want to say a few words. I
have been under the impression that
MIDSD has not done enough in terms of
coordinating the systems across these
lines functional, media, etc. One good
example of where they did what was, in
my opinion, a proper job of coordination
was in the Water Supply Program, in the
Model State Information System and in
the Federal Reporting System. In all
fairness to MIDSD, I think that the
operating programs need to take an
initiative very early in the game and to
bring MIDSD in to say, "We are starting to
look at the front end of the system design,
the feasibility study, perhaps, and we
want you in it from the very beginning as
we do the other program offices in the
Agency, such as Enforcement, etc., etc."
Often, that is not done. The reason that
it is not done is that the operating
departments start paying some attention
to the fact that they will need an ADP
system of some sort. Quite often for
most of them, they are not even thinking
about what it is they are going to be
doing, because what it is they will be
doing is farther down the line. An
example is Enforcement. Normally, En-
forcement would not be initially con-
cerned, because their work does not come
until about two years later. By the same
token, in ORD, they have ongoing R&D.
It is not in their cards to be doing
something about this particular system at
this point in time, because they are not
brought in. Unless someone from the
water program goes to MIDSD and says,
"We are starting to take a look at a
system, which is mandated by the Act.
We want to bring you in early in the game
and keep you in. In addition to you being
in on it, we also want you to coordinate
across agency lines to bring in Enforce-
ment, ORD, regions, labs, or whatever."
I have given you what I thought was
a good example of the operating program
bringing in MIDSD early in the game, and
MIDSD's response being to play a coordi-
native role. In contrast to that, let me
use the Hazardous Waste Management
System, as a poor example. This system
ran down the road for several months, at
least, before anyone from MIDSD or En-
forcement or any of the other offices got
involved. There are occasions where it
has been done well and very thoroughly.
What I'm advocating here is a stronger
G-2
-------
role by MIDSD in terms of coordinating
and integrating information systems
across functional, geographic, media, and
technical lines.
Another subset of the development
of an agency management information
program has to do with the development
and maintenance of the Agency's overall
management information system. Here,
once again, I have problems not knowing
what these words mean. What is the
Agency's overall management information
system? Still another subset is planned
coordination. Maybe I do not have a
proper perspective because I am in the
Office of the Assistant Administrator;
perhaps, program people in the individual
programs will have a different perspective
on this. I would say that, to the extent to
which I am aware, primarily relates to
training programs in these areas, and
some documentation along these lines.
One problem that I have had in mind
with respect to these kinds of things has
to do with where, in the organizational
structure, MIDSD is located. That is a
question that I have had and one we will
discuss today with enough points of view
that we will have a data base, from which
we could then go forward or backward.
What I mean by being improperly
located organizationally is that, in the
Office of Administration, one normally
thinks of services of some sort being
provided. I do not look at the things that I
talked about as services, per se. I look at
them more as management kinds of
things. In the coordination across
functional lines and similar kinds of
things, MIDSD would take the lead. I
guess in the absence of any recommenda-
tion, I can only say that it ought to be
looked at from the standpoint of putting
those functions about which I have talked
under the AA for planning management,
or perhaps directly under the Admini-
strator. On the other side of the coin,
there are some bona-fide Agency services
provided. In other words, we have been
talking about real management kinds of
things so far, but here are some services
that need to be provided. There are some
provided by MIDSD, such as determining
the need; arranging for the establishment
of EPA computer centers; prescribing
guidelines covering the operations and use
of data processing equipment; operating
the Headquarters; providing technical
guidance to field installations in ADP
operations and applications. Those things,
I think, are legitimately services and
perhaps should be provided from an orga-
nization which sits in the Office of Ad-
ministration. However, I contend that at
least it ought to be looked at from the
standpoint of breaking it into two pieces,
i.e., putting one services unit in the
Office of Administration and the other
one, which provides real technical
direction and coordination directly
responsible to the AA for Planning and
Management.
G-3
-------
QUESTIONS AND ANSWERS
Comment: In terms of the Agency's Management Information System, the language
was put in several years ago, when people were thinking in terms of one
Management Information System for General Motors and another one for
EPA, and another for the State Department. These would include all
facets of management information; namely, personnel, payroll, grants,
etc. In fact, there has been some allusion to the need for coming up with
that here at the conference. Yesterday, there was quite a bit of
discussion about combining OPM systems, making finance and grants one
system. I think everybody has in the back of their minds somewhere, an
image of what a total management information system would be. It
consists of the systems and an Assistant Administrator sitting down in
front.of the CRT console typing some nebulous inquiry that results in
exactly the information that he needs to make a prompt, quick, accurate,
and incontrovertible decision. I think that if that is the image, then that
is probably a little out of date in terms of what people now realize is
practical or possible with one central information bank.
Question: Is the term "Agency Management Information System" synonomous with
the administrative systems? The question is: Are those two terms
synonomous?
Answer: As / see it, the administrative system is one which is used for those
things which are normally associated with OPM, what is identified by the
government as administrative overhead or administrative tasks as
opposed to program management which you would have to include in MIS.
Grants, for instance, are handled by OPM, but used by the regional water
programs to track their progress and award grants. It is therefore in the
Management Information System, but not in the context of an
administrative system.
Question: I was going to comment on how I would interpret an agency management
information system to be if four or five years ago, you tried to write the
responsibility paragraph for the MIDSD organization. If you think about
the Agency's responsibility to the environment and to society, you would
be interested, not in the administrative system so much as what are we
doing nation-wide that has resulted in some kind of an environmental
cleanup. How can we measure the progress toward this? Where are the
significant problems arising and how can the top management, that is at
the AA level and above, address these issues and be sure that we are on
the right track? In that regard, I also looked at the responsibility
paragraph within the organization manual and was quite confused about a
lot of the language in there regarding MIDSD's responsibility, particularly
with regard to the Management Information System. I could not see
anywhere within the Agency that MIDSD was running, directing, or
assuming responsibility for this or is there any one type of system like
that in existence?
-------
does not have a mission. They do not have a piece of legislation that
they are enforcing. Yet is seems to me to provide a much clearer goal
than some of the other ADP programs, like GICS, which has a mission
and yet does not have nearly the reputation.
Comment: The STORET that you are picking up here is one in which I have been
interested for sometime. I do not often allow myself to complain in
public. Frankly, I have been in EPA since 1971, over six years now. I
have watched some things evolve and some things not. One of the basic
things that took me a long time to figure out was brought into focus one
day when Jim Tozzi, who is the OMB Budget Examiner for EPA, was up
for a briefing, the first time Jim Tozzi had every been out of
Washington. Regional Division Directors were going through the briefing
drill which we had down at that point pretty well. I was watching Jim
very closely, which is one of my hobbies. I can see lights coming in his
eyes every now and then. He was asking questions that indicated to me
that he was understanding sometimes. The things that he was
understanding was sort of how the Agency's programs fit together, which
is how water and Enforcement and Water Quality Standard, those type of
things, all fit together. I was sitting and thinking, my God, why is this?
We are certainly not nearly as smart as all those people in Washington
collectively. I am sure they have been over there telling him all about
these great things. It finally dawned on me that they had. They could
not probably explain to Jim Tozzi, because they did not know themselves
how these things fit together. Only at a regional level does the Agency
come together. My point is that, very simply, the Agency dogs not have
a strategy. There is the water strategy, and there is an effluent
guideline, but none of them fit together. You are talking about tails and
dogs and that does not make a lot of sense. Frankly, the problem is that
you can not design an information system and build an Agency around it.
In relation to what Joel was saying, there was an information system
called STORET. The Agency just happened to fit around it. That is
almost serendipitous. What has to happen to leadership to the Agency is
to decide what we are going to do. Then all of us get together, whether
we are building information systems or environmental quality. There is
the problem. That is why there is no Agency Information System. The
system provides some things that are required by law, and some things
that are not required by law, and some things that people want to build
because they happened to be in the right place at the right time. We
have a mish-mash of the systems that we have inherited or built, and
they do not fit together. We constantly wrestle with this problem, I do
not think you can put the systems that we have together. You have to
build them. You start with an idea that they do fit together; they do use
common data words, and you start from that point. We talk about the
organizational placement of this division or this function. I am not sure
it makes a lot of difference. It would adjust certain problems, but until
the basic problem is solved, we are just working on the symptoms. That
is where I have been for two years, trying to figure out what to do.
G-5
-------
Answer:
Comment:
Comment:
Comment:
Comment:
Comment:
In terms of the environmental system that would meet the Agency's
needs, as opposed to an administrative system, you could make a similar
analogy in the practicality in trying to combine all of the environmental
information into some sort of tracking system that would tell us whether
we are making progress or where there are areas where we need to put
more fuel on the fire to solve the nation's environmental needs. I guess I
am still not comfortable with that wording. Perhaps, if it were
interpreted and changed to mean the Agency Management Information
Systems or the Agency's Management Information Program, it would
make a little more sense. I think the wording is in there historically,
because, at one point, the way the future was going was to be one
Management Information System that would tell people what they
wanted to know, whether that be administrative or technical. Are there
other comments at the moment?
ADP is often considered the tail of the dog. I do not particularly like
that, but I think it describes a condition that, unless the program
manager tasks are orderly arranged and you know what they are, the
kinds of measurements you need, etc., etc., it is very difficult to use the
ADP system for something which you do not know. Bruce had referred to
an environmental meansurement of conditions. Until we, in the Agency,
can come up with some environmental index of some sort and measure
that, then it is pretty difficult to design an ADP program to handle it.
There must be indices, some basis of measurement, or something outlined
to determine whether or not the environment is getting better or worse,
or whatever. I think it would be unfair to expect MIDSD or any body else
to come Up with ADP systems until that is defined.
I think that's a very good point.
In addition to trying to coordinate our ADP, I have also been working in
that area to some degree. Frankly, we found ourselves getting almost
nowhere. Maybe there are some brains in the Agency who have
something cooking that is ready to pop, but I do not know about it.
In looking at systems, groups, or concentrations of ADP expertise within
the Agency, the ones that seems the most successful are, in part, so
because of the people running them, but also, in part, because they know
what they are doing. I could think of some negative ones, but I will not
mention them. I think the STORET group has a clear idea of what it is
trying to do. I think occasionally, it wanders off into some areas where
it does not have a clear idea and gets into trouble, but, in general, there
is a very clear mandate there with a whole lot of effort. As a result, it
comes out to be a better ADP system than it would if it did not have a
careful charter. I think if you start with the tail, you do not end up with
much of a dog.
This is true. I think STORET has set some goals. Apparently, what you
are saying is that you do not need the dog if you have a tail that can set
its own goal. The air system has a similar purpose and yet the air
systems are known to be not as good as STORET is. As I said, STORET
G-6
-------
Comment: I would think that the further up you are in the organization, the stronger
would be the ear of the person to whom would be listening, whatever it is
you say.
Comment: I think that maybe what Willis is saying is that if you start out saying,
"Gee, we want to be a staff office of the administrator." What you
really need is to have is the Administrator say, "Why / reaZZy need a staff
office to do this." Without the Administrator fully understanding why he
needs a staff office or the AA, it would not work.
Comment: I could go back to another analogy, for which, I am probably famous now.
I remember back in the early days of the Agency, that first crop of
regional management directors were constantly asking Howard Messner
to get the men to see their boss, the Regional Administrator. If I was
the appointed one to advise the Administrator on information systems, I
could not advise him unless he wants to be advised. I would have to
prove myself worthwhile to be in there in the first place. That was the
same thing with the first round of management directors. It was
difficult being useful, being accepted. I think a year ago, when we had
the steering group, I think the organizational placement was not as
important then as it is now. In the sense that you had an AA involvement
in some top-level kinds of decisions relative to ADP.
Comment: The thing I am hearing from George and Willis sums up. There may be
advantage in having an organizational change to get ADP closer to the
top, but only because the people in ADP know, more than anybody else,
what the Agency should be doing and what it lacks. Certainly nobody
else in ADP realizes that there is not an agency strategy, which if that is
true, I do not know how much difference it will make. If you get to the
top, and they do not know, our telling them will not make a difference.
Comment: I have not tried to say that, but I will say this, that I think it is
important. I would not go so far as to say that there is not a foundation
laid relative to the kinds of things we are talking about. I am saying that
until the Agency does something concrete in determining what its
strategy is, until there is a measurement of some sort available in these
areas, it makes designing the ADP systems awkward and aZZows us to run
in all kinds of directions, adding to the problems that already extst.
G-7
-------
ADP Management and Organization
Bruce Rothrock
Too often in the ADP area we limit
the management concerns to feasibility
studies, system design aspects, hardware
and software considerations, software
maintenance and operation. We worry
about storage space, job processing time,
software enhancements, ADP budgets and
the like, and concentrate all of our efforts
on the details related to matters of
secondary importance. The area requiring
the most emphasis, and certainly the one
to which computer-related management is
subordinate, is information management.
The Agency spends far more time con-
cerned about the software for data sys-
tems and data bases than it does about
information and the ability of the data in
these systems to provide information to
managers about their program areas.
What is of even more concern is the
amount of duplication throughout the
Agency in data collection, systems devel-
opment, and data processing, and the
general disinterest in developing common
data bases and data gathering activities.
The DA has indicated that data is a
valuable resource and that more effort
will be needed in the future to share and
cooperate in the gathering and use of
data. We must recognize the need to
share data across media and between
program offices.
A limited analysis follows that
creates an organizational structure that
coincides with the responsibilities
assigned to four broad areas of Informa-
tion, Data, Software and Hardware
(Figure 1).
The four areas have been arranged
in a hiearchiacal order: Information,
Data, Software, Hardware. This top-down
approach placed more importance on
areas that historically have not been given
much attention and conveys the concept
that software and hardware can be given
secondary interest behind information and
data. This arrangement also suggests that
perhaps each area should be managed
differently. Certainly hardware manage-
ment and information management are
not similar, and if we compar the func-
tions and activities between the three
pairs of adjoining areas it is easy to
recognize the potential for separate
management of all four areas.
There are numerous functions within
the Agency related to data processing.
Several have been identified and assigned
to one of the four categories. Initially
only the functions have been defined;
responsibility for the functions will be
analyzed later. The first category, infor-
mation, has activities associated with
information requirements analysis, and
data base establishment and maintenance.
(Figure 2). These include definition of
information needed to carry out program
objectives, determination of currentness
and accuracy of data that will be needed,
understanding sources of data, auditing
data bases to ascertain if they fulfill the
needs as defined, and periodically review-
ing and reevaluating information require-
ments.
Broadly the functions related to the
second category, data, deal with the
definition of data items/data elements,
data element standards, how the data will
be collected (including forms .designs),
data capture, data structure and
dependancy, and data base administration
as used in connection with data base
management systems (DBMS) (Figure 3).
The functions detailed system
design, program development and testing,
and system operation and maintenance
fall in the software category. (Figure 4).
G-8
-------
ADP FUNCTIONS
INFORMATION
DATA
SOFTWARE
HARDWARE
FIGURE 1
-------
FUNCTIONS
INFORMATION
' INFORMATION REQUIREMENTS ANALYSIS
' INFORMATION USES AND OUTPUTS
1 COMPLETENESS, CURRENTNESS, AND ACCURACY REQUIREMENTS
1 DATA SOURCES
1 DATA BASE AUDITS - DATA VERIFICATION
' DATA BASE - DM50
1 RETRIEVALS: OUTPUT REPORTS, DATA ANALYSIS, DATA REDUCTION
AND SUMMARIES
FIGURE 2
-------
FUNCTIONS
DATA
1 DATA ELEMENT DEFINITION
1 DATA ELEMENT ATTRIBUTES
1 DATA VALUE STANDARDS
' DATA VALUE EDITS
1 FORMS DESIGN
1 DATA CAPTURE AND INPUT
FIGURE 3
-------
FUNCTIONS
SOFTWARE
1 FEASIBILITY STUDIES
1 DETAILED SYSTEM DESIGN
1 SOFTWARE - DFI&O
' AUDIT OF SYSTEM SOFTWARE & SYSTEM DESIGN
1 SPECIAL APPLICATIONS AND ANALYSIS
FIGURE 4
-------
Functions in the hardware area per-
tain to the procurement and use of hard-
ware and hardware services that match
the Agency's needs. (Figure 5). Some
specific functions relate to low speed and
remote job entry terminal purchase, data
center operation, data center access
authorization, telecommunication, ac-
counting for resource utilization and
billing, and user communications and sup-
port.
The next step in the process looks at
who within the Agency does these func-
tions, who assumes or was responsible.
Figure 6 identifies which of four organiza-
tions has responsibility for the indicated
functions. The observer immediately
draws ihe conclusion that considerable
duplication and overlap exists. From
experience we know that contention fre-
quently develops, redundant data collec-
tion occurs, similar systems are
developed, and occasional confusion exists
over who has responsibility, especially in
the software area. Many people and
organizations throughout the Agency have
interest in software related functions.
Program offices generally write the
software, MIDSD likes to see that feasi-
bility studies have been conducted and
occassionally conducts audits. They try to
assure that proper consideration has been
given to the design and development of
software applications.
Several problems arise from this
organization of responsibilities:
1. Considerable duplicaton exists
in data gathering, systems develop-
ment, and systems operation.
2. Duplicate or similar data
items and values exist in different
systems.
3. No standards exists for data
elements and values and conse-
quently data cannot easily be shared
among systems.
4. Because of the multiplicity of
responsibilities that a program
director has he frequencly makes
decisions for which he doesn't have
the training and should not have the
responsibility.
A radical approach to overcome
these problems separates responsibilities
by division and eliminates or reduces
duplication of responsibilities. Figure 7
lists the same functions as in Figure 6, but
assigns primary responsibility for func-
tions to one of four areas. The program
offices and divisions maintain responsi-
bility for the functions related to
information requirements and data base
maintenance. Program Divisions would
have little need for programmers and
computer systems analysts. A new divi-
sion, the Data Coordination and Manage-
ment Division, has responsibility for data
element definitions, standards, and data
collection. In today's terms these
functions of a data base administrator
belong in this division. It takes on a
broader responsibility of translating infor-
mation requirements defined by program
divisions into data items and coordinating
these among the various divisions to
eliminate redundant data gathering activi-
ties and promote data sharing.
Another new division, the ADP Soft-
ware Services Division, takes the respon-
sibility for the software development,
operation, and maintenance functions.
Systems like GIGS, PCS, and STORET
would be operated and maintained from
this division.
Finally, the ADP Computer Services
Division has the responsibilities of
establishing and running the various data
centers, and other related functions.
Because of the relationship and de-
pendence of the three new divisions they
would have to exist in the same
organization of the Agency, preferably
directly under the Administrator or
G-9
-------
FUNCTIONS
HARDWARE
1 REQUIREMENTS ANALYSIS
1 PROCUREMENT
• SERVICE/CONTRACT MANAGEMENT
1 USER AUTHORIZATION AND REGISTRATION
1 USER COMMUNICATIONS
1 USER SUPPORT
• UTILITIES
1 OTHER EQUIPMENT PROCUREMENTS
1 ACCOUNTING OF RESOURCE UTILIZATION
FIGURE 5
-------
CURRENT RESPONSIBILITY FOR FUNCTIONS
RESPONSIBILITIES
INFORMATION
1 DEFINE INFORMATION REQUIREMENTS
1 DETERMINE How INFORMATION WILL BE USED
1 ESTABLISH COMPLETENESS, ACCURACY, AND CURRENTNESS REQUIREMENTS
• DETERMINE DATA SOURCES
1 DEVELOP, MAINTAIN, AND OPERATE DATA BASE
1 ANALYZE AND REDUCE DATA
DATA
' DEFINE DATA ITEMS
1 DESCRIBE DATA ELEMENT ATTRIBUTES
1 ESTABLISH DATA VALUE STANDARDS
1 DEFINE DATA VALUE EDITS
1 DATA COLLECTION AND INPUT MECHANISMS/PROCEDURES
1 COORDINATE ACTIVITIES AMONG OFFICES
SQFWARE
1 ASSURE THAT ADP USE WILL MATCH REQUIREMENTS
' MAKE EFFICIENT AND EFFECTIVE USE OF RESOURCES
' DEVELOP, OPERATE AND MAINTAIN SOFTWARE
' REVIEW SYSTEM PERFORMANCE AGAINST CRITERIA
' DOCUMENTATION
HARDWARE
' PROCURE OVERALL SYSTEM RESOURCES
1 ASSURE SYSTEM AVAILABILITY AND RESPONSE
1 CONTROL ACCESS TO RESOURCES
1 PROVIDE ACCOUNTING OF RESOURCE UTILIZATION
1 GUARANTEE THAT RESOURCES ARE USED EFFECTIVELY
' MAKE HARDWARE PROCUREMENT BENEFICIAL AND EFFECTIVE
X - Primary Responsibility
/ - Secondary Responsibility
PROG
DIV MIDSD
X
X
X
X
X
X
X
X
X
PRO
RO
ADP
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
/
X
X
X
X
X
X
X
X
X
X
X
FIGURE 6
-------
PROPOSED RESPONSIBILITIES
RESPONSIBILITIES
PROG
INFORMATION DIV DCMD
1 DEFINE INFORMATION REQUIREMENTS x
1 DETERMINE How INFORMATION WILL BE USED x
' ESTABLISH COMPLETENESS/ ACCURACY/ AND CURRENTNESS REQUIREMENTS x
' DETERMINE DATA SOURCES x
1 DEVELOP/ MAINTAIN/ AND OPERATE DATA BASE x
1 ANALYZE AND REDUCE DATA x
DATA
' DEFINE DATA ITEMS / x
1 DESCRIBE DATA ELEMENT ATTRIBUTES / x
' ESTABLISH DATA VALUE STANDARDS / x
' DEFINE DATA VALUE EDITS / x
' DATA COLLECTION AND INPUT MECHANISMS/PROCEDURES / x
1 COORDINATE ACTIVITIES AMONG OFFICES / x
SOFTWARE
' ASSURE THAT ADP USE WILL MATCH REQUIREMENTS
' MAKE EFFICIENT AND EFFECTIVE USE OF RESOURCES
1 DEVELOP/ OPERATE AND MAINTAIN SOFTWARE
' REVIEW SYSTEM PERFORMANCE AGAINST CRITERIA
' DOCUMENTATION
HARDWARE
1 PROCURE OVERALL SYSTEM RESOURCES
1 ASSURE SYSTEM AVAILABILITY AND RESPONSE
' CONTROL ACCESS TO RESOURCES
' PROVIDE ACCOUNTING OF RESOURCE UTILIZATION
' GUARANTEE THAT RESOURCES ARE USED EFFECTIVELY
MAKE HARDWARE PROCUREMENT BENEFICIAL AND EFFECTIVE
X - Primary Responsibility
/ - Secondary Responsibility
ADP
SSD
ADP
CSD
X
X
X
X
X
X
X
X
X
X
X
FIGURE 7
-------
Deputy Administrator. Such an organiza- political appointment or changes in ad-
tion could be the Institute of Information ministration. This office would have the
Technology and Data Processing, headed goals of "service, coordination, and stan-
by a career individual not subject to dardization."
G-10
-------
QUESTIONS AND ANSWERS
Question: I have a question. If the Systems Services Division will finally be
primarily responsible for software services, why can not MIDSD not be
responsive in its present form since it has that as a part of its bag? What
will cause you to be more effective then than now? Is it position in the
organization?
Answer: I think the position in the organization has a lot to do with it. The fact
that they have two things. The position under an AA ship does not give
them the direct responsibility to the line organizations or to the program
offices within the Agency. It is always up and over and down. That does
not work well within this Agency. The other thing is that because we
have little caches and groups of ADP expertise scattered throughout the
Agency, there is always a butting of heads about different decisions that
need to be made on a particular software development systems design.
Question: You have three organizations now having a responsibility for the
software. In the present organizational structure, why can not MIDSD be
given the prime responsibility in its present form? In other words, I do
not understand how you wipe out the program and a few ORD
responsibilities when you restructure the organization?
Answer: This gives a broader role to MIDSD, re-labeling it is all that it was
attempting to do. MIDSD and PRO have been caught up in the
responsibility of the data coordination, the management division, which I
suggest as a radical approach. Along with their present responsibility,
the visibility within the organization is important. I do not think that
where they are located, at this point, provides the proper leverage and
authority to carry out that responsibility.
Question: Where would the regions fit in your plan?
Answer: / did not go through this in all the details that are really necessary.
Regional offices did not get much focus. They would operate pretty
much in the same vein as they are now. The way they have been
centralized in the last three years is that regional data branch becomes
responsible for most of the regions' data processing activities. You will
still find that in some regions. Some of the program offices have
programmers who are writing special analysis programs to look at air and
water data. That is an area, too, that I did not look at too closely.
Question: I have a question having to do with what does the Deputy Administrator
mean when he said data is a valuable source?
Answer: Spending too much money.
G-ll
-------
COMMENTS
Comment: / would like to talk a little bit about the consolidation-decentralization
issue from a regional standpoint. If, in our particular region, we
consolidate or centralize everybody who is involved in ADP and the
region, I suspect we will have a branch consisting of about 50 people. We
have about 600 in the region. Everybody is dibbling and dabbing in ADP,
EDP or whatever you want to call it, but I do not think from a regional
perspective that it makes a lot of sense. If you took all the people, you
would have too many, but if you selectively took some people and freed
up those other ones to do some technical business towards the control
solution, it might make a lot of sense.
Comment: If we look at the centralization issue, whether it is Headquarters or the
region, I think it's important to look at the responsibilities that ADP
people have. I know that within most of the regions, a lot of the people
who might probably associate with ADP have a responsbility related to
the data input, the review of edit messages, the checking of the data
base, and the running of some retrievals which I would classify as
responsibility that is associated with the program office, i.e., managing
the data base itself is not really an ADP function, per se. The fact that
they have to use some ADP equipment to get some of their work done, I
think is incidential. The real responsibility there is to manage the data
base and the information in it. I would not think in the centralized
process that you would pick these people up necessarily, because they
would be assigned to the program divisions which should be responsible
for the data in the system.
Comment: One thing that was interesting to me was the training survey. The
contractor came back with some enormously high percentage, like one
out of three, or one out of four, people in the Agency were involved in
ADP. The training plan came back from the contractor saying that,
basically, it was at least one out of 10. It seemed very high and still
does. One out of every 10 people that you would run into in EPA were
ADP people. The problem with that was that there were an awful lot of
scientists, engineers, biologists, administrators, and secretaries and so
forth, that end up doing data processing-related work. I think we just
heard an interesting point. If you centralize all those people, you end up
with centralizing a good chunk of the Agency in one response, so that the
challenge is to separate out where there have been mixes of functions,
where a secretary is also a data enterer, a scientist is also a FORTRAN
programmer. If you separate out those functions so that you have the
scientist doing science, and the FORTRAN programmer supporting him,
that makes them both effective.
Question: At what point in this program was it suggested that ADP be
centralized? I do not recall having heard that.
G-12
-------
Answer:
Comment:
Question:
Answer:
I think, at least from a regional standpoint, we have long been on
the road of centralization. We have, in fact, about 80 percent of
that goal of centralization reached. It has worked effectively.
We are not there yet, but we will get there.
I would like to suggest another concept. The divisions, branches,
sections within the program offices certainly cannot have all the
capabilities required for the conduct of all kinds of feasibility
studies, audits, system design, and these types of things. There-
fore, in my opinion, there needs to be some centralized resource
for these kinds of capabilities. We can go to the DM&.O contract
for these kinds of things, but here, once again, it seems to me that
when that is done with regard to a system or a contemplated
system, then it ought to be done by a centrally-located organiza-
tion who can then look across functional and media lines and pull
it together. I look at that from the Headquarters Program Office
point of view.
Do the regions have any of these needs for a centrally located
systems unit within MIDSD or elsewhere? That is a question that I
want to pose.
In one word, the answer is yes. There are a lot of things we would
like to do throughout the regions, but we can not do.
G-13
-------
ADP Problems From a Manager's Perspective
Michael Steinacher
As Ken mentioned, I am from Willis"
North Carolina family. I do not know if
you saw the Godfather replaying on tele-
vision, but it certainly is a good example
of management theory and practice that
sure works. Whether you are theory X or
theory Y, that is one with which you
cannot argue. Ken did ask me to try to
stimulate some discussion and interaction
between the panel and the audience on
thought provoking ADP management
issues. I will attempt to do that. It is
awfully hard for me in my position to
disguise some of my own opinions and
philosophies. I think I could probably
argue some topics from either point of
view, but I do believe you will agree with
me that the topics of the conversion,
contracting, and centralization, even
though they may be of secondary impor-
tance, represent something to stimulate
thought and provoke conversation.
There are a number of problems that
face us as ADP managers as we project
into 1980 and the 1980 procurement. I
have tried to summarize some of the
problems that seem to be most mean-
ingful. I would like to share some of this
with you. It has been interesting this
week to communicate with people that
are knowledgeable in the areas of agency-
wide systems. It seems, however, that the
Agency is spending hundreds of thousands
of dollars on systems that, if you believe
what people say, are generally non-res-
ponsive. Systems that just do not seem to
satisfy management's requirements or the
intended user-application of the system.
We suffer, in my opinion, from what
seems to be a technological lag within
ADP and EPA. I can discuss many of the
data center specifics, but it does seem to
me that watching things running in our
UNIVAC we see an awful lot of second-
and third-generation technology, if you
will, being applied to what I would des-
cribe as fourth-generation problems.
There is a data center technological lag.
We are certainly faced with the problem
of limited resources. As managers, we
are going to be faced with increasing
demands placed on resources that are
available to us.
Additionally, we are all going to
affected by the 1980 procurement,
whether we like it or not. Odds are pretty
good that whatever is selected, it will not
be exactly what we want. So the whole
business of getting prepared for that
eventual conversion is something that
confronts us all. In terms of resources, if
your organization is anything like ours, we
will see more of a decline in in-house
resources, i.e., government resources.
These are clearly declining. Contractor
resources are, of course, available to us. I
think it is pretty clear that this is the
direction in which the government is
going. For those of us who either are or
claim to be able to clear memory in six
instructions, we find that this is changing.
We are playing a different role. As
technical managers, we are faced with the
whole process of re-tooling personnel.
I mentioned earlier that I was going
to attempt to cover three thought-pro-
voking topics. The first of which deals
with conversion, with which we all are
going to be faced. Conversions are topics
dear to my heart. Along with some of my
other NCC colleagues, I share the credit
for having affected today successful con-
version from IBM to UNIVAC. I am sure
that there are those of you who are aware
of how successful that conversion was and
how sweet it was. My past experience is
more in private enterprise than in govern-
ment, but I really do not see much
difference in the way conversion effects
organizations either inside or outside the
-------
government. It is a painful process. I
think that the success of a conversion is
really relative to degree of motivation
does not necessarily apply to all of the
inter-application systems about which we
are concerned.
In my opinion, the biggest problem
that any organization faces in looking
toward conversion is the attitude problem.
It is simply an acceptance of change and
an acceptance of the responsibility that
you, your staff, and your colleagues share
in that overall process of conversion. You
see some interesting attitudes. I think if
all of you would think for a moment you
would probably recall some of these
things, too. You hear comments like,
"Those turkeys bought it, by golly, they
can install and convert it. I have to sit
back and do my job." That is a great
ostrich attitude. You can stick your head
in the sand and say, "Those fools bought
that UNIVAC machine, they can make it
work."
In looking at conversions, we cer-
tainly can not ignore the very real pro-
blems of limited resources. There are the
technological differences. We all talk
about transportability and compatibility.
The facts are that if you go from Brand X
to Brand Y, you have a problem. Our
conversion, as we experience it, is one of
the real parts of the iceberg, that was just
not apparent to us, as we went from IBM
to UNIVAC. I think as managers we have
to consider very early in the game the
whole process of test and acceptance.
Conversion is part of it, whether it is
converted for us, we still bear the respon-
sibility of testing it and ultimately ac-
cepting it. Then the whole business of
paralleling those production systems on
your current computer with the converted
systems on the new one. It is a tricky
business. It has to be choreographed
pretty well. Ultimately, it will mean
success if it is handled properly. Another
thing, as managers, we can not ignore in
talking about conversion is kind of an
interesting phenomenon. You find that
the most non-responsive system in your
entire application mix, the one to which
you just do not want to own up because it
does not work well. You will find,
however, that this particular system, once
it is converted, becomes the most classic
example of high technology that you have
ever seen in all your life. Your recollec-
tions are always fine. It really was an
example of high technology. The thinking
is that if it was bad then, it will be worse
on the new one, no question about it.
What should we do now? A lot to be done
to be sure. It takes a lot longer than the
next 10 minutes to try to discuss.
Documentation is another topic. I
do not see any short cuts there. I think
that as you plan for the next three or four
years, that this is the time to develop if
you have not already. Some have to
complete programs, systems, and
operating documentation with the
emphasis on your ECL or JCL techniques
that oftentimes materially change. You
need to document the logic of the pro-
gram at execution time. You need to
quantify current performance. As we go
back to the high technology phemonenon,
you want to be able to measure, at
conversion time, just what that product is
when it is converted and finally delivered
to you. Along with documenting current
performance, I think you need to consider
current operating cost, and examine them
as you plan for the conversion and as you
go through your test and acceptance
process. I think you need to coordinate
very carefully the dynamics of your cur-
rent system and current programs in
respect to the conversion freeze which is
going to take place at some future point
in time. Granted all of our operational
programs can not function in a static
state for the next three years, change has
to take place. I think you have to
carefully demonstrate that change can
occur despite the freeze that undoubtedly
has got to be placed on making changes to
these systems as you approach the 1980's
conversion process. It is a good time to
police the accumulation of unnecessary
programs and unnecessary data files. It is
a good time to effect a good house-
cleaning, so that when the conversion does
G-15
-------
take place, you are not wasting time,
funds and resources converting things that
are never really used. We need to
emphasize the use of standard high-level
programming languages: COBOL,
FORTRAN, PL1. We need to think about
it now; that is the whole business of
parallel processing and test and accep-
tance procedures.
Undoubtedly this conversion effort
will be effected largely by contractor
resources. They will show up one day and
they will say, "Here is your converted
package, accept it. Ready or not, here it
comes." You need to be thinking about
that now. How do you go about the
process of continuing to run your opera-
tion while your operation is being con-
verted? To sum it up, I think the time
between now and the completion of the
1980's procurement is a good time to clean
up and take stock of what you have.
We mentioned that the thought-
provoking topics included contracting out.
Clearly the trend in government services
is to contract out ADP functions. Our
North Carolina experience has been that
over the past six years, our government
resources have declined. Six years ago,
we had a very small computer and 35
people. Today, we have a very, very large
computer and 18 people. Thus, the trend,
at least as far as we are concerned, is
pretty obvious. We have recently taken
what we think is a bold step forward by
issuing a mission-oriented contract for the
operation of NCC. This contract went
into effect October 1st. It, in 25 words or
less, provides contractor support for all of
the day-to-day activities associated with
running our data center. Our government
people are assuming the role of technical
area managers of various functional
sections within this mission contract
operation. For all practical purposes the
government people have retreated to the
position that I believe is the role that we
should be playing, i.e., one of planning,
one of monitoring, one of evaluating
performance, and one of attempting to
find and describe mission objectives in
terms of ADP functions and ADP solu-
tions. Contractors are being used essen-
tially to take the definition and do the
thing that they do best. My personal
experience in EPA as an ADP manager is
not contracting out, but it is the way to
go. I think if you woke me up in the
middle of the night and said, "Would you
rather do it with all government people or
with all contractor people, my inclination
would probably be, let's do it with all
government people because I am one."
Given the EPA situation , however, and
given the situation of government service,
I really can not see any other way to go.
What we need to do is just learn how to
use that resource effectively.
There are some significant advan-
tages in the whole business of contracting
things out. Although not an advantage,
MIDSD has greatly assisted us with the
whole business of contracting out because
we have standard contracts that are
reasonably easy to get. Specifically, I'm
thinking of the DM&O. I believe there are
advantages of contracting out; one of the
principle ones is ease of staffing. With
the contract resources now available, we
can get the quantity of people and the
kinds of people that we need when we
need them. We have the ability to load
level. According to our requirements, we
can get an analyst at the front end where
we need him and not have to pay overhead
on the programmers until we have pro-
gram specifications with which to work.
We have the facility to employ tech-
nology. We really can go and hire the
people who are specialist in these areas,
without having to experience the learning
period of time that it takes to get our own
talented people up to speed in these new
technology areas that are relatively new
to us. I do believe that in contracting out,
we have better control and accounting of
project cost. You just tend to pay more
attention to the cost of projects when
they are being supported by contracting
personnel. One reason you do this is
because in all probability it is costing you
more than what it would have cost you if
you had done it with your own people. As
G-16
-------
a manager, I feel that I can get more out
of my people than I could probably get out
of a contractor. Whether that is the case
or not, I do not really know. To be sure,
when you are tallying the cost of contrac-
tor services for projects, you will get
more management awareness than what
you experience when your programmers
were doing these tasks on in-house basis.
I think another significant advantage
in contracting things out is that you have
the facility to procure up-to-date tech-
nology through this contract resource.
Many of us have dealt with bits and bytes.
I recall some of these experiences in a
pretty foreign way. The fact is that in
our mode of operation in the Federal
Government, we do not generally have the
opportunity to maintain state-of-the-art
technology and state-of-the-art expertise,
ourselves. We are too busy. We are too
busy engaging in the business of the
Agency and what the Agency is about. It
is my opinion that the contract resource
procures up-to-date technology. The con-
tractors that are competing for these
kinds of projects are forced to maintain
that kind of technology. That is the only
way they can be successful in the field.
The ones that have experienced the
economic disasters of the early 70's had to
be good or they would not have made it
this long. Perhaps one of the biggest
advantages of contracting things out is
that it will free up a most vital resource
and the most limited resource that you
have. It will free up your technical
people. It will get them out of that bit
and byte mode of operation. It will
permit them to start addressing their time
and their energies toward your business,
the business of running the Agency. What
are they going to be doing? It seems to
me that one of the things that they will
not be doing is worrying about clearing
memory with six instructions. I guarantee
you that there are a lot of us who have
spent a lot of time learning how to do
that. We are going to be able to apply our
technology to mission-related problem
definitions. We will be able to do our own
feasibility study. There is one area that,
if we call ourselves professionals, really
ticks me off a little bit about contracting
out. When we have to call in a contractor
to perform a feasibility study because we
do not have the time to do it, that
contractor winds up spending half of that
contract time, getting to the point of
knowing most of the things that you have
forgotten a long time ago. If your
technical staff were freed up from day-
to-day activity, it would seem to me that
they would be able to perform these
feasibility and requirement studies.
I think an area that goes undone in
our Agency is performance monitoring and
evaluation. How good or how bad is your
current system? It seems to me that our
technical people can concentrate some
energies at looking at that. We have all
heard of the ADP stage hypothesis theory
which says we are now going from Stage 3
to Stage 4, Stage 4 being optimization
and enhancement. Again, it seems to me
that if we can free up our technical
people from the burden of day-to-day
activity, that they can concentrate their
efforts on getting from Stage 3 to Stage
^. I think one of the more significant
advantages of being able to contract
things out is that it is almost an unlimited
resource. It is expandible. We do have
the facility to inflate or deflate as our
mission requires.
There are some problems associated
with contracting things out to be sure.
Effective contract management requires
very special skills. There seems to have
been a lot of examples of poor contract
performance. To some degree, it is
attributable I am almost of the opinion—
as Don Fitzpatrick with Arthur Young
mentioned in his presentation—that con-
tract management is a form of art. We
try to write contracts that are so ironclad
that we have the contractor where we
want them, that it is almost an exercise in
futility, because you cannot contract sat-
isfaction. You can write that ironclad
contract and the guy could deliver the
goods right there on the line. It could be
the worse damn thing you have ever
G-17
-------
procured. It is very difficult to legislate
perfection. Our responsibility certainly
begins with clearly defining our require-
ments, our milestones, and the deliver-
ables. More importantly, we have to
provide these contractors with a demand
that they adhere to standards.
Of all the areas about which we
think, but probably have not done much
with as yet, is cost parameters. We do
not want to limit those cost parameters
simply to develop mental cost and imple-
mentation cost. We want this cost para-
meter to consider the operation of this
system once it is implemented. More
importantly, we want this cost parameter
to consider the maintenance of the system
after it is turned over to us. The
requirements in our contract must provide
for growth because we are looking really
at decisions that will effect us in the
Agency over a 10-year period of time. We
have to provide for schedule or design
reviews. We have to assure ourselves that
the design of a system or program is going
to be cost effective over the life cycle of
the system or program. We have to see to
it that the implementation of this effort
is consistent with the design. We
certainly have to have the feedback
facility of evaluating the performance of
this effort once it is completed. In terms
of contracting things out, I would suggest
that indepedent test and acceptance pro-
cesses need to be emphasized greatly.
This is a role that our in-house personnel
can perform very well. The contractor
does his thing, then we have to effectively
test and evaluate the product once it is
turned over to use. Lastly, the comment
that I would make about dealing with
contractors is that you cannot legislate
satisfaction and perfection. The thing
that a lot of us fail to realize in dealing
with contractors is that they are humans
like us and we have to learn to deal with
them reasonably to communicate with
them effectively.
G-18
-------
QUESTIONS AND ANSWERS
Question: How many stops did UNIVAC have last month?
Answer: I set you up for that one, Willis. We had an aZl time low. We had 18
stops for the month of November. It is the first time we have been under
20. We have looked on that as a step in the right direction. I can
remember a couple of years ago, when we were talking about 75 stops a
month. Eighteen is well within workable limits. We can attribute a lot
of that to the fine work of Don Fulford and technical people that have
made decisions in the past. The recent installation of our uninterrup-
table power sources have also been a tremendous help. The people system
is moving well.
G-19
-------
Centralization
Joel Brandon
I am going to discuss centralization,
and start out talking about centralization
in the context of the deliberate effort to
centralize ADP activities in Region V
which was amended by the Regional Ad-
ministrator, executed, and then com-
pleted. Then, I will try to relate to the
Agency as a whole, which is not real easy
because the scale is entirely different.
About six months before I got there,
an order was issued by the Regional
Administrator to bring all of ADP under
one branch and management division.
Prior to that, this is what the organiza-
tional structure looked like. The solid
circles represent what I would call profes-
sional positions. Civil Service refers to
the 300 series people as administrators,
rather than professionals, meaning that
there is no positive educational require-
ment to become a 334. That is fairly
important in what we did there, for
reasons with which you will become
familiar. Rather than sticking to Civil
Service, I will call those people profes-
sionals. The people who have no blue
filled in, are either clerical or technical
people, i.e., computer technicians, secre-
taries, keypunchers, and so forth. Prior to
centralization, Enforcement had its own
little package. There was a branch called
data systems, which largely was
responsible for the operation of the Data
100 System and did some programming and
analysis. Surveillance and analysis had a
very powerful group which was, for all
practical purposes, dedicated to STORET.
GICS had a couple of clerks hooked up to
the Grants Administration Branch in
Management Division. They were con-
sidered by the region to be computer
people. They were tagged for transfer.
There were some other ADP-related
types, mostly in air. Most of these people
are now considered to be people who are
mainly concerned with their own program
area using the computer as a tool. They
were not the subject of reorganization and
I found that to be appropriate. Of course,
we did not have a mini-computer then,
and we were not supporting it, as we are
now. The most dramatic difference there
is aside from the fact that everybody is
under one roof, the fact that we have had
an enormous increase in the ratio of
professionals to clericals, or professionals
to non-professionals. That was accom-
plished over time, of course. There is a
half professional listed in the current
branch. That is a person who is currently
classified as a supervisory operator, who I
have requested to be reclassified as a
computer specialist. Personnel has not
seen fit to agree with me yet. I think
they will come around. The reason for the
organization is that the situation existing
in Region V was pretty much the same as
we have in the overall Agency. These
efforts were completely unrelated. There
was considerable amount of bitterness,
jealousy; there were a couple of fistfights.
Dave Rockwell was thrown across the
room once. It was more over a loan of a
bridge book than it was over professional
matters. The level of bitterness and
animosity was considerable between the
groups, in some cases. The entire branch
is headed by a vacancy that I have labeled
GICS. I have tried to indicate in some
way what the responsibilities were and
how they could have been transferred. We
start out with a seven-man STORET
group. Right now we have essentially one
person involved in STORET in the Branch.
This, in itself, caused most of the actual
reductions in position. The entire effort
was redundant. The big problem was how
to go from one to the other. Obviously,
the order had people dragged into one
place. That was the easy part. It was far
easier than people thought it would be.
As soon as the Regional Administrator
issued the order, people began to scramble
for positions in the new branch. There
was not any question in fighting it. I think
G-20
-------
that would probably happen at this level
as well. You then find yourself with a
group of people who were your former
enemies. Their skills are not necessarily
what you want. If you want to head
toward more leverage, more professional
and fewer clerical people, you have to
find a way to do it. This is what we did.
The two GIGS people that you see on the
top are no longer associated with ADP at
all. They were largely responsible for
data entry. I have always considered data
entry to be a program problem. We work
that two ways. We transfer two people
back with their positions, and that was, of
course, facilitated both by our own efforts
and with the conclusion of GIGS. On the
STORET side, most of that effort was
eliminated with the one professional posi-
tion in STORET on the working level, the
supervisor was transferred up completely
and has become our STORET professional.
It turns out that he was doing all of the
work anyway. In Enforcement, the one
professional was transferred into the
Branch and remained a professional until
he left a few weeks ago. These were
opportunities for upward mobility even
though the positions were not identified
specifically as upward mobility positions
because of internal problems. If these
were engineering positions, we could not
have done it, but you can do it at ADP. If
you have a computer technician or an
environmental specialist that you want to
make into a computer specialist, if the
person is qualified and can be trained,
they can be converted. Two other En-
forcement positions were given back to
Enforcement; one has been transferred
into a professional position. In the Data
Systems Branch, we had four people on
the operation staff; now, there are two.
Two keypunchers have been given to the
Water Division without their positions
being transferred. All keypunching is now
being done on contract. The positions that
we have in the Branch that are classified
as 334 series are limited to one computer
operator. I would like to contract that
and a secretary, as well. What we have
ended up with is a soft core of 334 series
people. That is the sort of thing I would
recommend at the national level. It is
always a question of: Who do you transfer
if you are going to centralize? In my
opinion, it should be more or less limited
to 334's or people who would become that;
in other words, a solid core of data
processing people. That does not mean
that they do not know anything about
programs, but their responsibilities are
more concerned with the computer than
they are with the programs. That is a
fairly easy determination to make, except
that, in any successful centralization, if
you are going to be selfish about it, you
ought to drag more people in than you will
use to allow yourself the luxury of trans-
ferring some back, and getting rid of
some. There was one person who actually
has been released from the Agency in that
program. I do not think they had a whole
lot to do with centralization.
There are two parts to this graph.
The top one is proposed organization for
Headquarters; the bottom is a technique
of relating to the program once you have
done it. On top, I have divided the effort
into three parts which parallel, more or
less, what we are doing in the regions.
The set of resources management people
would pretty much be at the same level.
Then you would have some people working
on the management information system.
They would be called sytems developers,
or something like that, if you wanted to
separate them from another group; it
would probably useful to do so. One of
the primary reasons that I recommend this
kind of a combination is to avoid the most
ridiculous redundancy in efforts that we
have seen between STORET, the air sys-
tems, and MSIS, when it comes to collect-
ing and disseminating data about the
environment. I would hesitate to think of
the savings that we could have realized if
STORET has been made responsible for all
of this stuff in the beginning which they
wanted to do. That is probably an
unpopular view in some circles, but from
the regional standpoint this had an enor-
mous impact. We have had to maintain
relations with more people than we should
have. In addition to that, we really can
G-21
-------
not get the job done the way things are
set up now. In our region, we have an air
person and a STORET person. The
STORE! person is also a backup on air.
His work enables him to understand what
is going on. This is something that is a
rather important concept. The fact is
that the experience that one has in
developing a data base is transferable.
Even if you do not translate a live code
from one of the others, you simply would
not make certain mistakes. You would
include certain features just on the basis
of your experience. That does not seem
to be the case in the development of the
air system in the Agency.
That is enough for the top. The
bottom is a graphic demonstration of how
a so-called nucleus of data processors
would work, does work, in the regions. I
believe in the five-year plan. Index
systems has said a nucleus of data proces-
sors is probably a good thing to have.
That is one of the things they have said
with which I agree. I do not think we
necessarily have that. MIDSD certainly
does not act that way. There may be a
fairly sizable group of people who are
experts, but the question is how do they
deal with the programs? The answer is:
They are not dealing with them in a total
support relationship. It is kind of an
overall review process. They pretty much
supply resources as'needed, but, in the
analysis effort, in developing new sys-
tems, their facts are too late. This is how
we would attempt to stop it. We have an
established program with an ADP coordi-
nator in it. That person is not necessarily
an ADP person and he probably is not.
There is someone primarily responsible for
that system in ADP, then somebody to
back him up in case he is not there, in
case he quits, or in case they need more
than one person on an effort in any given
period of time. That is pretty much how
we do it in the Region now. We have a
person in ADP responsible for something.
We have at least one backup. On T&A,
for instance, on the payroll, we have at
least three backups. For an emerging
program, they obviously do not have
anybody in ADP, they do not have a
coordinator; they do not have anybody.
The question is how do they factor into
ADP when they are coming up? My
answer is that they draw on resources
without paying for them until they get
started. In other words, as soon as they
feel that they might have something to do
in ADP, some person or group of persons
in ADP is/are identified to help them out
on a part-time basis. This person would
be looking at what they are doing and
make random suggestions. Of course, as
they go further and further along, the
need becomes more and more apparent to
someone in their organization. Hopefully,
you end up with someone in ADP to handle
it; an ADP coordinator can be stolen from
the ADP group or hired from the outside
with the assistance or insistence of ADP.
This process worked as I understand it
with MSIS. It was long after it probably
should have been, but it is my under-
standing that Willis insisted -they they hire
an analyst. If they did, probably any
success that they have would be related to
that. I would like to discuss the issue of
how this sort of thing might happen, not
just desire it to happen, but how it might
actually occur. I doubt very much that
MIDSD is going to push strongly for this. I
had a word up there called Czar; that is
the Russian equivalent of Godfather. The
fact is that if the situation were to take
place, Willis" position would be kind of
tenuous. This agency has a habit of going
out and hiring new people for stuff like
that because EPA's management and good
management do not even read the same
newspapers. Anybody who tries something
like that has two choices. You can
succeed; they can take your job away.
You can fail, and you would make a whole
lot of enemies, or, possibly you could
succeed and they would give you the job,
but that is only a one out of three chance.
I do not look for this kind of effort coming
up from MIDSD. On the other hand in the
Region V effort, we went down from some
20-odd positions to 12. Somebody in
Headquarters might possibly notice that
between now and the end of this Admini-
stration. It is possible to reduce the
G-22
-------
overall number of position if you do
centralize. If it comes, that will probably
be the way it comes, which is rather
unfortunate. It will probably happen if it
happens, so that is to what you can look
forward, a forced centralization with a
reduction in time.
We have a list of characteristics,
and we would like to assign pluses or
minuses for the existing system which we
call fragmented. For a centralized sys-
tem call it rationalized because you do
not want to bias anyone's selection. I will
briefly discuss what I think these things
are and then will ask you either to agree
with me and say nothing, or say "boo" if
you do not agree with what I am saying.
The first question is: Is a decentralized
system more responsive, and my answer to
that is no, not necessarily. Responsive
depends on the people. Some place in the
decentralized organization, you will have
a data processor reporting to a complete
stranger. This guy can snow that guy in
any way that he wants. He can tell him
absolutely anything. When the manager
goes to the person in his organization and
says I want something, he does not neces-
sarily get it, so it is best not to send for
him. It is also bad from the standpoint
that these organizations are buried, that,
say, people even in the water program can
not get anything out of STORET because
they do not happen to be in the same
division. We have poor response from that
standpoint. I would favor the rationalized
system, from the standpoint of response,
if there are any boos I want to hear them.
I guess everybody agrees with that.
Either that or those nickels that passed
did some good. Flexibility. That is a
vague term, by flexibility I mean the
ability of the organization to respond to
new requirements; clearly this is related
to response. I think that a centralized
organization that has a nucleus can
quickly form an opinion about something
and can quickly give directions. I would
call a centralized organization more res-
ponsible. Cost. If you reduce the number
of positions, if you reduce redundant
effort, clearly you have improved cost. I
would aassign a plus to the rationalized
system for cost. No negatives. Accounta-
bility. Jim Hammerle had said that
accountability was not necessarily good. I
feel it is. I think the central system is far
more accountable if, for no other reason
than, its way of doing business is standard.
It is easy to see what is going on at any
one time. For instance, if someone wants
to know how many terminals EPA had, it
would be a whole lot easier to find out if
they were all under one authority. I would
assign a plus to be rationalized system for
cost as well. Standards are, of course, far
easier for a central organization to en-
force. The manager is responsible for the
standards. The people working for him
are the ones who are responsible for
applying them. Now, we have agencywide
standards which are, in many cases,
ignored. Again, I would assign a plus to
the rationalized system for that. New
approaches. This is something where
there is some confusion. It is possible
with the centralized system having those
standards that you may come up with
some one novel approaches. This would
increase overtime, but would find you
were doing things the same way time
after time. I would ssign a plus to the
fragmented systems for new approaches.
I just wanted to see if you were out there.
Technical resources. Centralization
would have a nucleus of data processors
providing you with a far better technical
resource than having just a few people
located in each department. I do not
believe in allowing at any time or any
place, one person to analyze a given
problem. No matter how good that
analyst is he will make mistakes. Techni-
cal resources depend on depth and I would,
therefore, distinctly assign a plus to the
rationalized system for technical re-
sources. How about management
resources? You are not going to have
computer managers in a fragmented
system unless you have some fairly large
fragments. The larger the organization
you have centrally, the more data
processing managers you will have and
quite probably they will be better.
Because it will be their sole job.
G-23
-------
Overhead. It is possible to have more
overhead centralized, but it is quite
unlikely. The only possibility that that
would happen is that if the centralized
agency became over-concerned with
things like documentation standards, ac-
countability, reporting, and things like
that. It is my opinion that we already
have as much of that as we can possibly
get. Every possible thing that can be
documented is supposed to be docu-
mented, not that it is. Every possible
form of documentation that exists in EPA,
every kind of reporting you can do, we
have been doing it. I would say that
overhead is probably pretty much
balanced between the two. An other
interesting characteristic is trouble. If
you have people in a central organization
who appear to cross different lines, you
will have to send fewer people to
different, far-flung places to accomplish a
given job. Rather than sending one from
ADP and a person from the program and
another person from a nother program
with another ADP person, etc. You can
send one person from ADP and one from
each program. This should reduce the
travel budget as well. Vulnerability.
There are two kinds; this the last one.
This is the biggest negative that we have
in centralization. If you combine every-
body, make them all professionals, and
stick them in an ADP group, they will be
the target of every administrative
overhead headhunting operation that
comes down the pipe. We have had that
problem in Region V. Generally speaking,
we have been fairly successful in fighting
it off, but it is a constant battle. You
always have to justify every damn position
you have in ADP. I would assign a plus to
the fragmented system for that. The last
one is absenteeism. Absenteeism is a very
grave problem in government. It is
certainly a grave problem in the regions.
I do not know how bad it is here, but
whenever I call somebody they are out. I
would say offhand that the central system
is much better than that because there is
a person who responds to your needs.
There is also a person to back him up, and
possibly a secretary to back up the back-
up. I would assign a distinct plus to the
rationalized system for vulnerability to
absenteeism.
G-2*
-------
COMMENTS
Comment: / would like to add one cautionary note on what Joel said. ADP
centralization seems to work fairly well with inter-regional offices. The
same argument might be used to centralized the ADP function within the
Agency. In other words, to make all regional offices, branches of MIDSD
or some big balloon like that. I do not know if that is a good idea or not.
Response: I would say offhand, in my own opinion, that it would not make a whole
lot of difference. It would depend on the regional management and
MIDSD's management. If the regional management were bad and
MIDSD's good, there would be an advantage in having it centralized; if
not, there would not. There is always something to be said about
decentralizing locations that are physically separated.
Comment: Throughout this discussion, while the various panelists have given
different points of view with respect to ADP management, I feel that it
is a common thing that can be summed up by saying that MIDSD ought to
take a look at being more active in certain areas. I believe that would be
good.
Comment: I had thought I might share with you some insights or experiences or
whatever on the COMNET conversion as related to the centralization of
ADP. There is not really time to do that. I do think, however, that an
awful lot of the centralization argument revolves around the kinds and
quality of people that you can attract and keep in these various
organizations. A lot of Joel's discussion is effective. His push for
centralization is effective if the people who are doing the centralizing
and the people who have run the central organization are talented,
interested, and dedicated people. If they are not interested and
dedicated, they will not work very well. I think that a lot of the feeling
that people develop, the intense feelings toward centralization and away
from centralization, depends a lot on their experience with those
services as provided. If you are a centralist, you tend to have had good
experiences with centralization. If you are fighting centralization by and
large the reason might be because there are managers of that central
organization who really are not doing their job. They need to be fired,
yet because they are in such powerful positions, they can not be let go.
My comment is if you can attract quality people, you can do it-either
way; you can centralize or you can decentralize. It would probably be
slightly more efficient to centralize than to decentralize with quality
people. You have to look at the ability of that central group to maintain
its excellence throughout a long period of time, because once you
centralize, you centralize. As soon as someone who is in a position to
establish a decrentralized kind of an organization figures out that he may
be able to get some more talent doing the job from a decentralized level,
then that tends to look more attractive.
G-25
-------
PANEL H: TOXIC SUBSTANCES
Chairman: Ken Olsen
Panelists: Denise Swink
Ernest Stalder
Morris Yaguda
Frederick Siff
John Seitz
Warren Muir
Henry Lau
OVERVIEW
Ken Olsen
Office of Toxic Substances
I think I will start by introducing the panel. Immediately to my left is Denise Swink,
Office of Research and Development; then John Seitz, Office of Enforcement; Morris
Yaguda, MIDSD; Warren Muir, Office of the Assistant Administrator for Toxic Substances;
Ernest Stalder, Office of Toxic Substances; and Fred Siff, Office of Toxic Substances.
The panel was chosen from representative offices that are on a performance
evaluation board on our TSCA Information System Contract, with Informatics. Before we
get into details, I would like to provide those of you, unfamiliar with the Toxic Substances
Control Act, with background on this Act.
The Toxics Control Act was passed by Congress in late 1976, and became effective
January 1, 1977. This legislation provides EPA with the authority to regulate those
commercial chemical substances which may impose an unreasonable risk to man and the
environment. The dimensions of the chemical industry suggest the magnitude of the
undertaking that EPA is now facing. The agency has estimated that there are
approximately 50,000 chemicals in commerce produced by over 10,000 chemical
manufacturing establishments which would be subject to this legislation. We also have
estimated that there are approximately 1,000 chemicals which are introduced into
commerce each year. The regulatory aspects of the bill are directed mainly at the
chemical and allied products sector of the chemical industry. Pesticides, food, drugs, food
H-l
-------
additives, and cosmetics currently regulated under other laws are exempt under the
provisions of this Act. The information authority, provided by this Act to the agency, can
be a vital source of new data upon which to access probable risk of chemicals in our
environment. Relatively speaking, only a small portion of the tens of thousands of
chemicals in commerce have been tested for long-term effects in laboratory animals. As
the number of recently identified hazards suggest, we know very little about the effects
of many of the chemicals which surround us. The new law provides EPA with the
authority to require reporting of data the chemical industry may have and to require the
development of new data necessary to assess the relative risks and benefits of existing
commercial chemical substances.
A significant feature of this legislation requires manufacturers of new chemicals and
of significant new uses of existing chemicals to notify the administrator and submit data
for EPA evaluation, 90 days before the manufacture of these chemicals or their new uses.
EPA can, on the basis of this data, permit the new chemical to be manufactured or require
that additional information be supplied. This is a critical decision process which requires
an efficient information system. While its mechanism is not a certification or registration
procedure for each new chemical about to enter commerce, this pre-manufacturing
screening provides EPA with the opportunity to review and take action to prevent
hazardous chemicals from coming into the markets. The legislation provides a regulatory
authority to take action against the manufacture and/or the use of the chemical
substance, once a risk has been identified and substantiated. The law provides, however,
that before such regulatory action can be initiated, benefits of the chemical, its
availability, adequacy of substitutes, the economic impact associated with such action,
and the cost of proposed regulatory action must be weighed against the projected
chemical risk to human health in the environment. I would like to focus on the
information authority within the Act. TSCA provides EPA with broad information
authority to require manufacturers and processers to report specific information to EPA.
These procedures must follow the standard rule-making process contained in EPA Order
1006. Other provisions of the Act direct EPA to share all information reported on TSCA,
including confidential business information, with other federal agencies and departments
and with TSCA contractors, and to create an integrated set of government-wide chemical
information files.
I am going to show a couple of slides here to give you the background on the
information reporting authorities of the Act. Section 4 required, through the rule-making
process, manufacturers and importers of chemical substances to perform tests of those
substances as EPA requires. There will be a significant amount of test data reported to
the agency over the next several years. EPA has established a section for a work group,
some of you may be on it. It is broken down into various parameters. Also, the inter-
agency testing committee, under Section 4, has named 10 chemical substances, including
some classes, for testing rules by the agency within the next year. Let me explain
something about that. There is an inter-agency committee that has met since the first of
the year. They just recently (late October) published a list of chemicals in the Federal
Register. Under Section 4, the Administrator has to either promulgate a testing rule
within one year of that notice, or show reason why he did not promulgate that testing rule.
Section 5, pre-market notification, which we are now calling pre-manufacturing
notification, will affect both new chemical substances and significant new uses of
chemicals. Manufacturers will be giving us information packages for each one of these
new uses or new chemicals once the inventory is published towards the end of next year.
The Act does not follow the logical order of implementation, so we might be getting a
little ahead of ourselves here.
H-2
-------
Section 6 in regulations requires us to keep hearing records of what the
administrative law judges and of open public hearings, as we regulate specific chemicals.
The PCB's and f luorocarbons, and PPBB's are now being regulated under Section 6.
Section 8 breaks down recordkeeping and reporting into five major components.
There is a general reporting provision under 8(a) which is very broad. It covers things such
as the chemical's usage, by-products, impurities, disposal methods, estimates of persons
exposed, and just about anything else in that particular area of epidemiological use or
economics. The final rules of the inventory, to be addressed later in more detail by Fred
Siff, will be published in the Federal Register. We are required to come up with an
inventory of existing chemical substances in order to identify exactly what is a new
substance. The Act also requires manufacturers to report adverse reactions, employee
health, or environmental effects that they may be observing. Under 8(b), Health and
Safety Studies, we are preparing a first rule for the substances mentioned by the
interagency testing committee in the Federal Register. Under 8(e), Notices of Substantial
Risks that require manufacturers to report to us any substantial risk of a chemical, we
have received about 25 of these since the 1st of 3anuary. These would primarily include
testing information showing adverse reactions.
In addition to the required reporting authority, the Act has some unique features.
Under Section 10 of the Act, Data Use and Dissemination, we are to establish and share an
interagency committee. That committee is to deal with toxicological and scientific data
retrieval throughout the Federal Government. This has been incorporated into the
Interagency Regulatory Liaison, which Warren Muir will discuss a little later.
On data disclosure, the Act has a unique feature. It states that all health and safety
data is subject to release. If persons claim their health and safety study is to be
confidential, we go back to them and tell them that, under Section 14, that particular
piece of information is subject to release. They may have to sanitize it somewhat in
certain cases, for example, if we are dealing with a proprietary or trade secret structure,
which would be disclosed within the test for safety data.
Confidentiality is a tremendous problem that we are facing right now, particularly
because of the sharing of information with other Federal agencies and protecting the
confidentiality of that information. We have been visiting other agencies and we have a
task force on TSCA Confidentiality. In our information system design, we are also
emphasizing the feature of confidentiality. It is one of the leading if not the leading,
design parameter.
Under Section 21, any citizen can petition EPA to take any action under TSCA that
would fall under Section 4, Testing; Section 6, Regulation; or Section 8, Reporting. That
area has not yet generated anything, but once it becomes better known to the public, we
will get a lot more citizen petitions. CPSC get a lot more a year under their authority.
In Section 25, in conjunction with HEW, we are to develop a Standards Data
Classification System. This is also being incorporated with the RLRG activities. Section
26 establishes an industry assistance office for the purposes of looking at new, unique and
efficient ways of getting the word out. We are affecting a tremendous number of
industries out there, especially when we get into chemical processors. These sectors do
not look at the Federal Register. We did a survey and we found that between 10 and 15
percent of the people affected read the Federal Register. We are establishing an
automated mailing list for a direct mailing of proposed regulations to these people. We
are looking at effective ways of getting the word out, so people can comply with our
regulations in a timely manner.
H-3
-------
The design and operation of an information system to support this legislation is an
important and critical task. It would be simple on the surface to approach this problem by
saying that the system will contain all available information on every commercial
chemical substance. This approach is not feasible because of the vast amount of resources
required, and the lack of justification on behalf of the agency to build such an enormous
system. EPA simply does not need all available health, safety, and economic information
on all chemicals to carry out effectively the mandate of TSCA. The magnitude of this
task, together with the associated problem of data collection, processing, and
maintenance, may not get practical with respect to system design and operation, nor cost
effective from a programmatic standpoint.
In order to provide an information system that effectively supports the TSCA risk-
benefit, decision-making process, it was decided at an early stage to design the system in
conjunction with the overall implementation of the Act. The TSCA Information System is
being designed as a principal component of a Federal data system that can be used to
conduct risk-benefit analyses of chemical substances. There are several hundred Federal
Government data sources for information on chemicals. The majority of these sources
deal with health and safety data. The TSCA system will support the assessment of
commercial chemicals for potential regulatory actions, from early warning activity
through enforcement of any subsequent regulations. It also shall control and manage
tracking features. The planning and operation of the TSCA information system is and
must continue to be an integral component of the overall TSCA decision and rule-making
process.
Focusing on the next items during system design: First, reporting regulations must
follow an open rule-making process. The need for data must be developed using a standard
rule-making process, and involving the participation of Federal agencies and interested
groups. The second point is that agency resources to collect data, required on the part of
the industry and government, must be justified relative to the uses of that data. A
balance, between data requested and resources available to analyze and take action, must
be established. Data that sits in a file without action is burdensome and goes out of date
very fast. The information system must support decisions on both existing and new
chemicals. The information system is designed to evolve overtime into a comprehensive
data base to support this.
As we get into analyzing risk-benefit in the development of TSCA strategy, we find
that the decisions that need to be made and the data that is required on existing and new
chemicals are very similar. The TSCA Information System is an integral part of decision-
making. The legislation provides the authority to write regulations to either require the
reporting of data or restrict the use or uses of particular commercial chemicals or classes
of chemicals. These regulations and corresponding information systems are used to make
decisions which will have significant impact on the chemical industry. These are highly
dependent functions which may cross organizational bounds. The design of the
information system to be flexible, modularized, and be able to react very quickly as
regulations, decisions, and the winds around the agency change. The effect of control of
chemical substances requires close integation of these functions, because of the variety of
the situations that potentially exist for the agency. We must be capable of systematically
reviewing the universe of existing commercial chemicals to determine which, if any,
require regulatory actions, reviewing new chemicals or significant new uses of existing
commercial chemicals to decide whether or not they should be allowed on the
marketplace, and responding in a rapid manner to emergency and unanticipated situations.
Following these three major functions, the regulatory process for chemicals follows seven
steps. If you look at the decision process from the initial hazard evaluation through
-------
enforcement—whether it is an EPA, a CPSC, or an FDA action—these seven steps are
fairly similar. The initial hazard identification comes in through citizen petitions, a
review of literature, or a detailed review of hazards. These determine whether additional
research or testing of studies is needed. This would then be incorporated into a decision
package and subsequent risk-benefit analysis, which leads to regulations and to eventual
enforcement. Some of us may be involved with just one of these steps, but these are the
overall steps as we see it. Converting these steps to TSCA activities breaks down into
input analysis and decisions. Inputs would be triggers for actions, such as studies by the
Federal Government, Inter-agency Test Committees and citizen petitions, pre-marketing,
pre-manufacturing, or other government regulatory action. These are the things that say,
all right, we should look at this chemical for one reason or another. We get into the data
evaluation or the analysis step, or you may have to write additional rules under Section 8
or Section *f, into formal data disclosure, into the analysis portion, and then finally, into
decisions. Then every time we make a decision, whether it is positive or negative
depending which side you are on, we are required to put this into the Federal Register. If
we decide not to take an action, we are to show the cause as to why we did not take the
action. Under Section 5, we also are required, when necessary, to publish a list of
"unreasonable risk chemicals." This is the hot list chemicals, where we might be either in
the middle of an evaluation or it might trigger certain chemical classes, etc. I think that
is far down the stream. It is a very hot issue to publish a list of possible candidates
without writing any specific regulations. You have Section 6 regulation and under Section
7, Imminent Hazard. If there is such a thing as an emergency situation, the administrator
can come in and wipe out this whole process, make a decision, and let the courts settle it
all later.
Before opening up the session to the panelist talks, I would like to talk about
background on our requirement analysis, performed to date. Back in 1974, when TSCA
was still debated in Congress, OTS contracted with the National Bureau of Standards to
perform an information system requirement analysis on the proposed legislation. This
document was the basis of an RFP, issued in December, 1976, to design and operate an
information system to process and disseminate all the data reported to the agency as a
result of TSCA. Last February, OTS, in conjunction with NLM (Nat'l Library of Medicine)
and CEQ (Council on Environmental Quality), conducted a study of a chemical information
system to support regulatory decision-making. This study was performed under the
contract with the MITRE Corporation. (Limited copies of that study are available through
my office.) TSCA was the focal point of much of this effort. EPA headquarter, regional,
and laboratory personnel were interviewed. An extensive survey of available chemical
information systems within the Federal Government was performed. The study
conceptualized the idea of a global chemical information network as a 10-year goal,
specifically with respect to TSCA. The study indicated that the existing major gaps are
commercial chemical substances, primarily in the areas of economics and use.
Confidentiality could be the subject of a three-hour discussion, but I will mention
briefly what we are doing in that area. We have a task force which has a very broad
representation throughout the Agency. We are developing specific EPA procedures for the
handling and use of information throughout the agency, with agency contractors, and also
through other Federal establishments. These are going to require people who have access
to the information to handle it in a manner similar to what FDA does with information on
drugs. You will have a log book and document control officers. You will have to establish
your need to know.
H-5
-------
THE INTER-AGENCY REGULATORY LIAISON GROUP
Warren Muir
Last July, the heads EPA, OSHA,
CPSC, and FDA decided to initiate an
effort to coordinate their regulatory
activities with regard to chemical sub-
stances. Each of the agency heads
selected two individuals to represent them
personally, and meet on a weekly basis in
an effort and to scope out mutual areas of
cooperation to pull together a series of
policies and procedures. This group of
eight surrogates is now known as the
Inter-agency Regulatory Liaison Group.
Subsequently, 10 regional groups with
representatives from each of the four
agencies and each of the regions, were
established and are in the process of
completing their work plans and under-
taking cooperative efforts at the regional
level. There are also eight Headquarters
working groups in concerned with testing,
research, epidemiology, risk assessment,
regulatory development, communications
and education, and compliance with en-
forcement, and, information exchange.
Each of these eight Headquarters working
groups has completed the development of
the proposed work plan with a number of
short and long term projects. A number
of groups have made significant steps
toward cooperation. I will be speaking on
the Information Exchange Work Group.
This work group has a draft work plan, and
will have a final work plan within a week.
These work plans will all be published and
distributed widely. The work plan, as it
now stands, contains six major projects.
The first, and perhaps the most important,
is an effort to develop and agree upon a
common identifier for data files. These
would include four different types of
identifiers. First, chemical identifiers
such as the Chemical Abstracts Registry
Number; second, descriptive code (unin-
telligible) for chemical use; third, is a
product code, such as the universal pro-
duct code, which is, perhaps, more
applicable to FDA and CPSC, and the
fourth will uniquely identify establish-
ments. There are many many different
types of enforcement actions and enforce-
ment files reporting. In order to be able
to cross reference the information, one
needs to have some kind of establishment
identifier.
The subproject is broken down into
three phases. The first is an effort to
assess what type of unique identifier
would be the most appropriate toward
which to be heading, such as agreeing
upon the use of Chemical Abstracts
number, or the Dunn and Bradstreet esta-
blishment code, or whatever. The second
phase is an effort to assess the implemen-
tation timeframe and implementation cost
of attempting to incorporate the
multitude of files in the four agencies.
The third would be the implementation
phase of all those files, where it seems
feasible.
The next sub-project is in the area
of confidentiality, information security
procedures. In the future, there will be
increased cooperation between the
agencies and toxic substances area, and
that there will be exchanges of informa-
tion among the agencies. Certainly the
statutory authorities are moving in that
direction. T5CA information legally can
be supplied to another agency with regula-
tory interest and in pursuit of their
official duties. Similarly, FDA statutory
language is being changed to provide
information to us. The concern is how-
ever, that if information is going to start
flowing, there would have to be some
agreed-upon, minimum level of security so
that the agency providing the information
can be assured that the confidential status
of the data will be maintained.
One of the more difficult tasks
attempted by the IEG is the sub-project
on monograph planning and production,
which involves joint-criteria document
H-6
-------
preparation. There is a tremendous
amount of overlapping research going on
in the four agencies. At a minimum, it
should be possible to identify when
criteria documents are contemplated so
that it would be possible for individuals
and groups starting to take criteria
document development to being able to be
informed as to who else might be working
on the same compound to coordinate their
efforts and share information. The more
ambitious goals of this sub-project would
be to undertake three or four master
contracts for criteria-document develop-
ment, which would be jointly sponsored by
the agencies. Once it is determined that
the criteria document is necessary, there
would be an appropriate task order
written up, and a criteria document
developed in a format usable to all
relevant agencies. That would be an
extremely difficult undertaking, but it is
one explored being for each of the
agencies. The next two involve feasibility
studies toward two data information
systems that came out of the series of
needs and recommendations identified by
contract report MITRE. On the basis of a
survey of user needs of toxic substance
and chemical information, MITRE
identified 10 types or 10 data system
requirements, and made recommendations
for these data systems. A number of the
systems are already under development,
being contemplated, or in various stages.
There were two that were not being
addressed but which had particular
regulatory agency significance. The
Office of Toxic Substances, with some
year-end funds, provided the IRLG with
same funds for the first phase—feasibility
studies on these two data information
systems, presently underway by SIGMA
Data Corporation. One of the systems
would allow agency personnel, industry or
other affected parties the ability to
identify which regulations, laws, and court
decisions, are applicable to their
particular chemicals. This would
presumably have references to the
appropriating Federal Register, Code of
Federal Regulations, or U.S. Code, and
would provide the system user with
abstracted information, or refer to the
primary source.
The second is really not a data base,
but a software package, for toxicological
data analysis, which would be available
primarily to two types of users. The first
would be testing laboratories, govern-
mental or private industry, conducting
toxicological testing. The system would
support tests for a maintaining data. It
would allow the experimenter, during the
progress of the experiment to do some
short-term analysis, analyzing the data
and at the end of the experiment to be
able to prepare a machine readable output
which would be submittable to the
regulatory agencies. The software
package would also be valuable to the
agencies that receiving the raw data. The
Office of Pesticides, receives a tre-
mendous amount of toxiological data for
registration process and it is envisioned
OTS will be receiving similiar amounts
which means the toxicologists will be
presented and analyzed in many forms. It
may be that the submitter has lumped
together the white rats, the males and
females, it analyzed the data using
certain statistics, and come out with their
results, it is just a mammoth task for the
reviewer to sit down and try to figure out
what the results would be if you had
separated the black mice from the white
rats, analyzed the data etc. forth. This
particular software being developed would
to allow the toxicologist or reviewer to
aggregate the data differently, apply
different statistical tests, to verify the
conclusions. A system which meets many
of these needs is now under development
at the National Center for Toxicological
Research and this feasibility study is
investigating the extent to which it meets
the needs of the four agencies.
The last of the sub-projects is in the
areas of reporting and recordkeeping.
This is one of the areas which kicked off
the IRLG. There was concern that the
regulatory agencies were not getting their
acts together, were requiring duplicative
reporting, and (unintelligible) their
H-7
-------
recordkeeping requirements. There is one at Headquarters and the regional level.
last project under consideration which I do This summarizes the information ex-
not believe is as yet in the work plan, but change activities.
will be in the area of library cooperation
H-8
-------
FEASIBILITY STUDY ON INFORMATION SYSTEMS
Morris Yagada
Management Information and Data
Systems Division
The MITRE study has been briefly
mentioned. It is a foundation document
which presents a basic analysis of the
information requirements and an inven-
tory of existing sources of a ten-year plan
to develop ways of understanding how to
use existing and new systems to meet the
defined requirements. One of the key
features of that ten-year blueprint is the
idea of a network. The system is called a
Chemical Substances Information Net-
work. It is not a system where you have
applications tied together by communca-
tion lines or under central management.
Rather it is a planned use of many,
individually managed systems, as they try
to meet the complex information needs of
the program. There were 10 systems
identified as core components of this
network. Sigma Data was hired to take a
look at these and to carry the analysis and
the planning one step further, and try to
look at implementation alternatives for
achieving some of the system capabilities
that were not being developed elsewhere.
That study, at this point, is in a final draft
form.
The MITRE study focused on several
items. It focused on the data base
directory, the Chemical Structure Nomen-
clature System, Chemicals in Commerce
public file, the OTS confidential file, and
the general security situation. Security
pervades everything that OTS is doing at
this stage. Industry is very concerned
about the fact that they are giving us the
keys to their operations; these must be
protected.
Regarding the Chemical Data Base
Directory, this is the system designed to
answer the question as to which files in
the network have particular kinds of data
information. It is a directory of data
elements. For instance, you could ask the
question, which files have production
volume? Or, which files have marketing
information? Or, which files have certain
combinations of data elements? Once you
have found out which files would satisfy
your request, you could then ask to see all
the data elements in the files in order to
see if these are the ones needed. You
would also get some information about the
scope of the data, how current it is, and
how specific it is. You would also get
information on how to access that file.
Sigma Data looked at the question of
whether this could be implemented in
manual form or automated, and presented
pros and cons on both alternatives. They
did not make any particular recommenda-
tion. The National Library of Medicine is,
however, very interested in building a
central file. They would establish and
maintain it as part of the Chemline,
Toxline family of systems on the National
Library of Medicine computer. They
would also make that information
available to anyone else who wanted to
use it as part of any other system or
systems, in computer or manual form.
Initially, it would focus on the files
identified as part of the Chemical Sub-
stances Information Network, but it could
be extended beyond that if that proved
reasonable.
The second core component in the
MITRE study is the Chemical Structure
Nomenclature System. The basic purpose
of this system is to help answer questions
where you do not know all of a chemical's
name or chemical structure, or you do not
know its standard CAS Registry number,
or its standard CAS Registry name? You
may also need technical data associated
with the chemical. You would also like to
know what files have information about it.
H-9
-------
You would like to be able to point to or
identify a standard identification data for
your chemical. This is also a directory-
type file. The first direction mentioned
above was ordered by data elements, this
second directory is by specific chemical.
There are two systems in existence that
approach the idealized requirement for
this kind of a system. One is Chemline,
operated by the National Library of Medi-
cine; the other is the Chemical Informa-
tion System operated by EPA and NIH. I
think some of you may have been present
yesterday in a panel - we ran in the
morning. There was a presentation given
on the EPA Chemical Information System.
Those systems need some changes to meet
the idealized requirement. In terms of
the Chemical Information System, our
office is presently doing a management
and technical evaluation of that system.
We are developing short-range and long-
range plans for improving it, making it
more flexible, and easier to use. The
National Library of Medicine is also going
through some planning steps, trying to
make their system more comprehensive
and more powerful. One curious point in
the MITRE study is that they suggested
that these two systems come at this
idealized requirement from two separate
directions. One is the scientifically
oriented user-community. The other
serves a library oriented user-community.
If they met the idealized requirement,
however, both systems would eventually
evolve into something that would look
very similar. MITRE thus proposed that
we should be looking at the feasibility of
these two systems merging and becoming
one. That alternative is also receiving
serious thought. One thing that we are
doing in that vein is that managers of
Chemline and CIS are talking to each
other.
Chemline also has this pointer con-
cept. Once you identify your chemical in
Chemline through a name entry, it does
point to several other files. They would
like to have the wider set of pointers that
CIS has. We are cooperating in giving
them our pointers, and they are cooper-
ating in giving us their pointers to
Toxline. I would like to mention that OTS
is presently using both systems. For
instance, the CIS system was used to
generate the initial TSCA candidate list.
There are three core component systems
defined as related to in-house OTS-
operated systems. One of them is the
TSCA Proprietary File organized by
chemical. It contains all the information
that gets reported to the Office of Toxic
Substances in regard to chemicals, some
of which are claimed to be proprietary,
some of which are not. There would also
be a file containing information on esta-
blishments, and which would keep track of
which establishments are supposed to
make certain reports, the status of that
reporting activity, and whether they have
complied or not. There would also be a
third OTS file which would essentially be
an extract of these first two files,
extracting all the information that is not
confidential, the information that would
be made public. It could be referred to as
the TSCA public file. There is one last
thing that I would like to mention in terms
of the Sigma Data report, and that is that
it has attempted to identify functions at
the proposed division level at the Office
of Toxic Substances. It looks at the
functions of these divisions and it looks at
the information flow through each division
in order for it to do its job. It shows
interactions between divisions, the
Federal Register, industry, and various
members of the 10 core components. I
suggest that this particular part of the
study would be interesting. Again, I would
recommend reading the MITRE study and
the Sigma Data study for those who are
interested in learning about this program.
H-10
-------
INVENTORY INFORMATION IN THE CHEMICAL ABSTRACT SERVICE
Frederick H. Siff
To prove that we're getting into the
operations aspects, I have the honor of
showing you the first flow chart of the
morning, which I hope will show the
processing of the inventory that will take
place at the Chemical Abstracts Service.
Both Warren and Morris have given a
global view of some of the information
requirements, not just those of the office
of Toxic Substances within EPA, but the
total Federal Government's requirements
for chemical information. At the heart of
the Toxic Substances Control Act, how-
ever, is the requirement to define the
universe of existing commercial chemical
substances. This is the necessary first
step so that pre-manufacture evaluation
of new chemicals can be performed by
EPA. This is one of the strongest parts of
the Act itself. Thus, the Act requires
EPA to compile, keep current, and publish
a list of each chemical substance manu-
factured in or imported into the United
States. This list is the foundation upon
which all toxic substances control will be
based and from which the commercial
chemical information system will be built,
eventually providing one of the important
building blocks or modules in the wider
chemical information network, to which
Morris has referred as suggestions that
came from both the MITRE study and the
Sigma Data study. The initial inventory
rule was proposed sometime last summer.
It had, as its basic thrust, the develop-
ment of a list of chemicals in commerce.
In the early stage, once the Act was
passed, we entered into a contract with
the Chemical Abstracts Service, a
Division of the American Chemical
Society, to develop the list, making use of
both their information processing
capability and the wealth of information
that they have on commerical chemical
substances and research substances.
There are more than 3.3 million sub-
stances in the file of registered
chemicals. It was recognized early on
that to develop this initial list of chemical
substances we needed to start with what
we refer to now as the candidate list,
which lists all substances that we think
are in commerce. Rather than have all
manufacturers report what they make in
their own style, we thought it would be
best to have a candidate list or a draft list
of the inventory that manufacturers could
report against. Many sources were used
to develop this file. These are some of
the Government sources used to compile
the candidate list. Some of these were
processed at the Chemical Abstract
Service under an existing contract that
MIDSD had with them. Some private,
non-government, source files were also
used to produce the candidate list. A list
of some 33,000 substances were developed
as a computer data file and then published
in a hard-copy three-volume set of some
2,200 pages. Chemicals were listed in
three ways; namely, by the Chemical
Abstracts registry number, by formula,
and by the preferred Chemical Abstracts
nomenclature. This will reduce the
reporting volume that we expect and also
increase the accuracy of the final
inventory list that will trigger the other
components of the Act. This was
published in June and can be acquired by
calling Ken. In addition, the list is
available on several computer timesharing
networks. It is available on Chemline. It
is available through the EPA/NIH
Chemical Information System. In
addition, manufacturers have been given
the opportunity to get a computer tape of
the candidate list against which they may
process their own files. The use of a
candidate list reduces reporting volume,
because manufacturers, if their
substances are on this list, need only
report the line number given in the list
and check digits within the candidate list.
They can be processed very rapidly with
H-ll
-------
the Chemical Abstract Service, and the
processing flow works. Regarding the
TSCA reporting forms, there are a variety
of forms developed to report substances
that are either on the list or not on the
list, or substances that cannot be uniquely
identified. The latter form one section of
the candidate list, the UVCB section. The
forms are currently being printed. The
revised inventory regulations are
currently awaiting signature by the Ad-
ministrator. The processing flow actually
has been developed for several months.
The report forms will be mailed directly
to Columbus, Ohio, where the Chemical
Abstracts Service is located, and then the
processing will begin. The reporting
period is a four-month period beginning in
January (this assumes that that the cur-
rent regulations are signed off before
then). We have made some estimates of
the total volume of reports that will be
received. It is very difficult to determine
how many commercial chemicals are man-
ufactured and how many manufacturers
will be reporting them. We have esti-
mated, however, that there will be a
maximum of some 300,000 different
reports that will come in. These are
reported substances, and there may be
duplicated substances. The Act originally
required that the final inventory list be
available for use by the middle of
November of this calendar year. Due to
the reproposal of the inventory regula-
tions it will not be available until the
middle of November next year under the
revised schedule.
The input processing will be per-
formed at the Chemical Abstract Service.
The Chemical Abstracts Service will
develop a plant-site file and also a sub-
stance file. The substance file will tie
into the CAS Registry System, and
substances which are not currently within
the CAS Registry System will be
registered. Substances which are reported
merely by the name or formula will
nevertheless provide access to the
synonyms and connection tables which are
available within the CAS system. The
output will be the inventory packaging
which will then result in the printed TSCA
inventory. I will not get into the timing
or how long it will take to process some of
these forms, or the variety of problems
that may result if the flow is greater than
we anticipated.
The inventory work group that
developed the inventory regulations,
chaired by Cindy Kelly of OTS, has
worked closely with us and with the
Chemical Abstracts Service in developing
regulations which would both reduce the
processing burden on industry and increase
the integrity and accuracy of the informa-
tion. We have been involved in developing
the forms which are being used to support
the inventory, and also the assistance
services that will be provided for
reporters. I mentioned that the inventory
list itself is available through three widely
available timesharing services. In
addition to hard copies and computer
tapes, there will be training services.
There is an instruction manual for how to
report under the Act, and there will be
training programs developed in the
regions. Regional TSCA Data officers
will work with reporters within their
regions. Forms have been made as simple
as possible to fill out, particularly if the
substance is on the candidate list. This is
an overview of the inventory. We would
expect that processing will begin well
within the four-month reporting period.
By the middle of the summer, we would
expect that some 90 percent of the
inventory would be established and made
available within EPA. Most of the sub-
stances on the candidate list should be
reported as manufactured and processed
by mid-summer, and then made available.
The inventory leads into the wider role
placed on the information system com-
ponent within OTS. The inventory
describes what is in the universe, plus
provides a little additional data on site
and production quantities. We are viewing
it as a card catalogue to some extent
within the Office. It will provide the
definition of substances. There will also
be additional information collected under
the Act, primarily through the mechansim
H-12
-------
r^
of pre-market reporting, and 8(a) system, the industry, and commerce infor-
reporting regulations. The inventory then mation system.
will feed into the larger information
H-13
-------
THE INFORMATICS CONTRACT
Ernest Stalder
I am going to talk about the Infor-
matics contract that OTS recently signed.
I will cover five different points about
that contract; namely, the purpose,
contract type, the mechanism under which
it was signed and will be executed, and
the kind of work that Informatics is now
doing during the initial period. I will talk
about how we are planning to manage the
contract activity, and finally, I will talk
about the present status of the work and
immediate plans for the future. There are
two main thrusts and general areas of
activity in the contract. The primary
purpose is mandated under Section 10b(l)
of the Act, which requires an information
system to be developed to collect and
disseminate data that is reported to the
administrator under the authority of the
Act. The first major thrust is the design,
implementation, and operation of a
system to manage TSCA data. The second
major activity is to provide a level of
analytical support for the decision-making
process that will use data reported under
the Act. There is, under the five-year
contract, up to 30 man-years of analytical
effort allowed. The analytical effort will
allow the analysis of TSCA data in com-
parison with other data sources; trend-
forecasting; evaluation of the impact of
proposed data collection regulations on
the chemical industry. The contract
activity is intended to supplement the
analytical resources of OTS, since at the
time we went out with the RFP,we antici-
pated that there would not be an adequate
number of internal slots to carry out this
activity.
I want to say a few words about the
contract type. This contract is a five-
year, cost-plus award-fee contract, a
rather new mechanism to EPA. It has
been used by NASA and perhaps other
agencies. What it means is that the
contractor is paid for his cost, plus a base
fee, plus an incentive fee. In this case,
the contractor gets costs plus 2 percent
profit, plus from 0-12 percent of his cost
awarded to him solely at the Govern-
ment's discretion, a unilateral decision on
the basis of the Government's evaluation
of his performance. The contract is
broken up into performance evaluation
periods, in our case every four months.
We assign to the contractor at the begin-
ning of each period, certain work areas
that we are going to emphasize within the
scope of work. The contractor will be
evaluated on his performance on these
categories, and awarded a fee based on
that. The system users are required to
submit performance evaluation observa-
tions throughout each period. The obser-
vations don't have a fixed frequency, but
can be submitted often or infrequently.
Of course, they have to be submitted at
least once each period. The performance
evaluation observations are reviewed by
the evaluation coordinator. In this case
he is the project officer, and will add his
own comments as to whether the observa-
tion in his opinion was correct or incor-
rect. A package is put together for the
Performance Evaluation Board, consisting
of people who are supervisory to the
performance monitors, who will determine
whether or not contract deficiencies are
due to contractor default or due to EPA's
faulty direction. The Performance Evalu-
ation Board makes a recommendation for
the level of fee to be awarded based on
the performance observations. The Fee
Determination Official then makes the
final decision as to what the award will
be.
We are now in our first performance
evaluation period. There are four cate-
gories of work activity in this period. The
first is initial system development, and is
broken down into three areas, overall
system design, inventory system, and a
H-14
-------
feasibility study of data needs of the
Office of Enforcement under TSCA. In
overall system design, the contractor
reviews the previous Sigma Data and
MITRE studies. He is to develop perfor-
mance specifications for the systems,
various ways of implementing these per-
formance specifications in terms of hard-
ware configuration, and what software
would be used. He will present the
implementation options to EPA for con-
sideration. The second activity is the
inventory system. This is the first system
that will be developed under this contract
and is envisioned as being the central core
of the overall TSCA information system.
The first task that I talked to you about
was overall system development, and how
the various pieces are going to be put
together. One of the pieces is the
inventory system. There are a number of
magnetic tape files that will be generated
by the Chemical Abstracts Service (CAS)
that will be provided to Informatics who
will manage and provide access to those
files. CAS is creating the inventory data
base but is not providing search services.
Therefore, Informatics will be required to
design a system to process, manage,
update, and provide both public and
private access to data collected under the
CAS inventory contract. We envision that
the data collected under the inventory
will constitute a core record, and will
provide a central reference to whatever
other sub-systems will be needed under
the TSCA information system. Other sub-
systems may be for regulatory, testing
regulations, citizen petitions, and health
and safety studies data.
Our third activity is the feasibility
study of data needs of the Office of
Enforcement (OE) under TSCA. One of
our next speakers will be addressing that
in detail, but at least one need is for
production data which will be collected
under the Act. The feasibility study will
examine methods of providing needed data
to OE, whether it be as part of the TSCA
information system or a separate OE
system.
The fourth area at which Informatics
will be looking is data risk analysis, to
examine and identify threats to data loss,
data modification, or unauthorized dis-
semination, identify the probability of
occurrence of these events and compute
what the cost of each event would be.
Information will develop several levels of
risk reduction and identify the associated
costs. We have a subcontract with Com-
puter Resources Coorporation, who has
been doing some work for MIDSD under
the COMNET contract, to provide us with
guidance on cost/benefits of risk reduc-
tion and an overview of risk analysis. Of
course, there is also an interface with the
TSCA Security Task Force, which is
focusing on security of manual data.
Another activity under this first four-
month period is support to rule-making
groups. This is on-demand work which
will be focused on data formating and
representation, and analysis of the impact
of proposed regulations and trendfore-
casting.
Finally, the last activity under this
first four-month period is project manage-
ment. That may seem redundant, but it is
contractor resources expended on
management of the contract, to assure
adequate resource control in terms of
hours and dollars; providing online inter-
face wtih the project officer; and
identifying problems at an early stage and
taking corrective actions in a responsive
way. After this first period, when ade-
quate controls have been established,
there probably will be little need to
continue project management as a task.
Regarding in-house project management
staff, we have a project officer and two
other persons assigned full-time. As
needs develop in specific subject areas,
other persons will be rotated in and out.
H-15
-------
CONFIDENTIALITY
Demise Swink
What I want to discuss with you is
activities of the Confidential Material
Task Force, established a couple months
ago. The Task Force is developing pro-
cedures for handling confidential material
collected under the TSCA reporting
requirements. One of the first things that
came up in the Task Force deliberations
was that, even though the MITRE Study
had been done, it had been six months to
nine months since people discussed the
kinds of TSCA information of interest to
them and required methods of access.
Consequently, the Task Force executed a
Agency-wide information needs survey.
First of all, we had a tremendous
response and we really appreciate it. All
the research laboratories responded and
ail of the Regions. There was one
response from each research lab and two
responses from each of the Regions, one
from the TSCA coordinator and one from
the enforcement coordinator. We began
by asking in this way what specific infor-
mation each organization would be
interested in. Data items included were:
chemical identification, company name
and address, production volume, by-
products, import/export, health and safety
studies, molecular structure, plant site,
process, categories of use, exposure data,
common or trade name, types of activity,
site-limited chemicals, method of
disposal, and test data. The Regions
generally said that they have a high
degree of interest in all the data, parti-
cularly with 100 percent response of
interest in chemical identification,
company name and address, production
volume, by-product, processes, common or
trade name, and method of disposal. The
research lab responses were quite
different because their interest in the
data is specific to the kinds of research
performed at their labs. All of the
research labs did report a general interest
in chemical identification, method of
disposal, and test data. The next thing
that we asked in the survey was, what
would be your selection criteria? If this
information system was available, how
would you access the information? The
regions generally responded that they
would select most often by specific
company name or by single chemical. The
research labs responded that they would
select information mostly by single
chemical. Other selection modes were
identified, such as by regions, generic
chemical groups, plant sites, and river and
air basing. Now as far as accessibility to
the information, 8 of the 10 Regions feel
that they need continuous access to TSCA
information with a very strong interest in
a capability for immediate response to
requests. Sometimes 24 to 48 hours
turnaround response to information
requests will be acceptable for these 8
Regions. Two of the Regions reported
mostly 24-hour to 48-hour responses, but
they did state that from time to time they
would probably need, for emergency
situations, an immediate response to
requests. Twelve of the 15 research
stated labs that they would need only
occasional access to the information, and
that a 48-hour turnaround mode would
generally suffice. Two of the research
labs will need continuous access but not in
an immediate response mode. Another
four research labs stated the same thing
as two Regional offices, that we will need
information occasionally, but there will be
certain sutuations such as emergencies,
that we will need to have immediate
response to request.
The reasons given by the Regions
regarding use of the information were:
implementation of TSCA, including
investigation and enforcement; response
in emergencies; planning strategies,
including pre-determination of problem
areas and preventive measures; execution
of surveys, monitoring, and risk
assessment; establishment of priority and
H-16
-------
contingency plans; NPDS requirements;
issuance of permits; characterization of
the region in general; and development of
regulations. The research labs reasons
were that they needed the information
for: design of health studies; industrial
assessments for R&D of Pollution Control
Technology; design of experiments;
ecological effects testing design of hazard
evaluation programs; assurance of proper
storage and adequate protection of
personnel having access to materials in
the lab; development of identification or
measurement technique; application of
measurement techniques; and source and
characterization, transport and transfor-
mation studies.
As you can see, there are varying
degrees of requirements for access to and
use of the information collected under
TSCA. The task force will analyze the
feasibility of continuous immediate
access, distributive processing, and
terminal access. One thing the task force
did find out through the services is that
there will probably be many requests that
will be able to be handled by OTS
headquarters. Requests could be sent by
registered mail within a couple of days to
the field offices. There has been no
policy decisions whatsoever on the
mechanism to get the information out to
the field offices. The determination has
to be made of what consitute the need to
know and what kinds of mechanisms from
a security aspect are acceptable. The
driving force of all the policy decisions
will be maintaining the integrity of the
confidential material being reported under
TSCA.
H-17
-------
QUESTIONS AND ANSWERS
Ken Olsen: First of nil, I want to thank the panel. I really appreciate the fine talks
that were given. It is an awful lot of information to try to cover in a
short period of time. They did provide you with an excellent overview of
all the activities, not only our long-range plans, but our immediate
implementations. This slide ties it together for FY 78. There are three
basic components on which we will focus in or around October, or the
start of FY 79. The first is TSCA inventory, publishing the final rule
sometime in early December. Second is the completion of the processing
system design. Fred mentioned that it was complete. But, there have
been a few minor changes in the regulations as well as in Form D, which
has voluntary reports of product trademarks containing those chemicals
that have been reported for the inventory. Thus their processors will
have some assurance that what they are buying will still be on the
inventory often a chemical company will sell a chemical under a product
trademark without the customer knowing what is in it. The reporting
period is scheduled from the 1st of January through the second of May,
120 days. With the unknowns we are still projecting form processing to
be complete early in the fourth quarter of FY 79. We will be spinning off
a file sometime this summer. We will transfer a file of information from
CAS down to the TSCA information system into the inventory module
pilot. That should contain 75 to 90 percent of the information reported
under the inventory. It will not be a complete inventory listing. The
Office of Enforcement has discussed this with us, and we were able to
make this Modification to our schedule in response to their needs. The
confidential handling procedures are there as well, and in order to make
this partial inventory operational throughout the agency, we will have to
evolve an EPA order for the handling of confidential information. That
information can be properly transferred to the user groups.
Question: I have a basic question on your current and future staffing of your ADP
contracts. First of all do you have any staff on board right now that
work with you full-time?
Answer: In the Office of Toxic Substances, the Assistant Administrator, Steve
Ellinek, has proposed reorganization to the Administrator. We will be
working within a Chemical Information Division, a parallel division to
Hazard Evaluation Testing, and other divisions that are established. The
information division has been given equal authority with all of the other
divisions. The ceiling for that division is some place in the 30's. I don't
know whether it is 31 or 39, but it is some place yet to be finalized. We
do have on board now a staff of 17 people, including two full-time
computer systems analysts, several program analysts, some information
specialists, and four chemists - chemists that are particularly interested
in chemical nomenclature, chemical information, and rulemaking. The
size of the CAS contracts, I believe, is about $420,000 to compile the
inventory over a two-year period. The Informatics contract is a $3.1
million over a five-year time frame. We have a few smaller contracts.
The minor contract was around $80,000. The computer resources control
on computer security is $10,000 and there are a few things in the
planning stage.
H-18
-------
Question:
Answer:
Answer:
Howard Howell, Program and Reporting Division. Please try to fit
together the ILRG with the inventory with CIS. How do all these
systems interrelate overall? It seems like an awful lot going on here, as
TSCA would probably require anyway. How are these pieces going to fit
together in a meaningful way?
Our system is strictly in response to rulemaking, and we have now a
schedule for the publication of the inventory. The ILRG may want us to
get into some of their schedule. I do not believe they have finalized
some of their schedules in the information exchange group yet, but we
are still working in the work plan stage. A lot of what we will be doing
under TSCA, particularly in the inventory and in the confidential
handling, would be of great value to ILRG. Some of the things that the
ILRG will be doing, we will be able to work along with and benefit from.
Warren, do you want to get into some detail about ILRG?
There are two ways to cut this thing. A number of the ILRG activities
are an effort to develop common approaches, common identifiers,
common approaches to monographs, maybe even single monograph
productions, and so forth, coordinated reporting, recordkeeping activi-
ties. I do not think your question really goes to that so much as really
the question about the systems development activities. How are these
linked together with the Office of Toxic Substances and other activities
around the Federal Government? The MITRE contract, lays out their
vision of a future Chemical Substances Information Network, as Morris
described with the 10 core components. Two of the 10 core component
systems are TSCA generated, one being the proprietary data base which
includes all of the data under TSCA. The other is the public portion, the
non-confidential portion of it. Two of the 10 are those being developed
by the ILRG which have feasibility studies dealing with the data analysis
and the ability to identify applicable regulations with respect to
individual chemical substances. Others include the directory activities
that Morris described, which are basically various file and data systems
descriptors in terms of data elements. Another is the whole sub-
structural search capabilities, again that Morris described. Most of the
others related to bibliographic and other types of data systems which are
available or in latter stages of development through the National Library
of Medicine. These are some of the 10 core systems. The hope and
thought would be that an individual user in any particular agency will
have access to these 10 independently managed data systems so that, to
the maximum extent possible, common identifiers will be incorporated
into their files.
The MITRE contract, sponsored by the Office of Toxic Substances, the
National Library of Medicine, and the Council on Environmental
Qualities, serves as an informal vision on this whole activity. There is no
specific, master, Federal time frame or development plan. I think that
the concept has been generally endorsed by the various agencies that
have reviewed it. The ILRG, the National Library of Medicine, and OTS
are making every effort to move the development of their components
along as quickly as possible. They are each operating on slighly different
time frames. Concerning ILRG activities: we are having feasibility
H-19
-------
Question:
Answer:
Answer:
studies on these two activities done in approximately six months,
depending upon the nature of the follow up activity that is required. I do
not know how long the implementation -will take. There are, of course,
the contract procedures which need to go through. We have been very
fortunate to use the very rapid contracting procedures that the Council
of Environmental Quality has available to the multi-agency effort, and it
has been a multi-agency effort with the National Library of Medicine,
CEQ, and others participating in the support of these activities. Once
one gets into the implementation phases on specific agency files and
when an agency has got a lead on developing and implementing particular
systems, one is almost certain he will be operating through the agencies'
own procedures. In closing, we do have a very close relationship between
OTS and ILRG. We are implementing our systems in accordance with
their philosophy, so eventually when this thing does come off, no matter
what timeframe it takes, it will be compatible.
My name is Robert Greenspan and I am with the Office of Water
Planning and Standards. I have a question about environmental
monitoring data. My question is how does OTS anticipate using
environmental monitoring data, if at all, under TSCA or other legisla-
tion? How much data do you intend to use? How often? From where do
you intend to get it? Do you get it yourself? Do you get it from
someone else? How do you intend to interchange information to allow
easy access to environmental monitoring data?
That is a big order. Let me say one thing about the Act. The Act.
states that if any sort of a regulatory action is needed it can be taken
under an existing piece of legislation, such as FWPCA or any other act.
The regulation should be written under that Act. We're only kind of
filling the big crack or void in-between. Under my group, we have a sub-
group. Our subgroup is looking at networking within EPA and with other
systems outside of EPA. We are addressing the monitoring problem. I do
not know how far we are.
You want us to ask what is likely to happen with respect to toxic
substances monitoring. One question that comes up in the whole area of
toxic substances monitoring is: what is a toxic substance? Is So2 in the
air a toxic substance? The definition of the chemicals with which we
become concerned is a very dynamic kind of thing. It changes over time.
The chemicals of concern in 1971 have been rapidly expanding. The
other question that I will have to ask is what type of monitoring is likely
to be done strictly in the toxic substances context. Are we going to be
thinking in terms of doing anticipatory monitoring, going out and
monitoring things in order to identify a new problem? I think there is
going to be very little of that type of monitoring to be done, at least by
our program office. I would anticipate the type of monitoring that would
be sponsored by the Office of Toxic-Substances would be more exposure
monitoring, the type of monitoring which will allow us to scope out the
character or size of the type of problem that we are dealing with,
anticipatory to Section 6 and other types of regulatory activity, or
perhaps in packaging it up and passing it off to some other program or
agency to be dealt with under their Act. I would not anticipate that the
H-20
-------
Question:
Answer:
Answer:
Question:
Answer:
Answer:
Office would be undertaking any large scale-oriented monitoring activi-
ties. Those presumably continue to be carried out by Water, Air, and so
forth. On the other hand, we will certainly want to take advantage of
the data that is collected there and will be working closely with the
STORET people and so forth. I come from CEQ. We are very high on
UPGRADE as a data analysis tool, and we are aware of the activity that
OID is sponsoring to identify the utility of the UPGRADE analysis system
as a tool for analyzing data files available in the Agency. We would hope
to see that that kind of tool will be available to us as a program office to
be able to analyze some of the data that is available in the agency.
You are telling me then you have no plans, as far as you know, to
generate the new OTS environmental data handling system?
We have not really defined exactly what the monitoring program is likely
to be. I would anticipate that the focus of our monitoring would be with
respect to identifying toxic substances issues. There may be some data
handling which would be required for that type of data, but it is not
likely to be anything of the type that exists in the program offices where
regular and ongoing media-oriented monitoring occurs and other type of
monitoring and effluent typed monitoring is going on. Ours is more likely
to be a one-time shot, in an effort to find out what we are dealing with.
I would like to make one short additional comment. The MITRE Study
indicates a string of about 20 or so other files within EPA and outside of
EPA, all of which will be used to help support the OTS missions. No
where in that constellation is there an OTS monitoring system. There
are too many things for them to rebuild. They have to use everything
that exists.
I had a lingering question. I am with Water Planning in Headquarters. I
am working in the pre-treatment area, basically with sewage treatment
plants and toxic substances. Our main interest right now is the list of
129 substances that they are studying. I assume your hazard evaluation
division is studying this, too. What is the status of your study?
I do not think we are evaluating the 129 substances at the Water Planning
Offices. We had a meeting with them about three weeks ago. We were
looking, at that time, at integrating our list of substances and also
integrating our list throughout EPA, to try to work together and
coordinate these efforts. I do not know of any effort, although I could be
wrong, because I am not sure of what is going on in all the groups within
OTS. I do not know of any specific hazard evaluation of those 129
substances that we are doing.
Let me address that briefly. In the proposed organization with the
Office of Toxic Substances, there is a proposed Steering Committee of
the Assistant Administrator and three Duputy Assistant Administrators
in the area. The major function of that Steering Committee is
anticipated as reviewing the information status on individual chemicals
and determining what stage of work they belong in. Do they belong in
the area of needing to get more reporting on this particular chemical, or
should we be going to a hazardous assessment on this chemical? That
H-21
-------
mechanism is obviously not yet operational. There are not DAA's at this
point. In anticipation of that type of activity, Steve Jellinek has
initiated a Zow key effort to review those existing hazardous assessments
that have been done in the Office over the past few years, and to review
the type of information which has been developed by the Interagency
Testing Committee in cases where they identified a number of chemicals
as low priority for testing. Their chemicals are relatively more
hazardous. In attempting to take an overview of all of these chemicals,
some of which may overlap the 129 and to identify those chemicaZs which
under TSCA, there may need to be future Section 6 action, I think the
feeling is that we ought not to avoid the 129 completely, because those
were developed through your litigation process. The water program may
be dealing with the water effluent aspect of the particular toxic
substances, but there may be other important ramifications in terms of
appropriate or inappropriate abuses, occupational exposure, or whatever,
that are leading to other media and other types of problems that would
.either fall under TSCA, or might be a concern for other agencies. Some
of those 129 may require additional testing for other agencies, or for
EPA, to take actions. There is some low-key review to decide whether
or not to come up with a Zist of chemicals against which we may want to
undertake Section 6 action. There will be reviews, overall lapping of the
129 with respect to testing rules or other types of evaluations that will
be going on in the office.
Question: There will be a very grey area. They are not going to be able to master
the significance, they are not going to develop guidelines. There will be
some interest in the ACP. Maybe there will be only one manufacturer in
the country, so there would not be national guidelines developed under
the Water Bill. Yet, it still remains as a concern, and then it becomes
TSCA. I'm wondering if you know?
Answer: I think that is right. Steve Jelliner is very well aware of the fact that
for the foreseeable future, we will not have enough resources to deal
with all toxic substances problems. What he is trying to do is develop
priority systems where we focus our limited resources on the highest
priority problems. Where there is one manufacturer, there is a very
localized problem. There is not a large exposure to either humans or the
environment to this particular toxic substance. It might be a lower
priority than one where there is broader exposure and/or better
characterization of toxicity.
Question: My name is Sherman B. Arthur from Region 9. Do you anticipate any
significant impact of the TSCA information requirement on regional
offices and especially in terms of data collection and handling?
Answer: You mean with respect to having people report to the regions? At the At
the present time, we do not see any reporting directly to the regions
under TSCA. We are working with the regional people now, and we'll
have a training session in Washington on the 13th, 14th and JSth of
December to have the regions provide assistance to people who will be
reporting to us under the inventory.
H-22
-------
CONCLUDING REMARKS/PANEL SUMMARIES
Willis Greenstreet
First, I would like to say that I am gratified and surprised to see so many of you here
at this late wind-up session. I also want to say that I am terribly pleased that the
conference has met my original intent. As you may recall, I announced at the opening
that this conference's purpose was for everyone to talk together. I think that has occured,
at least to my satisfaction. I would hope that you would continue this dialogue at other
opportunities, not the least of which is using the fine FTS system. You have to work at
talking to each other. It simply will not work any other way, because we are a very
dynamic organization in the truer sense of the word. We have certainly picked over our
bones in the past few days. Mine were just picked before lunch and I feel especially raw,
but nontheless we all understand some of our def iciences and we also have learned that we
do have some strengths in what we are doing. The overriding consideration with which I
am concerned, however, is that we all understand both our strengths and weaknesses, and
hopefully we can decide in what direction we are going. I am going to try to move as
rapidly through this as possible. I think that the panel chairmen can make very brief and
concise reports.
PS-1
-------
GENERAL SESSION II: PANEL SUMMARIES
Distributive Processing Summary
Theodore R. Harris
When we started out, we heard a lot of definitions of Distributive Processing. The
Distributive Processing panel also tried to define it. The purpose of the panel was to
present to everyone what EPA is doing; the panel represented the many different views
within the Agency. All of the EPA mini-computer managers who have POP 11/70 mini-
computers have made presentations. We had presentations of some applications that are
currently running on the mini-computer, and we had two presentations on the view from
EPA national data base managers. Several issues were raised. I will briefly state what
they were. Regarding distributive data bases, we need to find out the techniques of how
and when to validate them to national data bases. With system analysis, design and
implementation of software on distributed systems, the most important issue was the
shortage of highly qualified personnel. The issue of coordination within the regions and
labs was discussed. A new issue identified is the coordination with the national system
managers. The suggested answer was to invite to the national systems managers to the
mini-computer mangers' meeting, which happens every six months. I am inviting all the
conference attendees who would like to attend this meeting. In summary, there is a lot of
enthusiasm. EPA is doing things. Our approach is conservative, well-planned; and is
taking advantage of new technology and the state-of-the-art for the betterment of EPA.
PS-2
-------
Effluent Data Systems Summary
Jack Sweeney
We had three presentations, one from the Office of Enforcement on their proposed
compliance analysis of the effluent data system. We had a second presentation from
Region II, which is one of the three regions that have some form of effluent data system,
and a third presentation from a monitoring data support division on an application of
effluent data and water quality analysis situations. We had a very lively discussion during
the meeting, particularly in the area of the use of effluent data and the enforcement
program. About half a dozen major points came out of the presentations and discussions.
First of all, effluent data is being used quite extensively right now in a variety of
programs. It is used in the 208 Water Planning Program, and also in the facility planning
that goes on in the Construciton Grants Program. The second area is water enforcement
where it is being used for the NPDES program, and also in the development of effluent
guidelines. It is now being regarded for use in the toxic program and appears to have
applications in the water supply program for point sources upstream of water treatment
plants.
The demand seems to be increasing for effluent data, but the availability or
accessibility to that data by the variety of people that are using it in one form or another
is very limited, because it is not available or easily acessible in an ADP system. There are
a number or organizations that are looking to some form of an ADP system to handle
effluent data. At the regional level, there is not really consensus yet, as to whether
effluent data systems are needed. There are three regions, Regions X, VIII, and II, that
have some form of an effluent data system right now. Region VI is apparently interested
in volunteering as a pilot region for the system that Enforcement wants to bring out. At
the state level, there are seven states to my knowledge that have effluent data systems
right now. At the Headquarters level, there are the Office of Enforcement, Office of
Water and Hazardous Materials, and Office of Toxic Substances that are displaying an
interest in effluent data. There is a growing interest, but there is no bringing it all
together at the Agency level. There does not seem to be a single office in EPA that really
has the authority to play a leadership role in pulling together all these needs for effluent
data, trying to address them, and most likely coming up with some kind of EDP system or
systems that will address those needs. The key to resolving the problem, I think, probably
lies initially in the enforcement area.
There is not a consensus, of course, between regions and the Headquarters as to
what the need is. I think most of the discussions that occurred at the session really zeroed
in on the Compliance Analysis System that Enforcement is now proposing. At the regional
level, there are a lot of serious reservations as to whether that is the right way to go.
Some of the main problems that were thrown out in the question and answer session was
that of the resource impact of implementing a compliance anlaysis system. The
feasibility study that was conducted seemed to project very low estimates as what
resources will be required to implement the system. Once the system is implemented,
there is the question of what happens to these positions that are supposed to be saved
through an effluent data system. There is also the question, is Enforcement going to take
these positions back? Even if they are not taken back, how are they going to be
reallocated at the regional level? For example, you have shifted the workload away from
the Enforcement Division to the data processing branch. That issue has not been
addressed. Another point that was raised was that the regions felt that enforcement was
doing an end run in terms of pushing ahead with impleminting a compliance system
PS-3
-------
without getting a real clear mandate from the Regional Administrators. Another problem
was that the regions felt that it was going to be a mandatory system, and what might be
good for one region may not be good for another. That depends, in part, on regional
priorities and also how many states may have the permit programs Another point that was
raised was have they really considered interfacing the system with STORET, which seems
to be a system that could handle effluent data and make it available to planners to the
states, and a lot of other people within EPA? Apparently, this interface has not been
hammered out, or even considered in any detail. The last point is that enforcement has a
need to get out into the field and develop more grassroots support for the system.
Probably, the only way that they will do that is to go around to the regions individually
and discuss the Compliance Anlysis System study.
I think the main point, however, is that there really is not anyone in EPA that is in a
leadership position to resolve the problems that we now have with effluent data. One
proposal made was that EPA re-activate or set up a special steering committee, at the AA
level, to address the question of effluent data.
-------
Exchange and Standardization Summary
Ted Standish
The thrust of the Exchange and Standardization Panel was not just to address that
issue from the motherhood standpoint, since I believe all of us agree that we need to get
better capabilities for standardizaing and sharing the work that we are doing. For a more
pragmatic reason, the 1981 procurement effort for data processing is going to impact us in
two potential ways. One is that we may not be faced with compatible equipment with
either our current IBM or UNIVAC equipment, and secondly, my understanding of the
current GSA regulations states that if a software system is not documented, the
contractor is not responsible for converting it. There is a need to start working on
standardization within the Agency. We had presentations of software standardization,
methods to tie the programmatic data bases together, a presentation on data processing
hardware standardization, and a presentation on word processing standardization.
The issues that I saw that came out of the discussions included the following. We
are faced with the imminent issuance of software design, programming, and documenta-
tion standards by MIDSD. The draft stardards for documentation will be issued in 3anuary;
for programming, in February; and for design, in March. We have been requested to
review those in detail and get our comments back to MIDSD as quickly as we can. Linda
Tucker from Ann Arbor also brought up the issue of data security standards that has arisen
out there and the work that they have done. As I understand it she will be submitting the
work that they did on data secruity to MIDSD. In addition, she also is willing to share
work that they have done on software exchange, especially as it relates to the GSA
Software Exchange Committee. The contract with Arthur Young dealing with the
potential for standardization of data elements within the Agency, was also mentioned.
The RFP is in the final phase, and if anyone has any comments, or any concerns about
that, they should contact Frank Bullock.
As far as Agency ADP equipment is concerned, we will continue the Agency
contract for remote job entry terminals and for mini-computers. The standards for those
two areas will be the same as the ones in the current contract. If anyone has any
additional needs, or any changes to those, they should send them into Ted Harris as soon as
possible. The second thing mentioned as far as ADP equipment was concerned is that we
will not continue with a standard Agency contract for low speed terminals. Instead, the
standards that had been set for those terminals will remain in place, but each region will
be free to use the GSA contract to obtain their own equipment. It was suggested by
MIDSD that if we are intending to keep a low speed terminal for anything more than 18
months, we should seriously consider purchase since the lease vs. purchase payback period
is less than 18 months, in most cases.
In the case of word processing, there will be an order being issued by the
Management and Organization Division within the very near future that will standardize
word processing guidelines across the Agency. M&O Division is also willing to come out to
each of the regions or laboratories to help set up standards within the regions or
laboratories for word processing.
In terms of trying to tie the various Agency data bases together, it was mentioned
that Region III will be letting feasibility study sometime in the beginning of the new
calendar year, to pick up on work that was done by the Philadelphia 208 Agency that did
attempt to tie together the various data bases for water supply, grants, water quality,
effluent data, and so on.
PS-5
-------
One last thing that was brought up and which continued last night is the coordination
efforts necessary among all of the people here, and among the people within the Agency.
This Conference is certainly one of those efforts. In addition, last night, we had another
one of our peaceful regional ADP branch chief meetings. We have agreed among the
branch chiefs that becasue the workload that is coming out to us in reviewing proposed
systems and in trying to respond to the Headquarters issues being raised, the regions will
group themselves into three areas. Regions I, II, IX, and X form one group. Regions HI,
IV, and V form a second group; VI, VII, and VIII form another group. We have agreed
among ourselves that at least one region from each of those groups will review every
feasibility study that was prepared by Headquarters. There was a general consensus
among the ADP Branch Chiefs that if a system, is not in the zero-based budget, no support
will be given to that system. There was also concurrence that if the Regional
Administrator has not approved a proposed Headquarters system then Headquarters does
not have committment to that system from the region. We are asking that in cases of
proposed feasibility studies that would effect the regions, that each organization
preparing to initiate the feasibility study send a memo to the Regional Administrator with
a carbon copy to the Management Division Director announcing the feasibility study and
which regions will be contacted as part of that study. We are concerned that our
coordination with Headquarters be improved. We feel that by announcing the feasibility
studies ahead of time, we will be in a better position from the regional standpoint to
provide meaningful comments and meaningful suggestions on the way to go in the future.
PS-6
-------
System Development Cycle Summary
Morris Yaguda
In our panel, we had four presentations and two terminal demonstrations. Two of
the presentations dealt with what I refer to as Stage 4 Systems, using the familiar Nolan
Stage Hypothesis concept. That is, the first two presentations in our panels dealt with
systems based on other systems. These are the CEQ UPGRADE system, and the EPA-NIH
Chemical Information System. The UPGRADE system is a system that the CEQ
developed, when they were trying to write their annual report. They found they needed an
automated system that would let them look at water data, air data, demographic data,
health data, and pull all those things together with a very sophisticated analytical package
that would let them make some statistical sense out ot the interactions of these various
data bases. It should be pointed out that the Office of Research and Development in EPA
is presently exploring, through a systems study, whether or not this system can be brought
into use in EPA. ORD is sponsoring a survey of EPA offices to find out which offices have
a need for, and would use such a system. If anybody does have such a need, they should
contact Lance Wallace. They are also investigating the implementation alternatives
available at the present time. This system now runs on the NIH computer. They are
presently adding the SAS (Statistical Analysis System) package to it. It runs in a TSO
region in over 500 K. The question arises, where can one run such a large system? The
package has tremendous flexibility.
The second stage 4 system is the EPA Chemical Information System. Steve Heller
of MIDSD gave a presentation on it. This is a system that has two basic operational
components. One of them is the sub-structure search system, and the other is a set of
technical data bases, representing laboratory instrument readings and other technical data
for specific chemicals. The sub-structure search component is the component that he
spoke about the most. It is a tool that allows you to address the system with a particular
chemical structure or fragment in mind and allow you to identify one or more chemicals
that have that common structure. Once you have done that, you can then ask the
question, what other files in the Federal Government, or elsewhere, have information on
that specific chemical? Once again, we see a system that has in it information about
other systems. Users have a locator system. If you find a particular chemical and you
notice that it was on the NIDSH hazardous chemical list, the TSCA candidate list, the
Japanese candidate list, and had some hazardous AMES test readings, you then know you
have a bad actor.
In the third presentation, Don Fitzpatrick talked about the Arthur Young Company
which does our feasibility study contracts. He talked about theory and procedures for
doing a major systems study, and he tempered his presentation with some comments
reflecting some very hard-won experience in EPA. They have learned that we are a very
complicated agency, that if you touch one part, you really have to look around to see what
is going on or what other interactions exist with other program components in
Headquarters and out in the field. Even beyond that, you have to look very carefully. In
some of the recent studies, they have found that there is a tremendous emphasis nowadays
in looking at the impact on the public reporting burden that is implied in some of the
alternative ways of implementing systems. Don stressed the fact that it was very
important in trying to plan effectively for these systems and that you get everyone
involved early. I think he used the phrase, "You try to get everbody that ought to be or
should be interested together." I think his choice of words indicated that it is not always
easy to do. He also pointed out that it is really essential. He has found it to be essential
PS-7
-------
to have management checkpoints at certain key places along the way. You should not go
all the way to the end of the feasibility study and then hope to find that it will fit in. If
you recall the basic points in doing a feasibility study, you need to stop and check with all
the people who ought to be interested after you think you have understood the
requirement, after you have it on paper, and you think you understand what the evaluation
criteria ought to be. At that point, you should stop and check back. Make sure that you
have understood it correctly. Once you define a set of feasible alternatives, once again
(because there are so many feasible ways that you could possibly implement various
systems) you should stop before you do any detailed cost-benefit analysis. Stop and make
sure that you have the set of alternatives with which people are willing to live. Once you
have concurrence on that" point, you proceed ahead, do the detailed cost-benefit analysis
on the various alternatives that have been accepted and develop some draft recommenda-
tions. Once again, stop and check with management before you go through the trouble of
locking them up in concrete.
The fourth and last topic of the presentation was a briefing on the 1980's planning
effort, which essentially is the briefing that we are giving to senior management at this
point to show how we are, in fact, planning to develop the new systems for agency-wide
support. I would also mention that for the two systems, the UPGRADE system and
Chemical information System, we did provide terminal demonstrations. Unfortunately,
there was not too much time for too many people to get too much out of them, but I think
that those who were able to observe those systems were delighted. In our 1980's study, we
also had to face the problem of future costs. What can you say about future cost? We
found in the 1980's study that, as a first rough approximation, which we hoped was
adequate enough for planning purposes, we are using the assumption that inflation and
technological improvements will pretty much cancel themselves out over the future. We
pointed to the fact that if you look at the NIH Computing Center over the past few years,
after an initial cost reduction period as they put in larger and larger equipment and
achieved the economies of scale, their cost has pretty much stablized. We feel that is
support for our view point. If you are worried about inflation and technological
improvement, I suggest you might want to assume that they will balance each other out in
your studies. In our planning for systems we still have a long way to go in terms of
understanding the effects of states. There are varied requirements in the states and their
impacts on the regions.
PS-8
-------
Administrative Systems Summary
Neil Haley
Our panel was organized and conducted a little bit different from some of the
others. First of all, the objectives of the Administrative Systems Panel was to promote a
communication between systems managers and the systems users. We asked each of the
administrative systems managers to give a talk on their systems to discuss the
development of the system, the current status, and the future trends. The systems
managers who spoke were the managers of the personnel systems, the personal property,
the contracts management system, resources management system, finance and grant.
Then came interaction with a representative group of users through comments and
questions. We had representation from Air and Waste Management, Water and Hazardous
Materioals, ORD, and a regional office. One other thing—we had asked the systems
managers to prepare a paper beforehand for a couple of reasons. One was for the record,
and secondly, it enabled some of the managers to talk about their systems in a more
personal and philosophical way while they were comfortable knowing that the details of
their systems, or the technical aspects of the system were in the paper that would be in
the record.
It seems that there had been very little coordination between systems during the
development stage. Many of them were developed rapidly during the early stages of the
Agency, and had been developed primarily independently. They evolved from small update
and reporting systems. Initially, they were highly centralized and there was an initially
low development cost. Some of that is now seen in fairly high operating cost. They were
oriented in the beginning to meet Headquarters needs. In some cases, they had expanded
to meet other-than-Headquarters needs. This was characteristic. Under the Personnel
Management System, one of the themes brought out was that Mike Platt was very intent
on building the credibility of the PMS and building the credibility and reputation of his
staff. He was working very hard to meet very immediate needs, while at the same time,
working on more longer-range goals. The PMIS, one of their major efforts these days, is
to meet the new needs under ZBB, and to push towards MBO and try to tie those
techniques together. Regarding the Financial Management System, there was discussion
on the decentralized input/output process under SPUR software packages that were
available. With the Contracts Information System, Ed McLean said, right up front, it
serves the Contract Management Division and that's about it. He discussed his role in CIS,
how he had seen it evolve and how he though it might improve. GIGS is looking at new
mechanisms for updating the national master file. Also, the construction part of GIGS is
under review by an Arthur Young study. It is possible that the other portion of GICS will
be reviewed in some fashion. The Personnel Property System has been moved to NCC and
there was very stong endorsement that NCC was providing excellent service, and that the
transaction had gone quite smoothly. Some of the user concerns came out, not only in the
Administrative Systems Panel, but also in the ADP Management Panel and in other areas.
For example, the need for an integrated approach was mentioned. The administrative
systems managers were looking for some kind of agency-wide effort in this area. They
felt that on their own, as systems managers, they were not able to conduct anything like
that, and they were looking towards a higher level of support for this type of activity.
The users felt there was a need for better coordination between systems. There was a
need for a common technology for codes and standardization and so forth. They felt they
also needed to reconsider how some of the systems had been implemented, what they
were, the services they were performing now, and whether or not there ought to be more
flexibility and perhaps a wider range of users. Finally, another observation made was that
some user needs are just not being met by national systems; they are being provided either
by local systems, by makeshift systems, or not at all.
PS-9
-------
Water Supply Summary
Tom Martin
The water supply panel addressed that part of the Water Supply Program that deals
or relates to the supervision of public water supplies. From an ADP perspective, that
included primarily the Model State Information System and its follow-on system, the
Federal Reporting Data System. We accomplished that in three presentations. The first
presentation was given by Dan Barber and was entitled, "The Legislative Direction and
Decentralization of the Model State Information System." The second presentation was
given by Bruce Keith; it was entitled, "Meeting the Requirements of the Safe Drinking
Water Act and the Needs of the States and EPA." The third and final presentation was
given by Don Worley; it was entitled, "The Test and Acceptance of a System to be
Delivered to a User Other than EPA." From those presentations and the questions at the
end of the presentations, there were about six or seven major issues. The first was the
legislative direction, as well as general EPA-State relationships. The latter are tending
more and more towards a state role. As a result of that, MSIS was developed for state
usage on their own computer facilities or on the computer facilities of their choice.
Secondly, MSIS development was in fact impacted by the decision to develop a
decentralized system. Although much of this impact was attributable to whomever the
intended user was to be, MSIS was developed utilizing state-of-the-art techniques to
ensure reliability, maintainability, and usability. Also, MSIS was developed in an
extremely modular fashion in order to facilitate both adaptation or system enhancements
to satisfy specific state need. A third issue was the installation of a decentralized system
which can cause unique situations and problems to arise. For example, the installation
schedule, itself, once the system is developed, can produce a domino effect when anything
goes wrong in the installation schedule. Also, the installation of this system on different
computer mainframes results in problems because of the availability or implementation of
various facilities or capabilities on that mainframe. Nevertheless, we have discussed
some steps that can be taken to reduce system implementation problems. In MSIS's case,
we used some background information packages, various checklists. We have what we call
pre-installation management conferences which bring together the contractor, EPA, and
the state people before we go into the state. Then there is the package of post-
installation support in training, a user support group, and mechanism to modify the
system. Then, under testing and acceptance, the conclusion reached was that testing and
acceptance of such a system must be comprehensive and should include testing of the
total system, (i.e., testing of system design and program design, in addition to the
programs themselves, the operating procedures, the training facility, the usability of the
system, and system documentation). Finally, and this came out primarily in the question
and answer period, we discussed whether MSIS should have been centralized or
decentralized. The answer to this question can only be realized with time. We presented
issues on both sides; time will tell whether or not this is the best way to go. I think we
have something workable, though, and usable.
PS-10
-------
ADP Management Summary
Kenneth Byram
On our panel there were six of us from different parts of the Agency. The charter
was basically discussed and the question, what sort of ADP organization ought to exist or
not to exist in the central way in EPA? In other words, if you had to design an ADP
organization for EPA, where would you put it? Would you have it like it is now, or would
you have it more or less centralized? The people participating were from two regions,
Joel Brandon from Region V and Doug Shape from Region IV- Two were from MIDSD and
NCC, myself and Mike Steinacher; two were from Headquarters offices, Bruce Rothrock
from Enforcement and George Lehnert from Water and Hazardous Materials.
George started by looking at MIDSD's registered and approved functional statement,
going through it and seeing what it was that MIDSD was telling itself it was supposed to
do. One of the things that was brought out in George's presentation was that MIDSD has
responsibility for developing the Agency Management Information System. George said
that he was not quite sure what that was, and some of the rest of us admitted that we did
not know either, but that perhaps it was an archaic concept that needs a little
redefinition. One of the key things that I think George discovered in our functional
statement is that MIDSD is charged with integrating ADP efforts across functional,
media, and geographic lines within the Agency. George cited a couple of examples, one
which was MSIS. He felt MIDSD had done quite well with it. Another one that he thought
they had not done so well was the Hazardous Waste Management System. I think he was
indicating that there was great promise for good work here if systems could be integrated
across these lines.
Bruce Rothrock then attacked the problem from a little different angle, suggesting
that there were really four areas of effort that were of concern in data processing. One
of them was information management rather than data processing management. The next
was data management itself, ie., from where should the data come? What kind of data
should be collected? What should be the checks on that data? Also discussed were the
provision of software programming services and finally, the provision of harware services.
After introducing us to those four areas, Bruce suggested that the information
management function probably belonged mostly in the program offices. The programs,
themselves, were in the best positon to know what source of information* they needed and
what they should do with it. Data standardization, he thought, might be partly a
centralized function, and he said that, in a sense, it already was centralized with the
program reporting which exists within the Office of Planning and Management. Finally,
he suggested that the software and hardware services were properly a central kind of
function. He went on to suggest, in what he characterized as kind of a radical departure
from what we have now, that the central data processing organization within EPA might
properly consist of a group to analyze the data requirements, another group to provide the
software services, and finally a group to provide the hardware services. By software
service, I do not necessarly mean program analysis and system design. In a discussion that
followed around those two presentations, one point was brought out and that the
processing effort within the agency follows pretty closely what the agency itself is doing,
i.e., if the agency has a very clear idea of what it is to do and proceeds with it in a very
deliberate way, the data processing aspect of that program will also follow in a fairly
deliberate way. In many cases, it was very difficult to get an organized agency data
processing approach to a program, if the agency's approach was, in fact, not very
PS-11
-------
organized. Then we went with a chicken and an egg kind of thing and asked, do you
centralize the data processing and then get the larger thing together? I think it was Joel
Brandon who said that it sounds to me as if you are suggesting that the data processing
runs the agency.
There was some thought about where, if there was to be a centralization of any kind
of data processing with in EPA, it out to be. Some suggested it should be in a staff office
of the Administrator, or at least the Deputy Administrator; others though it could be
associated with the Office of Planning and Management which has functions like that in
other areas. The two regional people brought out clearly that they felt that centralization
of data processing efforts within a region was a pretty good idea, it had worked well in the
two regions they represented. Joel had an interesting discussion of some 20 or so positions
that had been devoted to data processing in one form or another before ADP was
centralized in Chicago. Since it has been centralized, the number of positions was
reduced to 11 or 12, with a much more organized effort than they had had before. This
was done partly be the logic of having the function centralized, partly by some
efficiencies when it was centralized, and also, by contracting out the clerical and sub-
professional or technical kinds of activities with a remaining higher percentage of
professional staff. Mike Steinacher talked about his experience with contracting out in
the operation of the data center at Research Triangle Park and providing several of the
services that it does down there. I think he endorsed his experience with contracting as a
very positive one. He thought it gave considerably more flexibility than if you tried to do
the same thing in-house, at least the way the Agency is currently organized and the way
that the emphasis is directed.
In summary, there seems to have been no very stong resistance to trying to
centralize more. The group, I think, as a whole did not raise large objections to
centralizing. I think it is important to emphasize to those who were not there that this
was a panel and not a Agency policy determination board so that the sentiment for a
stronger direction of data processing within the agency was with this group perhaps, it
might not be the agency's intent to proceed that way.
PS-12
-------
Toxic Substances Summary
Ken Olsen
Our panel gave an overview of the implementation of TSCA and its reporting
information system in order to provide a status report of what is going on and how are
interfacing with the various operating units within EPA and other Federal agencies
progressing. First, we started out with our design philosophy of the information system
being designed to support the decision-making processes under TSCA. We are taking a
very careful look at what decisions have to be made and what is really needed in risk-
benefit analysis. We then got into the overview, the big picture. We talked about the
requirements analysis that we conducted this spring. We talked about the activity of the
Interagency Regulatory Liaison Group, and specifically the Information Exchange Group,
in areas such as standardization and various networking possibilities between information
systems throughout the Federal Government. We then specifically talked about TSCA and
what is happening this year, in FY 78. We discussed the the inventory processing at CAS,
and how, by roughly a year from now, we expect to publish the inventory of commerical
chemical substances in the United States, a list of some estimated 50,000 chemicals. We
talked about our TSCA Information System contract with Informatics. We are designing
an information system to process all the data that will be reported under the Act's
authority. The Office of Enforcement discussed the compliance monitoring module and
how we are doing a feasibility study of the incorporation of the enforcement information
system within the OTS information system. Finally, we discussed our recent survey of
regional needs and laboratory needs with respect to data availability. We also touched on
data confidentiality and discussed why confidentiality is a driving force in our system
design and in our network. We are in the process of writing a new EPA order on the
handling of confidential information under the Act.
PS-13
* U.S. GOVEPMENT PRINTIHG OFFICE: 1978 0-620-007/3705
------- |