Ownership & operations
Make maintenance part of the plan
Unchanged code can stop working when the world around it changes. Plan care around dependencies, accounts and business assumptions as well as new features.
Pattern Engine · Practical field notes
Software can need maintenance even when nobody changes its code. A browser update, an expired credential, a retired API or a new business rule can break the assumptions under which it worked.
Maintenance is the work of keeping those assumptions aligned with reality. A simple system can need little care, but “finished” does not mean isolated from change. The right plan reflects what the business depends on and who will notice when that dependency shifts.
Watch the things you do not control
A reliable integration may fail because its vendor changes an authorization rule. A scheduled task may stop because the account that owns it is deactivated. Neither failure requires a defect in the original logic.
The useful inventory therefore includes relationships as well as software components: who receives notices, which account renews access, what an integration assumes and who can respond. The Canadian Centre for Cyber Security’s baseline guidance includes updates and unsupported products as continuing concerns.
AI can help investigate a dependency change or prepare a fix. Testing still needs to establish whether the operation works under the new conditions. The lasting value of maintenance is often uneventful continuity; waiting for a visible outage makes that work harder to plan.
Separate routine work from improvement
Routine care includes checking failures, applying appropriate updates, reviewing access and testing recovery. Product improvement changes what the system can do. Both consume capacity, but they answer different questions and should be visible in the budget.
A maintenance arrangement that quietly spends all its time on new features leaves essential care unattended. Conversely, a system with frequent avoidable failures may need a targeted improvement rather than an indefinitely growing support allowance.
Set a workable cadence
Choose review intervals around the consequences of failure and the rate of change. Some checks should be automated; others need a person. Define which events trigger immediate attention, such as a critical dependency notice or a failed backup, and which can wait for the next planned review.
Keep a short record of what was checked, changed and deferred. A useful maintenance log lets the next person understand the system’s condition without reconstructing months of messages. Deferred work should have a reason and a review point.
Leave room for replacement
Maintaining a system does not always mean preserving every component. A vendor may retire an API. A dependency may become unsupported. A once-useful workaround may become expensive as volume grows.
Watch for recurring repair work that indicates a deeper problem. Estimate whether replacing a small component would reduce the continuing burden. Keep this decision tied to the system’s expected lifespan and remaining value rather than treating every aging component as an emergency.
Make the responsibility transferable
Document the normal checks and the actions a maintainer can safely take. Keep accounts and recovery information accessible to authorized people. Test that a second person can follow the important procedures.
Before launch, the business should know who provides this care, how it is funded and what happens if that arrangement ends. Practical ownership covers those responsibilities; change control explains how to make maintenance changes without unnecessarily disrupting the work.