TOGAF
Mise en oeuvre des modèles d'architecture d'entreprise
L’extension « Gouvernance » du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
L'extension "Gouvernance" a pour but de gérer des données structurées supplémentaires par rapport aux objectifs et aux services métier, comme les mesures, les contrats et la qualité de service, permettant de mettre en place la gouvernance opérationnelle de TOGAF.
Dans les précédents articles, nous avons vu que le métamodèle fournit un modèle de base avec l'ensemble de fonctionnalités minimum et prend en charge un mécanisme d'extensions facultatives permettant d’adapter et de personnaliser la description de l’architecture TOGAF.
Nous allons nous intéresser dans cet article à la première extension, la Gouvernance.
Le périmètre de l’extension Gouvernance
- La capacité d'appliquer des mesures aux objectifs, puis de lier ces mesures aux services
- Possibilité d'appliquer des contrats pour gérer les interactions de communication ou de service avec des utilisateurs et des systèmes externes
- La possibilité de définir des qualités de service réutilisables définissant un profil de niveau de service pouvant être utilisé dans les contrats
- Création de diagrammes supplémentaires pour montrer les propriétés et la gestion des systèmes
Conditions d'utilisation de l'extension Gouvernance
- Lorsqu'une organisation envisage un changement informatique qui aura un impact significatif sur les modèles de gouvernance opérationnelle existants
- Lorsqu'une organisation a des exigences granulaires pour les niveaux de service qui diffèrent d'un service à l'autre
- Quand une organisation cherche à transformer sa pratique de gouvernance opérationnelle
- Quand une organisation se concentre fortement sur les moteurs, les objectifs de l'entreprise et comment ceux-ci se rapportent aux niveaux de service
Les avantages de l'utilisation de l'extension Gouvernance
Les niveaux de service sont définis de manière plus structurée, avec :
- Ajouts de détails
- Possibilité de réutiliser les profils de service dans les contrats
- Traçabilité des objectifs métiers
Les impacts
Les impacts sur les opérations et les modèles de gouvernance opérationnelle sont considérés de manière plus structurée, avec :
- Diagrammes supplémentaires de la propriété du système et des données
- Diagrammes supplémentaires du fonctionnement du système et des dépendances sur les processus d'exploitation
- Diagrammes supplémentaires de gestion d'entreprise
TOGAF est cadre d’architecture d’entreprise ouvert, vous pouvez intégrer par exemple le cadre COBIT pour la gouvernance informatique.
Les modifications apportées aux entités et aux relations du métamodèle
Pour les entités et les relations du métamodèle les modifications sont :
- La mesure est ajoutée en tant que nouvelle entité qui relie le service objectif et le service métier.
- La qualité de service est ajoutée en tant que nouvelle entité fournissant un modèle de profil de service générique à appliquer aux services ou contrats d'entreprise.
- Le contrat est ajouté en tant que nouvelle entité qui formalise les caractéristiques fonctionnelles et non fonctionnelles d'une interaction de service avec d'autres services, des applications externes ou des utilisateurs.
Les attributs sont ajoutés pour les nouvelles entités de métamodèle de Mesure, Qualité de service et Contrat.
Conclusion
Le rôle de TOGAF est de fournir une norme ouverte pour l'architecture applicable dans de nombreux scénarios et situations.
Afin de répondre à cette vision, il est nécessaire de fournir un métamodèle d'architecture d'entreprise complet pour le contenu et de permettre sa personnalisation afin d'éviter de mener des activités inutiles, c’est le rôle des extensions.
Comme toutes les autres extensions, l’extension Gouvernance est facultative et a pour objectif de faciliter l’adaptation du métamodèle en fonction des besoins.
En ce qui concerne, cette extension Gouvernance, mettant en œuvre les indicateurs, les contrats et la qualité de services, elle me paraît être presque obligatoire.
Rhona Maxwel
@rhona_helena
"Aucune grâce extérieure n’est complète si la beauté intérieure ne la vivifie.
La beauté de l’âme se répand comme une lumière mystérieuse sur la beauté du corps."
Victor Hugo
Articles conseillés :
La structure de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
Le diagramme de classe UML du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
Pour que la conduite du changement d’architecture soit un succès, tous les acteurs, quel que soit leur domaine d’expertise, doivent se comprendre sans ambiguïtés, s’impliquer et coopérer.
Selon le vieil adage, « un schéma vaut mieux qu’un long discours », la vue simplifiée du diagramme de classe UML représentant uniquement les entités et leurs relations, destinée à tous, y compris les experts métiers, permet d’avoir une communication efficace.
L’alignement entre les objectifs métiers et les artefacts d’architecture est assuré par des liens de traçabilité que l’on peut mettre en place avec des outils (MEGA, Envision TOGAF & ArchiMate CASE, Modelio, …) grâce à ce diagramme de classe UML.
Les entités de base et celles introduites par les extensions
Lorsque toutes les extensions sont appliquées au métamodèle de contenu de base, un certain nombre de nouvelles entités de métamodèle sont introduites.
La carte complète du métamodèle
Conclusion
L’adhésion et l’implication des parties prenantes au projet de transformation de l’architecture d’entreprise implique une bonne compréhension et une communication efficiente.
Pour cela il faut un glossaire accompagné d’une cartographie sous forme de diagramme de classe UML de toutes les entités TOGAF.
Quel que soit leurs préoccupations et leurs points de vue spécifiques, les différents acteurs y trouveront les informations qu’il recherchent.
Rhona Maxwel
@rhona_helena
"Sans changer vos schémas de pensée, vous ne résoudrez pas les problèmes créés par votre schéma de pensée actuelle."
Albert Einstein
Articles conseillés :
Urbanisme SI : la nécessité d'un "espéranto"
SysML : éléments de base - le diagramme de bloc (block definition diagram)
BPMN l’exemple type pour tout comprendre sans prendre d’aspirine
La structure de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
Les concepts du métamodèle de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
L’objectif du métamodèle TOGAF est de définir une structure formelle pour les termes utilisés afin d'assurer la cohérence au sein de l'ADM et de fournir des conseils aux organisations qui souhaitent implémenter leur architecture dans un outil.
Une architecture TOGAF est basée sur la définition d'un certain nombre de briques architecturales dans les catalogues d'architecture, spécifiant les relations entre ces blocs dans les matrices d'architecture, puis présentant des diagrammes de communication qui montrent de manière précise et concise ce qu'est l'architecture.
Le métamodèle de contenu principal de TOGAF et ses extensions
Le rôle de TOGAF est de fournir une norme ouverte pour l'architecture applicable dans de nombreux scénarios et situations.
Afin de répondre à cette vision, il est nécessaire de fournir un métamodèle d'architecture d'entreprise complet pour le contenu et de fournir la possibilité d'éviter de mener des activités inutiles en soutenant la personnalisation.
Le métamodèle doit fournir un modèle de base avec l'ensemble de fonctionnalités minimum, puis prendre en charge l'inclusion d'extensions facultatives lors de l'adaptation de TOGAF.
Le métamodèle principal fournit un ensemble minimal de contenu architectural pour prendre en charge la traçabilité à travers les artefacts.
Des concepts de métamodèle supplémentaires pour prendre en charge une modélisation plus spécifique ou plus approfondie sont contenus dans un groupe d'extensions qui regroupent logiquement des catalogues d'extensions, des matrices et des diagrammes, ce qui permet de se concentrer sur des domaines spécifiques.
Tous les modules d'extension sont facultatifs et doivent être sélectionnés pendant la phase préliminaire du développement de l'architecture pour répondre aux besoins de l'organisation.
De plus, les regroupements d'extensions décrits par le métamodèle de contenu ne sont qu'une suggestion et une adaptation ultérieure peut être effectuée pour répondre aux besoins spécifiques à la discrétion des architectes.
Ce concept de base et d'extension est destiné à soutenir les approches formelles d'extension de méthodes au sein de TOGAF, telles que le concept de plug-in de méthode trouvé dans le logiciel SPEM (Software Process Engineering Metamodel) développé par OMG (Object Management Group).
Les Entités du métamodèle de base
Le métamodèle utilise la terminologie discutée dans l'ADM TOGAF comme base pour un métamodèle formel.
La terminologie est la suivante :
Acteur : Une personne, une organisation ou un système qui est en dehors de la considération du modèle d'architecture, mais qui interagit avec lui.
Composant d'application : encapsulation de la fonctionnalité de l'application alignée sur la structure de la mise en œuvre.
Business Service : prend en charge les fonctionnalités métier via une interface explicitement définie et est explicitement géré par une organisation.
Entité de données : encapsulation de données reconnues par un expert de domaine métier en tant que concept discret.
Les entités de données peuvent être liées à des applications, des référentiels et des services et peuvent être structurées en fonction de considérations d'implémentation.
Fonction : fournit des fonctionnalités métier étroitement alignées sur une organisation, mais non explicitement gérées par l'organisation.
Service du système d'information : les éléments automatisés d'un service métier.
Un service de système d'information peut fournir ou prendre en charge tout ou partie d'un ou de plusieurs services métier.
Unité d'organisation : Une unité autonome de ressources avec des buts, des objectifs et des indicateurs de mesures.
Les unités organisationnelles peuvent inclure des parties externes et des organisations partenaires.
Service de plate-forme : Une capacité technique requise pour fournir une infrastructure qui prend en charge la livraison des applications.
Rôle: un acteur assume un rôle pour effectuer une tâche.
Composante technologique : Encapsulation d'une infrastructure technologique représentant une catégorie de produit technologique ou un produit technologique spécifique.
Les relation clés liés aux entités de métamodèle
Un processus est un flux d'interactions entre des fonctions et des services et ne peut pas être déployé physiquement.
Tous les processus doivent décrire le flux d'exécution d'une fonction et, par conséquent, le déploiement d'un processus passe par la fonction qu'il prend en charge ; c'est-à-dire qu'une application implémente une fonction qui a un processus, et non une application qui implémente un processus.
La fonction décrit les unités de capacité métier à tous les niveaux de granularité.
Le terme « fonction » est utilisé pour décrire une unité d'activité à tous les niveaux de granularité, en encapsulant des termes tels que chaîne de valeur, zone de processus, capacité, fonction métier, etc. Toute fonction d'unité d'activité délimitée doit être décrite comme une fonction.
Les services métier prennent en charge les objectifs organisationnels et sont définis à un niveau de granularité cohérent avec le niveau de gouvernance requis
Un service métier fonctionne comme une limite pour une ou plusieurs fonctions.
La granularité des services aux entreprises dépend de l'orientation et de l'importance de l'entreprise (comme en témoignent les facteurs, les buts et les objectifs).
Un service dans la terminologie SOA (Service Oriented Architecture) (c'est-à-dire une unité d'application déployable) est en fait beaucoup plus proche d'un service d'application, composant d'application ou composant technologique pouvant implémenter ou supporter un service métier.
Les services métier sont déployés sur les composants de l'application
Les services métier peuvent être réalisés par une activité métierne se rapportant pas à l'informatique ou pouvant être supportée par l'informatique.
Les services métier pris en charge par le service informatique sont déployés sur des composants d'application.
Les composants d'application peuvent être décomposés hiérarchiquement et peuvent prendre en charge un ou plusieurs services métier.
Il est possible qu'un service d'entreprise soit pris en charge par plusieurs composants d'application, mais cela est problématique du point de vue de la gouvernance et est symptomatique des services métier à trop forte granularité ou des composants d'application qui sont trop fins.
Les composants d'application sont déployés sur des composants technologiques
Un composant d'application est implémenté par une suite de composants technologiques.
Par exemple, une application, telle que « Système RH », serait généralement implémentée sur plusieurs composants technologiques, y compris le matériel, le logiciel du serveur d'application et les services d'application.
Catalogue, matrice et concept de diagramme
Le métamodèle de contenu est utilisé comme une technique pour structurer l'information architecturale d'une manière ordonnée afin qu'elle puisse être traitée pour répondre aux besoins des parties prenantes.
La majorité des acteurs de l'architecture n'ont pas vraiment besoin de savoir ce qu'est le métamodèle d'architecture et ne sont concernés que par des problèmes spécifiques, tels que "quelles fonctionnalités supporte cette application?", "Quels processus seront impactés par ce projet?"
Afin de répondre aux besoins de ces parties prenantes, les concepts TOGAF de blocs de construction, de catalogues, de matrices et de diagrammes sont utilisés.
Les blocs de construction sont des entités d'un type particulier dans le métamodèle (par exemple, un service métier appelé «Commande d'achat»).
Les blocs de construction portent des métadonnées selon le métamodèle, qui prend en charge la requête et l'analyse.
Par exemple, les services métier ont un attribut de métadonnées pour le propriétaire, ce qui permet à un acteur d'interroger tous les services métier appartenant à une organisation particulière.
Les blocs de construction peuvent également inclure des entités dépendantes ou contenues selon le contexte de l'architecture (par exemple, un service métier appelé «Commande» peut implicitement inclure un certain nombre de processus, d'entités de données, de composants d'application, etc.).
Les catalogues sont des listes de blocs de construction d'un type spécifique, ou de types apparentés, utilisés à des fins de gouvernance ou de référence (par exemple, un organigramme, montrant les emplacements et les acteurs).
Comme pour les blocs de construction, les catalogues contiennent des métadonnées selon le métamodèle, qui prend en charge la requête et l'analyse.
Les matrices sont des grilles qui montrent les relations entre deux ou plusieurs entités modèles.
Les matrices sont utilisées pour représenter les relations basées sur des listes plutôt que sur leur utilisation graphique (par exemple, une matrice CRUD montrant quelles applications Créer, Lire, Mettre à jour et Supprimer un type particulier de données est difficile à représenter visuellement).
Les diagrammes sont des rendus de contenu architectural dans un format graphique permettant aux parties prenantes de récupérer les informations requises.
Les diagrammes peuvent également être utilisés comme technique pour remplir graphiquement le contenu de l'architecture ou pour vérifier l'exhaustivité des informations collectées.
TOGAF définit un ensemble de diagrammes d'architecture à créer (par exemple, organigramme).
Chacun de ces diagrammes peut être créé plusieurs fois pour une architecture avec un style ou une couverture de contenu différent pour répondre aux préoccupations des parties prenantes.
Les blocs de construction, les catalogues, les matrices et les diagrammes sont tous des concepts bien supportés par les principaux outils d'architecture d'entreprise.
Dans les environnements où les outils sont utilisés pour modéliser l'architecture, ces outils prennent généralement en charge des mécanismes pour rechercher, filtrer et interroger le référentiel d'architecture.
L'interrogation à la demande du référentiel d'architecture (tel que l'exemple de propriété de service d'entreprise mentionné ci-dessus) peut être utilisé pour générer des catalogues ad hoc, des matrices et des diagrammes de l'architecture.
Comme ce type de requête est par nature requis pour être flexible, il n'est donc pas restreint ou défini dans le métamodèle de contenu.
Les interactions entre le métamodèle, les blocs de construction, les diagrammes et les parties prenantes
Vue d'ensemble du métamodèle de contenu
Le métamodèle de contenu définit un ensemble d'entités qui permettent de capturer, stocker, filtrer, interroger et représenter les concepts architecturaux de manière à assurer la cohérence, l'exhaustivité et la traçabilité.
Au niveau le plus élevé, le cadre de contenu est divisé en fonction des phases ADM TOGAF
Les artefacts des principes d'architecture, de la vision et des exigences visent à capturer le contexte environnant des modèles d'architecture formelle, y compris les principes généraux d'architecture, le contexte stratégique entrant dans la modélisation de l'architecture et les exigences générées par l'architecture.
Le contexte de l'architecture est généralement recueilli dans les phases « Préliminaire » et « Vision » d’ADM.
Les artefacts de l'architecture métier capturent les modèles architecturaux de l'activité métier, en examinant spécifiquement les facteurs qui motivent l'entreprise, la structure organisationnelle de l'entreprise et les capacités fonctionnelles de l'entreprise.
Les artefacts de l'architecture des systèmes d'information capturent les modèles d'architecture des systèmes informatiques en examinant les applications et les données en phase avec les phases ADM de TOGAF.
Les artefacts d'architecture technologique capturent les actifs technologiques acquis qui sont utilisés pour implémenter et réaliser des solutions de système d'information.
Les artefacts de réalisation capturent des feuilles de route de changement montrant la transition entre les états d'architecture et les instructions de liaison qui sont utilisées pour piloter et gouverner une implémentation de l'architecture.
Représentation détaillée du métamodèle
Conclusion
Le métamodèle TOGAF décrit les éléments de base pour concevoir une architecture d’entreprise.
L’objectif est d’avoir un diagramme de classe des entités et leurs relations.
Cette cartographie des composants de TOGAF servira de moyen pou assurer la traçabilité à travers les artefacts.
Le métamodèle est un élément essentiel de communication entre tous les acteurs, il évite les mauvaises compréhension, les ambiguités.
Les nombreux désaccord et les longues discussions qui en découlent lors de réunions interminables, sont épargnées lorsqu'on montre le métamodèle et les définitions rigoureuses, presque mathématiques qui y sont détaillées.
Rhona Maxwel
@rhona_helena
"Il devient indispensable que l'humanité formule un nouveau mode de pensée si elle veut survivre et atteindre un plan plus élevé."
Albert Einstein
Articles conseillés :
La structure de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
Model-Driven Engineering (MDE) : modèles, métamodèles, métamétamodèles, méta... ?
Ingénierie Dirigée par les Modèles (IDM) : le tour de passe-passe des transformations de modèles
Ingénierie Dirigée par les Modèles (IDM) : un exemple vaut mieux qu'un long discours
Eclipse Modeling Framework (EMF) : revoyons les fondamentaux
Urbanisation SI : comment marche le méta-modèle ?
Libérez-vous, laissez votre stratégie prendre le leadership"
En cas d'évènements imprévus, votre SI doit savoir jouer les "Transformers" !
Avec un peu de métier, métamodéliser la vue métier pour assurer la traçabilité avec la stratégie
La structure de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
Quels éléments constituent la formalisation de l’architecture ?
Comme toute architecture digne de ce nom, TOGAF est composé de blocs, d’artefacts et de livrables.
Ces éléments sont regroupés dans le « cadre de contenu TOGAF » permettant aux principaux livrables créés par un architecte d'être définis, structurés et présentés de manière cohérente.
Les architectes exécutant la méthode de développement d'architecture (ADM) produisent un certain nombre de livrables, tels que les flux de processus, les exigences architecturales, les plans de projet, les évaluations de conformité de projet, …
Le cadre de contenu fournit un modèle structurel pour le contenu architectural, permettant aux principaux livrables créés par un architecte d'être définis, structurés et présentés de manière cohérente.
Le cadre de contenu fourni ici est destiné à permettre à TOGAF d'être utilisé comme un cadre autonome pour l'architecture au sein d'une entreprise.
Cependant, d'autres cadres de contenu existent (tels que le cadre de l'urbanisation du Système d'Information, Zachman ou Praxeme) et il est prévu que certaines entreprises puissent choisir d'utiliser un cadre externe conjointement avec TOGAF.
Pour les curieux, voici quelques articles consacrés à l'urbanisation du Système d'Information (voir les catégorie de ce blog Le processus d'urbanisation du Système d'Information et L'urbanisme et la gouvernance du Système d'Information), au framework de Zachman et à Praxeme :
- Les zones, îlots et blocs du cadre de l'urbanisation du Système d'Information :
2/11 Projet informatique, passer du moyen âge à l'ère industrielle. Urbanisez pour mieux régner, 1ère partie : les fondations.
- Urbanisation SI : la carte au trésor se dissimule t-elle dans le POS ?
- L'urbanisme des SI et architecture d'entreprise : retour vers le futur
- Architecture d'entreprise : le framework de Zachman pour les nuls
- Urbanisation du Système d'Information vs Architecture d'Entreprise
- PRAXEME, la bonne (méthode) à tout faire ?
- Pour trouver les services logiques, les modèles sémantiques et pragmatiques tu dériveras. (« Praxeme 4ème commandement extrait de la bible de l’aspect logique »).
Dans ces cas, le cadre de contenu fournit une référence utile et un point de départ pour le mapping du contenu TOGAF à d'autres frameworks.
Le cadre de contenu d’architecture de TOGAF utilise 3 catégories pour décrire le type d’entité architecturale dans le contexte d'utilisation : livrable, artefact et bloc de construction.
Livrable
Un livrable est un document de travail qui est contractuellement spécifié et à son tour formellement révisé, approuvé et signé par les parties prenantes.
Les livrables représentent la sortie des projets et les livrables sous forme de documentation sont généralement archivés à la fin d'un projet ou transférés dans un référentiel d'architecture en tant que modèle de référence, standard ou une "photo" à un instant t du paysage architectural.
Artefact
Un artefact est un composant architectural qui décrit un aspect de l'architecture.
Les artefacts sont classés comme des :
- catalogues (listes d'entités),
- matrices (tableau des relations entre les entités),
- diagrammes (modélisations des différents aspects de l'architecture).
Bloc de construction
Un bloc de construction (Buildind Block) représente une composante (potentiellement réutilisable) de la capacité métier, informatique ou architecturale qui peut être combinée avec d'autres blocs de construction pour fournir des architectures et des solutions.
Les blocs de construction peuvent être définis à différents niveaux de détail, en fonction du stade de développement de l'architecture atteint.
Par exemple, à un stade précoce, un bloc de construction peut simplement consister en un nom ou une description de plan.
Plus tard, un bloc de construction peut être décomposé en plusieurs blocs de construction et peut être accompagné d'une spécification complète.
Les blocs de construction peuvent se rapporter à des « architectures » ou à des « solutions ».
Les blocs de construction d'architecture (Architecture Building Blocks ABB) décrivent généralement les capacités requises et définissent les spécifications des blocs de construction de solutions (Solutions Building Blocks SBB). Par exemple, une fonction de service client peut être requise au sein d'une entreprise, soutenue par de nombreux SBB, tels que des processus, des données et des logiciels d'application.
Les blocs de construction de solutions (Solutions Building Blocks SBB) représentent les composants qui seront utilisés pour implémenter la capacité requise. Par exemple, un réseau est un bloc de construction qui peut être décrit à l'aide d'artefacts complémentaires, puis mis à profit pour réaliser des solutions pour l'entreprise.
Exemples de Livrables
Le document "Vision de l'architecture" est un livrable qui documente une description d'architecture.
Ce document contiendra un certain nombre d'artefacts complémentaires qui sont des vues des blocs de construction pertinents pour l'architecture.
Exemples d'Artefacts
- Diagramme BPMN (Business Process Model & Notation) de processus métier
- Diagramme DMN (Decision Model and Notation) des règles métier
- Diagramme de classe UML (Unified Modeling Language) ou diagramme de blocs SysML (System Modeling Language)
- Matrice de correspondances objectifs métier/objectifs SI
- Matrice entre les objectifs stratégiques métier et les processus métier
- ...
Exemples de Blocs de construction
L'artefact diagramme BPMN modélise un bloc de construction correspondant au processus métier décrit, ce même diagramme représente aussi le bloc de construction correspondant aux acteurs impliqués par le processus comme un gestionnaire dans le processus de déclaration d'un décès en prévoyance. Une application est un bloc de construction, ...
Schéma récapitulatif
Le livrable de "Définition de l'architecture" inclue des artefacts comme une liste des exigences, une matrice de correspondances objectifs métier/objectifs SI et un diagramme de cas d'utilisation. Un livrable architectural peut contenir de nombreux artefacts qui formeront le contenu du référentiel d'architecture.
Conclusion
Dans TOGAF, un livrables est validé à la fin de chaque phase de la méthode ADM (Architecture Development Method) et est constitué d’artefacts et de blocs de construction.
Les artefacts sont des vues spécifiques de l’architecture comme des modèles, des listes ou des matrices.
Comme dans l’urbanisation des Systèmes d’Information, on retrouve le composant fondamental, le bloc appelé dans TOGAF « bloc de construction ».
Tous ces éléments sont rigoureusement définis dans un métamodèle comme dans tout cadre qui se respecte, c'est ce que nous verrons au cours d'une prochaine aventure.
Rhona Maxwel
@rhona_helena
"L'enthousiasme est à la base de tout progrès."
Henry Ford
Articles conseillés :
SysML : éléments de base - le diagramme de bloc (block definition diagram)
La vision dynamique des exigences de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
Avec TOGAF, les exigences peuvent changer tout au long des phases ADM.
Un nombre important de facteurs externes ou internes peuvent impacter les exigences durant le projet : les lois changent, la concurrence est de plus en plus agressive, les utilisateurs ne savent pas ce qu’ils veulent, des nouvelles technologies apparaissent à des fréquences de plus en plus réduites …
La solution est d’itérer le processus et d’intégrer à chaque nouvelle itération, la gestion des exigences et étudier s’il y des changements.
Pour en savoir plus sur système itératif ADM de TOGAF :
et l’article sur la phase H concernant la gestion des changements dans TOGAF
TOGAF avec la méthode ADM reprend toutes les bonnes pratiques bien connues.
Une exigence peut spécifier une fonction qu'un système doit exécuter ou des critères de performance à atteindre.
On pourra ainsi réutiliser des exigences dans d'autres produits ou projets.
Les scénarios typiques sont des exigences réglementaires, statutaires, ou contractuelles applicables à des produits et à des projets.
On doit pouvoir faire référence à une exigence qui peut donc se trouver dans des contextes multiples ou bien mettre à jour l'exigence d'origine et propager les modifications aux exigence réutilisées.
Si TOGAF n’impose aucune technique ni méthode de gestion d’exigences, il est fortement recommandé d’en prendre et de les adapter.
Vous trouverez dans la suite, des articles, qui vous aideront dans vos choix, sachant qu’ils sont le fruit de mes retours d’expérience.
Comment identifier les besoins ?
Expression des besoins : Techniques pour recueillir les besoins
Expression des besoins : Posez des questions efficacement
Expression des besoins : Soyez efficient dans l'organisation de vos groupes de travail !
Apprendre à modéliser les exigences avec SysML
SysML : le diagramme d'exigence (requirement diagram)
SysML : exemples de diagramme d'exigence tout droit sortie de la norme de l'OMG
SysML : le diagramme de cas d'utilisation (use case diagram)
SysML : les use case "top level" et opérationnels (tutorial SysML partie 4)
SysML pour les nuls : de la modélisation des exigences à la réalisation du système
Mettre en pratique une méthode efficace pour modéliser les exigences
SysML : la méthode, les exemples et l'étude de cas dont vous rêviez
SysML : les bonnes pratiques - les étapes pour une modélisation efficace
Comment modéliser vos processus métier avec BPMN (Business Process Model & Notation) ?
Comment mettre en place un jeu de rôles pour modéliser un processus métier ?
BPMN : l'antisèche pour rester incollable en modélisation de processus
BPMN l’exemple type pour tout comprendre sans prendre d’aspirine
BPMN : la norme, toute la norme rien que la norme. L'exemple à lire en attendant une pizza.
N’oublier pas de modéliser vos règles métier avec la norme DMN (Decision Model Notation) et les relier à vos processus métier
Vous pouvez aussi choisir UML (Unified Modeling Language)
Comment être efficace dans la modélisation de vos cas d'utilisation (UML use case diagram) ?
Notre palmarès des outils
Les meilleurs outils de modélisation UML, SysML, BPMN, DMN de l'année 2016 et les gagnants sont ...
Le gratuit :
Tutoriel Papyrus : vos diagrammes UML 2 comme à l'époque des manuscrits de l'antiquité !
Le payant (très cher !) :
Expression des besoins : modélisation des exigences avec le "mega extra super" AGL MEGA
Et une petite méthode exotique pour ceux qui aiment :
Ingénierie Dirigée par les Modèles : l'orienté but avec KAOS
Conclusion
Les exigences doivent être rédigées sous la forme « sujet, verbe, complément ».
L’exigence classique du type : « l’adhérent à la mutuelle peut consulter ses remboursements de soins en ligne à tout moment », cache en réalité une exigence fonctionnelle : « l’adhérent à la mutuelle peut consulter ses remboursements de soins en ligne » et une exigence non fonctionnelle « une consultation de remboursement peut être faite à tout moment ».
Les exigences sont rédigées bien sûr par le métier et c’est la responsabilité de l’architecte de faire préciser la formulation des exigences en fonction des impacts potentiels.
Dans le cycle ADM de TOGAF, tout en restant indépendante du domaine considéré, la gestion des exigences s’applique à toutes les phases qui peuvent les analyser et déterminer leurs impacts sur l’architecture.
Avec ces allers-retours, les redondances sont évitées et la cohérence est maintenue.
Les exigences sont rationalisées, hiérarchisées, suivies, possèdent un cycle de vie, des méta informations, …, le tout stocké dans un référentiel spécifique géré par un outil.
À vous de choisir ce que vous voulez utiliser, cela peut être le « Modèle de spécification des exigences de Volere », le langage normalisé SysML, …
Un bon conseil, identifiez les scénarios métiers les plus stratégiques et les plus complexes, simulez grâce à la modélisation ou bien faites réaliser un prototype (POC Proof Of Concept) qui montrera aux sponsors et aux utilisateurs que les projets avancent et qu’ils sont bien alignés avec les objectifs et exigences métiers.
Sinon gare aux dérives.
Rhona Maxwel
@rhona_helena
"Celui qui pose une question est bête cinq minutes, celui qui n’en pose pas l’est toute sa vie."
Proverbe chinois
Articles conseillés :
Les objectifs de la phase H « Gestion de la maintenance et des évolutions » de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
L'objectif d'un processus de gestion des modifications de l'architecture est de s'assurer que l'architecture atteint sa valeur métier cible initiale.
Cela inclut la gestion des modifications de l'architecture de manière cohérente et architecturée.
Il vous faudra donc vous assurez que l'architecture d'entreprise est bien capable de répondre aux exigences actuelles et que son cycle de vie est maintenu.
Ce processus prévoit généralement la surveillance continue telles que les demandes de gouvernance, les nouveaux développements technologiques et les changements dans l'environnement métier.
Lorsque des changements sont identifiés, la gestion du changement déterminera s'il faut initier formellement un nouveau cycle d'évolution de l'architecture.
De plus, le processus de gestion des changements d'architecture vise à établir et à soutenir l'architecture d'entreprise mise en œuvre en tant qu'architecture dynamique ; c'est-à-dire, avoir la flexibilité d'évoluer rapidement en réponse aux changements aussi bien métier que technique.
L'utilisation de l'architecture d'entreprise est la partie la plus importante du cycle de développement de l'architecture.
Trop souvent, l'entreprise s'est retrouvée avec une architecture d'entreprise qui fonctionne pour l'organisation d'hier, mais ne peut pas redonner une capacité suffisante pour répondre aux besoins de l'entreprise d'aujourd'hui et de demain.
Dans de nombreux cas, l'architecture continue à s'adapter, mais les solutions sous-jacentes peuvent ne pas l'être, et certains changements sont nécessaires.
L'architecte d'entreprise doit être consciente de ces exigences de changement et considère cela comme une partie essentielle du renouvellement constant de l'architecture.
La mesure de la capacité et des recommandations pour la planification est un aspect clé de cette phase.
Bien que l'architecture ait été conçue pour fournir une architecture d'entreprise stable avec une capacité déterminée pendant le cycle de vie, la croissance ou la baisse de l'utilisation doit être continuellement évaluée pour garantir une valeur métier maximale.
Le processus de gestion de la valeur et du changement, une fois établi, détermine :
- Les circonstances dans lesquelles l'architecture de l'entreprise, ou des parties de celle-ci, seront autorisées à changer après le déploiement, et le processus par lequel cela se produira
- Les circonstances dans lesquelles le cycle de développement de l'architecture sera à nouveau initié pour développer une nouvelle architecture
Le processus de gestion des modifications d'architecture est très étroitement lié aux processus de gouvernance de l'architecture de l'entreprise et à la gestion du contrat d'architecture entre la fonction d'architecture et les utilisateurs métier de l'entreprise.
Un rapport de conformité d'architecture doit indiquer si la modification est conforme à l'architecture actuelle. Si elle n'est pas conforme, une dérogation peut être accordée avec une justification valable. Si le changement a un impact important sur l'architecture, alors une stratégie pour gérer son impact devrait être définie.
Les directives pour établir ces critères sont difficiles à prescrire, car de nombreuses entreprises acceptent le risque différemment, mais au fur et à mesure que le niveau de maturité de la gouvernance s'améliore, les critères deviennent clairs pour des besoins spécifiques.
L'architecture est pilotée par le changement
L'objectif principal du développement de l'architecture d'entreprise à ce jour a été la direction stratégique et l'architecture descendante ainsi que la génération de projets pour atteindre les capacités de l'entreprise.
Cependant, l'architecture d'entreprise ne fonctionne pas dans le vide. Il existe généralement une infrastructure et des activités existantes qui fournissent déjà de la valeur.
Il y a aussi probablement des moteurs de changement qui sont souvent ascendants, basés sur la modification de l'infrastructure existante pour améliorer les fonctionnalités.
L'architecture d'entreprise modifie ce paradigme par une approche descendante stratégique à un degré, bien que la livraison d'incréments rende l'équation plus complexe.
. Changement stratégique dirigé vers le haut pour améliorer ou créer de nouvelles capacités
. Modifications ascendantes pour corriger ou améliorer les capacités (opérations et maintenance) pour la gestion des infrastructures sous gestion des opérations
La gouvernance devra gérer la coordination de ces demandes de changement, et il doit y avoir un processus de retours d’expérience pour permettre de résoudre les problèmes liés aux incréments récemment livrés et de modifier et de planifier les changements apportées aux architectures cibles.
Elles peuvent venir de n'importe où et de n'importe qui et couvrir n'importe quel aspect de l'architecture d'entreprise à n'importe quel niveau (stratégie, définition d'architecture d'entreprise, transition ou projet).
Souvent, un retour d’expérience liée à l'architecture d'entreprise peut être le résultat indirect d'une expérience apprise ailleurs dans l'organisation.
Une RFC est généralement en réponse à des problèmes connus, mais peut également inclure des améliorations. Un défi pour le conseil d'architecture lors du traitement d'un RFC est de déterminer s'il doit être approuvé ou si un projet dans une architecture de transition résoudra le problème.
Lors de l'évaluation de l'intégration d'un projet ou d'une solution dans l'architecture, il peut également se produire lorsqu'une solution innovante ou une RFC entraîne une modification de l'architecture.
En outre, il existe de nombreux facteurs liés à la technologie pour les demandes de changement d'architecture.
Par exemple :
- Nouveaux rapports technologiques
- Réduction des coûts de gestion des actifs
- Retrait de technologie
- Initiatives de normalisation
Ce type de demande de changement est normalement gérable principalement à travers les processus de gouvernance de la gestion des changements et de l'architecture d'une entreprise.
En outre, il existe des facteurs opérationnels pour le changement d'architecture, notamment :
- Les développements du métier
- Exceptions métiers
- Innovations commerciales
- Innovations technologiques d'entreprise
- Changements stratégiques
Ce type de demande de changements entraîne souvent un redéveloppement complet de l'architecture, ou au moins une itération d'une partie du cycle de développement de l'architecture, comme expliqué ci-dessous.
Le processus de gestion du changement d'architecture d'entreprise
Le processus de gestion des modifications de l'architecture d'entreprise doit déterminer comment les modifications doivent être gérées, quelles techniques doivent être appliquées et quelles méthodologies sont utilisées.
Par exemple, les modifications qui affectent uniquement la migration peuvent ne présenter aucun intérêt pour les phases de développement de l'architecture.
Il existe de nombreuses approches valables pour la gestion du changement, et diverses techniques et méthodologies de gestion pouvant être utilisées pour gérer le changement.
Par exemple des méthodes de :
- gestion de projet telles que PRINCE2,
- gestion de service telles que ITIL,
- conseil en gestion telles que Catalyst, ...
Une entreprise qui a déjà mis en place un processus de gestion des changements dans un domaine autre que l'architecture (par exemple, dans le développement de systèmes ou la gestion de projet) peut très bien être capable de l'adapter à l'architecture.
L'approche est basée sur la classification des changements architecturaux requis dans l'une des trois catégories suivantes :
- Changement de simplification : un changement de simplification peut normalement être géré via des techniques de gestion du changement.
- Changement incrémental : un changement incrémentiel peut être géré par des techniques de gestion du changement, ou il peut nécessiter une réorganisation partielle, en fonction de la nature du changement.
- Réorganisation du changement : Un changement de réarchitecture nécessite de remettre toute l'architecture dans le cycle de développement de l'architecture.
Pour déterminer si une modification est une simplification, une incrémentation ou une réarchitecture, les activités suivantes sont entreprises :
- Enregistrement de tous les événements pouvant affecter l'architecture
- Allocation et gestion des ressources pour les tâches d'architecture
- Le processus ou le rôle responsable des ressources d'architecture doit évaluer ce qui doit être fait
- Évaluation des impacts
Vous pouvez appliquer la règle suivante :
- Si le changement a une incidence sur deux parties prenantes ou plus, il est probable qu'il nécessitera une refonte de l'architecture et une réentrée à l'ADM.
- Si le changement n'a d'impact que sur un acteur, il est plus susceptible d'être candidat à la gestion du changement.
- Si le changement peut être autorisé dans le cadre d'une dispense, il est plus susceptible d'être candidat à la gestion du changement.
. Si l'impact est significatif pour la stratégie d'entreprise, il peut s'avérer nécessaire de refaire toute l'architecture de l'entreprise, ce qui implique une approche de réarchitecture.
. Si une nouvelle technologie ou de nouvelles normes émergent, alors il peut être nécessaire d'actualiser l'architecture technologique, mais pas toute l'architecture de l'entreprise - donc un changement incrémental.
. Si le changement est au niveau de l'infrastructure - par exemple, dix systèmes réduits ou modifiés en un seul système - cela ne changera peut-être pas l'architecture au-dessus de la couche physique, mais cela modifiera la description de base de l'architecture technologique. Ce serait un changement de simplification géré via des techniques de gestion du changement.
. Les fondements de l’architecture doivent être réorientée avec la stratégie métier.
. Des changements substantiels sont requis pour les composants et les directives à utiliser dans le déploiement de l'architecture.
. Les normes importantes utilisées dans l'architecture du produit sont modifiées, ce qui a un impact significatif sur l'utilisateur final ; par exemple, des changements réglementaires.
Si un cycle de rafraîchissement est nécessaire, une nouvelle demande d’étude d'architecture doit être émise (pour passer à un autre cycle).
Conclusion
Les étapes de la phase H sont les suivantes :
- Établissement du processus de réalisation de la valeur
- Déployer les outils de surveillance
- Gérer les risques
- Fournir une analyse pour la gestion du changement d'architecture
- Développer les exigences de modification pour atteindre les objectifs de performance
- Gérer le processus de gouvernance
- Activer le processus pour implémenter le changement
Rhona Maxwel
@rhona_helena
"Nous commençons à vieillir quand nous remplaçons nos rêves par des regrets."
Sénèque
Articles conseillés :
Comment mettre en œuvre la phase G Gouvernance de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
La Phase G Gouvernance de la mise œuvre a pour objectifs :
-
Assurer la conformité avec l'architecture cible par l'implémentation de projets .
-
Exécuter les fonctions de gouvernance d'architecture appropriées pour la solution de l’architecture mise en œuvre.
C'est ici que toutes les informations pour une gestion réussie des différents projets de mise en œuvre sont réunies.
Il y a l'exécution d'un processus de développement spécifique à l'organisation, où le développement réel se produit.
Chaque transition représente une étape incrémentielle vers la cible, et chacune apporte un avantage métier à part entière.
Approche globale de la phase G
Par conséquent, l'approche globale de la phase G consiste à :
- Établir un programme de mise en œuvre qui permettra la livraison des architectures de transition convenues pour la mise en œuvre pendant la phase de planification de la migration
- Adopter un calendrier de déploiement échelonné qui reflète les priorités opérationnelles incorporées dans la feuille de route de l'architecture
- Suivre les normes de l'organisation en matière de gouvernance d'entreprise, informatique et d'architecture
- Utiliser l'approche de gestion de portefeuille établie par l'organisation, lorsque celle-ci existe
- Définir un cadre d'opérations pour assurer la longévité effective de la solution déployée
La phase G établit le lien entre l'architecture et l'organisation de la mise en œuvre, à travers le contrat d'architecture.
Les détails du projet
Les détails du projet sont développés, y compris :
- Nom, description et objectifs
- Portée, livrables et contraintes
- Mesures d'efficacité
- Critères d'acceptation
- Risques et problèmes
Le niveau de détail abordé dans la phase G dépend de la portée et des objectifs de l'effort global d'architecture.
Les étapes de la phase G
L'ordre des étapes de la phase G ainsi que la date à laquelle elles sont formellement commencées et complétées doit être adapté à la situation en cours, conformément à la gouvernance de l'architecture établie.
. Confirmer la portée et les priorités du déploiement avec ADM
. Identifier les ressources de déploiement et les compétences
. Rédiger le Guide Développement de déploiement de solutions
. Effectuer des examens de conformité de l'architecture d'entreprise
. Mettre en œuvre des opérations commerciales et informatiques
. Effectuer un examen après la mise en œuvre et fermer la mise en œuvre
Conclusion
Les entreprises misent de plus en plus sur l’amélioration de la productivité avec de nouvelles applications, et celles-ci sont de plus en plus contextualisées ou réactives aux évènements.
Pour avoir une gestion dynamique des processus métier, il faut une gouvernance BPM adaptée, ce qui implique obligatoirement une architecture d’entreprise efficiente avec bien sûr sa propre gouvernance.
Rhona Maxwel
@rhona_helena
"Vivre sans espoir, c’est cesser de vivre."
Fedor Mikhaïlovitch Dostoïevski
Articles conseillés :
Les règles de l'urbanisme du Système d'Information : encore une contrainte de technocrates ?
Mais dans la vrai vie, qu'est ce qu'il y a dans les règles d'urbanisme du Système d'Information ?
Les règles d'urbanisme du SI : maîtriser les échanges inter-applications
Édicter des règles d'urbanisme du SI c'est bien, les faire appliquer c'est encore mieux.
Comment mettre en œuvre la phase F Planning de migration de la méthode ADM (Architecture Development Method) de l’architecture d’entreprise TOGAF (The Open Group Architecture Framework)
Cette phase consiste à :
-
Finaliser la feuille de route de l'architecture et le plan de mise en œuvre et de migration.
-
S’assurer que le plan de mise en œuvre et de migration est coordonné avec l'approche de l'entreprise en matière de gestion et de mise en œuvre des changements dans le portefeuille global des changements de l'entreprise.
-
Vérifier que la valeur métier et le coût des lots de travaux et des architectures de transition sont compris par les principales parties prenantes.
La phase E fournit une feuille de route d'architecture incomplète et un plan de mise en œuvre et de migration qui répondent à la demande de travail d'architecture.
Au cours de la phase F, cette feuille de route et le plan de mise en œuvre et de migration sont intégrés aux autres activités de changements de l'entreprise.
Les activités comprennent l'évaluation des dépendances, des coûts et des avantages des divers projets de migration.
La feuille de route de l'architecture, version 0.1 et le plan de mise en œuvre et de migration, version 0.1 de la phase E formeront la base du plan final de mise en œuvre et de migration.
Le niveau de détail de la phase F dépendra de la portée et des objectifs de l'effort global d'architecture.
L'ordre des étapes de la phase F ainsi que la date à laquelle elles sont formellement commencées et complétées doivent être adaptées à la situation en cours, conformément à la gouvernance de l'architecture établie.
Les étapes de la phase F :
- Confirmer les interactions du cadre de gestion pour le plan de mise en œuvre et de migration
- Affecter une valeur métier à chaque lot de travaux
- Estimer les besoins en ressources, les délais du projet, les disponibilités et la livraison
- Donner la priorité aux projets de migration par la conduite d'une évaluation coûts-avantages et d'une validation des risques
- Confirmer la feuille de route de l'architecture et le document de définition de l'architecture de mise à jour
- Générer le plan de mise en œuvre et de migration
- Terminer le cycle de développement de l'architecture et documenter les retours d'expérience
Rhona Maxwel
@rhona_helena
"Une demi-heure de méditation est essentielle sauf quand on est très occupé.
Alors une heure est nécessaire."
Saint François de Sales
Articles conseillés :
Comment mettre en œuvre la phase E Opportunités et Solutions de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)
La phase E d’ADM de TOGAF a pour but de générer la version complète initiale de la feuille de route de l'architecture, en fonction de l'analyse des écarts et des composants de la feuille de route de l'architecture candidate des phases B, C et D et de déterminer si une approche incrémentale est requise et, si c'est le cas, identifier les architectures de transition qui fourniront une plus-value métier en continue.
La phase E se concentre sur la façon de livrer l'architecture.
Elle prend en compte l'ensemble complet des écarts entre les architectures cible et initiale dans tous les domaines d'architecture et regroupe logiquement les changements dans les lots de travaux des portefeuilles de l'entreprise.
Il s'agit d'un effort visant à élaborer une feuille de route adaptée aux besoins des parties prenantes, à la préparation opérationnelle de l'entreprise, aux opportunités et solutions identifiées et aux contraintes d'implémentation identifiées.
La phase E est l'étape initiale de la création du plan de mise en œuvre et de migration qui est achevé dans la phase F.
Les pointst essentiels pour passer du développement à la livraison d'une architecture cible :
- Feuille de route d'architecture
- Architectures de transition
- Plan de mise en œuvre et de migration
La feuille de route d'architecture répertorie les lots de tâches à effectuer dans un scénario qui réalisera l'architecture cible.
Chaque lot de tâches identifie un groupe logique de modifications nécessaires pour réaliser l'architecture cible.
Les architectures de transition fournissent des architectures cibles intermédiaires sur lesquelles l'organisation peut converger.
C'est ce plan de mise en œuvre et de migration qui fournira un calendrier des projets qui réaliseront l'architecture cible.
Rhona Maxwel
@rhona_helena
"Le moment donné par le hasard vaut mieux que le moment choisi."
Proverbe chinois
Articles conseillés :
Comment mettre en œuvre la phase C Système d’Information et la phase D Technique de la méthode ADM (Architecture Development Method) du framework d’Architecture d’Entreprise TOGAF (The Open Group Architecture Framework)
La phase C doit mettre en place l’implémentation et l’exécution des constituants métier indépendamment de la phase D technique qui doit établir la correspondance physique et technologique avec les composants des phases précédentes.
Phase C Système d’Information
La phase C est divisée en 2 : l’architecture des données et l’architecture applicative.
On retrouve les mêmes principes des autres méthodes d’architecture d’entreprise comme l’urbanisation du Système d’Information ou Praxeme qui sont :
- d’avoir une interface entre la couche métier et la couche technique, indépendante de celle ci, ce rôle est joué par la phase C.
- de faire correspondre à chaque bloc de données un bloc applicatif qui en est l’unique propriétaire et qui est le seul à pouvoir les modifier.
Phase D technique
L’objectif de la phase D est d’avoir une infrastructure et des composants logiciels cohérents qu’ils proviennent de progiciels du commerce, d’ERP ou bien de développement maison.
Ce choix capital se pose à maintes reprises aux architectes des grandes organisations.
Combien se sont lancés dans des développements spécifiques pour s’apercevoir qu’ils réinventaient la roue, puis de tout arrêter pendant qu’il était encore temps pour à la fin adopter un progiciel du commerce paramétrable suivant leurs besoins quitte à les implémenter eux mêmes ou par l'éditeur dans le cas où ils n'existaient pas.
On retrouve les concepts de l’architecture SOA (Service Oriented Architecture).
La phase C est comparable à l’interface logique de service qui est la structure fondamentale du composant et qui reste inchangée quel que soit son implémentation en C, Java, SOAP, REST, … qui relève bien de la phase D.
L’important est de pouvoir identifier le rôle de chaque composant indépendamment des technologies employées pour leur exécution.
Encore une fois comme dans l’urbanisation du SI, il n’y a pas d’ordre préconisé, on peut appliquer une méthode top down c’est-à-dire commencer par spécifier l’architecture applicative puis technique ou faire l’inverse avec la méthode bottom-up.
Ce dilemme cornélien se solde par un mixte des 2 méthodes.
Les articles à venir seront bien évidemment consacrés aux phase E Opportunités et Solutions, F Planning de migration, G Gouvernance de la mise œuvre, H Gestion de la maintenance et des évolutions et enfin à la vision dynamique des exigences.
Rhona Maxwel
@rhona_helena
"La vraie faute est celle qu’on ne corrige pas."
Confucius
Articles conseillés :