From greenfield to operability: a sovereign private cloud for critical workloads

A large European transmission system operator is building a new cloud-native private cloud in its own data centres. It lays the foundation for modernising the existing application landscape and for running critical workloads sovereignly, independent of the public hyperscalers.

ARISE carries technical product responsibility on two levels: in platform-wide product management, and with a dedicated product management lead for identity & access management.

The brief goes well beyond backlog management. We connect product strategy, platform architecture, security, reliability, operations and delivery into one product and operating model — so that technical infrastructure becomes a platform that can be run reliably and, later, scaled economically.

The scale is not the point in itself. More than 300 non-functional requirements and a long list of platform domains — from infrastructure and Kubernetes through IAM to data and developer services — have to be translated into one product model. That is exactly the steering job of a technical product manager.

The platform is not being built for just any workload.

It is aimed at applications in critical infrastructure — applications where availability, reliability, security, recovery and operational independence decide whether a product is fit for production at all.

That changes the product logic. A new feature is only worth something if it works under real operating conditions. Self-service only makes sense if it does not undermine security and operability. And a technical dependency is more than an architecture decision when, during a connectivity loss or a serious incident, it affects what the operator can still do.

So we sharpened the platform profile consistently from the target workload: Which applications belong on this platform? Which requirements already apply to business-critical pilots? Which capabilities have to be learned and hardened in operation? And what has to be proven to work before mission-critical applications can move onto the platform?

The target extends to applications that have to run reliably even under exceptional disruption. The platform is being built today so that this next stage is not blocked, technically or organisationally, by early architecture or operating-model decisions. General availability is planned for the end of 2026.

Greenfield sounds like freedom. In an infrastructure programme of this size, though, greenfield means that a great many foundations have to emerge at once: technology, product boundaries, ownership, security, governance, release management, operational responsibility and team structures.

And the platform does not emerge in a vacuum. It has to fit into existing data centres, security models, identity landscapes and organisations. Platform services are consumed by other platform services at the same time, and later by application teams. Data, developer, runtime and security capabilities depend on each other.

Technically, the context runs from infrastructure and network through managed Kubernetes to identity, data and developer services — with streaming requirements from very large, critical use cases.

ARISE does not own every one of these products. Our job in platform product management is a different one: to turn these capabilities into one coherent product portfolio. For the data product line, for example, we worked out the requirements from the streaming use cases without owning the product line itself.

That is the role of the technical product manager: orchestrating dependencies, connecting security and architecture with delivery, making trade-offs decidable, and translating technical requirements into the roadmap and into product decisions.

Over the course of the programme so far, three ARISE product managers have worked in it: two platform product managers in consecutive engagements, and a dedicated product management lead for identity & access management.

The platform product managers' central persona is the operator — the people who will have to run the platform under real production conditions. That calls for a different yardstick than many classic digital products: operability, security, reliability and availability are not quality attributes at the end of delivery. They are product requirements.

That takes technical depth. Our product managers have to understand architecture and platform mechanics well enough to decide trade-offs with engineers, architects, SREs, security and compliance as equals.

It is the core of how we approach internal platforms: engineering builds capabilities. Product makes sure they become a platform product that can be steered, used, and that has an effect.

01 — Start from the workload

A platform can very quickly turn into a large catalogue of technical possibilities. That alone creates no leverage.

So we turned the perspective around: the starting point is the workload, not the capability. How critical is the application? Does it have to keep running through a connectivity loss? Which security and compliance requirements apply? Which reusable capabilities does it consume? And does its profile justify the platform's economics?

The result was a clear ideal application profile. Business-critical workloads provide a controlled start. Operation produces evidence. Platform capabilities are learned and hardened. On that basis, the product profile can be extended towards mission-critical workloads.

This reduces risk without shrinking the target. And it avoids one of the most expensive platform traps: building a universal platform before it is clear for which workloads its complexity actually creates value.

02 — Prioritise operability over convenience

The roadmap was not built around the most visible features. In critical infrastructure, a reduced operational or security risk often creates more value than another convenience flow. So there is a clear order:

Observability, runbooks, backup and restore, disaster recovery, controlled deployments, release management and clear operational ownership are not downstream tasks. They are part of the product.

Release delivery is a good example. In the early greenfield and factory build-up, substantial release packages could take months. Today the organisation plans to the sprint and moves security-relevant platform changes through the entire delivery path far faster.

The point is not to declare as many process steps as possible “compliant”. What matters is that the product shipped is compliant and safe to operate. A fully compliant development process does not guarantee a compliant product. Process is a means to that end — not an end in itself.

03 — Build the organisation around products, not processes

The bigger a platform programme gets, the stronger the temptation to answer every new dependency with a new process. More meetings. More boards. More approvals. More coordination. It can suggest control while making delivery slower — and in a fast-growing organisation with many external specialists, process sprawl sets in within a short time.

So we kept asking the same question: Which problem does this process solve? And then: What effort does it create? Which decision does it improve? What delay does it cause? And what happens when the next process is built on top of this one?

Where a process did not carry enough leverage, we simplified it or replaced it with clearer product ownership. Team Topologies principles helped organise teams and responsibilities around products and long-lived capabilities. Portfolio and release steering create transparency over the cross-product dependencies that are genuinely needed.

Not every decision is centralised. Instead, there is a clearer line between the decisions that belong in a product team and those that are a shared platform decision. Local optimisation can raise global security or compliance risk; a shared, risk-based roadmap makes those trade-offs visible and therefore decidable.

IAM shows particularly well why technical product leadership in a private cloud is more than backlog management.

In a platform with many upstream and downstream services, communication paths arise at infrastructure, platform, tenant and application level. Without a shared identity architecture, this web quickly ends in static credentials, secrets and service account tokens. That is credential sprawl — and it makes rotation, isolation and auditability harder, as well as the question of which workload is accessing which service with which permissions.

So we built workload identity for the platform as a reusable platform capability.

A workload is registered through the control plane. Managed Kubernetes provides the necessary integration as part of the platform. Through an injected integration, workloads obtain short-lived tokens without every consuming team having to build its own credential flow.

A central yet federable identity provider establishes the trusted identity. OIDC and OAuth2 form the standard basis for communication. Shared policy logic lets downstream services make authorisation decisions based on that identity.

Before the production rollout, the underlying identity control plane was load-tested for 5,000 to 10,000 workloads. The capability is designed for real lifecycle scenarios: automated registration, deployment changes, isolation, and rolling and blue/green deployments are part of the product design.

It is a good example of how we treat security. Not as an extra gate at the end, but as a reusable platform capability that raises security and at the same time makes life easier for the teams that consume it.

The technology stack alone would not have been enough for this programme. Alongside the platform, a new organisation, new product lines and new operational responsibilities emerged. The platform organisation now numbers around 350 people; the IAM product line alone around 20.

A scale like that changes product work. More engineering capacity does not automatically mean more platform impact. Without a shared product logic, every additional team also adds dependencies, interfaces and local optimisations. So we looked at people, process and platform together:

A platform is, after all, a service for other teams. It only creates leverage once it makes those teams faster and safer, and is usable enough that it actually gets used.

The platform has not reached the end of its journey. That is exactly why we do not measure today's success in invented ROI or projected savings. The changes that can be shown lie where a platform has to be robust right before general availability.

• A greenfield initiative has become a structured platform portfolio with a shared release and operating model.
• A broad cloud vision has become a clear product profile for critical workloads.
• More than 300 non-functional requirements are no longer treated as technical constraints alone, but translated into product, risk and release decisions.
• Delivery has become faster and more predictable despite growing system and organisational complexity.
• IAM provides central human and workload identity capabilities.
• Observability, runbooks, recovery mechanisms and operating procedures lay the foundation for the move from build & enable to scale.

The platform is cut so that scaling does not mean growing operations staff and operating costs in proportion. And the IAM expertise built up in the programme now reaches beyond the private cloud: ARISE is to help resolve the fragmentation of identity & access management across the wider organisation as well.

The most important lesson from this engagement is not which Kubernetes distribution or which IAM tool was used. A private cloud for critical infrastructure becomes valuable when target workloads, economics, technical capabilities and operational responsibility fit together.

That takes product managers who can work at real technical depth. They have to understand why an identity pattern solves a security and an operations problem. Why a streaming use case places different demands on Kafka and the data services. Why an architecture decision changes later OPEX. And why a seemingly helpful process can slow a platform's delivery down.

At the same time, they have to look far enough beyond the technology: adoption, portfolio, risk, reuse, investment sequencing, operating model. That is why we measure platform impact in four dimensions: adoption, delivery flow, governance & risk, and developer experience.

General availability at the end of 2026 starts the next stage of proof. So far the focus has been on building the right capabilities, establishing operability and putting a robust product and operating model in place. After that, it will show how well the platform delivers its leverage across more workloads and more consuming teams.

This phase is already built into today's product decisions. Scale should not mean that OPEX, manual operations work and organisational overhead grow in proportion. The platform should scale because its capabilities are reusable — and because the organisation can run it reliably.