Suppose a product team needs a database separate from production to test a new feature. The developers know what they want to test, but they still have to find out who provisions the database, where to request access, and who removes it when the test is over.
If we design a platform around this request, my first question is where does our responsibility for the service begin and end? A button to request a database helps only part of the way. Users also need to know what they are getting and whom to contact when something goes wrong.
This three-part series follows one hypothetical software team and one test-database service throughout. We start by agreeing on the boundaries, make the service usable from request through retirement, then consider whether to expand it. For the broader investment question, see From AI-Written Code to a System the Team Owns.
Read the platform diagram through its users' work
CNCF Platforms White Paper invites us to view a platform from its internal users' needs and to distinguish the experience they receive from the providers behind it. A platform team can bring existing services together rather than build everything itself.
Scroll sideways to see the details, or open the full-size image.
I read the diagram from the work of the people at the top. The product team wants to test a feature, so it uses understandable documentation, templates, or commands to request what it needs. Beneath that experience are data systems, access controls, and infrastructure services that must work together. The diagram also includes messaging, artifact storage, security and policy checks, builds, tests and delivery, and monitoring. It shows relationships; it does not say our hypothetical team must build every box before offering one service.
For the test database, users may need only a supported database type, a way to connect, and a way to finish. Behind the scenes, someone still has to deal with failed requests, issued access rights, and resources that continue to incur charges. Users should not have to chase each of those separately.
Give "service owner" a shared meaning
In this hypothetical case, I would separate the responsibilities of the product team, the people running the platform service, and the database provider. These are roles, not a requirement to create a new team for every box. One group may perform several roles, but everyone still needs to know who owns each task and how it is checked according to risk.
- Product team
- Defines what to test and manages the data and database use for its work
- Platform service operators
- Manage the agreed request process, status, access, limits, and support channel
- Underlying provider
- Works within the chosen service scope and configuration; the actual contract and limits must be checked
A provider, for instance, may maintain some of the machines and database software. That does not mean it will choose suitable test data for us or know which user account should see which information. I want the service description to say both what the service team manages and what the requester must still do.
| Task to agree on | Who needs to take responsibility |
|---|---|
| Test data | The product team chooses data fit for its work, starting with data created for testing rather than copying real customer data by default. |
| Access | The service operators define who may request the database, what network and permission boundaries apply, and which systems enforce them. |
| When it fails | Provide a reporting channel and a person to triage whether the issue is the request, connection, or underlying service, with a way to hand it off. |
| When use ends | Know who authorizes retirement, who removes access, and who checks resources, backups, or logs that must still be retained under the rules. |
Write down what users can expect before choosing a screen
I would have the team write a service description someone can act on: What kinds of tests is this database for? Where can it be reached from? Who can access connection secrets? What does deletion affect? If those questions have no answers, choosing between a portal and an API will not make expectations clearer.
The time to provision it, status updates, and support path should match what the operators can actually deliver. It is fine to begin with a process that needs a person for some steps, so long as the service says which steps wait for human action. A form that creates a work queue is not yet end-to-end automation.
The description also makes exceptions discussable. If some work needs a different database or different controls, users should know whom to talk to and what extra work they would need to manage. A standard service need not force every project into the same shape.
Before building the database-request button
The hypothetical team has not decided to buy a new system. It first has a test service with identifiable users, clear responsibilities, and work that must be coordinated with the underlying provider. Agreeing on those boundaries helps the team see where existing tools can be connected and where further experiments are needed.
If one database request still ends with everyone meaning something different by "owner," I would fix that first. In the next part, I will make this same service usable from request to retirement.
Source and scope
The original diagram and starting concepts come from the CNCF Platforms White Paper. The product team, test-database service, division of work, and proposals here are hypothetical examples for further thought, not operating results or a case study of a real organization.
