_Application de récompenses pour les compagnies aériennes

Mise en correspondance des exigences et de l’architecture pour la migration et la modernisation de l’application.

Dans cet article, le premier de la série sur le thème de la migration et  modernisation des applications, je vous guiderai à travers les étapes de conception, les choix techniques et certaines mises en garde et attentes de la migration des applications vers le cloud public, qui implique une stratégie de migration vers le cloud et un plan de modernisation des applications significatifs, ainsi que certains des compromis et des problèmes associés à cette approche.

Introduction

Je démontrerai ce processus en me basant sur les objectifs commerciaux existants, les caractéristiques de l’architecture et les objectifs fonctionnels et non fonctionnels auxquels l’architecture doit répondre. Un accent particulier sera mis sur la migration vers le cloud et la modernisation des applications qui vont bien au-delà des approches traditionnelles de transfert et d’adaptation. Il va même au-delà des modèles standards de migration dans le cloud et de modernisation des applications, y compris le processus de migration dans le cloud « lift and shift » et « PaaS ».

Bien que l’article soit fortement axé sur les performances techniques, il émet également des hypothèses sur les facteurs commerciaux, qui seront abordés dans l’article suivant de la série sur la migration et modernisation des applications. Pour rendre l’article plus attrayant, j’utilise un exemple concret.

Considérations architecturales pour la modernisation d’une application de gestion des récompenses d’une compagnie aérienne

L’application mentionnée ici et utilisée comme exemple est une application de récompenses et de fidélité pour les compagnies aériennes. Dans sa forme actuelle, elle se compose de quelques pages web simples qui permettent aux utilisateurs de consulter les vols passés, les miles acquis, les segments, le statut actuel des récompenses et les avantages, ainsi que de gérer des informations de profil basiques telles que le nom et l’adresse. Les employés de la compagnie aérienne peuvent gérer les comptes des employés et des clients, modifier l’historique des miles et des segments, et enfin, l’application propose une boutique de récompenses. L’application est accessible uniquement via des pages web ; il n’existe aucune application mobile.

La compagnie aérienne a l’intention d’étendre ce projet à grande échelle, notamment :

• La possibilité d’afficher les vols à venir.
• Une option pour annuler et réserver des vols via les récompenses.
• Une intégration avec les compagnies aériennes partenaires.
• Une application mobile et le souhait d’intégrer des notifications par e-mail et SMS.
• La capacité de gérer les informations de paiement.
• Les statistiques sur votre historique de voyages.
• La possibilité de gamifier l’historique des vols et les demandes de surclassement.

À partir de notre session précédente, nous pouvons faire quelques hypothèses sur notre vision. Nous prenons une application monolithique et la migrons vers une plateforme microservices sans serveur à partir d’une ancienne plateforme monolithique pour résoudre un certain nombre de considérations décrites ci-dessous. Bien qu’il n’y ait rien d’intrinsèquement mauvais dans l’application monolithique telle qu’elle existe aujourd’hui, il y a des exigences qui sont mieux satisfaites par la nouvelle architecture. Comme l’application doit faire l’objet d’un nombre important d’ajouts de fonctionnalités, le moment est bien choisi pour effectuer ces changements.

Les défis liés à l’architecture monolithique : complexité et évolutivité du processus de migration vers le cloud

L’architecture existante utilise une approche monolithique moderne, un cadre MVC (model view control) et une base de données simple. Bien qu’il n’y ait rien de mal à cette approche, elle exige que tout changement apporté à un service soit bien compris par la majorité de l’équipe de développement. Au fur et à mesure du déploiement de nouveaux services de migration et de l’ajout de nouvelles fonctionnalités, la taille de l’équipe s’agrandira pour aider à maintenir ces ajouts. Le nombre de fonctionnalités et la complexité interne de chacune d’entre elles ont augmenté et continueront d’augmenter au-delà de la capacité de compréhension d’une seule personne, ce qui explique la nécessité d’un modèle non monolithique complet.
Le diagramme ci-dessous représente l’architecture existante à un niveau élevé. Il convient de noter que la base de code est beaucoup plus complexe si les chemins d’URL et les points d’entrée de l’API devaient être cartographiés, de même que les diverses interactions et dépendances du cadre. Par souci de concision, nous exclurons ces cadres de l’application existante, mais nous les présenterons dans des articles ultérieurs.
L’architecture est simple : deux machines virtuelles primaires fonctionnant dans une paire HA (hautement disponible), avec un équilibreur de charge de trafic entre elles. Aucun partage de session n’est activé, ce qui signifie que les sessions actives pourraient perdre des informations en cours de transfert, et des déséquilibres (« hotspots ») pourraient se produire dans un environnement cloud.

Figure 1 : Diagramme d’architecture de haut niveau (HLD) de l’application existante

Définition des exigences techniques et commerciales pour un système complexe de gestion des utilisateurs

Les étapes précédentes de la découverte nous ont permis de classer plusieurs exigences en catégories. Certaines d’entre elles peuvent être de nature technique, d’autres peuvent être des motivations commerciales. Ensemble, ils définiront notre future solution et l’architecture proposée.
Compte tenu de la nature de l’application, il faut traiter avec de nombreux persona, qui ont des permissions et des vues de l’application très différentes. Bien que certains d’entre eux puissent être regroupés en termes d’autorisations générales – par exemple, les clients/groupes de famille, tous les agents, les employés et les administrateurs, chacun d’entre eux nécessitera sa propre gestion complexe des autorisations et ses propres vues. Cela nécessitera un système complexe de gestion des utilisateurs capable de définir ces rôles et ces politiques d’accès.

Tableau 1 : Personas d’utilisateurs et cohortes

Exigences techniques et caractéristiques de la plateforme des compagnies aériennes

Les exigences en matière de plateforme pour une nouvelle application impliquent plusieurs caractéristiques clés qui sont essentielles pour une plateforme cloud moderne et son succès :

• la plateforme doit permettre un prototypage et un déploiement rapides des nouvelles fonctionnalités des pages
• la plateforme doit permettre de dupliquer le comportement entre les applications web et mobiles sans réécriture complète
• toutes les pages doivent être pilotées par l’API et capables de charger des données à partir de sources internes et externes multiples
• les mises à jour d’une plateforme API (par exemple, les réservations de vols) doivent être possibles sans affecter les équipes travaillant dans d’autres domaines (par exemple, les prestations)
• la plateforme doit utiliser des solutions prêtes à l’emploi pour les fonctions communes (par exemple, la gestion des utilisateurs, le rendu des pages, les API), le cas échéant, afin de réduire la charge de travail des développeurs et la maintenance
• il n’est pas nécessaire de disposer d’un référentiel de données partagé ; les communications entre les fonctionnalités (par exemple, réservations et récompenses) se feront par l’intermédiaire d’API, et non par un accès direct
• la plateforme doit permettre d’envoyer facilement des notifications par SMS et par courrier électronique, ainsi que des notifications push (par exemple, report d’un vol)
• la plateforme doit être conçue de manière à pouvoir stocker et utiliser des informations relatives aux cartes de crédit, avec les conséquences que cela implique en termes de conformité à la norme PCI (Payment Card Industry Data Security Standard)
• la plateforme doit permettre une veille stratégique et une visualisation des statistiques robustes
• permettre l’application de règles complexes de gestion du cycle de vie des données, sachant que les données doivent être mises à la disposition de différents personas et à des fins réglementaires différentes, à des intervalles de temps différents, mais qu’elles seront en fin de compte archivées.
• la plateforme doit offrir des fonctionnalités utiles aux passagers :

• • • possibilité de s’inscrire à la plateforme de récompenses et de réservations
    • rechercher, réserver, modifier, annuler et afficher les vols à venir, y compris modifier les dates, la classe tarifaire et l’itinéraire
    • afficher des récompenses, utiliser ou échanger des récompenses, convertir des récompenses de compagnies aériennes partenaires, recevoir des récompenses de compagnies aériennes partenaires et reconnaître les réservations auprès de compagnies aériennes partenaires.
    • Intégration avec les compagnies aériennes partenaires pour envoyer des informations sur les réservations et l’utilisation des récompenses, y compris le partage de codes, le co-marketing et les segments fractionnés entre les compagnies aériennes partenaires.
    • suivre les bagages, idéalement grâce aux codes aéroportuaires, à la cartographie et aux étiquettes géolocalisatrices optionnelles dotées de puces 4g/5g
    • permettre aux utilisateurs de gérer les informations relatives à leur profil, les comptes liés/les plans familiaux, les informations relatives à la facturation, les réductions et d’autres informations pertinentes sur les compagnies aériennes et les récompenses
    • permettre à la plateforme d’offrir des voyages de jeux incitatifs, y compris des jeux de géocache à l’intérieur et autour des aéroports vers des destinations sélectionnées, des jeux de code QR « capturez le drapeau », des tableaux de classement et des prix
    • permettre aux passagers des compagnies aériennes de voir l’évolution de leur statut de récompense, ainsi que des statistiques
• la plateforme doit prendre en charge diverses fonctionnalités pour les agents et les employés rémunérés, y compris la possibilité de:

• • • rechercher, gérer et modifier des réservations, ainsi que toutes les informations relatives à l’itinéraire, aux places, à la cabine et autres informations concernant une réservation, un billet ou un PNR Passenger Name Record).
    • fusionner les profils, les réservations, les PNR et autres demandes des passagers
    • réinitialiser, réclamer, créer et enregistrer manuellement des passagers
    • effectuer toutes les actions de l’utilisateur sur une réservation spécifique
    • accorder des remises, des remboursements et annuler les frais de réservation
    • gérer les récompenses et leur disponibilité
• Les administrateurs doivent pouvoir gérer les utilisateurs et l’attribution des rôles, ainsi que les agents d’inscription et les employés de tous types.

Exigences de la plateforme :

• Facilité d’utilisation pour l’utilisateur final
• fonctionnalité mobile
• la possibilité de permettre aux équipes de développement d’étendre les fonctionnalités de certains éléments du site
• réduire la complexité pour les équipes de développement
• intégration d’API tierces

Philosophie du choix des caractéristiques pour la migration et la modernisation du cloud

Il est important de comprendre et d’accepter que l’on ne peut pas résoudre tous les problèmes potentiels avec une seule solution, du moins pas en tant que moteurs principaux. Les solutions doivent d’abord répondre à un ensemble de principes fondamentaux qui guident la discussion et la conception globale, après quoi les composants individuels peuvent être ajustés. Il existe un nombre infini de façons d’évaluer la manière de sélectionner ces critères et ce que ces architectures peuvent contenir en termes de caractéristiques. Dans cet article, nous nous sommes concentrés sur l’utilisation des caractéristiques architecturales de Mark Richard, en adaptant ces caractéristiques à nos propres cas d’utilisation spécifiques.

L’objectif de cet exercice est de choisir les architectures les plus critiques pour l’entreprise, telles qu’identifiées précédemment, puis de travailler à les résoudre au mieux en tenant compte des compromis entre les choix technologiques dans notre conception architecturale de base.

Caractéristiques architecturales choisies

a. Évolutivité
Compte tenu de l’évolution constante du comportement et des attentes des clients, de l’incertitude entourant les voyages, des restrictions de voyage et des incitations offertes aux utilisateurs, sans parler de l’écosystème de partenariats avec lequel cette application doit interopérer, l’évolutivité sera une considération primordiale pour cette plateforme.

b. Serviabilité
La plateforme doit convenir à un large éventail d’audiences potentielles, tant du point de vue technologique (par exemple, anciens appareils, téléphones modernes et API obsolètes) que des langues, des devises et des utilisateurs en situation de handicap. Une API doit piloter toute interface si un nouveau modèle de consommation émerge. Idéalement, toutes les couches de présentation doivent être complètement abstraites pour faciliter les transitions entre les applications existantes et les besoins d’affichage ou de technologie. Le produit étend la gamme de profils, allant des utilisateurs extrêmement compétents sur le plan technique aux utilisateurs ayant une connaissance technique limitée, et doit donc être suffisamment simple à utiliser tout en offrant des fonctionnalités avancées pour les utilisateurs expérimentés et les voyageurs fréquents.

c. Sécurité des données
Le système gère et traite une quantité importante de données PII (informations personnellement identifiables) des clients de compagnies aériennes. Des informations de réservation, des numéros de voyageurs connus (known traveler numbers), des numéros de correction, des numéros de passeport et des informations de carte de crédit, le système est exposé aux risques de vol financier et d’identité. Les cyberattaques, l’usurpation d’identité, les employés malveillants et la corruption des données sont autant de risques importants qui pourraient avoir un impact extrêmement néfaste sur la vie des clients. Assurer la sécurité et l’intégrité du centre de données sera une caractéristique globale non négociable.

Considérations secondaires pour la migration et la modernisation du cloud

Bien qu’il ne s’agisse pas de considérations primordiales, nous devons tenir compte du fait qu’il existe des seuils minimums pour certaines interactions. Ainsi, nous avons documenté des cas d’utilisation qui ne sont pas des décisions de motivation primaires mais qui, lorsque c’est possible et approprié, devraient être pris en compte.

a. Réactivité
Étant donné que l’application est orientée vers l’utilisateur, elle doit être réactive aux entrées de l’utilisateur. Il n’est pas exigé que les demandes soient satisfaites dans le délai de 400 ms prévu par le seuil de Doherty, mais toutes les demandes doivent faire l’objet d’une action bien en deçà de ce seuil.

b. Faisabilité des coûts

Les coûts directs et les coûts indirects de la vélocité sont tous deux des facteurs de motivation. Le produit est soumis à un budget et à des contraintes de temps, mais il ne s’agit que de contraintes, et non de la motivation première. Une solution plus coûteuse ou plus longue pour une meilleure expérience ou une vitesse de développement plus rapide est un compromis acceptable.

Architecture de la solution proposée : Niveau de base

La solution proposée ci-dessous fait l’objet d’une brève description, et plus de détails suivront dans les articles ultérieurs qui exposent les différents compromis et les descriptions complètes des composants. Il s’agira de s’appuyer sur cette architecture de base, en ajoutant des composants et des détails selon les besoins, pour obtenir une solution complète.

Pour une architecture de base, le processus de conception s’est principalement concentré sur la recherche d’une plateforme appropriée basée sur les microservices sans serveur, car cela nous permettrait de choisir les deux composants modernes, y compris les composants SaaS (software as a service), PaaS (platform as a service) et DBaaS (database as a service), à volonté, comme nous le souhaitions. Cette architecture pourrait être éventuellement étendue pour prendre en charge un nombre quelconque de composants logiciels différents, des VM (machines virtuelles) traditionnelles et des conteneurs aux API tierces, et d’autres services sans serveur sans le fournisseur de cloud que nous avons choisi – dans ce cas AWS. Une plateforme de microservices sans serveur emprunte en réalité à plusieurs styles d’architecture, mais elle convient bien à cet ensemble spécifique de critères de problèmes.

Architecture de la solution proposée : Choix des composants initiaux

Les choix initiaux de composants permettent un prototype et un développement très rapides, avec une application hautement modulable qui permet à différentes équipes de bénéficier d’une grande autonomie les unes par rapport aux autres lors du développement de fonctionnalités.

En outre, l’utilisation de l’amplificateur avec Cognito permet également ce qui suit :

• gestion un nombre important de tâches communes et redondantes, telles que la gestion des utilisateurs et des sessions,
• l’authentification, le mappage des rôles et de nombreux autres frais généraux qui sont regroupés dans un paquet soigné pour un déploiement rapide,
• la facilitation plus rapide des cycles de développement, l’augmentation de la vélocité et la diminution des coûts humains.

En outre, la plateforme est par défaut adaptée au web et au mobile. La possibilité de créer rapidement de multiples vues et interfaces avec le contenu résout également un certain nombre de problèmes liés à la facilité d’utilisation, notamment les interfaces ADL (activités de la vie quotidienne) pour les personnes handicapées, y compris les pages compatibles avec les lecteurs d’écran et d’autres produits d’assistance. Enfin, la plateforme est très conviviale, elle prend en charge plusieurs voies de notification, y compris les SMS dans plusieurs pays, et permet aux utilisateurs de s’authentifier avec leur fournisseur d’identité préféré qu’ils reconnaissent déjà, tandis que les agents de voyage et les employés internes peuvent utiliser SAML et OpenID.

Architecture de la solution proposée : Résilience et sécurité des composants et orientations futures

Les composants choisis:

• sont très résistants et permettent de contrôler et de vérifier l’intégrité des données et l’accès à celles-ci de différentes manières,
• ont la capacité d’enregistrer et d’auditer les accès, le code et les modifications de données, ainsi que les accès individuels à l’API et aux données,
• sont sécurisés par défaut, en s’appuyant sur un écosystème de confiance existant soutenu par AWS et validé par des milliers d’installations de production. Par coïncidence, l’empreinte financière de cette architecture peut être relativement faible et elle se prête bien à une réactivité rapide.

Nous aborderons plus en détail les différents services dans un prochain article de cette série, y compris les avantages et les inconvénients spécifiques de chacun dans un certain nombre de catégories importantes, tant du point de vue du développement que du point de vue opérationnel, et la meilleure façon d’atténuer les risques et les lacunes de chacun d’entre eux. Il ne s’agit en aucun cas d’une architecture complète, et les composants présentés aujourd’hui ne répondent pas à toutes les exigences. Elle constitue cependant une base solide sur laquelle il est possible de s’appuyer.

Figure 2 : Diagramme d’architecture de haut niveau (HLD)

Note : Une décomposition détaillée des composants et une cartographie des styles du HLD seront fournies dans un article ultérieur.

Remerciements à :

• Mark Richards pour les références de ressources
• Neal Ford pour une écriture inspirée
• Marc Boudreau pour les connaissances et les références
• Scott Lew pour ses connaissances et son expérience
• Samira Barouti pour les connaissances et les détails

Que se passe-t-il ensuite ? Décortiquer le parcours de migration et de modernisation des applications : une série complète

Il y a beaucoup de choses à faire tout au long du processus de migration et de modernisation des applications, depuis les discussions sur le concept jusqu’à un plan d’application complet, et tout cela ne se fait pas en même temps. Même si toutes les applications n’ont pas besoin d’être approfondies comme nous le faisons ici, certaines en auront besoin et toutes les applications utiliseront des éléments de nos méthodes présentées ici. C’est pourquoi nous allons procéder par étapes, en utilisant une série d’articles, afin que les lecteurs puissent choisir les sujets les plus pertinents et décider des éléments à suivre et de ceux à écarter. Rassembler tous ces éléments dans un seul article donnerait un petit livre, mais resterait incomplet.

1. Découverte et collecte des besoins métier (préquelle : À venir)
2. Mappage des exigences capturées et de la solution existante à une architecture de haut niveau (couvert dans cet article)
3. Conception des processus, de la séquence, des flux de travail UX et des maquettes d’interface utilisateur
4. Conception d’un processus de déploiement cohérent
5. Création de diagrammes C4 (Contexte système, Conteneurs)
6. Ajout de rapports et de Business Intelligence (BI)
7. Identification des risques et des migrations (business et techniques)
8. Création de dossiers de décision architecturale (ADRs), discussion des compromis et collecte des commentaires sur les décisions
9. Décomposition des coûts de possession (coûts de mise en œuvre, d’exploitation continue, d’infrastructure et de cloud continus, de sécurité et de risque)
10. Définitions et glossaire communs du projet
11. Création du backlog du projet (jalons, Epics, capture d’informations non fonctionnelles)
12. Considérations opérationnelles et de gestion continue
13. Un pseudo-projet complet prêt à être lancé (dépôt GitHub)