Les standards sont parfois vus comme l’antithèse de l’innovation. Et cela peut se comprendre : après tout, abandonner un buffet à volonté (autrement dit, une infinité de pratiques) pour se limiter à un menu fixe (un nombre réduit de pratiques standardisées) n’est pas une proposition très attrayante à première vue. Sans compter que les standards sont généralement associés au monde austère de conformité, et que celui-ci ne fait pas franchement chavirer les foules… Car les standards ont des noms très officiels tels que ISO 8076.905E et débordent de cases à cocher, d’auditeurs et de comités de contrôle : absolument rien qui ne puisse encourager la créativité.

Mais quand on pense innovation, et, en particulier d’innovation par le code, on réalise que tout cela n’existe pas : il n’y a aucun standard officiel qui ne régisse le choix des entreprises en matière de langages de programmation, de frameworks de développement ou de protocoles à implémenter dans tel ou tel cas.

Sur le terrain le choix se fait donc plutôt en fonction de considérations très pratiques telles que la disponibilité des talents, la capacité à supporter le projet, et bien entendu le coût total des logiciels ou des systèmes sur toute leur durée de vie (souvent considérable !)

Des études sur les vingt dernières années ont montré que la durée de vie moyenne du logiciel d’entreprise est de six à huit ans. Et cela augmente pour les projets les plus ambitieux : au-delà d’un million de lignes de code, la durée de vie dépasse la décennie, et peut aller jusqu’à 14 ans.

Maintenant, revenons à nos NetOps et souvenons-nous que les outils d’automatisation du réseau sont, eux aussi, du code. Durant toute la durée de vie d’un système NetOps, de nombreux administrateurs et développeurs donc seront chargés d’ajouter un bout de code par ci, d’améliorer telle API par-là, d’adapter tel connecteur à tel nouveau système, et bien sûr de déployer rapidement toutes ces modifications. Mais si chacun le fait dans son coin avec les outils de son choix, la pérennité du système NetOps, qui va pourtant devoir vivre presque une décennie, est mise à mal.

C’est exactement pour cela que la standardisation des pratiques NetOps est une bonne chose, et en particulier pour tous ceux qui devront développer et maintenir des systèmes d’automatisation du déploiement et de l’orchestration réseau, ou des infrastructures de services applicatifs.

Les silos, c’est pour les fermes

Si l’une des équipes choisit Python alors qu’une autre préfère PowerShell, on crée un silo organisationnel qui empêchera tout partage des compétences. Et c’est un souci ! Le premier défi de l’approche NetOps est en effet le manque de compétences (selon 49% des NetOps ayant répondu à l’étude « State of Network Automation 2018 »).

Dans ces conditions, il semble totalement anormal de créer des obstacles supplémentaires en laissant proliférer différents langages et outils à travers l’organisation. De même qu’il serait suicidaire de choisir des langages pour lesquels il n’y aucune source locale de talents : si les écoles d’ingénieurs environnantes privilégient Python et que l’entreprise choisi PowerShell, le recrutement sera probablement un peu plus compliqué…

Évidemment, il est rare qu’une organisation qui produit du code puisse standardiser sur un seul langage. Mais généralement, elle essaie de se limiter à une petite poignée. Et c’est exactement ce que devrait faire l’univers du NetOps : s’inspirer de ce que font déjà les mondes du développement et du DevOps car cela a porté ses fruits, notamment en termes d’optimisation des talents et même, comme nous allons le voir, d’innovation.

Le temps, c’est de l’argent

Beaucoup de NetOps n’arrivent déjà pas à suivre le rythme des requêtes des DevOps, du développement et des métiers. Et cela est accentué par le fait que les univers du NetOps et de l’automatisation réseau sont des environnements très hétérogènes avec peu d’intégration pré-packagée.

D’ailleurs, dans le rapport « State of Network Automation » mentionné plus haut, le manque d’intégration disponible est le second défi majeur mentionné, avec 47% des NetOps interrogés.

Standardiser sur les outils (et les infrastructures telles que les services applicatifs lorsque c’est possible) offre une opportunité de réduire le poids de l’intégration à travers l’organisation. Ce qu’une équipe développe, l’autre peut l’utiliser pour réduire le temps d’automatisation d’un autre projet.

Et ce n’est guère une surprise : la réutilisation fait gagner du temps, et donc de la productivité. C’est déjà le cas avec l’Open Source, où 80 à 90 % des applications actuelles intègrent des composants tiers ou Libres. Les mêmes principes peuvent tout à fait être appliqués à l’automatisation réseau en s’appuyant sur des intégrations existantes. Établir une culture du partage et de la réutilisation à travers toute l’entreprise permettra de récolter à terme tous les bénéfices de la standardisation.

Favoriser l’innovation

Dans ces conditions, plutôt que limiter l’innovation, comme certains ont pu le croire, la standardisation peut au contraire se révéler être un véritable catalyseur pour l’innovation. Car en généralisant les outils et les pratiques à travers les domaines opérationnels, l’entreprise s’offre une plateforme d’expertises et d’expériences partagées, avec des contributeurs capables de mieux collaborer.

Un tel ensemble de talents coordonnés au sein de l’organisation sera plus à même de proposer de nouvelles idées, de challenger les idées reçues ou d’imaginer de nouvelles fonctionnalités – et tout cela sans passer par l’habituelle (et longue !) étape de l’acclimatation.

Enfin, la standardisation accélère l’implémentation au quotidien, en grande partie grâce à la familiarisation commune aux outils. Plus l’on travaille longtemps avec le même outil ou le même langage, et meilleur l’on devient. Ce qui se traduit, évidemment, par une meilleure productivité et la capacité à proposer des solutions beaucoup plus innovantes autour de ces technologies.

La standardisation est une opportunité

Certes, à première vue une approche standardisée peut sembler rigide et contre-productive. En particulier si le standard fait disparaitre votre outil de prédilection. Mais quoi qu’il en soit, faire le choix de la standardisation dans l’univers du NetOps fera toujours émerger à terme une solide fondation pour les systèmes d’automatisation et les outils qui supportent le business. Et cela offrira aux NetOps de nouvelles opportunités d’apporter de la valeur à l’ensemble de la chaîne du déploiement continu.

Mais évidemment, il n’est pas question de standardiser par principe. Il est important de prendre en considération l’existant, en matière de compétences disponibles, notamment. Intéressez-vous notamment à la cartographie des talents dans votre région (universités, écoles d’ingénieurs…) et des technologies d’automatisation qui y sont enseignées, afin de vous assurer que vous ne soyez pas isolés dans vos choix technologiques.

Et une dernière astuce : commencez à standardiser dès aujourd’hui ! Ne traitez pas le NetOps comme l’a été en son temps la sécurité, en imaginant qu’il s’agit de quelque chose que l’on peut venir greffer en fin de projet (demandez d’ailleurs aux SecOps combien de temps il a fallu à la sécurité pour se débarrasser de cette mauvaise habitude !).

Plongez dès aujourd’hui dans la standardisation, au plus tôt de vos projets d’automatisation, afin d’éviter le piège de la dette technique et architecturale plus tard dans le projet. Car il sera alors beaucoup plus difficile de standardiser !

En bref, pour bien standardiser, standardisez tôt. Et vos NetOps vous remercieront…

___________
Lori MacVittie est chercheur en cyber-menaces, F5 Networks