jeudi, 18 avril 2024

L’architecture cloud doit s’adapter aux changements rapides

Disons qu’il y a une entreprise de biotechnologie de taille moyenne de cinq ans. Nous l’appellerons MidCo, et ils se spécialisent dans le dépistage automatisé d’échantillons de sang et de tissus. Le résultat net a explosé tout au long des 5 premières années de service de MidCo. Les nouvelles start-up rivales produisent des articles plus avancés qui peuvent tirer parti de technologies telles que l’intelligence artificielle, et les concurrents de MidCo fournissent leurs services à des tarifs bien inférieurs. En termes simples, MidCo est perturbé.

Le service informatique de MidCo ne peut pas rester à jour avec les changements requis par la R&D et le marketing pour construire des technologies de test avancées et mieux optimisées à un bien meilleur coût. Plusieurs des articles brevetés de MidCo ne peuvent pas entrer en production étant donné que leurs systèmes existants basés sur le cloud ont trop de limitations. Leurs systèmes ne s’intégreront qu’à quelques fournisseurs, ils ne peuvent pas utiliser un fabricant de pièces tiers et ils ne peuvent pas accéder à une chaîne d’approvisionnement optimisée pour contourner automatiquement les pénuries de pièces ou modifier les fournisseurs.

Ce qui tue cette entreprise n’est pas de la malchance ou un marché de plus en plus congestionné. Il est vrai que ceux qui ont produit la solution préliminaire basée sur le cloud pour automatiser les systèmes importants de l’entreprise n’ont pas intégré la capacité de s’adapter aux changements rapides. Cette contrainte a fini par devenir un problème plus important, car l’entreprise s’est développée au sein d’un marché qui a changé plus rapidement que prévu au départ.

De nos jours, des entreprises comme MidCo sont plus la règle que l’exception. Vous vous attendez à voir ce problème dans les entreprises héritées qui ont trop de silos non intégrés et des enjeux d’innovation qui reviennent 60 ans. Ces entreprises ont généralement moins de 10 ans et beaucoup n’ont jamais utilisé quoi que ce soit d’autre que des systèmes basés sur le cloud. Comment ont-ils été interrompus ?

De nombreuses personnes pensent que le cloud computing offre automatiquement la meilleure dextérité ainsi qu’une optimisation des coûts. La vérité est qu’absolument rien n’est automatique. Vous devez construire vos systèmes pour s’adapter aux modifications rapides, cloud ou non. Dans la plupart des cas, il sera aussi difficile d’intégrer des fonctions de modification rapide dans les systèmes cloud existants que de mettre à jour des systèmes traditionnels plus conventionnels. Sans ces fonctionnalités, les entreprises passeront la mort de mille coupures au fur et à mesure que les perturbateurs prendront le contrôle. Il vous suffit de regarder le covoiturage, le partage à domicile et le divertissement à domicile pour voir comment cela se passe.

Aujourd’hui, nous devrions planifier à l’avance les modifications. Toute architecture, cloud ou non, doit pouvoir s’adapter au changement. Gardez à l’esprit, bien qu’un système puisse être optimisé pour des circonstances préliminaires dans le temps, cela ne signifie pas qu’il s’agit d’une excellente architecture continue. Il ne suffit plus de produire un système qui fonctionne aujourd’hui. Il devrait également s’adapter à des modifications rapides demain et le surlendemain.

La capacité à s’adapter au changement ou à être plus agile n’est pas nouvelle. La SOA (architecture orientée services) et le cloud computing ont encouragé les architectes à offrir le plus de dextérité. Il n’est pas surprenant qu’une architecture ne fournisse pas de capacités de modification rapide à moins que vous ne la conceviez pour elle. Lorsque vous superposez plusieurs systèmes au-dessus d’un style qui ne s’adapte pas facilement aux changements rapides, vous aurez plus de couches de problèmes.

Comment planifions-nous ce dont nous ne savons pas qu’il se produira ?

Nous pouvons définir la capacité réelle à devenir un système et nous assurer qu’il s’agit d’un préoccupation architecturale. Cela nécessite des actions supplémentaires qui coûteront plus d’argent et de temps à l’avance, mais elles seront payantes à long terme. Certaines de ces actions incluent :

Placer la volatilité dans des domaines. Qu’il s’agisse de données, de règles d’organisation ou de comportement d’application, offrez la possibilité d’intégrer des changements de configuration rapides sans redévelopper et retester l’ensemble du système. Ceci est beaucoup plus puissant lorsqu’il est utilisé dans des clouds publics, en pensant que des systèmes largement distribués peuvent exploiter des configurations centralisées.

Utilisation courante des services. Des microservices aux services de base, décomposez les services discrets et non discrets qui peuvent être réutilisés dans toute l’architecture. Fournir à ces services la capacité de modifier sans redéploiement ni retest, au moins la majorité du temps.

Utilisation de l’abstraction. L’abstraction est un outil crucial pour faire face aux changements nécessaires de l’information physique et du traitement physique. En termes simples, ce système permet de placer la volatilité dans des domaines, tels que définis ci-dessus. Nous modifions ces structures et ces séquences dans les logiciels pour modifier les processus physiques et le stockage physique des informations, et non pour forcer les modifications des systèmes back-end.

Oui, il y a bien d’autres astuces à prendre en compte. Si vous ne comprenez pas ce que sont ces modèles d’options, vous ne comprendrez probablement pas qu’ils sont nécessaires avant qu’il ne soit trop tard. De nombreux concepteurs de cloud ne donnent toujours pas la priorité aux conceptions capables de s’adapter à des changements rapides. Beaucoup ne comprennent pas comment le faire, et ceux qui le font soulignent généralement les dépenses et le temps supplémentaires comme raisons d’éviter les étapes supplémentaires.

À moins que nous ne commencions à planifier des modifications, nous verrons des entreprises d’un milliard de dollars disparaître à mesure qu’elles finiront par être perturbées. La majorité de ces échecs majeurs remontent à l’incapacité d’une entreprise à se tenir au courant des changements pour rester compétitive. Être agile n’est plus quelque chose de formidable, c’est une exigence. Peu importe que vous développiez une toute nouvelle entreprise ou que vous ayez besoin de réparer l’architecture existante. Découvrez comment mettre la volatilité dans les domaines. Sortez et recyclez les services quand et où vous le pouvez. Spécifiez comment un système peut utiliser au mieux l’abstraction.

Simple, non ? Il est temps de se mettre au travail.

.

Toute l’actualité en temps réel, est sur L’Entrepreneur

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici