Capabilities/Support, Maintenance & Evolution
Deployment ends the project. It does not end the responsibility.
Once a system is live, the longer work begins: keeping it running, correcting faults, closing security gaps, and adapting it as the organization and its rules change. CREA-KO treats that stretch as engineering, not aftercare — so a system stays dependable while it operates, and stays relevant as everything around it moves.
Where most delivery stops
The assumptions a system launches with do not stay true.
Software is usually handed over at go-live and treated as finished. But the day a system launches is the day its assumptions start to date. The organization reorganizes. Rules and obligations change. The people who understood the system move on. Dependencies age, and the threats against them do not stand still.
The question that decides a system’s working life is not who built it. It is who stays responsible for it once it is live, the organization has changed, and the original implementation no longer fits the world around it.
The lifecycle, drawn to scale
Most vendor timelines stop at deployment. This one keeps going.
Both lines share the same start and reach the same deployment. One ends there — handed over, then left to age. The other treats deployment as an early marker: operation, adaptation and modernization are the long stretch that follows, and every change along the way passes a control point.
CREA-KO’s model
- Design
- Implementation
- Deployment
- OperationKept running day to day, on clear incident-response principles.
- AdaptationReworked as the organization, its rules and its connections change.
- ModernizationRenewed onto current technology across the years, without discarding the record it holds.
- ContinuityKnowledge and control carried forward — handed over cleanly where an engagement calls for it.
The usual delivery
Handed over. Responsibility ends here.
Two kinds of responsibility
Maintenance protects current operation. Evolution protects future relevance.
They are not the same discipline. Maintenance keeps a system dependable as it stands — faults corrected, security current, performance held steady. Evolution changes what the system does, deliberately, as the organization asks more of it. A system needs both: one holds the present, the other keeps it worth running.
Maintenance — protects current operation
Corrective maintenance
Faults found and corrected, so a problem in production does not become the organization’s problem.
Preventive maintenance
Routine upkeep and housekeeping that address wear before it reaches the people using the system.
Security & dependency maintenance
Vulnerabilities closed and the libraries beneath the system kept current as the threat landscape keeps moving.
Compatibility
The system kept working as the browsers, platforms and connected systems around it change versions.
Performance review
Behaviour under real use watched and tuned, so response stays steady as data and demand grow.
Evolution — protects future relevance
Change requests
A structured way for the organization to ask for change, with the impact understood before anything is committed.
Controlled enhancement
New capability added deliberately and tested against what already runs, rather than bolted on.
New integrations
Fresh connections to other systems built as the organization’s landscape widens.
Organizational change
Structures, rules and categories adjusted as the organization reorganizes — as configuration where the design allows.
Configuration over rebuild
Change absorbed by reconfiguring the system wherever possible, to avoid the cost and risk of starting over.
Change stays governed
Nothing reaches the live system unassessed.
Operational support runs underneath all of this, on clear incident-response principles rather than improvisation. But the part that protects a live system most is how change is handled: every request — a fix, an enhancement, a new connection — travels the same disciplined route before it touches production.
Request
A change is raised and captured — from the organization, from day-to-day operation, or from a change in the rules.
Impact assessment
Its effect on the running system is weighed before any work begins.
Build and test
The change is engineered and tested against what already runs, not just in isolation.
Controlled release
It reaches the live system on a deliberate release, never by surprise.
Documentation
What changed, and why, is recorded and kept with the system for whoever maintains it next.
Knowledge, control and responsibility over time
The system should never depend on a single memory.
A system that only one person understands is already at risk. So knowledge is kept attached to the system, not held in someone’s head: documentation that stays current, decisions recorded with their reasons, and releases traceable long after they ship.
Control stays with the organization throughout. Responsibility can evolve as circumstances change — and where an engagement calls for it, the system is handed over cleanly, with the knowledge needed to run it. Long-term responsibility here is a way of working and an engineering capability, not a blanket promise to maintain every system forever.
It is the same discipline that lets a system endure inside a demanding institution — Institutional Continuity — under the control model set out in Security & Standards.
Plan for the years after launch, not just the launch.
The systems worth building are the ones still worked on years later — kept running, kept secure, kept relevant. That is where this conversation starts.