Les techniques de planification de migration dans TOGAF offrent une approche structurée pour évaluer et planifier la mise en œuvre et la migration de l’architecture d’entreprise. En utilisant ces techniques, les architectes peuvent s’assurer que les plans sont complets et alignés sur les objectifs commerciaux, tout en tenant compte des contraintes et des dépendances pouvant impacter la mise en œuvre.
Chaque technique a un objectif spécifique et peut être utilisée à différentes phases du processus de planification de migration. Par exemple, la matrice d’évaluation et de déduction des facteurs de mise en œuvre peut aider à identifier et à documenter les facteurs influant sur la mise en œuvre, tandis que la technique d’évaluation de la valeur commerciale peut aider à évaluer la valeur et les risques associés à différentes options.
En combinant ces techniques, les architectes peuvent élaborer un plan de migration global qui prend en compte tous les facteurs pertinents et garantit une mise en œuvre réussie de l’architecture d’entreprise.
Matrice d’évaluation et de déduction des facteurs de mise en œuvre TOGAF ADM
La matrice d’évaluation et de déduction des facteurs de mise en œuvre TOGAF ADM est un outil utilisé pour identifier et évaluer les facteurs pouvant impacter la mise en œuvre d’un plan d’architecture d’entreprise. La matrice comprend généralement trois colonnes, à savoir :
- Facteur : Cette colonne liste les différents facteurs pouvant affecter la mise en œuvre du plan d’architecture. Ces facteurs peuvent inclure les Risques, les Problèmes, les Hypothèses, les Dépendances, les Actions, les Impacts ou tout autre facteur pertinent.
- Description : Cette colonne fournit une brève description de chaque facteur, expliquant ce qu’il est et pourquoi il est important de le prendre en compte lors de la formulation du plan.
- Deductions : Cette colonne énumère les déductions à faire en fonction de chaque facteur. Ces déductions indiquent les actions ou contraintes à prendre en compte lors de la conception du plan de mise en œuvre.
Par exemple, supposons qu’un des facteurs répertoriés dans la matrice soit « Risques ». Dans la colonne de description, ce facteur pourrait être défini comme « événements ou situations négatifs potentiels pouvant impacter le succès du plan de mise en œuvre ». Dans la colonne des déductions, la matrice pourrait indiquer que tous les risques identifiés doivent être évalués et prioritaires, et que des stratégies appropriées de mitigation des risques doivent être mises en place.
Dans l’ensemble, la matrice d’évaluation et de déduction des facteurs de mise en œuvre est un outil utile pour s’assurer que tous les facteurs pertinents sont pris en compte lors de la conception d’un plan de mise en œuvre, et que des actions appropriées sont prises pour résoudre tout problème ou contrainte potentiel.
—
Voici une possible révision de la matrice basée sur le passage au messagerie instantanée :
| Facteur | Description | Deductions |
|---|---|---|
| Changement de technologie | ||
| Fermeture des centres de messagerie | Décision de fermer les centres de messagerie et de passer à la messagerie instantanée comme canal de communication principal |
|
| Personnel | Les personnes impliquées dans la mise en œuvre du plan et/ou touchées par les changements |
|
| Messagerie instantanée | La nouvelle technologie introduite dans le cadre du plan de mise en œuvre |
|
| Coût | Les implications financières du plan de mise en œuvre |
|
Encore une fois, il s’agit simplement d’une des façons possibles de régénérer la matrice sur la base de la technologie mise à jour, et les facteurs, descriptions et déductions réels utilisés dans la matrice dépendront du scénario d’affaires spécifique traité.
Matrice consolidée des écarts, des solutions et des dépendances
La matrice consolidée des écarts, des solutions et des dépendances est une technique utilisée dans le processus de développement d’architecture TOGAF pour identifier et regrouper les écarts dans le domaine d’architecture, évaluer les solutions potentielles et les dépendances liées à ces écarts.
Cette technique aide les architectes à prioriser leurs tâches et à identifier les domaines où les solutions peuvent avoir l’impact le plus important. En regroupant les écarts, les architectes peuvent mieux comprendre les relations entre eux et identifier des solutions qui traitent plusieurs écarts simultanément.
La matrice est également utile pour planifier et créer des paquets de travail. Les dépendances identifiées peuvent aider à piloter la création de projets et à informer la planification de migration dans les phases E et F du processus de développement d’architecture. Cela garantit que les projets sont correctement priorisés et alignés sur les objectifs commerciaux.
Dans l’ensemble, la matrice consolidée des écarts, des solutions et des dépendances est un outil précieux pour les architectes à utiliser tout au long du processus de développement d’architecture, leur permettant d’identifier les écarts, les solutions et les dépendances, de prioriser leurs tâches et de piloter une planification et une exécution de projet efficaces.
Exemple
Voici un exemple de la manière dont la matrice consolidée des écarts, des solutions et des dépendances pourrait être utilisée :
Supposons que, pendant la phase d’analyse des écarts du processus de développement d’architecture, l’équipe d’architecture a identifié plusieurs écarts dans l’architecture actuelle. Ces écarts incluent :
- Absence d’un référentiel centralisé de données clients
- Définitions de données incohérentes entre les unités commerciales
- Intégration limitée entre les systèmes CRM et de traitement des commandes
Pour créer une matrice consolidée des écarts, des solutions et des dépendances, l’équipe d’architecture regrouperait ces écarts et évaluerait les solutions potentielles et les dépendances. Par exemple :
Voici à nouveau l’exemple, avec des numéros ajoutés dans la première colonne :
| # | Écart | Solutions potentielles | Dépendances |
|---|---|---|---|
| 1 | Absence d’un référentiel centralisé de données clients | Mettre en place un data lake pour les données clients | Dépend de la résolution des définitions de données incohérentes |
| 2 | Définitions de données incohérentes entre les unités commerciales | Établir un cadre de gouvernance des données et un modèle de données commun | Dépend de la mise en œuvre d’un lac de données |
| 3 | Intégration limitée entre les systèmes CRM et de traitement des commandes | Mettre en œuvre un bus de services d’entreprise (ESB) pour permettre l’échange de données en temps réel | Dépend de la mise en œuvre d’un cadre de gouvernance des données et d’un modèle de données commun |
Dans cet exemple, la matrice montre qu’il est nécessaire d’adopter une approche en plusieurs étapes pour combler les lacunes relatives aux données clients, en passant par la résolution des incohérences de données, la mise en œuvre d’un lac de données, l’établissement d’un cadre de gouvernance des données et d’un modèle de données commun, puis enfin la mise en œuvre d’un ESB pour permettre l’échange de données en temps réel.
Cette matrice peut être utilisée pour planifier les paquets de travail, identifier les dépendances et prioriser les projets dans les phases E et F. Par exemple, l’équipe d’architecture pourrait privilégier la mise en œuvre du cadre de gouvernance des données et du modèle de données commun comme première étape pour combler les lacunes identifiées, car il s’agit d’une dépendance pour la mise en œuvre du lac de données et de l’ESB.
Tableau des incréments de définition de l’architecture
Le tableau des incréments de définition de l’architecture est une technique utilisée dans le cadre d’architecture The Open Group (TOGAF) qui permet aux architectes de planifier et de suivre le développement d’une architecture d’entreprise au fil du temps. Le tableau liste les différents projets qui contribueront au développement de l’architecture, et attribue à chaque projet des livrables spécifiques qui seront réalisés par incréments au fil du temps.
Le but de ce tableau est de créer une feuille de route qui décrit la séquence prévue des architectures de transition, qui sont des états intermédiaires de l’architecture atteints à des moments précis durant le processus de développement. Chaque architecture de transition représente une étape de l’architecture plus complète et plus proche de l’état final que l’étape précédente.
En divisant le processus de développement en livrables incrémentaux et en les attribuant à des projets et des délais spécifiques, le tableau des incréments de définition de l’architecture aide les architectes à :
- Planifier le développement de l’architecture d’entreprise de manière structurée et maîtrisée
- S’assurer que chaque projet est correctement séquencé et que chaque incrément est achevé dans les délais
- Identifier les dépendances potentielles et les conflits entre différents projets
- Fournir une vue d’ensemble claire du processus de développement, qui peut être partagée avec les parties prenantes afin de s’assurer que tous sont alignés sur les objectifs et le calendrier du projet.
Dans l’ensemble, le tableau des incréments de définition de l’architecture est un outil puissant qui peut aider les architectes à gérer des projets complexes d’architecture d’entreprise et à garantir qu’ils soient menés à bien et terminés dans les délais.
Voici un tableau des incréments de définition de l’architecture mis à jour qui regroupe à la fois les informations sur les incréments et les dates de début :
| Nom du projet | Incident 1 – Date de début | Incident 1 | Incident 2 – Date de début | Incident 2 | Incident 3 – Date de début | Incident 3 | Incident 4 – Date de début | Incident 4 |
|---|---|---|---|---|---|---|---|---|
| Système CRM | T1 2023 | Architecture conceptuelle | Q2 2023 | Architecture logique | Q3 2023 | Architecture physique | Q4 2023 | Système entièrement opérationnel |
| Entrepôt de données | Q1 2023 | Architecture conceptuelle | Q2 2023 | Architecture logique | Q3 2023 | Architecture physique | Q4 2023 | Système entièrement opérationnel |
| Plateforme de commerce électronique | Q2 2023 | Architecture conceptuelle | Q3 2023 | Architecture logique | Q4 2023 | Architecture physique | Q1 2024 | Système entièrement opérationnel |
| Application mobile | Q2 2023 | Architecture conceptuelle | Q3 2023 | Architecture logique | Q4 2023 | Architecture physique | Q1 2024 | Système entièrement opérationnel |
Dans ce tableau mis à jour, chaque projet comporte quatre incrémentations, et chaque incrément a une date de début représentée par un trimestre et une année. Cela permet à l’architecte de planifier une série d’architectures de transition et de suivre les progrès vers la réalisation du système entièrement opérationnel pour chaque projet.
Par exemple, le projet CRM System débute en Q1 2023, et chaque incrément suivant débute au trimestre suivant. Le tableau indique que l’incrément Système entièrement opérationnel est prévu pour Q4 2023. Cela permet à l’architecte de planifier et de suivre les progrès vers la réalisation du système entièrement opérationnel pour le projet CRM System.
De même, le tableau indique les dates de début pour chaque incrément des trois autres projets. Cela aide l’architecte à planifier et à suivre les progrès vers la réalisation du système entièrement opérationnel pour chaque projet, et à identifier d’éventuels conflits ou dépendances entre les différents projets.
Tableau d’évolution de l’état de l’architecture de transition
Le tableau d’évolution de l’état de l’architecture de transition est une technique utilisée dans le cadre d’architecture The Open Group (TOGAF) pour démontrer l’état proposé des architectures d’une organisation à différents niveaux à l’aide d’une taxonomie définie, telle que le Modèle de référence technique (TRM) de TOGAF. Ce tableau est un outil visuel qui aide les architectes à identifier les services de la taxonomie utilisés dans l’entreprise, puis à lister les architectures de transition et les transformations proposées pour ces services.
Le tableau doit inclure une liste de tous les Blocs de construction de solution (SBB) et décrire leur impact et leur contribution aux services mentionnés. Les SBB doivent également être marqués pour montrer leur contribution à l’évolution de l’architecture d’entreprise. Par exemple, si une nouvelle capacité est introduite, elle sera marquée comme « nouvelle » ou « conserver » dans le tableau. Si une capacité est en cours de transition vers une nouvelle solution, elle sera marquée comme « transition ». Et si une capacité est remplacée, elle sera marquée comme « remplacer ».
Le tableau d’évolution de l’état de l’architecture de transition fournit une image claire des changements qui auront lieu dans l’architecture d’une organisation au fil du temps. Il permet aux architectes de voir comment leurs changements proposés affecteront les services de l’organisation et comment ils contribueront à conduire l’organisation vers son état cible. En utilisant ce tableau, les architectes peuvent s’assurer que leurs changements proposés s’alignent sur les objectifs et buts de l’organisation et qu’ils peuvent être mis en œuvre efficacement.
Exemple
Voici un exemple de ce à quoi pourrait ressembler le tableau d’évolution de l’état de l’architecture de transition en fonction des colonnes que vous avez mentionnées :
| Sous-domaine | Service | Architecture de transition 1 | Architecture de transition 2 | Architecture de transition 3 |
|---|---|---|---|---|
| Ventes | Gestion des commandes | État actuel | État de transition | État cible |
| Ventes | Gestion des clients | État actuel | État de transition | État cible |
| Finance | Fournisseurs | État actuel | État de transition | État cible |
| Finance | Clients | État actuel | État de transition | État cible |
| RH | Paie | État actuel | État de transition | État cible |
| RH | Gestion des avantages | État actuel | État de transition | État cible |
Dans cet exemple, la première colonne liste les sous-domaines au sein de l’organisation, tels que les ventes, la finance et les ressources humaines. La deuxième colonne liste les services spécifiques dans chaque sous-domaine, tels que la gestion des commandes, les paiements et la paie. Les colonnes restantes représentent les diverses architectures de transition, qui pourraient inclure l’état actuel, l’état de transition et l’état cible.
Chaque cellule du tableau serait ensuite remplie avec les informations pertinentes pour ce service et cette architecture. Par exemple, la cellule relative à la gestion des commandes et à la colonne de l’état actuel pourrait contenir une description de l’architecture actuelle utilisée pour gérer les commandes, tandis que la cellule relative à la gestion des commandes et à la colonne de l’état cible pourrait décrire l’architecture proposée pour gérer les commandes à l’avenir.
Technique d’évaluation de la valeur métier
La technique d’évaluation de la valeur métier que vous avez décrite est une méthode utile pour évaluer et prioriser diverses initiatives ou projets commerciaux. En utilisant une matrice basée sur les dimensions valeur et risque, les entreprises peuvent évaluer leurs options selon des critères objectifs alignés sur leurs objectifs stratégiques.
La dimension de l’indice de valeur, qui inclut le respect des principes, la contribution financière, l’alignement stratégique et la position concurrentielle, aide à déterminer les bénéfices et opportunités potentiels qu’un projet peut apporter à l’entreprise. La dimension de l’indice de risque, qui inclut la taille et la complexité, la technologie, la capacité organisationnelle et l’impact d’une défaillance, aide à identifier les risques et défis potentiels auxquels un projet pourrait être confronté.
Exemple
En attribuant des poids individuels à chaque critère, les entreprises peuvent déterminer l’importance relative de chaque critère dans le processus de décision. Cela permet de s’assurer que les facteurs les plus critiques reçoivent une plus grande pondération dans l’évaluation.
Enfin, il est important d’établir les critères de décision avant de connaître les options. Cela garantit que le processus d’évaluation reste objectif et cohérent, et que toutes les options sont évaluées selon les mêmes critères. Cela aide également à prévenir les biais et les préférences personnelles d’influencer le processus de décision.
Résumé
Les techniques de planification de migration de TOGAF incluent plusieurs méthodes pour soutenir la planification de migration dans les phases E et F. Ces techniques comprennent la création d’une matrice d’évaluation et de déduction des facteurs d’implémentation pour documenter les facteurs influant sur le plan d’implémentation et de migration de l’architecture, une matrice consolidée des écarts, des solutions et des dépendances pour regrouper les écarts et évaluer les solutions et dépendances potentielles, un tableau des incréments de définition d’architecture pour planifier une série d’architectures de transition, et un tableau d’évolution de l’état des architectures de transition pour montrer l’état proposé des architectures à différents niveaux.
En outre, la technique d’évaluation de la valeur métier consiste à établir une matrice basée sur une dimension de l’indice de valeur et une dimension de l’indice de risque pour évaluer la valeur métier. Il est essentiel de développer et d’obtenir l’approbation de l’indice, de ses critères et de ses pondérations par la direction supérieure avant de définir les critères de décision. En combinant ces techniques, les architectes peuvent élaborer un plan de migration global qui prend en compte tous les facteurs pertinents et assure une mise en œuvre réussie de l’architecture d’entreprise.