Architecture agile

À première vue, on pourrait croire à un oxymore, car l’architecture est culturellement une des étapes du Waterfall, et l’agilité est contre une conception totale et complète en amont du développement (c’est l’antipattern "Big Design Up Front") ; en revanche, elle n’interdit pas la conception, bien au contraire [Martin 2015b] !

Dans une approche Shuhari, on va examiner ce que propose "TOGAF", un standard reconnu dans le domaine de l’architecture [TOGAF 2018].

Modèle "Shu-ha-ri" - images/i06.png

Shuhari est un concept issu des arts martiaux japonais qui décrit les trois étapes de l’apprentissage :

Shu ( - "protéger", "obéir") : c’est la sagesse traditionnelle, qui consiste à apprendre les fondamentaux.
Ha ( - "se détacher", "digresser") : cette étape correspond à casser avec la tradition pour trouver les exceptions à la sagesse traditionnelle et trouver de nouvelles approches.
Ri ( - "quitter", "se séparer") : à partir de ce point, il s’agit de transcender les choses, car finalement il n’y a pas de technique ou de sagesse traditionnelle, tous les mouvements sont permis.

Depuis les années 1990, un framework générique de génération d’architecture pour l’entreprise nommé TOGAF (applicable au waterfall et à l’agile) a mis au point des éléments de méthode de développement de l’architecture. Ces éléments adressent les quatre domaines du métier, des données, des applications et de la technique.

Les méthodes de création d’architecture sont contraintes par [Mandebvu 2014] :

la capacité du business,
les méthodes de gestion de portfolios, de programmes et de projets,
les méthodes de développement pour obtenir des solutions,
les méthodes de gestion des opérations qui exploitent la solution.

Figure III-1 : l’architecture vue par le TOGAF [Mandebvu 2014]

La réponse de SAFe à ces contraintes sur le plan de l’architecture est un ensemble de valeurs et pratiques pour permettre l’évolution de la conception d’un système.

Craig...

Domain-Driven Design - DDD

Le risque avec les ASR tout comme avec un métier et plus généralement un domaine que vous découvrez est de voir émerger de nouvelles exigences avec le temps ou avec l’accroissement de votre perspicacité à force d’expérience sur ce métier, et de devoir remodeler jusqu’aux fondations de votre édifice.

Le réusinage est intrinsèque aux méthodes itératives telles que l’agile et, tandis qu’au niveau du code, des techniques de réusinage sont définies pour parfaitement répondre à des motifs de code [Fowler 1999], lorsqu’il s’agit d’un domaine, les motifs sont difficilement identifiables ; la conception doit donc être suffisamment flexible pour faciliter le réusinage, car la structure du code existant peut opposer une résistance à un remodelage [Evans 2003], en particulier si les différents domaines ne sont pas orthogonaux, c’est-à-dire indépendants les uns des autres. Dans le cas contraire, on va passer du temps à détricoter le code pour séparer les parties utiles et réutilisables, et malheureusement, lorsqu’on aborde un domaine dont on n’a pas l’expérience, il n’est pas rare de faire face à une découverte majeure, souhaitée, mais qui va potentiellement impliquer toute une série de remodelages.

Dans un contexte TOGAF, il est tout à fait concevable d’introduire la pratique du "DDD" (Domain-Driven Design - conception pilotée par le domaine) afin de conserver une architecture à la fois stable et flexible [Clément 2017].

Architecture et conception

Pour certains, une subtilité existe entre les notions d’architecture et de conception (en anglais, le terme de "design" est utilisé) :

Du côté de l’étymologie

Pour les grecs, l’architecture est la fusion de deux mots "ἀρχός" (árkhô) - commander - et "τέκτων" (tektōn), l’artisan charpentier. L’architecture désigne la notion de commander aux ouvriers ; et l’architecte, celui qui les commande [Picoche 1994] [Harmonie 2008].
Tandis que le mot conception...

Model-Based System Engineering - MBSE

1. Présentation du MBSE

Lorsque la solution implique différents corps de métiers comme :

l’électronique,
la mécanique, avec des parties en matières plastiques ou métalliques,
d’autres pans de connaissances tels que l’aéronautique, la médecine, la télévision numérique, le bâtiment et autres sciences.

La capture des besoins, des contraintes métier et techniques et d’exploitation entraîne un mélange des complexités. L’approche MBSE adresse depuis 2007 via la communauté INCOSE (https://www.incose.org/) [Schindel 2020b]. [Fosse 2016] définit le MBSE comme l’approche formalisée par la modélisation de toutes ces étapes. Le MBSE est donc une approche d’ingénierie des systèmes, basée sur la modélisation des domaines comme moyen d’échange entre les ingénieurs plutôt que des documents.

Cette approche implique des modèles qui représentent les conceptions techniques tant sur le plan structurel que comportemental, matériel et des moyens de simulations. Ces modèles évoluent tout au long du cycle de vie et soutiennent :

les études des métiers,
les vérifications et validation de la conception.

Elle permet :

des représentations plus parlantes et partagées pour réduire les silos,
un outillage qui facilite l’exploitation des modèles et l’obtention de la continuité dans les artefacts,
de plus grandes réutilisabilité et cohérence.

Dans ce contexte, Fosse identifie les enjeux du MBSE.

La complexité des objectifs du MBSE croissent plus vite que la capacité à les gérer.
La conception du système émerge des parties plus que de l’architecture. Il en résulte un système fragile, difficile à tester, qui est complexe et onéreux à opérer.
La connaissance et les investissements se dissipent lors de la transition entre les phases du cycle de vie du projet, ce qui accentue les coûts de développement et les risques de découverte tardive des problèmes de conception.
Les parties logicielles et techniques sont faiblement couplées, ce qui gêne la prise...

DevOps

1. Visions sur DevOps

Ici, l’état d’esprit (voire la culture) DevOps est d’abolir le mur qui existe entre les équipes de réalisation et d’opération, comme l’ultime silo qui ralentit la mise à disposition des services attendus par un client.

Pour y parvenir, on retrouve différents aspects généralement présents comme [Leffingwell 2018] :

augmenter les fréquences de livraison et améliorer la qualité,
augmenter les tentatives d’innovation et les moyens pour sécuriser ces tentatives,
réduire l’impact, la fréquence et les temps de retour à la normale.

a. Vision de Kim

Une autre vision de DevOps est proposée par [Kim 2016] et repose sur trois "voies" :

Principes liés aux flux

Limiter la quantité de travail en cours (voir la notion de « WIP » à la section Pantesting appliqué au cycle de développement - Synchronisation des développements).
Réduire la taille des lots.
Réduire le nombre de changements de mains (afin de limiter les délais d’attente).
Continuellement identifier et élever les contraintes (c’est la TdC).
Éliminer les difficultés et les gaspillages dans la production de valeur.

Principes liés aux feedbacks

Travailler en toute sécurité dans un système complexe.
Voir les problèmes au moment où ils apparaissent.
Se ruer sur les problèmes afin de bâtir de la connaissance supplémentaire.
Toujours pousser la qualité au plus près du besoin.
Permettre une optimisation continue des moyens à destination des utilisateurs.

Principes liés à l’apprentissage et l’expérimentation continus

Permettre l’apprentissage organisationnel et une culture de sûreté.
Institutionnaliser l’amélioration du travail quotidien.
Transformer les découvertes locales en améliorations globales.
Injecter des pratiques de résilience dans les tâches quotidiennes.
Renforcer, via les leaders, la culture d’apprentissage.

b. Vision de SAFe

SAFe propose une vision de DevOps basée sur l’abréviation CALMR :

Culture : partager notamment

des valeurs (de SAFe, de l’agilité, de l’architecture...

Du code propre avec le Software Craftsmanship

Pour paraphraser [Leffingwell 2018], un code de mauvaise qualité ne peut pas être mis à l’échelle (l’auteur parle en fait littéralement de code "merdique").

La cinquième valeur de l’agile

En 2008, un des cosignataires du manifeste agile, Robert C. Martin, surnommé "Uncle Bob", a proposé, lors de sa keynote de la conférence Agile 2008 de Toronto, une cinquième valeur pour l’agile [Bria 2008] :

"Craftsmanship over crap"

(L’ouvrage d’artisanat plus que la merde).

Dans son discours, Uncle Bob raconte comment la médecine a pu faire d’incroyables progrès, simplement en se lavant les mains [Boutin 2008].

Cette conférence a donné naissance au mouvement du Software Craftsmanship...

Architecture Decision Record - une pratique autour de la prise de décision architecturale

Un adage dit que les problèmes d’aujourd’hui viennent des solutions d’hier. Malheureusement, avec le temps, l’organisation prend des décisions qui visent à s’améliorer. Lorsque les décisions impliquent des choix structurants tels que des choix techniques (technologie, architecture), mais aussi organisationnels, il en résulte des vérifications, voire des contraintes qui s’empilent et rendent complexes les décisions suivantes.

Cette prise de conscience doit s’accompagner de la capacité à identifier les décisions déjà prises et éventuellement, les remettre en question.

Pour faciliter cette approche, il existe le simple concept d’« Architecture Decision Record » (trace de décision architecturale), qui consiste à garder pour chaque décision la trace des informations suivantes [Deshpande 2018] [Revial 2018] [Revial 2019].

Titre
Date
Décideurs
Contexte
Décision
Statut - Proposé, Accepté, Rejeté, Remplacé
Conséquences

Ces ADR doivent être accessibles facilement pour les challenger. Elles doivent aussi être au plus près du code ou de l’environnement de codage pour faciliter l’enregistrement de décision, en particulier lorsque...

Résumé

La technique pour la technique ne doit pas être une finalité en soit. Qu’elle soit mise en place pour structurer la solution ou pour accélérer sa mise en production, il est indispensable d’appuyer son évolution sur la création de connexions avec l’écocycle dans lequel la solution doit s’ancrer.

Pour faciliter ces connexions, des séances de Model Storming vu plus haut raccourcissent les cycles et évitent que les ingénieurs se forgent un modèle qui, bien que cohérent, se trouve de plus en plus déconnecté de la réalité des besoins, du terrain ou des découvertes et innovations en provenance d’autres écocycles.

Afin de faciliter la communication et l’efficacité du système dans sa globalité, SAFe propose de travailler de façon synchronisée et cadencée (principe #7) [Leffingwell 2018]. Voici quelques possibilités.

Au moment du PI Planning ou en début de sprint, des ébauches de modélisation induites par les premières versions des US émergent, et peuvent alors être partagées par des sessions de Model Storming, qui facilitent déjà la conception de moyens de tests à mettre en œuvre
Au moment où le développement d’une US est démarré, les détails...

Pantesting appliqué à la testabilité technique