TOGAF 9.2
Généralités
4 sections de la lib togaf:
Docs de fondation
Guides et techniques génériques
Guides et techniques p/r industrie
Guides et techniques p/r organisation
Catégorie de documents:
Standard TOGAF 9.2
Collection de guides (guide series)
Guides: best practices, reco
White Papers: discussions, échanges, ReX…
Orga TOGAF:
Partie 6: Cadre de capacité d'architecture
Partie 2: ADM
Partie 3: Reco et techniques pour ADM
Partie 4: Cadre de contenu
Partie 5: Enterprise Continuum et outils
Introduction
Définition: fournit un cadre stratégique pour l'evo du SI en réponse aux besoins de flexibilité constante des métiers
2 groupes d'intervenants dans l'EA:
Les Acteurs concernés = parties prenantes
Les architectes
L'EA est la seule structure organisationnelle s'assurant que les préoccupations et exigences des acteurs concernés seront toutes adressées
= n'est pas une activité d'une DSI ou BU mais plutôt rattaché à une direction générale
TOGAF est un cadre d'architecture qui permet la création d'architectures spécifiques à des organisations en fonction des besoins et contraintes de celles-ci.
Une méthode pour construire:
Des Composants (Building Blocks)
Comment les composants s'assemblent
Un ensemble d'outils
Un vocabulaire commun
Une liste de standards et produits à utiliser
Def Entreprise: une organisation (ou un ensemble d'orga au même but) avec ses missions et fonctions
Def Architecture:
Description formalisée d'un système, description détaillée permettant de guider sa transfo
Structure des composants, relations, principes de conception et evolution dans le temps
Etapes d'architecture = transitions, organisées par feuilles de routes
Recommandation de la numérotation :
0.1: draft
1.0: version validée par les parties prenantes
ADM:
Généralités:
8 phases, A-H, execution en cycle
Permet de piloter les changements nécéssaires pour apporter de nouvelles capacités
Le processus doit impérativement s'exécuter comme spécifié
Les phases sont décrit par le même schéma:
Objectifs
Entrées
Etapes
Sorties (= livrables)
Approches
Souvent la premiere execution ADM est difficile car le référentiel d'archi est à construire
Phase préliminaire :
Objectifs:
Prépare l'entreprise a réussion son projet d'EA
Détaille la demande de mise en chantier de l'architecture (QQOQC) - clarifie le besoin
Souvent en one-one avec le sponsor
Identifie les impacts sur l'orga / scope / composants
Identifie les besoins pour réaliser l'archi - outils et skill de l'équipe d'architecture
Méthodo, référentiels, guides
outils
Adapte le référentiel
Définis les principes d'architecture
Permet de renseigner un premier niveau d'exigences = les objectifs
Trigger:
Demande de mise en chantier de l'archi
Retour arrière depuis la phase A car la demande ne peut pas être adressée
Changements métiers ayant un impact sur la capa d'archi, identifié en phase H
Créé un nouveau cycle ADM
Entrée:
Modèle d'orga en architecture d'entreprise, si existant
Méthodo développement de l'ADM
Cadre de contenu d'archi
Outils
Principes d'archi existants
Continuum d'entreprise yc referentiel d'archi
Stratégie, objectifs, moteurs de changements des métiers
Données budgétaires
Etapes:
Clarifier l'impact: identifier les orga fortement impactés, yc les org externes
Confirmer les cadres de gov et support
Produit le cadre de gov du projet d'archi
Définir et établir l'equipe projet d'archi
Evaluer la maturité de l'equipe d'archi
Définir le scope du projet d'archi
Déterminer les contraintes
Evaluer les exigences budgétaires
Allouer roles et responsabilités
Définir et établir les principes d'archi
Adapter les référentiels méthodo
TOGAF doit être adapté au contexte de l'entreprise (maturité, ambition…)
L'EA doit s'intégrer dans les référentiels et processus existants (ITIL, SCRUM, Budget…)
Implémenter les outils
Sortie:
Demande de mise en chantier d'architecture
Synthèse stratégie métier, but, objectifs, moteurs changement et principes à appliquer
Organisation de l'équipe d'EA
Adaptation des méthodes de dev d'archi (ADM)
Init de ref d'archi
Cadre de gov du projet
Quelques Approches:
Partitionnement de l'archi:
De multiple projet d'archi pour être at scale
Fédération de ces projets pour avoir une archi globale
TOGAF propose 3 niveaux: stratégique (= vision long terme), segment (= une BU), capacité (= un projet)
Approche itérative:
Plusieurs cycles ADM en //
Ou bien plusieurs cycles A->F gouvernés par les mêmes phases G-H
S'applique bien avec une approche de partitionnement d'archi
Principe d'architecture:
Règles généralistes appliquées à l'entreprise et que l'archi doit respecter
Ex: Respecter les règlementations (FRTB, GDPR…)
Listé dans un référentiel:
Nom: nom du principe
Déclaration: description du principe
Justification: en quoi le principe est important, le bénéfice du principe, la priorité
Implications: impact du principe sur l'entreprise et son SI (ressources, cout, tâches)
Permet de cadrer le travail de l'architecte et justifier des choix
2 catégories:
Principes d'entreprise
Principes d'architecture
Doit être robuste et stable
TOGAF propose des principes d'archi par domaine (Business, App, Data, Tech)
A) Architecture Vision :
Objectifs:
=> Initialise un cycle ADM
Développe une vision de haut niveau
Obtenir la validation de la définition du chantier d'archi
Vision high level des nouvelles capa + la valeur ajoutée à la fin du cycle sur les 4 domaines de l'archi
Définit le sous périmètre du projet adressé par le cycle ADM courant
= une partie des objectifs de la phase préliminaire
Delta existant / cible macro => macro impact, permet de déduire la charge
Définit le planning des travaux d'archi pour le projet demandeur
Entrées:
Demande de mise en chantier de l'archi
Principes et objectifs métiers
Cadre d'archi, adapté
Enterprise continuum
Etapes:
Identifier exigences et acteurs:
Identifier les acteurs concernés
Identifier les pdv les plus adaptés pour B, C et D pour démontrer le traitement des exigences
=> Permet de produire la carte des acteurs concernés (inclue la classification des acteurs)
Confirmer objectifs et moteurs du changement:
Identifier objectifs et moteurs
Définir les contraintes
Valider les principes:
Passer en revue les principes d'architecture
Evaluer les capacités du métier
Quelles sont les capacités existantes
Quelles sont les capacités manquantes
Evaluer le niveau de préparation des métiers à la transfo:
Identifier la présence des facteurs clés de succès des projets
Fournis des éléments pour élaborer le plan de migration (F)
Développer la vision de l'architecture:
Sur le périmètre concerné
HLD archi existante et cible
S'aider des scénarios métiers si besoin
=> Permet de créer le premier draf de la définition de l'archi
Etablir le projet d'architecture:
Planifier le cycle ADM
Se coordonner avec les autres projets d'archi si besoin
Approbation de la direction, sponsor et engagement des métiers
Définir la proposition de valeur de l'archi cible:
Evaluer la valeur ajoutée de la cible et des changements
Ajouter ces résultats dans la définition du chantier d'archi
Identifier les risques de transformation métier
Analyse de risque, classifiées, définies et actions à prendre
Inclure les actions à prendre dans la définition d'archi
Sorties:
Vision de l'architecture pour le cycle ADM en cours
Définition du chantier d'archi (= plan projet), approuvé
Détails des principes et objectifs et moteurs de changement
Principes d'archi
Evaluation des capacités
Carte des acteurs concernés
Plan de communication
Quelques approches:
Scénarios métiers: pour découvrir et documenter les exigences afin d'articuler une vision archi
Acteur concerné = rôle clé, préoccupation sur un système (personne, équipe, orga)
Préoccupation = questions des acteurs concernés sur tous les aspects possibles de l'archi
Description de l'archi = artefacts qui documentent une archi, notamment Vue d'archi
Pdv d'archi =
Définit la perspective d'une archi ainsi que technique de modélisation choisis
Détermine ce qu'on voit / ce qu'on doit voir
Vue d'archi =
représentation partielle d'une archi pour répondre à des préoccupations
Est-ce qu'on voit
Est associée à un pdv
3 typologie de vue: existant, trajectoire et cible
Gestion des acteurs concernés:
Inclure très tot dans dans le projet
Communiquer régulièrement avec eux pour informer
Anaylse et découverte des acteurs dans la phase A
Adapter les livrables en conséquence
Classer les acteurs: pouvoir + intérêt et reporter ces infos dans une matrice
Gestion des risques:
2 niveaux de risque: initial et résiduel (= risque avant les actions et après les actions)
Produire une matrice de risque en fonction de l'impact
Principalement en A, E, F et G
Fonctionnement générique des 3 phases B, C et D :
Possèdent les mêmes étapes
= phases de production d'architecture
Etapes:
Selectionner les modèles de ref, PDV et outils
Identifier les datamodel de ref dispo sur étagère (si besoin)
Identifier les exigences à adresser
Identifier catalogue, matrices et diagrammes nécéssaires
Definir processus de modélisation
Identifier les niveaux de granularité requis, limites et contrats
Desc archi existante
Produire les vues identifiés dans l'étape A
Desc archi cible
Gap analysis
Mettre en exergue les composants éliminés ou pas encore définis et également ceux modifiés
Tous les building block sont concernés
Ecart sur les besoins = exigence qui ne serait pas traitée
Définir les composants des archi de transition
Résoudre les impacts dans le paysage d'archi
Vérifier que l'archi cible reflète les intérêts des acteurs concernés
Finaliser l'architecture
Compléter et faire valider le doc de définition de l'architecture
Approche:
Pattern: Façon d'assembler plusieurs building block dans un contexte pour décrire une solution réutilisable à un problème
B) Business Architecture :
Objectifs:
Développe l'archi cible en process & people, produit une liste d'exigences métiers
Identifie les écarts entre les exigences existantes et la cible
Description des processus et organisation pour executer une stratégie et atteindre les objectifs
Orga
Capacité, fonctions, processus
Info métiers
Stratégie et services
Services du SI attendus
TOGAF conseille de décrire les changements désirés:
Moteur / justification
Buts = orientations stratégiques
Objectifs = quels résultats / livrables opérationnels, mesurables et planifiés
Exigences = que doit être fait pour atteindre les objectifs (que transformer uniquement)
Contraintes = externes à l'entreprise et pour lesquelles il faut s'adapter
Permet de guider les archi du SI (App&Data puis technique) = prérequis
Sorties:
Init du document de définition de l'architecture
C) Architecture du SI (appli et des données) :
Objectifs:
Comment le SI aide et supporte les processus (app & data) + interopérabilités
=> App et data au sens fonctionnel !! Pas de code ni solution techno App:
Définis les services et interactions en mode boite noire
Data:
Décrit la structure logique de données
D) Architecture technique :
Objectifs:
Comment la technologie supporte les app et data
Décrit les exigences techniques (perfs, restrictions OS, compatibilité etc. => specs techniques)
Décrit l'infra (compute / storage / network) + software
NE DETAILLE PAS LES SOLUTIONS TECHNIQUES à mettre en face des exigences
E) Opportunités et solutions :
Objectifs:
Génère la version initiale de la feuille de route
Fait un choix definitif sur les building blocks de solution (dev spécifiques, SaaS, sur étagère etc.)
Détermine l'approche (incrémentale vs annule et remplace…)
Construit au besoin les architectures de transition
Etapes:
Déterminer les facteurs clés du changement (matrice IFAD)
Déterminer les contraintes métier:
Revoir le plan stratégique du métier
Revoir les impacts avec les évo en cours ou à venir
Revoir et consolider les analyses d'écarts
Matrice Gaps, Solutions, Dépendances (GSD)
Définir la stratégie globale de mise en œuvre:
From scratch
Big bang
Évolutive
Approches pour la mise en œuvre:
Quick win
Objectifs atteignables
Basé sur la chaine de valeur
Sorties:
Mise a jour des livrables des étapes précédentes
Architectures de transition
Feuille de route de l'archi - v1.0
Init Plan de mise en œuvre et migration - draft
Approche:
Work Package: lot de travail, groupe logique de changements pour réaliser une archi cible
Feuille de route: enumère les lots de travaux planifiés dans un calendrier
Archi de transition: architecture temporaire sur la trajectoire cible qui permet une convergence
Plan de mise en œuvre: calendrier des projets qui implémentent l'archi cible
F) Planification de la migration - Finalisation de l'archi :
Objectifs:
Transforme les exigences d'archi en projets de réalisation chiffrés en temps + $
S'appuie sur les PO / Chef de projet
Définis un plan détaillé de migration et mise en œuvre
Finalise la feuille de route des projets de réalisation => planning
S'assure que les plans sont coordonnés
Les métiers ont validés les projets
L'architecte passe de Owner à Contributeur, en mode "support aux projets"
Etapes:
Confirmer les interactions avec les autres référentiels
Planif métier, EA, PMO, gestion des ops
Aligner le plan de mise en œuvre avec les métiers
Evaluer les problemes de synchro de l'EA avec les planif de l'IT existants
Donner une valeur métier à chaque projet:
Confirmer la valeur ajoutée, ROI et mesures de perfs métier
Associer les risques
Evaluer l'apport continu de valeur
Estimer le besoin en ressources, planif et orga realisation du livrable
Fait par les CP de chaque projet sous jacent
Associer des dates sur les incréments
Moyen de réalisation: interne, presta, les 2 etc.
Donner une priorité à chaque projet de migration
Confirmer les incréments
Sorties:
Tous les livrables sont livrés en version finalisée
Produit les draft de contrat d'archi
Approches:
Technique planification des transitions:
Planification basée sur l'apport de valeurs aux métiers
G) Gouvernance de la mise en œuvre (= de l'implémentation) :
Objectifs:
Superviser les projets de déploiements
Assure le lien entre l'équipe d'archi et les équipes de mise en oeuvre en se basant sur le Contrat d'Architecture
S'assurer de la conformité des projets avec l'archi cible
Formuler des recommandations
Etapes:
Confirmer le scope et les prio avec chaque projet (avec Contrat d'Archi)
Identiifier les ressources et compétences => action des CP de chaque projet
Guider le développement des solutions (= reco)
Effectuer les revues de conformité
Pour chaque building block
Publier les infos dans le référentiel d'archi
A des jalons clés du projet
Evaluation par rapport au contrat d'archi
Revue de bilan = revue de conformité une fois le projet délivré
Sortie:
Contrats d'architectures signés:
1 contrat par projet: Nom, desc et objectifs du projet
Thèmes: app, data, secu…
synthèse des exigences du dossier d'archi pour le projet
Validé (signé) par le projet, archi et sponsor
CR des évaluations de conformité
Demandes de changements
H) Gestion du changement de l'architecture :
Objectifs:
Garantir que le cadre de gov de l'archi est executé
Vérifie que les exigences et capacités sont bien atteintes
Garanti que les capacité de l'EA satisfont les exigences actuelles
Peut intervenir n'importe quand dans le cycle
Prépare le démarrage d'un nouveau cycle ADM
Identifier les demandes de changement d'archi
Intégrer des modifs dans les projets en cours => c'est une simplification = cycle courant
Si changement d'une capacité => modification incrémentale = cycle suivant ADM
Si changement pour améliorer / créer de nouvelles capa => modif re architecture = nouveau projet ADM
Comité d'archi evalue et approuve les demandes de changement
2 types de moteurs du changement de l'archi:
Moteurs métiers
Moteurs technologiques
Etapes:
Etablir la valeur ajoutér après MEP
Consulter les outils de monitoring
Gérer les risques
Effectuer l'analyse des demandes de changements (instruire les demandes pour présenter au comité d'archi)
Les développer pour répondre aux objectifs de perfs
Gérer le processus de gouvernance
Activer le processus de mise en oeuvre des changements
Sorties:
Update referentiel d'archi
Demandes de changements avec décisions
Gestion des exigences :
Identifier, sauvegarder et versionner les exigences
Def exigence:
déclaration d'un besoin de l'entreprise
adressé par une architecture particulière
Analyse d'impact des exigences:
Priorité pour le métier
Phase de l'ADM à revoir si impact ADM
Phase ADM permettant de définir la priorité dans le projet d'archi
Résultats des analyses d'impact
Recommandations
Synthèse :
ADM Reco & Techniques:
Adapter TOGAF:
Utiliser les itérations ADM
Utiliser ADM a différents niveaux de l'entreprise
Techniques à appliquer dans les phases de l'ADM:
Principes d'archi
pattern d'archi
Gestion des acteurs concernés
Techniques de planif et migration
Exigence d'interoperabilité
Eval du niveau de préparation du métier a la transfo
Gestion des risques
Planif basé sur l'apport de capacité
Series guide lib TOGAF:
Business scenarios pour les phases A et B
Integration des risques et de la sécurité
TOGAF pour SOA
Cadre de contenu:
Permet de structurer les différents artefacts pour faciliter la cohérence entre les différentes archi (qui seraient fédérées) lors d'un cycle ADM
Il définit un Méta modele:
= Modèle du modèle
Définit le datamodel objets et relations pour représenter les architectures pour assurer:
Cohérence
Exhaustivité
Traçabilité
Vise a simplifier les concepts, en fonction du point de vue
Les types d'objets et domaines proposés par TOGAF:
General Entites : conditions et contraintes de l'archi
Business Arch (jaune)
App Arch (vert)
Data Arch (rose)
Tech Arch (bleu)
Driver + Goal + Objective + Measure = ne sont pas des building blocks car non réutilisables
Building Blocks:
= un composant réutilisable
Décrit un ensemble de fonctionnalités
A un type correspondant à ce qui est proposé dans le méta modèle
Sa terminologie est connue pour les experts du domaine
Peut servir à construire d'autres BB
BB d'Architecture = ABB
Décrit la capacité attendue
Spécifie les BB de solution
BB de Solution = SBB
Représente une implémentation d'un composant d'archi
= "Physical componant" dans le datamodel TOGAF
Artéfacts:
= la plus fine représentation d'un point de vue
=> égale une brique
Décrit 1..n building block
Différents types:
Catalogs
Matrices
Diagrams
Livrables:
= produit d'une phase d'un cycle de développement d'archi (cycle ADM)
Contractuellement spécifié
Formellement revu et validé par les acteurs concernés
Est composé de 1..n artefacts
Définitions:
Pdv d'archi: specification des conventions pour construire et utiliser une vue + perspective 1..n acteurs
Vue d'archi: Représente un système selon la perspective d'un ensemble de préoccupations
Modèle d'archi: représentation d'un sujet d'intérêt (1..n modèle de différente représentation)
TOGAF propose une liste d'artefact à produire par phase ADM et domaine d'architecture
Continuum d'entreprise et outils:
Fournit une classification (= taxonomie) pour:
les Building Block (ABB et SBB)
les artefacts
les livrables
En fournissant:
Une méthode
Un ou plusieurs outils = le Référentiel d'architecture
Référentiel d'architecture = organisé / classé, est une solution d'organisation:
=> le continuum c'est une vue sur le référentiel d'archi
Permet à l'architecte de montrer avec quoi, pourquoi, et comment l'architecture d'entreprise a été conçue
Favorise la réutilisation des xBB
Propose 2 répertoires de classification:
Continuum d'Archi: archi génériques et spécifiques avec 4 niveaux:
Socle générique, archi de système communs, archi d'industrie, archi spécifique à l'orga
Ex socle: technical reference model, modèle d'archi logicielle (= un Pattern)
Ex système commun: archi réseau, archi secu, archi échange d'infos… (= cross système)
TOGAF propose III-RM qui est une archi de systèmes communs
Continuum de Solutions: Solutions génériques et spécifiques avec 4 niveaux:
=> produits réels déployés / à déployer
Socle commun générique, solution de systèmes communs, Industrie, spécifique à l'orga
Propose différents conteneurs pour y ranger les xBB + artéfacts:
Paysage d'archi
Paysage de solution
Bibliothèque de référence
Capacité d'archi
Journal de gouvernance
…
Partitionnement de l'archi: Propose un découpage pour réaliser l'EA sur les grandes orga
Cadre de capacité:
Objectifs:
Fournit un ensemble de référence pour savoir comment créer une cellule archi TOGAF
Définir roles, responsabilités, compétences et processus de gouvernance
Gouvernance des travaux de l'EA:
TOGAF doit être adapté au contexte de l'entreprise (maturité, ambition…)
L'EA doit s'intégrer dans les référentiels et processus existants (ITIL, SCRUM, Budget…)
4 types de gov selon TOGAF:
Gov d'entreprise
Gov informatique
Gov du business
Gov de l'EA - est bien indépendante de la gov informatique
Les processus de la gouvernance de l'EA:
Prise en charge et gestion des règles
Conformité
Dérogation
Surveillance et rapports
Contrôle business
Gestion de l'environnement (paramétrage et config des outils)
Comité d'archi:
Transverse à toute l'entreprise - en principe -, inclus les EA + le CIO / CTO + …
Les couts de mise en place sont largement compensés par la garantit d'obtenir des composants réutilisable tout en evitant les problèmes et couts induits par des solutions uniques
Modèle de marurité de l'archi:
Permet de connaitre sa maturité et evaluer ses capacités
Evaluation sur 9 domaines
Examen Prep lvl 1
40 questions:
Concepts de base: 3 q
Concepts principaux: 3 q
ADM: 3 q
Continuum enterprise: 4 q Phases ADM: 9 q ADM Reco et techniques: 6 q Gouvernance de l'archi: 4 q Archi vue, pdv et acteurs: 2 q
Building blocks: 2 q
Livrables: 2 q
Modèles de ref: 2 q
22 bonnes réponses pour avoir la certif (55% mini)
QCM, 1 seule bonne réponse
60 minutes
Prep
