A sovereign IT platform for a joint venture

Two corporations found a joint venture. The new company needs its own IT foundation — on day one, not in two years. Hyperscaler lock-in is politically sensitive because neither parent may hold strategic leverage over the other. Building your own stack without a foundation costs years. We set up the platform: 100% open source, on-prem Kubernetes, multi-tenant — production-ready from the start.

On this foundation several independent use cases run alongside each other today, with shared identity, shared monitoring, shared audit path. New use cases arrive as namespaces, not as separate platforms.

Three requirements that are non-negotiable

Multi-tenant from day 1. Multiple use cases, multiple provider teams, cleanly separated authorization and data scopes. One platform, many applications — but resources, identities and costs attributable.

Data sovereignty non-negotiable. Sensitive operations data must not flow uncontrolled into foreign clouds. On-premise with a clear responsibility model — not out of nostalgia, but because it’s compliance-relevant reality.

No vendor lock-in. A joint venture from two corporations must not technically maneuver itself into a position where one parent could hold license-contract leverage over the other. The JV company is independent — its IT must be just as independent technically.

Production-ready from the start. Security, monitoring, backup, CI/CD are not “do later” topics, but baseline. Anyone betting on downstream hardening phases for a JV foundation has not understood the problem.

What the platform brings

Base layer. A Kubernetes cluster with multi-tenant namespaces, a Postgres operator as database layer, a BI and visualization layer, SSO via Authelia plus Dex and LDAP, message broker for service-to-service communication. All open source, all production-ready.

App layer. Apache Camel-based integration runtime for data streams, dbt for SQL transformations, an Open Data Discovery catalog for data catalog and lineage, MLflow plus Jupyter where analytics is needed, use-case-specific front ends. Components are added per use case — the foundation stays stable.

Operated by datatactics. Platform operations, patching, extensions, security updates as ongoing service. The JV company consumes engineering without having to scale its own platform team.

Why open source end-to-end

Political clarity. When both parents of a joint venture have to agree on which vendor delivers the platform, a negotiation begins that no one wins. Open source is the answer no one can strategically argue against — no vendor relationship, no license geography, no usage metrics flowing into outside hands.

Economic clarity. No platform license costs on the OSS base, no ramp-up costs when scaling the foundation, no vendor license audits. What the JV company pays for is engineering and operations of the platform.

Architectural clarity. Components built on open standards are replaceable. If a better Postgres operator variant arrives tomorrow, if the ML stack shifts, if the data catalog should change — the platform survives that.

What runs productively on it

On the shared foundation several applications run independently alongside each other today — a data analytics platform for operational optimization, a collaborative positioning tool for operational decisions, a real-time incident management stack (since then productized), a data catalog for business-user self-service. New use cases arrive without rebuilding the existing components.

The foundation scales without platform license costs. What the JV company pays for is engineering and operations.

Joint ventures, group subsidiaries, public-sector entities, mid-market companies with sovereignty requirements all share the same pattern problem. The answer isn’t “another SaaS”, but a foundation that belongs to them. If that applies to you, the Tactical Assessment clarifies the way there.