xvEPA
United States
Environmental Protection
Agency
Office of Water
(WH-S50E)
EPA 800-S-92-001
December 31, 1992
Public Water System Supervision
Information System
Modernization Project
Executive Summary
Synopsis
The Drinking Water program has experienced
considerable change in the past several years,
resulting in increased demands on State and
Federal data management systems. Most
recently, the Total Coliform Rule, the Surface
Water Treatment Rule, the Lead and Copper
Rule, and the Standard Monitoring Framework
have dramatically increased the complexity of
Public Water System Supervision (PWSS)
program. At the same time, EPA has embarked
on several agency-wide initiatives to improve the
quality, accessibility, and integration of
environmental data to support Federal, state and
local oversight and enforcement efforts.
In May 1992, the Office of Ground Water and
Drinking Water (OGWDW) began work with the
newly established EPA Systems Development
Center (SDC), to develop a PWSS Information
Strategy Plan (ISP) which would address informa-
tion needs for all stakeholders in the Drinking
Water program (Federal, state, local and public).
The resulting plan, which was developed utilizing
state-of-the-art Information Engineering (IE)
methodologies and technology, detailed a compre-
hensive Information System Modernization GSM)
program to improve the OGWDW's and Primacy
Agencies' ability to more confidently answer the
following key questions:
Is the water being supplied to the public safe
to drink?
Is the quality of the water getting better (or
worse)?
Moreover, the ISM program will develop
computer'soft ware to improve performance of the
myriad functions required to implement the
Drinking Water program at state and Federal
levels while supporting EPA's efforts to improve
overall enforcement and data administration,
including:
Supporting development of technology for
multi-media enforcement.
Implementing data standards, including
latitude/longitude standard and chemical
standard.
Supporting development of new data
standards, such as a sample standard.
Building towards data integration, including
supporting development of the EPA-wide
information architecture.
Developing improved public access to EPA
Drinking Water data.
SDC-OOS5-012-TB-2006A
(Reproducod'on Recycled Paper)
-------
The ISM Program is proposed as a four to
five year effort. Through the state/EPA Joint /
Requirements Planning (JRP) workshops,
conducted throughout the ISP developmental
phase, consensus was developed around a plan
wherein the first component of the system would
be the inventory management system. The initial
system would feature a "user friendly" Personal
Computer (PC) interface for users (located in
state and Federal offices) connected to EPA's
National Computer Center (NCC) IBM mainframe
system. Subsequent versions of the system could
be decentralized and distributed to states as
required. The inventory management system
would be built using Rapid Application
Development (RAD) techniques and be available
for Pilot testing in July-September 1993. Follow-
on projects would include Field Surveillance,
Compliance, and Primacy Implementation
Systems. These systems will be "rule-based"
systems with capabilities for tailoring the systems
to satisfy specific state regulations and
organizational structure.
k
\
The implementation of the ISM Program will
be continually guided through JRP structured
work groups including state and Federal
representation. The program schedule will focus
on rapid incremental development of functional
components, within the constraints of resource
availability. Development will initially be geared
to satisfy immediate needs of states with limited
automation, and with fairly straightforward
Drinking Water program infrastructure, while
keeping in mind the longer term needs of states
with advanced automation systems and/or more
complicated infrastructural organization.
We anticipate that the current FRDS-II
environment will continue to be supported for the
next 2 years and cutover to the new PWSS system
beginning for sometime in late 1994. All states
will be encouraged to adopt the new PWSS
system as their own operational system because
of the significant cost savings which could be
realized in state software development and
support. However, states opting not to utilize the
new PWSS information system as their own
operational system would continue to be required
to submit requisite data to EPA on a periodic
basis.
Purpose of the Executive Summary
This executive summary highlights the process
and products of the ISP development effort.
Additionally, the executive summary constitutes
the final progress report for the planning phase of
the PWSS Program. Questions or comments on
this document should be submitted to:
Mr. Larry Weiner
USEPA, Mail Code (WH-550E)
401 M Street, SW
Washington, DC 20460
'(202)260-2799
Purpose of the PWSS ISM Project
The mission of the Drinking Water Program is to
provide an adequate supply of safe drinking
water. To accomplish this mission, program
managers must know the^answers to two
fundamental questions:
Is the water being supplied to the public safe
to drink?
Is the quality of the water getting better (or
worse)? -
The purpose of the PWSS ISM Project is to
develop information systems that improve the
ability to confidently answer the above questions
sbc-0055-012-TB-2006A
-------
and to improve performance of the myriad
functions required to implement the Drinking
Water Program at state and Federal levels.
Background
The Office of Ground Water and Drinking Water
(OGWDW) conducted and published a detailed
Mission Needs Analysis in January 1992. One
result of this analysis was a concept for a Public
Water System Supervision (PWSS) Information
System Modernization (ISM) Program to support
both Federal and state information needs within
the PWSS program. By developing a shared
information system, significant economy of scale
could be realized; also the quality, timeliness, and
reliability of the data could dramatically improve.
In May 1992, the OGWDW undertook this
comprehensive effort, tasking EPA's Systems
Development Center (SDC) to complete an
Information Strategy Plan (ISP) using an
advanced systems development approach called
the Information Engineering Methodology
(IBM). An ISP involves three types of
analysis:
Identifying and analyzing the mission, goals,
objectives, strategies, functions, performance
measures, information needs, and data of an
organization.
Developing a target information environment
that satisfies the information needs.
Developing a strategy to implement the target
environment.
An ISP includes the following major
components, which will be discussed in the
following sections:
Business Strategy
Information Architecture
Business System Architecture
Technical Architecture
Information Strategy
A series of Joint Requirements Planning (JRP)
sessions, involving Federal and state representa-
tives, served to provide user input throughout the
development effort.
Business Strategy
The mission, goals, and strategies of the PWSS
program were determined during JRP sessions
with several state and Federal representatives. A
PWSS Business Strategy Statement, shown on the,
foldout following this page, was prepared to
summarize the strategy. Additionally, the bus-
iness strategy was analysed to determine the
information needed to monitor the implementation
of the business strategy. These information needs
serve as the high-level requirements for the PWSS
program.'
Information Architecture
The Information Architecture describes the
functions performed by the PWSS program and
details the data required to satisfy the information
needs. The results of this analysis are contained
in two computer-based models:
The functional model, defining the operational
functions and the relationships among these
functions.
§DC-OObb-U IJ.-
-------
The data model, defining the types of
information required to satisfy information
needs and the relationships among the data.
PWSS Functional Model
The PWSS functional model provides a high-
level picture of the activities performed by
organizations involved with public water systems.
A high-level Junction is a grouping of related
business activities (e.g., Sanitary Survey
Scheduling), which may be performed at varying
levels of an organization or by completely
different organizations. Inherent within each
function are the coordinating, supervising,
managing, and reporting activities common to any
area within an organization.
Eighteen high-level functions were identified.
Each function within the model is a candidate
function for automation some will be automated
and others will continue to be manual.
The high-level functions include:
Program Administration: Rule and Regulation
Development; Resource Management;
Implementation Planning; Primacy
Administration; Policy and Guidance
Provision; Grant and Loan Administration;
Implementation Support; and Implementation
Assessment.
Water Resource Planning: Geographic Area
Analysis; Forecasting; Source Protection;
Contingency Planning; Allocation; and
Conservation Actions.
Lab Capacity and Certification: Lab Site
Review; Lab Personnel Qualification; Lab
Capability Capacity Assessment; Lab Quality
Assurance/Quality Control Plan Evaluation;
and Lab Certification.
Risk and Vulnerability Assessment:
Vulnerability Analysis; Risk Determination;
Health Advisory Development; and Cross
Connection Control.
Data Management: State Federal Interface
Guidance; Request for Information Response;
Information Systems Development; and
Information Systems Maintenance.
Technology and Methods: Technology
Assessment; Applications and Methods
Development; and Standard Development.
Operator Certification: Operator Tracking;
Operator Classification; Operator Exam
Administration; and Operator Certification
Issuance.
Engineering Plan Review: Engineering.Plan
Evaluation; and Construction Inspection.
Field Surveillance: Sanitary Survey
Scheduling; Sanitary Survey Performance;
Inspection and Site Visits; and Survey and
Inspection Followup.
Disease Outbreak and Surveillance:
Epidemiology and Public Health Coordination;
Outbreak Analysis and Recommendations; and
Public Notification.
Compliance Determination Resolution:
Inventory PWS; Waivers and Exceptions
Administration; Permit Issuance; Monitoring
Plan Development; Water Sampling; and
Monitoring Performance Assessment.
5DC-OO55-O12-TB-2O06A
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
Technical Assistance: Technical Assistance
Needs Assessment; Technical Support
Provision; and Networking and Coordination.
Enforcement: Enforcement Case
Development; and Enforcement Tracking.
Emergency Response: Emergency Response
Coordination; and Emergency Response
Assistance.
Training: Training Needs Identification;
Training Development; Training Presentation;
and Training Records Maintenance.
Outreach: Outreach Material Development;
Risk Communication; and Public Education.
Inventory Plant and Equipment
Inventory Population
PWSS Data Model
The PWSS data requirements were derived from
two principle sources:
1) Information needs required to implement the
business strategy.
2) Analysis, of documentation relating to the
PWSS program, including legislation, rules,
and mission area analyses.
The analysts first identified the basic entity
types for PWSS. An entity type is a fundamental
thing of relevance to the PWSS Program about
which data may be kept. Examples of this data
include: inventory information, violations, and
enforcement actions taken against a PWS.
Related entities were then placed into subject
areas, or high-level associations of related entity
types. Finally, relationships among the entity
types were determined and modeled using an
Entity Relationship Diagram (ERD). PWSS
subject areas include:
Compliances: Information supporting the
compliance determination. Compliances
information is used to evaluate
implementation of PWS program
requirements, oversight efforts, violations,
and actions to return systems to compliance.
Controlling Instruments: Information
concerning legislation (i.e., the Safe Drinking
Water Act [SDWA]~and SDWA amendments);
National Primary Drinking Water Regulations,
National Secondary Drinking Water
Regulations, safe drinking water policies,
guidance, agreements, state equivalent
regulations, waivers to these instruments,
agency standards, regulatory economic impact
costs and benefits data, and schedules for
implementing these controlling instruments.
Cross Media Sources: Information concerning
the cross media sources with which the PWSS
Program will share data. Includes the types
of data that will be shared and the information
needed to exchange and interface with cross
media sources.
Inventories: Information concerning the
inventory of public water systems; Ownership,
staffing, water sources, consumer groups,
locational data (e.g., latitude, longitude,
Federal Information Processing Standard
[FIPS] county code, and FIPS state code),
permit number, and facility standard industrial
code.
-------
Legal Entities: Information describing the
legal entities within the PWSS Program
community. Includes government (e.g., EPA,
state, territory, city, town, Indian Tribe, or
municipality), public or private organization
(e.g., association, council, or company), or
individual citizen.
Programs and Plans: Information concerning
PWSS programs and supporting plans to
implement the approved programs. Includes
programs and plans mandated by legislation
(e.g., school water cooler program), along
with Federal, state, and local programs
developed in response to legislation or other
regulatory instruments (e.g, tap water
sampling program).
Public Water System Supervision: The global
subject area which identifies and describes all
of the information required by the PWSS
Program.
Samples: Information associated with the
monitoring of water quality. Included are
contaminants, sampling information,
monitoring requirements, sampling plans, and
public notifications.
Technologies: Information related to the
technologies required to treat water, assess
-water quality, or analyze data relating the
PWSS program implementation.
Business System Architecture
The Business System Architecture, shown on the
foldout following this page, was developed
through the following steps:
Identification of business systems to satisfy the
business needs represented in the Information
Architecture. ,A business system is a
collection of related business activities, such
as activities related to inventory.
Identification of data stores (collections of
related data) required to support the
Information Architecture.
Identification of information flows between the
business systems.
Development of business areas (collections of
related business systems and data stores).
Rank ordering the business areas to determine
priorities for scheduling. '
The eight business areas and their associated
business systems are listed in priority order
below.
1. INVENTORY - characterizing public water
systems, including plants and equipment,
human resources, and populations served.
2. FIELD SURVEILLANCE - certifying labs
and personnel. Also, conducting surveys and
inspections and taking samples.
3. COMPLIANCE - developing monitoring
plans, monitoring performance, building cases
against violators and noncompliers, taking
enforcement actions, and tracking enforcement
actions.
4. WATER RESOURCE PLANNING - charac-
terizing water resources. Also, providing
forecasts, promoting water conservation, and
allocation. Includes assessing risks to water
sources and human health.
SDC-OObo-O I z-1
-------
8
5. TECHNICAL ASSISTANCE - providing
assistance in the form of expertise,
technology, and training.
6. REGULATION - scanning scientific and
technological research. Using the research in
developing regulation, policy, and standards;
in planning and delegating primacy; and in
assessing regulatory and implementation
success.
7. DISEASE OUTBREAK - developing disease
outbreak information. Compiling the
information to be communicated to the public.
Identifying the proper means of
communication. Conducting the
communication and responding to requests for
information.
8. MANAGEMENT AND BUDGET -
coordinating activities and information with
other organizations, including the provision of
information-retrieval .capabilities and other
information systems development. Includes
financial assistance and permits and waivers.
Additionally, the following seventeen data
stores were identified:
AGENCY - includes Government Agency and
Non-Government Agency or Company entity
types.
AGREEMENT - includes Agreement entity
type.
CERTIFICATE - includes Lab Certificate,
Operator Certificate, and Permit entity types.
COMPLIANCE - includes Deviation, Sample,
Sample Analytical Result, Sample Assessment,
Violation, and Enforcement Action entity
types.
CROSS MEDIA - includes Environmental
Event, Weather Data, Water Habitat Quality
Information, and Water Threat entity types.
EVALUATION - includes Review Audit and
Evaluation and Complaint entity types.
FINANCIAL ASSISTANCE - includes
Budget, Grant, and Guaranteed Loan entity
types.
INVENTORY - includes Legal Entity, Public
Water System, Water System Facility,
Treatment Equipment, and Population Group
entity types.
OUTREACH - includes Communications
Media, Public Notification, Technical
Publication, and Information Request entity
types.
PLAN - includes Monitoring Plan, Cross
Media System, Contingency and Emergency
Plans, and Engineering Plan entity types.
PROGRAM - includes Program and Program
Plan entity types.
i
REQUIREMENT - includes Legal Mandate,
Regulation, Research Need, and Requirement
entity types.
RESEARCH RESULT - includes Research
Result and Contaminant entity types.
RESOURCE - includes Analytical Equipment,
Field Equipment, Individual, and Laboratory
entity types.
SDC-0055-012-TB-20O6A
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
10
RULE - includes Policy and Guidance and
Standard Techniques or Procedures entity
types.
SOURCE DATA - includes Drinking Water
Source, Hydrological Information, and
Hazardous Waste Information entity types.
- TECHNICAL ASSISTANCE - includes
Technical Assistance and Training Event
entity types. . s
Technical Architecture
The Technical Architecture defines the hardware
and software required to implement the
Information and Business Systems Architectures.
Hardware environment means the physical units,
such as computers and telecommunications
equipment, on which the system operates.
Software environment refers to the software
products employed, such as databases and
communications programs.
i
The Technical Architecture presents a general
framework for the system. It defines where
components would be located and how they would
interact. The Technical Architecture will be
refined during follow-on Business Area Analysis
(BAA) projects, when technical details and
specifications are added, including model numbers
and software product names.
Three major products result from completing
the Technical Architecture: the Statement of
Technical Requirement, the Technical
Architecture chart, and the Statement of Technical
Direction. The Statement of Technical ^
Requirement specifies needed system throughput,
availability, response, and security for each
proposed business system. The Technical
Architecture Diagram illustrates the basic
architectural options proposed for PWSS
development. The Statement of Technical
Direction describes long-term plans and
recommended alternative(s) for the PWSS system;
it also describes policy implications and proposed
changes that could affect the PWSS program.
The following four-step approach was usedjto
develop the products:
An organizational model was developed for
the system that shows each organization and
identifies the interfaces between organizational
units. For each organization, pertinent
business systems were identified and stored '
information was characterized.
Performance requirements used to evaluate
various Technical Architecture options were
identified. The "Statement of Technical
Requirement" was produced during this
analysis step.
General computer hardware and software
needs were identified for each organizational
level, as well as the communications needed to
connect the organizations.
Technical Architecture alternatives were
identified and described. Evaluation of the
alternatives was based on the appropriateness
of the architecture to the business operations
and information needs of each organization.
The alternatives were also evaluated against
the performance requirements to determine the
most suitable architectures) at each
organizational level of the PWSS. The
Statement of Technical Direction was
produced during this step.
SDC-0055-012-TB-2006A
-------
11
PWSS Users
Five generic types of organizational users were
identified. These users include:
Labs - the laboratories designated to analyze
water samples.
PWSs - each of the 205,000(+) Public Water
Systems which serve piped water to at least 25
people for at least 60 days each year.
State/State Regions - the drinking water
program Primacy Agencies located at the state
level. State regions are represented here
because certain states delegate primacy
authority to state regions, counties, or water
districts.
EPA/EPA Regions - the National EPA
authority with responsibility for administering
the Safe Drinking Water Act.
Public/Other Organizations - outside groups
or individuals which require access to PWSS
data.
Candidate Architectures
The following five candidate architectures were
identified:
Time-sharing - Time-sharing uses dumb
terminals connected to a central mini or
mainframe computer that manages all
databases, processes all applications, and
.handles all user interfaces.
Client/Server - The client/server approach
includes client workstations or PCs connected
to a central server or host computer.
Client/server software manages a tightly
coupled relationship between client processes
and server processes. Workstations typically
handle user interface. Applications may either
be retrieved from the server or reside on the
client. In either case, the application executes
on the workstation, while the server centrally
stores the databases and performs database-
management services.
Distributed Database - The distributed,
database approach utilizes one logical DBMS
operating across multiple physical computers,
generally at separate geographic locations.
Distributed database computers may be
connected with many intelligent workstations
that individually process applications and
handle user interface.
Cooperative Processing - The cooperative
processing approach provides for the exchange
of data between two or more computer
systems performing independently. Each
computer provides database-management
services to its user community and interacts
with other computers to exchange selected
information. Generally the processes running
on the various computers have knowledge of
one another and essentially "cooperate,"
exchanging information transparently to the
user.
Store-and-forward - Store-and-forward is a
two-tiered approach. While computer systems
may be physically connected, applications do
not directly intercommunicate and do not have
"knowledge" oif one another. Typically,
extracts of databases from a "local" computer
are performed, then physically or
electronically forwarded to a "remote"
computer. The database extract is then
imported into the database system residing on
the "remote" computer. Batch programs may
sbC-OOb5-012-lb-
-------
12
be written to facilitate extract, store, forward,
and import processes.
Mapping Candidate Architectures to PWSS
Technical Architecture
The PWSS Technical Architecture, shown on the.
following page, is a tailored integration of
architectural candidates applied at each
organizational level and between organizations.
The proposed architectural solutions for each
organizational level are described below.
PWS and LAB
At the PWS and lab levels, architectural
options are limited. Neither type of site is a
candidate for full PWSS-application
implementation, and the actual technical
architecture for these sites cannot be mandated
by PWSS. The architecture for these levels
consists of PCs or workstations running low-
end (less than full PWSS functionality)
application shells and commercial
communications software. This architecture
would enable the sites to interface with the
state/stale region level to do uploading of
required data, processing of change requests,
and read-only querying of information stored
at higher levels in the architecture.
Communication would be via dial-up access or
leased line for sites with appropriate
hardware.
More advanced communications options are
envisioned for the Labs to support connecuon
of PWSS to lab data systems tech arch using
EDI (Electronic Data Interchange). The Lab
PWSS component would receive and format
the data from the lab's data system, and
facilitate the forwarding of data on a periodic
basis to the Primacy Agency.
Primacy Agency (State/State Region)
The Primacy Agency architectural options are
more varied. Some states have complex and
fully functional PWSS systems already in
place that would need only interface access to
the national level PWSS. Other states have
virtually no existing systems. Still other states
have some hardware and software capability
that either would be replaced by the new
PWSS applications or would have to interface
with them.
States desiring to continue existing automated
systems may modify existing state software to
conform to the data and interface requirements
of PWSS; or implement a PC-based
communications cross-connect which would
maintain the interface between the state system
and the national PWSS. The PC-based
communications cross-connect has the least
impact on existing state software and
consequently offers the lowest risk approach.
Primacy Agencies with few PWSs, desiring
PWSS functionality could use one of the
following configurations:
PC connected to EPA's National Computer
Center (NCC) (via leased or dial-up line),
timesharing. The state database would be
established on the NCC environment and
would interact with the NCC PWSS
environment, as any other state. Public
access would be through the NCC PWSS
public access gateway. Lab and PWS
-------
PAGE NOT
AVAILABLE
DIGITALLY
-------
14
interface with the Primacy Agency would be
manual.
PC based PWSS, cooperative processing
with NCC. The PWSS applications and
state database would reside on the state
PC, interacting with the NCC on a
cooperative basis. Public access, including
Labs and PWSs could be through the state
PC.
States with large number of PWSs, desiring
PWSS functionality could use the following
configuration:
Server-based PWSS. PWSS potentially
would include application,
communications, and database servers.
Terminals connected to the server would
operate in a Client/Server Architecture.
The state PWSS would operate in a
cooperative architecture with EPA.
Connection would be established through
the communications server using leased
lines. Public access, PWS, and lab access
would be managed through the state based
communications server. Depending on the
size of the. database and numbers of users,
the functions of the database server,
application server, and communications
server may be performed by processors
. ranging from PCs to mini computers.
State regions would interconnect with this
mature system using any of "the
architecture options previously outlined,
depending on their work load and data
requirements.
X
EPA Region
Two architectures are recommended for EPA
regions: timesharing by connection with the
NCC, or client/server on a regional LAN.
Timesharing will support the majority of
regional functions. Client/server would be
most appropriate for an EPA region with
primacy, or for downloading selected data
from NCC for regional analysis. Public
access is not envisioned at the regional level.
EPA Headquarters/NCC
EPA Headquarters would be supported using
the same approaches developed for the EPA
regions. Public access would be accomplished
by dial-in to NCC.
Public/Other Organizations
Other EPA and non-EPA organizations and
the general public have an interest in the data
potentially held in the PWSS information
system. The technical architecture will have
to include mechanisms by which these groups
can access the data they may need. This
access will be provided by the use of
terminals external to the PWSS system query
application shell. These external PCs,
terminals or workstations will use the dial-up
or leased line communications facilities to use
the PWSS application on a limited, read-only
basis.
STATEMENT OF TECHNICAL
REQUIREMENT
The Statement of Technical Requirement consists
of an assessment of each of the business systems
to determine the kind of technical support needed
throughout the PWSS program. Performance
requirements for all levels of PWSS have been
established for four criteria. A list of these
criteria along with a broad description is as
follows:
3UC-O055-0 12-TB-2O06A
-------
15
Throughput requirements vary widely across
business systems. The largest flow of data
will be from PWSs and Labs to Primacy
Agencies at the state level. Some states
receive hundreds, even thousands, of sample-
analytical results per day. The timeliness of
submissions is based on the monitoring
schedules of the PWSs and the reporting
requirements of the Labs. PWSs and Labs
must comply with state and Federal policies
and have reporting requirements for given
contaminants.
Response requirements also cover a wide
range. Sub-second response times are
required for online transaction processing at
the Primacy Agency level. Less stringent
response is required for query and summary
functions at all levels of the PWSS structure.
To reduce network traffic and response-time
degradation, the application software must be
able to identify potentially time-consuming
queries and warn users before the queries are
executed.
Availability: The PWSS system will be
available at all levels for online access and
transaction processing during normal working
hours with portions of nonworking hours
reserved for system maintenance, batch
processing, backup and recovery, and
upgrading of system hardware and software.
Security: The PWSS system will process
sensitive data as defined by OMB Circular A-
130, and will require incorporation of security
safeguards to preclude unauthorized access or
modification, or inadvertent loss of PWSS
data. Determining who has access to the
system at each level and across the levels will
be established according to policy based on
agreements between Primacy Agencies and the
national EPA. Public assess is assumed to be
read only.
STATEMENT OF TECHNICAL DIRECTION
The Statement of Technical Direction focuses on
three architectural options that are designed to
support the spectrum of existing capabilities of the
PWSS user groups. These options include:
Option One: The basic low-end architecture is
a national system residing on a time-sharing
mainframe at the NCC; the system would
have direct connections with regional offices
nationwide through the EPA backbone, and
direct connection to stand-alone PWSS
applications running at the Primacy Agency
level. This option focuses on Primacy
Agencies with little or no automated
capability.
Option Two: The high-end solution consists of
tailored PWSS application systems functioning
at each Primacy Agency; the systems would
communicate interactively with PWSs, Labs,
and national level EPA. The architecture
would be a combination of client/server and
cooperative processing architectures, whereby
Primacy Agencies maintain control over their
own data while allowing querying and
extraction of selected information.
Option Three: The phased solution is a
marriage of the two previous solutions. While
PWSS application systems would be provided
to states having limited (or no) automated
capability, states having fully functional
systems would initially attach to the PWSS
system through PWSS interface systems over
leased-line or dial-up connections. Portions of
the PWSS system would gradually be phased
into these existing systems, the desired end
§OC-OObb-012-TB-2006A
-------
16
being full replacement of the existing system
by PWSS over time.
While all three architectural alternatives are
possible over time, Option 3 presents the most
logical solution for meeting the needs of EPA and
the Primacy Agencies. The phased solution
provides for:
Nonautomated Primacy Agencies being
brought up first with basic functionality.
Primacy Agencies maintaining their own data
and cooperatively sharing data with EPA.
1 PWSS developed interface systems
interconnected to existing full-function
Primacy Agency systems to transfer selected
data to EPA.
1 Flexible communication network options using
existing leased-line and dial-up capabilities and
supporting non-electrical transfer of magnetic
media where appropriate.
Phased implementation allowing all Primacy
Agencies to evaluate the new PWSS
applications and encouraging state "buy-in."
Providing the best use of existing hardware
and software.
PWSS ISM Project Strategy
The Information Strategy provides the blueprint
for implementing the PWSS ISM Project. The
information strategy for the PWSS ISM Project is
based on the following four principles:
Initial development for states with limited
automation capabilities.
Interface with mature state1 systems
Modular development and phased
implementation of system components
Early development and refinement of a
standard user interface.
The information strategy focuses on states
having comparatively little automated capability
by targeting these states as the initial users of the
system. When feasible, the PWSS ISM Project
will interface with existing state systems, allowing
the existing systems to be gradually phased into
the PWSS architecture. Modular development
and phased implementation of PWSS components
will provide for early fielding of critical
capabilities, with phased growth toward the
objective architectures. Systems will be rule
based, allowing tailoring for specific state needs.
The PWSS Information Strategy also includes
a phased implementation plan. The plan was
based on the business area priorities and on the
category of the business systems within each
business area, providing essential capabilities for
primacy implementation and management of the
state and Federal drinking water programs.
The initial system, an inventory management
system, features a "user friendly" Personal
Computer (PC) interface for users (located in
state and Federal offices) connected to EPA's
National Computer Center (NCC) IBM mainframe
system. Subsequent versions of the system would
be decentralized and distributed to states as
required. The inventory management system
would be built using Rapid Application
Development (RAD) techniques and be available
for Pilot testing in July-September 1993. Follow-
on projects would include Field Surveillance,
Compliance, and Primacy Implementation
Systems.
SDC-0055-012-TB-2006A
------- |