Services

Platform Operating Model

Team boundaries, golden paths, governance, and adoption criteria for internal platforms.

Platform Operating Model

A platform operating model explains how a team turns shared infrastructure into a reliable product for developers. It should clarify who owns the platform, which workflows are paved roads, how exceptions are approved, and how reliability, cost, security, and adoption are measured.

Use this guide when starting a platform team, formalizing DevOps/SRE retainers, or deciding whether Assistance should operate parts of your delivery platform.

Decision criteria#

QuestionGood signalRisk signal
Is there repeated delivery friction?Multiple teams need the same deployment, secrets, CI, observability, or environment workflow.Every team needs unique tooling and no common path exists.
Can ownership be explicit?Platform, application, security, and business owners are named for each capability.Incidents bounce between teams because nobody owns the shared layer.
Can the platform be consumed as a product?Developers get documented workflows, templates, support channels, and change notices.Platform changes are tribal knowledge or private scripts.
Are guardrails preferable to tickets?Security, policy, and cost controls can be encoded in templates and automation.Every exception requires manual approval with no feedback loop.

Reference architecture#

1
Developer teams
2
  -> Golden paths: app template, CI workflow, IaC module, deployment workflow
3
  -> Platform APIs: identity, secrets, DNS, certificates, observability, environments
4
  -> Runtime platforms: Kubernetes, managed databases, runners, cloud accounts
5
  -> Operating loop: SLOs, incident review, cost review, roadmap, enablement

Keep the first version small. A useful platform can begin with one supported application template, one deployment path, one environment model, and clear escalation ownership.

Operating model checklist#

  • Define platform customers: product teams, data teams, security, operations, or external tenants.
  • Publish a service catalog with supported workflows, maturity level, and support expectations.
  • Create golden paths for the most common app types and explicitly label experimental paths.
  • Document ownership boundaries for application code, infrastructure, data, secrets, and incidents.
  • Establish intake and exception handling for workloads that do not fit the default path.
  • Track adoption, deployment lead time, change failure rate, incident load, cost, and developer feedback.
  • Review the platform roadmap with engineering leadership at a fixed cadence.

Governance without slowing teams#

Platform governance works best when controls are built into the normal workflow:

  • policy-as-code for required tags, regions, encryption, network exposure, and image provenance;
  • CI checks for tests, security scanning, dependency review, and artifact publication;
  • templates that include observability, rollback, runbooks, and ownership metadata by default;
  • exception records with expiry dates and accountable owners;
  • dashboards that show adoption, reliability, cost, and risk trends.

Assistance engagement fit#

NeedAssistance path
Define the platform product, team model, and roadmapTechnology Consulting
Build cloud foundations, IaC, or landing zonesCloud Infrastructure
Operate Kubernetes and runtime guardrailsManaged Kubernetes
Improve release flow and delivery ownershipDevOps as a Service
Formalize reliability practice and incident responseSRE as a Service

Evidence to collect#

  • current delivery value stream and repeated developer blockers;
  • current tool inventory and ownership map;
  • platform service catalog draft;
  • golden-path backlog and retirement list for unsupported paths;
  • quarterly scorecard covering reliability, cost, delivery, security, and adoption.

30-60-90 day rollout#

WindowOutcomePractical deliverables
0-30 daysDiscover the platform product.Stakeholder map, top developer journeys, ownership matrix, current-state risk register, and first scorecard baseline.
31-60 daysProve one golden path.App template, CI/CD workflow, environment promotion path, observability defaults, support channel, and exception process.
61-90 daysExpand with governance.Service catalog entries, policy-as-code checks, adoption dashboard, recurring platform review, and retirement plan for unsafe paths.

Keep adoption voluntary until the first golden path is demonstrably easier than custom work. Mandate guardrails only after teams have a supported migration route.

Before expanding scope, publish the support promise for the golden path: response hours, escalation channel, ownership of template defects, and the process for requesting new capabilities.

References#