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 ------- |