Evolutive maintenance: definition, examples and rules for managing it

Evolutive maintenance covers the work that makes a live application evolve: new features, improvements to what exists, compliance with a new rule. It differs from corrective maintenance, which repairs, and from adaptive maintenance, which follows the technical environment. This guide gives the definition, examples, and how to frame it with a provider.

It is written for managing directors, CIOs and product managers whose application is in production and keeps changing. In a third-party application maintenance (TMA) contract, the evolutive part is the one decided as you go: it commits the scope, the budget and the priorities.

Evolutive maintenance: definition

Evolutive maintenance means the work that changes what an application already in service does, or the way it does it. You are not repairing, and you are not bringing up to date: you are adding, improving, bringing into compliance.

The general administrative clauses for public information and communication technology contracts, the CCAG-TIC 2021, give a definition that serves as a reference well beyond public procurement. Its article 38 understands “evolutive” as “maintenance measures aimed at making one or more applications evolve”. It places three kinds of work under that word.

• Adding features. A new export, a new user role, a new step in a journey.
• Improving operation or ergonomics. A simplified screen, faster processing, shorter data entry.
• Taking new legal or regulatory obligations into account. A rule changes, the application must follow.

Source: CCAG-TIC 2021, article 38 (order of 30 March 2021). The examples are ours.

The same article defines third-party application maintenance as the services that keep an information system in a state that allows it to fulfil its function, and specifies that they may also cover the evolution or adaptation of software. Evolutive maintenance is therefore part of a TMA when the contract provides for it, not automatically.

Evolutive, corrective, adaptive, preventive: the boundaries

The four families of maintenance do not answer the same question. Telling them apart is not an exercise in vocabulary: each has its own trigger and its own degree of urgency, and may have its own way of being invoiced.

Definitions based on CCAG-TIC 2021, article 38. The questions and examples are ours.

Defect or evolution? This is the boundary that gives rise to disagreements. A defect is a deviation from what was agreed: specification, signed acceptance, documented behaviour. If the application does what was planned and it is no longer what you want, it is an evolution. The reference is a written document, not the feeling of the person reporting it.

Adaptation or evolution? Adaptive maintenance absorbs a change in the technical environment (operating system, database, exchange interfaces, components) without adding anything to the service provided. As soon as you take the opportunity to modify a feature, the part added is evolutive.

Examples of evolutive maintenance

A few cases, from the lightest to the heaviest.

• Adding a field, a filter or a column to an existing screen.
• Creating a new export or a new document template.
• Opening a new user role, with its rights.
• Connecting the application to a third-party service: payment, signature, sending messages.
• Reviewing a journey that users find too long.
• Speeding up a process that has become slow as the data has grown.
• Complying with a new obligation, such as receiving electronic invoices or the accessibility of online services.

Conversely, the following are not part of it: fixing a wrong calculation (corrective), applying a security update (preventive) or moving to a new version of a database (adaptive).

Evolution or new project: where maintenance stops

Not every evolution belongs in a maintenance contract. Four signs show that you are leaving maintenance and entering a project.

• The size. The work no longer fits within the usual pace of maintenance deliveries.
• The architecture. The request affects the data model or the structure of the application, not a screen.
• The audience. It opens the application to new users or to a new use.
• The risk. It requires full acceptance testing, a data migration or a planned switchover.

A project is run differently: scoping, its own budget, a dedicated team, a schedule. The simplest approach is to write the threshold into the contract, for example a workload above which a request leaves maintenance and is estimated separately. The figure depends on the application; what matters is that it exists.

A project of this size also needs someone to lead it on the client side. If the company has no technical director available to do so, an interim CTO can take charge of it for the duration of the work.

How an evolution is ordered and paid for

Corrective and preventive maintenance lend themselves to a fixed-price commitment: their volume can be estimated from what exists. Evolutive maintenance, for its part, depends on what the company decides. There are three ways to contract it, and they coexist.

The three options can be combined: an allowance for small requests, a quotation above the threshold. In every case, two rules protect both parties: no development without written agreement on the scope and the workload, and a record of time spent that is accessible without having to ask for it. Our guide to the application maintenance contract details the corresponding clauses.

Managing evolutive maintenance: six rules

• A single list of requests. Every evolution goes into it, wherever it comes from, with its requester and its rationale.
• Qualification on entry. Each request is classified (defect, adaptation, evolution) before it is handled.
• Priorities set by the business. The provider estimates and raises alerts; the order of work is decided on the client side.
• An estimate before launch. With what it includes: development, testing, documentation, release to production.
• Regression tests. An evolution must not break what exists: testing and acceptance are part of the work, not an option.
• A regular review. What has been delivered, what has been used, what comes next.

What the company keeps when a provider evolves its application

• The rights to the code added. With an external provider, they require a written assignment: paying for a development is not enough to hold the rights to it, as Bpifrance Création points out. Check that the assignment provided for in the contract also covers evolutions, not only the original version.
• The code repository and the access. Each evolution is delivered into a repository in the company’s name.
• The documentation. It is updated with the evolution, otherwise it stops describing the application.
• The decision. What goes into the application, and in what order, remains an internal decision.

These points apply to any maintenance entrusted to a third party. They are developed in our guide to outsourcing your application maintenance.

Frequently asked questions

Evolutive maintenance: frame it before you launch it

Evolutive maintenance is what keeps an application useful over time. It goes well when three things are written down: what distinguishes an evolution from a defect, how an evolution is estimated, and who decides the priorities.

The iones team provides application maintenance for existing applications, evolutions included, and can start with an audit of what exists. You can also write to us for an initial discussion.