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 :
Comment mettre en œuvre la phase B Métier de la méthode ADM (Architecture Development Method) du framework d’Architecture d’Entreprise TOGAF (The Open Group Architecture Framework)
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.
Par exemple, une optimisation ou carrément l’apparition d’un nouveau processus métier est décrite dans cette phase et montre les changements dans le travail des acteurs, dans les flux d’informations échangés et dans les services métiers.
La phase B métier est modélisée comme toutes les autres phases suivant les points de vue des acteurs c’est-à-dire en fonction des sujets qui les intéressent et de leur niveau d’affinement.
Le document de sortie de la phase B Métier est le document de "définition de l’architecture" qui est complété par chacune des phases en fonction du domaine qui la concerne.
Le document est validé avant les phase E Opportunités et Solutions et F Planning de migration.
Au début de la phase B Métier, comme indiquée dans la « check list », on consulte le référentiel à des fins de réutilisabilité des travaux précédents et de conformité aux règles édictées.
Bien sûr, ceci est commun à chaque phase.
Une autre chose commune à toutes les phases, c’est d’évaluer les impacts de manière transverse au-delà de ses frontières pour éviter les effets de bords imprévus par exemple sur des projets en cours.
Les phases B, C et D décrivent le document « Spécifications des exigences d’architecture » qui est livré en sortie de chaque phase.
Le but est de décrire en détail ce qui sera réalisé dans l’architecture cible.
Comme dans tous les projets, on spécifie les exigences fonctionnelles sans oublier les non fonctionnelles qui impactent les solutions en termes de faisabilité.
La phase B Métier a donc pour objet :
- Les entités métier c’est les concepts cœur du métier et qui sont la base de la phase C Système d’Information
- Les processus métier, rouages centraux de l’efficience de l’entreprise et donc la base de l’architecture d’entreprise
- Les buts stratégiques et opérationnels
- L’organisation
- Les acteurs métier et leurs rôles
Rhona Maxwel
@rhona_helena
"Ce qui est passé a fui ; ce que tu espères est absent ; mais le présent est à toi."
Proverbe arabe
Articles conseillés :
La phase A Vision du cycle de la méthode ADM (Architecture Development Method) de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)
Elle a pour but :
. de développer les éléments de la phase préliminaire comme le planning d’élaboration, les indicateurs clés, les concepts d’architecture et l’organisation.
. de préparer les phases suivantes avec des modélisations globales de haut niveau non détaillées des architectures initiale et cible avec les principales solutions.
Vous trouverez un condensé de TOGAF et le fonctionnement itératif d'ADM dans mes précédents articles :
- TOGAF pour les nuls.
- Le processus des itérations ADM (Architecture Development Method), le moteur de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)
La perspective est horizontale (métier, système et technique) alors que les autres phases se situent de manière verticale en ne couvrant qu’un seul domaine.
La phase A Vision commence par la validation du document « demande de mise en chantier de l’architecture (Request for Architecture Work) » de la phase préliminaire.
Elle se termine par le document « Vision de l’architecture » qui est validé.
Ce document contient :
- 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
Que du classique, comme pour tout projet, il faut connaître les sponsors, les décideurs, les frontières, les buts, le calendrier, les coûts, les ressources et les risques.
Logiquement, la phase suivante B Architecture Métier sera l'objet du prochain épisode.
Rhona Maxwel
@rhona_helena
"Vieillir n’est, au fond, pas autre chose que n’avoir plus peur de son passé."
Stefan Zweig
Articles conseillés :
Quelques raisons de l'échec des projets informatiques
Comment identifier, simuler, améliorer et modéliser les processus métiers ?
Comment mettre en place un jeux de rôles pour modéliser un processus métier ?
Le processus des itérations ADM (Architecture Development Method), le moteur de la transformation d’entreprise TOGAF (The Open Group Architecture Framework)
Le processus itératif est le meilleur moyen pour parvenir à ses objectifs c’est-à-dire la transformation de l’architecture d’entreprise pour avoir une vision globale des aspects stratégiques, métiers, organisationnels et pour maîtriser l’alignement entre le métier et la technique, clé d’un Système d’Information agile.
Ce concept d’itération a été traité dans nos différents articles consacrés aux méthodes de développement d’application comme UP (Unified Process ou RUP Rational Unified Process ou encore 2TUP 2 Tracks Unified Process).
Du reste tous les concepts qui suivent comme la phase préliminaire, la vision, les parties prenantes, leurs rôles, le périmètre, le plan de développement, les risques, … se trouve dans UP et dans les autres méthodes comme l'urbanisation du Système d'Information, Praxeme, ....
Voici quelques articles que nous avions consacré à la méthode UP et à la méthode de modélisation des besoins avec l'outil UML :
- Modélisation des besoins : qu'est ce je dois faire et ne pas faire ?
- Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 1ère partie - Vue globale
La documentation de la méthode ADM se trouve dans la parties II les bonnes pratiques dans la III.
En ce qui oncerne TOGAF nous retrouvons le fameuse étoile représentant le cycle des différentes phases de la méthode ADM :
TOGAF conseille d’avoir 4 cycles de plusieurs itérations où chaque itération regroupe les phases suivantes :
- Itération de contexte, composé des phases « préliminaire » et « A Vision »
- Itération de définition de l’architecture, composé des phases « B Métier », « C Système d’Information », « D Technique »
- Itération de transition et de planning, composé des phases « E Opportunités et Solutions », « F Planning de migration »
- Itération de gouvernance, composé des phases « G Gouvernance de la mise en œuvre », « H Gestion de la maintenance et des évolutions »
- Phase A Vision
- Itération 1 « B Métier 1 », « C Système d’Information 1 », « D Technique 1 »
- Itération 2 « B Métier 2 », « C Système d’Information 2 », « D Technique 2 »
- Itération 3 « B Métier 3 », « C Système d’Information 3 », « D Technique 3 »
- Itération 1 « E Opportunités et Solutions 1 », « F Planning de migration 1 »
- Itération 2 « E Opportunités et Solutions 2 », « F Planning de migration 2 »
- …
Dans un contexte de refonte du Système d’Information (cas d’une fusion, très fréquent par les temps qui courent), où on doit concevoir des solutions dans un laps de temps réduit, il est conseillé que la 1ère itération de définition (« B Métier 1 », « C Système d’Information 1 », « D Technique 1 ») se concentre sur l’architecture cible et ensuite dans la 2ème itération insister sur l’architecture existante.
Mais comme on l’a dit au début de cet article, il faut s’adapter au contexte.
En fonction de la situation, on peut aussi prendre parti pour une planification opposée de la précédente, c’est-à-dire la 1ère itération de définition (« B Métier 1 », « C Système d’Information 1 », « D Technique 1 ») se concentre sur l’architecture existante et ensuite dans la 2ème itération insister sur l’architecture cible.
La phase préliminaire
Le but est de mettre l’organisation en capacité de maîtriser la gestion et les transformations de son architecture et de préparer le déclenchement d’un cycle ADM avec le procès-verbal de démarrage : « demande de mise ne chantier de l’architecture (Request for Architecture Work) ».
Cette phase de ne fait pas partie du cycle ADM.
Les questions « où, quoi, pourquoi, qui et comment » trouvent réponses dans ce document spécifiant entre autres les objectifs stratégiques, les sponsors, les moyens financiers, les contraintes, …
TOGAF spécifie une approche itérative par incrément commune aux autres méthodes comme l’urbanisation des Système d’Information, Praxeme, …
Ce concept permet de ne pas figer les entrées qui peuvent évoluer selon des évènements externes ou internes.
La progression par itération permet de prendre en compte le plus tôt possible les contraintes de tout ordre.
Les prochains articles seront consacrés à une synthèse des différentes phases du cycle de la méthode ADM.
Rhona Maxwel
@rhona_helena
"Autrui, c’est ce moi-même dont rien ne me sépare, absolument rien si ce n’est sa pure et totale liberté …"
Jean-Paul Sartre
Articles conseillés :
Recette d'une bonne urbanisation du SI
L'urbanisation du SI, ne perdez pas les clés du succès !
L’élaboration du Cahier de Recette
Modélisation des besoins : qu'est ce je dois faire et ne pas faire ?
Urbanisation SI : la méthode ultime pour modéliser les besoins d'un projet - 1ère partie - Vue globale