I received an early Christmas present on December 8 via email in the form of the E-Enterprise Bulletin (Vol. 1, No. 13). This issue’s Featured Project section included an article about the SDWIS (Safe Drinking Water Information System) modernization effort. Any news of SDWIS modernization is a treat for me since information about the project is hard to come by.
While the article includes a link for registering for the monthly “All Things SDWIS” call, I doubt that Jane or John Public would be welcome on it. The drinking water program is like a big mostly functional family and the monthly calls were like a holiday family dinner – and you know how those can go. But it would be nice for the SDWIS Communications Work Group (if it still exists) to consider developing a communications channel for disseminating information to the public. It could come in useful, especially later when the modernized SDWIS system is up and running. What really caught my interest, however, were these two items:
- SDWIS ESC (Executive Steering Committee) approved the project plan for SDWIS modernization design and development, and;
- The EPA SDWIS Modernization Team and its technical support contractor started designing the new system.
I find this interesting because it appears that from the information available to the public (and there isn’t a whole lot) , EPA is doing the same things it did before on earlier, unsuccessful iterations of SDWIS modernization. Chief among them is maintaining a governance structure that places decision making responsibilities on individuals who are not directly involved in SDWIS. Furthermore, it seems as if EPA is limiting modernization to SDWIS State and its “data flow components” while ignoring other assets that should be part of a new and modernized SDWIS. (My article Some Inconvenient Truths About SDWIS describes SDWIS and other assets and how they fit together and depend upon each other.)
Concerns With Stakeholder Governance
Recently, EPA reconfigured the SDWIS stakeholder governance structure by replacing the earlier SDWIS Advisory Board (which superseded the earlier SDWIS Steering Committee) with the SDWIS Modernization Board. A draft Phase II Charter for the SDWIS Modernization Board (found here) describes the “structure, operating assumptions, and decision processes throughout the second phase of the modernization process.”
As described in the Phase II Charter, Phase I consisted of technical analysis, retrospective (presumably lessons learned from earlier modernization attempts), and alternatives analysis. In mid-2020, EPA completed the alternatives analysis (available here from ASDWA’s web site) and, along with it, phase I. I’ll cover the findings of the alternatives analysis later in this article, but first I’ll discuss why the Executive Steering Committee, in its current configuration, may not be the optimal approach for stakeholder governance.
The Office of Water (OW), the parent organization of SDWIS, is a stove-piped organization, reflecting the way the water programs are organized at EPA. In EPA lingo, OW is called an “AA-Ship” because it’s headed up by a politically appointed AA (Assistant Administrator). One of the interesting things about EPA is the sheer number of political appointees. This is by design and serves to allow whatever political party is in power to either impede or facilitate the agency’s work. If we wanted real progress on protecting human health and the environment, the first place to look is to eliminate a bunch of political positions. But that’s my opinion a subject for a different article that somebody else can write.
In addition to the AA, the OW AA-ship includes a Principal Deputy Assistant Administrator (PDAA) and a Deputy Assistant Administrator (DAA). Like the AA, the DAA is a political appointee. (Why it’s necessary to have two political appointees is beyond me. Perhaps a better investment for the taxpayer would be to hire a couple of mid-level scientists and engineers instead of paying for another political appointee.) Anyway, unlike the DAA, the PDAA is a career Civil Service Senior Executive. It’s usually the PDAA who runs OW when an AA hasn’t been confirmed by the Senate. PDAAs have the deep institutional and technical knowledge to run the OW show that most political appointees don’t possess.
EPA also uses the term “AA-Ship” because most AA level “Offices” contain two or more “sub-offices.” For example, the OW AA-Ship contains four “sub-offices:” the Office of Ground Water and Drinking Water (OGWDW, where SDWIS “lives”), the Office of Science and Technology (OST), the Office of Wastewater Management (OWM), and the Office of Wetlands, Oceans and Watersheds (OWOW, my favorite acronym).
You can think of these offices this way: OWOW handles ambient water (water as it exists in the environment), OGWDW handles water that is taken from the environment and that people drink, and OWM handles waste in water (generated by people and by industry). OST provides scientific and engineering support for the other three offices and is usually the place where regulations begin.
So far, I’ve described offices at EPA headquarters in Washington DC. There are also ten EPA regional offices scattered around the country. Each EPA Region has a Water Division that works closely with the states, territories and tribes within its boundaries with enforcing the various regulations involving the ambient, waste, and drinking water programs. That’s a broad portfolio of activities OW and the EPA regions are involved with as far as water is concerned. Which brings me to this question: why would the DPAA for Water (and the EPA CIO, for that matter) want to get involved in a project like SDWIS Modernization?
These individuals are very senior executives and they usually operate at a strategic, or 50,000 foot level. Making decisions like approving plans and scope changes for a project like SDWIS Modernization affecting OGWDW and the Office of Compliance and Enforcement Assurance (OECA, which isn’t referenced in the Phase II charter at all) seems like a big ask of them. Earlier iterations of SDWIS Modernization had similar issues with finding a SDWIS program/project sponsor at tactical level in the OW organization. A senior executive at the OGWDW or, perhaps more fittingly, at the DWPD (Drinking Water Protection Division within OGWD) level would be more appropriate, in my opinion as the sponsor.
In closing this topic, I’ll add that the earlier iterations of the SDWIS Modernization and CMDP development projects didn’t have a DWPD or OGWDW executive filling the role as a project sponsor. Instead, it was almost as if executives were playing “hot potato” with the sponsor role. Maybe the retrospective completed during Phase I recognized the lack of an executive acting as a strong project sponsor. If it did, judging from the makeup of the Executive Steering Committee as it currently exists, it appears OW chose to ignore this lesson from its earlier work on SDWIS Modernization.
In any case, the culture of the drinking water program is not conducive to a strong sponsor SDWIS sponsor. Most of the work of the program is done by the states (they have delegated primary enforcement responsibility, hence the term “primacy”) and the states use this as leverage with EPA. Despite the fact that the majority of EPA appropriated funds for drinking water go to the states as various grants, the EPA’s control over the program isn’t that strong. And that, in my opinion, is a barrier to building a truly effective system consistent with the drinking water regulations and their intent.
SDWIS Modernization Alternatives Analysis
Perhaps the single most important product of the Phase I effort was the alternatives analysis. Note that this analysis is not a complete business case (see my article How to Build a Business Case), but a comparison between three deployment alternatives and two acquisition strategies (custom development and commercial off the shelf acquisition). These alternatives are:
EPA hosted – Like SDWIS Prime and SDWIS NextGen before, in this alternative the user interface, decision support system and database are hosted in an EPA-managed “cloud.” This is the same deployment model the earlier SDWIS NextGen/Prime projects used. EPA would use a low-code development toolset to build this system. These tools would, presumably, be more refined and flexible than the low-code development tools used for the first iteration of SDWIS NextGen development. Note that I call this alternative “EPA Hosted” since EPA would be paying for the hosting environment of this system. Page 12 of the Alternatives Analysis slide deck explicitly states, “Options involving EPA hosting at the EPA’s National Computer Center (NCC) were eliminated.” Apparently this alternative will reside in some other “cloud” hosting environment meeting federal government information security standards – it just can’t be the NCC. Not stipulated is who pays for this environment.
Hybrid – This is the same as the EPA hosted alternative above. The only difference is that states could still use their own systems and “interface” them, using an application programming interface, to the hosted system. This will be the most likely scenario as the states transition to the modernized SDWIS system and beyond as some states will continue using their “home grown” compliance systems and interfacing applications. Like the EPA Hosted alternative, the Hybrid alternative will have components running in a hosted cloud environment – but one that doesn’t involve the NCC.
State Hosted – This alternative follows the legacy SDWIS State approach where EPA develops the new SDWIS software, using low-code development tools, and the states install and run it in a state-managed environment. This is the model in use today, but without the low-code tools. Because each state SDWIS hosting environment is different, this causes a bit of a technical support headache for EPA. States usually don’t reimburse EPA for end user and technical support, though there are exceptions. Presumably this practice would continue with this alternative.
Modified SDWIS Prime – This alternative would take the existing and incomplete SDWIS Prime system, correct the deficiencies found in its underlying database design (presumably so the database looks and operates like the legacy SDWIS State database), and complete the system. Not mentioned is if EPA would continue using the obsolete Angular JS technology or move on to Angular (this move is not trivial). This system existed at one time in the EPA NCC environment and would have been an EPA-hosted solution. Later, on slide 38 the Alternatives Analysis notes that GDIT (the company that wrote-up the analysis), “recommends a document database,” which necessitates a change in backend database. Personally, I don’t think a document database is a requirement. Certainly having a relational database supporting, say, XML or JSON data types, would be hugely advantageous for a system like SDWIS.
Commercial off the Shelf (COTS) – For this alternative, EPA would acquire a commercially available solution. The analysis compares two products, one of which the US Geological Survey currently uses. The analysis doesn’t say if this alternative is a shared hosted solution, if it is installed at the states, or who pays for ongoing licenses. Based on my experience with SDWIS, states were not interested in paying licensing fees for SDWIS or its replacement. I’m sure that view hasn’t changed since I retired from EPA.
To Centralize or Not to Centralize ?
Of the five alternatives discussed above, only the State hosted alternative doesn’t involve a centralized SDWIS State-like component. When I presented the SDWIS business case at the 2009 ASDWA Data Management Users Conference (DMUC), the preferred alternative, full SDWIS State replacement, didn’t officially involve consolidating the 54 instances of legacy SDWIS State into a single, multi-tenant, centralized system and database. However, myself and the contractor responsible for writing that business case implied that it would be a centralized system during our presentation.
The business case presentation raised many questions and concerns from the primacy agencies and EPA Regional personnel in attendance. One question from a state representative that stuck in my mind that came was why the business case did not analyze the cost and benefits of replacing SDWIS State from a primacy agency’s perspective. I’m sure people didn’t like our answer, but as federal dollars would pay for the replacement system, we had to limit the economic impact to EPA.
As OGWDW would learn later, many states had a vague idea of how much their current systems (including SDWIS State) cost to operate and maintain. OGWDW repeatedly asked states to provide these data to no avail. Without this cost data, it is very difficult to develop cost/benefit comparisons with an adequate level of precision for a state. Multiply that by the total number of states, territories, and tribes having delegated primary enforcement responsibility (PES holders – 55), and the effort becomes daunting.
The alternative that became SDWIS NextGen/Prime called for a single database shared by all PES holders and EPA Regions. This database would use a design that optimized transaction processing speed and employed a security scheme allowing each PES holder and EPA Region to manage access to its data in the common database. In addition to the shared database, there would be a single application “stack” shared by all.
While it might have helped to produce a document clearly laying out the pros and cons of a centralized system, we never did. On the other hand, that document might have served as a catalyst for resistance to the centralized system approach. Below, I describe the pros and cons of moving to a centralized, multi-tenant SDWIS State replacement.
From OGWDW’s perspective of making the monetary outlays to pay for the new system, there were many upsides to a centralized, shared system like SDWIS Prime. Here are a few of them:
It reduces OGWDW’s total cost of ownership – OGWDW saves because there is one instance of the centralized system rather than the potential 66 instances (PES holders and EPA Regions). This ensures everyone is using the latest version of the software in the same hosting environment, simplifying user and technical support.
It makes it easier to share data between the states – Many water systems are interconnected across state lines. As one state usually doesn’t have access to another state’s compliance system, they cannot log into the other state’s compliance system to view information about the interconnected water system. With a shared database, a primacy agency could allow users from bordering states (and the EPA Regions during emergencies) access to its data.
It makes it easier to share data with EPA – Currently, the quarterly reporting to EPA process all states must go through involves a number of time consuming steps such as “consolidating violations” (which made more sense when data uploads were over 9600 BAUD acoustic modems), and managing and submitting data files for uploading to EPA’s Central Data Exchange. By moving to a centralized system, reporting data could be extracted automatically and loaded into the Drinking Water Data Warehouse with little human intervention.
It makes it easier for EPA Regions to work with states on federal enforcement actions – With SDWIS State, Regional enforcement personnel don’t have access to the state system, so they manage federal actions in SDWIS Fed. To see the federal actions, states have to download a Quality Assurance (QA) extract of their database from SDWIS Fed and then add the federal actions into their instance of SDWIS State. With a shared database, primacy agencies can grant access to Regional enforcement personnel who can then enter and maintain federal actions where the primacy agency can view it. This eliminates the need for the QA extract and issues with trying to manually maintaining federal actions in the primacy agency database.
It eliminates double entry of federal enforcement actions into ICIS – EPA Regional enforcement personnel enter and maintain federal actions using SDWIS Fed. They also have to maintain the same federal action data in the Office of Enforcement and Compliance’s (OECA) Integrated Compliance Information System (ICIS). This double data entry could be eliminated by implementing a synchronization service between SDWIS Prime and ICIS. Operations done on federal actions (add/update/delete) in SDWIS Prime would automatically propagate to ICIS, and vice versa.
It gives resource constrained state program options – Many states have lost their in-house and contractor IT support resources because of budget cuts and reorganizations. A centralized system reduces (and could eliminate) the need for these resources.
Other benefits – Looking further out into the future, there are additional benefits EPA, primacy agencies, water systems, and the public could accrue from a centralized system. Here’s a few examples:
- Using data analytics to evaluate the effectiveness of drinking water regulations. This could provide a feedback loop for improving the regulations.
- Using predictive analytics, artificial intelligence and machine learning on the SDWIS parametric data to identify potential problems with a water system. Regulators could take proactive measures and avoid violations based on recommendations from these analyses.
- Improving EPA Regional oversight abilities by making SDWIS Prime “auditable”. The system would record who did what, when they did it and why the did it. Currently, OW has a very limited and narrow view into the delegated programs and OW’s budget doesn’t support a more robust data verification program. Using the audit features of a centralized SDWIS Prime gives the EPA Regions the ability to do data verifications on demand and remotely.
- Similarly, primacy agencies using a centralized SDWIS Prime can leverage the audit features to monitor the efficiency of their operations and identify bottlenecks. Primacy agencies could use this information to justify budget increases for their drinking water programs.
From a delegated program perspective, there are several “downsides” to the SDWIS Prime:
Loss of control – Primacy agencies would lose complete control of their databases. They would have to work through whomever managed the central database to complete certain tasks, such as mass data migrations and corrections and, possibly, creating and downloading large datasets. However, as I mentioned before, many primacy agencies are experiencing IT support personnel cut-backs. For them, a centralized compliance system could work to their advantage.
No system response time guarantee – There is no guarantee of system response time. As all system capabilities are delivered through the user’s web browser, response time depends on the speed of the user’s connection between their browser and the centralized “back end” SDWIS Prime servers. Performance could be affected by traffic on the Internet that is out of the hosting provider’s control. For example, a worker watching a network bandwidth hungry training video could degrade system response time for everyone on the same network segment in that primacy agency’s office.
Freedom of Information Act (FOIA) Concerns – If EPA hosted the new system, data could be subject to Freedom of Information Act (FOIA) requests. For example, an individual could submit a FOIA request to OGWDW for state A’s data. OGWDW could refuse the request saying the data is “pre-decisional” (which is partly true). However, according to the EPA’s Office of General Council (OGC), if the requestor sued EPA for the data, it was likely that OGC would advise avoiding the suit and granting the FOIA request.
Interfacing Applications – Many states developed applications and reports bypassing the SDWIS State application layer and connect directly to the SDWIS State database using Open Database Connectivity (ODBC) calls. Interfacing applications support business processes like processing and tracking operator certification, tracking engineering plan reviews, billing and permitting, agency specific reports, and other business needs not supported by SDWIS State.
These states and EPA Regions also acquired interfacing applications replacing portions of the SDWIS State user experience. For example, at least one primacy agency developed a samples entry module because the existing SDWIS State user experience for samples management was inefficient and cumbersome.
This issue with exchanging data over the internet for interfacing applications drove the SDWIS team to come up with a solution replacing the ODBC calls with ReST API (Representation State Transfer Application Programming Interface) calls. The downside of using ReST is that primacy agencies will have to modify their interfacing applications by replacing the OBDC calls with calls to the ReST API. This places additional burden on the primacy agencies, especially those without ready access to IT resources to updated these programs.
The alternatives analysis included a qualitative comparison between the alternatives using ranked scores. The table below shows the qualitative scoring comparison of the alternatives:
This scoring is based on a review of 37 summary requirements (though it’s not clear in the slide deck if the original 42 requirements were included in the table, which it appears it does). Stakeholders evaluated each requirement and assigned a score of 1,2,3 or 4 (from least to most important), thus giving an estimation of their relative priority. However, we don’t know what these requirements are as they are not included in the slide deck.
Each alternative was evaluated against every requirement and assigned points based on the level of effort needed to make the alternative meet the requirement. If an alternative fully met the requirement “out of the box” with minimal configuration, 3 points were assigned. Two points were assigned if moderate effort is needed to meet the requirement whereas one point if the effort is high. If the alternative did not meet the requirement, then no points were assigned.
This approach works well, and I’ve used it many times in when evaluating competing software systems, when the systems under evaluation are operational. It becomes problematic when comparing a concept for a custom-built system with off the shelf (commercial or otherwise) systems. I’ll get into this a little later.
Multiplying the priority score by the level of effort score for each requirement/alternative combination and summing them by alternative resulted in the weighted scores shown in the Qualitative Score Comparison table shown above. For example, consider a requirement with a priority score of 4 (the most important, highest priority). Let’s say the alternative being evaluated partially met the requirement with a moderate level of configuration (2 points). The weighted score for this requirement is 4 X 2 = 8 points. As described in the slide deck, the maximum score achievable by an alternative is 381 points (based on 42 requirements). These calculations are what we see in the Qualitative Score Comparison table above.
Not defined or discussed in the alternatives slide deck is the definition of “out of the box” and “configuration.” Traditionally, “out of the box” means using existing capabilities and “configuration” means altering the appearance or a function of the system without having to directly alter its source code. In other words, using configuration settings to alter system behavior and appearance.
This begs the question, how can the EPA hosted alternative achieve a score of 234 if the system doesn’t yet exist? By definition, a nonexistent system can’t meet any requirement out of the box. Following this logic, the EPA Hosted, Hybrid, and State Hosted options should have scored zero points total. Instead, we see the SDWIS Prime and COTS alternatives, all scoring lower than the three conceptual alternatives. It appears that the analysis is relying on the supposition that using a low code development toolset will mitigate the software development risk to the point where it’s a matter of configuration settings instead of coding. That might be true, but has EPA produced a proof of concept using some of the more complex SDWIS requirements to validate this assumption?
Without a proof of concept, EPA is taking a big risk in assuming a low code tool will reduce development time to 15 months (at most, as stated in the analysis). Almost ten years ago, EPA required the then development contractor to use a low code development environment. After six months of work, EPA had do abandon development because the tool could not accommodate the user access control requirements. And this was before EPA had developed a design for a “task scheduling backbone” the enforcement case is based upon. I suggest that EPA first create a proof of concept showing that the selected low code development toolset is capable of supporting the user access control requirements, the scheduling “backbone,” and integration with the Central Data Exchange (CDX) and Shared CROMERR Services (SCS) before committing to this solution.
Another question is who is how much confidence should one give to the estimates for making an alternative meet a requirement? Was it the Modernization Board members or did technical specialist who could evaluate the existing alternatives and make an educated guess of the level of effort? In addition, this analysis could lead to anomalous results. For example, it’s going to take more effort to convert the back-end database for the existing SDWIS Prime system and make all the changes cascading from that then it is to design a new database backend for a new, “clean sheet” system. As for the off the shelf products, unless the people doing the evaluation are intimately familiar with those products, the effort estimates are speculation.
To this last point, let’s take a look at the modified SDWIS Prime score of 202 points. Considering the analysis recommends the EPA Hosted alternative and that it involves custom software development, I would be concerned that, after six years of custom development work on SDWIS Prime, the resulting system only yielded an overall score of 202. Perhaps features that were not yet programmed counted against the SDWIS Prime score? Or did the database design issues, which contributed to halting the third iteration of SDWIS Prime development, factor into the scoring (despite the fact the analysis recommends using a radically different backend database, so the design will change anyway)? Looking at it a different way, has the project culture changed in a way that a development effort for a system as complex as SDWIS Modernization is now feasible?
The Alternatives Analysis included a three year notional cost estimate covering nine month, one year, and fifteen month time to develop scenarios. The table below shows these costs:
I won’t spend much time on these costs except to say that there’s little, if any, material difference between the EPA hosted, hybrid, and modified SDWIS Prime alternatives. I don’t know enough about low or no code development or the state of the detailed functional requirements of the system to know if developing the system is possible within a fifteen month (much less a nine month) window. I do think it might be possible if the goal is to merely replace SDWIS State, but, as I stated in my article Building Tomorrow’s System to Meet Yesterday’s Problems, there is much more to modernizing SDWIS than just modernizing SDWIS State and it’s data flow components.
Another issue driving the cost of SDWIS modernization concerns the scope of the system. Has EPA and the states come to an agreement on what features/functions will be delivered in the first operational version of the system? This was always an area of contention during the first three iterations of past development attempts. Hopefully, in the almost four years since I retired, EPA and the states have a firm agreement on this and it is something less nebulous than “equivalent functionality to the latest version of SDWIS State.”
More importantly, has the culture changed (within OW and the stakeholder community) in such a way to facilitate project success? From the information provided about the Executive Steering Committee and the Modernization Board (which, admittedly, isn’t a lot), I doubt the culture has changed much. You still can’t point to a single executive at EPA acting in the role of sponsor who is responsible for SDWIS Modernization.
In this section, I describe several alternatives approaches to obtaining a modernized SDWIS.
Legacy SDWIS State “Overhaul”
This alternative is roughly equivalent to the hybrid approach. For this alternative, OW would upgrade the legacy SDWIS State system by modernizing its archaic user experience and converting it into a single web page application using the latest version of CA Gen. This would make SDWIS State behave more like a desktop application while eliminating the constant page loading, a hallmark of the legacy system’s user experience.
Included in this alternative would be a review of the business processes and the data supporting them with an eye towards “rationalizing” the design. For example, EPA economized on the later versions of SDWIS State by avoiding, to the extent possible, custom coding and database design changes. Effects of this economizing included:
- Leveraging of user defined fields (measures, flow rates and indicators) instead of adding new fields to the SDWIS State database.
- Creating new modules (as new apps) instead of modifying the core SDWIS State application. For example, the Groundwater bridge had a more modern user experience using Adobe AIR.
- Implementing requirements as “work arounds” using existing and less efficient features.
- Never completing some features (such as monitoring and sampling schedules).
The overhaul would eliminate these side effects through database redesign and business process/workflow revisions. In addition, the legacy SDWIS State Compliance Determination System (CDS) component would be replaced with the Business Rules Engine (BRE) used in the SDWIS Prime project. The BRE would separate the application logic of the system and the business logic used to calculate compliance with the drinking water rules. This would make the system more flexible and easier to update for new drinking water rules.
OGWDW’s Infrastructure Branch (IB) discussed this alternative with the incumbent SDWIS contractor shortly after the Project Management Office (PMO) released the summer 2009 version of the business case. A rough order magnitude estimate for this work came it at $4M and one year to complete. The estimate did not include replacing CDS with the BRE, but much of this work was completed under the SDWIS NextGen/Prime projects. The ability to integrate the BRE with CA Gen would have to be evaluated before going down this path.
Open Source SDWIS
For this alternative, OW would create a new grant for managing an open source software project to develop SDWIS Prime. EPA would fund (for less than it is spending on SDWIS Prime development contracts), solicit and make an award to a university. The winner would be responsible for creating and maintaining a team to manage and lead SDWIS Prime development. Primacy agencies could also pitch-in funding and developer resources (along with the rest of the world) to help build the system.
There could be some real possibilities with this alternative, including building open source software that water suppliers could use to help them with their compliance programs. This approach was proposed to OGWDW not long after I started at EPA, but it was met with a lot of skepticism. Years later, OGWDW would “pitch” the idea to the Association of State Drinking Water Administrators (ASDWA) as a possible expansion of their grant, but ASDWA wasn’t interested.
SDWIS Prime as a Service
As with COTS Replacement, his alternative depends upon OGWDW and the PMO developing a well documented set of requirements. The next step would be, like the COTS option, to develop a request for proposal (RFP) with the detailed requirements attached as an addendum.
Under the terms of the contract award, the winning bidder would provide access to their SDWIS Prime-like system on a subscription basis. It would be up to the winning contractor to build/buy a solution, but whatever it was, it would have to meet the requirements attached in the RFP (through a validation/verification exercise). Failure to meet the requirements would incur a penalty or loss of contract.
This option would take OGWDW and the PMO out of the SDWIS software development business. OGWDW would also have to decide what to do with SDWIS Fed. It can continue with SDWIS Fed running at EPA (with changes for parametric data) or turn SDWIS Fed over to the software vendor.
SDWIS as a Condition of Primacy
This is the most radical alternative and the least likely to be implemented but here it goes:
OGWDW would decommission SDWIS State, taking the system out of service completely. Instead of developing a replacement system, OGWDW would specify the compliance monitoring data, perhaps as a new regulation, that primacy agencies would be required to report to EPA on demand (instead of quarterly). Primacy agencies would be given a deadline to implement the on demand data reporting requirements.
OGWDW would continue maintaining SDWIS Fed and the process used by primacy agencies and EPA regions for reporting data to EPA. OGWDW would also decommission the Compliance Monitoring Data Portal (CMDP), but give primacy agencies and EPA Regions sufficient time to move to a different solution or take over running it.
In this scenario, it would be up to the primacy agencies to develop the replacement system and certify that it meets EPA stipulated requirements. States could use a portion of their technical assistance grants from EPA to partially fund development, perhaps using the open source approach described earlier to reduce development costs. This option takes EPA out of the SDWIS State software development and maintenance “business” and shifts the responsibility of finding a replacement system over to the states.
A big gap with this alternative is how to handle the EPA Regions and their direct implementation program. Regions could join in with the primacy agencies to acquire a common solution or band together and develop and in-house system capable of supporting the smaller regional drinking water programs.
As you can see by this brief write-up about the SDWIS Modernization Alternative Analysis, there’s a lot of moving pieces to consider. My opinion, however, is that all this work is premature without first figuring out exactly how SDWIS will be paid for. During the time I worked at EPA, the Drinking Water Protection Division (DWPD), which was responsible for SDWIS, was constantly moving funds from other efforts within the Division to fund SDWIS. At one point, OGWDW (DWPD’s “parent” office) asked the states about contributing funds through their technical assistant grants and other grants help fund SDWIS modernization. But the states have their own budget issues, and that was a non-starter.
Recently, we’ve seen several bills pass Congress for upgrading the nation’s drinking water infrastructure. We definitely need that. But we also need to upgrade the data systems used to ensure that the water suppliers are in compliance with the drinking water regulations. The data model currently in use dates from the 1980s and some of the practices in use today (such as quarterly reporting of drinking water data) were designed during a time when 9600 baud acoustic modems were in use. With today’s high-speed internet, there’s no good reason why the drinking water program should have to continue limiting data exchanges based on 40 year old constraints.
Replacing the legacy SDWIS System with something new is going to take a lot of time. And the monetary commitments don’t end at initial operational capability. New drinking water rules are going to come along. Hosting environments are going to change and software is going to require adaptive maintenance. This leads me to the conclusion that what the drinking water program needs is a reliable source of funding for building and maintaining a modern SDWIS into the future. Sort of like an “automation fund” for drinking water.
Beyond the financial issue is the way EPA and its regulatory partners govern SDWIS. EPA foots the bill for developing and maintaining SDWIS while providing the software to its regulatory partners free of charge (though they are responsible for the cost of running the software). This creates a situation where EPA acts as a vendor providing free software to its customers to assist them in making their work (regulating water suppliers) more efficient.
At the same time, EPA is responsible for overseeing the work of these customers to ensure their work is consistent with the drinking water regulations. It’s kind of like EPA’s left hand is trying to respond to its customers needs to build software the customer wants to use while the right hand is watching what the customer does and correcting them when their actions are inconsistent with the regulations. It makes an already difficult balancing act even more difficult. Does EPA build a “strict” system that enhances its ability to oversee the drinking water program at the risk of the states refusing to use the software? Or does it build a more “lenient” system with “leaner” workflows supporting state business practices that are inconsistent with the drinking water regulations?
These are all big questions that should have been answered years ago, especially before embarking on a journey to modernize a data system supporting a program as complex as drinking water. My concern is that EPA and its regulatory partners are, once again, plowing the same furrow.