The Tata Internal Developer Platform is the London Engineering Centre of Excellence's flagship product: a service provider-grade IDP that maps the deep, multi-tiered structure of a global enterprise onto a single, opinionated paved road - and ships it both inside Tata and to the clients we serve. It is built on open, AI-enabled, cloud-native foundations and on the wider cloud native ecosystem, drawing on cloud, DevOps, IoT, and automation patterns proven at scale.
Most IDPs are built for a single product team and stretched, painfully, to cover the rest of the business. Ours starts at the other end: an organisation with hundreds of thousands of engineers, deep multi-tiered hierarchies, and a client portfolio that pays close attention to audit, residency, and isolation. That changes every architectural decision underneath - and it changes who the platform is allowed to feel sluggish to (no one).
Group, business unit, account, sub-account, project, team, environment - the platform's logical boundaries mirror the real shape of the business. Move a team between business units and its golden paths, quotas, and policies follow it.
Compute, network, and data isolation between business units and client projects is the default, not a configuration option. Workload identity, namespace boundaries, network policy, and storage all derive from the same tenant model.
Fine-grained role and attribute-based access control, expressed as code and version-controlled with the rest of the platform. Every action that needs an auditor's signature comes with an audit trail an auditor will actually read.
An AI-enabled collaboration suite sits at the top of the platform with an infrastructure-as-design surface that enables architects, platform engineers, security teams, and developers to model, govern, deploy, and continuously reconcile cloud and cloud-native components across a long tail of technologies. Acting as a common control plane for design, operations, and lifecycle management, it provides a shared system of record for platform architecture and application topology.
Beneath it, we layer the developer experience surface (GitLab-integrated), providing source control, CI/CD, GitOps workflows, artifact management, and self-service platform capabilities. This developer layer abstracts infrastructure complexity while maintaining consistency, security, and operational guardrails.
The platform services layer is composed of a set of cloud native building blocks that provide observability, security, networking, and application delivery capabilities.These capabilities are complemented by policy enforcement, secrets management, service discovery, traffic management, and platform observability services that enable secure and reliable application operations at scale.
This runtime fabric operates consistently across hybrid and multi-cloud infrastructure environments including Google Cloud Platform (GCP), Microsoft Azure, and Amazon Web Services (AWS), enabling workload portability, centralized governance, and operational consistency while supporting diverse deployment models ranging from traditional microservices to cloud-native and AI-enabled workloads.
The platform was built first for our own engineers and the way Tata actually delivers projects. That gave it the maturity to be packaged - on the same architecture, with the same SLOs - for clients who want a Tata-grade IDP without standing up the team to build one.
A single, opinionated paved road that scales from a two-person team on a proof of concept to a 2,000-person account programme.
A productised IDP we deliver as part of strategic engagements, or stand up on a client's own infrastructure with their own tenancy boundaries.
A platform of this scale only earns its budget if its impact is visible at the group P&L line. Ours does - by collapsing the cost of starting an engagement, removing whole categories of compliance toil, and giving clients a story they can buy at the board level.
The London CoE platform team is a tight group of platform engineers, infrastructure architects, and design-minded developers - many of them long-time contributors to the developer community. The mix is deliberate: most platforms feel like a back-office tool because they are written by people who never have to use them. Ours is written by people who refuse to ship something they would not put on their own laptop.
The team grew up untangling monolithic estates and standing up early cloud platforms. That experience shows up as a low tolerance for one-off scripts, hidden state, and clusters nobody owns.
Unlike most infrastructure teams, ours treats UI, typography, and design systems as first-class concerns. Internal tools should be as beautiful and intuitive as the consumer products developers use the rest of their day.
When the team needs a capability the wider ecosystem lacks, it contributes upstream rather than forking in private. That keeps the platform honest, keeps the costs of maintenance shared, and keeps clients out of vendor cul-de-sacs.
The platform's competitive edge does not come from secrecy. It comes from being one of the most active enterprise contributors to the cloud-native projects underneath - so we know how the ecosystem will evolve, and so the wider community gets to benefit from the problems we have to solve at Tata's scale.
Our team is a core contributor to the AI-enabled, design-led collaboration suite that anchors the platform. Heavy use of Go and TypeScript, with a particular focus on the model that lets one control plane manage cloud-native components (Kubernetes, serverless) across many tenants.
We contribute meaningfully to the operators that manage the lifecycle of the collaboration suite on container orchestrators like Kubernetes and - the same operators that run in production across every cluster the IDP supervises, in both Tata and client environments.
A Helm-aware tool for capturing and visualising the state of a release - the kind of see-what-you-shipped capability we needed in production and decided to build in the open rather than as an internal-only utility.
The platform is opinionated, not exotic. Every component is something a cloud native practitioner will already recognise - so a new engineer (or a client team taking ownership) ramps up in days, not quarters.
Infrastructure should empower developers, not block them. A platform is only as good as the day-to-day it gives the people who depend on it - which means the platform team is, finally, just another product team.The Platform team - London Engineering Centre of Excellence
