Operations and Maintenance (OPS) Phase of the Systems Development Lifecycle (SDLC)

Defines the IF4IT SDLC phase in which the Production Solution is operated, monitored, supported, secured, maintained, recovered, improved, reassessed, and governed until replacement or Retirement, while each Release is stabilized and formally closed.

Purpose

The Operations and Maintenance phase sustains the intended enterprise outcomes of the live Solution over time. It manages Service performance, users, data, controls, suppliers, incidents, changes, vulnerabilities, capacity, continuity, knowledge, and technical health while preserving accountability for the enduring Product, Service, Asset, System, or Solution.

Typical Inputs

Inputs may include the accepted Production baseline, operational ownership, Service objectives, monitoring and alerting, runbooks, support and escalation models, supplier agreements, active Risks and exceptions, known defects and Technical Debt, recovery plans, maintenance schedules, Release conditions, training and knowledge, and applicable regulatory or policy obligations.

Core Activities

Operate and monitor the Solution; provide support; manage Incidents, Problems, requests, access, capacity, availability, performance, Security, Privacy, data quality, suppliers, certificates, licenses, patches, upgrades, vulnerabilities, configuration, backups, recovery, continuity, and operational documentation; assess changes; initiate new Releases; measure outcomes; maintain inventories; and preserve evidence and knowledge.

Release Stabilization, Closure, and Continuing Lifecycle Governance

OPS includes the Release Post-Mortem and Closing activities that determine whether the bounded Release met its objectives, which findings remain, what lessons should improve the SDLC, and whether Release records can close. Closing a Release does not close the underlying Solution lifecycle. Enduring owners must continue to govern supportability, obsolescence, supplier health, controls, Risks, Technical Debt, and future change.

Outputs and Evidence

Outputs may include operational telemetry, Service reports, Incident and Problem records, maintenance and patch evidence, access and control reviews, supplier performance data, recovery exercises, updated configurations and inventories, Risks and exceptions, Technical Debt Items, post-mortems, Release-closure records, lessons learned, and proposals for new Releases, modernization, or Retirement.

Decision and Exit Criteria

OPS ordinarily continues while the Solution remains active. A Release may exit through formal closure after stabilization and disposition of its obligations. The Solution exits OPS only when an authorized Retirement decision is made, a successor or closure plan exists, operational dependencies and obligations are understood, and the enterprise is ready to enter Retirement, Decommissioning, and Disposal.

Application Across Solution Types and Methods

Custom-Built Solutions require enterprise maintenance of code, infrastructure, dependencies, and technical knowledge. Acquired Solutions require supplier, Product-release, contract, configuration, evidence, and renewal governance. Composite Solutions require end-to-end ownership across parties. Agile, DevOps, and continuous delivery may integrate operations and engineering closely, but enduring accountability, Release closure, risk decisions, and operational controls remain explicit.

Crawl-Walk-Run Maturity

At Crawl maturity, establish ownership, monitoring, support, Incident response, backups, maintenance, supplier contacts, inventory updates, and Release closure. At Walk maturity, integrate Service, configuration, Release, Security, supplier, Risk, and Technical Debt workflows with measured objectives. At Run maturity, use predictive operations, automated control health, self-healing where safe, continuous assurance, dynamic capacity, and outcome-driven lifecycle optimization.

Common Antipatterns

Enterprises should avoid declaring success immediately after a Deployment completes and dissolving delivery accountability before the Solution has stabilized. Guarding against this keeps Release governance active through stabilization, closure, and the transfer of continuing obligations to durable owners, and prevents the false signal that a successful technical Deployment is the same thing as an accepted, stable, and supportable Release.

Connections to Related IF4IT Practices and Inventories

Use Application Portfolio Management (APM) Best Practices and the Applications Inventory and Attributes to connect production and operational evidence to application health, cost, technical fitness, lifecycle status, and modernization decisions. Use Technology Portfolio Management (TPM) Best Practices, the Software Technologies Inventory and Attributes, and IT Operating Environments Best Practices to connect the decisions and responsibilities addressed in this chapter to governed technology choices, platform lifecycle, and environment controls.

Apply Service Management Best Practices and Service Catalog Best Practices to define operational ownership, support models, service levels, monitoring, knowledge transfer, and customer-facing service commitments before and after Production.

Apply Technical Debt Management Best Practices and the Technical Debt Inventory and Attributes to identify, qualify, record, prioritize, remediate, accept, and periodically reassess intentional, inherited, emergent, and deferred lifecycle obligations.