Data is like Sauron’s ring: whoever holds it has the power. Traditional organizations have used this to control Citizen Developers, leaving them with scraps like unstable Access databases and CSV files on shared drives.
Self-Serve Data plateform
The foundational technology for UCD is a self-service data platform, open to everyone and especially Citizen Developers.
In this new framework, data becomes a shared resource thanks to a self-service platform that provides the full range of Data as Products.
Data must be universally accessible, secure, monitored, and monetized.
Secure, because access rules, GDPR, PII, trade secrets, and intellectual property must be protected.
Monitored, because it’s essential to know where the data comes from, who uses it, and how it’s distributed.
Finally, monetized, because nothing is free in this world, and showing consumers the real cost for a company highlights the value of data and encourages more thoughtful and responsible usage.
The foundational technology for UCD is a self-service data platform, open to everyone and especially Citizen Developers. Without it, UCD cannot exist.
If you are working within a Data Mesh or Data Fabric culture, you likely already have a self-service platform. Often, all that’s missing is one final step: making it accessible to Citizen Developers.
If you don’t have anything in place, a data virtualization tool like Denodo can make it much easier to build a self-service platform.
Another important anchor point is the Read Data Stores (RDS) Architecture by Piethein Strengholt, which is detailed in his book Data Management at Scale, 2nd Edition.
Data as product
Today, the concept of Data as a Product, its governance, and the related self-service approach have been extensively developed through Zhamak Dehghani’s Data Mesh principles (https://martinfowler.com/articles/data-mesh-principles.html).
The goal of this article is not to go into detail on these elements but to focus on what matters most for a Citizen Developer.
For simplicity:
A Citizen Developer expects data to be easily discoverable. This means the company must establish a web catalog, managed by its technology arm, that consolidates all Data as Products. As explained in the Data Mesh, the Citizen Dev should be able to connect with the Domain Data Product Owner through this catalog to quickly get answers to their questions.
A Citizen Developer assumes the data they receive is reliable and trustworthy. They are not concerned with data quality issues—that’s not their role.
For independence:
A Citizen Developer expects to easily understand the underlying data models. The vocabulary used should closely match their business experience. Domain-Driven Design (DDD) remains the best approach to modeling.
They should be able to access data without relying directly on IT. While this doesn’t exclude governance, such governance should remain lightweight and be led by a business unit. Security, while essential, should be as seamless and transparent as possible.
For self-improvement:
Citizen Developers need regular training on the latest updates to the self-service platform, both technologically and functionally. In practice, many Citizen Devs lack sufficient training on data. While they don’t need to fully understand the intricacies of what a Data as a Product entails, they should grasp the three key limitations of datasets:
- Does this dataset cover all the entities I need? For instance, does the “Article” Data Product include all articles sold in Asia?
- Does the dataset contain all the fields I need?
- How fresh is the data I am retrieving?
In 2025, simply coupling a naive LLM to your data platform will not address these needs.
Data as a Product becomes the primary area of excellence for software teams. Its testability, modeling, metadata, governance, security, and support are essential for the democratization of Citizen Development. As shown in the previous diagram, these are supported by a self-service platform.
Read-Only API
We include APIs in the data section because we focus on consumption and distribution. Of course, we’ll discuss modification APIs later, particularly in the context of CQRS.
Ideally, read-only APIs should be built directly on top of Data as Products, making them unnecessary for Citizen Developers since they can directly access the dataset.
However, there are cases where only an API is available. This might happen because the operational system offers a freshness level that the self-service platform cannot handle, or because it’s a purchased software.
Naturally, a Citizen Developer can still work with an API. It requires more effort, especially if the data needs to be joined or aggregated. The solution we recommend is to use a data virtualization tool (such as Denodo or TIBCO Data Virtualization). By virtualizing the API as a database, the Citizen Developer won’t notice any difference from a regular Data as Product.
Streams / Motion
The flow of data moving through events or messages is extremely difficult for a Citizen Developer to handle. IT will need to set up structured secondary storage layers. Event stores should be avoided.
Modification and Processing
A Citizen Developer wants and needs to interact with the information system. For example, they may want to receive automatic notifications, generate internal reports, modify reference data, create their own datasets, process payments automatically, settle invoices, orchestrate workflows, and more.
Wherever possible, they should be able to perform these actions without relying on specific software or screens.
API Catalog
The company’s API catalog should allow Citizen Developers to know all the operations they can perform. Just like data, there should be no distinction between APIs for corporate IT and Citizen Developers. An enterprise API is, by definition, meant for the entire organization.
For transformations of the CRUD type, Citizen Developers can operate directly on the data product while respecting their ACLs. They can be assisted by their IT reference (Athena) to write their query or by using an LLM.
For more advanced operations, a command-based approach is recommended. In fact, we even suggest this for simpler actions as described earlier. We strongly adopt a CQRS approach here: modifications are made through commands sent to APIs, while data is queried using SQL on Data as Products:
Let’s not forget that Data as Products and APIs are the result of high-level expertise provided by IT.
In short, by using commands, we give Citizen Developers a business-friendly vocabulary, safeguard the information system, and provide technological independence for operational persistence strategies. However, this comes with higher integration complexity that Citizen Developers must manage.
Now that we’ve covered data, it’s time to focus on the Graphical User Interfaces (GUI) for Citizen Developers.