Migration Nike Order Entry
vers AWS.
12 mois prévus.
5 mois livrés.

Quatre fois par an, la plateforme de saisie des commandes de Nike devenait l'atout numérique le plus important de l'entreprise. Des milliers de marchands de produits de toutes tailles se mettaient en ligne pour placer des commandes pour la prochaine saison. Une semaine, une date limite, 13 milliards de dollars d'engagements d'inventaire.

La plateforme et la pression trimestrielle dont elle ne pouvait pas s'échapper

L'échelle était impossible à ignorer. Nike a traité plus de 13 milliards de dollars de commandes d'inventaire planifiées au cours de chaque cycle d'achat trimestriel. Ces commandes provenaient de partout dans l'écosystème de détail de Nike, des grands détaillants nationaux aux petits magasins de sport indépendants. Tous avaient une date limite. Tous convergeaient dans une seule semaine, quatre fois par an.

La plateforme qui gérait cela était construite sur l'infrastructure héritée du passé. Un matériel dédié coûteux conçu pour des charges de travail prévisibles et à l'état stable. C'était un monstre du 20e siècle. Il ne pouvait pas évoluer dynamiquement. Il ne pouvait pas gérer la vague trimestrielle sans grincer des dents. Après chaque date limite de commande dépassée, 75 % de cette infrastructure coûteuse restait inactif pendant trois mois jusqu'à l'approche de la date limite suivante.

Le problème structural était clair. Une plateforme construite pour gérer une charge moyenne était sollicitée pour gérer des charges de pointe d'ordre de grandeur supérieures. Le matériel traditionnel ne pouvait tout simplement pas absorber ce type de variabilité sans gaspillage énorme.

Nike utilisait ce système depuis des années. Cela fonctionnait, techniquement. Mais cela fonctionnait de façon coûteuse. Et cela fonctionnait d'une manière qui garantissait des contraintes sur la façon dont l'entreprise pouvait évoluer.

Pourquoi le déplacement et l'évolution était le bon appel

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. Lorsque la migration de saisie des commandes a reçu le feu vert, les ingénieurs TechSparq ont été immédiatement mobilisés. Il n'y avait pas de période de démarrage consacrée à demander « que fait ce système ». L'équipe savait déjà.

Le choix stratégique était une approche de déplacement et d'évolution. Chaque composant de l'application héritée a été dupliqué dans l'environnement Amazon en utilisant un empreinte matérielle aussi proche que possible de l'original. Ce n'était pas une tentative d'optimiser ou de reconstruire à partir de zéro. C'était une décision délibérée de préserver la logique connue-bonne, de prouver que la migration a fonctionné, et de différer l'optimisation à la phase 2.

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

L'équipe a adopté les méthodologies Agile Scrum. Ce choix s'est avéré critique pour ce qui s'est passé ensuite.

Comment une chronologie de 12 mois est devenue 5

Le projet a commencé avec une fenêtre de livraison de 12 mois. C'était l'estimation initiale basée sur l'étendue et la complexité. Au deuxième mois, quelque chose s'était décalé.

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, ils les ont trouvés toutes les deux semaines.

Après deux mois de développement, la chronologie a été comprimée de 12 mois à 9 mois. L'équipe se déplaçait tout simplement plus vite que l'estimation originale ne l'expliquait. À mesure que la vélocité continuait à augmenter, la chronologie s'est comprimée à nouveau. Neuf mois sont devenus sept. Sept mois sont devenus cinq.

Tout cela s'est produit au cours des deux premiers mois de développement. L'équipe s'était déplacée si vite et avait appris tellement que sa savait que le projet pouvait s'atterrir en cinq mois, non pas parce qu'ils travaillaient plus longtemps, mais parce que la planification en cascade avait été pessimiste quant à ce qui était réalisable avec une livraison itérative.

Au moment où la marque des cinq mois est arrivée, toute la plateforme de saisie des commandes fonctionnait sur AWS. Le projet était un grand succès.

Ce que 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 la migration seule. L'infrastructure massive qui restait inactif 75 % de l'année a disparu. À sa place était une plateforme qui n'évoluait que si nécessaire, quand cela était nécessaire.

Mais le plus grand déverrouillage était la capacité. Le pipeline de développement eCommerce entier a été déplacé vers AWS. Le pipeline d'intégration continue qui construit, teste et déploie le code s'exécute maintenant dans AWS lui-même. Les équipes de développement peuvent établir des environnements à la demande. Ils peuvent les démonter lorsqu'ils 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 une mise à l'échelle dynamique. Les ressources informatiques augmenteront à l'approche des dates limites de commande trimestrielle. Après le passage de la date limite, les ressources se réduit. La plateforme correspondera maintenant à son empreinte de ressource à la demande réelle. Nike a découvert qu'un système construit pour la rafale était souvent le meilleur moyen de servir la moyenne également.

Les coûts d'hébergement sont estimés à 20 % de la dépense annuelle d'origine. Une réduction de 80 %. Mais ce nombre seul ne capture pas la vraie transformation. Ce qui était le plus important, c'est que l'entreprise est devenue agile. L'équipe eCommerce pouvait publier des logiciels plus vite. Ils pouvaient expérimenter avec des fonctionnalités qui auraient été impossibles à tester dans l'ancien modèle matériel.

Ce que cela signifie pour les plateformes entreprise avec des problèmes de trafic en rafale

Le cycle d'achat trimestriel de Nike n'est pas unique. Ventes saisonnières, lancements de produits, ventes flash, événements promotionnels limités dans le temps, publi­ca­tions des résultats trimestriels. Le commerce est rempli de rafales 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. Approvisionnement pour le pic, et vous gaspillez de l'argent 75 % du temps. Approvisionnement pour la moyenne, et vous échouez quand le pic arrive. Il n'y a 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 connaissance 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à. La montée en charge était mesurée 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é composée quand l'équipe sait déjà ce qu'elle construit et pourquoi cela importe.

• ✓ La profondeur du partenariat réduit le temps de démarrage. Un partenaire qui comprend déjà vos systèmes peut se déplacer plus vite qu'une équipe apprenant à partir de zéro.
• ✓ Le déplacement et l'évolution préservent la tolérance au risque. Prouver que la migration fonctionne avant l'optimisation signifie aucune surprise inattendue.
• ✓ La vélocité Agile composée. La livraison itérative révèle ce qui est réellement possible plus vite que la planification en cascade.
• ✓ Cloud déverrouille la mise à l'échelle dynamique. Le matériel ne pouvait jamais. La mise à l'échelle dynamique est la réponse au trafic en rafale qui ne disparaîtra jamais.