Qu’est-ce que TOGAF ? Guide pratique de The Open Group Architecture Framework
TOGAF est un framework utilisé par les entreprises pour cartographier l’articulation de leurs processus métier, applications et systèmes de données, et pour les faire évoluer sans perturber ce qui fonctionne déjà. Ce guide explique comment sa méthode principale (ADM), et plus particulièrement la phase C, aide les équipes data à transformer des environnements complexes et fragmentés en plans de modernisation clairs.
- Qu’est-ce que le framework TOGAF ?
- La méthode ADM du TOGAF et l’architecture de données
- TOGAF et les plateformes data modernes
- TOGAF, COBIT et DAMA-DMBOK
- Questions fréquentes
- Ressources
Le projet de modernisation d’une plateforme data commence généralement au cœur d’un parc existant. Imaginez que le service financier dépende d’un circuit de reporting, et les équipes produit d’un autre. Imaginez que les équipes régionales aient leurs propres contraintes de résidence des données, et que les propriétaires d’applications soient les seuls à savoir quelles intégrations peuvent être modifiées sans rien abîmer. Avant d’être en mesure de définir une plateforme cible, les architectes doivent pouvoir décrire la plateforme actuelle avec suffisamment de précision pour planifier les changements. The Open Group Architecture Framework (TOGAF), un framework d’architecture d’entreprise, offre une approche commune pour ce travail de planification.
Qu’est-ce que le framework TOGAF ?
Géré par The Open Group, TOGAF organise l’architecture d’entreprise autour des domaines métier, des données, des applications et de la technologie. La norme TOGAF, 10e édition, structure ces directives sous la forme d’une bibliothèque de contenu modulaire, articulée autour de la méthode de développement de l’architecture (ou ADM, pour Architecture Development Method). Elle fournit une démarche cohérente qui relie la vision d'architecture initiale à la définition détaillée des différents domaines, puis à leur mise en œuvre et à la gestion continue des évolutions.
Pour les leaders des données, le travail le plus pertinent se déroule lors de la phase C, où l’architecture de données s’intègre à la feuille de route globale de l’entreprise.
La méthode ADM du TOGAF et l’architecture de données
La méthode ADM commence par une phase préliminaire au cours de laquelle les architectes établissent la capacité d’architecture elle-même : définition du framework et des principes, adaptation de l’ADM au contexte de l’entreprise et mise en place des structures de gouvernance avant le début de tout travail d’architecture de domaine.
À partir de là, l’ADM se décline en huit phases, auxquelles s’ajoute un processus de gestion des exigences qui s’exécute en continu tout au long de ces phases :
- Phase A : Vision de l’architecture
- Phase B : Architecture métier
- Phase C : Architectures des systèmes d’information, qui incluent l’architecture de données et l’architecture d’application
- Phase D : Architecture technologique
- Phase E : Opportunités et solutions
- Phase F : Planification de la migration
- Phase G : Gouvernance de la mise en œuvre
- Phase H : Gestion des changements de l’architecture
- La gestion des exigences, qui s’applique à l’ensemble du cycle
La phase C est celle où TOGAF est le plus directement lié à la gouvernance des données. Dans phase C consacrée à l'architecture de données, les équipes définissent la situation actuelle et la cible à atteindre, analysent les écarts entre les deux et les traduisent en initiatives inscrites dans la feuille de route d'architecture. Ce travail peut inclure des catalogues d’entités et de composants de données, des diagrammes de diffusion des données, des diagrammes de sécurité des données, des modèles de données logiques, des modèles de données physiques et des descriptions de la façon dont les informations circulent entre les systèmes.
Concrètement, la phase C demande aux architectes de rendre les données lisibles dans le cadre du système d’entreprise. Par exemple, une entité client est un nom de table, mais c’est aussi bien plus que cela : elle a une signification métier, des systèmes sources, des applications consommatrices, des contraintes d’accès, des attentes en matière de conservation et des relations avec d’autres entités.
Le workflow habituel de la phase C est simple, même lorsque l’environnement est complexe. Une équipe décrit l'état actuel de l’architecture de données, définit la cible à atteindre, compare les deux, puis détermine une feuille de route pour passer de l’un à l’autre. Cette feuille de route peut inclure des modifications du modèle de données, la modernisation de la plateforme, l’amélioration des métadonnées, l’alignement des politiques de sécurité ou des changements dans la façon dont les produits de données sont publiés et consommés.
TOGAF et les plateformes data modernes
Une fois qu’une équipe a défini l’architecture de données cible dans TOGAF, la question suivante est de savoir comment cette architecture est mise en œuvre dans la couche de la plateforme. Un modèle de données logique, un diagramme de diffusion ou une description de la sécurité des données doit toujours correspondre à des objets physiques, à des modèles de partage, à des ressources de calcul, à des contrôles d’accès et à des services de métadonnées. Voici comment Snowflake prend en charge ce travail :
Mappage de l’architecture de données avec les structures de données physiques
Les entités et les composants de données de la phase C peuvent correspondre aux bases de données, schémas, tables et vues Snowflake. Les modèles conceptuels et logiques appartiennent toujours à l’équipe d’architecture, mais Snowflake fournit les structures physiques où ces modèles deviennent des ressources gouvernées et interrogeables.
Traduction des diagrammes de diffusion en modèles de partage
Les diagrammes de diffusion des données peuvent correspondre aux modèles de Data Sharing, de réplication et de collaboration interrégionale de Snowflake. C’est là que les décisions d’architecture concernant le déplacement, la résidence et la disponibilité des données deviennent des modèles de mise en œuvre.
Connexion de l’architecture technologique à la conception de la plateforme
La phase D est liée à l’architecture de la plateforme elle-même : le stockage, le calcul, l’évolutivité, la simultanéité et la résilience opérationnelle. Dans Snowflake, cela peut inclure la séparation du stockage et du calcul, les entrepôts virtuels et la mise à l’échelle multi-cluster.
Association des exigences de gouvernance aux contrôles de la plateforme
Les descriptions de la sécurité des données peuvent correspondre au contrôle d’accès basé sur les rôles, au Dynamic Data Masking, aux Row Access Policies et aux politiques réseau. Les attentes en matière de métadonnées peuvent correspondre à Horizon Catalog pour la traçabilité des données, la classification, le balisage et le contexte des politiques.
TOGAF aide les équipes d'architecture à définir ce qui doit être mis en place : les domaines cibles, les flux, les produits de données, les exigences de sécurité, les étapes de migration et les points de contrôle de gouvernance. Une plateforme comme Snowflake peut aider à mettre en œuvre la couche physique et opérationnelle : les bases de données, les schémas, l’isolation du calcul, le partage, la réplication, les contrôles d’accès, la traçabilité des données et les métadonnées.
TOGAF, COBIT et DAMA-DMBOK
TOGAF, COBIT et DAMA-DMBOK apparaissent souvent ensemble, car ils abordent des questions connexes sous des angles différents.
- TOGAF est la méthodologie d’architecture. Il aide les architectes à définir l'architecture d'entreprise, à relier les besoins métier aux systèmes et aux données, et à piloter les évolutions grâce à l'ADM.
- COBIT est un framework de gouvernance. Il aide les entreprises à définir les objectifs de contrôle, les droits de décision, les mesures de performance et la responsabilité dans l’ensemble de l’informatique d’entreprise.
- DAMA-DMBOK est un corpus de connaissances sur la gestion des données. Il définit les disciplines de la gestion des données telles que la gouvernance des données, la gestion des métadonnées, la qualité des données, la gestion des données maîtres, la modélisation des données et la sécurité des données.
Pour mieux comprendre leur rôle respectif, examinons la question fondamentale à laquelle chacun tente de répondre. TOGAF demande : « Quelle architecture nous faut-il et comment y parvenir ? » COBIT demande : « Comment cette capacité doit-elle être gouvernée et contrôlée ? » DAMA-DMBOK demande : « Quelles pratiques de gestion des données doivent être appliquées au quotidien ? »
Dans le cadre d’un programme de modernisation de la plateforme data, les trois fonctionnent souvent ensemble. TOGAF peut définir l’architecture cible et la feuille de route de migration, COBIT peut façonner la gouvernance et la supervision des contrôles, et DAMA peut guider les pratiques opérationnelles relatives aux données qui maintiennent à jour les entités, les définitions, les métadonnées, les règles de qualité et les responsabilités de gestion des données.
FAQ sur TOGAF
Non. TOGAF est un framework d’architecture d’entreprise géré par The Open Group. Il comprend une phase d’architecture de données, mais il ne remplace pas un framework de gouvernance des données ou un modèle opérationnel. Les entreprises utilisent souvent TOGAF avec COBIT, DAMA-DMBOK ou des politiques de gouvernance internes.
Le portefeuille de certifications TOGAF de The Open Group comprend des titres basés sur la norme TOGAF, version 9.2 et la norme TOGAF, 10e édition. Les parcours de certification TOGAF Enterprise Architecture actuels incluent les niveaux Foundation et Practitioner, avec des options de transition pour certains professionnels qui détiennent déjà la certification TOGAF 9.
