Accueil > Méthode SOLIDITE :  Comparatif avec et sans
Sébastien Thomas
14 avril 2022

Méthode SOLIDITE :  Comparatif avec et sans

Méthode SOLIDITE : Comparatif avec et sans

Sans la méthode SOLIDITE, les conséquences des interblocages des projets sont souvent méconnues, nombreuses et complexes. En appliquant les 8 règles de cette méthode, on parvient à les adresser. Nous vous proposons ci-dessous un comparatif fonctionnel sans la méthode SOLIDITE puis avec la méthode SOLIDITE.

 

SANS la méthode SOLIDITE

AVEC la méthode SOLIDITE
Budget impacté très fortement

Les études d’impacts et les mises à jour contraintes lors de chaque évolution sont nombreuses. Elles sont dues aux interdépendances.

 

Budget Maitrisé 

L’étude d’impacts se limite au périmètre du projet. Les projets connexes ne sont pas impactés.

Les interfaces exposées représentent un coût initial mais il est amorti très rapidement.

 

Latence de développement

Une évolution nécessaire sur un projet entraine des évolutions contraintes sur les projets dépendants. La livraison de tous les projets impactés devra attendre le projet le plus en retard pour éviter les régressions.

 

Vélocité non impactée

Tant que les interfaces exposées respectent les contrats. Chaque projet est maître de son agenda et de ses livraisons.

Aucun impact sur les projets annexes.

Arrêts de production

Ils sont souvent longs (quelques heures à plusieurs jours) car de multiples projets (applications, api) doivent être livrées concomitamment.

 

Peu d’arrêt de production

Avec la méthode, les mises à jour impactent un nombre réduit d’applications. Combiné à des techniques de déploiements automatisés de type blue /green, le downtime peut même être négligeable ou nul.

Mécanique interne exposée 

Des données brutes et des fonctionnalités internes complexes peuvent être exposées.

 

Aucune exposition non désirée.

Les interfaces exposées sont documentées et adaptées au besoin des clients.

Seul le strict nécessaire est mis à disposition par des profils de droits spécifiques.

Perte de maîtrise 

Des calculs et traitements sont effectués par les projets connexes pour lesquels une MOE différente est responsable.

Cela reporte la compréhension de mécaniques internes sur les projets clients. Des erreurs du fait d’une mauvaise connaissance peuvent compromettre les résultats ou les données.

Maitrise conservée

Seules des interfaces sont exposées. Aucune fonction interne ou donnée brute n’est accessible.

Aucun « truc », aucune mécanique interne n’est laissée à l’appréciation des autres projets. Pas de risque d’incompréhension.

 

Ecarts systématiques préjudiciables

Les différentes applications ont la même source de données mais les requêtes peuvent être différentes ou exécutées à des moments différents.

Des traitements en erreur ou non terminés entrainent des données incomplètes ou incohérentes.

Données et résultats cohérents 

Les données et fonctions exposées restent cohérentes.

Des mécanismes simples peuvent être mis en place pour éviter les impacts des traitements en cours sur les données à disposition des clients.

 

Tests complexes et risques de régression importants du fait de la perte de contrôle et la multiplicité des applications connexes.

 

 

 

Tests Maitrisés et risques de régression contenus

Seul le périmètre du projet et ces interfaces sont à tester.

Le nombre de tests à effectuer diminue radicalement.

Cumulés avec des tests automatisés des interfaces, les risques de régressions sont très faibles.

Exposition aux risques

Dans un système complexe, si en plus la responsabilité est multiple, les risques sont exponentiels : fuites de données, déclarations fiscales ou calculs de rendement erronés, délais contractuels ou légaux non respectés.

Exposition limitée

On ne pourra jamais atteindre le 0 risque.

Cependant, si chaque projet protège son périmètre fonctionnel, si ses interfaces et ses abstractions sont testées, le risque est drastiquement réduit.

Monitoring complexe et/ou limité

On peut généralement connaitre le profil qui se connecte. Mais très peu de détails émergent vraiment sur l’application / les types de traitements qui initient la requête : fréquence, volumétrie, impact de la charge sur les serveurs, fonctions et versions qu’ils utilisent…

Monitoring simplifié

La maitrise du périmètre implique un monitoring simplifié. Les applications et serveurs dont le projet est responsable peuvent être monitorés facilement.

Mais surtout les interfaces le son et leur monitoring est une mine d’or pour une gestion sereine du projet et donc du SI.

Budget gaspillé pour maintenir du code mort

Des traitements étant déportés hors du périmètre projet, comment savoir si des outils essentiels mais peu fréquemment lancés (ex : rapports de fin d’année) utilisent toujours une API, une application ou une table de données du projet ?

Pas d’autre solution que de considérer que c’est le cas et donc dépenser du temps pour gérer l’impact de code probablement mort.

Code mort détecté rapidement

Le monitoring complet donne des indications sur les fonctions / données véritablement utilisées.

Un monitoring sur de longues période permettra de découvrir rapidement les fonctions inutilisées.

Si seule une poignée d’applications connexes utilisent encore une vieille version, des actions ciblées permettront de les basculer sur une version plus récente.

Budget dépensé pour maintenir du code dupliqué

Des fonctions utiles à plusieurs projets connexes sont souvent des copier/coller à peine différents les uns des autres.

Ces codes dupliqués doivent être maintenus dans chacun des différents projets.

Rationalisation et mutualisation du code

Avec la méthode, le code n’est plus disséminé aux quatre vents. Les fonctions et données sont disponibles dans le périmètre du projet, ce qui réduit le code à maintenir et rationalise l’ensemble du SI.

Le projet peut décider seul un refactoring sans impacter ces clients et sans devoir déléguer l’implémentation.

Obsolescence et perte de support éditeur 

Les interdépendances rendent le refactoring fonctionnel et technique difficile voire impossible. Les technologies évoluent de plus en plus vite. Les éditeurs ne supportent pas les versions longtemps. Un projet qui ne répercute pas une mise à jour éditeur immédiatement n’évoluera plus.

Mises à jour et nouvelles implémentations simplifiées

Le projet peut décider de mettre à jour, changer de langage, de version de serveur, voire de tout changer.

Tant que les interfaces renvoient des données correspondant au contrat, peu importe l’implémentation.

Recrutement difficile et fuite des cerveaux

Maintenir un SI complexe avec de multiples technologies vieillissantes… Ce ne sont pas de bons arguments de recrutement.

L’intégration de nouveaux ingénieurs devient aléatoire, laborieuse et anxiogène.

Sans perspective d’évolution intéressante, la qualité du travail et la motivation sont en berne. Quand elles n’entrainent pas la fuite des bons éléments.

 

 

 

 

Recrutement facilité et sentiment de lassitude évité

C’est une spirale vertueuse. Des projets maitrisés, c’est un SI maitrisé, des technologies qui évoluent plus simplement.

Il peut rester des projets sur des technologies vieillissantes mais ils n’impactent pas les autres. Leur réécriture devient possible, il ne reste qu’à la planifier au bon moment.

Il devient alors plus aisé de recruter mais aussi de faire des passations de connaissances.

Les bons éléments sont moins lassés car ils trouveront toujours un nouveau terrain de jeu.

 

 

Pour continuer sur la méthode SOLIDITE, nous vous invitons à consulter notre article sur les 8 bonnes idées à nuancer pour faire évoluer votre projet.

 

 

Nos autres articles
Commentaires
Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

Restez au courant des dernières actualités !
Le meilleur de l’actualité sur le Cloud, le DevOps, l’IT directement dans votre boîte mail.