Trade-off analysis¶

Rendre les compromis explicites pour que les décisions soient collectives, pas individuelles.

Pourquoi les compromis sont inevitables¶

Aucune option architecturale n'est objectivement supérieure. Chaque choix est un ensemble de compromis. La matrice de décision rend ces compromis explicites et structure la conversation d'équipe — sans elle, le choix revient souvent à l'option que la personne la plus influente dans la salle connait le mieux.

L'architecture est l'art de maximiser le nombre de décisions non prises (Robert C. Martin) — mais les décisions qui restent sont des compromis. Performance contre coût. Simplicité contre flexibilite. Vitesse de livraison contre robustesse. Chaque choix sacrifie quelque chose — le trade-off analysis rend ce sacrifice explicite.

Architecture Significant Requirements (ASR)¶

Avant d'analyser des trade-offs, il faut identifier les exigences qui pilotent reellement l'architecture. Toutes les exigences ne sont pas architecturalement significatives. Un ASR est une exigence dont la satisfaction nécessité un choix structurel — un choix qui ne peut pas être modifie facilement après coup.

Critères de significance¶

Une exigence est architecturalement significative si :

• Elle impacte la structure du système (decomposition, patterns, technologies)
• Elle contraint les choix technologiques (performance, scalabilité, sécurité)
• Elle est difficile à satisfaire à posteriori (disponibilité, conformité)
• Elle généré des risques importants si elle n'est pas satisfaite

Identifier les ASR¶

graph TD
    REQ[Toutes les exigences] --"filtre"--> F1{Impacte la structure ?}
    F1 --"oui"--> ASR[ASR identifie]
    F1 --"non"--> F2{Contraint les technologies ?}
    F2 --"oui"--> ASR
    F2 --"non"--> F3{Difficile a changer apres ?}
    F3 --"oui"--> ASR
    F3 --"non"--> NASR[Exigence non-ASR]

Exemples d'ASR vs exigences ordinaires¶

Quality Attribute Workshop (QAW)¶

Le QAW est une méthode structurée pour identifier et prioriser les attributs qualité (quality attributes) qui pilotent l'architecture. Développé par le Software Engineering Institute (SEI), il précédé le travail de conception.

Déroulement du QAW¶

Format d'un scenario qualité¶

Chaque scenario suit une structure en six parties :

Exemple de scenario priorise¶

Scenario S-003 (priorité haute) : pendant les soldes d'hiver (environnement), les utilisateurs (source) passent 500 commandes par minute (stimulus) sur le service de commande (artefact). Le système traite toutes les commandes (réponse) avec une latence p99 < 300ms et zero perte de données (mesure).

Ce scenario est un ASR : il pilote le choix entre stateless et stateful, impose du caching et du load balancing, et orienté le choix de la base de données vers un moteur capable de gérer cette charge.

Méthode de trade-off analysis¶

Étapes¶

1. Lister les critères pertinents pour le contexte du projet
2. Attribuer un poids à chaque critère — la somme doit egaliser a 1.0 (ou 100%)
3. Noter chaque option sur chaque critère de 1 (très mauvais) a 5 (excellent)
4. Calculer le score pondere pour chaque option
5. Discuter les ecarts — la matrice ne décidé pas, elle révélé les hypothèses implicites

La valeur n'est pas dans le score final. Elle est dans le debat sur les poids : si deux personnes proposent des poids très différents pour un même critère, c'est que leurs priorités divergent — et c'est ce desaccord qu'il faut résoudre avant d'aller plus loin.

Choisir les bons critères¶

Les critères doivent refléter les priorités réelles du projet, pas des critères génériques. Exemples par contexte :

• Startup early-stage : time-to-market, simplicité, facilite de recrutement
• Scale-up : scalabilité, observabilité, isolation des défaillances
• Entreprise : conformité, intégration systèmes existants, support vendor
• Équipe petite : charge opérationnelle, maturité de la technologie, documentation disponible

Exemple 1 : choix du style d'architecture (startup)¶

Contexte : API backend pour une startup en phase de croissance, équipe de 5 développeurs full-stack, budget ops limite a 800 EUR/mois, time-to-market critique pour la prochaine levee de fonds.

Calcul des scores ponderes :

• Monolithe : (5x0.25) + (2x0.15) + (4x0.20) + (5x0.25) + (4x0.15) = 1.25 + 0.30 + 0.80 + 1.25 + 0.60 = 4.20
• Microservices : (2x0.25) + (5x0.15) + (2x0.20) + (2x0.25) + (3x0.15) = 0.50 + 0.75 + 0.40 + 0.50 + 0.45 = 2.60
• Serverless : (3x0.25) + (4x0.15) + (4x0.20) + (3x0.25) + (3x0.15) = 0.75 + 0.60 + 0.80 + 0.75 + 0.45 = 3.35

Exemple 2 : choix du style d'architecture (scale-up)¶

Contexte : plateforme SaaS B2B avec 200 clients, équipe de 25 développeurs en 4 squads, croissance de 30% par trimestre, SLA de 99.95% contractuel.

Les mêmes options, des poids différents, un résultat inverse. Le contexte a change — la décision aussi. C'est exactement le mécanisme attendu.

Exemple 3 : choix du style d'architecture (enterprise)¶

Contexte : grande entreprise du secteur bancaire, 500 développeurs, conformité PCI-DSS et reglementations bancaires, SI existant de 200 applications, intégration avec des mainframes.

Dans un contexte enterprise, la conformité et l'intégration avec l'existant dominent les critères. Le SOA classique, souvent moque dans les conferences tech, reste le choix rationnel quand ces facteurs pesent plus que la scalabilité.

Sensitivity points et trade-off points¶

Ces concepts, issus du framework ATAM (Architecture Tradeoff Analysis Method) du SEI, aident à identifier les zones critiques d'une architecture.

Sensitivity points¶

Un sensitivity point est un élément de l'architecture ou un petit changement dans un parametre produit un grand changement dans un attribut qualité.

Trade-off points¶

Un trade-off point est un élément ou la satisfaction d'un attribut qualité dégradé un autre attribut qualité. C'est le cœur du compromis architectural.

graph TD
    ARCH[Decision architecturale] --"ameliore"--> QA1[Attribut qualite A]
    ARCH --"degrade"--> QA2[Attribut qualite B]
    QA1 --"mesure par"--> M1[Metrique A]
    QA2 --"mesure par"--> M2[Metrique B]
    M1 --"arbitre par"--> TP[Trade-off point]
    M2 --"arbitre par"--> TP

Le debat sur les poids¶

La matrice ne décidé pas — elle structure la conversation et rend les trade-offs explicites. Si l'équipe estime que la scalabilité indépendante est plus critique que le time-to-market parce que la croissance est prévue très rapide, les poids changent et le résultat aussi. C'est précisément l'objectif : forcer l'explicitation des priorités avant de choisir, pas après.

Un bon signe : si tout le monde est d'accord sur les poids avant de noter les options, la décision sera acceptee collectivement même par ceux qui preferaient une autre option. Le debat sur les notes ("est-ce que les microservices meritent vraiment 2 sur la scalabilité ?") est secondaire par rapport au debat sur les poids ("est-ce que le time-to-market vaut vraiment 25% pour notre contexte ?").

Pieges a éviter¶

• Trop de critères : au-delà de 7 critères, les poids deviennent insignifiants. Garder 4 a 6 critères discriminants.
• Poids uniformes : si tous les poids sont a 20%, la matrice ne discrimine rien. Au moins un critère doit peser significativement plus.
• Notes complaisantes : noter 3/5 partout evite les desaccords mais rend la matrice inutile. Forcer les ecarts.
• Ignorer le debat : le score est un support de discussion, pas un verdict. Si le résultat semble faux, le problème est dans les poids, pas dans le calcul.

Documenter le trade-off¶

Chaque trade-off analysis significative merite un ADR. L'ADR capture non seulement la décision finale mais aussi la matrice, les poids et le raisonnement.

Structure recommandee¶

# ADR-NNN : Choix du style d'architecture

**Statut :** accepted
**Date :** YYYY-MM-DD

## Contexte
Description du contexte et des contraintes.

## ASR identifies
- ASR-1 : description
- ASR-2 : description

## Matrice de trade-off
[La matrice complete avec poids et scores]

## Sensitivity points identifies
- SP-1 : description et impact
- SP-2 : description et impact

## Decision
Option choisie et justification basee sur les poids.

## Consequences
Positif et negatif, avec reference aux trade-off points.

ATAM en aperçu¶

L'Architecture Tradeoff Analysis Method (ATAM) est la méthode formelle du SEI pour évaluer les trade-offs d'une architecture. Elle est plus lourde que la simple matrice de décision mais plus rigoureuse.

L'ATAM se déroulé en neuf étapes :

1. Présentation de l'ATAM
2. Présentation des drivers métier
3. Présentation de l'architecture
4. Identification des approches architecturales
5. Génération de l'arbre de qualité (utility tree)
6. Analyse des approches architecturales
7. Brainstorming et priorisation des scenarios
8. Analyse des scenarios priorises
9. Présentation des résultats

Chapitre suivant : Modeliser — du métier au modèle, par intention.