Initiatives et objectifs
Si la transformation numérique nous a laissé quelque chose, c'est l'état d'esprit de changement constant, ou d'amélioration continue, selon lequel toute entreprise ou individu doit toujours être en mouvement pour atteindre ses objectifs. La clé est d'avancer par le biais d'un flux de petites initiatives révisables qui apportent des changements (dans nos processus, nos activités, nos départements) et dont l'impact peut être mesuré pour guider l'initiative suivante.
Ce cycle constant implique d'avoir des objectifs clairs (mais pas nécessairement immuables), de lancer des initiatives avec agilité (afin de pouvoir attribuer des résultats aux initiatives et d'avoir la capacité d'itérer) et de mesurer correctement l'impact sur les objectifs.
Au départ, il peut sembler que mesurer l'impact d'une initiative, à l'ère où les organisations stockent toutes les informations dans une perspective d'avenir, soit une affaire simple. Toutefois, le fait de disposer des données ne permet pas de répondre directement à la question. Le plus difficile est d'interpréter ces informations et de poser les bonnes questions.
Pour mesurer si nous atteignons les objectifs, nous devons les relier à de bons indicateurs clés de performance (KPIS) qui sont clairement liés aux objectifs (et contextualisés). Ensuite, identifiez les mesures disponibles qui seront utilisées pour formuler les indicateurs clés de performance.
Parfois, la relation entre objectif, indicateur et métrique est simple et directe. Par exemple, si l'un des objectifs était d'augmenter les ventes annuelles de 20%, l'indicateur serait l'évolution des ventes sur une période d'un an, et serait calculé à partir des ventes issues du CRM.
En d'autres occasions, la relation n'est pas aussi directe. Par exemple, si notre objectif était d'augmenter l'engagement du personnel de 20 %, nous constaterions qu'il n'existe pas d'indicateur direct ou universel et nous devrions probablement en concevoir un sur mesure, basé sur une combinaison de plusieurs mesures, comme, par exemple, le taux de participation aux événements de l'entreprise, l'augmentation du nombre d'idées dans la boîte à idées, le nombre de recommandations internes, etc.
Ces types d'indicateurs sont connus sous le nom d'indicateurs proxy, car lorsque nous ne pouvons pas mesurer directement l'état d'un système, nous devons nous appuyer sur d'autres mesures qui sont liées au système que nous voulons mesurer. Ces indicateurs de substitution auront une relation physique avec l'indicateur souhaité qui peut être calculé à partir d'eux, de la même manière que le climat d'il y a des millions d'années est calculé à l'aide de paramètres alternatifs actuellement disponibles tels que les niveaux d'isotopes.
Dans cet article, nous allons parler d'une mesure très intéressante comme les dépenses liées au cloud, qui peut être pertinente pour les indicateurs de forme en raison de la quantité d'informations qu'elle contient.
Les dépenses dans le Cloud
Les organisations "natives du Cloud" fonctionnent selon ce principe d'amélioration continue car elles ont l'avantage que le "système d'exploitation" sur lequel fonctionnent leurs charges de travail est conçu pour être piloté par le code, ce qui leur donne la souplesse nécessaire pour mettre en œuvre des changements. Leurs applications sont conçues nativement pour tirer parti des ressources du Cloud, où une approche de paiement à l'utilisation leur donne la possibilité de mieux comprendre leur investissement.
Avant le Cloud, le calcul des coûts d'infrastructure était compliqué car il y avait de nombreux coûts partagés (des serveurs aux coûts énergétiques des bâtiments), des coûts de main-d'œuvre pour la maintenance, des licences, le matériel était un investissement à amortir, et il n'était pas nécessaire de justifier l'effort de le calculer en permanence. L'infrastructure était donc généralement considérée comme faisant partie d'un centre de coûts informatiques commun. L'effort de décomposer le coût par unités commerciales, applications ou même équipements n'a pas été très fructueux.
Cependant, lorsque nous opérons dans le Cloud, ces données nous sont fournies sur la facture et nous pouvons savoir ce que coûte l'ensemble de l'infrastructure qui supporte nos charges de travail. Cela nous rend plus conscients de l'investissement nécessaire en ressources pour déployer un service ou un système. Mais le plus intéressant, c'est que ces dépenses peuvent être ventilées au niveau que nous souhaitons, de sorte que nous pourrions savoir combien chaque domaine, application, département, y compris les équipements, consomme. Et c'est pourquoi les dépenses liées au cloud deviennent une mesure très nutritive. Cependant, comme toute métrique, elle n'est pas simple ou directe à appliquer, et devra être contextualisée et calibrée avant d'être utilisée.
Tous les Hyperscalers fournissent une structure hiérarchique de comptes, de projets ou de groupes de ressources qui permettent de séparer les dépenses. Lorsque ce niveau de regroupement n'est pas suffisant, nous recourons à l'utilisation de labels de ressources qui nous permettront ensuite d'exploiter les informations relatives aux dépenses.
Les dépenses détaillées ainsi que l'utilisation des ressources nous permettent de calculer des aspects tels que, par exemple, le coût du stockage d'une donnée (un client, un fichier), les dépenses d'un service API, ou le moteur de recherche de la page d'accueil. Des données qu'il était impossible d'obtenir avant le Cloud.
Les dépenses liées au Cloudsont une mesure que les équipes d'ingénierie comprennent et qui les rend plus conscientes de l'impact de leurs décisions techniques sur l'équilibre général du produit sur lequel elles travaillent.
Lorsque nous parlons de mesures basées sur les dépenses en Cloud, nous nous concentrons sur la partie directement liée à l'utilisation de l'infrastructure, IaaS, que nous pouvons obtenir en séparant les dépenses par type de ressource, en laissant de côté les autres dépenses telles que le support ou les services PaaS pour d'autres types d'analyse.
Le coût du Cloud (IaaS) est une mesure de substitution pour la technologie sous-jacente qui nous permet de mesurer directement ou indirectement d'autres facteurs pertinents tels que:
- Performance du système. La performance est le rapport entre le travail utile obtenu dans un processus par rapport aux ressources totales utilisées. Dans notre cas, cela se traduit par un indicateur qui mesure le degré d'utilisation des ressources en Cloud. Par exemple, il peut être utilisé pour comparer deux technologies équivalentes, en mesurant la différence du nombre de demandes traitées entre deux alternatives ayant les mêmes ressources (même coût).
- Le retour sur investissement. L'atomicité avec laquelle les applications sont construites (grâce aux microservices, au serverless, etc.) permet de séparer les différentes parties qui les composent, de sorte que le retour sur investissement pourrait être mesuré au niveau de la fonctionnalité du produit, c'est-à-dire si le coût de l'infrastructure est compensé par l'augmentation de l'activité provoquée par une nouvelle fonctionnalité.
- La durabilité. L'une des raisons qui pèsent de plus en plus lourd dans la décision de migrer vers le Cloud est le remplacement des centres de données traditionnels par d'autres qui peuvent atteindre une meilleure efficacité. Aux objectifs liés à la durabilité peuvent s'ajouter des initiatives visant à réduire l'utilisation des ressources, ce qui se traduit par un coût inférieur en raison d'un double facteur : la réduction des ressources par l'optimisation et la substitution de ressources plus efficaces, qui sont généralement proposées par les Clouds à un prix inférieur.
- Le rapport coût-efficacité. Similaire au facteur précédent. Elle permet d'augmenter la marge d'un système (produit ou service de l'organisation) en réduisant les dépenses en Clouds par l'utilisation (optimisation de l'utilisation, etc.). Contrairement à la durabilité, ce facteur peut être amélioré en appliquant des réductions du coût du Cloud par le biais de remises pour l'engagement d'utilisation, comme la réservation d'instances ou l'utilisation d'instances spécifiques.
Durabilité
Le développement durable est devenu l'un des principaux axes des stratégies des organisations, faisant partie de leurs feuilles de route. Les activités d'une organisation commencent à prendre en compte leur impact sur l'environnement, même si nous sommes encore loin de pouvoir disposer de mesures qui incluent l'ensemble de la chaîne de valeur.
En ce sens, les dépenses liées au Cloud peuvent également être considérées comme un indicateur lié à la durabilité, car les fournisseurs de Cloud deviennent des partenaires stratégiques dans la chaîne d'approvisionnement et leur empreinte a un impact sur l'empreinte des organisations. Plus les dépenses sont faibles, meilleure est l'utilisation des ressources et donc plus faible est l'impact environnemental.
Le fournisseur de Cloud se préoccupe d'appliquer et de développer la technologie la plus efficace et la plus performante afin d'améliorer les marges, principalement par la réduction de l'énergie. L'investissement consenti par ces marques pour améliorer leurs infrastructures est difficile à réaliser individuellement par les organisations car elles ne peuvent pas appliquer les économies d'échelle, la mise en commun des ressources (conditionnement, entretien des installations, sécurité), la rotation plus fréquente du matériel, etc. L'efficacité de ces centres de données est mesurée par la métrique connue sous le nom de Power Usage Effectiveness (PUE), qui mesure le rapport entre l'énergie totale consommée et l'énergie nécessaire pour effectuer le calcul et est estimée à 1,1 dans les cas les plus efficaces.
Mais comme pour la sécurité des Clouds , la durabilité est une responsabilité partagée entre le fournisseur de Clouds et ses clients. C'est là que les clients ont la possibilité d'améliorer leur impact et que les mesures des dépenses peuvent indirectement nous aider à nous améliorer.
Les organisations opérant dans le Cloud doivent l'utiliser de manière responsable et activer des critères d'optimisation avant tout:
- Ajuster correctement les ressources à leurs besoins, en profitant de l'élasticité du Cloud pour évoluer en fonction de la demande. De cette manière, il n'est pas nécessaire de surdimensionner les infrastructures et donc les dépenses.
- Il tire parti de l'atomicité avec laquelle les applications sont construites pour appliquer des politiques de conception et des cycles de vie personnalisés pour chaque ressource. Par exemple, les données peuvent être séparées et différents systèmes de stockage peuvent être utilisés en fonction de la criticité de l'information, ou de ses attributs, de sorte que les données utilisées occasionnellement peuvent être archivées.
- Tirer parti de la maîtrise acquise dans le domaine de la livraison du code (CD) pour mettre à niveau l'infrastructure sans incidence sur l'activité. L'infrastructure des fournisseurs est constamment mise à niveau vers des versions plus efficaces. La migration des charges de travail vers une nouvelle infrastructure peut être simple pour les organisations qui ont atteint un niveau de maturité élevé dans leur processus de déploiement.
- Utilisez l'infrastructure en tant que code (IaC) pour recréer et retirer les environnements lorsque cela est nécessaire, et les libérer lorsqu'ils ne sont pas utilisés.
- Concevoir avec des caractéristiques réalistes de fiabilité, de résilience, de sécurité et de latence pour chaque type de charge de travail. L'augmentation de la fiabilité, de la résilience ou la réduction de la latence a des conséquences sur les architectures d'application qui influent sur les ressources consommées. Toutes les charges de travail n'ont pas les mêmes exigences, nous devons donc nous adapter à chaque cas.
La consommation du Cloud peut nous aider à estimer un impact initial et, par comparaison, à voir comment les initiatives d'optimisation peuvent réduire la consommation (proportionnellement à l'entreprise) et, par conséquent, fonctionner de manière plus durable.
FinOps
La prise de conscience de l'impact des décisions techniques sur le coût des systèmes transforme les équipes chargées des produits en petits investisseurs qui doivent trouver un équilibre entre les coûts et les avantages.
Pour les ingénieurs des équipes, la nouvelle mesure du coût du Cloud les incite à tenir compte de l'efficacité lors de la conception et de la mise en œuvre de leurs logiciels. Les décisions prises lors de la mise en œuvre, telles que la dette technique, peuvent désormais avoir un impact non seulement sur la maintenabilité des logiciels, mais aussi sur les coûts. Cela implique une activité supplémentaire qui augmente la charge cognitive des ingénieurs.
La charge cognitive est la quantité d'activités mentales que les développeurs doivent prendre en compte en même temps pour exécuter une tâche. Le modèle DevOps a augmenté leur charge cognitive en les sensibilisant aux aspects de développement, de productisation et d'infrastructure. Maintenant, l'ajout d'une nouvelle variable telle que le coût des ressources peut ajouter une nouvelle charge.
Pour réduire cette charge, les organisations intègrent des domaines de soutien dans la discipline FinOps, qui aident l'organisation à maximiser l'investissement dans le Cloud et à aligner les objectifs entre les différentes parties prenantes (finances, ingénierie, cadres et entreprises). En ce qui concerne les équipes d'ingénierie, les spécialistes FinOps aideront à intégrer les mesures avec le moins de friction possible, tout comme les équipes chargées des plateformes aident les équipes chargées des produits à se concentrer sur le développement.