5 min read

Dirk Wassermann

What he needs: Kaphera managing the platform on his own infrastructure, with a source-available exit path. What he will not do: Run connector infrastructure on a third party’s cloud. Why he buys: Operational expertise his team lacks, without surrendering infrastructure control.

VP of data and platform engineering at a major automotive OEM, leading a team of forty engineers across platform, data infrastructure, and developer tooling. His organisation cannot run connector infrastructure on a third party’s cloud; he wants Kaphera to operate the platform on his own infrastructure under a source-available licence that gives him a credible exit path.

Role: VP of Data & Platform Engineering, large automotive OEM (45,000 employees)

Background

Dirk has spent twenty years in infrastructure and platform engineering at large enterprises, the last seven at one of Germany’s major automotive manufacturers. He studied electrical engineering before pivoting into software early in his career, and he has led platform teams through two major cloud migrations and one significant infrastructure insourcing initiative, an experience that gave him a detailed understanding of what vendor dependency actually costs when the terms change. He holds strong convictions about infrastructure ownership: his organisation runs its own private cloud on dedicated hardware in German data centres, and every architectural decision is evaluated against whether it creates an exit constraint. He is technically deep, he can read a Kubernetes operator implementation and form a view on its architecture, and he leads a team of forty engineers covering platform, data infrastructure, and internal developer tooling.

Responsibilities

Dirk is accountable for the platform infrastructure that underpins the organisation’s data exchange capabilities, including its participation in Catena-X and the internal dataspace it operates for its tier-1 supplier network. He sets the architectural standards his engineering teams build against, owns the vendor relationships for platform-level infrastructure, and is the escalation point when platform failures affect production systems or external commitments. He also carries responsibility for the organisation’s infrastructure compliance posture, TISAX Level 3, ISO 27001, and internal security standards that exceed what most managed services are certified to, which means every infrastructure decision goes through a security review that he personally signs off on.

Challenges

Dirk’s organisation cannot run its connector infrastructure on a third party’s cloud. This is not a preference, it is a firm requirement driven by data classification policies, contractual obligations with OEM partners, and a board-level commitment to infrastructure sovereignty that predates the dataspace conversation. His team has been attempting to run EDC Connectors internally for eight months and has found the operational overhead significant: upstream breaking changes arrive faster than his team can absorb them, the identity stack requires constant attention, and the gap between what the EDC documentation describes and what production actually requires has consumed engineering capacity he cannot afford to dedicate to connector operations indefinitely. He wants the operational expertise of a managed service without surrendering control of where the infrastructure runs.

Goals

Dirk wants Kaphera to manage the platform operator on his organisation’s own infrastructure, handling upgrades, upstream EDC tracking, credential lifecycle, and operational runbooks, while his team retains full control of the underlying compute, network, and data. He wants the source-available licensing to give him the contractual and technical ability to take over operations entirely if the relationship with Kaphera changes, without being locked into a migration project. He wants the connector infrastructure to be integrated into his organisation’s existing observability, RBAC, and GitOps toolchain rather than sitting beside it as a foreign system. And he wants a provider relationship that is genuinely collaborative at the technical level, one where his engineers and Kaphera’s engineers can work together on the platform rather than operating through a support ticket system.

Technology use

Dirk’s organisation runs Kubernetes on private cloud infrastructure, manages secrets with HashiCorp Vault, uses ArgoCD for GitOps deployment, and has built out observability on a self-hosted stack. His engineers are cloud-native and Kubernetes-literate; they are not unfamiliar with operator-pattern infrastructure. What they are not is EDC specialists, and they do not want to become one. Dirk evaluates infrastructure providers by reading their architecture documentation and, where available, their source code. He will not approve a platform dependency whose internals he cannot inspect. He has a formal vendor security assessment process that takes twelve to sixteen weeks and requires ISO 27001 and TISAX certification as baseline inputs.

Needs from Kaphera Cloud

Dirk needs the full Kaphera platform, operator, identity stack, credential management, connector profiles, running on his organisation’s own infrastructure, managed by Kaphera but owned by his team. He needs the source-available licensing to give him a credible exit path: the ability to take over operations without rebuilding from scratch if the commercial relationship changes. He needs the platform to integrate cleanly with his existing Kubernetes environment, his RBAC model, his observability stack, his GitOps deployment pipeline, rather than requiring a parallel operational track. He needs the provider to carry ISO 27001 and TISAX Level 2 certification, and to be able to engage substantively with his security team’s assessment process. He needs a commercial arrangement that includes direct engineering engagement, not just operational support, his team will have architectural questions that a ticketing system cannot answer. And he needs upgrade and change management to be handled by Kaphera transparently, with advance notice and documented rollback procedures, so that his engineers are not surprised by breaking changes in production.

Quote “We’re not looking for someone to host our data. We’re looking for someone who can run our connector platform on our infrastructure, with the expertise we don’t have, without creating a dependency we can’t exit.”

Graph View

Backlinks