During a tech sprint at last year’s Big Data from Space, we realized how many of the software engineers and architects in the room were connected to ESA’s EOEPCA effort in one way or another.

Some were building APIs. Others were maintaining catalog infrastructure, deploying processing systems, working on standards, or supporting operational Earth observation platforms across Europe. Many came from different institutions, different countries, and different technical backgrounds.

But they were all contributing to the same ecosystem.

To us that’s one of the most exciting aspects of EOEPCA.

Large architecture efforts can easily become abstract exercises disconnected from operational reality. It is not difficult to produce documentation describing how platforms should work – and opinions are never lacking. Building infrastructure that people actually adopt is much harder. But on EOEPCA, it’s actually happening.

(Btw, the group photo above is actually from the ESA Living Planet Symposium.)

A shared problem across EO platforms

Organizations building Earth observation platforms are facing the same challenges: How do you catalog and expose large collections of EO data? How do you support scalable processing workflows? How do you manage authentication, user workspaces, and infrastructure deployment? And how do you avoid reinventing the wheel to provide these functions?

EOEPCA — ESA’s Earth Observation Exploitation Platform Common Architecture — emerged from the recognition that a joint effort benefits providers and users alike. The list of stakeholders is long and impressive: German Aerospace Center (DLR), Greek Data Hub (GNEO), UK Research and Innovation (UKRI), French Space Agency (CNES), Canadian Space Agency (CSA), Digital Earth Canada, ESA APEx/EarthCODE and Information Factories, and many others, forming a very engaged steering committee.

How does one size fits all? – It does not: In practice, EOEPCA provides a collection of shared infrastructure components that organizations can pick and choose from and adapt to their own systems.

Some platform owners are mainly interested in cataloging and data access. Others also need processing infrastructure, authentication services, or workspace management. Thanks to well-defined interfaces, mixing and matching is possible.

From architecture to operational infrastructure

What helped EOEPCA mature was a strong focus on existing technology and community-endorsed concepts rather than purely theoretical architecture: STAC, OGC APIs, Kubernetes, Keycloak, openEO, eoAPI, and many others.

One thing we appreciated quickly about EOEPCA was the requirement that components are independently viable open-source software projects. The goal is not to build project-specific software, but to improve and integrate open-source tools that are widely popular.

Such projects are a critical source of stable funding for open-source software.

Collaborative spirit

EOEPCA is fostering something larger than a technical architecture: a collaborative environment where agencies, research institutions, and companies work on shared infrastructure problems together.

People were also much more open about their work than we initially expected and generous to support each other. Teams regularly pointed to things another group had built and said, more or less, “this works well, you should look at this approach.”

That is not always what you expect in infrastructure work, especially when many of the organizations involved could just as easily operate much more competitively.

Development Seed’s role

Development Seed is delivering the Data Access building block to EOEPCA, building on experience from eoAPI and other cloud-native geospatial infrastructure projects already being developed in the open.

Within EOEPCA, the Data Access building block focuses on helping platform providers expose and serve Earth observation data through scalable APIs and cloud-native services. Much of this work builds directly on eoAPI and related tooling around STAC and dynamic tiling.

For us, the project aligned naturally with many ideas we already believed in: open standards, modular architectures, reusable infrastructure, and upstream open-source development.

But one of the most valuable outcomes has been the relationships with like-minded organizations such as DLR, EOX, VITO, and others building operational EO infrastructure at different scales.

Why this matters now

More organizations across Europe are now running Earth observation systems operationally rather than experimentally. That includes climate monitoring, environmental reporting, scientific workflows, and increasingly large-scale processing infrastructure around EO data.

Some of the technologies have matured rapidly in the last few years. Tools and standards that were once mostly discussed at conferences are now running inside production platforms across multiple institutions. There is now a fairly large operational ecosystem around parts of the architecture, which probably says more than any diagram or specification could.

As the community gathers again at FOSS4G Europe, it is worth recognizing that some of the most important open-source work in geospatial is not always visible through individual applications or announcements. Sometimes it appears through slower, long-term collaboration around the infrastructure that many systems quietly depend on. In the long run, that collaborative ecosystem may be EOEPCA’s most important outcome.