Comment choisir vos premières applications à transformer

Fouad Hamdi
VMware Pivotal Labs Paris
5 min readJul 31, 2019

Chez Pivotal, nous accompagnons régulièrement nos clients dans la transformation de leurs applications.

Par transformation, on entend généralement l’une des activités suivantes¹:

  • Re-hoster” l’application en la “containerisant” puis en la déployant sur PKS
  • “Re-platformer” l’application après l’avoir modifié en adressant quelques-uns des Twelve Factors. Ce type d’application est en général déployé sur le PAS.
  • “Re-factoriser” l’application en la rendant cloud native. On parle dans ce cas de modernisation. Ces applications sont également déployées sur le PAS.
  • “Re-architecturer” l’application en la réécrivant complètement (par exemple pour des applications de type mainframe)

“Mais quelle application doit-on transformer en premier ?” est l’une des questions souvent posées par nos clients.

Pour y répondre, nous nous appuyons sur un certain nombre de critères et d’outils maison. Parmi ces critères, un score technique est attribué aux applications selon leur complexité et leur niveau de compatibilité avec les Twelve Factors.

La méthodologie SNAP est un des moyens employés pour déterminer ce score. Elle s’avère cependant consommatrice de temps face à des portfolios contenant plusieurs centaines d’applications.

Pour accélérer ce processus, Steve Woods et Jonathan Newell ont créé Pivotal App Analyzer (PAA), un outil capable d’analyser automatiquement un portfolio applicatif.

Développé en Go, PAA peut estimer (entre autres choses) le score technique des applications grâce à des règles et des calculs statistiques. Compatible avec plusieurs langages, il est également configurable pour lui permettre de fonctionner dans différents contextes.

Pour respecter la confidentialité de nos clients, on exécute en général PAA directement sur site: inutile donc de partager le code source pour bénéficier de l’analyse.

Concrètement, PAA est un simple fichier binaire nommé forge qu’on lance soit pour effectuer une analyse, soit pour en visualiser les résultats.

Par exemple, voici quelques applications composant mon portfolio:

Un petit portfolio applicatif

Pour l’analyser, on lance depuis un terminal la commande² forge -p .

Les informations affichées dans la console sont déjà très intéressantes à observer:

Les résultats de l’analyse

On y remarque les langages détectés par PAA et un tableau récapitulatif contenant le score technique estimé et la transformation recommandée.

Les résultats complets sont stockés dans une base de données locale. Celle-ci conserve l’historique des analyses et est consultable dans l’IHM de visualisation.

La commande forge vulcan-ui démarre cette IHM:

Page d’accueil de l’IHM de visualisation

Dans le tableau récapitulatif, on remplit avec le client la colonne nommée Business Value pour attribuer un score (une note de 0 à 10) qui correspond à la valeur stratégique et/ou financière de l’application.

Cette valeur combinée au score technique permet de représenter graphiquement le portfolio et de choisir les premières applications à transformer:

Une vue des applications en fonction de leurs scores technique et business

Une stratégie de sélection classique est de commencer à transformer les applications qui ont le plus de valeur business et qui ne présentent pas trop de difficultés pour se faire la main avec la plateforme de déploiement et la méthodologie Pivotal.

Dans notre exemple, on se concentrera probablement sur spring-boot-monolith, une application à la fois stratégique et facile à déployer sur le cloud (score technique de 10). On poursuivra ensuite avec legacy-app (importance business) ou example-ruby-app (facile à déployer et assez importante) par exemple.

Il est également possible de voir plus de détails dans la vue Application:

Détails d’une application

Certains résultats sont associés à des conseils ou des recettes expliquant comment le code peut être modifié pour le rendre plus “cloud friendly”:

Une combinaison de conseils et de recettes pour améliorer l’application

Nous avons vu comment Pivotal App Analyzer nous fait gagner énormément de temps et d’énergie dans l’analyse des applications à transformer.

En mettant en perspective les applications en fonction de leurs scores technique et business, l’outil nous permet de mieux choisir celles à transformer en premier.

En réalité, d’autres critères sont susceptibles d’altérer cet ordre mais gardons cela pour un futur épisode…

Pour conclure, la video ci-dessous contient une démonstration de Pivotal App Analyzer par Steve Woods, l’un de ses créateurs:

Pivotal Labs

Pivotal Labs, leader du développement agile depuis plus de 20 ans, accompagne les entreprises pour résoudre leurs défis les plus importants. Au-delà d’écrire du code en binôme, nos développeurs, nos designers et nos product managers font partie intégrante de votre équipe.

Grâce à notre approche collaborative, votre équipe se forme aux meilleures pratiques et technologies innovantes pour acquérir des connaissances tout aussi précieuses que les produits eux-mêmes.

Contactez-nous

Si vous avez envie de savoir plus sur les sujets de Transformation d’Applications, Agile Software Development, Lean ou User-Centered Design n’hésitez pas à nous contacter: Twitter, Linkedin ou laissez-nous un message.

Vous souhaitez faire un workshop gratuit et sans engagement avec nous ? Discuter de la problématique design ou produit que vous rencontrez en ce moment ? Participez à nos “Product Office Hours”

[1] On peut aussi décider de “Retirer” une application lorsque celle-ci a peu de valeur business et s’avère complexe techniquement.

[2] L’option -p indique à l’outil de considérer chaque répertoire comme une application indépendante(par défaut, il considère que les dossiers font partie de la même application).

--

--