TOGAF (The Open Group Architecture Framework) est un cadre organisationnel ouvert. Le framework lui-même est un corpus de connaissances bien documenté, comprenant des méthodes détaillées et un ensemble d’outils de support pour le développement de l’architecture d’entreprise. TOGAF 9.2 est la dernière version du framework.
- TOGAF est développé et maintenu par des membres de The Open Group et travaille au sein d’une équipe appelée Architecture Forum. Le premier développement de TOGAF version 1 a été produit en 1995, et les versions ultérieures de TOGAF ont élargi et amélioré ce système de connaissances.
- TOGAF a été développé grâce aux efforts conjoints de plus de 300 membres du forum d’architecture représentant certaines des principales entreprises et organisations mondiales. Il s’agit donc d’un bon résumé des pratiques générales d’architecture d’entreprise.
- Le développement et la maintenance d’une architecture d’entreprise est un processus complexe impliquant de nombreux acteurs et processus décisionnels. TOGAF aide en documentant les spécifications d’architecture d’entreprise, les processus et les produits de travail.
- En utilisant TOGAF, les organisations peuvent développer une architecture d’entreprise cohérente qui reflète les besoins des parties prenantes, adopte les meilleures pratiques et prend en compte de manière appropriée les besoins actuels et les besoins futurs perçus de l’entreprise.
D’où vient TOGAF ?
TOGAF est issu du cadre d’architecture des technologies de gestion de l’information (TAFIM) du département américain de la Défense. TOGAF 1.0 a finalement été publié en 1995 après des années d’exploration, avec l’autorisation du département américain de la Défense et l’aide d’un investissement important du gouvernement américain. TOGAF a publié sa neuvième version à ce jour, TOGAF 9 (la dernière version est TOGAF 9.2)
Pourquoi TOGAF ?
L’architecture informatique doit refléter étroitement les objectifs commerciaux de l’organisation. En effet, des techniques spécifiques (scénarios métiers) doivent être utilisées pour s’assurer que les objectifs métiers sont bien compris par l’architecte informatique, et reflétés dans l’architecture informatique développée à l’aide de TOGAF.
Voici les raisons pour lesquelles nous devrions adopter TOGAF ADM pour le développement d’architecture :
- Une méthode générale complète
- Complémentaire et non concurrent des autres frameworks
- Largement adopté sur le marché
- Adaptable pour répondre aux besoins d’une organisation et de l’industrie
- Disponible sous une licence perpétuelle gratuite
- Norme ouverte neutre vis-à-vis du fournisseur, de l’outil et de la technologie
- Évite de réinventer la roue
- Alignement informatique d’entreprise
- Basé sur les meilleures pratiques
- Possibilité de participer à l’évolution du framework
Qu’est-ce qu’ADM ?
La méthode de développement d’architecture (ADM) est appliquée pour développer une architecture d’entreprise qui répondra aux besoins commerciaux et informatiques d’une organisation. Le TOGAF ADM est le résultat des contributions continues d’un grand nombre de praticiens de l’architecture pour servir les objectifs suivants :
- Il décrit une méthode de développement et de gestion du cycle de vie d’une architecture d’entreprise et constitue le cœur de TOGAF.
- Il peut être adapté aux besoins de l’organisation et est ensuite utilisé pour gérer l’exécution des activités de planification de l’architecture.
La méthode de développement d’architecture, souvent appelée l’abréviation d’ADM, est un processus détaillé étape par étape utilisé pour développer ou modifier l’architecture d’une entreprise.
ADM décrit 10 phases couvrant le cycle de développement de l’architecture.
Ces phases sont :
- Stage préliminaire
- Phase A : Vision architecturale
- Phase B : Architecture métier
- Phase C : Architecture du Système d’Information
- Phase D : Architecture technique
- Phase E : Opportunités et Solutions
- Phase F : Planification de la migration
- Etape G : Mettre en place la gouvernance
- Phase H : Gestion du changement d’architecture
- Gestion des exigences
Entrée et sortie ADM
TOGAF fournit un certain nombre de livrables d’entrée et de sortie de chaque phase :
- Ce sont des suggestions et il n’est pas nécessaire de les suivre exactement
- Chaque livrable produit doit être versionné pour indiquer quand un changement s’est produit
- La numérotation des versions indiquée est également une suggestion et n’a pas besoin d’être suivie
Livrables
Un produit de travail spécifié contractuellement et à son tour formellement examiné, accepté et approuvé par les parties prenantes. Il sera généralement archivé à la fin d’un projet ou transféré dans un référentiel d’architecture en tant que modèle de référence
Stade initial:
L’objectif principal de la phase initiale est de déterminer et d’établir les capacités architecturales requises de l’organisation.
L’un des éléments clés consiste à déterminer ce qui doit être fait et comment le mettre en œuvre. Par exemple, le résultat principal est une demande de travail architectural qui décrit les exigences et décide de la portée, de la structure, des outils ou du cadre architectural nécessaire pour prendre en charge ce travail.
À ce stade, TOGAF est spécifiquement conçu pour répondre aux besoins d’itération ADM à venir. Nous définissons les principes de base, évaluons la capacité de la structure de l’entreprise et de l’activité à apporter les modifications requises et intégrons TOGAF à d’autres cadres de gestion. Il y a des étapes à ce stade pour limiter l’organisation de l’entreprise affectée par les changements proposés, confirmer le cadre de gouvernance et de support correct, définir et établir une équipe et une organisation EA, identifier et établir des principes architecturaux, personnaliser TOGAF et tout autre cadre, et mettre en œuvre des outils . À la fin de cette phase, l’équipe d’EE devrait être prête à suivre les itérations du cycle ADM. Cela s’explique en partie par le fait que l’étape préliminaire est affichée en haut du diagramme ADM et à l’extérieur de la boucle principale des étapes A à H.
Phase A : Vision architecturale :
La phase A fournit un énoncé de travail architectural clair qui sera fourni dans l’itération d’ADM. Il fournit également une vision de l’architecture d’entreprise proposée. Ce sens de l’orientation est essentiel pour guider le travail d’ADM tout au long du processus d’itération. L’ énoncé de l’œuvre architecturale définit les procédures de développement et de déploiement de l’architecture décrite dans la vision architecturale. C’est la vision qui fournit le désir de haut niveau pour la fonctionnalité et la valeur commerciale que l’architecture d’entreprise proposée fournira. En commençant par la demande d’emploi dans la construction, la phase A fournit un outil (cette vision) pour vendre les avantages des capacités proposées aux parties prenantes et aux décideurs de l’entreprise. Les scénarios métier sont utilisés pour comprendre les exigences métier et aider à clarifier les exigences architecturales impliquées par les fonctions requises. Ceci est documenté dans la déclaration de travail d’architecture et est utilisé pour établir un consensus pour prendre en charge l’architecture finale. Lorsque l’organisation parrainante signe le document, un consensus émergera.
Les étapes de la phase A consistent à transformer la demande de travaux de construction en un énoncé de travail architectural clair et à s’assurer que l’entreprise est capable, prête, disposée et engagée à apporter les modifications architecturales nécessaires. Il s’agit d’établir un projet d’architecture, incluant la définition de son périmètre, ainsi que la validation et l’élaboration des principes d’architecture et d’affaires. La phase A identifie les parties prenantes et leurs préoccupations et exigences, et confirme les objectifs commerciaux, les facteurs moteurs et les contraintes de la phase préliminaire. Pour garantir le succès, il évalue également les capacités de l’entreprise, évalue la préparation à la transformation de l’entreprise et résout tous les risques de transformation.
Phase B : Architecture métier :
TOGAF considère l’architecture d’entreprise comme un moyen d’améliorer les capacités métier. C’est pourquoi la première phase de développement de l’architecture traite de l’architecture métier .
ADM du point de vue commercial – dans les étapes préliminaires des demandes de travaux d’infrastructure pour déterminer la forte demande commerciale, et affiné pour la phase A dans l’énoncé de vision des travaux d’infrastructure et de l’architecture .
Un objectif clé de la phase d’architecture métier est de développer l’architecture métier cible, qui montre comment l’entreprise réalise la vision de l’architecture et résout la demande de travail d’architecture. Son deuxième objectif est d’abord d’identifier les composants candidats de la feuille de route de l’architecture pour combler l’écart entre l’architecture de référence et l’architecture métier cible. TOGAF considère la connaissance de l’architecture d’entreprise comme une condition préalable au travail d’architecture dans d’autres domaines (tels que les données, les applications et la technologie). L’architecture d’entreprise démontre également aux principales parties prenantes la valeur commerciale et le retour sur investissement du travail d’architecture. Les modèles commerciaux, tels que les modèles d’activité ou de processus, les cas d’utilisation et les modèles de classe, ou les diagrammes de connexion de nœuds,
Les trois phases de développement de l’architecture (B, C et D) suivent des étapes similaires. Il est important de réutiliser tout modèle de référence disponible et de personnaliser tous les résultats pour répondre au point de vue des parties prenantes. Ensuite, l’architecte développe une description de base et des objectifs de l’architecture métier, et effectue une analyse des écarts pour déterminer comment passer de l’un à l’autre.
Phase C : Architecture du système d’information :
TOGAF divise la phase C – Architecture du système d’information – en deux parties, couvrant le développement de l’architecture des données et des applications . Le document TOGAF comporte un court chapitre d’introduction couvrant deux domaines, suivi de chapitres distincts sur les données et les applications. Comme pour les autres étapes de développement d’architecture (B&D), l’objectif est de développer l’architecture du système d’information cible pour les données et les applications, et de déterminer les composants de la feuille de route de l’architecture candidate en fonction de l’écart entre l’architecture de référence et l’architecture cible.
La phase C implique toujours la combinaison des données et de l’architecture des applications. À condition que les deux soient inclus, et cela n’a pas d’importance dans l’ordre, il y a des défenseurs des deux méthodes. Les étapes pour les données et les applications sont très similaires : sélectionnez des modèles de référence, des points de vue et des outils ; développer des bases de référence, puis localiser des descriptions d’architecture, effectuer une analyse des écarts et définir les composants de feuille de route candidats ; et résoudre tout impact sur l’environnement global de l’architecture. Après un examen formel des parties prenantes, l’architecture a finalement été déterminée et un document de définition de l’architecture a été créé.
La principale différence entre les données et les applications réside dans le thème, qui se reflète dans l’utilisation de différents modèles de référence, technologies et représentations architecturales. Par exemple, l’architecture de données peut utiliser des relations d’entité ou des diagrammes de classes, tandis que l’architecture d’application peut utiliser des diagrammes de communication d’application ou des diagrammes d’ingénierie logicielle.
Phase D : Architecture technique :
La phase D est la phase de TOGAF, qui développe l’architecture technique du projet d’architecture. L’architecture technologique décrit la structure et l’interaction des services de plate-forme et des composants technologiques logiques et physiques. La phase D développe l’architecture technologique cible, qui prend en charge les composants de données et d’application (développés dans la phase C) pour réaliser les composants métier.
Les architectures développées dans les phases B, C et D sont combinées pour réaliser la vision architecturale répondant aux préoccupations des parties prenantes et aux demandes de travaux de construction. Comme pour les autres phases de développement d’architecture, la phase D identifie les composants candidats de la feuille de route de l’architecture pour réaliser la transition de la référence à la cible. Les étapes de la phase D sont presque les mêmes que celles des phases B et C – la principale différence est que l’accent est maintenant mis sur la technologie. Par conséquent, cela inclut les modèles de référence technique et les normes ou mesures techniques, telles que les performances, la maintenabilité, l’emplacement et la latence ou la disponibilité.
La détermination des extrants et des livrables est très importante pour aider à construire l’architecture technique qui prend réellement en charge le système d’information et l’architecture métier. L’obtention de la bonne portée peut accélérer les retours, tandis qu’une trop grande portée entravera la réussite de la mise en œuvre. Il ne s’agit pas de la technologie de déploiement elle-même, mais du développement d’une architecture technique qui répond véritablement à la vision architecturale et aux demandes de travail.
Phase E : Opportunités et solutions :
La phase E tire son nom – elle consiste à trouver des opportunités pour fournir l’architecture cible en mettant en œuvre des solutions spécifiques. La phase E génère la première version complète de la feuille de route de l’architecture en combinant les recommandations des phases d’analyse et de développement du bâtiment – B, C et D.
À ce stade, l’accent est mis sur la façon de fournir l’architecture. Par conséquent, il se concentre sur la création d’une feuille de route d’architecture, répertoriant les packages de travail dans un calendrier pour atteindre l’architecture cible. Lorsque le changement est si important qu’il est impossible de passer directement de l’architecture de référence à l’architecture cible, alors l’étape E produira une approche incrémentale, constituée d’architectures intermédiaires ou transitoires. La phase E cartographie les changements architecturaux requis pour les procédures d’investissement et les projets qui disposent des fonds et des ressources nécessaires pour exécuter le lot de travaux, et fournit des architectures de transition et cibles. L’entrée à ce stade est presque tout ce qui sort du stade initial. Ces étapes prennent ces sorties; les consolider, analyser les dépendances et concilier les différences ; et reconfirmer que l’organisation peut apporter des changements. La phase E améliore et met à jour les exigences, les documents d’architecture et les feuilles de route d’architecture. Le résultat clé est la première étape du plan de mise en œuvre et de migration.
Phase F : Planification de la migration :
Les premières étapes d’ADM ont identifié le besoin de changements architecturaux, puis ont développé les architectures commerciales, de données, d’application et techniques pour répondre à ce besoin. Ensuite, dans la deuxième phase, un plan de mise en œuvre et de migration de haut niveau est développé pour tirer parti des opportunités d’investissement et identifier des solutions spécifiques. Architecture cible : la phase F finalise le plan détaillé d’implémentation et de migration, ainsi que la feuille de route finale de l’architecture.
Il s’assure également que le plan est coordonné avec les méthodes de conduite du changement utilisées au sein de l’entreprise et les autres plans du portefeuille global de changement. Enfin, la phase F garantit que les principales parties prenantes comprennent pleinement la valeur commerciale, le coût du lot de travaux, ainsi que la transition et l’architecture future. Bien que les premières étapes d’ADM soient très guidées par l’équipe d’architecture d’entreprise, l’étape de E à H nécessite une collaboration avec d’autres agents de changement.
La phase F nécessite notamment une coopération étroite entre les quatre cadres de gestion afin de réussir la mise en œuvre et le plan de réinstallation.
Les quatre domaines sont :
- plan d’affaires
- L’architecture d’entreprise
- Gestion de portefeuille
- gestion de projet
Grâce à la coopération, ces quatre domaines doivent prioriser le travail, en utilisant des critères tels que l’évaluation des performances, le retour sur investissement, la valeur commerciale, les facteurs clés de succès, la mesure de l’efficacité et l’adéquation stratégique.
Étape G : Mettre en œuvre la gouvernance :
Le développement et la mise en œuvre proprement dits se déroulent en parallèle avec la phase G. La phase G garantit que le projet de mise en œuvre et les autres projets en cours sont conformes à l’architecture définie.
En règle générale, l’architecture cible est développée sous la forme d’une série de transformations pour obtenir une valeur et des avantages commerciaux aussi rapidement que possible et pour atténuer les risques dans le plan de transformation. Chaque transformation est une étape vers l’entreprise cible pour réaliser ses propres intérêts commerciaux.
Au moment où nous atteignons la phase G, l’architecture a été développée (dans les phases A à D), les opportunités et les solutions pour fournir l’architecture ont été identifiées (dans la phase E), et les plans détaillés de mise en œuvre et de migration ont été achevés (dans la phase F ). Ainsi, le rôle de l’équipe d’architecture de la phase G est de superviser la mise en œuvre de l’architecture. Cela se fait en validant la portée et les priorités du déploiement, en guidant le développement et le déploiement de la solution et en effectuant des vérifications de conformité.
Les documents de contrat d’architecture sont utilisés pour piloter les changements d’architecture. Généré au début de la phase G et approuvé par la fonctionnalité d’architecture et les responsables de la mise en œuvre, il s’agit d’un mécanisme d’évaluation de la conformité de gouvernance de l’architecture.
Phase H : Gestion du changement de structure :
Rien ne s’est déroulé comme prévu – il y aura toujours de nouvelles exigences et des changements dans l’architecture. La phase H décrit le processus de gestion des modifications pour gérer les modifications apportées à l’architecture de manière cohérente et structurée. Habituellement, cela nécessite une surveillance continue des demandes de gouvernance, des nouvelles technologies ou des changements dans l’environnement des affaires.
Le processus doit prendre en charge l’architecture d’entreprise réalisée en tant qu’environnement dynamique capable de répondre avec souplesse à ces changements et de se développer rapidement. Dans la phase H, il est important que l’instance de gouvernance établisse des normes pour déterminer si une demande de changement nécessite une simple mise à jour de l’architecture ou si elle doit initier un nouveau cycle de méthode de développement de l’architecture (ADM). Les modifications doivent être directement liées à la valeur commerciale. Comment utiliser l’architecture d’entreprise est la partie la plus importante du cycle de développement de l’architecture, il est donc crucial de surveiller la croissance et le déclin de l’entreprise dans la phase H.
Au final, l’architecture d’entreprise qui fonctionnait hier pour l’organisation ne prend plus en charge les fonctions actuelles ou futures. Le résultat d’une demande de changement dans la phase H peut être classé comme une simplification, généralement motivée par l’exigence de réduire l’investissement ; un changement incrémental nécessitant une valeur supplémentaire de l’investissement existant ; ou reconcevoir le changement, qui est une exigence pour augmenter les investissements et créer une nouvelle valeur.
Gestion des exigences architecturales :
À chaque étape de l’ADM, des exigences de génération, d’analyse et d’examen sont requises. La phase de gestion des exigences décrit le processus de gestion de ces exigences architecturales dans l’ADM. La phase de gestion des exigences est au cœur d’ADM, c’est pourquoi elle apparaît au centre de l’agroglyphe ADM. Cette étape décrit le processus de gestion des exigences et comment le processus est lié aux autres étapes de l’ADM. Les exigences ne sont pas statiques, elles évoluent dynamiquement entre chaque étape de notre achèvement d’ADM et du cycle d’ADM.
Les exigences de l’architecture d’entreprise et les modifications ultérieures de ces exigences seront identifiées, stockées et entrées et sorties liées aux phases ADM, et entre les cycles ADM. Faire face aux changements de la demande est crucial. L’architecture traite de l’incertitude et du changement – la « zone grise » entre les attentes des parties prenantes et les possibilités ! Par conséquent, les exigences architecturales changeront toujours.
En outre, l’architecture implique de nombreux facteurs moteurs et contraintes qui échappent au contrôle de l’entreprise, tels que l’évolution des conditions du marché ou une nouvelle législation, qui entraîneront des modifications des exigences de manière imprévue.
TOGAF souligne que le processus de gestion des exigences lui-même ne traitera pas, ne résoudra pas ou ne hiérarchisera pas les exigences, car cela se fait dans la phase pertinente de l’ADM. L’étape de gestion de la demande n’est que le processus de gestion des demandes dans l’ensemble de l’ADM.
Phase préliminaire du SMA
Les activités de préparation et d’initiation requises pour créer une capacité d’architecture, y compris la personnalisation de TOGAF et la définition de l’architecture
Produits livrables :
- Principes architecturaux
- Référentiel d’architecture
- Principes commerciaux, objectifs commerciaux et moteurs commerciaux
- Modèle d’organisation pour l’architecture d’entreprise
- Demande de travaux d’architecture
- Cadre d’architecture sur mesure
ADM Phase A : Vision de l’architecture
La phase initiale d’un cycle de développement d’architecture. Il comprend des informations sur la définition de la portée de l’initiative de développement de l’architecture, l’identification des parties prenantes, la création de la vision de l’architecture et l’obtention de l’approbation pour poursuivre le développement de l’architecture.
Produits livrables :
- Principes architecturaux
- Feuille de route architecturale
- Vision architecturale
- Principes commerciaux, objectifs commerciaux et moteurs commerciaux
- Évaluation des capacités
- Plan de communication
- Déclaration de travaux d’architecture
- Cadre d’architecture sur mesure
ADM Phase B : Architecture opérationnelle
Architecture d’entreprise : le développement d’une architecture d’entreprise pour soutenir la vision architecturale convenue
Produits livrables :
- Document de définition d’architecture
- Principes architecturaux
- Spécification des exigences d’architecture
- Feuille de route architecturale
- Principes commerciaux, objectifs commerciaux et moteurs commerciaux
- Déclaration de travaux d’architecture
SMA Phase C : Architecture des systèmes d’information
Architectures des systèmes d’information : le développement des architectures des systèmes d’information pour soutenir la vision architecturale convenue
- Document de définition d’architecture
- Principes architecturaux
- Spécification des exigences d’architecture
- Feuille de route architecturale
- Déclaration de travaux d’architecture
ADM Phase D : Architecture technologique
Architecture technologique : le développement de l’architecture technologique pour soutenir la vision architecturale convenue
Produits livrables :
- Document de définition d’architecture
- Principes architecturaux
- Spécification des exigences d’architecture
- Feuille de route architecturale
- Déclaration de travaux d’architecture
ADM Phase E : Opportunités et solutions
Opportunities & Solutions effectue la planification initiale de la mise en œuvre et l’identification des véhicules de livraison pour l’architecture définie dans les phases précédentes
Produits livrables :
- Document de définition d’architecture
- Spécification des exigences d’architecture
- Feuille de route architecturale
- Vision architecturale
- Évaluation des capacités
- Plan de mise en œuvre et de migration
- Déclaration de travaux d’architecture
ADM Phase F : Planification de la migration
La planification de la migration explique comment passer des architectures de base aux architectures cibles en finalisant un plan détaillé de mise en œuvre et de migration
- Blocs de construction architecturaux
- Document de définition d’architecture
- Spécification des exigences d’architecture
- Feuille de route architecturale
- Demande de changement Plan de mise en œuvre et de migration
- Plan de gouvernance des implémentations
- Demande de travaux d’architecture
- Déclaration de travaux d’architecture
ADM Phase G : Gouvernance de la mise en œuvre
La gouvernance de la mise en œuvre fournit une supervision architecturale de la mise en œuvre
Produits livrables :
- Changer de requête
- Évaluation de la conformité
- Éléments constitutifs de la solution
- Déclaration de travaux d’architecture
ADM Phase H : Gestion des changements d’architecture
La gestion des changements d’architecture établit des procédures pour gérer les changements apportés à la nouvelle architecture. La gestion des exigences examine le processus de gestion des exigences d’architecture dans l’ensemble de l’ADM.
Sommaire
L’ADM est une méthode générale complète
- Il recommande une séquence pour les différentes phases et étapes impliquées dans le développement d’une architecture
- C’est une méthode itérative
- Il s’appuie sur les autres parties de TOGAF pour les actifs et les processus
- Il peut être utilisé avec d’autres livrables d’autres cadres
Voici l’aperçu de l’ADM TOGAF pour chacune des phases de développement, comme illustré dans la figure suivante :
- En savoir plus sur le guide TOGAF ADM
- En savoir plus sur les modèles TOGAF juste-à-temps
- En savoir plus sur les outils ArchiMate
- Essayez Visual Paradigm GRATUITEMENT
TOGAF Références d’introduction
- Qu’est-ce que TOGAF ?
- Tutoriel TOGAF ADM
- Cadre TOGAF 9.1 – Un guide complet
- Logiciel TOGAF pour l’architecture d’entreprise
- Le meilleur logiciel TOGAF
Français
English
简体中文
繁體中文
Deutsch
Español
العربية
Italiano
Português
日本語
Nederlands
Русский