2. Conduire une démarche d’architecture d’entreprise

Pour entreprendre une démarche d’architecture d’entreprise, il importe d’établir les éléments essentiels qui la composent. Dans les sections suivantes, on présente la marche à suivre afin d’élaborer une architecture d’entreprise organisationnelle publique en cohérence avec le programme d’Architecture d’Entreprise Gouvernementale du Togo (AEGT).

Figure 26: Schéma de la démarche méthodologique d’archiecture d’entreprise

2.1. Les différentes phases de la démarche d’AE

2.1.1. La phase préliminaire

Cette phase préliminaire consiste à définir « où, quand, pourquoi, qui et comment faire de l’architecture » dans l’entreprise concernée. Elle comporte deux aspects principaux : la définition du cadre à utiliser et la définition des principes d’architecture qui serviront de base à tout travail d’architecture.

L’approche de l’entreprise en matière de réutilisation des actifs architecturaux est un élément clé de la définition du cadre et des principes d’architecture. (En règle générale, les principes énoncent la politique de réutilisation et le cadre explique comment la réutilisation est effectuée).

2.1.1.1. Les principes [1]

Les principes représentent en ce sens un ensemble de lignes directrices qui servent de base à la prise de décision à travers l’organisation et conditionnent le choix des transformations à mener.

Le travail d’architecture s’appuie sur des principes d’entreprise ainsi que sur des principes d’architecture. Pour autant, la phase préliminaire se focalise sur les principes d’architecture. Ils eux-mêmes sont normalement basés en partie sur des principes d’entreprise. La définition de ces principes dépasse normalement le cadre de la fonction d’architecture. Toutefois, selon la manière dont ces principes sont définis et promulgués au sein de l’entreprise concernée, il est possible que l’ensemble des principes d’architecture reprennent ou renvoient à un ensemble de principes, d’objectifs et de moteurs stratégiques définis ailleurs au sein de l’entreprise.

Les cinq caractéristiques d’un bon principe sont les suivantes

Caractéristiques	Descriptions
Intelligible	L’idée de base d’un principe est d’être compris rapidement par n’importe quel acteur de l’organisation. Il doit être clair, non ambigu, ce qui limite les risques de non-respect
Robuste	Chaque principe doit être suffisamment clair et précis pour permettre une prise de décision cohérente dans des situations complexes et potentiellement conflictuelles.
Complétude	Chaque principe doit être important et gouverner la gestion des opérations et des TI
Stabilité	Chaque principe doit être durable dans le temps, mais permettre néanmoins des modifications.

Note

L’énoncé de principes, qui apparaît simple au départ, est un exercice complexe à réaliser. Les quelques conseils suivants pourront aider à les déterminer.

• Ils sont formulés en nombre limité, globalement et par volet ou segment.

• Ils sont cohérents avec ceux de l’AEG et les transformations qu’elle induit dans l’appareil gouvernemental.

• Ils sont évidemment adaptés au contexte de l’organisation et aux préoccupations actuelles et à moyen terme.

• Ils doivent marquer les esprits, d’où l’importance de les communiquer à toute l’organisation.

• Ils sont documentés pour que, en cas d’interprétation, tous leur attribuent et en comprennent le même sens

2.1.1.2. Le cadre de développement

Le cadre de développement est un ensemble de règles destiné à conduire la démarche d’architecture d’Entreprise. Il propose une méthodologie et un ensemble d’étapes qui mènent à l’élaboration de l’AE d’une organisation.

Ce guide suit le cadre de développement Togaf (version 10) combiné au language de modelisation Archimate (version 3.2)

TOGAF (ADM) est une méthode générique, destinée à être utilisée par des entreprises dans une grande variété de secteurs d’activité et de zones géographiques. Elle est également conçue pour être utilisée avec une grande variété d’autres cadres d’architecture d’entreprise, si nécessaire (bien qu’elle puisse parfaitement être utilisée seule, sans adaptation).

Figure 26: Les domaines du cadre TOGAF

ArchiMate, est un langage de modélisation qui permet de décrire visuellement les architectures d’entreprise. Il est spécialement conçu pour documenter, analyser et visualiser les aspects de l’architecture d’entreprise de manière intégrée.

ArchiMate et TOGAF sont deux cadres complémentaires dans la démarche de l’architecture d’entreprise. TOGAF, le cadre méthodologique, oriente le développement, la planification, et la gestion de l’architecture d’entreprise, tandis qu’ArchiMate offre un langage de modélisation pour la visualisation et la documentation des architectures. Leur intégration permet une planification stratégique efficace, une meilleure compréhension et une communication améliorée de l’architecture d’entreprise, facilitant ainsi les décisions et la mise en œuvre de projets de transformation numérique.

2.1.2. Phase A: Vision architecturale

La phase A, également connue sous le nom de phase de vision d’architecture, est la première phase du cycle de vie de l’architecture d’entreprise. Dans cette phase, le schéma directeur informatique (SDI) est élaboré en détail pour fournir une orientation stratégique à long terme pour les activités informatiques de l’entreprise.

Le détail de cette phase est le suivant:

1. Identification des besoins et opportunités

Dans cette première phase du SDI, les besoins commerciaux, les défis actuels, les opportunités futures et les aspirations de l’entreprise sont identifiés. Cela peut être réalisé par le biais d’entrevues avec les parties prenantes clés, d’analyses de marché, de revues de documents stratégiques de l’entreprise, etc. La fiche d’audit relative à la prise de connaissance de l’entité en Annexe peut être utilisée.

Les résultats de cette étape peuvent être intégrés au document de portée de la phase A, qui décrit les objectifs et les contraintes du projet d’architecture d’entreprise.

2. Élaboration de la vision et des objectifs stratégiques

Sur la base des besoins et des opportunités identifiés, une vision à long terme est élaborée, décrivant où l’entreprise souhaite être dans un avenir défini. La vision doit décrire la réussite future de l’organisation et être exprimée par des énoncés simples et faciles à comprendre. Elle doit être inspirante et réaliste. Elle doit :

• Tenir compte de la situation actuelle et du contexte opérationnel dans lequel évolue l’organisation, point de départ essentiel à toute transformation ;

• Permettre à l’organisation de se projeter dans le futur, généralement à moyen terme (environ 3-5 ans);

• S’établir en cohérence avec les orientations gouvernementales ;

• Tenir compte des contraintes et des priorités de l’organisation ;

• Servir de base à l’établissement des orientations et des objectifs opérationnels ;

• Guider les décisions et fédérer les actions de tous en vue d’atteindre les objectifs fixés ;

• Permettre également de communiquer un message clair à la clientèle quant aux ambitions de l’organisation pour les années à venir.

L’architecture d’entreprise joue un rôle majeur dans la concrétisation de cette vision. Elle accompagne l’organisation dans l’établissement de sa vision, de sa stratégie et de sa mise en œuvre.

• Des objectifs stratégiques spécifiques sont également définis pour soutenir cette vision.

• Ces éléments peuvent être intégrés à la section « Vision » du document d’architecture d’entreprise de la phase A, qui décrit la direction stratégique générale de l’entreprise et les motivations pour entreprendre le projet d’architecture.

3. Analyse de l’existant et évaluation des capacités actuelles

Cette étape implique une évaluation approfondie des capacités informatiques existantes de l’entreprise, y compris les systèmes, les processus, les compétences humaines et les ressources financières.

Les résultats de cette analyse peuvent être intégrés à la section « État actuel » du document d’architecture d’entreprise de la phase A, qui fournit une vue détaillée de la situation actuelle de l’entreprise en matière d’informatique et de systèmes d’information.

4. Identification des lacunes et définition des initiatives stratégiques

En comparant la vision stratégique avec l’état actuel, les lacunes sont identifiées, définissant ainsi les domaines où des améliorations sont nécessaires. Des initiatives stratégiques sont alors définies pour combler ces lacunes et atteindre les objectifs fixés.

Ces lacunes et initiatives peuvent être intégrées à la section « Gaps » du document d’architecture d’entreprise de la phase A, qui décrit les écarts entre l’état actuel et l’état désiré, ainsi que les grandes lignes des actions nécessaires pour les combler.

En résumé, les phases détaillées du SDI dans la phase A de TOGAF s’intègrent aux livrables de cette phase en contribuant aux sections du document d’architecture d’entreprise qui décrivent la vision stratégique, l’état actuel, les lacunes et les initiatives stratégiques. Cela garantit une alignement étroit entre la stratégie informatique et les objectifs commerciaux dès le début du processus d’architecture d’entreprise

2.1.3. Phase B: Architecture Métier

Cette étape suit la prémière phase dans laquelle a été élaborée le schéma directeur. Dans cette nouvelle phase, le travail consiste principalement à élaborer une architecture cible alignée sur les objectifs stratégiques de l’organisation et à identifier les composants candidats de la feuille de route de l’architecture en fonction des écarts entre l’architecture de référence et l’architecture cible de l’entreprise.

2.1.3.1. Description de l’Architecture d’Entreprise Actuelle

Dans des environnements architecturaux matures, les descriptions d’architecture existantes servent de base pour actualiser et développer l’Architecture d’Entreprise. Si ces descriptions manquent, il faut collecter les informations disponibles. L’analyse de l’état actuel se fait souvent de bas en haut, en s’appuyant sur des hypothèses pour établir les faits. Les processus et composants obsolètes sont évalués pour leur valeur résiduelle. L’objectif est de maximiser la réutilisation des matériaux existants et de recueillir uniquement les informations nécessaires pour définir l’architecture cible, tout en évitant les détails superflus.

2.1.3.2. Modélisation

Dans le cadre du développement de l’architecture d’entreprise, divers modèles et techniques de modélisation peuvent être utilisés pour décrire les processus et fonctions d’affaires. Voici quelques exemples de modèles :

• Modèles d’activité (Modèles de processus d’affaires) : Ils décrivent les fonctions liées aux activités commerciales, les échanges de données ou d’informations à l’intérieur et à l’extérieur de l’entreprise. Ces modèles sont hiérarchiques et peuvent inclure des règles d’affaires détaillant les relations entre les entrées, les contrôles, les sorties et les mécanismes (ICOMs).

• Modèles de cas d’utilisation : Utilisés pour décrire les processus d’affaires ou les fonctions systèmes à travers des cas d’utilisation et des acteurs qui correspondent aux processus d’affaires et aux participants organisationnels. Ils se composent de diagrammes et de spécifications de cas d’utilisation.

• Modèles de classe : Similaires aux modèles de données logiques, ils décrivent les informations statiques, leurs comportements et les relations entre elles, à différents niveaux de granularité. Ils peuvent représenter des entités du domaine d’affaires ou des classes d’implémentation de systèmes.

Ces types de modèles peuvent tous être représentés en Langage de Modélisation Unifié (UML), et divers outils existent pour générer de tels modèles.

Il est important que l’architecte prenne la peine de faire une analyse des ressources pertinentes en matière d’architecture d’entreprise qui sont disponibles dans le cadre des activités de l’entreprise.

2.1.3.3. Validation de l’architecture

Une étape clé de la validation d’une architecture consiste à prendre en compte ce qui a pu être oublié. L’architecture doit répondre à tous les besoins essentiels de l’organisation en matière de traitement de l’information. La source la plus critique de lacunes à prendre en compte est constituée par les préoccupations des parties prenantes qui n’ont pas été prises en compte dans les travaux architecturaux antérieurs.

Les sources potentielles de lacunes peuvent être:

• Lacunes au niveau du personnel (par exemple, exigences en matière de formation polyvalente)

• Lacunes dans les processus (par exemple, inefficacité des processus)

• Lacunes au niveau des outils (par exemple, duplication ou absence de fonctionnalité des outils)

• Lacunes en matière d’information

• Lacunes dans les mesures

• Lacunes financières

• Lacunes au niveau des installations (bâtiments, espaces de bureaux, etc.)

L’analyse des lacunes met en évidence les services et/ou les fonctions qui ont été accidentellement omis, délibérément éliminés, ou qui doivent encore être développés ou achetés. La matrice d’analyse des lacunes de la phase D illustre un exemple de matrice d’analyse des lacunes. Les étapes suggérées sont les suivantes

2.1.4. Phase C: Architecture des Systèmes d’information

L’objectif de la phase C est de développer des architectures cibles couvrant l’un ou l’autre des domaines des systèmes de données et d’applications, ou les deux (en fonction de la portée du projet).

2.1.4.1. Le domaine des données

L’objectif de cette partie est de définir les principaux types et sources de données nécessaires pour soutenir l’activité de l’organisation, d’une manière qui soit

• compréhensible par les parties prenantes

• Complètes et cohérentes

• stables.

Il est important de noter que cet effort ne concerne pas la conception de la base de données. L’objectif est de définir les entités de données pertinentes pour l’organisation, et non de concevoir des systèmes de stockage logiques ou physiques.(Toutefois, des liens avec des fichiers et des bases de données existants peuvent être développés et peuvent mettre en évidence des domaines importants à améliorer).

Une étape clé de la validation d’une architecture consiste à examiner ce qui a pu être oublié. L’architecture doit prendre en charge tous les besoins essentiels de l’organisation en matière de traitement de l’information. La source la plus critique de lacunes à prendre en compte est constituée par les préoccupations des parties prenantes qui n’ont pas été prises en compte dans le travail d’architecture.

Les types de lacunes dans les données sont les suivantes :

• Les données ne se trouvent pas là où elles sont nécessaires

• Les données ne sont pas celles dont on a besoin

• Données non disponibles au moment voulu

• Données non créées

• Données non consommées

• Lacunes dans les relations entre les données

• etc.

L’analyse des lacunes met en évidence les insuffisances dans les services de données et/ou les éléments de données qui ont été accidentellement omis, délibérément éliminés ou qui doivent encore être définis

2.1.4.2. Le domaine des applications

L’objectif est ici de définir les principaux types de systèmes d’application nécessaires pour traiter les données et soutenir l’entreprise.

Il est important de noter que cet effort ne concerne pas la conception des systèmes d’application. L’objectif est de définir les types de systèmes d’application pertinents pour l’entreprise et ce que ces applications doivent faire pour gérer les données et présenter les informations aux acteurs humains et informatiques de l’entreprise.

Les applications ne sont pas décrites comme des systèmes informatiques, mais comme des groupes logiques de capacités qui gèrent les objets de données dans l’architecture des données et soutiennent les fonctions de l’entreprise dans l’architecture d’entreprise. Les applications et leurs capacités sont définies sans référence à des technologies particulières. Les applications sont stables et relativement immuables dans le temps, alors que la technologie utilisée pour les mettre en œuvre évoluera au fil du temps, en fonction des technologies actuellement disponibles et de l’évolution des besoins de l’entreprise.

Une dernière étape consiste à valider ce qu’on propose. Cette validation consiste à prendre en compte ce qui a pu être oublié, comme dans le domaine des données.

2.1.5. Phace D: Architecture technologique

Le but de cette phase est de décrire l’architecture technologique qui constituera la base des travaux de mise en œuvre ultérieurs.

Les étapes sont les suivantes:

• Sélectionner les modèles de référence, les points de vue et les outils

• Élaborer une description de l’architecture technologique de référence

• Élaborer une description de l’architecture technologique cible

• Effectuer une analyse des écarts

• Définir les éléments de la feuille de route

• Résoudre les impacts dans l’ensemble de l’architecture

• Procéder à un examen formel des parties prenantes

• Finaliser l’architecture technologique

• Créer un document de définition de l’architecture

2.1.6. Phase E: Opportunités et solutions

La phase E, intitulée « Opportunities and Solutions », consiste à identifier et évaluer les différentes opportunités d’amélioration et les solutions potentielles pour combler les écarts identifiés dans les phases précédentes. Cette phase vise à élaborer une stratégie d’implémentation en vue de transformer l’architecture actuelle en une architecture cible souhaitée. Voici les principaux objectifs et activités de cette phase :

• Analyser les écarts : Identifier et confirmer les écarts entre l’architecture actuelle et l’architecture cible.

• Rechercher des opportunités : Trouver des opportunités d’amélioration au sein de l’administration qui peuvent être exploitées grâce à la transformation.

• Élaborer des solutions : Développer des options de solution pour adresser les opportunités et combler les écarts.

• Évaluer et sélectionner des solutions : Évaluer les solutions potentielles en termes de faisabilité, de risques, d’impacts et de bénéfices attendus, et sélectionner les options les plus appropriées.

• Définir des projets : Découper les solutions choisies en projets réalisables et les planifier en phases d’implémentation.

• Établir une feuille de route de mise en œuvre : Créer une feuille de route détaillant l’ordre de mise en œuvre des projets et les dépendances entre eux.

Cette phase permet d’aligner les initiatives de transformation avec les objectifs stratégiques de l’organisation et de préparer le terrain pour la planification de l’implémentation dans la phase suivante (Phase F).

2.1.7. Phase F: Planification de la migration

Les objectifs de cette phase sont de :

• finaliser la feuille de route de l’architecture et le plan de mise en œuvre et de migration qui l’accompagne

• Veiller à ce que le plan de mise en œuvre et de migration soit coordonné avec l’approche de l’entreprise en matière de gestion et de mise en œuvre du changement dans le portefeuille global de changements de l’entreprise.

• Veiller à ce que les principales parties prenantes comprennent la valeur commerciale et le coût des lots de travaux et des architectures de transition.

Avoir un plan de migration approprié garantit une transition en douceur. Il reprend tous les éléments essentiels et précise le mode de mise en œuvre selon les priorités. La phase F se concentre sur la planification détaillée de la mise en œuvre des projets et initiatives identifiés dans la phase E pour réaliser la transformation de l’architecture actuelle vers l’architecture cible.

Les différentes étapes sont les suivantes:

• Établissement des priorités pour les projets de migration : Cette étape implique l’évaluation de chaque projet proposé basé sur des critères tels que la valeur stratégique, le coût, les bénéfices potentiels, et les risques associés. Les projets sont ensuite classés par importance et impact sur les objectifs de l’entreprise, et un séquencement est défini pour gérer efficacement les interdépendances et optimiser les capacités organisationnelles.

• Confirmation des ressources et des financements : Il est crucial d’identifier et de confirmer la disponibilité des ressources nécessaires, telles que le personnel, la technologie, et les infrastructures pour chaque projet. Cela inclut également la sécurisation du financement en collaborant avec les départements financiers pour confirmer les budgets.

• Développement d’une feuille de route détaillée : Un calendrier détaillé est établi pour chaque projet, identifiant les échéances critiques. La planification inclut la définition des phases clés, des jalons, et des livrables, tout en gérant les interdépendances entre les différents projets.

• Planification des ressources : Cette étape consiste à allouer les ressources humaines et matérielles nécessaires à chaque phase des projets. La planification des capacités vise à assurer que l’organisation peut gérer les ressources requises au fil du temps.

• Établissement d’un mécanisme de gouvernance : La mise en place de structures de gouvernance est essentielle pour superviser la mise en œuvre des projets. Des mécanismes de suivi et de contrôle sont définis pour évaluer les progrès et prendre les décisions nécessaires de manière transparente et efficace.

• Préparation du changement : Les initiatives de gestion du changement sont planifiées pour soutenir les employés durant les transitions. Des stratégies de communication sont élaborées pour informer et engager toutes les parties prenantes, et des formations sont organisées pour développer les compétences nécessaires à la gestion des nouvelles technologies et processus.

• Création d’un plan de mise en œuvre : Un document détaillé est rédigé, couvrant tous les aspects de la mise en œuvre. Ce plan détaille les actions, les responsabilités, les critères de succès, et les méthodes de mesure de performance pour chaque projet, assurant ainsi une exécution ordonnée et efficace des initiatives planifiées.

2.1.8. Phase G: Gouvernance de la mise en oeuvre

Les objectifs de la phase G sont les suivants :

• assurer la conformité des projets de mise en œuvre avec l’architecture cible

• assurer les fonctions appropriées de gouvernance de l’architecture pour la solution et toute demande de modification de l’architecture liée à la mise en œuvre.

Cette phase se concentre sur le déploiement de l’architecture cible sous la forme d’une série de transitions. Chaque transition représente une étape incrémentale vers la cible, et chacune apporte un avantage commercial en soi. Elle prend également en compte la supervision de l’implémentation des projets conçus dans les phases précédentes.

Elle a pour phase:

• La gouvernance de l’implémentation : Cette activité consiste à mettre en place des mécanismes et structures de gouvernance pour superviser le déploiement des architectures. Il s’agit d’assurer que tous les projets de mise en œuvre respectent les plans et les spécifications architecturales établis. Les structures de gouvernance peuvent inclure des comités de pilotage, des équipes de projet et des rôles de gouvernance spécifiques, tous chargés de surveiller le progrès des projets et d’intervenir si nécessaire.

• Le suivi de l’implémentation : Le suivi rigoureux de la conformité à l’architecture est essentiel pour éviter les déviations qui pourraient compromettre les objectifs de l’entreprise. Cela inclut la vérification que les solutions déployées s’alignent sur les architectures définies et les standards établis. Des revues régulières et des audits sont menés pour évaluer la conformité des projets en cours et terminés.

• La gestion des changements architecturaux : Au cours de cette phase, il est souvent nécessaire d’apporter des modifications à l’architecture initialement prévue en réponse à des changements dans l’environnement technologique, réglementaire ou commercial. La gestion efficace de ces changements est vitale pour maintenir la pertinance de l’architecture.

• Validation des résultats : À mesure que les projets de mise en œuvre sont complétés, il est important de valider que les solutions déployées fonctionnent comme prévu et atteignent les objectifs définis. Des tests, des évaluations de performance et des retours d’utilisateurs sont utilisés pour confirmer que les solutions répondent aux besoins de l’entreprise.

2.1.9. Phase H: Gestion des modifications de l’architecture

Les objectifs de la phase H consistent à assurer le maintien du cycle de vie de l’architecture, à mettre en œuvre le cadre de gouvernance de l’architecture et à garantir que la capacité d’architecture d’entreprise corresponde aux exigences actuelles. Il s’agit notamment de gérer les modifications apportées à l’architecture de manière cohérente et structurée.

Ce processus prévoit généralement un suivi continu d’éléments tels que les demandes de gouvernance, les nouveaux développements technologiques et les changements dans l’environnement opérationnel. Lorsque des changements sont identifiés, la gestion des changements détermine s’il convient de lancer officiellement un nouveau cycle d’évolution de l’architecture.

En outre, 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 une architecture ayant la flexibilité d’évoluer rapidement en réponse aux changements dans l’environnement technologique et commercial.

En somme, elle a pour activités:

• La Surveillance continue de l’environnement : Cette activité implique une veille continue du marché et de l’environnement technologique pour identifier les tendances émergentes, les innovations technologiques et les changements dans les exigences réglementaires qui pourraient influencer l’architecture d’entreprise.

• Évaluation des impacts des changements : Lorsqu’un changement potentiel est identifié, il est crucial d’évaluer son impact sur l’architecture actuelle et les opérations de l’administration. Cette évaluation comprend l’analyse des risques, des coûts et des bénéfices associés à l’adoption de ce changement.

• Gestion des demandes de changement : Toutes les demandes de changement doivent être gérées de manière systématique à travers un processus formel de gestion des changements. Ce processus évalue les propositions de changement, priorise les actions et assure que les changements sont implémentés de manière contrôlée et efficace.

• Mise à jour de l’architecture : Sur la base des évaluations réalisées, l’architecture peut nécessiter des mises à jour pour intégrer les changements approuvés. Cela peut inclure la modification des modèles, des standards ou des politiques pour assurer que l’architecture continue de répondre aux besoins actuels et futurs de l’entreprise.

• Communication et formation : Il est important de communiquer les changements d’architecture à toutes les parties prenantes concernées et de fournir la formation nécessaire pour faciliter la transition vers la nouvelle architecture. Cela assure que les changements sont bien compris et efficacement mis en œuvre à travers l’organisation.

• Réévaluation périodique de l’architecture : Finalement, une réévaluation périodique de l’architecture est nécessaire pour s’assurer qu’elle reste alignée avec les objectifs stratégiques de l’entreprise et continue de fournir la valeur attendue. Cette réévaluation peut également déclencher une nouvelle itération de si des changements significatifs sont nécessaires.

[1]

Les principes.