I recently attended an Exchange Network workshop where the main topic was how to reimagine the network. The workshop went well, and it got me thinking, which is not always the safest thing to do. But here we are.
My view is that the Exchange Network still works as a concept. It was the right decision for the time, and it solved the problem we had. In the early 2000s, we needed a common way to exchange environmental data between states, EPA, and other partners. We needed shared rules, shared definitions, and a predictable way for one system to talk to another.
The part that has aged is not the concept. It is the original implementation.
How We Got Here
Back then, Web Services and SOAP were everywhere. SOAP and WSDL were serious technologies, and they were the responsible choice for the kind of cross-organization work we were trying to do. They were also new enough that a lot of the details had to be worked out the hard way.
Our main interoperability targets were Java and .NET. Python was not something many people in our world were using for this kind of work yet. So contractors and program teams worked through all the small but important details: headers, SOAP actions, payload handling, error responses, attachments, and the rest of the machinery needed to make the same protocol work across different platforms.
Large files were also a practical concern, so the specifications had to deal with DIME, MIME, and the other pieces needed to move bigger payloads reliably. It took a lot of work to make those things interoperate. Eventually the details got polished, the reference implementations came together, and the Exchange Network launched.
That took serious work, and the Node model did its job.
What Has Changed
A lot has changed since then. We are no longer thinking only in terms of moving large data packages from one place to another. More and more, we are thinking in terms of smaller, more specific requests: fetch this record, update that submission, check this status, return this set of data.
That model fits REST and JSON much better than it fits the old SOAP Node approach.
The Resource Conservation and Recovery Act (RCRA) program has already been moving in this direction. RCRAInfo and e-Manifest use REST APIs and JSON for production work today. We have been talking about this with our partners for a few years, including at the RCRA conference we hold every two years. Developers can authenticate, call an endpoint, and get back a clear response without standing up a Node or dealing with WSDLs and SOAP envelopes.
The RCRA program is not the only one moving this way. From the workshop, and from other conversations, it sounds like programs in the Office of Water and the Office of Air are also going down this path. That matters because once several programs are already moving in the same direction, the question becomes whether we let it happen separately or give it a common shape.
What the Next Version Should Be
I do not think the Exchange Network needs to go away. I think the Node needs to be slowly sunset, and the Exchange Network needs to become something simpler and more useful for the way systems are built now.
The next version should be a central website and a set of principles for how environmental data is exchanged. It should list the REST services available across programs and explain the rules clearly: how authentication works, how requests are structured, how errors are returned, how versioning is handled, and how a partner can actually use the service.
This should be much easier than building the original Node specification. We do not have the same interoperability problems we had in the early 2000s. We do not need to design around DIME and MIME. We do not need every program to publish a WSDL and expect new developers to work backward from it.
A modern version needs a much smaller set of things:
- OpenAPI documentation for each service.
- Practical recipes that show how to authenticate, retrieve data, and update data.
- Shared conventions for errors, versioning, pagination, and common request patterns.
- Guidance for programs designing new workflows so they do not each invent a different style.
That is enough to give the network shape without making it heavy.
The Timing Matters
This is also timely because AI-assisted tools are becoming part of how software gets built. They work much better with REST endpoints and JSON than they do with SOAP Node implementations and program-specific XML flows. That does not mean we redesign the Exchange Network just for AI. It means that simple, well-documented interfaces now matter even more than they already did.
If environmental data is exposed through predictable APIs, people can query it, validate it, load it into warehouses, and build useful workflows around it much more easily. That helps developers today, and it gives newer tools a cleaner foundation to work from later.
Do Not Overbuild the First Step
One lesson from the original Node work is that committees can spend a long time trying to make every data model line up perfectly. There is value in consistency, but we should be careful not to make that the first barrier.
The immediate opportunity is access. Make the services discoverable. Make the documentation clear. Make the authentication consistent. Make it easy for a state, a program, a researcher, or a contractor to get the data they need and use it responsibly.
Some of the deeper data consistency problems can be worked through over time. In many cases, partners can already land the data in their own systems and relate one dataset to another in ways that are useful for their work. We should not lose momentum by trying to solve every modeling problem before we make the data easier to reach.
Where This Leaves Us
The Exchange Network was the right idea in the early 2000s, and it is still the right idea now. The part that needs to change is the old Node implementation. A central catalog of REST services, backed by clear principles and practical documentation, would keep the value of the Exchange Network while making it much easier to use.
This is already moving forward. The question is whether we can give it enough common structure before every program solves the problem separately.
If you are thinking about where environmental data exchange should go next, we would be glad to talk. I have been personally involved with the design and implementation of the Exchange Network since the early 2000s, and I am obviously interested enough to think about this on a Sunday. You can email us and send us your thoughts.
