Le manifeste agile date de 2001. Néanmoins, cette vague de l'agilité, annonciatrice de réconciliation entre DSI et métiers, d’efficience et de gains économiques, submerge depuis cinq à six ans un grand nombre de projets informatiques. Et toutes les grandes entreprises se sont engouffrées dans ces nouvelles méthodes de déploiement.
Deux modes d’organisation des projets s’affrontent
Pour ces projets, des équipes indépendantes (incluant le métier) ont été mises en place dans un coin des DSI ou des directions métiers. Actuellement, il s’agit essentiellement de projets autour de la relation client ou en relation avec des sites Internet ou du marketing.
Après quelques projets pilotes, de nouvelles approches ont favorisé - entre autres - un réchauffement des relations entre parties prenantes : un droit à l’erreur et à la reformulation du besoin, des livraisons fréquentes, des délais courts, des face-à-face avec tous les protagonistes dans une organisation de type pizza team, de l’excellence, de la simplicité, une holacratie (organisation indépendante), la recherche de l’optimisation des compétences, la non-appréhension de changer d’orientation pour recadrer les livrables aux besoins… Bref, la mouvance Agile définit de nouvelles relations avec le métier. Et de très nombreuses expériences réussies prouvent combien cette organisation porte ses fruits.
Une abondance de projets basés sur l’approche agile sont apparus, chacun dans leur coin, sur des sujets très orientés front office. Cela a engendré le besoin d’interconnexions avec le back office (le legacy). Or, ces derniers évoluent via des projets organisés à travers des cycles en V. Les premières querelles ont alors germé autour de problématiques de synchronisation et de rapidité d’évolution du legacy pour ne pas perturber les livraisons et les tests des équipes agiles.
L’abondance des projets basés sur l’approche agile a soulevé à elle seule un autre problème structurel : le manque de vision globale.
Les API dénouent la situation et ouvrent des perspectives
Pour un fonctionnement plus harmonieux de l’entreprise, une réduction des dépendances s’impose entre les projets en V et l’afflux de projets agiles. Limiter les frictions peut passer par l’absence d’interaction directe entre applications grâce aux API. Des API plus rapides à développer avec les outils actuels.
Mettre en place des API permet d’une part d’éviter les interconnexions hasardeuses avec des méthodes historiques coûteuses à maintenir et, d’autre part, de rendre les développements de back office indépendants des interfaces, tout en ouvrant l’accès aux applications de façon contrôlée. De multiples solutions de gestion des API sont matures et disponibles. Ces développements devront être réalisés en parallèle des projets legacy, par d’autres équipes connaissant le legacy et des experts de « l’API management ». Ainsi, il devient possible de fournir des solutions rapides via des projets indépendants pour ne pas perturber les projets legacy.
De même, pour les projets agiles, il conviendra de mettre en place des API en entrée et en sortie afin de ne gérer plus que les demi-interfaces et simplifier la maintenance et les évolutions. De nouveaux socles techniques émergent pour partager les composants et gagner en efficacité. Avec les API, les projets en V ou agile évoluent de manière indépendante et leurs tests sont réalisés plus simplement. Avec, par exemple, la possibilité de mettre en place des bouchons ou des simulacres, directement à partir des outils d’API management. Pour l’entreprise, le legacy couplé aux API n’est donc plus un frein au déploiement agile.
Très bonne lecture...Sur ce qu'il ne faudrait pas faire. on dirait que la réponse de TNP aux problèmes qu'ils ne savent pas gérer est de revenir aux techniques ancestrales qui ont su montrer qu'elles n'étaient pas adaptées.
Signaler un abusOui la problématique citée est réelle, et oui cette flexibilité d'un côté, face à un côté existant apporte une désynchronisation, mais comment on fait les grandes entreprises IT (Microsoft, Amazon, Google) et surtout comment font les grands groupes ? ils rendent agiles ce legacy tout simplement. M. Diz, arrêtez de regarder en arrière, sortez de votre bureau et allez rejoindre sur le terrain vos équipes et vous verrez que vous proposez une solution parce que vous ne savez pas, tout simplement.
On n'appelle pas ça de ESB? J'ai travaillé il y longtemps avec des solutions "middleware", Biztalk, Tibco, etc, justement pour faire abstraction des applications legacy et se focaliser sur les nouveaux projets à valeur ajoutée.
Signaler un abus