Compétences essentielles pour DevOps : Comprendre et gérer le processus d’approvisionnement
Dans un blog précédent, j'ai expliqué pourquoi il est important d'adopter une approche de « réflexion systémique » pour la livraison d'applications, fonctionnant davantage comme une usine bien réglée et optimisée pour une livraison de valeur efficace. Pour y parvenir, il faut évaluer les outils sur lesquels vous comptez ainsi que le processus par lequel vous les sélectionnez et les achetez. L’efficacité nécessite de privilégier les modèles réutilisables lorsque cela est possible, ainsi que de sélectionner des outils et des processus cohérents entre les équipes et les environnements. En théorie, cela a du sens pour la plupart des gens, en particulier lorsque les outils en question sont liés à l’infrastructure ou à la sécurité, avec un impact minimal sur la fonction de l’application. Cependant, un obstacle sous-estimé à la construction de tels modèles se dresse souvent sur la voie : Le processus de fournisseur et d'approvisionnement.
À l’heure actuelle, il n’est pas rare que les ingénieurs DevOps utilisent des outils cloud natifs, des solutions open source ou d’autres types de ressources peu coûteuses (ou gratuites) qui ne nécessitent pas d’investissement important ni d’interaction avec l’équipe d’approvisionnement. Mais que faire si vous devez plaider en faveur d’un investissement informatique plus riche pour générer les gains d’efficacité nécessaires et garantir une meilleure sécurité et de meilleures performances pour vos applications ?
Plaidoyer en faveur de l’investissement dans les technologies de l’information
Voici quelques éléments que les professionnels DevOps doivent garder à l’esprit lorsqu’ils naviguent dans les eaux inconnues du processus d’approvisionnement.
- Se concentrer sur la valeur
Si vous lisez ce blog, vous préférez probablement vous concentrer sur les capacités technologiques nécessaires, vous pouvez parler d’API toute la journée et vous êtes obsédé par l’optimisation. Mais devinez quoi : vos collègues chargés de signer les gros chèques ne s’en soucient probablement pas du tout. C’est pourquoi la chose la plus importante que vous puissiez faire pour soutenir l’achat d’un nouvel outil ou d’une nouvelle ressource est d’articuler, dans leurs termes, la valeur commerciale qu’il apportera.
Souvent, cela commence par identifier ce qui manque ou manque actuellement. Demander l’achat d’un nouvel outil simplement parce qu’il est désormais disponible n’est pas aussi convaincant que de souligner un défaut ou une responsabilité importante, d’expliquer comment ce défaut crée des problèmes (ralentit la production, expose des vulnérabilités, etc.), puis de proposer un nouvel outil qui résoudra tout cela.
Les trois éléments clés sur lesquels se concentrer sont le coût, la valeur et le risque. Il est important d’en parler en termes commerciaux : comment une solution spécifique résout le problème identifié par :
- Réduire les coûts à court, moyen ou long terme
- Comment l'entreprise peut accroître son agilité, accélérer la mise sur le marché ou attirer de nouveaux clients
- Comment le risque commercial est réduit grâce à une meilleure conformité réglementaire, à un risque d'attaque réduit ou même à quelque chose qui réduit l'exposition concurrentielle
Dans tous ces cas, il est très important de quantifier chacun d’eux du mieux possible. Personne ne veut d’opinions purement qualitatives. Les données concrètes sont importantes.
Pour vos collègues des Achats (et plus largement des équipes Finance), tout a un coût et une valeur. Cela inclut le coût de l’inaction (face aux problèmes connus), ainsi que la valeur de libérer les travailleurs de la gestion de ces problèmes. Sachez simplement que, tandis que les équipes NetOps peuvent trouver un intérêt à éliminer les tâches banales simplement parce que cela rend le travail moins fastidieux, les équipes financières voient un intérêt à libérer ces mêmes ingénieurs pour qu'ils se concentrent sur des initiatives stratégiques et génératrices de revenus.
Will Marken, responsable des solutions techniques chez F5, suggère de « vous positionner comme un solutionneur de problèmes ; en vous concentrant sur la création de valeur, reliez la solution proposée aux aspirations de l'entreprise : cela montre que vous pouvez interagir avec la direction selon ses conditions et répondre à ses besoins. »
- Connaître le jargon : CapEx vs. abonnement
- Soyez persévérant
- Divisez-le en morceaux
- Faites équipe
Votre équipe peut être entièrement décidée à acheter une solution via un modèle d'abonnement, puis découvrir que votre organisation est axée sur des dépenses d'investissement importantes et qu'elle ne dispose pas d'un processus de financement des investissements informatiques sur la base d'un abonnement. Dans ce cas, vous avez du travail supplémentaire à faire. Il peut être plus simple pour vous de passer à une demande de budget d’investissement (par exemple, un seul achat important qui sera amorti au fil du temps). D’un autre côté, même les entreprises qui ont tardé à adopter les modèles d’abonnement cherchent comment les soutenir. Vous aurez peut-être simplement besoin de prévoir un peu de temps supplémentaire pendant que vos collègues des finances relèvent leurs propres défis en matière de processus organisationnels.
Aussi cliché que cela puisse paraître, c'est vraiment l'un de ces cas où c'est le voyage qui compte, et non la destination. Justifier des achats importants nécessite souvent plusieurs tentatives. En fait, votre demande pourrait bien être en concurrence avec d’autres qui ont fait le tour de deux ou trois cycles budgétaires, affinant leur orientation et recueillant du soutien en cours de route. N’abandonnez pas lorsque vous entendez « Non ». Au lieu de cela, planifiez-le, acceptez-le quand il arrive et avancez en faisant des ajustements à partir de là.
Abordez les achats comme vous le feriez pour toute autre tâche dans votre flux de travail Agile. Identifiez les problèmes ; résolvez-les un par un ; et itérez, itérez, itérez.
Pour les demandes budgétaires importantes, il est souvent utile de diviser votre projet en parties plus digestes. Cela peut être utile pour deux raisons : a) Il est plus facile de créer une preuve de concept (POC) plausible et d'identifier la valeur réelle lorsqu'il y a une concentration plus étroite ; et b) il est tout simplement plus facile pour les responsables de valider des demandes plus petites.
Il existe toutes sortes de raisons pour lesquelles il est judicieux de demander de l’aide aux autres membres de l’organisation. Pour commencer, vos pairs directs ou transversaux peuvent être plus familiers avec le processus d’approvisionnement en général, et avec la valeur des solutions F5 en particulier, et peuvent donc vous aider à formuler la demande (et à éviter les dangers connus). Vous pouvez également réduire le risque perçu en montrant comment la solution que vous proposez aura un impact positif sur plusieurs services. Enfin, il n’est pas rare (surtout dans les très grandes organisations) de découvrir qu’un autre groupe a déjà tenté une demande similaire à la vôtre (auquel cas vous pouvez apprendre d’eux) ou peut-être même commencé à mettre en œuvre une solution similaire (auquel cas vous pouvez vous associer à eux).
Note sur la structure
Lorsque vous entreprenez la création d’une demande budgétaire, vous pouvez vous appuyer sur bon nombre des mêmes tactiques que vous utiliseriez pour créer des documents plus typiques de votre domaine, tels que des livres blancs et des fiches techniques. Cela commence par trouver le modèle approprié afin que vous sachiez que votre demande ressemblera et se lira comme d'autres demandes que le responsable connaît. Cela implique également de le soumettre à plusieurs collègues pour recueillir leurs avis et commentaires tout au long du processus. Jon Gross, responsable du développement de produits chez F5, ajoute que « comme pour les fiches techniques et les livres blancs, le succès dépend souvent de la description ou du paragraphe d'ouverture. » Il vous suggère de « rechercher des architectures de référence et des cas d’utilisation existants qui peuvent étayer votre feuille de route de mise en œuvre avec des points de données du monde réel ».