Ce n’est pas une version, c’est un cycle de vie

C'est un vieux mantra dans le domaine de la technologie : Soit vous avez la bonne technologie, soit vous n’arrivez à rien. Mais le principe selon lequel disposer de la meilleure technologie est synonyme de succès est-il vraiment valable ?

Aujourd’hui, nous savons qu’il y a bien plus que cela. Vous pouvez créer la meilleure technologie au monde, mais si vous n’aidez pas les gens à comprendre comment appliquer les nouveaux concepts et capacités à leurs problèmes, vous n’aurez qu’un widget que personne ne pourra utiliser, et aucun moyen de savoir s’il fonctionne vraiment.

Le véritable travail de création d’un produit réussi se fait lorsque nous investissons à parts égales dans le développement de ce produit et dans les personnes qui l’utiliseront dans leur environnement. À mesure que la technologie évolue, il est important que les fournisseurs investissent activement dans l’enseignement, le mentorat et l’acquisition par les personnes, avant même la conception des produits, des compétences fondamentales nécessaires pour exploiter les nouvelles technologies.

En procédant ainsi, nous contribuons à créer une base d’utilisateurs meilleure et mieux informée, qui peut appliquer son expérience et son contexte. Et à son tour, cette base d’utilisateurs nouvellement informée forme une relation symbiotique avec nous en tant que fournisseur, aidant à guider la manière dont nous développons des produits et des solutions à partir d’une position d’autorité mature et informée.

Dans cet environnement, la barre du succès ne réside plus dans le lancement d’un nouveau produit. Il s’agit d’engager et d’écouter en permanence tous les composants du produit (clients, partenaires, ingénieurs F5, personnel d’assistance) dans un cycle de vie constant d’innovation et d’amélioration.

Utiliser les méthodologies DevOps pour la formation

Vous pouvez voir comment cela fonctionne en consultant l’historique du programme Super-NetOps . Dans le cadre de la transformation de F5 en une société de services d'applications multi-cloud, nous avons dû former des centaines d'ingénieurs à travers le monde avec un nouvel ensemble de compétences fondamentales dans les méthodologies cloud, d'automatisation, d'orchestration et DevOps.

Ce faisant, nous avons travaillé dur pour construire une relation symbiotique avec nos propres ingénieurs. Le cycle ressemblait à ceci : Développer du contenu de formation. Testez le contenu avec quelques utilisateurs. Déterminez où l’expérience utilisateur doit être améliorée. Intégrez cela à notre produit. Répéter.

En mettant un produit sur le marché auprès des clients, vous pouvez corréler cette même méthodologie DevOps et Agile avec ceci : Vous construisez quelque chose, et maintenant vous avez un prototype. Vous devez obtenir des retours, mais vous n’en obtiendrez pas tant que vous n’aurez pas trouvé des personnes prêtes à y consacrer du temps et des efforts. Et pour cela, ils ont besoin de formation. Ils ont besoin de documentation. Ils ont besoin d’être accompagnés pour y parvenir.

Ainsi, parallèlement à nos efforts de développement, nous élaborons les mécanismes de notre formation. Et cela implique en partie de créer une boucle de rétroaction, à la fois sur la formation et sur les produits eux-mêmes. Comment pouvons-nous faire en sorte que les personnes qui utilisent ces prototypes puissent contribuer de manière open source ? Comment pouvons-nous apprendre à partir du moment où un client se retrouve bloqué dans une implémentation ? Et comment pouvons-nous exploiter ces apprentissages pour rendre nos produits et notre support encore meilleurs ?

Au cours des dernières années, nous avons impliqué nos clients et la communauté, et ces efforts ont conduit au Super-NetOps d'aujourd'hui, s'appuyant sur le lancement du programme chez Agility il y a deux ans.

Il s’agissait d’un changement fondamental pour nos ingénieurs centrés sur NetOps. Nous ne nous contentons pas de créer des solutions d’automatisation et d’orchestration, nous nous alignons en réalité sur la méthodologie autour de DevOps et du processus logiciel. Nous concevons comme s’il s’agissait d’un projet logiciel distribué géant qui s’exécute et s’intègre à la plateforme F5, et non d’éléments réseau intégrés à ce qui ressemble à un système logiciel.

Créer des partenariats

Tout cela consiste à la fois à adopter et à s’engager dans DevOps, mais aussi à créer des partenariats. Nous avons maintenant les éléments en place pour avoir une nouvelle conversation avec les clients. Nous écoutons attentivement et menons un débat actif et constructif, entièrement axé sur la manière d’amener le client à obtenir le résultat le plus satisfaisant. Parfois, cela se résume à dire oui, nous allons développer une fonctionnalité. Parfois, nous vous déconseillons de suivre cette voie.

Cela nous donne également les outils pour aider NetOps à devenir un véritable partenaire de DevOps. Ils ne doivent pas forcément être cette personne qui se contente de se voir confier des projets qui lui ont été lancés par-dessus bord. Ils peuvent être un partenaire, celui qui peut aider les équipes DevOps et les développeurs à réussir et à faire chanter leur application, leur objet, leur création. Si cette personne n’existe pas déjà dans votre entreprise, nous pouvons l’y intégrer en deux semaines.

Passer par ce processus et opérer ces changements a fondamentalement changé la façon dont F5 considère qui nous allons être. Nous comprenons désormais comment nous engager dans la pointe de la technologie, avec la manière dont les écosystèmes de conteneurs sont construits, la manière dont les microservices sont construits, la manière dont les logiciels sont développés à l’ère moderne.

Et comme vous le verrez avec notre sortie des API Automation Toolchain ce mois-ci, c'est une philosophie qui fait vraiment la différence dans nos produits également, un cycle de vie à la fois.