Le CFO est responsable des finances, le COO des opérations, tout cela est clair.
Pour l’architecture d’entreprise, les PDG sont généralement les responsables ultimes en dehors de rôles de Chief Architect par exemple.
Mais qui est clairement responsable de votre architecture de la qualité logicielle?
L ‘«architecture» est présente de manière transversale et conduit à des confusions régulières: parle-t-on d’architecture d’entreprise, fonctionnelle ou technique?
La création de logiciels est en partie supportée par le processus de SDLC – Software Development Life Cycle – qui est architecturé, intentionnellement ou non.
L’architecture de la qualité logicielle est généralement diluée par les organisations dans différentes fonctions, entraînant une inclusion médiocre et incohérente.
Pour vous, où est votre architecte qualité assurant une approche holistique?
Les architectes traditionnels sont le pivot avec une vision globale au sein des organisations
Les architectes sont généralement accompagnés d’une aura de mystère, que font-ils en réalité?
En pivot entre le Business et l’IT, ils doivent généralement articuler des perspectives divergentes et transversales.
Les différenciateurs clés sont d’identifier les exigences structurantes fonctionnelles et non fonctionnelles, qui autrement auraient été manquées.
Cela implique que les architectes soient interfonctionnels et multidisciplinaires dans leurs interactions et leurs perspectives.
Ils ne sont pas nécessairement des experts dans divers domaines, mais ils doivent avoir la capacité d’inclure de manière proactive différentes visions.
Dans les interactions initiales, ils doivent être une véritable éponge capable de poser des questions pertinentes.
L’architecture de la qualité est généralement perdue dans l’organisation
Selon leur périmètre, les architectes peuvent plus ou moins interagir avec la qualité logicielle.
Une réelle difficulté réside dans le positionnement au sein des organisations, qui par design n’est pas aussi clair que celle d’un CFO.
La position finit souvent par se chevaucher avec d’autres selon le contexte de l’entreprise.
Votre CFO est responsable des finances, mais à qui appartient la qualité logicielle?
Antoine Craske
En plus de cette configuration complexe d’architectes, la qualité des logiciels n’est elle-même pas suffisamment comprise, manquant le lien avec les objectifs métier au sein des organisations.
Hormis le récent dialogue entre les développeurs et les opérations connu sous le nom de DevOps, les équipes qualité n’ont pas sauté rapidement dans le train du DevQAOps.
Je pense personnellement que nous nous retrouvons dans des organisations confuses, avec des responsabilités inconnues, mal définies, conduisant à une mauvaise performance.
Différents types d’architectes résident dans les organisations
Les rôles de l’architecte traditionnel peuvent être différenciés dans ce qui suit, inspiré de la pratique de l’architecture d’entreprise de Svyatoslav Kotusev.
Les architectes d’entreprise sont généralement des pivots entre le PDG, les conseils d’administration et la structure organisationnelle globale, la stratégie et son évolution.
En passant aux équipes opérationnelles, nous pouvons trouver des architectes de Business Unit et les architectes du domaine, assurant l’écosystème de leur périmètre.
Ils peuvent être complétés par des postes plus restreints tels que Architecte de solution, Architecte technique, Architectes cloud en fonction des organisations.
Les configurations dépendent de la maturité de l’entreprise, de la capacité et des exigences en termes d’architecture. Dans une petite structure, un seul architecte peut jouer les différents rôles.
La qualité logicielle est un système qui nécessite une architecture
La production de logiciels implique un système complet et complexe.
De son idéation, conception, mise en œuvre, exploitation et maintenance, différents acteurs sont impliqués dans toute la chaîne de valeur.
Nous faisons généralement référence au processus de cycle de vie du développement logiciel (SDLC), au moins pour son aspect de développement.
Des processus complémentaires doivent être inclus depuis la priorisation stratégique de l’initiative, jusqu’à l’instance de gouvernance technologique, fournissant de manière proactive les fondations nécessaires.
Mais qu’arrive-t-il à la qualité dans ces différents processus?
La qualité logicielle peut être évaluée dans les différentes étapes et processus impliqués.
Nous supposerons que le «pourquoi» du logiciel a du sens pour l’organisation, en passant au «quoi» et au «comment».
Une architecture qualitative commence par des exigences bien définies
Dès son idéation, les attributs de qualité du produit logiciel doivent être identifiés, en mentionnant les exigences fonctionnelles et non fonctionnelles.
Être capable de les identifier clairement est déjà un défi de qualité de communication, de formalisation et de priorisation.
Voici quelques attributs fonctionnels qui devraient être pris en compte dans l’ISO / CEI FCD 25010: exhaustivité, exactitude, pertinence.
Nous pouvons aller très loin avec le reste de la liste: performances, efficacité, compatibilité, utilisabilité, fiabilité, sécurité, maintenabilité, portabilité.
Les attributs de qualité des logiciels sont perdus dans les traductions d’organisations cloisonnées.
Antoine Craske
Revenons à notre problème: comment garantir que ces exigences soient identifiées?
Cela peut être un processus douloureux si l’architecte de domaine doit travailler sur certains d’entre eux, laissant le reste aux autres rôles.
Il n’est pas rare de voir une vague affectation des autres exigences entre un architecte technique, un ingénieur devops, un responsable d’automatisation et d’ingénierie qa, qui se synchronisent rarement entre eux.
Sans une organisation claire, les différentes exigences finissent par se perdre dans les différents silos.
Une perspective transversale est nécessaire pour construire un système performant
C’est là que je pense qu’un responsable de l’architecture qualité peut faire la différence.
Il peut s’agir de responsabilités et de fonctions affectées à un rôle existant au sein de l’organisation, un responsable QA ou un responsable technique par exemple.
La perspective du système affecte son développement global.
La perspective du système qualité logiciel influe sur son développement global.
Antoine Craske
Les fourmis sont un exemple très profond de la dynamique du système. Elles travaillent de manière synchronisée pour optimiser le système dans lequel elles sont impliquées.
Le jour où leur nid commencera à se développer avec un autre, quelque soit leur affectation initiale, leur coordination s’étendra à l’optimisation globale du système.
Nous devons apprendre de ces autres systèmes performants.
Les organisations sont des systèmes optimisés en fonction de leur perspective
Revenant au monde des affaires, c’est ce qui a tendance à se produire dans les organisations.
Un CEO local dans une organisation décentralisée optimisera ses résultats locaux, en fonction de ses objectifs et de ses incentives.
Les cas positifs peuvent entraîner des avantages à la fois pour l’organisation locale et globale, mais cela n’est pas garanti.
Si le CEO local doit améliorer son flux de trésorerie, il pourrait simplement précommander plus d’articles dans l’entrepôt central, ce qui se traduirait par un flux de trésorerie globalement médiocre pour l’entreprise avec un stock excédentaire.
Le jour où cette filiale sera intégrée dans un groupe plus large, ou évoluera vers une gestion centralisée, sa perspective d’optimisation sera bien différente.
La clé est qu’un système peut être amélioré en tenant compte de son périmètre global, de ses interfaces, de ses objectifs, de ses acteurs et de sa dynamique.
Les optimisations locales sont dangereuses dans leur évaluation de la qualité locale
Nous connaissons tous les pièges et les anti-patterns d’optimisations locales qui s’appliquent dans l’industrie du logiciel.
La pré-optimisation locale est l’une des principales raisons du gaspillage de la qualité des logiciels.
Antoine Craske
Une équipe QA peut, de son point de vue, investir dans une campagne de tests automatisés avec une couverture élevée de 80%, montrant les résultats aux autres équipes.
En attendant, les développeurs veilleront à ce que leurs tests unitaires couvrent tous les cas d’utilisation, ajoutant des tests d’intégration pour sécuriser leur développement.
En fin de compte, les deux équipes ont probablement chevauché le travail en termes de couverture et de test, ce qui entraîne des retards, des coûts de mise en œuvre et de maintenance plus élevés.
L’équipe aurait pu gagner 50% de son temps en ayant une approche commune.
L’architecte de la qualité doit être le gardien de la qualité globale du système
Les architectes de la qualité logicielle doivent agir comme des architectes dans leurs racines, en se concentrant sur une perspective transversale de la qualité.
Assurer l’adéquation du produit aux objectifs de l’organisation et aux besoins des clients est la première étape.
Sa tâche suivante est de garantir les différents attributs des exigences, fonctionnelles et non fonctionnelles.
L’architecte de la qualité du logiciel doit s’approprier la perspective transversale de la qualité.
Antoine Craske
Son travail n’est pas nécessairement d’être responsable de chacun des domaines, mais de s’assurer de leur exhaustivité, d’être globalement responsable.
Concevoir le système de bout en bout pour une qualité logicielle structurelle est sa prochaine tâche.
C’est lui qui devrait avoir une perspective globale dans l’ensemble de tous les intérêts locaux, en tenant compte des contraintes globales du système.
L’architecte de qualité doit être un «doer» impliqué dans l’équipe
Comme tout architecte, il doit rester loin des tours d’ivoire, en étant participatif et collaboratif.
Passer des exigences aux opérations du logiciel nécessite une réelle implication de l’équipe vers l’architecture définie.
C’est pourquoi les architectes de la qualité doivent interagir avec le reste de l’équipe pour transformer l’architecture en une réalité.
Il peut par exemple aider à structurer la matrice de test, la stratégie de test et la plate-forme d’automatisation de test qui doivent être utilisées tout au long de la mise en œuvre.
En étant complémentaire et transversal, il peut travailler avec les équipes ingénierie, qa et plateforme pour définir une architecture CI/CD structurellement performante.
Une vue combinée conduit plus facilement à des pratiques transversales telles que les quality gates, la supervision, les features-flags.
Avec une vision transversale, on pense plus globalement au résultat final du processus et à son impact.
L’architecte qualité doit être présent en permanence
Le logiciel est un produit vivant, évoluant au fil du temps.
Un acteur impliqué temporairement dans un système aura tendance à optimiser ses objectifs sur sa durée de participation, souvent à court terme.
Comme dans de nombreux sujets, il est essentiel de parvenir à un équilibre.
Prenons l’exemple d’un président, dans certains pays, ils sont là pour environ 4 à 5 ans et peuvent être réélus jusqu’à deux fois.
Ce n’est pas parfait, mais pousse les acteurs à produire des résultats à différents horizons, pour être valorisés aujourd’hui, réélus demain et assurer leur avenir par la suite.
Les logiciels ont une durée de vie qui même si raccourcie, restent néanmoins sur des cycles comparables.
C’est pourquoi certains acteurs clés doivent être présents en permanence dans le développement du système logiciel.
L’architecte qualité doit obtenir la boucle de rétroaction produit
C’est le cas de l’architecte de la qualité logicielle.
La nécessité de fermer la boucle de rétroaction jusqu’à l’expérience client est indispensable.
Le produit répond-il à ses exigences fonctionnelles et non fonctionnelles originellement émises?
Comment les différents attributs du logiciel ont-ils été traduits et sont-ils satisfaisants?
Que faut-il changer pour améliorer la qualité du produit logiciel tout en réduisant sa dette architecturale dans le temps?
Obtenir la boucle de rétroaction est ce qui permettra une performance et une adaptation structurantes.
Nous, humains, ne sommes pas conçus pour intégrer des boucles de rétroaction retardées (voir toute la littérature sur la perte de poids).
Clarifiez qui est l’architecte de la qualité logicielle dans votre organisation
Les responsabilités de l’architecture de la qualité doivent être clairement attribuées, comme pour le CEO, le CFO et le COO.
Nous retrouvons des points communs avec l’architecture traditionnelle, mais la connexion entre les différents points vues par une perspective holistique de la qualité fera la différence.
Avec l’évolution de la complexité et de la distribution des équipes et produits, je ne serai pas surpris de voir apparaître des architectes de qualité logicielle.
Où est votre architecte de la qualité logicielle?
Antoine Craske
Un réel besoin de clarté de la responsabilité existe au sein de l’organisation: architecte de domaine, responsable QA, responsable qualité, développeur principal?
Le choix vous appartient, il doit être clair et pour une qualité logicielle holistique.
Que pensez-vous du fait que les architectes de qualité deviennent une fonction à part entière?