How Jargon Can Affect System Design

In this article I discuss how over-reliance on jargon can lead to problematic design decisions. As an example, I’ll use the U.S. Environmental Protection Agency’s (EPA) Safe Drinking Water Information System (SDWIS) modernization project.

Problems with Jargon

A jargon is a set of words and expressions used by a group of people (a community) that’s often beyond the comprehension of individuals outside of that community. Remember when you started a new position and you had to “learn the ropes”? One of those “ropes” is gaining an understanding of the jargon – the vocabulary – of the community you just joined.

In my career as a federal government employee, I’ve worked in four different civilian agencies. As a contractor before that, I worked with two branches of the military, a bank regulator, and fifth civilian federal agency. Each agency had its own vocabulary. I wish I had a dollar for every instance of the same acronym used by different agencies having different meanings. I was fortunate that some agencies I worked with maintained glossaries, sort of dictionary, defining the agency specific acronyms and, on rare occasion, terms used in the workplace.

One of the first tasks of the business analysts on a system development project is to understand the jargon of the stakeholder community. This task is made easier if there’s a glossary of standard terms and acronyms defining the jargon. If a glossary isn’t available, then the business analyst should begin writing one and vetting it with the stakeholders to ensure it’s correct.

Documenting the “community jargon” is more difficult when the community consists of many independent organizations each with their own jargon. Terms and expressions used by one organization could have different meanings to another. Normalizing the jargon across organizations can become quite a task. If the community has been around for several stakeholder generations, then the meanings of some terms may have become ossified with the passage of time. Sort of “it means this because it’s always meant this since before the time I started 20 years ago.” This is another challenge for the business analyst – overcoming resistance to change.

Another challenge for business analysts and application architects is recognizing when not to use jargon as a basis for design. Sometimes a well used term doesn’t accurately reflect how the business works. This could lead to design decisions with downstream consequences such as late database and application redesign, degraded system robustness, and costly workarounds that affect usability and add to operations and maintenance costs.

Like many things in life, things don’t always appear as they seem. Sometimes, over relying on jargon can bias system design. Things don’t always fit into neat boxes – often, there are exceptions to the “perfect design” reflecting how things work in the real world and not the world described by the community vocabulary. I’ll use the term “design exception” for describing this situation.

There are two ways of dealing with a design exception – ignore it, or design it into the system. But before making that decision, it’s best to understand what the downstream implications are of changing the design to remove the exception. The idea is to make an informed decision now and not wait until later with the hope that “something will work out”. Things rarely “work themselves out” on system development projects.

Sometimes the ignore/design revision decision is quickly made based on generally accepted concepts (been around for generations) defined by jargon. Before making this decision, the prudent application architect would first evaluate the concept to determine if it is correct (and not “lore”) and, if correct, relevant to the design. The next step is to estimate the downstream consequences of ignoring the exception; sort of like a miniature cost/benefit/risk analysis. It doesn’t take much time to do these kinds of analyses – anything more than a few hours means your spending too much time and are probably over thinking it.

An Example – The EPA’s SDWIS Modernization Effort

As required by the Safe Drinking Water Act, or SDWA, the U.S. Environmental Protection Agency (EPA) sets standards for drinking water quality and works with its regulatory partners to ensure Americans have safe drinking water. The statute defines “public water systems” and EPA delegates primary enforcement responsibility to states and Indian tribes if they meet certain requirements.

While not explicitly stated in this definition of primacy, EPA can delegate primary enforcement responsibility to U.S. Territories and to the District of Columbia.  Indeed, EPA has delegated primary enforcement responsibility to all states and U.S. Territories except the District of Columbia and Wyoming. Of the Indian tribes, only the Navajo Nation has “primacy”.

Drinking water program jargon uses the term “primacy agency” for those entities having delegated SDWA primary enforcement responsibility. However, this is technically inaccurate. For example, in California, the Water Resources Control Board manages the public water system supervision program. California is the primacy holder and the Water Resources Control Board is the primacy agency.

What about Washington, DC, Wyoming, and the Indian tribes that don’t have primacy under SDWA? For them, EPA retains enforcement responsibility through the EPA Region where the entity is located. For example, Washington, DC is located in EPA Region 3, which has primary enforcement responsibility under SDWA directly for the District of Columbia. Similarly, EPA Region 8 has primary enforcement responsibility for Wyoming. All of the other EPA Regions have primary enforcement responsibility for the Indian tribes located within their boundaries (except for the Navajo Nation in Region 9 noted above). 

The arrangement where an EPA Region has primary enforcement responsibility is called “direct implementation” – abbreviated “DI”. Thus all of the EPA Regions have “Tribal” DI programs (except EPA Region 3 where there are no tribes). Similarly, EPA Region 3 has the DC DI program and EPA Region 8 has a combined Tribal/Wyoming DI program.

Reporting Drinking Water Data to EPA

40 CFR §142.15 requires primacy holders, through their reporting agencies, submit quarterly reports of violations, enforcement actions, and new variances and exemptions to EPA.To facilitate reporting, EPA provides software to the reporting agencies that extracts, collates and formats data into an electronic file using a standardized data exchange template (the SDWA 3.5 data exchange template, or DET). 

The reporting agencies submit these files to using one of several mechanisms to the EPA’s Central Data Exchange (CDX). A back office process at EPA headquarters (called “production control”) extracts data from the uploaded files, transforms the data, and loads  it into the SDWIS Fed Data Warehouse (SFDW). EPA reporting tools access SFDW to generate various reports of drinking water data available to the public and for EPA and federal government internal use.

One of the public tools using SFDW data is the EPA’s Government Performance and Results Act (GPRA ) tool for drinking water. As required by GPRA, EPA maintains a set of performance measures for the national drinking water program. EPA reports these measures to the public and to the Office of Management and Budget (OMB) every year. The measures show if the drinking water program, at a rolled-up, national level, is meeting its goals

A public user can adjust the GPRA tool to show measures for each state, territory, DC, the Navajo Nation, and Tribal DI programs. In the Table 1 below, I’ve manipulated the GPRA Summary by Primacy report and expanded EPA Region 8 and show the statistics for the individual “primacy agencies” within the region.

Region 8 Community Water System GPRA Report
Table 1 – Region 8 Community Water System GPRA Report

The first primacy agency is “08”, which is the EPA Region 8 Tribal DI program, followed by the states located in the region in alphabetical order. Perhaps a better label for the “Primacy Agency column is something like “State/Territory/Tribe” because Wyoming and Region 8 are not primacy agencies, but part of the EPA Region’s combined Wyoming/ Tribal DI program.

Let’s take a look at Region 3 in Table 2:

Table 2 – Region 3 Community Water System GPRA Report

Here we see DC listed as a primacy agency – but the drinking water program is directly implemented by EPA Region 3. Also, we can see that there isn’t an “03 Primacy Agency” because there are no tribal water systems in EPA Region 3.

Table 3 shows the breakout for EPA Region 5:

Region 5 GPRA
Table 3 – Region 5 Community Water System GPRA Report

Here we see the “05” primacy agency for the Region 5 Tribal DI program. Of particular interest is the IL primacy agency. Illinois is the only state dividing its drinking water program in community and non-community components. The non-community component is managed by the Illinois Department of Health (IDPH) and their reported data does not appear here because the report covers only community water systems (CWS) managed by the Illinois Environmental Protection Agency (IEPA). This is an example of a primacy holder having two reporting agencies. This is not the same as the combined Wyoming/Tribal DI program we saw in Region 8 because that region has only one reporting agency.

Lastly, the EPA Region 9 GPRA report where there are no design exceptions:

Region 9 GPRA
Table 4 – Region 9 Community Water System GPRA Report

Region 9 includes three territories (AS – American Samoa, GU – Guam, and MP – Commonwealth of the Northern Mariana Islands) and the Navajo Nation (NN). As the Navajo Nation has delegated primary enforcement responsibility for SDWA, it is not part of the Region 9 Tribal DI program and reported separately like the other states and territories in the region.


In this section I define a vocabulary for SDWA based on the jargon used in the drinking water program, but with some adjustment. This “vocabulary” is inconsistent with the generally accepted drinking water vocabulary but it is technically accurate and unambiguous for system design purposes.

Primacy Holder – states, territories, and Indian tribes having negotiated primary enforcement responsibility for SDWA with EPA. EPA Regions that directly implement SDWA on states, territories, and Indian tribes that do not have delegated SDWA primary enforcement responsibility are also primacy holders. EPA Regions do not have primacy agreements because they are part of EPA.

Primacy Agency – by strict definition, a state, territory (including Washington, DC), or Indian tribe having delegated primary enforcement responsibility for SDWA through a primacy agreement with EPA. When used less formally, the term also refers to EPA Regions having Tribal DI or State/Territorial DI programs. This term should be avoided for system design purposes because of potential confusion.

Reporting Agency – When the primacy holder is a state, territory, or Indian tribal government, the agency within that state, territorial, or tribal government with overall responsibility for executing the drinking water program and reporting program data to EPA is the reporting agency. Here are some examples of reporting agencies:

  • EPA Region 9 is the reporting agency for the Region 9 Tribal DI program. Likewise, EPA Region 8 is the reporting agency for the combined Region 8 Tribal and Wyoming DI programs.
  • EPA Region 3 directly implements the District of Columbia’s public water system program and serves as its reporting agency.
  • The California State Water Resources Control Board manages the public water system supervision program for the state of California – the primacy holder. As California is a very large state, it divides its drinking water program into field operation branches and local primacy agencies and delegates responsibility down to those levels within the state. However, the State Water Resources Control Board is responsible for reporting SDWA data to EPA, so it is the reporting agency for California.
  • For Illinois, the IDPH is the reporting agency for the state’s non-community public water system program and IEPA is the reporting agency for the state’s community public water system program.

GPRA Code – a code used to collate data by state, territory, Indian tribe, and EPA Region for reporting and calculating SDWIS GPRA measures. For states and territories, the code is the two-character postal abbreviation. The Navajo Nation is designated using the code “NN”. EPA Region DI programs are reported by EPA Region using the numeric code of the Region (with a leading zero for Regions one through nine).

Potential SDWIS Prime Design Revisions

Armed with the definitions above from the revised vocabulary, we can develop a revised SDWIS system design accommodating the exceptions to the one primacy agency – one reporting agency rule. Before getting started, let’s briefly review the technical architecture of the legacy SDWIS State system compared to the modernized SDWIS Prime system. Notice in this description I do not use the term “primacy agency” because it has ambiguous meaning. Instead, I also use the term “reporting agency”, which is a little used term outside of SDWIS IT specialists, but relevant to SDWIS modernization design.

SDWIS State is designed to process data for a single reporting agency. Currently, there are 59 instances of SDWIS State running in states, territories, and EPA Regions – one instance for each reporting agency using SDWIS State. Eight reporting agencies use custom developed systems other than SDWIS State, meaning there are 67 reporting agencies total participating in the national drinking water program managed by EPA.

SDWIS Prime, the ultimate result of the SDWIS modernization project, is a new system that will replace SDWIS State. It is a centralized system capable of housing and processing data for all 67 reporting agencies. In the current SDWIS Prime design, each primacy agency and EPA Region is assigned a system partition. System configuration and options are set at the partition level so that reporting agencies can tailor their partition to meet their individual needs. Examples of partition configuration settings include, but not limited to: user security role definitions, maximum contaminant level (MCL) values more stringent than national standards, sampling requirements more frequent than national standards, and primacy agency and EPA Region defined lookup values. Primacy agencies and EPA Regions can also define custom data fields and scheduling templates (also known as standard responses in SDWIS State).

To repeat, the partition design for SDWIS Prime aligns with primacy agency. However, this causes design exceptions for the District of Columbia, EPA Region 8 Tribal/Wyoming DI program and, potentially, Illinois community and non-community programs. Table 5 in the SDWA Reporting Agencies document (opens in a new browser tab as a pdf file) lists all of the states, territories and tribes having delegated SDWA primary enforcement responsibility and Table 6 (in the same document as Table 5)  shows the EPA Regions and their direct implementation programs. From left to right, the columns in Tables 5 and 6 are (see the Definitions section for column meanings):

  • State/Territory/Tribe – corresponds to the classical definition of primacy agency, but actually refers to a U.S. state, territory, or Indian tribe
  • Reporting Agency Code
  • GPRA Code
  • Current SDWIS Prime Partition – current system/data partition used in SDWIS Prime for the state/territory/tribe
  • Revised SDWIS Prime Partition – shows rearranged partitions corresponding to reporting agency instead of primacy agency
  • Reporting Agency – Name and web address of the reporting agency

Comparing the State/Territory/Tribe column to the Current SDWIS Prime Partition column, we see that the partitions correspond to primacy agency. At first blush, this seems appropriate. However, this approach breakdown for Illinois because the state has two reporting agencies for their community and non-community programs. The simplest way to correct this problem is to base the partitions on reporting agency – not primacy agency. For Illinois, the fix is to replace the current IL partition with an ILC partition for the community public water system reporting agency and an ILN partition for the non-community agency. Each Illinois agency can now manage its own SDWIS Prime system configuration settings and security roles without having to coordinate with its counterpart.

However, before making this decision for Illinois, business analysts should meet with representatives of both reporting agencies and cover the advantages/disadvantages of maintaining separate partitions versus combining both reporting agencies in the same partition (as discussed later for EPA Region 8). Discussions should include how each approach would work with the Compliance Monitoring Data Portal (CMDP) and CROMERR (neither described in this article).

For EPA Regions and their DI programs, there are three exceptions to the current SDWIS Prime design (highlighted in the table). Currently, EPA Region 3 is assigned the DC partition in SDWIS Prime. The revision shows the Region assigned to the 03 partition corresponding to its designation as the reporting agency for DC. Also, as the District of Columbia is not a reporting agency, the revised SDWIS Prime design would not have a DC partition.

More problematic is the two DI programs maintained by EPA Region 8. Currently, Region 8 has two partitions in SDWIS Prime, one each for Wyoming and the its Tribal DI program. The design revision proposes housing Wyoming and the Tribal DI data in the same partition. Merging the data this way requires a redesign of the way SDWIS Prime handles Public Water System Identifiers (PWSID).

Currently in SDWIS Prime, PWSIDs are prepended with the primacy agency code. For example, a Wyoming PWSID looks like “WY1234567” and a Tribal PWSID like “081234567”. The problem is that if the Tribal DI program was merged into the Wyoming program, all of the tribal PWSIDs would start with “WY” instead of “08”. PWSID “081234567” would change to “WY1234567”, causing a duplicate PWSID, which is prohibited. 

One way to overcome this issue is to use reporting agency ID instead of primacy agency ID as the prefix for the PWSID and allow both to exist in the 08 SDWIS Prime partition. Region 8 users would see PWSIDs prepended with “WY” and “08” mixed together in the user interface. A configuration setting would tell SDWIS Prime that the 08 partition allows two GPRA codes – “WY” and “08”. This would require a new user story (user story 1 below) where the user must select the appropriate GPRA code for a new water system:

User story 1: As an inventory maintainer, I want to select the GPRA code from a list of acceptable values when I am entering a new PWSID so that SDWIS Prime will associate the water system to the correct state, territory, or tribe in SDWIS Fed.

Because this exception only affects EPA Region 8, we need three more user stories to allow a partition to handle more than one GPRA code:

User story 2: As the SDWIS Prime System Administrator, I want to specify from 1 to any number of GPRA reporting codes a SDWIS partition will handle so that the system can process and store data for more than one state, territory, and tribe in the same partition.

User story 3: As an inventory maintainer, I want SDWIS Prime to automatically select and display the GPRA code if there is only one GPRA code associated with my current partition so that the system doesn’t make me needlessly select a GPRA code from a a set consisting of one GPRA code.

User story 4: As the SDWIS Prime System Administrator, I want SDWIS Prime to warn me when I attempt to associate a GPRA code to a partition when the code has already been assigned to another partition.

In these user stories, the “SDWIS Prime Administrator” is not the same as a “Reporting Agency System Administrator”. The former operates at the system-wide level while the latter at the reporting agency partition level. Ensuring that reporting agencies are not duplicated across partitions is a responsibility of the SDWIS Prime System Administrator. GPRA codes have to be setup before a reporting agency can begin using their partition, which his something the Reporting Agency System Administrator cannot do. 

Downstream CMDP Issues

There are downstream issues requiring examination before blindly making the changes suggested in the article. For example, the Compliance Monitoring Data Portal (CMDP) design is partition into primacy agency, which doesn’t correspond to the exceptions described in the previous section. This would cause a “disconnect” between the SDWIS Prime redesign discussed here for EPA Region 8 (and, possibly, Illinois). Shifting CMDP partitioning and Shared CROMERR Services (SCS) integration points to correspond to the revised SDWIS Prime partitions would make it easier for CMDP submissions to the Wyoming and Region 8 DI programs (since both would be combined).

As I discussed above, more information is needed to determine what to do about Illinois and its two reporting agencies. For example, how much do the agencies coordinate their activities? If a lot, merging both primacy agencies into a single SDWIS Prime partition like Region 8 may make sense. With the current system design, both Illinois agencies will have to share a SDWIS Prime partition partition.


I apologize for “dragging” you through the rather complex example of SDWIS Prime, CMDP, and SCS (yet more jargon and acronyms). But hopefully you can see the point I was trying to make at the beginning of this article – as business analysts and application architects, we have to make sure that the language our stakeholders are using doesn’t constrain the design. In EPA’s drinking water program, the term “primacy agency” has a lot of meaning, but from a system design perspective, it’s fraught with loaded meaning. However, because most of the stakeholders involved in the SDWIS Prime and CMDP projects work for primacy agencies (and not EPA Regions in this context), they attach a lot of significance to the term to the point where it’s driven system design. Our example shows that reporting agency, a term familiar to people working on the quarterly reporting process, is more appropriate to SDWIS design. The trick is convincing the stakeholders.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: