Application management

Support answers “something is broken, can you fix it?”. Maintenance also answers “what breaks next, and what do we do about it before then?”. The second needs time set aside for preventive work, such as updates, restore tests and decommissioning, and that time belongs in the contract. The work can run through tickets like everything else, but it should not have to wait for something to break.

What is included

• Planned updates of frameworks, runtimes and libraries, at times agreed in advance.
• A documented restore: who does what, in what order, and how it works when the person who knows is not there.
• Ongoing removal of code, flags and integrations that are no longer used.
• Security updates with an agreed time from release to production, set by how serious the flaw is and how exposed the system is.

Why are updates hard?

Changing the version number is the small step. What takes time is finding out what the update changes in your particular system. If the most important flows have automated tests, running them gives you much of the answer. If not, someone has to click through the flows by hand, and that work is easy to put off until several updates have piled up. That is why we count tests on the most important flows as maintenance, not just development.

Three questions for your current supplier

1. When did you last actually restore a backup, and how long did it take?
2. How many of our dependencies are more than one major version behind today?
3. Which parts of the system does only one person on your side understand?

The answers tell you something a monthly report of tickets closed does not: whether anyone works on the system before it breaks. We take over systems we did not build, and those three questions are where we start. The infrastructure side is covered under cloud and infrastructure.