Launch is the moment a system begins its working life. From that day it carries real customers, real transactions and real data, and the care it receives determines how well it serves the organisation in the years that follow.
What a system needs once it is in service
A system in service depends on a small number of disciplines carried out without interruption. It must be hosted on infrastructure that is secure and correctly configured. It must be monitored, so that a fault is noticed and addressed before it affects the people who rely on it. Its operating system and software must receive security updates as they are released. Its data must be backed up, and those backups must be tested.
It must also change. Organisations adjust their services, their teams and their processes, and the system has to follow: a form gains a field, a report gains a measure, an integration is added. Each change has to be made with care, by people who understand how the system is built, so that improving one part does not disturb another.
Agree the service before launch, in writing
The arrangements for operation are best settled before launch. A written service agreement should state who hosts the system and where, who applies security updates and how quickly, how the system is monitored, and how faults are reported and resolved. It should define response times, and it should state what is included as standard and how further work is agreed.
The agreement should also settle ownership. The domain, the hosting and the accounts should be registered in the organisation’s own name, and the source code, the project files and the documentation should be available to it. An organisation that holds these keeps full control of its system, whoever operates it.
Why the same team should run it
When a system passes from the team that built it to a different team that operates it, knowledge is lost at the handover. The reasons behind a design decision, the details of an integration and the history of an issue rarely survive a transfer in full. The operating team must learn the system before it can maintain it with confidence, and in the meantime changes take longer and carry more risk.
When the engineers who built a system also host, maintain and support it, that knowledge remains in use. Faults are diagnosed by people who know where to look. Changes are made by people who understand their consequences. Accountability sits in one place, so there is never a question of which supplier is responsible.
Questions to settle before any launch
- Who hosts the system, and in which location?
- Who applies security updates, and within what period?
- How is the system monitored, and who is alerted when something fails?
- What response times are agreed in writing?
- How are backups taken, and when were they last tested?
- In whose name are the domain, the hosting and the accounts registered?
- Where are the source code and the documentation held?
- What happens to the system if the engagement ends?
How Codebay approaches it
Every system we deliver is hosted, monitored, updated and supported by the engineers who built it, under a defined service agreement that begins on the day of launch. Following a technical review, we also assume responsibility for systems built by other suppliers.
More insights
-
Where an AI agent helps with customer enquiries, and where a person stays in charge
What an AI agent handles well, the decisions that should remain with your staff, and how the handover between them should work.
Read the article -
From scattered data to dashboards your team can act on
How Codebay designs and builds business intelligence around an organisation’s own data, measures and decisions.
Read the article
A structured assessment of your current systems and requirements, concluding in a written plan.
