Run and improve systems

Responsibility after launch

Operational software needs an operator. Someone has to watch it, respond when it fails, maintain its dependencies, test recovery and make changes as the business develops.

Opsenium normally continues with the systems it builds under a written managed service agreement. The agreement records the support route, response expectations, hosting position, backup arrangements and exit process. A client can choose another operator; ownership of the delivered system does not depend on staying with Opsenium.

Day-to-day operation

• Microsoft Azure hosting, normally in UK South
• Infrastructure defined in the repository and deployed through a controlled pipeline
• Application telemetry, availability tests and alerts routed to people
• A support desk with cases tracked from report to closure
• Dependency, runtime and certificate maintenance
• Review of performance, usage and cloud cost

Service levels are agreed for the system rather than claimed universally. Urgent faults and routine requests have different handling, and material incidents receive a written account.

Recovery

Backups are only useful if they can be restored. Each managed system has documented recovery objectives and a runbook. Database recovery, independent copies and restore exercises are selected according to the system’s risks and the agreement with the client.

For Bishops Emporium, Opsenium operates the production estate in Azure UK South, maintains independent off-site backups and has rehearsed the database restore procedure. The details are set out in the case study.

Improvement

The backlog continues after launch. Smaller changes can be delivered on an agreed cadence; larger additions go through the same design, review and release process as the original system. This keeps the software aligned with the operation instead of allowing another layer of workarounds to grow around it.