Les ARB traditionnels sont dépassés dans les environnements Agile et DevOps
Les comités d’examen de l’architecture traditionnels semblent être des reliques dans les organisations d’aujourd’hui qui évoluent rapidement et qui sont à la pointe de la technologie. Ils sont enracinés dans une culture de paperasserie et de contrôle rigide, qui ne s’accorde pas bien avec la vitesse effrénée du développement agile ou l’éthique d’auto-organisation de DevOps. Dans un monde où les décisions doivent être prises rapidement et où les cycles de développement de logiciels se mesurent en semaines et non en mois, l’ARB à l’ancienne ralentit les choses.
La mentalité traditionnelle de « taille unique » est un problème. Lorsque les plates-formes à code réduit ou sans code, l’IA et les outils modulaires donnent aux équipes une autonomie sans précédent, pourquoi imposer un modèle de gouvernance descendant ? L’Open Group Architecture Framework (TOGAF) énumère plus de 20 responsabilités pour les ARB, mais nombre d’entre elles – comme le fait de mandater les ARB en tant qu’autorité unique de prise de décision – ne tiennent plus la route. Les équipes modernes ont besoin de flexibilité, pas d’un gardien.
Ne jetez pas les ARB par la fenêtre, essayez plutôt de les faire évoluer. Plutôt que de s’appuyer sur des processus obsolètes, les ARB doivent adopter un rôle dynamique et consultatif qui soutienne la rapidité et la créativité des équipes d’ingénieurs d’aujourd’hui.
« L’innovation ne doit pas rester bloquée dans l’attente d’une autorisation. Les équipes ont besoin de soutien, pas d’un goulot d’étranglement, et les ARB qui s’accrochent aux flux de travail hérités ne feront que se retrouver à la traîne.
Mettre l’accent sur la collaboration, la confiance et le partenariat
L’avenir des comités d’architecture réside dans la collaboration et non dans le contrôle. Au lieu d’être considérés comme des obstacles, les ARB doivent devenir des alliés de confiance qui offrent des conseils sans faire de microgestion. C’est ce dont nous parlons lorsque nous disons que les ARB doivent s’orienter vers la promotion de la confiance et du partenariat entre les équipes DevOps, les responsables de la conformité et les parties prenantes de l’entreprise.
Voici l’exercice d’équilibre que les ARB doivent maîtriser. L’innovation va vite, mais la conformité ne peut être ignorée. L’expérimentation est un moteur de croissance, mais elle ne doit pas se faire au détriment de la fiabilité. Les équipes s’épanouissent dans l’autonomie, mais elles ont aussi besoin de garde-fous partagés pour éviter que les projets ne dévient de leur trajectoire. Un bon ARB trouve le juste milieu entre ces priorités concurrentes et aide tout le monde à rester aligné.
Dalan Winbush, DSI, souligne ici un point important : Aujourd’hui, les ARB ne se limitent pas à l’architecture. Ils s’attaquent à la gouvernance, à la sécurité, à la gestion des données et même à la collaboration entre les équipes.
Cette perspective plus large positionne les ARB non pas comme des obstacles, mais comme des facilitateurs (oui, je sais que nous n’aimons pas ce mot). En restant flexibles et tournés vers l’avenir, les ARB peuvent devenir un élément clé de la réalisation des objectifs de l’entreprise sans sacrifier l’agilité dont les équipes modernes ont besoin.
Les ARB peuvent atténuer la dette technique et gérer la complexité
Si vous ignorez la dette technique, la pile devient de plus en plus grande jusqu’à ce qu’elle ralentisse tout. C’est là que les ARB peuvent faire la différence. Ils sont là pour aider les équipes à éviter de construire un château de cartes en matière d’architecture.
Le problème des microservices est clair : ils sont puissants mais peuvent tourner au chaos si personne n’y prête attention. En l’absence de normes relatives à des aspects tels que la facilité d’utilisation, la fiabilité et les tests, vous vous retrouvez avec des API auxquelles personne ne fait confiance et des services impossibles à maintenir. Et c’est sans parler des pipelines CI/CD à la Frankenstein qui apparaissent lorsque chaque équipe construit le sien à partir de zéro. C’est inefficace et, au fil du temps, cela ralentit la vitesse de développement.
Rob Reid de Cockroach Labs a raison de souligner que les systèmes d’aujourd’hui sont bien plus complexes que les architectures client-serveur du passé. Les ARB sont dans une position unique pour guider les équipes dans la simplification de leurs flux de travail, la gestion de la dette technique et l’évitement des pièges. Des mesures, des normes partagées et une approche collaborative sont les outils qui permettent d’éviter l’emballement de la complexité, ce qui est bénéfique pour toutes les parties concernées.
Hiérarchiser et simplifier la remédiation des risques
Les risques sont inévitables, mais leur bonne gestion est ce qui sépare les organisations prospères de celles qui sont constamment en train de se rattraper. C’est là que les ARB peuvent briller : en jouant le rôle de guide dans la hiérarchisation et la gestion des risques avant qu’ils ne fassent boule de neige et ne deviennent des problèmes coûteux.
Les outils actuels, comme le registre des risques de Jira et les fonctions de gestion des risques de ServiceNow, facilitent plus que jamais le suivi et l’évaluation des risques. Mais les outils seuls ne résoudront pas le problème. Les ARB apportent la perspective et l’expertise nécessaires pour évaluer ce qui compte le plus. L’alignement de la gestion des risques sur les flux de travail agiles aide ces équipes à prendre des décisions plus intelligentes sans faire dérailler les progrès.
Miles Ward, directeur technique de SADA, le dit bien. Il est facile de réagir aux violations ou aux dépassements de coûts, mais c’est dans la prévention proactive que réside le travail le plus difficile. Les ARB peuvent jouer un rôle de premier plan à cet égard, en apportant des informations exploitables et en permettant aux équipes de se concentrer sur les risques qui comptent vraiment.
« Avec les ARB comme guide, les organisations peuvent éviter des surprises coûteuses et maintenir leur élan.
Adopter l’IA, l’automatisation et l’observabilité
Les ARB doivent se tourner vers l’avenir en intégrant l’IA, l’automatisation et l’observabilité dans leurs processus. Pourquoi ? Parce que l’environnement de développement moderne est déjà en train de prendre de l’avance et que les ARB ne peuvent pas se permettre de rester à la traîne.
Les outils pilotés par l’IA peuvent transformer le mode de fonctionnement des ARB. Imaginez que vous puissiez visualiser et analyser une architecture en temps réel, avec des informations automatisées signalant les risques potentiels ou les inefficacités avant qu’ils ne deviennent des problèmes. C’est ce qui se passe aujourd’hui. L’automatisation permet également d’alléger les tâches routinières, libérant ainsi les ARB pour qu’ils se concentrent sur la stratégie globale.
Moti Rafalin de vFunction présente un excellent argument en faveur des normes d’observabilité. En connectant les métriques de développement et d’exploitation, les ARB peuvent gérer l’architecture de manière proactive au lieu d’éteindre constamment les incendies. Il est nécessaire d’être proactif pour éviter la prolifération de microservices qui transforme l’innovation en un cauchemar de maintenance.
Dernières réflexions
Lorsque vous réfléchissez à l’avenir de votre comité de révision de l’architecture – ou quel que soit le nom que vous lui donnez – posez-vous la question suivante : Vos systèmes et processus permettent-ils réellement à vos équipes d’innover ou les ralentissent-ils discrètement ? Les entreprises qui prospèrent avancent rapidement avec un objectif, en équilibrant la créativité et la discipline.
