L'importance d'une bonne gestion des données clients a été clairement démontrée par le scandale Facebook-Cambridge Analytica en début d'année. De plus, la mise en œuvre du Règlement général sur la protection des données (GDPR) par lequel le Parlement européen, le Conseil de l'Union européenne et la Commission européenne entendent renforcer et unifier la protection des données dans L'Europe, et par extension dans de nombreux pays du monde. Mais qu'en est-il des processus qui entourent ces données et des boucles de rétroaction des clients qui ne cessent d'augmenter pour créer de nouvelles sources de valeur et améliorer leurs résultats financiers?
Dans mon dernier article je propose un modèle de réflexion sur la transformation numérique et la croissance centré sur trois piliers: l'intimité du client, l'évolution technologique et la culture. J'ai également décrit le premier pilier centré autour de la construction de la boucle de rétroaction. Dans ce post, je voudrais me concentrer sur le deuxième pilier autour de l'architecture, de la mise à l'échelle et de l'évolution de cette boucle de rétroaction. Comme nous l'apprenons tous les jours, ce n'est pas seulement la technologie elle-même qui change rapidement, mais les environnements dans lesquels nous la déployons – qu'il s'agisse de réglementation et de confiance, ou d'expérience utilisateur et de modèles commerciaux. La nécessité d'une adaptation rapide peut alimenter des pratiques comme agile et devops, mais la capacité d'évoluer aux vitesses du marché d'aujourd'hui est finalement gagnée ou perdue par l'architecture.
Qu'est-ce que l'architecture moderne de toute façon? ] Dans les «temps anciens», lorsque la technologie était isolée du monde extérieur par les limites strictes à la périphérie de l'entreprise, l'architecture était un concept très simple. À l'époque précédente, l'architecture des applications reflétait généralement l'architecture de l'infrastructure et vice versa. De grandes applications monolithiques fonctionnaient sur des machines de «gros fer» virtualisées. La virtualisation créait une certaine efficacité dans l'utilisation des ressources, mais l'unité de travail de base était toujours «la machine».
Mais aujourd'hui, l'architecture est une cible mouvante. Il comprend généralement des composants de SaaS et de Cloud, mais les plates-formes de demain peuvent tout aussi bien être définies par l'apprentissage automatique et les API distribuées. La vérité est que nous ne savons pas exactement ce que l'avenir nous réserve, ce qui explique pourquoi nous avons besoin d'une approche très élastique de la conception, de la construction et de l'amélioration de la technologie et de la création de valeur.
l'architecture doit être " Construit pour changer ." Il doit s'agir d'un système d'incorporation, d'organisation et de structuration du changement en cours plutôt que d'une structure ou d'un cadre permanent. En fait, l'architecture moderne doit être assez dynamique – c'est comme les glaciers à certains égards; il peut sembler se déplacer presque imperceptiblement un peu à la fois, mais il doit être constamment en mouvement pour se refaçonner.
Ceci est en partie pour rester en tête de la dette technique – cette somme de décisions de développement de logiciels faites pour satisfaire à court terme exigences qui, à long terme, limiteront la capacité de l'architecture à répondre aux nouveaux besoins. À moins que la dette technique ne soit continuellement payée par l'évolution architecturale et le refactoring, même l'architecture logicielle la plus robuste se transformera au fil du temps en patchwork fragile et mal compris de changements et de modifications de plus en plus incapables de répondre aux nouvelles demandes. On pourrait dire: «Mais c'est exactement ce que sont les conteneurs et les microservices!» Après tout, les architectures architecturales à base de microservices visent à abstraire et à lier des blocs discrets de fonctionnalités au point où ces segments de fonctionnalité peuvent être facilement modifié et même réorganisé en réponse à de nouveaux besoins. Les conteneurs transforment certainement la notion de grandes unités de travail fixes. Une unité de travail conteneurisée peut être aussi grande qu'elle doit l'être pour s'adapter à la tâche et, contrairement aux machines virtuelles, peut être créée, arrêtée ou déplacée presque instantanément.
Les conteneurs permettent également de partitionner le calcul et les données, et en effet, une approche basée sur les microservices impose un certain niveau de rigueur architecturale dû à l'isolation entre les unités de fonctionnalité. Et la nécessité d'orchestrer toutes ces unités de fonctionnalité pour créer un système complet nécessite également de concevoir et d'optimiser la façon dont les différentes pièces s'emboîtent.
Mais même une architecture basée sur le microservice nécessite une évolution et une réarchitecture continues. capable d'évoluer le système au fil du temps. Les fonctionnalités obsolètes doivent être soigneusement supprimées, les nouvelles fonctionnalités nécessitent la redéfinition de composants connexes, et les interactions entre les composants et l'orchestration du système dans son ensemble doivent être soigneusement entretenues pour éviter les inefficacités, les conséquences imprévues et le fluage de la complexité inutile.
Entrez "informatique sans serveur"
Les conteneurs sont un outil utile pour construire des architectures de services hautement efficaces et évolutives; Ce n'est pas par hasard que le moteur de recherche massif de Google est basé sur des conteneurs. Mais si les conteneurs se concentrent sur des unités de fonctionnalité plus petites et plus séparables au lieu de machines, l'architecture d'infrastructure de prochaine génération deviendra-t-elle invisible pour les développeurs et les architectes au fil du temps? Une telle abstraction accrue des machines et des détails matériels de l'infrastructure physique fait partie de l'attrait de l'informatique sans serveur qui permet de se concentrer presque entièrement sur le code
Compte tenu des modèles historiques et de l'émergence de capacités sans serveur (FaaS – Fonctions en tant que service). ), il est peu question que l'infrastructure continuera à être de plus en plus abstraite, avec plus de concentration sur le travail que les mécanismes sous-jacents nécessaires pour l'accomplir. Combien de développeurs connaissent aujourd'hui – ou ont besoin de savoir – les instructions machines sous-jacentes que leur code produit finalement?
Le monde sans serveur est attrayant et les conteneurs nous poussent déjà dans cette direction. De plus, avec les conteneurs, les développeurs jouent un plus grand rôle dans le déploiement de leur code, et les opérations doivent avoir une meilleure compréhension de ce qu'il y a dans les conteneurs et de leur interopérabilité. Devops lui-même se métamorphose à mesure que de nouvelles architectures prennent forme. Avec une architecture sans serveur, qui est responsable des opérations? Est-ce le fournisseur de cloud? Ou une nouvelle fonction hybride? Quoi qu'il en soit, le besoin de prêter attention à la conception et à l'évolution de l'architecture d'un système basé sur FaaS sera aussi important qu'avec les technologies précédentes – sinon plus – compte tenu de la nature hautement distribuée et interconnectée de ces environnements de calcul
fin ": instrumentation et télémétrie
Si l'avènement d'architectures sans serveur avec une infrastructure abstraite et déconstruite est à l'horizon, alors peut-être que notre focalisation sur l'infrastructure" end end "peut nous aider à mieux comprendre comment le logiciel est réellement expérimenté. que comment ça fonctionne. Nous ne faisons actuellement qu'effleurer la compréhension des besoins des utilisateurs grâce à l'instrumentation, la télémétrie et l'analyse. L'avenir ne concerne pas les tableaux de bord opérationnels, il s'agit de connaissances approfondies.
La vérité est que, quelle que soit la qualité de votre architecture logicielle et de vos processus de développement, votre boucle de rétroaction ne peut évoluer sans une compréhension profonde des utilisateurs. votre logiciel grâce à des informations basées sur les données. Bien que la santé de l'architecture de votre logiciel reste toujours un facteur déterminant pour l'évolution de votre logiciel, l'architecture de vos boucles de rétroaction client sera désormais sur le chemin critique de votre capacité à faire évoluer l'expérience utilisateur elle-même.
est que même si la technologie évolue, le rôle de l'architecture restera central tandis que sa portée et son but évoluent. Étant donné que les informations et les boucles de rétroaction basées sur les données deviennent essentielles pour votre entreprise, l'architecture sera plus directement connectée à votre modèle d'entreprise. La question va de «Votre logiciel fonctionne-t-il comme prévu?» À «Qu'est-ce que votre logiciel nous dit sur notre entreprise?». Votre architecture et votre évolution des boucles de rétroaction pour votre entreprise détermineront votre capacité à interagir efficacement avec vos clients. et répondez plus vite que vos concurrents.
Cet article est publié dans le cadre du réseau de contributeurs IDG. Voulez-vous devenir membre?