Why we built Ambientia Data Platform?

It started with a customer question

Early last year, one of our teams was asked a fairly specific question: could we build a data platform that was not directly tied to one of the large commercial platform ecosystems, and that could also run on-premises? The request came at an interesting time. Our data engineers and architects had already been discussing another problem for a few years: modern data platforms are powerful, but that power also brings complexity. A lot of engineering time can go into configuration, pipeline dependencies, scheduled runs, and debugging what changed where.

The customer question connected with that existing frustration. Instead of asking how to add more features, we started asking what a data platform would look like if we deliberately made it easier to understand, operate, and move. We wanted to know what was happening at each stage of the data flow, keep important configuration visible and machine-readable, and avoid creating a system where one technology choice would become permanent simply because replacing it later was too difficult.

One request became a pattern

At first, this could simply have become one customer solution. During the spring, we developed the idea together with the customer and evaluated the components that could form the foundation. Then another customer raised a similar need. That changed the conversation. If the same question was appearing in more than one place, perhaps we should design the solution once, properly, instead of solving the same type of problem separately every time.

That was the point where the idea started becoming Ambientia Data Platform. We already had an architectural concept and a set of components we had evaluated, even though we didn't yet have a finished platform.

When we started visualising the architecture, we imagined independent blocks with clear responsibilities. Each block should work as part of the whole, but none of them should become irreplaceable. That idea also became the basis for the ADP visual identity. We then made the decision with Ambientia's business leadership to move forward and be brave: combine our data, architecture, DevOps, and open-source experience, build the platform, and take the idea to the market.

What we decided ADP had to be

The first architectural principle was that every component must be replaceable. ADP has a default stack, and we take responsibility for evaluating those components, following their lifecycle and maintaining the combination as a working platform. But the architecture itself should not depend permanently on any one of them. This is not a marketplace of interchangeable plug-ins. It is a considered default stack built around clear boundaries, with the possibility of replacing a component when there is a good reason to do so.

The second principle was machine-readable configuration. Important configuration should not live only in a graphical interface or in someone's memory. We want it to be visible, version-controlled, and reproducible. The same thinking applies to the rules used to transform and manage data. From an engineering point of view, this makes the platform easier to understand, review, and rebuild. It also gives AI-assisted development a useful role: AI can help generate configuration and intermediate logic without hiding that logic from the people responsible for the platform.

The third principle was semantics. Moving and transforming data is not enough if nobody knows what the data means in the business context. AI readiness makes this particularly visible. A useful data foundation needs definitions, business rules, data contracts, and quality information alongside the data itself. We want that knowledge to be version-controlled as well. ADP can support the semantic layer, but we draw a clear boundary around its role: ADP is a data platform, not an AI platform. Its job is to provide reliable, timely, and meaningful data that analytics and AI systems can use.

From architecture to running data

Once the principles were clear enough, we moved from diagrams to implementation. We've installed the initial open-source components and are building the first end-to-end flow through the platform. For the first test case, we deliberately chose something the whole team could understand: electricity forecasts and actuals. The subject itself is familiar, but using it properly requires the full path from the upstream source through ingestion, contracts, raw data, transformation and modeling to something that can finally be consumed and visualized.

Data is now moving successfully through that path. The next step is to test one of our main architectural assumptions: component dependency. What happens if we remove a component? Can another one take its place? Does the rest of the architecture still make sense? The ability to answer those questions in practice matters more to us than simply describing ADP as modular.

Keep your options open

ADP is not intended to replace every data platform an organisation already has. In many cases, there's no reason to do that. A company may already have a good platform in Azure, Fabric, AWS, Google Cloud, Snowflake or another environment. ADP can live alongside those choices and be used where greater control or portability is important.

The need may appear during an acquisition, when organisations are restructured or when a cloud strategy is reviewed. It may also concern only a particular set of sensitive data rather than the organisation's entire data estate. The common factor is not a particular technology or industry. It is the decision to keep meaningful options open, rather than assuming every part of the data architecture must follow the same path.

An acquisition is a good example. Bringing a company into a group does not necessarily mean every data platform must be absorbed immediately into the group's existing environment. A separate managed platform can allow the business to move forward while longer-term decisions are still being made. Sometimes it makes sense to integrate the business before integrating every platform.

Owning the meaning, not just the data

This is also why we think ownership needs to include more than raw data. The definitions, transformation logic, data contracts, and quality rules around the data are what make it useful. They describe what a customer means, how a particular metric is calculated, which transformations have been applied, and what others should expect from the result. If that knowledge cannot move, the data is not as portable as it first appears.

The semantic layer is one place where this becomes concrete. An organisation can continue using its existing data platforms while maintaining important business definitions and rules as version-controlled assets in ADP. Those definitions can then be made available through interfaces to analytics tools, other data platforms and AI applications. The data does not all have to live in the same place for the organisation to own and manage the meaning around it.

Ambientia's role is to help set up and operate the technical foundation, evaluate the components and help the organisation get started. We can also use AI-assisted methods to speed up the creation of semantic definitions and other machine-readable assets. But the business meaning itself should remain with the organisation. A technical platform can support that understanding, but it cannot decide what a customer, product or revenue figure means for the business.

Where we are now

ADP started with a customer question and met an engineering frustration that had been building for years. A second customer helped us see that the need might be broader, and that was enough for us to turn the idea into a platform concept. Today, the initial stack is running, data moves through the platform from source to consumption, and we are testing the assumptions behind the architecture in practice.

We also know that ADP is not for every organisation. It makes sense for organisations that want to take a concrete step towards greater data portability and control, and that are willing to understand and own the rules around how their data moves and what it means. We have built that alternative now. We are testing it as we go and learning where it creates the most value. If your organisation is asking similar questions, we would be happy to compare notes.