Every integration leader eventually reaches the same inflection point. The team has grown from five integration engineers to thirty. Onboarding a new service still requires a sequence of Jira tickets — namespace, topic, queue, secret path — that takes anywhere from two days to two weeks depending on the availability of three different platform teams. Senior engineers are spending 20% of their capacity chasing infra tickets rather than writing integration logic. The answer, the platform team will tell you, is an internal developer platform: a self-service portal where a developer fills in a form and gets a running service skeleton in under 30 minutes.
They are right. But the platform conversation in most banks starts at the wrong level. It starts with tooling — which portal, which scaffolder, which infrastructure provisioner — and skips the organizational questions that determine whether the IDP will succeed or quietly die in 18 months with a sunk cost that nobody wants to report.
An IDP is a product with a product team, a product owner, a roadmap, and users who choose to use it because it is better than the alternative. Everything else is a tooling project that will not reach critical mass.
The question of mandate versus adoption
The first decision a VP needs to make is deceptively simple: will teams use the IDP because it is mandated, or because it is better? The instinct in regulated environments is to mandate — “all new integration services must be onboarded through the IDP by Q3.” The problem with mandates is that they do not distinguish between an IDP that works and one that frustrates. A team that is forced to use a broken scaffolder will comply in letter — they will run the template, get a broken repo, and then manually fix it — and the mandate will look like a success in the metrics while the actual developer experience gets worse.
The better approach is to make the IDP the path of least resistance. The first golden-path template should be the one workflow that is currently the most painful to do manually. When the IDP demonstrably saves developers two days of ticket-filing, they use it without being told to. Then the second template gets used too, and the third. Adoption that builds from genuine utility is self-reinforcing; adoption that relies on mandate collapses when the mandate weakens or the team lead finds a workaround.
What the regulator actually cares about
SAMA’s Technology Risk Management framework does not prescribe how you provision infrastructure, but it is intensely interested in the auditability of what you provision and why. The IDP is, in that framing, an opportunity rather than a risk — if it is built correctly. Every service onboarded through the IDP has a documented owner, a creation event with an audit trail, a set of infrastructure claims that are version-controlled, and a Backstage catalog entry that links to the runbook and the on-call contact.
Contrast that with the current state in most banks: namespaces created by whoever had cluster admin at the time, Kafka topics named by convention rather than policy, secrets stored in a spreadsheet shared among team members. The IDP is an audit artifact generator if you treat it as such. The catalog entry is evidence of ownership. The Crossplane claim is evidence of the infrastructure configuration at creation time. The Tekton pipeline run is evidence of what was tested before the service went to production. That framing is worth making explicit to compliance and risk stakeholders early — an IDP that reduces ticket-filing is a convenience; an IDP that produces an auditable trail is a control.
The team structure question your architecture team will not surface
The most common cause of IDP failure is treating it as a build-and-hand-off project. The platform team gets six months and a budget to build the Backstage instance, the scaffolder templates, and the Crossplane compositions. They launch. Six months later, three of the original five platform engineers have moved to product teams, the Backstage instance is two major versions behind, the golden-path templates reference a Kafka cluster that was decommissioned in a platform upgrade, and nobody is triaging the developer feedback.
An IDP requires a permanent product team: a product owner who sets priorities based on developer NPS and ticket deflection metrics, two or three platform engineers who own the scaffolder templates and Crossplane compositions as a production service, and a relationship with the security team who need to review plugin changes and infrastructure policy updates. The headcount is not large — a team of three to four can support an integration estate of 20–30 teams — but the commitment needs to be permanent, not project-gated. If the team is wound down at the end of the build phase, the IDP will be an abandoned asset within a year.
The build-versus-buy trade-off that most banks get backwards
The tooling decision — which portal, which scaffolder — is usually where these conversations spend most of their time, and it is where the energy is least well spent. The honest answer is that Backstage (or its enterprise distribution, Red Hat Developer Hub) is the correct portal choice for a bank running OpenShift, and that the real build-versus-buy question is elsewhere.
The real question is which parts of the IDP to build yourself and which to adopt as conventions from the broader ecosystem. The scaffolding framework: adopt Backstage, do not build your own. The golden-path templates: build these yourself, because they encode your specific platform conventions, your naming standards, your Vault path structure, your domain classification. The infrastructure compositions: build these yourself in Crossplane, because they encode your security posture, your NetworkPolicy baseline, your Kafka cluster topology. The catalog plugins for ArgoCD status and Tekton pipeline status: adopt community plugins, do not build your own integrations.
The mistake is building the portal when you should be adopting it, and adopting the templates when you should be building them. Teams that build a custom portal spend their capacity on framework maintenance rather than developer experience. Teams that adopt community templates find them too generic to encode the security constraints that SAMA requires — and then they fork them, and then they have a maintenance problem.
For the engineering detail behind these decisions — the Backstage configuration, scaffolder template structure, Crossplane XRD definitions, RBAC and multi-tenancy patterns, and the metrics that tell you whether the IDP is working — see the companion Lab article: Internal Developer Platform for Integration Teams: Backstage, Golden Paths & Scaffolders on OpenShift.