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

-------