The lifecycle: the other eighty percent
Development is a phase. The system then has to be deployed, operated, supported, changed and eventually killed — and all of that is designed now, whether you plan it or not.
- You can name the six lifecycle stages and say what each one demands of the design.
- You can spot the decisions that quietly make year three expensive.
ISO/IEC/IEEE 15288 describes a system's life in six stages. Most teams only budget attention for the second one, which is why the other five arrive as surprises.
| Stage | What happens | What it demands of the design |
|---|---|---|
| Concept | Needs, feasibility, alternatives, rough cost | A boundary and a purpose you can defend |
| Development | Requirements, architecture, build, integrate, verify | Traceability, interfaces, testability |
| Production | Manufacture or deploy, configure, hand over | Repeatable deployment; configuration as code |
| Utilization | The system does its job in the real environment | Observability, capacity margin, user support |
| Support | Maintenance, updates, training, spares, migration | Upgrade paths, versioning, documentation, ownership |
| Retirement | Decommission, migrate data, archive, delete | Export formats, data retention, dependency exit |
8.1Design for operability
The features that make year three cheap are unglamorous and can be listed:
- Observability — metrics, logs and traces keyed to the same identifiers, so an incident can be reconstructed rather than guessed.
- Upgrade path — a way to change the thing without downtime, and a tested way to roll back. "We'll redeploy" is not a plan if deployment is manual.
- Data lifecycle — where data lives, how long it stays, how it is exported, and how it is deleted when asked (or when required by law).
- Ownership — one team name on the on-call rota, one team name on the roadmap. Systems with two owners have none.
- Runbooks — what to do at 3am, written by someone who was awake when they wrote it.
- Exit plan — for every vendor and every proprietary format, a sentence on how you'd leave.
Debt isn't "bad code". It's a decision that moved cost from development into support without a plan to pay it back. Naming it that way makes it manageable: who is paying, at what rate, and when does the interest become unacceptable?
The stage most often skipped is transition — the move from "it works in staging" to "it runs the business". It has its own acceptance criteria: data migrated and reconciled, users trained, support rota live, monitoring wired to the right pager, rollback rehearsed. A launch that goes badly is usually a transition that was never designed, only announced.
8.2Retirement is a requirement
Systems outlive their authors, their vendors and sometimes their purpose. The retirement stage asks: can the data leave, can the integrations be unwound, does anyone still depend on this, and what has to be true before we switch it off?
Writing one page about retirement at design time is cheap and prevents two classic incidents: the system nobody can turn off because a downstream report depends on it, and the archive nobody can read because the export format was proprietary.
Launch plans describe the first week. Lifecycle plans describe the third year: what breaks at 10× data, who changes the model when the provider deprecates it, what happens when the person who understands the pipeline leaves. If your plan has no sentence about year three, it is a launch plan wearing a lifecycle label.
8.3Transition: the stage with no ceremony
Between "it passed acceptance" and "it runs the business" sits a stage that most plans omit. Transition has its own acceptance criteria, and they are operational rather than technical — which is why they get skipped by teams who equate done with deployed.
| Criterion | The failure it prevents |
|---|---|
| Data migrated and reconciled — counts match, a sample of records compared field by field | The new system is correct and the data in it is not |
| A named owner on the rota, with an escalation path that has been called once | Nobody answers at 2am because everyone assumed somebody would |
| Monitoring wired to the pager, proven by triggering a synthetic failure | Dashboards that look healthy because nothing is reporting |
| Rollback rehearsed, with a measured duration | A rollback plan that takes four hours and was never timed |
| Users trained, and the old path still works for a defined window | A cutover with no way back and a support queue on day one |
| Decommissioning scheduled for whatever is being replaced | Two systems running in parallel for three years |
The tell for a launch that will go badly is a plan written entirely in the future tense about software, with no sentences about people, data or the old system. Those are the three things that decide the first week.
Which choice most reduces lifetime cost, and is easiest to make early?
60-second recap
- Six stages: concept, development, production, utilization, support, retirement.
- Run and support dominate the lifetime. Design for operability, not for the demo.
- Technical debt is deferred support cost — name who pays and when.
- Plan retirement early: export, retention, dependencies, switch-off criteria.