Migration du système
de commandes Nike
vers AWS
12 mois prévus
5 mois livrés

Quatre fois par an, la plateforme de saisie des commandes de Nike devient l'atout numérique le plus critique de l'entreprise. Des milliers de marchands produits de tous les segments se connectent pour passer les commandes de la prochaine saison. Une semaine. Un délai. 13 milliards de dollars d'engagements d'inventaire.

La plateforme et la pression trimestrielle impossible à contourner

L'échelle était indéniable. Nike traite plus de 13 milliards de dollars de commandes planifiées à chaque cycle d'achat trimestriel. Ces commandes proviennent de tous les points de l'écosystème de détail de Nike, des grandes chaînes nationales aux petits magasins de sport indépendants. Chacun avait un délai. Tous convergeaient en une seule semaine, quatre fois par an.

La plateforme qui gérait ce flux était née sur l'infrastructure hérité du passé. Du matériel dédié onéreux pensé pour des charges prévisibles et stables. Un mastodonte du XXe siècle. Il ne pouvait pas évoluer de façon dynamique. Il ne pouvait pas absorber la vague trimestrielle sans grincer. Après chaque deadline, 75 pour cent de cette infrastructure coûteuse restait inactif pendant trois mois jusqu'à la prochaine deadline.

Le problème structurel était patent. Une plateforme dimensionnée pour la charge moyenne était imposée de gérer des pics d'ordre de grandeur plus élevés. Le matériel traditionnel ne pouvait tout simplement pas absorber cette variabilité sans gaspillage massif.

Nike utilisait ce système depuis des années. Cela fonctionnait techniquement. Mais le modèle était coûteux. Et il créait des contraintes sur la façon dont l'entreprise pouvait évoluer.

Pourquoi le lift-and-shift était la bonne décision

Le partenariat existant de TechSparq avec Nike était l'accélérateur. Des années de compréhension de la logique métier de Nike, des systèmes logiciels, des rythmes opérationnels. Quand la migration de saisie des commandes a reçu le feu vert, les ingénieurs TechSparq ont été immédiatement engagés. Il n'y avait pas de période de ramp-up consacrée à demander "que fait ce système". L'équipe savait déjà.

Le choix stratégique était une approche lift-and-shift. Chaque composant de l'application hérité a été répliqué dans l'environnement AWS en utilisant une empreinte matérielle aussi proche que possible de l'original. Ce n'était pas une tentative d'optimiser ou de redévelopper de zéro. C'était une décision délibérée de préserver la logique validée, de prouver que la migration fonctionnait, et de différer l'optimisation à la phase 2.

L'échelle de ce qui était déployé était significative. Plus de cent nœuds composés de serveurs d'applications Java, bases de données Oracle 11i, clusters MongoDB, serveurs web Apache, infrastructure de recherche Apache SOLR, messagerie RabbitMQ et diverses autres technologies interconnectées. Tout devait fonctionner du premier coup, sinon le cycle de commande Nike souffrirait.

L'équipe a adopté les méthodologies Agile Scrum. Ce choix s'est révélé critique pour ce qui a suivi.

Comment 12 mois se sont contractés en 5

Le projet a commencé avec une fenêtre de livraison de 12 mois. C'était l'estimation de base sur la portée et la complexité. Au deuxième mois, quelque chose a basculé.

Agile Scrum a créé une visibilité sur ce qui était réellement possible. Les métriques de vélocité ont montré que l'équipe se déplaçait plus vite que prévu. Les sprints ont révélé des dépendances qui pouvaient être éliminées. Les rétrospectives ont montré ce qui fonctionnait et ce qui ne l'était pas. Au lieu d'attendre 12 mois pour découvrir les problèmes, on les trouvait toutes les deux semaines.

Après deux mois de développement, la chronologie s'est contractée de 12 mois à 9 mois. L'équipe se déplaçait tout simplement plus vite que l'estimation originale ne l'avait prévu. À mesure que la vélocité s'accumulait, la chronologie s'est à nouveau contractée. Neuf mois deviennent sept. Sept mois deviennent cinq.

Tout cela s'est produit dans les deux premiers mois de développement. L'équipe s'était déplacée si vite et avait appris tellement qu'elle savait que le projet pouvait être livré en cinq mois, non pas parce qu'on travaillait plus longtemps, mais parce que la planification en cascade avait été pessimiste quant à ce qui était réalisable avec la livraison itérative.

Quand la marque des cinq mois a été atteinte, toute la plateforme de saisie des commandes fonctionnait sur AWS. Le projet était un succès retentissant.

Ce qu'AWS a déverrouillé au-delà des économies de coûts

L'impact financier immédiat était impossible à manquer. Nike économise des millions de dollars par an en coûts d'hébergement à partir de cette migration seule. L'infrastructure massive qui restait inactif 75 pour cent de l'année a disparu. À sa place se trouvait une plateforme qui n'évoluait que si nécessaire, uniquement quand c'était nécessaire.

Mais le déblocage plus grand était la capacité. Tout le pipeline de développement eCommerce a été déplacé vers AWS. Le pipeline d'intégration continue qui crée, teste et déploie le code s'exécute maintenant dans AWS lui-même. Les équipes de développement peuvent mettre en place des environnements à la demande. Elles peuvent les démonter quand elles ont terminé. La friction de l'approvisionnement matériel a été éliminée.

La phase 2 a commencé. La prochaine évolution de la plateforme ajoutera la mise à l'échelle dynamique. Les ressources informatiques augmenteront à l'approche des dates limites de commande trimestrielle. Après le passage de la deadline, les ressources se contracteront. La plateforme correspondra maintenant à son empreinte de ressource à la demande réelle. Nike a découvert qu'un système pensé pour la rafale était souvent la meilleure façon de servir la moyenne également.

Les coûts d'hébergement sont estimés à 20 pour cent de la dépense annuelle originale. Une réduction de 80 pour cent. Mais ce nombre seul ne capture pas la vraie transformation. Ce qui importait le plus était que l'entreprise est devenue agile. L'équipe eCommerce pouvait publier les logiciels plus vite. Elle pouvait valider des fonctionnalités qui auraient été impossibles à tester dans le modèle matériel ancien.

Ce que cela signifie pour les plateformes entreprise avec des pics de trafic

Le cycle d'achat trimestriel de Nike n'est pas unique. Ventes saisonnières, lancements de produits, flash sales, événements promotionnels limités dans le temps, publications de résultats trimestriels. Le commerce est rempli de pics prévisibles. Toute marque ayant une saison de vente définie comprend le problème.

Le modèle matériel hérité crée un piège structurel. Approvisionner pour le pic et vous gaspillez de l'argent 75 pour cent du temps. Approvisionner pour la moyenne et vous échouez quand le pic arrive. Il n'existe pas de bonne réponse dans l'ancien modèle. La mise à l'échelle dynamique du cloud résout cela. Les ressources correspondent à la demande. La facture correspond à la consommation.

Mais la compression de la chronologie révèle quelque chose d'aussi important. Avoir un partenaire ayant une compréhension préexistante du système était très important. TechSparq ne devait pas apprendre la logique métier de Nike à partir de zéro. Ce contexte était déjà là. Le ramp-up était mesuré en semaines, pas en mois. L'équipe a sauté directement à la livraison.

C'est cette profondeur de partenariat qui a rendu le processus Agile Scrum si efficace. La vélocité se compose quand l'équipe sait déjà ce qu'elle développe et pourquoi cela importe.

• ✓ La profondeur du partenariat réduit le temps de ramp-up. Un partenaire qui comprend déjà vos systèmes peut se déplacer plus vite qu'une équipe apprenant à partir de zéro.
• ✓ Le lift-and-shift préserve la tolérance aux risques. Prouver que la migration fonctionne avant l'optimisation signifie aucune surprise inattendue.
• ✓ La vélocité Agile se compose. La livraison itérative révèle ce qui est réellement possible plus vite que la planification en cascade.
• ✓ Le cloud déverrouille la mise à l'échelle dynamique. Le matériel ne peut jamais. La mise à l'échelle dynamique est la réponse aux pics de trafic qui ne disparaîtront jamais.