Platform engineering as a control plane: Santander’s Catalyst pattern (EKS + Crossplane + GitOps + policy)
A bank reduced provisioning from ~90 days to hours by standardising *claims* and reconciling them into approved stacks. This is the pattern enterprise GenAI platforms need: a governed control plane, not a thousand bespoke pipelines.
KMS ITC
Most platform initiatives fail in one of two ways:
- they become a ticketing system with nicer UX, or
- they become an opinionated platform that teams route around.
Santander’s Catalyst pattern (shared by AWS Architecture Blog this week) is a useful “third way”:
- standardise what teams ask for (claims)
- enforce guardrails as code (policy)
- produce approved stacks (compositions)
- run it all as a control plane (Kubernetes + reconciliation)
The result, per the write-up: provisioning that used to take up to ~90 days drops to hours/minutes, while improving standardisation and governance.
1) The capability jump: from “pipelines everywhere” to a single control plane
What’s architecturally interesting isn’t “they used Kubernetes.”
It’s the operating model implied by this stack:
- Developer portal as the front door (self-service)
- GitOps as the change mechanism (reviewable, versioned)
- Crossplane as the universal provisioner (reconcile desired state)
- OPA/Gatekeeper as the policy substrate (guardrails at admission)
- A stacks catalog (compositions/blueprints) that encode architecture decisions
This combination shifts the centre of gravity from:
- “each team owns pipelines + Terraform + exceptions”
to:
- “the platform owns the contract and the guardrails; teams own the intent.”
2) The architecture implication: claims are the integration boundary
When enterprises say “we need standardisation,” they often mean:
- standardise every service configuration
- mandate one toolchain
- lock down everything centrally
That doesn’t scale.
Catalyst’s core move is to make claims the boundary:
- a team requests a capability (env, database, queue, RAG index, agent stack)
- the platform translates that intent into an approved composition
- the reconciler keeps it aligned over time
This is how you get both:
- velocity (teams request in minutes)
- governance (platform encodes architecture + policy once)
Here’s a reference architecture, simplified:
3) Why this matters for GenAI in particular
Enterprise GenAI doesn’t just add “another workload.”
It adds:
- new data classes (prompts, traces, embeddings)
- new blast radius (model/prompt swaps can change behaviour instantly)
- new controls (PII handling, tool permissions, egress, evaluation gates)
Catalyst’s write-up calls out a GenAI agents stack as an early success case (Bedrock + S3 + KMS + IAM).
That’s the right shape: don’t let every team assemble a bespoke “agent runtime” from scratch.
Instead, publish a golden path that includes:
- identity, network, and encryption defaults
- safe data storage (prompt/trace/embedding separation)
- tool-access boundaries (least privilege)
- observability (latency, token/cost, tool errors)
- release/evaluation gates where appropriate
4) The tradeoffs (what you must design for)
Tradeoff A: your platform becomes a product
A catalog implies you’ll manage:
- versions
- deprecations
- paved-road evolution
- migration paths
If you can’t commit to platform product management, you’ll accumulate “one-off compositions” and lose the benefit.
Tradeoff B: policy is only useful if exceptions are governed
OPA guardrails are great until:
- teams need an exception
- the exception becomes permanent
You need an explicit exception workflow:
- time-bounded exemptions
- audit trails
- periodic recertification
Tradeoff C: Crossplane is powerful — but composition sprawl is real
Crossplane gives you a programmable API surface for infra.
The risk is that your catalog becomes an unowned forest of YAML.
Mitigations:
- treat compositions like code (owners, tests, CI)
- implement “reference stacks” + a small number of variants
- publish capability tiers (bronze/silver/gold) rather than infinite knobs
5) What to do next (a pragmatic 30-day plan)
If you want to apply the Catalyst pattern in your enterprise (even partially):
- Pick one thin slice (e.g., “RAG-ready environment” or “agent stack with safe tool access”).
- Define the claim contract (what teams request; what you promise).
- Encode one composition that provisions the full stack end-to-end.
- Add guardrails (OPA) for the controls you care about most.
- Put it behind a portal and run it via GitOps.
- Measure: lead time, ticket volume, policy violations prevented, and rework avoided.
Do that, and you’ll have something rare: a platform that improves both speed and architecture consistency.
Sources
If you’re building an enterprise platform for cloud + GenAI and want help defining the claim contracts, catalog structure, and guardrails (plus a reference “agent stack” golden path), reach out via /contact — we’ll map it to your operating model and get the first slice shipped.