Maintenance keeps existing system functionality working while its environment changes: customers arrive, datasets shift, or infrastructure evolves. It differs from improvement, which adds functionality or changes it substantially. In practice, the boundary can be blurry, and maintaining an ML system often takes more effort than building it from scratch. section 1.3
Plan for maintenance before release, not after the original team moves on. The people who built a system may leave, and its assumptions or business constraints may change. A maintainable design lets successors understand the system’s logic and keep it operating without depending on its creators. section 1.3 section 16.0
Make responsibility and response arrangements explicit:
- Name the people responsible for maintenance and support, and remind them of their roles rather than assuming everyone agrees. section 16.6
- Arrange on-call coverage for critical incidents. Balance efficient staffing against enough redundancy to handle peak demand without exhausting the team. section 16.6
- Keep documentation current and accessible to everyone involved. Begin with small fixes, learn from colleagues, and avoid complexity that does not address a real need. section 16.6
Match the arrangement to the organization
A large retailer with nontechnical business units needs coordination across levels of management: a detailed RACI matrix and delivery, executive, and business sign-offs can establish who is involved. A smaller image-search company faces continuous traffic and peaks across API handlers, an index, ranking models, and internal tools. There, a senior engineer responsible for each component, backed by a primary on-call responder who can escalate to component specialists, fits the operational problem. section 16.5
