In the earlier article (part two, on what to improve after building a platform) the hypothetical team chose not to add another database type. It first made request status, handoff, and retirement checkable. Now I want to follow that work to the day someone asks when the service should expand.
I would not wait for every part of the existing service to be perfect. But I would not let a count of new requests excuse problems we already know about. The decision is what work the addition helps users do and whether we can take responsibility for what follows. We may fix the current service, run a limited expansion trial, or defer the request.
This article continues the same hypothetical test-database service. Its examples and proposals are ways to think through the decision, not results from a real organization or a certification of readiness.
Check whether the problem we chose to fix has changed
If the previous round addressed stalled requests, follow actual stalled requests within the trial's scope. Can users see their status? Does the person taking the issue know what was created? How far can someone else carry it forward? Changing the screen text is not enough if everyone still waits for the same person to investigate.
Retirement deserves the same treatment. Trace a request to stop using the service through permissions, resources, and any data that must be kept under its terms. If an owner must confirm retirement, check that step too. Do not treat a successful click on Delete as evidence that the entire job is complete.
I would look at work users finish, the time they wait, and the help operators provide. Compare similar tasks before and after a fix, and ask the people who tried it. Faster completion may depend on someone quietly helping behind the scenes; it does not yet prove the total workload has fallen.
Separate problems to resolve first from improvements that can continue gradually
If the service cannot identify who can access data, or cannot tell what remains after retirement, I would address that before adding users. The scope of potential harm is still unclear. Improvements that do not affect the correctness or safety of the work may continue during a limited trial. Assess the actual risks rather than use one checklist to decide for every service.
- Can we operate the current service?If important problems remain uncontrolled, fix or limit the risky area first. Consider a new request once the existing scope can be managed.
- What work does the new request address?If the need is still vague, talk to users and examine alternatives. Once the need is clear, assess the added work.
- Who will carry the added work?If time, people, or budget have not been agreed, defer it or choose another path. Design a trial only when the load can be carried.
- How will we try and stop it?If we cannot handle a stop, first plan for users and data. Begin the trial once its boundaries are agreed.
A request for another database type should say more than "we want one." In this hypothetical example, the team needs to test a connector against that database type, including reads, writes, and error reporting when the connection fails, using data created for testing. Trying only the existing database cannot show that the connector works correctly with the new one. I would talk to the people who need it and check whether an existing service or external provider can support the work before taking on maintenance ourselves.
The same request can lead to different answers
Consider two hypothetical situations. Both teams receive a request to support another database type, but the evidence about their current service differs. These are alternative cases, not a before-and-after result for a real team.
Case A: fix the current service first
Users still ask for request status. The backup operator does not know what resources were created, and retirement records lack complete checks.
I would make status, handoff, and closure verifiable before adding a database type in this round.
Case B: try a limited expansion
Assume a backup can investigate problems and retirement steps have been checked under the service terms. Users need to test a connector with another database type, and someone has taken responsibility for the added operation.
I would propose a trial for the agreed test work, then review it before opening the service more widely.
In Case A, declining to add the service does not necessarily mean stopping all work. Existing users may continue within boundaries the team can control while it addresses the known problems. If a problem affects access, data, or security, the affected area may need to be limited or stopped as necessary. Users also need to know how to continue their work.
For Case B, I would assess production requests separately. A successful handoff or retirement in a test service does not replace assessment of the data used, the damage from an outage, backup and recovery, or the provider's duties in production.
Count the work after launch before calling it worthwhile
Before a Case B trial, the requester and operators should identify the added tasks: configuring and testing templates, updating, handling incidents, checking permissions, and retiring instances. What does the provider do, and what remains with the team? Check the actual service scope rather than guessing from a managed-service label.
Show external charges and people's time separately. A lower system bill may look attractive while the new operating work leaves no one available for incidents. Time returned to users has value too, but it does not automatically equal cash saved. Ask what they will do with that time and which expenses actually change.
For a team with limited staff, the question I want answered is if we take on this new service, what work moves back, and who accepts the effect of that delay? Without an answer, I would not promise a launch date even when the new need is reasonable. An external service within a suitable scope, or revisiting the request next round, may be better.
Design a trial that answers a question
The Case B trial should start with agreed users and test work, use data created for testing, and set access, resource, and spending limits the team can manage. Before it starts, agree on what to review when that round of work ends. Otherwise "trial" can stretch on without a decision.
Evidence I would want includes whether users completed the named tests, where they needed help, whether the backup operator could follow an issue, and whether retirement was verified against the terms. Record actual service charges and operating work too, then compare them with what was agreed before the trial.
If access controls depart from the agreement, or the team cannot account for resources and data at retirement, stop accepting additional requests in the affected area and investigate. Stopping expansion does not mean deleting databases that people are using. Someone must contact users, check what data needs to be kept, and agree on migration, rollback, or retirement according to each case's risk.
End the discussion with a decision someone can own
I want the review to produce a short record that still makes sense later. The example below fills in Case B to show the questions to answer. It is not a mandatory form for every organization.
| Item to record | Hypothetical team's answer |
|---|---|
| What was decided? | Trial support for another database type only for testing agreed with a user group, not for production. |
| Why this option? | The team needs to check reads, writes, and connection failures against another type. Handoff and retirement for the current service are now checkable within their scope. |
| Who is responsible? | Service operators handle updates and incidents with a backup. The product team owns test data and results. The plan must name the actual people. |
| How is the added load covered? | Reserve time for setup, testing, and operation, and agree on spending limits and which other improvements move back before starting. |
| When do new requests stop? | If access or data handling departs from the agreed scope, or operations exceed allocated capacity, the owner assesses the impact and tells users. |
| When is the review? | At the end of the agreed test round, review usage, support work, charges, and retirement. Set an actual meeting date known to everyone before starting. |
After review, the team may expand, fix another issue first, or discontinue the part that costs more to operate than it is worth. Ending a service also needs a plan to notify users and hand over outstanding work. Keeping the options to stop or use an existing service prevents the team from maintaining everything merely because it once invested in building it.
Source and scope
The maturity framework appears in the earlier article (part two) which cites the CNCF Platform Engineering Maturity Model. The questions, diagram, two cases, and decision record here are proposals for a hypothetical situation. They are not CNCF criteria or research findings and cannot replace assessment of a real system.