{"id":3341,"date":"2026-10-20T16:45:00","date_gmt":"2026-10-20T16:45:00","guid":{"rendered":"https:\/\/www.bestheartsurgery.com\/blog\/?p=3341"},"modified":"2026-10-20T16:45:00","modified_gmt":"2026-10-20T16:45:00","slug":"platformops-audit-hospital-it","status":"publish","type":"post","link":"https:\/\/www.bestheartsurgery.com\/blog\/platformops-audit-hospital-it\/","title":{"rendered":"PlatformOps Audit: A Checklist for Hospital IT Teams"},"content":{"rendered":"

Anyone who has stood in a theatre while a surgical checklist gets read aloud knows the peculiar comfort of it: the room slows down, each item gets a spoken confirmation, and gaps surface before a single incision is made. Most hospital IT departments never give their internal tooling that same courtesy. PlatformOps is the discipline that fixes this \u2014 running an internal developer platform the way a good clinical service is run, with named owners, published service levels, planned upgrades, and honest retirement dates. If you cannot say who supports what on your estate, this audit is overdue.<\/p>\n

PlatformOps in One Paragraph Before We Begin<\/h2>\n

Platform engineering grabs the headlines, yet PlatformOps is the operating half of it: treating the internal developer platform as a product with real customers rather than a pile of servers someone installed years ago and quietly forgot. The Cloud Native Computing Foundation describes platforms as optional and composable, which sounds gentle until you absorb the implication \u2014 nobody is obliged to use yours, and they will route around it the moment it feels like paperwork. Teams that get this right publish support tiers, keep lifecycle labels current, and accept that adoption has to be pulled by willing users instead of pushed out by memo.<\/p>\n

The Ten-Question PlatformOps Audit<\/h2>\n

Pull a whiteboard, bring whoever actually runs your developer tooling, and work through these. Score one point for each honest yes \u2014 no generous marking.<\/p>\n

    \n
  1. Can every shared tool name one accountable owner \u2014 a person, never a mailing list?<\/li>\n
  2. Does each capability carry a lifecycle label (Proposed, Alpha, Beta, GA, Deprecated, Retired) that somebody genuinely maintains?<\/li>\n
  3. Is there a published service level for the platform, and do you actually track attainment against it?<\/li>\n
  4. When the platform fails at 2 a.m., who gets paged \u2014 the platform team, or whichever application team happens to be awake?<\/li>\n
  5. Do developers use the platform because it is the quickest route to production, or because a policy told them to?<\/li>\n
  6. Can a team step off the paved route without seeking permission, accepting only the loss of guaranteed support?<\/li>\n
  7. Do you know how many services truly consume each capability \u2014 from access logs, not from a wiki page last edited in another fiscal year?<\/li>\n
  8. Has anything ever been formally deprecated, with notice, migration help, and a real switch-off date?<\/li>\n
  9. Are you running the thinnest viable version of each capability, or has accreted complexity outlived its users?<\/li>\n
  10. Can a brand-new developer reach their first successful deployment inside a day, unaided?<\/li>\n<\/ol>\n

    Reading the Score Without Flinching<\/h2>\n

    Seven or more yeses means you are genuinely running a product. Four to six points to a serviceable setup drifting toward neglect. Below four, the honest description is a renamed operations queue \u2014 precisely the pattern Thoughtworks cautions about, where a team reprints its org chart with the word “platform” on it and nothing about how work actually flows. A low score is not shameful; concealing it is.<\/p>\n

    Questions three and seven deserve a worked example, because they catch out even experienced teams. Suppose you publish a 98 percent availability objective and the platform handled 2,400 requests last month: the arithmetic grants you 48 failures before the objective is breached. That budget is only meaningful if somebody reviews it monthly, the way a ward round reviews observation charts. Question seven bites harder. Catalog entries are self-declared by whoever registered the service, so reconcile them against real callers in the access logs. In one documented exercise, a capability claimed five consumers and the logs showed seven \u2014 the two undeclared teams only surfaced when a breaking change went out.<\/p>\n

    Two failure patterns appear in nearly every poor-scoring review. Ticket-ops comes first: every request becomes a queue entry, developers sit waiting days for things they could have safely done themselves, and the platform team drowns in toil of its own design. Launch-and-leave comes second: a triumphant release, a well-attended demo, then silence \u2014 no roadmap conversations, no deprecations, no measurement. No cardiac unit would discharge a patient with zero follow-up and call it care. Recovery is where value is created, which is why structured cardiac rehabilitation<\/a> outperforms surgery alone; platforms behave in exactly the same way.<\/p>\n

    From Audit to Ninety-Day Plan<\/h2>\n

    When the score comes back low, resist the urge to rebuild everything at once. The sequence that works is deliberately dull:<\/p>\n