How the Live phase works
Where this fits
The longest phase. The service is up and running, and the work is keeping it useful:
- watching how it performs
- fixing and improving it
- adding capability as more people arrive
- keeping it secure and funded, year after year
This is where the one-time work of standing the service up ends, and the service becomes something a team looks after. Launch is not the finish line. It is the point where the service starts being used, where its running costs begin, and where it needs steady care to stay useful.
Live is open-ended. There is no single delivery date to aim at the way Create has launch. Sometimes an end is already known, when a contract runs for a fixed term or a policy sets a retirement date, but even then the daily work is a cycle rather than a countdown to it. That cycle repeats for as long as the service is used: watch how it performs, fix and improve it, keep listening to the people who use it, keep it secure, and renew its funding in good time. The three sub-phases below mark how the cycle changes as the service matures.
Think ahead to Sunset while you run. Every service ends, and the teams that end well are the ones that saw it coming: they watch the signals that point to retirement or replacement, keep the exit possible as contracts renew, and set the money aside before the current funding ends. The end of one service is usually the Create of the next, so that planning starts years before the last day.
The work of Live
Live is three kinds of work, running side by side for as long as the service is used.
The work comes round again. Live's checks recur: a security check on every release, the privacy assessment refreshed as the service changes, funding renewed before it runs out. Live settles into a rhythm and keeps going.
What runs in Live
Every cross-cutting thread keeps running through Live. A few carry most of the weight here:
- Monitoring and instrumentation Watch the signals and turn them into work; most monitoring lives here.
- Backlog Decide what to improve next; this is the longest chapter of continuous improvement.
- Releasing changes Release small changes often, and roll them out safely.
- Change management Win adoption, so the service is actually used.
- Security Detect and respond, and keep the service patched and current.
And the obligations that recur here:
- renewing funding before the money runs out
- keeping the privacy assessment current
- holding the service to the accessibility standard
- patching dependencies
- retaining and disposing of data on schedule
- re-testing that the service can actually be recovered in the time it promised
- keeping the team together
Live's checks come round again
Create runs through one-time approvals. Live works differently: its checks recur. Build a security check into every release, update the privacy assessment when the service changes substantially, and secure renewal funding before the current money ends. How critical the service is and how fast it has to come back are re-asked here too. Stabilization tests whether the recovery targets set in Alpha are achievable. Growth reopens them when the service changes, and Maturity re-runs them on the department's own cycle. The work does not finish; it comes round again.
The three sub-phases of Live
Live moves through three sub-phases. They mark how the work changes as the service matures: steadying it right after launch, growing it as more people arrive, and keeping it healthy over the long term.
Just launched; make it reliable under real, full load.
Expand reach, features, and scale.
Steady state; keep it healthy over the long term.
Leaving Live is the crossing into Sunset: the service is being replaced or retired, and the exit has to be planned and funded before the money runs out.
CAUTION
The cost of leaving it late
The recurring work is easy to defer, and every deferral has a price:
The renewal starts late.
The only option left is an emergency extension on the supplier's terms, and the lock-in deepens.
Improvement is deferred.
The service ages into a forced replacement, run as an emergency with a fixed date. The last famous one of those was named Phoenix.
The exit money is never set aside.
The signals point to Sunset, and there is nothing to pay for the crossing.
The assessments go stale.
A new feature waits on a privacy assessment that should have been kept current as the service changed.
Support is scaled after the wave.
The users arrive before the help does, and people struggling alone becomes the service's reputation.
Assumptions this page makes
You are already working to the Government of Canada Digital Standards, design with users, iterate and improve frequently, work in the open, use open standards, address security and privacy, build in accessibility, empower staff, be good data stewards, design ethical services, and collaborate widely, and to the law on privacy, security, official languages, and accessibility. The standards say how the government works in the digital world. The six Government of Canada digital competencies say what every public servant has to be able to do to work that way, and the team page covers them. This guide builds on those.