Par David Andrzejek, responsable des services financiers, DataStax
Capital One est peut-être la sixième plus grande banque des États-Unis, mais elle travaille dur pour exploiter ses données et le cloud pour fonctionner beaucoup plus comme une fintech. La société a pour mission de révolutionner le secteur bancaire grâce à la technologie et aux données et sert de modèle pour exploiter la puissance des données pour la croissance.
Aujourd’hui, Capital One est une entreprise de services financiers à la pointe de la technologie, utilisant des technologies cloud open source telles que la base de données NoSQL hautement évolutive Apache Cassandra.® pour améliorer l’expérience client, stimuler l’innovation et accélérer la mise sur le marché de leurs applications. Nous avons récemment discuté avec le directeur principal de Capital One, David Harmony, de la migration vers le cloud, de la création d’une plate-forme de données client et de l’importance des données en temps réel.
Parlez-nous de Capital One et de votre rôle
Capital One est l’une des plus grandes banques du pays qui propose des produits bancaires traditionnels, ainsi que des services bancaires en ligne. Nous offrons des prêts auto et des cartes de crédit. Au-delà de cela, nous avons des prêts commerciaux, ainsi que des services à court terme, comme Capital One Shopping.
Il y a quelques années, les dirigeants ont réalisé que le secteur bancaire allait être dominé par de grandes entreprises technologiques qui gèrent exceptionnellement bien les risques. La gestion des risques a toujours été l’un des fondements de l’entreprise. Ils ont donc décidé d’améliorer nos pratiques de développement d’applications et de développement. Vers 2015, Capital One s’est adressé à AWS re:Invent et a défini notre objectif ambitieux de moderniser l’ensemble de notre infrastructure technologique.
Fondamentalement, nous voulions sortir de nos centres de données et fonctionner dans un cloud public. L’un des principaux composants sur lesquels j’ai travaillé était la plate-forme client. C’était un si grand déménagement pour nous. Il y a eu tellement de changements associés au passage au cloud.
J’ai rejoint Capital One il y a 10 ans, à l’aube de sa transformation numérique. Au fil des années, j’ai eu la chance de travailler avec des équipes formidables sur des projets stimulants. Lors de mon arrivée, j’ai travaillé sur la création des modèles d’API qui prendraient en charge les applications que nous exécutons aujourd’hui. Nous avons travaillé avec les équipes d’application pour créer les API de notre application mobile existante disponible sur l’App Store. J’étais vraiment fier du travail que nous avons fait. J’ai beaucoup appris de l’écosystème.
Après ce projet, nous avons déplacé nos services numériques – dans le cadre de la migration – vers AWS. Ensuite, je suis allé travailler sur notre plate-forme client, l’un de nos principaux systèmes où nous avons migré le système client hors du mainframe et l’avons transféré dans le cloud. Cette initiative de plate-forme de données client a eu beaucoup d’engagement avec DataStax [a managed database service built on Cassandra].
À quels défis avez-vous été confronté avec la plateforme de données client et en quoi le passage au cloud vous a-t-il aidé ?
Que vous vous connectiez au site Web, à l’appareil mobile ou que vous interagissiez avec un agent, le système client est interrogé pour déterminer votre relation avec la banque et la manière dont vous souhaitez interagir avec nous. Nous conservons ces informations pour vous offrir le bon service.
La plate-forme de données client de Capital One fonctionnait auparavant sur un modèle de système de gestion de base de données relationnelle centralisé (RDBMS) qui ne pouvait publier au maximum que quatre nouvelles fonctionnalités par mois. Cela a entraîné des retards dans la résolution des problèmes rencontrés par les équipes d’application avec la plate-forme, ainsi que les efforts de l’entreprise pour introduire des fonctionnalités plus transparentes sur le marché.
Capital One a également eu du mal à faire évoluer son infrastructure obsolète. La planification de la capacité sur site était un projet de grande envergure. Le coût et les délais de mise à l’échelle de la capacité du mainframe ont entravé les mises à niveau des applications et ralenti leur capacité à commercialiser de nouvelles fonctionnalités, faisant de la technologie un obstacle pour les fonctionnalités de l’entreprise. Pendant les périodes de vacances, l’entreprise a dû se démener pour s’assurer qu’il y avait une capacité suffisante pour répondre aux pics de demande.
Capital One a adopté un style architectural de microservice, qui a par conséquent extrait un tas de données des emplacements centraux et les a séparées en différentes parties de l’écosystème d’applications client. Désormais, les composants que nous exécutions auparavant sur notre ordinateur central s’exécutent désormais sur DataStax. Nous avons adopté cette architecture pour nous aider à atténuer les risques de défaillance, à générer des lignes de séparation claires pour évoluer de manière indépendante et, surtout, à permettre aux équipes de créer et de déployer nos applications de manière indépendante.
Désormais, nous pouvons facilement faire une centaine de releases par mois pour certains de nos composants. Cela nous permet d’obtenir plus de fonctionnalités sur le marché à un rythme plus rapide avec moins. Nous avons toujours des fournisseurs tiers qui s’appuient sur des ordinateurs centraux, mais toutes nos applications internes sont hors de l’ordinateur central et fonctionnent entièrement à l’intérieur d’AWS et au-dessus de Cassandra. Le cloud nous a donné la capacité de publier des fonctionnalités beaucoup plus rapidement et d’évoluer facilement, modifiant ainsi notre façon de fonctionner.
Pourquoi Capital One a-t-il choisi Cassandra pour la plateforme de données client ?
Il y a quelques choses qui me viennent à l’esprit. Les modèles d’accès dont nous avons besoin pour la plate-forme client sont assez simples et correspondent parfaitement au modèle de valeur clé de Cassandra. Nous faisons également bon usage de la mise en œuvre de colonnes larges de Cassandra pour ajouter de nouveaux attributs à nos données clients et les ajouter à la structure existante.
L’un des plus grands avantages de Cassandra est la résilience. Puisque Cassandre penche pour AP dans CAP Théorème, il peut gérer les pannes de partition pour rester disponible 24h/24. L’architecture peer-to-peer sans maître de Cassandra garantit que les applications ne subissent jamais de temps d’arrêt, même lors de pannes système désastreuses.
L’entreprise elle-même a investi beaucoup de temps et d’efforts dans notre résilience et cet engagement a fait de Cassandra un excellent choix. Il est toujours disponible. Il est toujours là pour nous. Et il a fonctionné comme un roc solide.
Comment mesurez-vous le ROI de la plateforme de données et quels sont les résultats que vous constatez avec Cassandra ?
Lorsque nous parlons de retour sur investissement, il y a trois éléments principaux à prendre en compte : les coûts d’opportunité, les coûts opérationnels et l’expérience client.
L’investissement dans Cassandra peut être important, mais il y aura également des coûts d’opportunité perdus en restant là où vous êtes. Sur le mainframe, c’était vraiment difficile. Nous avions des contraintes sur ce que nous pouvions mettre en œuvre du point de vue des fonctionnalités métier, car l’obstacle à l’investissement dans le mainframe était si élevé. Nous sommes désormais en mesure de faire évoluer notre plate-forme assez facilement pour apporter de nouvelles fonctionnalités sur le marché 24 heures sur 24 avec une capacité suffisante.
Deuxièmement, du point de vue des coûts opérationnels : en tant que banque, nous acquérons des portefeuilles de grandes entreprises comme Walmart et les intégrons à notre écosystème. En règle générale, ces migrations de portefeuille prenaient plusieurs semaines, voire plusieurs mois. Avec Cassandra, nous pouvons le faire pendant un week-end sans aucun temps d’arrêt. Il a atteint un point où l’ajout de 15 millions de nouveaux clients est désormais une opération quotidienne standard.
Enfin, grâce aux excellentes informations en temps réel que nous avons acquises grâce à l’architecture moderne, nous avons pu identifier les lacunes dans les processus et les composants technologiques et les compenser, réduisant ainsi le nombre de fois où les gens contactent le service client. En fin de compte, notre investissement a créé une meilleure expérience client à long terme et amélioré notre profil de coûts.
Spécifiquement pour notre plate-forme de données client, nous avons activement suivi deux mesures : les objectifs de point de récupération et de temps de récupération. L’objectif de point de récupération est la capacité de s’isoler d’un seul niveau de défaillance et d’éviter les problèmes, tandis que l’objectif de temps de récupération est de s’assurer qu’aucune perte de données n’est persistante.
Auparavant, nos implémentations RDBMS avaient du mal à atteindre nos objectifs de point de récupération, qui sont généralement inférieurs à cinq minutes pour une panne régionale. De plus, ces implémentations étant actives, passives et non basées sur plusieurs maîtres, nous avons connu une latence supplémentaire. Cela nous a amenés à remettre en question l’intérêt d’exécuter deux systèmes si nous devons toujours réécrire dans une seule région. Maintenant, je suis vraiment fier des équipes et de la disponibilité qu’elles ont obtenue. Nous aspirons à une disponibilité de cinq à neuf et nous respectons souvent nos SLA existants. Notre équipe client s’est également largement approprié la plateforme, ce qui est super génial.
Au sein de la plateforme client, la grande majorité de notre trafic qui va vers Cassandra est en temps réel. Ajouter Apache Étincelle [an open source data analytics engine] dans l’écosystème Cassandra nous aide à valider la cohérence de nos données dans l’ensemble de l’écosystème et à obtenir des informations supplémentaires sur les lacunes du service et du système. Nous avons maintenant construit un centre de données en temps réel et un centre de données analytique pour prendre en charge tous nos systèmes bancaires, y compris des modèles d’apprentissage automatique supplémentaires.
La migration des fonctions hors du mainframe est une opération notoirement difficile. Comment avez-vous vécu ce changement ?
Passer au cloud peut être une conversation très effrayante. Il y a un risque à faire presque n’importe quel changement et vous devez être réfléchi et prudent pour éviter de faire les mauvais choix. La chose la plus importante que nous ayons faite a été le test des données. C’était un niveau de frais généraux important pour nous, mais nous avons pu migrer nos clients en toute sécurité. C’est ce niveau de test des données qui a rendu notre migration vers DataStax très réussie.
Une autre chose importante est de bien réfléchir à votre modèle de données, en particulier au sein de Cassandra. Réfléchissez bien à vos modèles de données et assurez-vous que vous vous sentez bien avec eux. De plus, il n’y a pas de système parfait et vous devez vous préparer aux échecs. Essayez de comprendre en amont comment vous allez les compenser et comment vous les corrigerez lorsque les pannes arriveront.
Enfin et surtout, vous devez absolument investir dans vos collaborateurs au sein des équipes. Ils sont très talentueux et ce sont eux qui stimuleront l’innovation dans votre écosystème d’applications.
Avec DataStax investi à 100 % là où nous sommes, et avec notre solide relation au sein de Cassandra, j’ai l’impression que nous sommes bien placés. J’ai été très satisfait des performances et de la disponibilité qui sont désormais fournies sur nos plates-formes.
Écouter le conversation complète avec David Harmony pour en savoir plus sur la façon dont DataStax aide Capital One à tirer parti de l’évolutivité transparente de Cassandra pour accélérer l’innovation et améliorer l’expérience client.
À propos de David Andrzejek :
David a passé 25 ans à aider les entreprises à adopter la technologie pour obtenir des résultats de transformation d’entreprise démesurés.
Source link