Matrix: Application maintenance

How the installed product is maintained: defects, fixes, versions, technical debt, compatibility, third-party components, knowledge, end of life.

≈ 11 min readReading

In brief

8 dimensions, levels 0 to 5, 112 criteria.
Tool: self-assessment, choosing "Application maintenance".
Levels and criteria: original synthesis, references cited at the bottom of the page.

On this page

Overview
Fixes and versions
Debt and compatibility
Knowledge and life of the product
1. Technical knowledge and documentation
2. End of life and retirement
Sources and verification

Scope

The life of the installed product: handling of defects, fixes and maintained versions, numbering and release notes, technical debt, compatibility and version upgrades, third-party components and libraries, technical knowledge and documentation, end of life. The planning of enhancements falls under the "Project management" theme, and getting changes into production under the "Deployments" theme.

8 dimensions, six levels (0 to 5) and 112 observable criteria. To place your product: open the self-assessment for this theme. The calculation rules are here.

Overview#

Each cell is the level's signature for the dimension.

Dimension	0 · Handcrafted	1 · Locally tooled	2 · Shared	3 · Industrialized	4 · Integrated and governed	5 · Autonomous
Defect management	Defects are fixed as requests come in, with no trace.	Defects recorded.	Triage and severity.	Complete process.	Defects analyzed.	Defects prevented.
Fixes and supported versions	Only one state of the product: the fix is applied to whatever exists.	Versions identified.	Versions maintained.	Fixes under control.	Fixes tracked.	Fixes automated.
Numbering and release notes	Versions named by date or by habit, with no rule.	Simple numbering.	Meaningful numbering.	Useful notes.	Notes produced from the work done.	Automated release communication.
Technical debt	Debt piles up without anyone seeing it.	Debt perceived.	Debt listed.	Debt arbitrated.	Debt measured.	Debt under control.
Compatibility and version upgrades	Every version upgrade is an adventure.	Upgrades documented.	Upgrades verified.	Migration paths.	Compatibility managed.	Frictionless upgrades.
Third-party components and libraries	The third-party components are whatever a developer once installed.	Components listed.	Components tracked.	Updates planned.	Supply chain under control.	Dependencies monitored.
Technical knowledge and documentation	How the product works is known to one person.	Personal notes.	Technical documentation.	Documentation maintained.	Documentation generated and verified.	Knowledge accessible.
End of life and retirement	A feature disappears because it broke and no one repairs it.	Retirements decided.	Retirements announced.	Support policy.	Retirement supported.	Lifecycle steered.

Link with the global model

Dimensions of the global model most concerned: Testing and fixes, Industrialization and deployment, Documentation and traceability and Project management and roadmap.

Fixes and versions#

Defect management#

How is a defect received, qualified, fixed and tracked?

Level	Signature	Criteria to meet
0 · Handcrafted	Defects are fixed as requests come in, with no trace.	Starting point: no criteria.
1 · Locally tooled	Defects recorded.	Each defect is recorded in a tool, with a description. A person is assigned to each defect.
2 · Shared	Triage and severity.	Each defect is qualified: severity, product and version concerned, how to reproduce it. The expected fix time depends on severity. The person who reported the defect is informed of its fix.
3 · Industrialized	Complete process.	Each fixed defect is verified by someone other than the author of the fix. An automated test that reproduces the defect is added with the fix. Defects are linked to the versions in which they are fixed.
4 · Integrated and governed	Defects analyzed.	The backlog of open defects and their age are tracked. Causes (specification, code, data, environment) are analyzed in order to act on the most frequent ones. Defects are handled within the announced times for each severity, and deviations are tracked.
5 · Autonomous	Defects prevented.	A fixed defect triggers an automatic search for its twin elsewhere in the code. Defects detected in production are automatically attached to the change that caused them. The number of defects per version decreases, and this is tracked.

Effect on the user

A reported defect has a number, an owner and a deadline; you know where it stands.

Fixes and supported versions#

Which versions are maintained, and how is a fix delivered to them?

Level	Signature	Criteria to meet
0 · Handcrafted	Only one state of the product: the fix is applied to whatever exists.	Starting point: no criteria.
1 · Locally tooled	Versions identified.	Each installation knows its version. The versions delivered are kept.
2 · Shared	Versions maintained.	The list of supported versions is defined. A fix can be applied to a supported version without bringing enhancements into it. A fix made on one version is carried over to the other versions concerned.
3 · Industrialized	Fixes under control.	Fixes are delivered as numbered, tested versions. An urgent fix follows a shortened process, but keeps the essential tests. The carrying over of a fix to all supported versions is verified.
4 · Integrated and governed	Fixes tracked.	The versions installed at each customer are known, along with the fixes they are missing. The time between the fix and its application at the customer is measured. A fix can be installed hot or with minimal interruption.
5 · Autonomous	Fixes automated.	Fixes are proposed and applied automatically to the installations that accept them. A faulty fix is withdrawn automatically. The fix status of all installations is visible on a dashboard.

Effect on the user

A customer on a supported version receives their fix without having to change version.

Numbering and release notes#

Are versions numbered meaningfully and accompanied by clear explanations?

Level	Signature	Criteria to meet
0 · Handcrafted	Versions named by date or by habit, with no rule.	Starting point: no criteria.
1 · Locally tooled	Simple numbering.	Each version has a unique number. A deliverable no longer changes once published under a number.
2 · Shared	Meaningful numbering.	The numbering distinguishes incompatible changes, compatible additions and fixes (for example major version, minor version, patch). Each version has release notes. The notes list visible changes, fixes and points of attention.
3 · Industrialized	Useful notes.	Release notes are written separately for users and for administrators. Incompatible changes are flagged at the top, with the steps to follow. The notes are kept for all published versions.
4 · Integrated and governed	Notes produced from the work done.	Release notes are largely generated from the requests and fixes delivered. The version number is calculated by rules, not chosen by hand. A history of changes can be consulted by feature and by date.
5 · Autonomous	Automated release communication.	The customers concerned are notified automatically of a new version according to its effect on them. The nature of a version (incompatible, compatible) is verified automatically by comparison with the previous one. Customers' questions about a version enrich the following notes.

Effect on the user

A version's number tells you whether installing it is risky, and the notes tell you what changes.

Debt and compatibility#

Technical debt#

Do you know where the shortcuts were taken, what they cost, and when to pay them back?

Level	Signature	Criteria to meet
0 · Handcrafted	Debt piles up without anyone seeing it.	Starting point: no criteria.
1 · Locally tooled	Debt perceived.	The areas of the code that the team avoids touching are known. Deliberate shortcuts are flagged at the time they are taken.
2 · Shared	Debt listed.	Technical debt is entered in the backlog, with a description of its effect. Each debt item has an estimate of its repayment cost. A shortcut taken under constraint is recorded with its planned repayment date.
3 · Industrialized	Debt arbitrated.	A share of the time in each period is reserved for repaying debt. Debt is repaid first where the code is modified most often. New shortcuts are reviewed before being accepted.
4 · Integrated and governed	Debt measured.	Measures (complexity, duplication, test coverage, age of components) are tracked over time. The cost of debt is estimated in lost time and incidents. Debt is one of the decision criteria for a new feature.
5 · Autonomous	Debt under control.	A debt threshold is set, and exceeding it stops new features. Automated checks prevent certain types of debt from being introduced. Debt decreases from one period to the next, and this is tracked.

Effect on the user

The product remains easy to evolve, and speed is not gained on credit without anyone knowing.

Compatibility and version upgrades#

Is moving from one version to another predictable, tested and reversible?

Level	Signature	Criteria to meet
0 · Handcrafted	Every version upgrade is an adventure.	Starting point: no criteria.
1 · Locally tooled	Upgrades documented.	A version upgrade procedure is written. Backups before an upgrade are planned.
2 · Shared	Upgrades verified.	The upgrade from one version to the next is tested on a copy of real data. Existing data and customizations are preserved by the upgrade. A post-upgrade check verifies the essential elements.
3 · Industrialized	Migration paths.	Upgrade paths between supported versions are defined and tested. Changes to the data structure are applied by replayable scripts. A return to the previous version is planned and tested.
4 · Integrated and governed	Compatibility managed.	Incompatible changes go through a period in which old and new coexist (add, migrate, remove). Compatibility with customers' reports and extensions is verified before each version. The downtime of an upgrade is measured and reduced.
5 · Autonomous	Frictionless upgrades.	Upgrades are performed automatically, without noticeable interruption, with automatic rollback on failure. Compatibility is verified automatically for each known customer configuration. Customers choose the date of their upgrade within a defined range.

Effect on the user

A version upgrade loses nothing: no data, no customization, no report.

Third-party components and libraries#

Are the components used known, up to date and free of known vulnerabilities?

Level	Signature	Criteria to meet
0 · Handcrafted	The third-party components are whatever a developer once installed.	Starting point: no criteria.
1 · Locally tooled	Components listed.	The list of third-party components used is known. The version of each component is noted.
2 · Shared	Components tracked.	The list of components is kept in a file managed alongside the code. Abandoned components or components at end of support are identified. The license of each component is known and compatible with the intended use.
3 · Industrialized	Updates planned.	Components are updated at a defined interval, with regression tests. Known vulnerabilities in components are searched for by a tool. A serious vulnerability follows a rapid fix process.
4 · Integrated and governed	Supply chain under control.	Components are downloaded from approved sources. The complete list of components of each delivered version is kept. A critical component has an identified replacement.
5 · Autonomous	Dependencies monitored.	Security updates are proposed and tested automatically. Customers are informed automatically when a vulnerability affects their version. The average age of components is tracked as an indicator.

Effect on the user

A flaw published in a component is spotted and fixed before it becomes an incident.

Knowledge and life of the product#

Technical knowledge and documentation#

Does knowledge of the product depend on a few people, or is it shared and written down?

Level	Signature	Criteria to meet
0 · Handcrafted	How the product works is known to one person.	Starting point: no criteria.
1 · Locally tooled	Personal notes.	Technical notes exist on the critical parts. The people who know each part are identified.
2 · Shared	Technical documentation.	The general architecture and the dependencies are described in a shared document. Each important component has at least two people able to work on it. Operating and fix procedures are written down.
3 · Industrialized	Documentation maintained.	Technical documentation is stored with the code and updated along with it. Architecture decisions are recorded with their rationale. A person joining the product can build and run it by following the documentation.
4 · Integrated and governed	Documentation generated and verified.	Part of the documentation (objects, dependencies, schemas) is generated from the code and the metadata. Outdated documentation is detected in the review of each change. The distribution of knowledge is tracked in order to spot components mastered by too few people.
5 · Autonomous	Knowledge accessible.	The documentation can be queried through an assistant that draws on it. Questions put to the team automatically improve the documentation. Knowledge is passed on through a proven onboarding path.

Effect on the user

The departure of one person blocks neither a fix nor an enhancement.

End of life and retirement#

How do you retire a feature, a version or a product without surprises for users?

Level	Signature	Criteria to meet
0 · Handcrafted	A feature disappears because it broke and no one repairs it.	Starting point: no criteria.
1 · Locally tooled	Retirements decided.	Retirement decisions are made explicitly. The users of the retired feature are sought out.
2 · Shared	Retirements announced.	A retirement is announced with advance notice and a date. An alternative or a set of steps to follow is offered. The retired feature is flagged as deprecated during the notice period.
3 · Industrialized	Support policy.	A written policy defines the support duration of each version. The end-of-support date of each version is communicated as soon as it is published. The use of features being retired is measured in order to adjust the notice period.
4 · Integrated and governed	Retirement supported.	Customers using a version at end of support are contacted with a migration plan. The data of retired features is kept or exported according to a defined rule. Obsolete code and data are actually deleted after the planned period.
5 · Autonomous	Lifecycle steered.	Little-used features are identified automatically and proposed for retirement. Migrations to the alternatives are tooled for common cases. The cost of keeping each feature is known and feeds retirement decisions.

Effect on the user

A retirement is announced, explained and supported; no one discovers that a feature has disappeared.

Origin of the criteria

The dimensions are inspired by the references cited below; the levels and criteria are an original synthesis, not a reproduction of a framework. They are offered for discussion and adaptation, not as authoritative.

Sources and verification#

Martin Fowler — Technical Debt — technical debt: "interest" (extra effort on every change) and "principal" (the repayment); repay frequently modified code first
Semantic Versioning 2.0.0 (French version) — MAJOR.MINOR.PATCH number; a published version must no longer be modified
Martin Fowler — Parallel Change — expand (old and new coexist), migrate, then contract; also applicable to the evolution of a database schema
DORA — Software delivery performance metrics — time to restore service after a failed deployment, change failure rate
ISO/IEC 25010:2023 — Product quality model (SQuaRE) — maintainability among the quality characteristics of a software product; only the number of characteristics (nine) was verified, the standard is paid