Dirk · BYOC after a knowledge-concentration scare
A VP of Data & Platform Engineering at a large automotive OEM is hit by a knowledge-concentration risk when his most senior EDC engineer resigns. His infrastructure policy forbids third-party cloud, so he procures a BYOC arrangement: Kaphera operates the platform on his own private Kubernetes cluster, with a documented exit path he can take over independently.
Scenario
Dirk is VP of Data & Platform Engineering at a large automotive OEM with 45,000 employees and a private cloud running on dedicated hardware across two German data centres. His team of forty engineers covers platform infrastructure, data infrastructure, and internal developer tooling. Eight months ago they began self-hosting EDC Connectors, one for the company’s Catena-X participation, one for an internal dataspace the company operates for its tier-1 supplier network. The connectors are running. The operational reality is not what anyone planned for.
Upstream EDC breaking changes have arrived three times in eight months. Each one required two to three days of engineering time to absorb across both deployments. The identity stack, IdentityHub, CredentialIssuer, Vault integration, requires continuous attention from one engineer who has developed the deepest knowledge of it on the team. Three weeks ago, that engineer accepted an offer from another company. He leaves in thirty days. Dirk has assessed the knowledge transfer documentation the engineer has produced and concluded it is insufficient to make someone else equally effective in under three months. The CTO has asked Dirk to present a plan for how the company manages EDC operational expertise going forward without concentrating it in a single person who can leave.
The company’s infrastructure policy is absolute: no production data infrastructure runs on a third-party cloud. The answer is not a managed cloud service. The answer is finding someone who can manage the operational expertise on Dirk’s own infrastructure.
Storyline
Step 1: The knowledge concentration risk surfaces
Action
Dirk writes a risk assessment for the CTO covering the EDC operational dependency: one engineer holds the effective working knowledge of the identity stack, the connector lifecycle, and the upstream EDC change management process. The documentation that exists is insufficient to transfer that knowledge in thirty days. The options Dirk presents are three: accelerate internal knowledge transfer and accept six months of elevated operational risk, hire a replacement with EDC-specific expertise in a market where that expertise is scarce, or find an external operator who can manage the platform on the company’s own infrastructure under a formal operational agreement. He recommends the third option. The CTO approves the evaluation.
Thoughts
“The knowledge concentration risk was always there. The engineer leaving is not the cause, it is the event that made the risk visible. If I fix this by hiring another engineer with the same knowledge profile, I have not fixed the risk. I have reset the clock.”
Emotions
Clear-headed and unsentimental. Dirk has managed enough infrastructure teams to know that knowledge concentration in a single person is a structural problem, not a personnel problem. He is not looking for a replacement. He is looking for a different model.
Step 2: Defining what BYOC actually means for this organisation
Action
Dirk writes a requirements document for the external operator arrangement. The infrastructure stays on the company’s private cloud, non-negotiable. The operator manages the Kaphera platform components: the EDC operator, the identity stack, the connector lifecycle, and the upstream EDC change management. Dirk’s team retains full access to the underlying compute, network, and data at all times. The source-available licensing must give the company the contractual and technical ability to take over operations independently if the arrangement ends, without being dependent on a migration project. The operator must be able to integrate with the company’s existing observability stack, RBAC model, and ArgoCD deployment pipeline rather than sitting beside them as a parallel system. TISAX Level 2 certification is the minimum compliance baseline. The operator must be able to engage substantively at the engineering level, not through a support ticket system, when the company’s engineers have architectural questions.
Thoughts
“The exit path clause is the one most operators will push back on. If they are not willing to commit to source-available terms that give us the ability to take over independently, they are not confident enough in their own platform to trust with our infrastructure.”
Emotions
Precise and non-negotiable on the things that matter. Dirk knows exactly what he needs. The requirements document is not a wishlist, it is the contract he will sign or not sign.
Step 3: Evaluating Kaphera: reading the source before the briefing
Action
Dirk’s engineering lead reads the Kaphera EDC operator source code and the platform architecture documentation before the first commercial conversation. He produces a four-page internal technical assessment covering the operator’s reconciliation model, the controller boundary design, the identity stack integration, and the multi-tenant data plane architecture. His conclusion: the architecture is clean, the controller boundaries follow a clear single-responsibility model, and the Rust implementation gives him confidence in the memory safety and concurrency properties relevant to multi-tenant connector infrastructure. He recommends proceeding to a technical briefing. Dirk schedules the briefing and sends the engineering lead’s assessment to Kaphera’s team in advance, with a note that the technical session should assume this level of familiarity with the codebase.
Thoughts
“Sending the assessment in advance serves two purposes. It tells Kaphera that we have read the code and will ask real questions. And it tells me immediately whether they are the kind of team who reads what their counterpart sends before a meeting.”
Emotions
Deliberate and testing. Dirk is evaluating the Kaphera team’s technical depth and their attention to the relationship as much as the platform itself. The advance assessment is a probe as much as a courtesy.
Step 4: Technical briefing: engineering depth on both sides
Action
The technical briefing runs three hours. Dirk’s engineering lead leads the session on his side. He asks specific questions about the trust boundary handling in multi-tenant deployments, the operator’s behaviour under network partition, and the process for absorbing upstream EDC breaking changes without surfacing disruption to connector operations. He asks to see the upgrade runbook for a breaking change scenario. Kaphera’s engineer walks through a real example from a recent upstream EDC version bump, what changed, how the operator abstracted it, what the connector operator saw. Dirk’s engineering lead takes notes. At the end of the session he tells Dirk it is the first technical briefing in this evaluation where the counterpart clearly understood every question he asked.
Thoughts
“Three hours and not a single question that was deflected to a product manager or a follow-up email. That is the team I want managing infrastructure on my cluster.”
Emotions
Genuinely impressed and ready to move to the commercial conversation. The technical depth Kaphera demonstrated in the briefing is the signal Dirk was looking for. Everything else in the evaluation is now a matter of terms.
Step 5: Compliance assessment: TISAX and the company’s internal security standards
Action
Dirk submits the Kaphera platform architecture documentation, the operator source code, and the ISO 27001 certification to the company’s information security team for a formal assessment. The assessment runs in parallel with the commercial negotiation, Dirk has learned from previous procurements that running them sequentially doubles the timeline. The security team returns two findings after six weeks: one requesting additional documentation on the secrets rotation policy in the Vault integration, one requesting clarification on the operator’s permission model for cross-namespace resource access. Both are addressed by Kaphera’s engineering team with detailed written responses within four days. The security assessment is closed. TISAX Level 2 is confirmed as meeting the company’s current automotive compliance baseline.
Thoughts
“Four days for detailed written responses to two architectural questions. That response time from an engineering team, not a documentation team, tells me more about how they will operate on our infrastructure than any SLA commitment.”
Emotions
Satisfied with the process and increasingly confident in the operational relationship. The security findings were legitimate questions that deserved proper answers, and they received them. Dirk notes the four-day response as a data point he will return to when the operational relationship is under stress.
Step 6: Negotiating the BYOC arrangement: engineering engagement, not support tickets
Action
Dirk negotiates three terms that are not standard in the operator’s commercial model. First, a direct engineering engagement clause: his team has the right to a regular technical sync with Kaphera’s engineers, not the support team, to discuss platform evolution, upcoming upstream changes, and architectural questions. Second, an advance notification commitment: Kaphera commits to a minimum two-week notice period for any upstream EDC change that affects connector behaviour, with a written impact assessment before the change is applied. Third, a full operational handback procedure: a documented process for transferring full operational responsibility to Dirk’s team within thirty days if the commercial relationship ends, using only the source-available code and the documentation Kaphera maintains as standard practice. All three terms are agreed. Dirk countersigns.
Thoughts
“The handback procedure clause is the one that cost me the most negotiating capital. It is also the one I was least willing to drop. A BYOC arrangement without a credible exit path is not a BYOC arrangement, it is a managed service with extra steps.”
Emotions
Settled and professionally confident. Dirk has negotiated complex infrastructure contracts before. This one is cleaner than most because the requirements were specific from the start. He did not negotiate from a wishlist; he negotiated from a requirements document he wrote eight weeks ago.
Step 7: Migration from self-hosted to BYOC: continuity is the constraint
Action
Dirk’s engineering lead and a Kaphera engineer jointly plan the migration from the self-hosted EDC deployments to the BYOC-managed platform. The constraint is absolute: both connectors, the Catena-X participation and the internal supplier dataspace, must remain operational throughout the migration with no service interruption to participants. They agree a parallel-run approach: the Kaphera-managed platform is deployed alongside the existing self-hosted deployment, validated against it for four weeks, and the cutover is a DNS switch with a tested rollback that reverts within five minutes if needed. The four-week parallel run also serves as the knowledge transfer period, the departing engineer participates in two joint sessions during his notice period, transferring operational context directly to Kaphera’s team rather than into documentation alone.
Thoughts
“Having the departing engineer transfer knowledge directly to Kaphera’s team rather than into a runbook is the right approach. Documentation captures what someone knew. A joint session transfers how they thought about it.”
Emotions
Operationally precise and slightly relieved. The departing engineer’s notice period, which was the catalyst for the entire procurement, has become an asset in the migration plan. The knowledge leaves the company in the most useful form it could, directly to the team that will need to act on it.
Step 8: BYOC steady-state: Kaphera manages, Dirk’s team retains control
Action
Six weeks after the cutover, the BYOC arrangement is in steady state. Kaphera’s team manages the operator on Dirk’s private cloud infrastructure: handling the connector lifecycle, absorbing a minor upstream EDC version bump with two weeks’ advance notice and no service interruption, and rotating certificates automatically on schedule. Dirk’s team retains full access to the underlying cluster, monitors the platform through their existing observability stack, the Kaphera operator emits metrics and logs in the format their Prometheus and Grafana setup expects, and participates in a monthly technical sync with Kaphera’s engineering team. The engineer who left has been replaced, but not with an EDC specialist. Dirk hired a platform generalist. The EDC operational expertise now lives with Kaphera’s team.
Thoughts
“The upstream version bump came and went in two weeks without my team touching anything. That is the event I was designing this arrangement around when I started the procurement. It happened exactly as planned.”
Emotions
Operationally confident and quietly validated. The upstream version bump was the test case Dirk had been waiting for since the migration completed. Its clean resolution is the proof that the BYOC arrangement is working as designed.
Step 9: Engineering capacity redirected to the internal supplier dataspace
Action
With the EDC operational overhead absorbed by Kaphera, Dirk’s team redirects the engineering capacity that had been allocated to connector maintenance toward the internal supplier dataspace’s application layer, the use-case-specific integrations that sit on top of the connector infrastructure and represent the actual value the dataspace creates for the company’s supplier network. In the three months following the BYOC migration, the team ships two new use-case integrations that had been on the roadmap for six months but could not progress while connector operations were consuming the available engineering time. Dirk presents both at the company’s quarterly technology review. The CTO notes that the BYOC arrangement has produced more visible output in three months than the internal connector operation produced in eight.
Thoughts
“Two use-case integrations in three months versus eight months of operational maintenance that produced nothing visible to the business. That comparison is not fair to the engineering work that went into the operational period, that work was necessary. But the CTO is not wrong about the output.”
Emotions
Satisfied and clear on the strategic argument. The BYOC arrangement was justified on risk management grounds, the knowledge concentration problem. The engineering capacity recovery is the dividend that was always implied but never promised. Having it materialise in a form visible to the CTO makes the next procurement conversation easier.
Step 10: Dirk shapes the BYOC model for the industry
Action
Dirk presents the BYOC operational model at an internal technology leadership forum attended by IT and platform engineering leaders from the company’s joint ventures and major subsidiaries. Two subsidiary CTOs ask for introductions to Kaphera. He also contributes a formal feedback document to Kaphera covering three platform improvements that would reduce the operational surface area for BYOC customers: a structured upstream change impact assessment format, a BYOC-specific observability integration guide, and a recommendation to formalise the handback procedure documentation as a standard deliverable rather than a negotiated term. All three are accepted as roadmap items.
Thoughts
“The handback procedure should be a standard deliverable, not something a customer has to negotiate for. If Kaphera is confident in their platform and their relationship with customers, they should offer the exit path without being asked.”
Emotions
Invested and genuinely collaborative. Dirk’s feedback is not a complaint, it is the contribution of someone who has run the arrangement and can see clearly what would make it better for the next customer. The distinction between a vendor relationship and a genuine platform partnership is that the customer’s operational experience flows back into the product.
Key features
🏠 BYOC operator deployment on private cloud infrastructure: full platform deployment on the customer’s own Kubernetes cluster, with Kaphera managing the operator and the customer retaining ownership of compute, network, and data at all times
📤 Source-available exit path with documented handback procedure: formal operational handback process documented as a standard deliverable, enabling the customer to take over full operational responsibility within thirty days using only source-available code and standard documentation
🔧 Direct engineering engagement: regular technical sync between the customer’s platform engineers and Kaphera’s engineering team, not mediated through a support function, covering platform evolution, upstream changes, and architectural questions
🔔 Two-week upstream change advance notification with impact assessment: formal notice period for any upstream EDC change affecting connector behaviour, with a written impact assessment provided before the change is applied to the customer’s deployment
📊 Observability integration with existing customer stack: operator metrics and logs emitted in formats compatible with the customer’s existing Prometheus, Grafana, and alerting infrastructure without requiring a parallel observability deployment
🔐 TISAX Level 2 compliance documentation for automotive security assessments: architecture documentation, secrets management detail, and permission model documentation structured for submission to automotive-sector security assessors
🔄 Parallel-run migration with five-minute rollback: migration path from self-hosted to BYOC using a parallel deployment validated over four weeks, with a DNS-based cutover and a tested rollback procedure that reverts within five minutes
🤝 Knowledge transfer to operator during migration: structured joint sessions between the departing customer engineer and Kaphera’s operational team during the migration window, transferring working context directly rather than through documentation alone
Related
- dirk-wassermann: the protagonist: VP of Data & Platform Engineering at an automotive OEM with an absolute on-premise policy
- participant: the archetype: dataspace participants, here in the BYOC sub-pattern (own infrastructure, vendor expertise)
- kaphera-edc-operator: the Apache 2.0 operator that manages the EDC connector lifecycle on Dirk’s private cluster
- kaphera-cloud-operator: the source-available operator managing the platform infrastructure layer (PostgreSQL, Vault, NATS, Keycloak) on his cluster
- participant-playbook: sales motion for the participant archetype, including the BYOC operating model