CONCEPT Cited by 1 source
Platform team vs application team split¶
Definition¶
An explicit organisational boundary where platform engineers own how a capability runs (storage, engine, telemetry, bundle distribution, SLOs) and application engineers own what the capability expresses (policies, schemas, business rules). The seam between the two halves is usually a narrow declarative contract: an annotation, an identifier, a small config object.
This is a specialisation of the general concepts/developer-platform-over-bare-substrate axis applied to a single capability (authorization, observability, routing, persistence) rather than the whole platform.
Why the split is load-bearing¶
- Minimises surface area for app teams. Adopting a capability becomes "declare that I want it" rather than "learn and operate a new piece of infrastructure".
- Concentrates operational expertise. One team owning every instance of the capability accumulates runbook knowledge, incident experience, and bundle / version / migration discipline.
- Aligns responsibility with blast radius. Platform owns the things whose failure affects the fleet; apps own the things whose failure is scoped to their own feature.
- Produces as-a-service -style shapes. Any capability framed as "X as a service" has this split at its core.
The seam¶
The seam is almost always a narrow declarative handoff:
- An annotation (e.g.
opaAuthorizeRequest("my-application")). - A registered identifier (application ID, bundle name, schema ID).
- A label / selector that resolves to platform-side config.
On one side of the seam the platform commits to a specific contract ("I will evaluate policies named X against every request matching routes Y"); on the other side the application commits to the narrow artifact ("I maintain a valid Rego bundle named X in my Git repo").
Seen in¶
- sources/2024-12-05-zalando-open-policy-agent-in-skipper-ingress — Zalando makes this split explicit as a goal: "Clear Responsibility Split: The integration allows a clear delineation of responsibilities: platform teams manage the core authorization infrastructure while application teams focus on application- specific policies, ensuring efficiency and security." The seam is the Skipper filter name + application-ID parameter: platform owns OPA embedding, bundle source (S3), telemetry (Lightstep), and virtual-instance lifecycle; app teams own Rego + what paths to protect.
Related¶
- concepts/authorization-as-a-service — the user-facing shape
- concepts/externalised-authorization — the architectural move this split enables for authorization specifically
- concepts/developer-platform-over-bare-substrate — the platform-engineering generalisation
- concepts/conways-law — the org-structure analogue
- patterns/ingress-layer-authorization-offload
- patterns/embedded-opa-in-proxy