Readers of this site understand something most technology commentary misses: a good outcome depends less on the brilliance of a single procedure than on the quality of the journey around it \u2014 the assessment, the plan, the follow-through, the verification. That belief is exactly what one fictional but faithfully drawn organisation, the Meridian Care Group, carried into its own technical crisis. Meridian runs twelve hospitals across four countries, and its software teams were drowning. The way they applied PlatformOps to climb out reads like a patient journey, which is precisely why it is worth telling here.<\/p>\n
Meridian’s first move was not a purchase. Their newly appointed platform lead, Amara, spent her first month the way a good consultant physician spends a first consult: listening. Five product teams, five structured conversations, one question \u2014 where do your weeks disappear? The pattern that emerged was familiar and corrosive. Every team maintained private build scripts. Two had built matching deployment-approval workflows without either knowing of the other’s existence. Requests for anything shared waited behind a ticket queue measured in days. Amara’s write-up recommended PlatformOps in substance if not in name: run the shared tooling as a managed service with the same seriousness the group applied to clinical services.<\/p>\n
The diagnostic phase produced an inventory \u2014 every shared capability Meridian already operated, each tagged with an owner or, more often, with nobody. The treatment plan followed as a two-page charter built on the thinnest viable platform principle: offer only those shared capabilities that erase work the teams were duplicating, and nothing beyond them. Two commitments went into the document. Adoption would be voluntary \u2014 teams join because the service shortens their work, echoing the CNCF’s position that platforms are optional and composable. And every published capability would carry three attachments from day one:<\/p>\n
The board asked what would happen if teams declined to adopt. Amara’s answer \u2014 then the platform will have failed on its merits and deserves to \u2014 unsettled them into approval.<\/p>\n
Reconstruction began with a single golden path: one template feeding one pipeline, the whole journey from source code to production watched end to end. The design partner was the appointments-booking team, chosen for the same reason surgeons prefer an index case \u2014 a well-understood, low-drama service where complications, if any, would be instructive rather than catastrophic. For a month, the pair worked in tight collaboration, every snag logged and fixed in public. By the end, the booking team’s deployment lead had stopped asking for exceptions. That silence was the first real evidence the path worked. Nothing about the underlying pattern was novel; the novelty lay in refusing to build ten capabilities at once and finishing none of them properly.<\/p>\n
Widening to a two-team beta brought the predictable setback. Delivery metrics sagged for six weeks \u2014 teams migrating, habits rewriting themselves \u2014 and a hospital-group director asked, reasonably, whether the programme was failing. Amara presented the J-curve documented in DORA’s research: performance typically dips during migration, then recovers beyond baseline if operations hold steady. She committed to specific recovery markers rather than vague reassurance, and the programme survived its hardest meeting. During rehabilitation the service levels went public, with attainment reported monthly, and the paging boundary was fixed: application teams answer for their services around the clock, the platform team for its own components under its published tiers.<\/p>\n
General availability at Meridian was deliberately unglamorous. The runbook had been rehearsed against real failures, on-call coverage for platform components was rota-ed, the lifecycle policy from proposal through retirement was published, and \u2014 the step most programmes skip \u2014 one legacy capability was formally withdrawn, with engineers assigned to migrate its remaining users rather than a notice pinned to a portal. Amara had read the field’s guidance on deprecation: passive warnings move almost nobody; assisted moves work. Twelve months on, the group’s numbers read plainly \u2014 first-deployment latency for a freshly created service fell from days to hours, the majority of routine requests fulfilled without any human queue, and service-level attainment reported at board level beside the clinical indicators.<\/p>\n
The closing lesson is the one this site’s readers will appreciate most. Six months after launch, Amara reconciled the platform’s service catalogue \u2014 entries declared by whichever team registered them \u2014 against actual callers found in access logs. A widely shared audit capability claimed five consumer teams; the logs counted seven. Two had quietly wired themselves in without declaring, which meant a breaking change would have blindsided them. Meridian now reconciles quarterly, on the simple principle that declared and actual are different things until verified \u2014 the same principle that makes an accreditation check worth more than a brochure, explored in our guide to checking a hospital’s accreditation abroad<\/a>.<\/p>\n The source discipline itself is documented best in the Ops Atlas write-up of PlatformOps<\/a>, which records the vocabulary, the three-layer architecture and the day-to-day operating habits Meridian followed. And because choosing wisely is the theme under every layer of this story \u2014 for platforms and for patients alike \u2014 the questions worth asking before committing are collected in what to ask before surgery abroad<\/a>, while the value of a structured comparison before any major commitment is argued in how careful hospital comparison protects a surgery journey<\/a>. Verify first, proceed on evidence, and keep following up: it works for care, and it works for code.<\/p>\n","protected":false},"excerpt":{"rendered":" A fictional twelve-hospital network runs its platform programme like a patient journey \u2014 consultation, plan, procedure, rehab, discharge, follow-up.<\/p>\n","protected":false},"author":13,"featured_media":2587,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1557],"tags":[],"class_list":["post-2586","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technology"],"_links":{"self":[{"href":"https:\/\/www.surgeryplanet.com\/blog\/wp-json\/wp\/v2\/posts\/2586","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.surgeryplanet.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.surgeryplanet.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.surgeryplanet.com\/blog\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/www.surgeryplanet.com\/blog\/wp-json\/wp\/v2\/comments?post=2586"}],"version-history":[{"count":1,"href":"https:\/\/www.surgeryplanet.com\/blog\/wp-json\/wp\/v2\/posts\/2586\/revisions"}],"predecessor-version":[{"id":2610,"href":"https:\/\/www.surgeryplanet.com\/blog\/wp-json\/wp\/v2\/posts\/2586\/revisions\/2610"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.surgeryplanet.com\/blog\/wp-json\/wp\/v2\/media\/2587"}],"wp:attachment":[{"href":"https:\/\/www.surgeryplanet.com\/blog\/wp-json\/wp\/v2\/media?parent=2586"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.surgeryplanet.com\/blog\/wp-json\/wp\/v2\/categories?post=2586"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.surgeryplanet.com\/blog\/wp-json\/wp\/v2\/tags?post=2586"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}