Dans leur rapport 2018 intitulé L’année du DevOps d’entreprise, Forrester a déclaré : «Nos données confirmant que 50 % des organisations mettent en œuvre DevOps, les questions sont passées de « Qu'est-ce que DevOps ? » à « Comment mettre en œuvre DevOps à grande échelle ? »

DevOps favorise la création d'équipes plus petites, plus autonomes et plus performantes, ainsi que l'automatisation et la mesure. Il a un grand potentiel pour améliorer considérablement la façon dont l'informatique et les entreprises travaillent ensemble, et il constitue un renversement bienvenu après des années de centralisation et d'externalisation.

Mais nous constatons également que de nombreuses organisations sont confrontées à deux difficultés :

1. Une prolifération de nouveaux outils d'« automatisation » qui fonctionnent rarement ensemble. Il faut beaucoup de temps pour mettre en place un pipeline pour ces outils, et ils ne sont pas faciles à modifier et à gérer pour les équipes DevOps.
2. L'état d'esprit des architectes est toujours le même que celui d'une grande organisation informatique : soit les microservices ne sont pas du tout promus, soit une mauvaise approche des microservices est adoptée.

Sans adopter la technologie, la conception et l’architecture à la nouvelle façon de travailler, l’exercice DevOps sera un exercice désagréable sans avantages clairs.

Si les DSI introduisent DevOps à grande échelle dans l’ensemble de l’organisation informatique, il est absolument nécessaire de déployer également une nouvelle façon de concevoir en tenant compte de l’architecture de microservices (MSA). Sinon, les équipes dépendront les unes des autres et le résultat sera pire qu’avant.

L'utilisation d'un Plateforme à haute productivité est fortement recommandé. Ces plateformes disposent déjà d'un pipeline de livraison clair au sein du package, ce qui rend possible une automatisation et une adaptation plus poussées de l'intégration continue pour les personnes les moins techniques des équipes DevOps.

Figure 2 : Architecture, Méthodologie, Organisation, et L’automatisation doit être intégrée dans un parcours cohérent pour fonctionner.

Les services informatiques centraux disposent de composants informatiques centraux

Tout remonte à la loi de Conway de 1967 : «les organisations qui conçoivent des systèmes… sont contraintes de produire des conceptions qui sont des copies des structures de communication de ces organisations" .

Depuis 2005, un mouvement fort s'est développé en faveur de la centralisation de la DSI et, en son sein, de la séparation du Développement et des Opérations. Les motivations de ce mouvement étaient les économies d'échelle, la concentration des expertises, les synergies de la DSI entre les départements métiers et la possibilité de négocier des contrats de sourcing importants avec certaines composantes en délocalisation.

Selon la loi de Conway, les services informatiques centraux créaient souvent des composants informatiques qui ressemblaient à la structure organisationnelle de ce service informatique. Le service était souvent divisé en domaines d'expertise (par exemple, la centralisation des efforts UX, la centralisation de la gestion des processus métier (BPM), l'intégration dans les ESB, les règles dans un moteur de règles, etc.). L'architecture en couches SOA était adaptée à cela, et de nombreuses entreprises en ont fait leur architecture de référence.

Le département informatique central a cherché à éviter la duplication des données et des fonctions. D'une certaine manière, c'était compréhensible : au sein d'une même application, il existe de bonnes raisons d'éviter la duplication. Mais cela ne se traduit pas par une stratégie à l'échelle de l'entreprise, car les dépendances deviennent incontrôlables.

Comme nous l’avons douloureusement appris au cours des dix dernières années, l’idée d’une meilleure efficacité par des moyens plus importants n’a pas porté ses fruits. La flexibilité, la spécialisation, l’alignement des activités et les investissements informatiques à petite échelle basés sur des calculs de profits et de pertes liés à l’activité ont pratiquement disparu.

Le fait que le développement, les tests et les opérations aient été délocalisés, peut-être vers des fournisseurs différents, n'a pas aidé. La délocalisation a permis de faire la même chose à moindre coût, mais elle a creusé la distance entre les personnes qui devaient innover et les entreprises qui avaient besoin d'innover.

Cloud, Mode 2 et DevOps font bouger les choses

Entre 2010 et 2013, les offres Cloud sont devenues de plus en plus intéressantes. Mais les entreprises ont eu du mal à migrer vers le Cloud et à profiter de ses avantages. Elles étaient contraintes par des organisations informatiques rigides et par le fait que les composants informatiques étaient fonctionnellement très dépendants les uns des autres.

Au même moment, du côté des développeurs, DevOps prenait forme. Les développeurs disaient : «Il ne sert à rien d'être agile dans le développement si je ne peux pas déployer le composant par la suite« C'est-à-dire que l'ensemble de l'organisation doit être agile pour que les méthodologies agiles fonctionnent.

DevOps a également une grande part d'automatisation, le cloud et la conteneurisation permettant une toute nouvelle génération d'outils d'intégration continue. Les ressources informatiques locales devaient rivaliser avec les tarifs horaires plus bas des ressources offshore, et la solution était d'accroître l'innovation et l'automatisation.

En 2014, Gartner a proposé aux entreprises de travailler selon deux modes : un mode 1 stable et un mode 2 plus rapide et plus léger, afin de tirer parti de cette nouvelle évolution. Cela a permis aux entreprises de commencer à expérimenter avec des équipes plus petites, de nouvelles technologies et moins de paperasserie dans les domaines qui nécessitent un rythme d’innovation plus rapide.

Deux ans plus tard, l’expérience de rapidité et d’efficacité des entreprises migrant vers les technologies Cloud, travaillant en Mode 2 et utilisant des plateformes à haute productivité est si forte que les responsables informatiques adoptent le Mode 2 en se disant « pourquoi ne pas être efficaces dans tous les domaines du développement informatique ? »

La numérisation et DevOps sont-ils les moteurs du changement ?

Le vecteur de cette évolution semble être DevOps. En réaction au département informatique central, avec sa forte séparation entre le développement et les opérations, DevOps va jusqu'à l'extrémité opposée du spectre : les équipes DevOps alignées sur les petites entreprises qui possèdent leurs propres composants et gèrent leurs solutions également en production.

La première étape a consisté à fusionner les opérations et le développement, puis à inclure l’entreprise pour créer (Biz)DevOps. Cela revient à l'état antérieur à l'informatique centralisée, mais désormais dans le Cloud, avec des méthodes agiles et beaucoup plus d'automatisation. Une petite équipe peut désormais créer et maintenir des composants importants.

L’époque des grands services informatiques centraux n’est peut-être pas révolue, mais nous pensons que le temps est venu de séparer le service informatique de l’entreprise. La fusion entre l’entreprise et l’informatique résulte également de la numérisation des processus d’entreprise eux-mêmes.

L'informatique est promue de «quelque chose qui devrait simplement fonctionner”, au cœur des guerres de compétitivité. Amazon, Airbnb, Spotify, Uber, Netflix, Facebook et d’autres ont montré que des secteurs et des modèles commerciaux entiers peuvent être perturbés par l’évolution de l’informatique. Le DSI fait désormais partie du conseil d’administration de nombreuses entreprises, et l’objectif est de réveiller les services informatiques.

Les microservices et l'automatisation suivront

Selon la loi de Conway : avec de petites équipes DevOps autonomes, le monde commencera à produire de petits composants autonomes, appelés microservices. Outre la taille de l'équipe, il est également judicieux de produire des composants déployables capables de remplir une fonction métier de manière autonome. Cela permet de modéliser le paysage informatique au plus près de la manière dont l'entreprise est gérée. La flexibilité et les délais de mise sur le marché s'améliorent considérablement.

Nous constatons une amélioration de la vitesse de cinq à dix fois en passant au cloud et en utilisant une plate-forme à haute productivité telle que Mendix. Quand Mendix les composants deviennent plus volumineux, nous constatons une amélioration jusqu'à cinq fois de la vitesse de développement des fonctionnalités en divisant la portée fonctionnelle en microservices. DevOps et microservices sont plus ou moins indissociables, ils peuvent difficilement exister séparément.

Étapes pour que DevOps fonctionne avec succès

Cette évolution est très enthousiasmante, mais requiert également toute notre attention.

Nous recommandons à tout DSI, architecte, manager, coach agile, concepteur et développeur impliqué dans DevOps d'acquérir au moins une compréhension de base de la manière dont les microservices modifient notre façon de concevoir les choses. Mendix nous prévoyons de publier une série de blogs décrivant les microservices et nos expériences dans ce domaine, alors restez à l'écoute pour plus de contenu qui peut faire ou défaire vos efforts DevOps.

Nous recommandons également de combiner DevOps avec une plateforme à haute productivité. Un DSI ayant des objectifs ambitieux aura intérêt à éviter la longue phase de création d'une automatisation à partir de zéro et à se consacrer directement à la création de valeur pour l'entreprise.

Gardez un œil sur d’autres blogs sur la façon dont nous voyons le style DevOps et les microservices percer et évoluer vers le paradigme le plus important des 10 prochaines années.

BLOG : La valeur des microservices d'entreprise avec le low-code