Suppose the product team from the first article can now request a test database through the service it built. A developer can submit a request and connect without help. Yet a stalled request still needs the person who wrote the system. Updates wait until that person is free. When testing ends, no one is quite sure that unused resources have all been cleaned up.
On screen, the service looks much more ready. Before inviting other teams to use it, though, I would ask whether the work users can do themselves has people and operating methods behind it. A working button tells us one thing. Readiness also depends on what happens afterward.
This article uses the same hypothetical test-database service to explore what to improve next. Every situation here is an example of how to think through the work, not a result from any company.
Use a maturity model to choose what to fix
The CNCF Platform Engineering Maturity Model examines five aspects: investment, adoption, interfaces, operations, and measurement. The source table describes four levels for each: Provisional, Operational, Scalable, and Optimizing.
Each aspect needs to be considered separately, although they affect one another. They should not be collapsed into a single grade for the organization. Higher levels also require more money and people's time, so a team should choose what fits the work rather than aim for the highest level everywhere.
I would use the model to ask questions about the one service we are building, not to judge how good the team is. Start with what users and operators actually experience, then choose the problem worth addressing next.
One service can be ready in some respects and weak in others
Return to the hypothetical team. Letting people request databases themselves is visible progress. It does not yet tell us whether the operators have enough time, why users choose this service, or how the team knows when testing work has finished.
Users can request it themselves. What about the rest?
- Investment
- No time has been reserved to maintain the service.
- Adoption
- People hear about it from colleagues, but the team does not know why some stop using it.
- Interfaces
- Users can request and connect to a supported database themselves.
- Operations
- A stalled request or retirement still requires someone to chase it case by case.
- Measurement
- The team sees how many databases were created, but not whether users finished their tests.
If we call all of this "ready to scale," we may simply pass unowned work on to a larger group of users. I want "ready" to say which people can do which work, within what boundaries. Convenience at the point of request cannot stand for the whole service.
Ask about the user's work and the operator's work
I would ask a user and an operator to follow the same request from start to finish. Where can the user act independently? Where do they wait? Where does someone help without that work being visible on screen? Then discuss evidence that can be checked later, such as request history, incident records, and maintenance work on the plan.
| Aspect | Question to answer | Evidence to examine |
|---|---|---|
| Investment | When other urgent work appears, is anyone still responsible for updates and user support? | Allocated time, backup owners, and outstanding maintenance work |
| Adoption | What work does the service help people do, and what causes former users to leave? | Actual trials, reasons for support requests, and users' explanations |
| Interfaces | Can users complete supported tasks, or do they merely submit a ticket to a queue? | Steps users can complete, visible status, and points still waiting on a person |
| Operations | Who does what when the service fails, needs an update, or is retired? | Incident history, update plans, and checks for outstanding access or resources |
| Measurement | How does the team know whether a fix helps users finish their work? | Comparable before-and-after results, with explanations from users and operators |
Some answers may not exist yet. Those are things to investigate, not boxes to mark "passed." Nor does the team need a large report before fixing anything. If request history and conversations with users identify a problem, it can test a small change.
Fix the work that follows the request
For this hypothetical service, I would first set aside maintenance time, name a backup when the main operator is away, and make stalled requests visible and transferable. A handoff needs enough information for the next person to continue, not just another name on a document.
Retirement also needs to finish in practice. Users should know how to extend use or confirm that they are done. Operators should be able to check which permissions, resources, and data have been handled, and which must still be retained under the service terms. A successful deletion message on screen does not prove every part is gone or that charges have stopped.
- RequestKnow what is in scope and who is responsible
- Review the requestCheck access, limits, and data to be used
- Create and connectSee status and connect with the right permissions
- Use and operateHandle incidents, updates, and continuing need
- Retire and check leftoversHandle access, resources, and data under the service terms
Access rules must be enforced by the actual request system, whether the user comes through a web page or a command. Connection secrets need restricted delivery and storage. Start test data with data created for testing, not copies of real customer records by default. Sensitive data, if needed, calls for a separate review of the applicable conditions.
Then return to the people who tried the service, including those who completed their work and those who got stuck. Record how the chosen problem changed and how much extra work operators took on. Collecting feedback without anyone using it to decide leaves users with the same problems, however many surveys the team runs.
Get ready where the work calls for it
A small team may not need a full-time operator or another tool yet. It does need to agree whose time maintenance will use and which other work will give way. Adding duties without allocating time does not remove the cost. It only keeps that cost out of the plan.
For the hypothetical team, I would not add another database type in this round. I would make request status, handoff, and retirement checkable first, then see whether users can actually finish more of their work. That evidence will help decide in the next article what to expand and what to keep fixing.
Source and scope
Based on CNCF Platform Engineering Maturity Model provides the framework for the questions. The test-database scenario, explanatory diagram, question table, and proposals apply that framework to a hypothetical case. They do not certify any organization's maturity or results.