TOGAF ADM¶

Un cadre d'architecture d'entreprise pour structurer la transformation — quand la taille de l'organisation l'exige.

Pourquoi TOGAF existe¶

TOGAF (The Open Group Architecture Framework) est le cadre d'architecture d'entreprise le plus repandu dans les grandes organisations. Il fournit une méthode structurée — l'ADM (Architecture Development Method) — pour concevoir, planifier et gouverner l'évolution du système d'information.

TOGAF répond a un problème réel : dans une organisation de 500 personnes avec 200 applications, comment s'assurer que les décisions d'architecture prises par différentes équipes convergent vers un SI cohérent ? Sans cadre, chaque équipe optimise localement — et le SI global devient un patchwork inconciliable.

Le revers de la medaille : TOGAF est lourd. Pour une startup de 10 personnes ou un projet isole, appliquer TOGAF integralement est du sur-engineering. L'objectif de ce chapitre n'est pas de prescrire TOGAF, mais de comprendre ses concepts pour en extraire ce qui est utile selon le contexte.

Le cycle ADM¶

L'ADM est le cœur de TOGAF. C'est un processus iteratif en phases qui guide la transformation d'un état actuel (baseline) vers un état cible (target).

graph TD
    PRE[Phase Preliminaire] --"principes, gouvernance"--> A
    A[Phase A - Vision] --"vision validee"--> B
    B[Phase B - Architecture metier] --"processus cibles"--> C
    C[Phase C - Architecture SI] --"applications et donnees cibles"--> D
    D[Phase D - Architecture technique] --"infrastructure cible"--> E
    E[Phase E - Opportunites et solutions] --"feuille de route"--> F
    F[Phase F - Planning de migration] --"plan de transition"--> G
    G[Phase G - Gouvernance] --"suivi de conformite"--> H
    H[Phase H - Gestion du changement] --"evolutions"--> A
    RM[Requirements Management] --"alimente toutes les phases"--> A
    RM --"alimente toutes les phases"--> B
    RM --"alimente toutes les phases"--> C
    RM --"alimente toutes les phases"--> D

Phases et livrables clés¶

Architecture Repository¶

Le Repository d'architecture est le dépôt centralise qui stocke tous les artefacts produits par l'ADM. Il fournit la mémoire institutionnelle de l'architecture — sans lui, chaque nouveau cycle repart de zero.

Dans la pratique, le Repository prend des formes variees : un wiki Confluence, une base Notion, un outil specialise comme LeanIX ou Ardoq, ou simplement un ensemble de fichiers Markdown dans un dépôt Git. L'important n'est pas l'outil mais l'existence d'une source de vérité unique pour l'architecture.

Building Blocks¶

TOGAF distingue deux niveaux de Building Blocks qui permettent de passer progressivement de l'abstrait au concret.

ABB — Architecture Building Blocks¶

Les ABB sont des composants abstraits qui décrivent une capacité sans prescrire l'implémentation. Ils répondent a "de quoi a-t-on besoin ?"

Exemples d'ABB :

• Service d'authentification
• Bus de messages
• Stockage de données relationnelles
• Moteur de règles métier
• Service de notification

SBB — Solution Building Blocks¶

Les SBB sont les implémentations concrètes des ABB. Ils répondent a "comment le réalisé-t-on ?"

graph TD
    ABB[Architecture Building Block] --"specifie"--> REQ[Exigences]
    ABB --"realise par"--> SBB[Solution Building Block]
    SBB --"implemente par"--> PROD[Produit / Service concret]
    SBB --"deploye sur"--> INFRA[Infrastructure]

La distinction ABB/SBB est utile même en dehors de TOGAF. Elle force a séparer le besoin (ABB) de la solution (SBB). Quand on écrit dans un ADR "on a besoin d'un bus de messages" (ABB) puis "on choisit Kafka" (SBB), le raisonnement est plus clair que "on a besoin de Kafka" — qui melange besoin et solution.

Architecture Continuum¶

L'Architecture Continuum organisé les assets architecturaux du plus générique au plus spécifique. Il est compose de quatre niveaux :

graph LR
    F[Foundation] --"specialise en"--> CS[Common Systems]
    CS --"specialise en"--> IND[Industry]
    IND --"specialise en"--> ORG[Organization]

L'intérêt du Continuum : éviter de reinventer la roue. Avant de concevoir un composant, vérifier s'il existe déjà à un niveau plus générique. Un service d'authentification est un problème résolu au niveau Common Systems — pas besoin de le reconcevoir from scratch au niveau Organization.

Quand utiliser TOGAF¶

TOGAF apporte de la valeur quand la complexité organisationnelle justifie la structure qu'il impose. Il est contre-productif quand l'overhead dépassé le benefice.

TOGAF est pertinent quand¶

• L'organisation compte plus de 100 développeurs répartis en équipes autonomes
• Le SI comprend plus de 50 applications avec des integrations croisees
• Plusieurs programmes de transformation sont en cours simultanément
• La conformité reglementaire exige une traçabilité formelle des décisions
• L'architecture doit survivre au turnover — les décisions doivent être institutionnelles, pas personnelles

TOGAF est excessif quand¶

• L'équipe compte moins de 20 personnes
• Le projet est un produit isole sans dépendances majeures avec le SI existant
• Le time-to-market est la priorité absolue
• L'organisation n'a pas de rôle d'architecte enterprise dédié

Alternatives et complements¶

TOGAF et les autres frameworks¶

TOGAF ne couvre pas tout. Il se combine avec d'autres frameworks selon les besoins :

TOGAF fournit le processus. ArchiMate fournit la notation. C4 fournit la simplicité visuelle. ITIL fournit les processus opérationnels. Chaque framework répond a une question différente — aucun ne répond a toutes.

Gap analysis¶

La gap analysis est la technique centrale de TOGAF pour planifier la transformation. Elle compare l'état actuel (baseline) et l'état cible (target) pour identifier ce qui doit être créé, modifie, supprimé ou conserve.

Matrice gap analysis¶

graph LR
    BL[Baseline Architecture] --"gap analysis"--> GAP[Gaps identifies]
    GAP --"priorise en"--> PROJ[Projets de transformation]
    PROJ --"realise"--> TGT[Target Architecture]
    TGT --"devient la nouvelle"--> BL2[Baseline pour le cycle suivant]

Prioriser les gaps¶

Tous les gaps ne se traitent pas en même temps. La priorisation tient compte de :

• Risque : les gaps qui exposent a un risque reglementaire ou sécurité passent en premier
• Dépendances : certains gaps sont des prérequis pour d'autres (pas de microservices sans CI/CD solide)
• Valeur métier : les gaps qui debloquent des capacités métier sont prioritaires sur les améliorations techniques pures
• Effort : les quick wins (effort faible, valeur haute) se traitent en parallèle des projets structurants

Adapter TOGAF a son contexte¶

L'erreur la plus courante avec TOGAF est de l'appliquer tel quel, sans adaptation. Le standard lui-même recommande de le "tailor" — c'est-a-dire de l'adapter au contexte de l'organisation.

Adaptation pour une équipe de 20-50 personnes¶

Adaptation pour une startup¶

L'objectif n'est pas de "faire du TOGAF" mais d'emprunter les concepts utiles. La distinction baseline/target, la gap analysis et le Requirements Management continu apportent de la valeur a n'importe quelle échelle.

Certification et ressources¶

TOGAF est un standard de l'Open Group. La certification se fait en deux niveaux :

• TOGAF Foundation (Level 1) : comprendre les concepts et la terminologie
• TOGAF Certified (Level 2) : appliquer TOGAF dans un contexte réel

La certification est utile pour les architectes enterprise qui travaillent dans des organisations qui l'exigent. Pour les autres, la comprehension des concepts (ADM, Building Blocks, Continuum) apporte une grille d'analyse sans necessiter la certification formelle.

Le standard est disponible sur le site de l'Open Group. La version courante est TOGAF 10, publiee sous forme de TOGAF Standard. Elle modularise le contenu pour faciliter l'adoption partielle — cohérent avec l'approche "emprunter sans adopter" recommandee ici.

Chapitre suivant : Documenter les decisions (ADR) — capturer le contexte de chaque choix pour que les décisions survivent au turnover.