Réponse courte : oui. Mais cela nécessite un autre type d'état d'esprit.

Le défi du monolithe

Les systèmes monolithiques sont souvent vastes, complexes et le résultat d'années d'évolution. Un simple changement dans une partie du système peut déclencher des effets secondaires inattendus ailleurs. Nous testons donc à nouveau. Et encore. Jusqu'à ce que finalement... personne n'ose publier.

Le résultat ? Longs délais d'attente. Comportement peu enclin à prendre des risques. Frustration des utilisateurs et des équipes. Pourtant, de plus en plus d'organisations souhaitent appliquer les principes DevOps, même dans ces paysages monolithiques.

Pourquoi ?

Parce que la promesse d'un retour d'information plus rapide, d'une véritable appropriation et d'une plus grande satisfaction du client est tout aussi pertinente ici. Peut-être même plus.

Ce que Gene Kim et Steven Spear nous apprennent

Au Le projet Licorne et Câbler l'organisation gagnante, Gene Kim montre que l'accélération et l'amélioration ne dépendent pas uniquement de la technologie. Elles sont le résultat d'une conception sociale et organisationnelle.

Il décrit trois principes essentiels :

• SimplificationLes objectifs de l'UE : réduire la complexité afin que le travail devienne gérable et modifiable.
• SlowificationLe projet de la Commission européenne : prendre le temps de ralentir intentionnellement, de réfléchir et d'élaborer des solutions solides.
• Amplification: renforcer les signaux émis par le système, notamment les erreurs, le retour d'information et les opportunités, afin que les équipes puissent réagir plus rapidement.

Dans un contexte monolithique, ces principes ne sont pas facultatifs. Ce sont des tactiques de survie. Plus le système est complexe, plus il est nécessaire de simplifier, de ralentir délibérément et d'écouter attentivement ce que le système vous dit.

Les trois niveaux du changement organisationnel

Gene Kim décrit également trois niveaux distincts où l'amélioration peut se produire :

• Couche 1 - L'objet technique
  Le niveau de travail direct : écrire du code, exécuter des tests, corriger des défauts.
• Couche 2 - Outils et instruments
  Les structures qui soutiennent le travail : pipelines de construction, automatisation des tests, systèmes de surveillance.
• Couche 3 - Le circuit social
  La couche souvent négligée : la façon dont les gens collaborent, partagent leurs connaissances, discutent des échecs et remettent en question les hypothèses.

Les transformations DevOps échouent souvent parce que l'accent est mis sur la couche 1. Vous introduisez le CI/CD ou de nouveaux outils, mais si les gens ont toujours besoin d'approbations manuelles (couche 2) ou ne se sentent pas en sécurité pour s'exprimer (couche 3), le système reste bloqué.

Dans un monolithe, il est souvent difficile de modifier la couche 1. Le code est ancien, volumineux ou étroitement couplé. La mise à niveau de la couche 2 peut également être lente et coûteuse. Mais la couche 3, le circuit social, est l'endroit où vous pouvez commencer tout de suite :

• Changez les conversations que vous avez.
• Examinez les incidents ensemble, non pas pour attribuer des responsabilités, mais pour apprendre.
• Posez des questions sans porter de jugement.
• Appropriez-vous l'ensemble, même si vous ne pouvez en changer qu'une partie.

Se connecter aux cinq idéaux de Gene Kim

• Localité et simplicité
  Simplifier et attribuer la propriété par domaine. Même au sein d'un monolithe, la prise de décision locale favorise l'autonomie.
• Concentration, fluidité et joie
  Le flux ne provient pas seulement de l'automatisation, il émerge de la collaboration. Limitez le travail en cours, protégez la concentration et la joie suivra.
• Amélioration du travail quotidien
  L'amélioration devrait faire partie du travail quotidien, et non pas être une réflexion après coup. Créez des moments pour ralentir et apprendre. Votre système devient plus sûr et plus intelligent.
• Sécurité psychologique
  C'est le fondement de la couche 3. Sans sécurité, les gens cachent les problèmes au lieu de les résoudre. Il n'y a pas de DevOps durable sans cela.
• L'orientation client
  Dans un environnement traditionnel, le client peut sembler très éloigné. En amplifiant le retour d'information par le biais de mesures, de canaux d'assistance ou d'histoires d'utilisateurs réels, vous reconnectez les équipes avec un objectif.

Comment commencer ?

DevOps dans un contexte monolithique :

• Création propriété au niveau du domaine, même au sein d'une base de code commune.
• Investir dans automatisation des tests et créer des réseaux pour rétablir la confiance dans le changement.
• Bâtiment temps de réflexionLe programme d'action de l'Union européenne : arrêter de courir, commencer à s'améliorer.
• Renforcer la câblage social entre les équipes au lieu de protéger les silos.
• Avoir le courage de simplifier, même lorsque cela semble risqué.

Et peut-être le plus important :
Concentrez-vous sur la couche où vous faire ont une influence.
Toutes les organisations ne peuvent pas passer aux microservices du jour au lendemain, mais chaque équipe peut commencer à améliorer la collaboration, l'appropriation et le flux, dès aujourd'hui.

En fin de compte

DevOps n'est pas une destination finale. Il s'agit d'une méthode de travail qui permet de fournir de la valeur plus rapidement, de manière plus sûre et avec plus de plaisir. Même dans un environnement monolithique, les équipes peuvent se développer en termes d'appropriation, de collaboration et d'amélioration continue.

Le voyage ne commence pas avec l'outillage. Il commence par le comportement. Pas avec des microservices, mais avec des personnes. Et c'est peut-être exactement ce dont votre système et votre organisation ont besoin en ce moment.

Entrer contact Avec le mouvement connecté.