Building the data centre behind two Mumbai Metro lines

The programme

Line 2B runs 23.6 km across 22 stations, from D.N. Nagar through Bandra to Mandale, tying Mumbai’s western suburbs to the eastern seaboard. Line 7A is short and disproportionately important — a 3.17 km underground extension from Gundavali into Terminal 2 of Chhatrapati Shivaji Maharaj International Airport, removing roughly an hour of surface journey for passengers coming from Mira-Bhayandar and the western suburbs.

I worked on both from the contractor side. My remit was the data centre.

Why a construction programme needs one

This is the part that surprises people who assume infrastructure work is concrete and steel. A metro corridor is, administratively, one of the most document-intensive things a city builds.

Design drawings are revised continuously and every revision must be retrievable years later. Survey data, geotechnical records, structural calculations, procurement, contractor submissions, quality and safety records, progress reporting to the authority — all of it accumulates across a programme that runs for the better part of a decade, and much of it has to survive audit long after the people who created it have moved on.

That produces requirements ordinary corporate IT rarely faces:

• Retention measured in decades, not backup cycles. The record has to outlive the project, the hardware, and often the vendor.
• Version integrity as a safety matter. Building to a superseded drawing is not a data-quality problem. It is a structural one.
• Many organisations, one system. Authority, contractors, consultants and subcontractors all need access, on different terms, with the boundaries actually enforced.
• No graceful degradation. Site work does not pause because a server is down. Downtime converts directly into idle crews and slipped programme dates.

What “the entire data centre” meant

Building one from nothing is a different discipline from running one that already exists. There is no incumbent configuration to inherit, and no prior decisions to hide behind — every layer is a choice, and the choices compound.

The full stack of that build:

• Siting, power and cooling — the physical envelope, and the redundancy design that determines what actually happens when utility power fails.
• Compute and storage — capacity planned against a programme whose data volume grows for years rather than plateauing after go-live.
• Virtualization — consolidating workloads so that capacity is a pool rather than a set of stranded boxes.
• Network — the fabric inside, and the links out to sites and offices.
• Backup and disaster recovery — the part that only matters once, and matters absolutely.
• Security and access control, physical and logical, across multiple organisations working in the same facility.

Why it belongs in this record

Everything else in this portfolio is enterprise IT inside a commercial business, where the clock speed is quarters and the worst case is a wrong report or an afternoon of lost billing.

Public infrastructure is not that. The timelines are longer, the stakeholders include a state authority, the requirements are set by regulation before they are set by convenience, and the decisions are not reversible. Having built the systems backbone for a programme like that — and then gone on to run enterprise applications for franchise retail, travel and hospitality — is a materially different claim from having done five variations of the same job.

It is also the clearest evidence that the enterprise architecture work came after the hands-on work, rather than instead of it.