Meet the digital team of “Nid Heart Network” — a fictional three-city hospital group we will follow for one quarter, because stories teach what checklists only list. Six engineers support appointment portals, lab-result views and internal dashboards across three hospitals. Each city has its own way of doing everything. And this year, leadership asked a question that made the team’s lead, Priya, reach for an idea she had been reading about: PlatformOps, running the group’s shared software machinery as a managed product instead of three private hobbies. Here is the quarter, week by week, with the numbers left in.
Three hospitals, three private toolboxes
Priya’s audit reads like a joke with three punchlines. The Delhi portal deploys through a script only Rahul can run. The Jaipur site has a scheduler built during a monsoon week, undocumented since. The Kochi team maintains a notification service that — unknown to anyone — two other cities have quietly started calling. Every hospital keeps a private stash of deployment lore in chat scrolls and memory. Nothing is broken, exactly. Everything is fragile, expensively, and the cost shows up whenever someone resigns or a release slips before a cardiology camp weekend.
The PlatformOps experiment, week by week
Priya sells leadership a ninety-day experiment, not a transformation. Weeks one to three: she interviews her own consumer teams — the portal group, the labs-data pair, the dashboard duo — and lists every task that recurred across conversations. The list is short and damning: environment setup, release wiring, notification plumbing. Weeks four to eight: the team builds a single paved route — one template, one pipeline, one logging setup — with the Jaipur scheduler’s author as design partner, since he knows where the bodies are buried. Weeks nine to twelve: two hospital teams run the route for real while the team writes the GA package: a runbook, an on-call rota, and a rule that every shared capability names a single owner and states plainly which lifecycle stage it occupies. The reference she kept open through all of it was xOps School’s Ops Atlas PlatformOps page, mostly for the failure stories, which she quotes in standups like parables.
The week the catalog lied (helpfully)
Mid-quarter comes the moment the team still talks about. The new catalog recorded five consumers for the Kochi notification service. A routine reconciliation — comparing declared consumers against actual access-log callers — found seven. Two hospital apps had been depending on the service without telling anyone, in the classic pattern the CNCF’s own worked examples describe. Nothing malicious: the callers simply never knew a registry existed. The team added them, and the deprecation calculus for the old Jaipur scheduler instantly changed, because the blast radius had just doubled. Lesson, now painted on the team wall: a catalog is a claim; access logs are a fact; reconcile the two or the facts will reconcile you.
Error budgets: learning to fail on purpose
The paved route needed a reliability promise, so the team set a modest one — 98 percent availability for the deployment service — and did the arithmetic their reading suggested: at 2,400 requests in a month, a 98 percent objective allows 48 failures before the service is, by its own definition, failing. That reframed every incident debate. Forty-seven wobbles and you are inside budget; forty-nine means fix the machine before shipping features. Inspired by Google’s old practice of deliberately taking Chubby, its lock service, offline in controlled doses, the team rehearsed outages on a quiet Friday — pulled the deployment service, watched consumer teams cope, and fixed the two gaps the drill exposed. Consumers, Priya noted, tested against the objective rather than the brochure.
The first deprecation: retiring the Jaipur scheduler
The quarter’s graduation exercise was a funeral. The old scheduler — beloved, undocumented, load-bearing — was formally deprecated with a date attached. An announcement alone moved nobody, exactly as the literature warns; advisory notices, it turns out, are how organisations pretend to migrate. So Priya staffed the retirement: two sessions where holdouts migrated together, with the design partner answering questions live. Everyone moved in a week. The lifecycle policy earned its keep that month, because the retirement was not an ambush but a stage the whole network had already read about in advance.
What PlatformOps changed, in plain numbers
The quarter’s scoreboard, kept deliberately boring: new service setup dropped from roughly two weeks to two days on the paved route. On-call pages split cleanly — hospitals paged for their apps, the platform pair paged for shared parts. And the duplicated-work tax, previously invisible, now had a number attached, because the template started showing up in metrics. Leadership, who had approved a quiet experiment, renewed it into a second quarter without being asked twice. The team’s lessons generalise beyond healthcare IT:
- Interview consumers before building; the recurring-request list is the requirements document.
- One paved route beats three average ones; breadth can wait for a second quarter.
- Reconcile declared consumers with actual callers, or deprecations will surprise you.
- Publish a reliability target and rehearse failure; a budget nobody has practised against is a rumour.
- Staff every retirement. Notice-plus-date is theatre; people-plus-time is migration.
Two habits from the day job made the whole experiment feel natural, Priya says. Hospitals already live by monitoring — the way advanced heart monitoring technology supports cardiac care — so a dashboard for the deployment service felt like familiar medicine, telemetry first, treatment second. And the GA runbook borrowed its shape from the structured safety guidelines ICUs give patients and families: who is responsible, what happens at each stage, and what to do when values drift. Good platform practice, it turns out, is good clinical discipline wearing a different coat.