Un Système Interne Vieillissant : Le Réparer ou Le Reconstruire

La situation à laquelle les entreprises sont confrontées aujourd'hui

Les entreprises utilisant un système interne de plus de dix ans se trouvent généralement dans la même situation. Le système fonctionne toujours. Il n'y a pas de pannes majeures. Il suffit qu'une petite demande prenne deux semaines, et qu'une seule personne dans l'entreprise puisse s'en occuper.

Cet état est dangereux car le problème s'aggrave progressivement. Un système qui s'arrête soudainement obtient immédiatement un budget. Mais un système qui devient un peu plus lent et un peu plus exigeant chaque année passe avec un verdict annuel de "nous avons également surmonté celui-ci". Laissez suffisamment d'années s'accumuler et trois choses arrivent en même temps.

Tout d'abord, la personne qui comprend le système part à la retraite. Les règles commerciales non documentées partent avec elle. Deuxièmement, le support de sécurité pour la technologie sous-jacente prend fin. Une fois qu'une version de langage ou de base de données n'est plus supportée, aucun correctif n'apparaît même lorsqu'une vulnérabilité est trouvée. Troisièmement, de nouvelles exigences ne peuvent plus être ajoutées. Les demandes de support mobile, d'intégration de services externes ou d'analyse de données sont rejetées avec "le système actuel ne peut pas faire cela".

Lorsque les trois arrivent ensemble, la seule option restante est une reconstruction complète. Et une reconstruction complète est l'option la plus coûteuse et la plus risquée qui soit.

Cinq signaux indiquant qu'un remplacement mérite d'être envisagé

Si trois ou plusieurs des éléments suivants s'appliquent, il est temps de commencer à envisager un remplacement.

1. Le coût du changement est asymétrique. Ajouter un seul champ à un écran prend des jours. Si le temps de développement pour une demande qui semble triviale pour les utilisateurs ne diffère guère de celui d'une demande majeure, la structure ne peut déjà plus absorber le changement.

2. La maintenance repose sur une seule personne. Un système que seule une personne peut toucher transforme les vacances et la démission de cette personne en un risque commercial. C'est un problème structurel, pas un problème de personnel.

3. Le support pour la technologie sous-jacente a pris fin. Vérifiez les dates officielles de fin de support pour le runtime de langage, le framework et la base de données utilisés. Si elles sont déjà dépassées, un incident de sécurité n'est qu'une question de temps.

4. Les données ne peuvent pas être extraites. Si produire les chiffres nécessaires pour une décision de gestion nécessite que quelqu'un écrive des requêtes à la main, ou ouvre plusieurs écrans et les totalise manuellement, le système retient les données en otage.

5. Les solutions de contournement se multiplient. Si le domaine que les utilisateurs commerciaux gèrent dans des feuilles de calcul plutôt que dans le système s'élargit, le système échoue à refléter les opérations réelles. Comme ces processus parallèles ne sont enregistrés nulle part, le problème est invisible si l'on ne regarde que le système.

Calculez le coût de sa conservation

Les discussions sur le remplacement stagnent généralement sur la question "il fonctionne encore, alors pourquoi dépenser de l'argent". Répondre à cela nécessite de montrer en chiffres que le maintien du système entraîne également des coûts. Totalisez les quatre éléments suivants.

Les trois premiers sont des coûts déjà payés mais non comptabilisés. Le quatrième n'est pas encore survenu mais s'accumule en tant que probabilité.

Ce qui suit est un exemple hypothétique destiné à illustrer la méthode de calcul ; les valeurs réelles varieront selon les circonstances de chaque entreprise. Avec 30 demandes de changement par an, un temps d'attente moyen de 10 jours par demande, et le coût d'opportunité de cette attente fixé à 150 000 KRW par jour, le coût de retard seul s'élève à 45 000 000 KRW par an. Ajoutez deux départements chacun dépensant cinq heures par semaine sur la gestion de feuilles de calcul en double et, à un coût horaire de travail entièrement chargé de 25 000 KRW, un autre 13 000 000 KRW par an.

Si le total est de 58 000 000 KRW par an, sur trois ans, cela représente 170 000 000 KRW. Ce n'est qu'à ce stade qu'un chiffre existe qui peut être comparé au coût de remplacement. Conserver le système n'est pas gratuit ; c'est une dépense pour laquelle aucune facture n'arrive.

Pourquoi une reconstruction complète est dangereuse

Une fois le remplacement décidé, la première approche qui vient à l'esprit est une reconstruction complète : arrêter l'ancien système, construire le nouveau et effectuer la transition en une seule fois à une date donnée. C'est intuitif, mais cela comporte trois risques.

Le bénéfice est nul jusqu'à la fin du projet. Lors d'une reconstruction de douze mois, l'organisation paie pendant onze mois et ne ressent aucune amélioration. Si l'environnement commercial évolue pendant cette période, le projet subit une pression pour être annulé.

Les exigences deviennent obsolètes en cours de route. Les exigences établies au lancement diffèrent de ce que le côté commercial souhaite un an plus tard. Si la différence est reflétée, le calendrier glisse ; si elle n'est pas reflétée, vous terminez avec un système obsolète.

Le risque se concentre au moment de la transition. Comme chaque fonction change en même temps, il n'y a pas de moyen de retour prêt si quelque chose tourne mal le jour J. Et quelque chose tourne presque toujours mal, car le système existant conserve invariablement des règles d'exception que personne ne se souvient.

Migration incrémentale comme alternative

Au lieu d'un remplacement total, il existe une approche qui laisse le système existant en place et déplace les fonctions une par une. La séquence est la suivante.

Étape 1 — Définir les limites

Divisez le système actuel en blocs de fonctionnalité. Séparez selon des lignes opérationnelles telles que les commandes, l'inventaire, le règlement et le personnel, mais tracez les lignes sur la base de qui possède les données. Lorsque plusieurs blocs écrivent directement dans les mêmes tables, ce point devient le plus grand obstacle par la suite.

Lors de la définition des limites, suivez le flux de données plutôt que l'organigramme. Deux départements qui modifient conjointement les mêmes données forment un seul bloc ; inversement, un seul département peut être divisé lorsque ses données sont entièrement séparées.

Étape 2 — Séparer d'abord les lectures

La première tâche la plus sûre est la fonctionnalité de requête. Les fonctionnalités qui ne font que lire des données, telles que les tableaux de bord, les statistiques et les rapports, peuvent être construites dans le nouveau système sans affecter l'existant. S'ils échouent, les écrans existants restent en place, donc le retour en arrière est facile, et les utilisateurs commerciaux ressentent immédiatement l'amélioration.

Il y a un autre avantage à ce stade. La construction de la fonctionnalité de requête expose les problèmes dans les données existantes. Les doublons de dossiers clients, les dates dans des formats cassés et les lignes avec des valeurs de code vides sont tous découverts ici. Prendre connaissance de ces problèmes avant que la fonctionnalité d'écriture ne soit déplacée est très important.

Étape 3 — Migrer la fonctionnalité d'écriture

Une fois que les requêtes ont validé l'approche, déplacez les fonctions d'entrée et de modification. Deux systèmes géreront les mêmes données pendant un certain temps, donc désignez un côté comme la source de vérité. Laissez les deux modifiables et des incohérences apparaîtront, et les traquer prendra plus de temps que la migration elle-même.

Il est plus sûr de séquencer la migration en commençant par des fonctions à faible utilisation et à faible impact. Mais déplacer des fonctions que personne n'utilise ne fournit aucune validation, donc une fonction qui est réellement utilisée mais qui pourrait supporter une interruption d'une journée constitue le meilleur point de départ.

Étape 4 — Réduire le système existant

Supprimez les fonctions migrées du système existant. Si vous les laissez, certains utilisateurs continueront à utiliser les anciennes interfaces, et vous vous retrouverez à maintenir deux systèmes de manière permanente. Reporter cette étape est la raison la plus courante pour laquelle la migration incrémentale échoue.

Si la suppression est difficile, au minimum bloquez l'accès et passez la fonction en mode lecture seule. Fixez ensuite une date pour la retirer complètement. Un plan de désaffectation sans date n'est pas exécuté.

Quelle approche adopter

Une reconstruction complète n'est pas toujours erronée. Lorsque la portée est réduite, que les règles commerciales sont documentées et qu'une interruption de quelques heures est acceptable, tout changer d'un coup est plus rapide et moins coûteux. Le critère décisif n'est pas l'âge du système mais où les règles sont enregistrées.

Qu'est-ce qui cause réellement des problèmes dans la migration des données

Schedules slip because of data rather than feature development. Older systems accumulate conditions such as these.

• The same customer registered several times under different spellings
• Dates, telephone numbers and business registration numbers formatted differently by period
• Rows with mandatory fields left empty
• Data still referencing code values that no longer exist
• Rows merely flagged as deleted but in fact still present

Discover these problems during the migration stage and the schedule will certainly slip. Investigate in advance, before work begins, and decide first what will be cleaned up and what will be discarded. Attempt to clean all historical data perfectly and the migration itself will never finish. Cleaning only the last few years and retaining the rest as read-only archive is often the realistic course.

An opportunity to redesign security and access rights

Replacement is also a rare opportunity to put the security regime in order. Older systems generally have loose permission boundaries and are run with most staff able to see more data than they need. Settle the following items as part of the migration.

Minimisation of access rights. Separate visibility so that each role sees only the data it needs. Carry the existing system's permission structure across unchanged and the old problems come across with it.

Storage location and retention period for personal data. Document which personal data is stored where and when it is destroyed. Where the move is to the cloud, the country in which data is stored must also be confirmed.

Retention of processing records. Record who changed what and when. Older systems frequently lack these records, leaving no way to trace the cause when something goes wrong.

How to persuade the executive

Replacement budgets are rarely approved on technical arguments. Explanations such as "the architecture is outdated" or "technical support has ended" do not register as urgent with the person signing off. Recast them as the following three.

The money leaking now. The total of the delay, workaround and error costs calculated above. The essential point is that this is already being spent even without replacement.

What cannot be done. Compile a list of the requests turned down over the past year on the grounds that the current system cannot support them. Where any of them connect to revenue or customer attrition, put those first. Lost opportunity is a stronger argument than maintenance cost.

The worst case. Estimate the duration and cost of recovery if the sole maintainer resigns, or if an incident occurs in an out-of-support component. Low probability still moves a decision when the scale is large.

Having presented all three, request approval for the first stage of the incremental migration only. Ask for the entire budget at once and the review period lengthens, while the situation deteriorates further in the meantime.

Setting the schedule and the staffing

Schedule is what most often goes wrong in an incremental migration. Account for three things in advance.

Put the business side's time into the schedule. The scarcest resource in a migration project is not developers but business users who know the rules. They participate while carrying their day jobs, so unless the available hours are agreed in advance, the schedule slips at every validation step.

Include the parallel operation period in the calculation. Even after a function has been moved, both systems must run together for a time. Operational load actually increases during that period. Fail to reflect this in the schedule and budget and you will be short of people at the final stage.

Allow separate time for data clean-up. The data integrity problems discussed above can proceed in parallel with development, but they require their own time and their own owner. Bury them inside the development schedule and they will certainly slip.

What to check when working with an external supplier

It is often impractical to carry out a migration with internal staff alone. If you are considering an external supplier, confirm the following before signing.

Does the deliverable include documentation. Receive only code and the same problem recurs a few years later. Business rule specifications, data structure descriptions and operating procedures must all be included in the deliverables.

Is the handover arrangement defined for after the migration. Internal staff must be able to operate the system once the build is complete. Specify the handover period and the scope of training in the contract.

Can the contract be split by stage. Contract for the whole thing at once and it becomes difficult to change direction midway. A structure in which the first stage is performed and the remainder decided afterwards is safer for both parties.

Are the rights to our data clear. If real data is used during development, document what data moves where and how it is destroyed on completion.

What to prepare before starting

Whichever approach is taken, secure the following three things before work begins.

Documentation of the current business rules. Rules that exist only in code are invariably lost during migration. A perfect specification is not required, but exception handling and approval conditions must at least be written down.

A data integrity review. Survey the current state against the items set out above and decide the scope of the clean-up.

A rollback plan. For each stage, define how to reverse it if something goes wrong. A stage that cannot be reversed is by that fact too large a stage, and is a signal that it must be broken down further.

Summary

The cost of an ageing system appears in the form of delay and dependency rather than outages. That is why it is recognised late.

• Review the five signals: cost of change, concentration of expertise, end of technical support, data accessibility, and workarounds.
• Calculate the cost of keeping the system across four items — delay, workarounds, errors and risk — to produce a figure comparable with the cost of replacement.
• If the rules survive only in the code, a full rebuild is dangerous.
• Move query functionality first, and always remove migrated functions from the existing system.
• Investigate data integrity before work begins and fix the scope of clean-up in advance.
• Take the opportunity to redesign access rights and the personal data retention policy at the same time.

More important than whether to replace is not deferring the decision. If three of the five signals apply, beginning the review this year is cheaper than a full rebuild next year.