Service retirement and decommission¶
Trigger¶
A service, application, platform or technology component is approved for retirement, replacement or exit.
Intended outcome¶
The component is retired without hidden dependencies, unmanaged data/access, stale records or unowned residual obligations, and the retirement benefit is measured.
Workflow steps and gates¶
| Step | Accountable role | Activity | Handover | Gate |
|---|---|---|---|---|
| 1 | IT Service Owner | confirms retirement scope, accountable owner and business/service decision | retirement mandate and target date | Scope and authority are explicit |
| 2 | Technology Lifecycle and Decommission Manager | runs repository impact analysis and builds the retirement/disposition plan | dependency impact and retirement plan | Every material dependency has an owned disposition or named waiver |
| 3 | Data Protection Officer | advises on retention, archive, destruction and privacy obligations where applicable | data disposition position | Regulated/personal data disposition is authorised before irreversible action |
| 4 | Identity and Access Management Engineer | removes/transfers identities, privileged access, secrets/certificates as assigned | access/credential closure evidence | No active credential remains without owner and purpose |
| 5 | Change Manager | applies the authorised production-change path and rollback boundary | approved execution window/decision | Destructive steps are within approved change authority |
| 6 | IT Asset Manager | reconciles CMDB/assets and coordinates licence/supplier closure evidence | asset/configuration closure | Systems of record match the retired technical state |
| 7 | Architecture Repository and Modelling Lead | updates repository lifecycle state, removes/retains views appropriately and records residual dependencies | repository retirement revision | Repository has no unowned active dependency into the retired element |
| 8 | Benefits Realisation Manager | measures retirement cost/risk/complexity benefit and records variance | benefits closure result | Benefit or disbenefit variance has an accountable owner |
Running this workflow: operator and implementer boundary¶
In Claude Code or Codex CLI, use the prompt in the next section (or adapt it to your programme): it is a provider conversation request, not a shell program named after this workflow. You supply the source materials, actual owners, gate acceptance and any authorisation for changing real systems. The provider agent interprets the registered workflow stages and role contracts, calls supported tools if allowed, and returns explicit evidence and blockers. Stage completion in the diagram or metadata is not proof of a successful external tool call, an approved exception or a released system.
For consequential decisions explicitly start /layered (Claude) or $workflow-layered (Codex); this version does not force every direct/natural-language workflow invocation into Fabric. Human L0 authority remains separate, with Codex requiring the actual human to run any protected authority command in a trusted terminal. See the interaction model, layered engagement and human authority.
How to use this workflow¶
A practical prompt pattern is:
Apply the
service-retirement-and-decommissionworkflow to this situation. For each step, identify the current state, accountable role, required evidence, hand-over artefact, gate status and unresolved blocker. Do not skip a gate merely because the implementation is technically complete.
Operational interpretation¶
The workflow is most useful when the team keeps each hand-over explicit. The system can help generate or review the artefacts, but the accountable role and approval decision remain organisational responsibilities.