Define a platform path with a support contract

TL;DR: Start a platform with one supported path to a working service, and define who owns failures before expanding the catalog.

Where you are. Begin the advanced platform course after reliability. You will apply familiar identity, delivery and incident boundaries to shared infrastructure.

Choose a workflow worth supporting

Parcel's organisation has several teams repeatedly creating service repositories, deployment configuration and dashboards. A portal can collect those steps, but a form submission is not the outcome. The useful outcome is a service that deploys through an approved pipeline, exposes the required signals and has an owner who can respond when it fails.

Choose one common workflow first. For the exercise, support a stateless HTTP service with a managed database connection. State what is excluded, such as privileged node agents or unusual hardware. A narrow, reliable path can reduce repeated work without pretending every workload fits one template.

Write the ownership boundary

The CNCF Platforms White Paper describes platforms as products for internal users. The ownership split here is a proposed exercise contract, not a universal organisational rule.

Measure completion and friction

Track time from a valid request to a usable deployment, including manual approvals and failed attempts. Count how often developers leave the supported path and why. A high portal click count can coexist with slow delivery if each request waits three days for a permission ticket.

In the fixture, automation takes ten minutes but approval waits two days. Optimising the generator to five minutes saves little total elapsed time. Investigate the approval boundary: can low-risk requests be pre-authorised under a policy, while exceptions retain review? Preserve the underlying control rather than deleting it to improve a metric.

Make adoption evidence specific

Ask developers to perform the workflow and observe where they get stuck. Do not infer satisfaction from compulsory usage. Keep failure reports attached to template versions and service types, then use that evidence to prioritise improvements.

In a platform interview, explain the first supported user outcome and the support promise. A list of portal plugins says what can be installed; it does not establish who will keep the resulting services operable when those plugins change.

Follow a failed provisioning request through ownership

Suppose the exercise portal creates the repository and database, then fails while binding the service identity. The developer retries. If the workflow creates another database each time, the platform has made recovery the developer's problem even though the failed step belongs to its supported path.

Give the request a durable operation identifier and record completed resources against it. A retry should inspect those resources and continue only the missing work, with explicit handling for conflicting state. Do not call the workflow successful until the deployed service can perform its permitted database operation and its responder is discoverable. A green pipeline that cannot authenticate to its database has not met this contract.

The support record should distinguish an application query failure from a broken identity binding generated by the platform. For the latter, the platform owner investigates the template revision and affected requests. The application owner still provides enough request context to reproduce the failure without sharing credentials. This division makes escalation actionable.

Measure the original request through recovery as one workflow. Resetting the start time on every retry would hide the developer's actual wait. Keep abandoned requests visible too: successful completions alone exclude the people who gave up.

Do this before moving on

Write a one-paragraph support contract for the stateless-service path. Include one excluded workload, one developer-owned responsibility and one measure of usable completion. Then identify the bottleneck in the ten-minute automation/two-day approval fixture.

Expected: the approval wait dominates elapsed time. A proposed improvement must preserve the purpose of its control. Pass when the contract names both owners and an outcome beyond creating a repository or clicking a portal button.

Go deeper

• Platform product model develops measures of adoption and useful outcomes for developers.
• Delivery measures helps assess whether the path reduces rework.
• Identity boundaries keeps self-service permissions explicit and reviewable.

Key takeaways

• Support one complete workflow before widening the catalog.
• Name platform and application ownership separately.
• Measure usable completion and waiting time.

Check yourself

Say it before you reveal it. Pulling the answer out of your own head is what fixes it. Nodding along to someone else's does nothing.

1. 1Ten-minute automation plus two-day approval is mainly constrained by:

   Generator speedApproval waiting timeDashboard color

2. 2Why is mandatory usage weak adoption evidence?

   Answer it, then reveal