Le cadre de référence TOGAF® est une méthode pour développer l’architecture d’entreprise, grâce à l’utilisation d’un ensemble d’outils, et est disponible gratuitement sur le site Web Open Group pour les organisations souhaitant mettre en œuvre une architecture d’entreprise. La première version publiée en 1995 était basée sur le cadre d’architecture technique de la gestion de l’information (TAFIM), développé par le département américain de la Défense.
Les objectifs de TOGAF:
Le cadre de référence TOGAF® est une approche de développement architectural « rapide » et de gouvernance efficace. Il ne prescrit pas les modèles à utiliser pour représenter l’architecture, mais guide le processus lors de la création de l’architecture. Grâce à son évolutivité, il peut être utilisé pour les organisations gouvernementales, les grandes entreprises et même les petites et moyennes entreprises. En examinant les différents niveaux d’architecture qu’un framework peut prendre en charge, TOGAF® essaie de prendre en charge tous les niveaux, allant de l’architecture d’entreprise, de données, d’application à l’architecture technologique.
Les avantages de TOGAF® :
- Une méthode testée et appliquée par des milliers d’architectes numériques
- Un dictionnaire commun, pour que chacun puisse comprendre les informations fournies par l’architecture résultante
Le cadre de référence TOGAF® :
La structure TOGAF® est composée des principales parties suivantes:
- Le Cadre de Capacité : Who ? Qui devrait être impliqué ?
- Le Cycle ADM, pour Architecture Development Method (ADM) : What ? Que faire ?
- Les lignes directrices et techniques d’ADM : How ? Comment faire ?
- Le Cadre de Contenu : Which ? Quelle documentation produire ?
- Continuum d’entreprise et outils : Where ? Où stocker la documentation ?
ADM: La méthode de développement architectural
La méthode de développement architectural est une approche détaillée, divisée en phases, qui explique comment gérer l’ensemble du cycle de vie d’une architecture.
Phase préliminaire:
Dans cette phase, l’équipe d’architecture d’entreprise, les principes architecturaux et le cadre à utiliser sont définis.
Phase A – Vision de l’architecture :
Cette phase permet d’identifier :
- La liste des parties prenantes, leurs rôles, leurs implications
- Un consensus sur les objectifs, les exigences, les contraintes et les règles d’architecture
- Le périmètre impacté
- Le plan de développement du cycle ADM, les moyens humains, techniques et financiers
- Une cartographie à grande échelle de l’architecture initiale et de l’architecture cible
- L’identification des risques et le plan pour les réduire
Phase B – Architecture Métier :
Le métier avec ses exigences, ses processus et ses entités, gouverne l’architecture d’entreprise. La phase B Métier permet de fixer l’architecture cible et de mesurer les impacts. Les résultats de cette phase peuvent être définis en utilisant, par exemple, UML ou IDEF-0. Le choix de la méthode de modélisation utilisée est basé sur les vues (views) requises, dont les “viewpoints” sont identifiés dans cette phase.
Phase C – Architecture des Systèmes d’Information :
Le but de cette phase est de décrire l’architecture des données et l’architecture des applications. Les vues créées dans cette phase sont à nouveau modélisées dans la modélisation choisie. Pour les bases de données, par exemple, il peut s’agir de modélisation de données relationnelles.
Phase D – Architecture technique :
Le but de cette phase est de décrire l’architecture technologique qui constituera la base des travaux de mise en œuvre ultérieurs.
Phase E – Solutions et opportunités :
Cette phase identifie les caractéristiques du changement, détermine les contraintes de mise en œuvre, valide les dépendances et identifie toute architecture de transition. Le résultat de cette phase constituera la base du plan de mise en œuvre requis pour passer à l’architecture cible.
Phase F – Planning de migration :
Cette phase se concentre sur la priorisation des projets et les coûts de migration des différents projets sont estimés. Le résultat final est une feuille de route détaillée de l’architecture, incluant le plan de mise en œuvre et de migration.
Phase G – Gouvernance de la mise œuvre :
Pour chacun des projets de mise en œuvre, une organisation correspondante est désignée pour assurer sa mise en œuvre. Parallèlement, des revues de conformité seront effectuées pour s’assurer qu’à la fin de cette phase, le système est entièrement réalisé et implémenté conformément aux spécifications.
Phase H – Gestion de la maintenance et des évolutions :
Le cycle de vie de l’architecture ne s’arrête pas après la mise en œuvre du système. Le but de cette phase est de gérer les modifications de l’architecture de manière cohérente. Afin de maintenir l’architecture flexible et dynamique, tout changement technologique ou environnemental doit être rapidement intégré à l’architecture. Au cours de cette phase, la décision est prise sur la nécessité d’initier formellement un nouveau cycle d’évolution de l’architecture pour chaque demande de changement. Cette décision doit être prise sur la base de critères prédéfinis, qui détermineront si une demande de changement ne nécessite qu’une mise à jour de l’architecture actuelle ou un redémarrage du cycle. Ces critères ne sont pas prédéfinis par le cadre TOGAF®, car l’acceptation du risque diffère trop d’une organisation à l’autre.
Phase Gestion des exigences:
Le cercle central du cycle ADM nous montre que les différentes phases de l’ADM sont alimentées par les exigences. Le cadre TOGAF® ne prescrit pas une manière spécifique de collecter et de gérer ces exigences, il spécifie uniquement ce que doit être un processus efficace de gestion des exigences.
Les inputs pour le processus de gestion des exigences sont fournies par les différentes phases du cycle ADM.
Résultat final :
Lors de l’application du cadre de référence TOGAF® pour créer une architecture, de nombreuses organisations ne bénéficient pas toujours des bénéfices prévus. Cela est généralement dû au fait qu’une architecture est souvent mise en œuvre de bas en haut, où la direction ne s’engage pas suffisamment pour atteindre les objectifs de l’entreprise avec des objectifs architecturaux, ce qui rend impossible d’atteindre l’objectif de l’entreprise attendu par le biais du levier de l’architecture. Ce problème se produit pour chaque framework utilisé pour créer une architecture. Il est donc essentiel que le plan stratégique, utilisé dans la phase A, soit partagé et approuvé par l’ensemble de l’organisation.
A lire également : ITIL vs COBIT : différences et points communs
