Méthode SOLIDITE :  Comparatif avec et sans

SANS la méthode SOLIDITE

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

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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…

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.

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.

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.

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.

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.

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.

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.

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.

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.