Architecture d'entreprise et Transformation Digitale (PDF)

Université Abdelmalek Essaâdi Ecole Nationale des Sciences Appliquées - Al Hoceima Département Mathématiques et Informatique Architecture d’Entreprise et Transformation Digitale Mohamed El Marouani PhD, Engineer I. Archit...

Université Abdelmalek Essaâdi Ecole Nationale des Sciences Appliquées - Al Hoceima Département Mathématiques et Informatique Architecture d’Entreprise et Transformation Digitale Mohamed El Marouani PhD, Engineer I. Architecture d’Entreprise 2 Architecture d’Entreprise: Concept L'Architecture d'Entreprise (AE) (Enterprise Architecture) est un ensemble de pratiques et de concepts visant à aligner la stratégie et le modèle opérationnel d'une organisation. Elle implique la conception globale et la planification de l'ensemble des composants et des processus métier d'une organisation. L’architecture d’entreprise est une discipline qui aide les organisations à structurer et harmoniser leurs processus, technologies, et ressources pour atteindre leurs objectifs stratégiques. Elle permet une vision globale de l’organisation en prenant en compte à la fois les aspects métiers et IT. 3 Architecture d’Entreprise: Pourquoi? Elle fournit un langage et un cadre communs aux entreprises qui discutent des initiatives informatiques. L'architecture d'entreprise peut aider une organisation à aligner ses investissements informatiques sur ses objectifs stratégiques / métier / commerciaux. L'architecture d'entreprise peut améliorer l'efficacité globale d'une organisation en l'aidant à identifier et à éliminer les doublons et les redondances dans ses systèmes informatiques. 4 Architecture d’Entreprise: Objectifs Garantir que tous les composants de l'entreprise, y compris les stratégies commerciales, les processus commerciaux, les architectures de données et les architectures de systèmes, sont intégrés, sécurisés et efficaces. Améliorer la prise de décision au sein des entreprises, accroître leur agilité, réduire leurs coûts opérationnels et améliorer leur performance globale. L'EA facilite la communication entre les différents départements, en fournissant un langage commun et un cadre permettant aux parties prenantes de comprendre et de collaborer à des projets informatiques complexes. Grâce à l'architecture d'entreprise, la transformation digitale peut être menée de manière proactive et holistique, ce qui permet d'obtenir des résultats fructueux et de concrétiser la vision d'entreprise souhaitée. 5 Architecture d’Entreprise: Composants 6 Architecture d’Entreprise: Bénéfices 7 Architecture d’Entreprise: Acteurs 8 Architecture d’Entreprise: Frameworks Un framework (cadre de travail) est un ensemble de structures, processus et outils qui supportent la gestion et la mise en oeuvre d’une Architecture d’Entreprise. C’est un accélérateur pour mettre en place rapidement une pratique d'architecture d'entreprise, grâce à la définition rapide de chaque concept et de leurs relations. Le framework Zachman Le framework TOGAF Autres frameworks: ○ Le FEAF (Federal Enterprise Architecture Framework): un framework conçu pour fournir une structure aux agences fédérales américaines. ○ DODAF (Department of Defense Architecture Framework): créé par le ministère de défense américain. Il est particulièrement adapté aux grands systèmes présentant des défis complexes d'intégration et d'interopérabilité. ○ ODF (Open Digital Framework): C’est un framework destiné pour l’industrie télécom. 9 Architecture d’Entreprise: Frameworks Le framework Zachman Conçu à l'origine par John Zachman chez IBM en 1987. Il utilise un modèle de classification à deux dimensions basé sur : ○ six interrogations de base : Quoi, Comment, Où, Qui, Quand, et Pourquoi. ○ Qui croisent six types de modèles distincts qui se rapportent à des groupes de parties prenantes : Visionnaire, Propriétaire, Concepteur, Réalisateur, Sous-traitant et Exécutant 10 Architecture d’Entreprise: Frameworks Le framework Zachman 11 Architecture d’Entreprise: Frameworks Le framework TOGAF TOGAF (The Open Group Architecture Framework) est un standard industriel créé au milieu des années 1990 couvrant le domaine de l’Architecture d’Entreprise. TOGAF est un standard de fait géré par l’organisme Open Group, vaguement adopté par les entreprise: En 2016, L'Open Group affirme que TOGAF est employé par 80% des entreprises du Global 50 et 60% des entreprises du Fortune 500. Un nombre de certificats sont fournis aux spécialistes autour du standard TOGAF (Foundation, Certified, EA Foundation, EA Pratictioner, Business Architecture Foundation). TOGAF est basé sur 4 domaines: Business Architecture, Data Architecture, Applications Architecture, Technical Architecture. Le Cycle ADM (Architecture Development Method) constitue le cœur de la démarche TOGAF et délivre, sous la forme d’un processus cyclique, les bonnes pratiques pour développer l’Architecture d’Entreprise au centre 12 d'une organisation. Architecture d’Entreprise: Modèles Pour l’Architecture d’Entreprise, La modélisation est essentielle pour décrir la complexité de l’entreprise et la communiquer à toutes les parties prenantes. Modèle de motivation de l'entreprise (Business Motivation Model) pour représenter la stratégie de l'organisation et visualiser les objectifs de l'entreprise. Business Model Canvas pour obtenir une vue globale des éléments stratégiques nécessaires à la commercialisation réussie d'un produit. Cartes des capacités de l'entreprise pour comprendre les capacités de l'entreprise et la manière dont elles sont soutenues par les ressources informatiques. Carte du parcours client pour comprendre comment ces derniers interagissent avec l'organisation et leur niveau de satisfaction. Cartes des processus/flux de valeur pour visualiser la manière dont les produits et services sont fournis et analyser la valeur fournie aux clients. La feuille de route de la transformation de l'entreprise et la feuille de route informatique pour visualiser et communiquer la manière dont les projets métier et informatiques sont planifiés dans le temps. 13 Architecture d’Entreprise: Modèles Modèle de motivation de l'entreprise (Business Motivation Model) pour représenter la stratégie de l'organisation et visualiser les objectifs de l'entreprise. 14 Architecture d’Entreprise: Modèles Modèle de motivation de l'entreprise: 15 Architecture d’Entreprise: Modèles Business Model Canvas pour obtenir une vue globale des éléments stratégiques nécessaires à la commercialisation réussie d'un produit. 16 Architecture d’Entreprise: Modèles Cartes des capacités de l'entreprise pour comprendre les capacités de l'entreprise et la manière dont elles sont soutenues par les ressources informatiques. 17 Architecture d’Entreprise: Modèles Carte du parcours client pour comprendre comment les clients interagissent avec l'organisation et leur niveau de satisfaction. 18 Architecture d’Entreprise: Modèles Carte de flux de valeur pour visualiser la manière dont les produits et services sont fournis et analyser la valeur fournie aux clients. 19 Architecture d’Entreprise: Modèles Cartes des processus pour comprendre comment les tâches sont liées entre elles au sein d’un processus et leur enchaînement.. 20 Architecture d’Entreprise: Modèles La feuille de route de la transformation de l'entreprise pour visualiser et communiquer la manière dont les projets métier et informatiques sont planifiés dans le temps. 21 Architecture d’Entreprise: Modèles Et d’un point de vue des solutions au sein d’une entreprise, on peut s’appuyer sur les modèles suivants: Modèle d'environnement de la solution pour définir l'intégration de la solution dans le paysage informatique existant. Modèle de déploiement de l'application pour décrire la manière dont les composants techniques d'une application doivent être déployés pour éviter les pièges potentiels Carte de l'infrastructure technique pour décrire l'infrastructure technique requise pour supporter la solution déployée. 22 Architecture d’Entreprise: ArchiMate ArchiMate est un langage de modélisation d'architecture d'entreprise ouvert et indépendant qui prend en charge la description, l'analyse et la visualisation de l'architecture au sein et entre les domaines d'activité. Il est maintenu par The Open Group, qui gère également le framework TOGAF. Il repose sur les concepts de la norme IEEE 1471. ArchiMate fournit un ensemble de concepts et de notations pour créer des modèles qui décrivent les relations entre les différentes couches d'une architecture d'entreprise. 23  Architecture d’Entreprise: ArchiMate ArchiMate organise ses concepts en couches, reflétant différents aspects d'une entreprise : Couche métier : représente les processus métier, les services, les fonctions, les rôles et les acteurs qui définissent le fonctionnement de l'entreprise. Couche application : modélise les composants d'application, les services et leurs relations avec les processus métier. Couche technologie : se concentre sur le matériel, les logiciels et l'infrastructure réseau qui prennent en charge les applications. Couche motivation : aborde les aspects stratégiques, notamment les objectifs, les principes et les moteurs. Couche implémentation et migration : aide à planifier et à gérer l'évolution de l'architecture actuelle vers l'architecture cible. 24 Architecture d’Entreprise: ArchiMate ArchiMate utilise un ensemble de concepts clés pour structurer et modéliser les architectures : Éléments de structure actifs : représentent les entités qui exécutent des activités (par exemple, les acteurs métier, les composants d'application et les périphériques). Éléments comportementaux : définissent ce qui se passe dans l'architecture (par exemple, les processus, les fonctions, les interactions). Éléments de structure passifs : représentent les objets sur lesquels on agit (par exemple, les objets métier, les objets de données et les artefacts). Ces concepts sont liés par diverses relations, telles que la composition, l'affectation, la réalisation et l'association, pour démontrer comment les composants de l'architecture sont interconnectés. 25 Architecture d’Entreprise: ArchiMate 26 Architecture d’Entreprise: ArchiMate ArchiMate est complémentaire à TOGAF, en fournissant un langage de modélisation formel capable de représenter les concepts décrits dans TOGAF. Il aide les architectes à créer des modèles cohérents et alignés d'architecture d'entreprise. ArchiMate est particulièrement utile dans les organisations à grande échelle, où l'architecture est multiforme et doit être communiquée clairement entre les départements. Les bénéfices de ce langage sont principalement: la standardisation, la visualisation, la traçabilité. 27 Architecture d’Entreprise: ArchiMate Un modèle exemple 28 Architecture d’Entreprise: Outils 29 Architecture d’Entreprise: Bonnes pratiques Comprendre clairement les buts, les objectifs et les stratégies de l'entreprise. Aligner l'architecture sur les objectifs de l'entreprise. Adopter une architecture flexible, évolutive et ouverte, capable de s'adapter à l'évolution des besoins de l'entreprise. Evaluer la rentabilité globale de l'architecture d'entreprise. Communiquer le cadre de l'architecture d'entreprise à toutes les parties prenantes pour s'assurer que tout le monde est sur la même longueur d'onde. Faire évoluer le cadre d'architecture pour répondre aux besoins en constante évolution de l'organisation. 30 Architecture d’Entreprise & Transformation Digitale L'architecture d'entreprise est importante pour guider les efforts de transformation digitale au sein d'une organisation. Elle fournit une vue d'ensemble détaillée des systèmes internes, des processus et des flux de données, permettant aux organisations d'identifier les domaines d'amélioration et les opportunités d'innovation. En outre, l'architecture d'entreprise empêche la duplication des systèmes ou des services informatiques qui peuvent potentiellement augmenter les coûts de l'entreprise, améliorer la résilience des systèmes et renforcer l'agilité. Sans architecture d'entreprise, un parcours de transformation digitale peut être décousu et ne pas atteindre les objectifs de l'entreprise. Il est donc recommendé pour les organisations en cours de transformation digitale de donner la priorité à l'architecture d'entreprise afin de s'assurer qu'elles restent sur la bonne voie et atteignent les résultats souhaités. 31 II. TOGAF 32 1. Concepts clé TOGAF 2. Méthode de développement de l’architecture (ADM) 33 TOGAF 10 th Edition Un framework est une structure fondamentale, ou un ensemble de structures, qui peut être utilisé pour développer une large gamme d’architectures différentes. Bien que toute la documentation TOGAF fonctionne comme un tout, il est attendu que les organisations la personnalisent lors de l'adoption. 34 TOGAF: Les concepts clé TOGAF dispose de 7 importants concepts clé: Définition de l’entreprise Les domaines de l’architecture: BDAT Architectures Development Method (ADM) Architecture Work Products Enterprise Continuum Architecture Repository Définition de la capacité d’architecture 35 Les concepts clé: Entreprise “The TOGAF Standard considers an "enterprise" to be any collection of organizations that have common goals”. Le terme « entreprise » dans le contexte de « l'architecture d'entreprise » peut s'appliquer soit à une entreprise entière, englobant toutes ses activités et capacités business, ses informations et sa technologie qui constituent l'ensemble de l'infrastructure et de la gouvernance de l'entreprise, soit à un ou plusieurs domaines d'intérêt spécifiques au sein de l'entreprise. De nombreuses organisations peuvent être constituées de plusieurs entreprises et développer et maintenir un certain nombre d'architectures d'entreprise indépendantes pour répondre à chacune d'elles. 36 Les concepts clé: les domaines de l’architecture BDAT Il existe quatre domaines d'architecture qui sont communément acceptés comme sous-ensembles d'une architecture d'entreprise globale. Business Architecture: définit la stratégie, la gouvernance, l'organisation et les processus métier clés de l'entreprise. Data Architecture: décrit la structure des actifs de données logiques et physiques et des ressources de gestion des données d'une organisation. Application Architecture: fournit un plan pour les applications individuelles à déployer, leurs interactions et leurs relations avec les processus métier de base de l'organisation. Technology Architecture: décrit l'architecture digitale et les capacités et normes d'infrastructure logicielle et matérielle requises pour prendre en charge le déploiement des services métier, de données et d'applications. Cela comprend les services numériques, l'Internet des objets (IoT), les services cloud, l'infrastructure IT, les middleware, les réseaux, … 37 Les concepts clé: Architecture Development Method La méthode ADM fournit un processus testé et reproductible pour le développement d'architectures. L'ADM comprend l'établissement d'un framework d'architecture, le développement du contenu de l'architecture, la transition et la gestion de la réalisation des architectures. Toutes ces activités sont réalisées dans le cadre d’un cycle itératif de définition et de réalisation d’architecture continue qui permet aux organisations de transformer leurs entreprises de manière contrôlée en réponse aux objectifs et aux opportunités business. 38 Les concepts clé: Architecture Development Method Les phases de l'ADM sont les suivantes : La phase préliminaire décrit les activités de préparation et d'initiation nécessaires à la création d'une capacité d'architecture, y compris la personnalisation du cadre TOGAF et la définition des principes d'architecture. A. Architecture Vision : La vision de l'architecture décrit la phase initiale d'un cycle de développement d'architecture. Elle comprend des informations sur la définition de la portée de l'initiative de développement de l'architecture, l'identification des parties prenantes, la création de la vision de l'architecture et l'obtention de l'approbation pour procéder au développement de l'architecture. B. Business Architecture : décrit le développement d'une architecture business pour soutenir la vision d'architecture convenue. C. Information Systems Architectures : Les architectures des systèmes d'information décrivent le développement des architectures des systèmes d'information pour soutenir la vision d'architecture convenue. 39 Les concepts clé: Architecture Development Method D. Technology Architecture : L'architecture technologique décrit le développement de l'architecture technologique pour soutenir la vision d'architecture convenue. E. Opportunities & Solutions : Lors de cette phase une planification initiale de l’implémentation et de l'identification des véhicules de livraison est effectuée pour l'architecture définie dans les phases précédentes. F. Migration Planning : La planification de la migration aborde la manière de passer des architectures de base aux architectures cibles en finalisant un plan d’implémentation et de migration détaillé. G. Implementation Governance : fournit une supervision / contrôle architecturale de l’implémentation. H. Architecture Change Management : La gestion des changements d'architecture établit des procédures de gestion des changements vers la nouvelle architecture. La gestion des exigences (Requirements Management) gère le processus de gestion des exigences d'architecture dans l'ensemble de l'ADM. 40 Les concepts clé: Architecture Work Products Le framework TOGAF utilise trois catégories pour décrire le type de produit de travail architectural dans le contexte d'utilisation : Un livrable (deliverable) est un produit de travail spécifié contractuellement et sera formellement examiné, approuvé et signé par les parties prenantes. Les livrables représentent le résultat des projets et les livrables qui sont sous forme de documentation seront généralement archivés à la fin d'un projet ou transférés dans un référentiel d'architecture (architecture repository) en tant que modèle de référence, norme ou snapshot du paysage architectural à un moment donné. Un artefact (artifact) est un produit de travail architectural qui décrit un aspect de l'architecture. Les artefacts sont généralement classés comme des catalogues (listes d'éléments), des matrices (montrant les relations entre les éléments) et des diagrammes (images d'éléments). Les exemples incluent un catalogue d'exigences, une matrice d'interaction d'application et un diagramme de chaîne de valeur. 41 Les concepts clé: Architecture Work Products Un livrable architectural peut contenir un ou plusieurs artefacts et les artefacts formeront le contenu du référentiel d'architecture. Un artefact peut ou non être considéré comme un livrable en fonction de la spécification contractuelle. Un bloc de construction (Building Blocks) représente un composant potentiellement réutilisable qui peut être combiné 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 générale. Plus tard, un bloc de construction peut être décomposé en plusieurs blocs de construction de support et peut être accompagné d'une spécification complète. Les blocs de construction peuvent se rapporter à des « architectures » ou à des « solutions ». 42 Les concepts clé: Architecture Work Products 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 la capacité requise et façonnent la spécification des blocs de construction de solution (SBB) ; par exemple, une capacité de service client peut être requise au sein d'une entreprise, prise en charge par de nombreuses SBB, tels que des processus, des données et des logiciels d'application. Les blocs de construction de solution / Solution Building Blocks (SBB) représentent des 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 par le biais d'artefacts complémentaires, puis utilisé pour réaliser des solutions pour l'entreprise. 43 Les concepts clé: Architecture Work Products Les relations entre les livrables, les artefacts et les blocs de construction sont illustrées ci-dessous: 44 Les concepts clé: Enterprise Continuum La norme TOGAF inclut le concept de Continuum d'entreprise / Enterpise Continuum, qui définit le contexte plus large d'un architecte et explique comment les solutions génériques peuvent être exploitées et spécialisées afin de répondre aux exigences d'une organisation individuelle. Le Continuum d'entreprise est une catégorisation des actifs détenus dans les référentiels d'entreprise qui fournit des méthodes de classification des actifs, y compris les artefacts d'architecture et de solution en mesure qu'ils évoluent des architectures de base génériques vers les architectures spécifiques à l'organisation. Le Continuum d'entreprise comprend deux concepts complémentaires : le Continuum d'architecture et le Continuum de solutions. 45 Les concepts clé: Enterprise Continuum Enterprise Continuum Architecture Continuum 46 Les concepts clé: Architecture Repository Le concept de référentiel d'architecture (Architecture Repository), qui peut être utilisé pour stocker différentes classes de résultats architecturaux à différents niveaux d'abstraction, créés par l'ADM, supporte le continuum de l'entreprise. De cette manière, la norme TOGAF facilite la compréhension et la coopération entre les parties prenantes et les praticiens à différents niveaux. L'exploitation d'une capacité d'architecture mature au sein d'une grande entreprise génère un volume considérable de production architecturale. La gestion et l'exploitation efficaces de ces produits de travail architecturaux nécessitent une taxonomie formelle pour les différents types d'actifs architecturaux ainsi que des processus et des outils dédiés au stockage du contenu architectural. 47 Les concepts clé: Architecture Repository 48 Les concepts clé: Définition de la capacité d’architecture Afin de mener à bien l'activité architecturale au sein d'une entreprise, il est nécessaire de mettre en place une capacité business (business capability) appropriée pour l'architecture, à travers des structures organisationnelles, des rôles, des responsabilités, des compétences et des processus. Un aperçu de la capacité d'architecture TOGAF est présenté ci-dessous: 49 ADM: TOGAF & ArchiMate  Les normes ArchiMate et TOGAF partagent une base solide dans leurs idées fondamentales et leur utilisation de points de vue pour capturer et communiquer différents aspects d'un modèle d'architecture sous-jacent unique. Les normes se complètent dans la mesure où la norme TOGAF se concentre sur une méthode de développement et de mise en œuvre d'architectures, tandis que le langage ArchiMate se concentre sur une notation uniforme pour la modélisation des architectures.  Le langage ArchiMate complète le framework TOGAF dans la mesure où il fournit un ensemble de concepts et de relations indépendants des fournisseurs, y compris une représentation graphique qui permet de créer un modèle cohérent et intégré, qui peut être représenté sous forme de vues. Alors que ArchiMate définit ses propres exemples de points de vue qui servent de modèles pour une large gamme de vues, le langage peut également être utilisé pour construire les diagrammes définis dans le cadre de contenu TOGAF. 50 ADM: La phase préliminaire Il s’agit des activités de préparation et d'initiation nécessaires pour répondre à la directive business pour une nouvelle Architecture d‘Entreprise, y compris la définition d'un framework d'architecture spécifique à l'organisation et la définition de principes. Objectifs: 1. Déterminer la capacité d'architecture souhaitée par l'organisation  Examiner le contexte organisationnel pour mener l'AE  Identifier et définir la portée des éléments organisationnels affectés par la capacité d'architecture  Identifier les frameworks, méthodes et processus établis qui recoupent la capacité d'architecture  Établir la maturité cible de la capacité 1. Établir la capacité d'architecture  Définir et établir le modèle organisationnel pour l'architecture d'entreprise  Définir et établir le processus détaillé et les ressources pour la gouvernance de l'architecture  Sélectionner et mettre en œuvre des outils qui prennent en charge la capacité d'architecture  Définir les principes d'architecture 51 ADM: La phase préliminaire Etapes:  Déterminer la portée (scope) des organisations d'entreprise impactées  Confirmer les frameworks de gouvernance et de suport  Définir et établir l'équipe et l'organisation de l'architecture d'entreprise  Identifier et établir les principes d'architecture  Adapter le framework TOGAF et, le cas échéant, d'autres cadres d'architecture sélectionnés  Élaborer une stratégie et un plan d’implémentation pour les outils et les techniques Approche:  Définir l'entreprise  Identifier les principaux éléments et moteurs (drivers) du contexte organisationnel  Définir les exigences pour le travail d'architecture  Définir les principes d'architecture qui éclaireront tout travail d'architecture  Définir le/les frameworks à utiliser  Définir les relations entre les frameworks de gestion  Évaluer la maturité de l'architecture d'entreprise  Déterminer la capacité d'architecture souhaitée par l'organisation 52 ADM: Vision d’Architecture C’est la phase initiale de l'ADM. Elle comprend des informations sur la définition du périmètre, l'identification des parties prenantes, la création de la vision de l'architecture et l'obtention des approbations. Objectifs: 1. Développer une vision ambitieuse de haut niveau des capacités et de la valeur business à fournir grâce à l'architecture d'entreprise proposée. 2. Obtenir l'approbation d'une déclaration des travaux d'architecture qui définit un programme de travaux pour développer et déployer l'architecture décrite dans la vision de l'architecture. Entrées: La vision d’architecture et un projet d’architecture nécessitent des informations d’entrée. 1. Entrées non architecturales:  Demande (Request for) de travaux d'architecture  Principes business, objectifs business et moteurs business 2. Entrées architecturales:  Modèle organisationnel pour l'architecture d'entreprise (i.e. portée, contraintes, rôles et responsabilités, budget)  Framework d'architecture sur mesure (i.e. méthode, outils, livrables et artefacts, principes d'architecture)  Architecture Repository (référentiel) peuplé (i.e. éléments constitutifs de 53 l'architecture, description de base) ADM: Vision d’Architecture Etapes:  Établir le projet d'architecture  Identifier les parties prenantes, les préoccupations et les exigences business  Confirmer et élaborer les objectifs business, les moteurs business et les contraintes  Évaluer les capacités  Évaluer l'état de préparation à la transformation de l'entreprise  Définir le périmètre  Confirmer et élaborer les principes d'architecture, y compris les principes business  Élaborer une vision de l'architecture  Définir les propositions de valeur et les KPIs de l'architecture cible  Identifier les risques de transformation de l'entreprise et les activités d'atténuation  Élaborer une déclaration des travaux d'architecture 54 ADM: Vision d’Architecture Approche:  Recevoir une demande de travaux d'architecture  Définir ce qui est inclus et ce qui est exclu de la portée de l'effort d'architecture et des contraintes  Obtenir, vérifier et comprendre les principes business documentés, les objectifs business, les moteurs stratégiques et les principes d'architecture (phase préliminaire) et s'assurer que les définitions existantes sont à jour  Décrire les architectures de base et cibles pour tous les domaines (métier, données, application, technologie) à un niveau élevé  Définir et documenter la vision de l'architecture dans la déclaration des travaux d'architecture  Obtenir la déclaration des travaux d'architecture signée par l'organisation sponsor. 55 ADM: Vision d’Architecture Les sorties: Les sorties/résultats de cette étape peuvent inclure, sans toutefois s'y limiter,  Déclaration des travaux d'architecture (validé)  Principes business, objectifs, moteurs (révisé)  Principes d'architecture  Évaluation des capacités  Framework d'architecture sur mesure  Vision de l'architecture  Document de définition de l'architecture (draft)  Plan de communication  Référentiel d'architecture 56 ADM: Vision d’Architecture Déclaration des travaux d’architecture / Statement of Architecture Work Objectif  Définit la portée et l'approche utilisées pour un cycle de développement d'architecture  Peut constituer la base d'un accord contractuel entre le fournisseur et le consommateur de services d'architecture (contrat entre l'organisation d'architecture et le sponsor du projet d'architecture) Contenu  Titre, approbations et procédures de changement de portée  Demande de projet d'architecture, contexte, description, portée, plan et calendrier  Critères et procédures d'acceptation, rôles, responsabilités et livrables  Présentation de la vision de l'architecture 57 ADM: Architecture Business Développer une Architecture Business pour soutenir une vision d’architecture convenue. Objectifs: 1. Développer l‘Architecture Business cible qui décrit comment l'entreprise doit fonctionner pour atteindre les objectifs business et répondre aux moteurs stratégiques (strategic drivers) définis dans la vision de l'architecture, d'une manière qui répond à la déclaration des travaux d'architecture et aux préoccupations des parties prenantes. 2. Identifier les composants candidats de la feuille de route de l'architecture en fonction des écarts (gaps) entre les architectures métier de base et cibles. 58 ADM: Architecture Business Définition: L‘Architecture Business:  est une représentation holistique et multidimensionnelle des vues business des capacités, de la livraison de la valeur de bout en bout, des informations et de la structure organisationnelle  comprend les relations entre les vues business et les stratégies, les produits, les politiques, les initiatives et les parties prenantes  relie les éléments business aux objectifs business et aux éléments des autres domaines  est déterminée dans son champ d'application principalement par la vision de l'architecture 59 ADM: Architecture Business Entrées: La vision d’architecture et un projet d’architecture nécessitent des informations d’entrée. 1. Entrées non architecturales:  Demande de travaux d'architecture  Principes, objectifs et moteurs business  Évaluation des capacités  Plan de communication 2. Entrées architecturales:  Modèle organisationnel pour l'architecture d'entreprise (c'est-à-dire portée, contraintes, rôles, responsabilité, budget)  Framework d'architecture sur mesure (c'est-à-dire méthodes, outils, livrables et artefacts)  Déclaration des travaux d'architecture (Validé)  Principes d'architecture (y compris les activités les principes business)  Continuum d'entreprise  Référentiel d'architecture (c'est-à-dire blocs de construction d'architecture, modèles de référence, les standards/normes d'organisation)  Vision de l'architecture (c'est-à-dire problème, objectif, vues, scénario business, exigences des parties prenantes)  Document de définition de l'architecture (Draft) 60 ADM: Architecture Business Etapes:  Sélectionner des modèles de référence, des points de vue et des outils  Élaborer une description de l'architecture business de base  Élaborer une description de l'architecture business cible  Effectuer une analyse des écarts  Définir les composants candidats de la feuille de route  Résoudre les impacts sur l'ensemble du paysage architectural  Effectuer un examen formel des parties prenantes  Finaliser l'architecture métier  Créer/mettre à jour le document de définition de l'architecture NB: Ces étapes sont aussi valides pour les phases C et D (Information Systems Architectures, Technology Architectue). 61 ADM: Architecture Business Sélectionner des modèles de référence, des points de vue et des outils Testez avec des questions et évitez de retravailler :  Étant donné un ensemble de parties prenantes et de préoccupations, quelles informations devez-vous connaître sur le système examiné pour répondre à leurs préoccupations?  Étant donné un ensemble d'informations, comment allez-vous les modéliser, les représenter, les capturer et les analyser?  Existe-t-il des modèles de référence qui vous permettent de passer directement à la collecte et à l'analyse plutôt qu'à l'invention?  Quelles informations manquent actuellement dans le paysage de l'AE? 62 ADM: Architecture Business Élaborer une description de l'architecture business de base et cible, et analyser les écarts  Décrire l'architecture de base uniquement dans la mesure où cela permet d'obtenir un alignement entre les parties prenantes et de déterminer les écarts  Décrire l'architecture de base et l'architecture cible avec la même technique et au même niveau de détail pour identifier tout ce qui change  Se concentrer sur le paysage EA qui va changer et qui nécessite une traçabilité Définir les composants candidats de la feuille de route  Identifier le travail à effectuer pour atteindre la cible en tenant compte du coût et de la valeur  L'état cible fournit une augmentation de la valeur, au prix d'un changement  Être responsable de la préservation de la valeur  Créer une compréhension du travail à effectuer pour atteindre la cible parmi les parties prenantes TOGAF 63 ADM: Architecture Business Résoudre les impacts sur l'ensemble du paysage architectural  Étudier l'impact de l'architecture candidate par rapport aux autres architectures candidates, aux états de transition, à l'état cible, aux projets de mise en œuvre en cours et aux risques de l'entreprise  Résoudre les impacts concernant l'architecture cible et le travail requis  S'appuyer sur un référentiel d'architecture d'entreprise (EA) fonctionnel et sur un logiciel d'analyse et de reporting solide  Se concentrer sur un ensemble minimal de préoccupations et d'informations qui soutiennent visiblement la valeur aux yeux des principales parties prenantes 64 ADM: Architecture Business Effectuer un examen formel des parties prenantes  Obtenir l'approbation de l'architecture cible  Explorer les options, les coûts et les avantages des alternatives à l'aide de la méthode de compromis d'architectures (Architecture Trade off Method)  Aider à trouver un compromis et à sélectionner la meilleure voie possible et contre un ensemble de préférences et d'intérêts concurrents  Assurer une architecture cible approuvée définissant l'avenir et créant une traçabilité vers les objectifs 65 ADM: Architecture Business Approche:  C’est un prérequis pour les travaux d'architecture Data, Application et Technologie.  Elle représente un moyen pour démontrer la valeur business et le retour sur investissement des travaux d'architecture ultérieurs aux principales parties prenantes.  Cas 1 : des parties de l'architecture business sont déjà réalisées  vérifier et mettre à jour le matériel documenté et établir un lien entre les exigences de haut niveau et les exigences spécifiques  Cas 2 : peu ou pas d'architecture business réalisée  rechercher, vérifier et obtenir l'adhésion aux objectifs et processus business clés  Réutiliser le matériel et les descriptions existants (par ex., document de définition d'architecture)  Utiliser et mettre à jour les descriptions d'architecture existantes (phase A) et/ou recueillir des informations pour développer les modèles d'architecture business. 66 ADM: Architecture Business Approche:  Déterminer si la vision fondamentale du business est en train de changer  Développer des modèles d'architecture business (par ex., carte des capacités business, modèle de flux de valeur, carte d'organisation, modèles de processus métier) et appliquer des techniques de modélisation (spécifiques à l'industrie) (par ex., UML)  Utiliser les ressources de la Référentiel d'architecture (modèles de référence sectoriels, normes applicables, les vues et les blocs de construction de l’architecture business spécifique à l'entreprise). 67 ADM: Architecture Business Business Capabilities:  Une capacité business est une capacité ou une aptitude particulière qu'une entreprise peut posséder ou échanger pour atteindre un objectif ou un résultat spécifique  Une combinaison de rôles, de processus, d'informations et d'outils permet d’activer une capacité business  Une carte des capacités business représente un ensemble complet et stable de toutes les capacités dont une entreprise dispose pour gérer son activité  Utilisez la cartographie thermique (heat mapping) pour montrer différentes perspectives sur le même ensemble de capacités (par exemple, maturité, efficacité, performance, valeur, coût) 68 ADM: Architecture Business Information Mapping:  La carte d'information est un ensemble de concepts d'information et de leurs relations  Les concepts d'information reflètent le vocabulaire de l'entreprise / du business (par exemple, client, compte, produit)  Regrouper et classer les informations associées dans des domaines d'information  La cartographie des informations dans l'architecture d'entreprise commence par répertorier et décrire les éléments les plus importants pour l'entreprise  Les cartes des parties prenantes aident à définir les concepts d'information 69 ADM: Architecture Business Information Mapping:  Les concepts d'information sont liés aux capacités business sans supposer des implémentations spécifiques  Les flux de valeur et les concepts d'information sont liés par les capacités business 70 ADM: Architecture Business Value Streams:  Le flux de valeur (value stream) est un ensemble d'activités à valeur ajoutée déclenchées de manière interne ou externe, créant un résultat global pour une partie prenante (par exemple, un client, un utilisateur final).  Les activités à valeur ajoutée sont représentées par des étapes de flux de valeur, chacune d'entre elles créant et ajoutant une valeur supplémentaire (incrémentale) pour la partie prenante d'une étape à l'autre.  L'ensemble complet des flux de valeur désigne l'ensemble principal d'activités business d'une organisation et regroupe la manière dont l'organisation crée de la valeur pour ses parties prenantes.  La valeur est toujours définie du point de vue de la partie prenante. 71 ADM: Architecture Business Value Streams:  L'ensemble complet des flux de valeur décrit comment une organisation orchestre ses capacités à créer de la valeur pour les parties prenantes  Une seule étape de flux de valeur (de l'extérieur dans la perspective du client) peut correspondre à un ou plusieurs processus d'entreprise (perspective opérationnelle, vue de l'intérieur) 72 ADM: Architecture Business Organization Map:  Une carte d'organisation est un plan d'architecture d'entreprise montrant les principales unités organisationnelles, les partenaires et les groupes de parties prenantes ainsi que les relations de travail.  Fournit une compréhension des unités business à impliquer, de qui et quand parler des exigences, et comment mesurer l'impact des décisions  Les cartes d'organisation sont orientées système pour représenter les relations formelles et informelles entre les principales parties prenantes du modèle business de l'entreprise  Phase A : La Vision de l‘Architecture recherche et utilise les descriptions d'organisation existantes dans les organigrammes conventionnels et les cartes d'organisation  Phase B : L‘Architecture Business construit la carte d'organisation avec les détails et les relations pour garantir que les besoins de l'entreprise sont compris 73 ADM: Architecture Business Business Models:  Les modèles métier (business) fournissent une représentation visuelle de haut niveau de l'état actuel et/ou de la conception de l'état futur d'une entreprise (d’un business)  Un modèle métier décrit la raison d'être de la manière dont une organisation crée, capture et fournit de la valeur à ses parties prenantes internes et externes  Le développement d'un modèle métier permet de communiquer des idées clés sur la vision et la stratégie, de générer des discussions interdisciplinaires et de promouvoir l'adhésion  L‘Architecture Business articule les perspectives et les impacts du modèle business (par exemple, les capacités, les flux de valeur, la structure organisationnelle, les objets d'information) 74 ADM: Architecture Business Modeling Techniques: Appliquer des techniques de modélisation (spécifiques au secteur) (par exemple UML ou BPMN)  Utiliser des modèles des cas d'utilisation (Use Cases Models) avec des diagrammes et des spécifications pour décrire les processus métier, les acteurs et les participants  Utiliser des modèles de données logiques (Logical Data Models) pour décrire les entités, leurs attributs et leurs valeurs acceptables ainsi que leurs relations  Utiliser des modèles de classe (Class Models) pour décrire les entités, leurs attributs et leurs valeurs acceptables ainsi que leurs relations et leurs comportements 75 ADM: Architecture Business Sorties: Les résultats peuvent inclure, sans toutefois s'y limiter,  Vision de l'architecture (affinée et mise à jour, le cas échéant)  Déclaration des travaux d'architecture (mise à jour)  Principes, objectifs et moteurs business (validés)  Principes de l'architecture  Document de définition de l'architecture (draft)  Spécification des exigences de l'architecture (draft)  Composants de l‘Architecture Business d'une feuille de route de l'architecture 76 ADM: Architectures des Systèmes d’Information Objectifs:  Développer les architectures cibles des systèmes d'information (Data & Application Architecture), en décrivant comment l‘Architecture des Systèmes d‘Information de l'entreprise réalisera l‘Architecture Business et la Vision de l‘Architecture, d'une manière qui réponde à la déclaration des travaux d'architecture et aux préoccupations des parties prenantes.  Identifier les composants candidats de la feuille de route de l'architecture en fonction des écarts entre les architectures de base et cibles des systèmes d'information (Data & Application). 77 ADM: Architectures des Systèmes d’Information Entrées: Les composants de l’architecture data & application cibles nécessitent les informations d’entrée suivantes: 1. Entrées non architecturales:  Demande de travaux d'architecture  Évaluation des capacités  Plan de communication 2. Entrées architecturales:  Modèle organisationnel pour l‘Architecture Business (c-à-d. portée, contraintes, rôles, responsabilité, budget)  Framework d'architecture sur mesure (c-à-d. méthode, outils, livrables et artefacts, principes d'architecture)  Principes d'architecture (Data et Application)  Déclaration des travaux d'architecture  Vision de l‘Architecture  Repository d‘Architecture (c-à-d. blocs de construction d'architecture, modèles de référence, normes d'organisation)  Document de définition de l'architecture (draft)  Spécification des exigences d'architecture (draft)  Composants d'architecture business d'une feuille de route d'architecture 78 ADM: Architectures des Systèmes d’Information Etapes (Idem pour les phases B, C et D) :  Sélectionner des modèles de référence, des points de vue et des outils  Élaborer une description de l'architecture data & application de base  Élaborer une description de l'architecture data & application cible  Effectuer une analyse des écarts  Définir les composants candidats de la feuille de route  Résoudre les impacts sur l'ensemble du paysage architectural  Effectuer un examen formel des parties prenantes  Finaliser l'architecture data & application  Créer/mettre à jour le document de définition de l'architecture 79 ADM: Architectures des Systèmes d’Information L’Architecture Data - Approche: Techniques  Data Entity / Data Component Catalog  Data Entity / Business Function Matrix  Application / Data Matrix  Conceptual Data Diagram  Logical Data Diagram  Data Dissemination Diagram  Data Security Diagram  Data Migration Diagram  Data Lifecycle Diagram 80 ADM: Architectures des Systèmes d’Information L’Architecture Data - Approche: L'architecture Data est créée à l'aide de trois entités métamodèles  Entités du métamodèle : entités de données, composants de données logiques et physiques  Utiliser des modèles de données conceptuels avec des entités de données pour aider les développeurs informatiques à comprendre les concepts qu'ils auront à traiter  Utiliser des modèles de données logiques avec des composants de données logiques pour créer une vue d'ensemble des données des environnements informatiques, et qui seront des exigences sur les données stockées, utilisées et déplacées dans les applications  Utiliser des modèles de données physiques avec des composants de données physiques pour regrouper les implémentations informatiques existantes ou futures (par exemple, schémas de base de données, messages XML)  Utiliser des modèles d'échange de données pour les données transmises entre/dans/hors des services informatiques et des composants d'application logiques et physiques  Ajouter des attributs de qualité aux entités de données, si nécessaire 81 ADM: Architectures des Systèmes d’Information L’Architecture Data - Approche: L'architecture des données doit gérer les données au repos, en mouvement, en cours d'utilisation et les données ouvertes 82 ADM: Architectures des Systèmes d’Information L’Architecture Data - Approche: Trois considérations clés lors du développement d’une architecture de données :  Adopter une approche structurée et complète de la gestion des données (Data Management)  Définir les composants d'application qui servent de données de base (master) de l'entreprise  Comprendre comment les entités de données sont utilisées par les capacités business, les fonctions business, les processus et les services business et applicatifs  Comprendre comment et où les entités de données d'entreprise sont créées, stockées, transportées et signalées  Identifier les exigences de migration des données de l'application cible  Fournir des indicateurs pour la transformation, le désherbage et le nettoyage des données  Assurer une définition commune des données à l'échelle de l'entreprise (enterprise-wide) pour soutenir la transformation et la migration  S'assurer que l'entreprise dispose des structures, des systèmes de gestion et des personnes nécessaires pour permettre la transformation  Réaliser une gouvernance des données basée sur une structure organisationnelle, un système de gestion des données et des personnes qualifiées 83 ADM: Architectures des Systèmes d’Information L’Architecture Application - Approche:  Utiliser des modèles d'application pertinents pour les fonctions business courantes de haut niveau (par exemple, le commerce électronique, la supply-chain)  Utiliser des modèles business génériques et des modèles d'application connexes pertinents pour le secteur industriel de l'organisation fournis par: - The Open Group Forum - Object Management Group (https://www.omg.org/ - TM Forum (https://www.tmforum.org/  The Open Group dispose d'un modèle de référence pour The Open Group has a Reference Model for Integrated Information Infrastructure (III - RM) qui se concentre sur les composants et services de niveau application nécessaires pour fournir une infrastructure d'information intégrée. 84 ADM: Architectures des Systèmes d’Information L’Architecture Application - Artifacts:  Application Portfolio Catalog  Application and User Location Diagram  Interface Catalog  Application Use-Case Diagram  Application/Organization Matrix  Enterprise Manageability Diagram  Role/Application Matrix  Process/Application Realization Diagram  Application/Function Matrix  Software Engineering Diagram  Application Interaction Matrix  Application Migration Diagram  Application Communication Diagram  Software Distribution Diagram 85 ADM: Architectures des Systèmes d’Information L’Architecture Application : Application Portfolio Catalog ▪ Fournit une base pour d'autres matrices et diagrammes ▪ Contient des composants d'application logiques et des composants d'application physiques ▪ Généralement, c’est le point de départ de la phase d'architecture d'application 86 ADM: Architectures des Systèmes d’Information L’Architecture Application : Application Communication Diagram ▪ Les interfaces peuvent être associées à des entités de données ▪ Les applications peuvent être associées à des services métier ▪ La communication doit être logique et ne doit montrer la technologie que là où elle est pertinente 87 ADM: Architectures des Systèmes d’Information L’Architecture Application : Application / Organization Matrix ▪ Affiche les unités organisationnelles prises en charge par les applications ▪ Aide à comprendre les exigences de prise en charge des applications ▪ Prend en charge l'analyse des écarts et détermine si des applications sont manquantes et doivent donc être créées ▪ Définit l'ensemble d'applications utilisé par une unité organisationnelle particulière 88 ADM: Architectures des Systèmes d’Information Sorties: Les sorties (outputs) peuvent inclure, sans toutefois être limitées à:  Vision de l'architecture (affinée et mise à jour, si applicable)  Déclaration des travaux d'architecture (mise à jour)  Principes business, objectifs, moteurs (validés)  Principes des données (validés ou nouveaux)  Document de définition de l'architecture (draft)  Spécification des exigences de l'architecture (draft)  Composants de l'architecture des données d'une feuille de route d'architecture  Composants d'architecture d'application d'une feuille de route d'architecture 89 ADM: Technology Architecture Objectifs:  Développer l'architecture technologique cible qui permet de réaliser la vision de l'architecture, les blocs de construction métier, données et applications cibles par le biais de composants technologiques et de services technologiques, d'une manière qui réponde à la déclaration des travaux d'architecture et aux préoccupations des parties prenantes  Identifier les composants candidats de la feuille de route de l'architecture en fonction des écarts entre les architectures technologiques de base et cibles 90 ADM: Technology Architecture Entrées: Les composants de l’architecture technologique nécessitent des informations d’entrée suivantes: 1. Entrées non architecturales:  Demande de travaux d'architecture  Évaluation des capacités  Plan de communication 2. Entrées architecturales:  Modèle organisationnel pour l‘Architecture Business (c-à-d. portée, contraintes, rôles, responsabilité, budget)  Framework d'architecture sur mesure (c-à-d. méthode, outils, livrables et artefacts, principes d'architecture)  Principes Technologiques  Déclaration des travaux d'architecture  Vision de l‘Architecture  Repository d‘Architecture (c-à-d. blocs de construction d'architecture, modèles de référence, normes d'organisation)  Document de définition de l'architecture (draft)  Spécification des exigences d'architecture (draft)  Composants d'architecture business, data et application d'une feuille de route d'architecture 91 ADM: Technology Architecture Etapes (Idem pour les phases B, C et D) :  Sélectionner des modèles de référence, des points de vue et des outils  Élaborer une description de l'architecture technologique de base  Élaborer une description de l'architecture technologique cible  Effectuer une analyse des écarts  Définir les composants candidats de la feuille de route  Résoudre les impacts sur l'ensemble du paysage architectural  Effectuer un examen formel des parties prenantes  Finaliser l'architecture technologique  Créer/mettre à jour le document de définition de l'architecture 92 ADM: Technology Architecture Approche: Technologies émergentes : ▪ Anticiper et être ouvert aux changements induits par la technologie ▪ Rechercher de nouvelles façons innovantes de fonctionner et d’améliorer l’entreprise ▪ L’architecture technologique doit saisir les opportunités de transformation disponibles grâce à l’adoption de nouvelles technologies ▪ Le TOGAF ADM permet au changement technologique de devenir un moteur et une ressource stratégique plutôt qu’un récepteur de demandes de changement ▪ L’architecture technologique peut à la fois stimuler les capacités de l’entreprise et répondre aux exigences du système d’information en même temps ▪ L’adoption rapide de technologies en évolution peut entraîner des discontinuités dans l’ensemble de l’entreprise. Utiliser les ressources du repository d’architecture : ▪ Services informatiques existants documentés dans le référentiel informatique ou le catalogue de services informatiques ▪ Modèles technologiques génériques pertinents pour le secteur d’activité de l’organisation ▪ Modèles de référence de The Open Group Technology (par exemple, III RM, Technical Reference Model TRM) 93 ADM: Technology Architecture Artifacts: Technology Portfolio Catalog ▪ Comprend le matériel, les logiciels d'infrastructure et les logiciels d'application ▪ Point de départ typique pour l'architecture technologique de la phase D ▪ Fournit un élément d’entrée pour d'autres matrices et diagrammes de l'architecture technologique 94 ADM: Technology Architecture Artifacts: Platform Decomposition Diagram Le diagramme de décomposition de la plateforme:  doit montrer les applications d'entreprise et les composants technologiques décomposés  couvre tous les aspects de la plateforme d'infrastructure et offre un aperçu de la plateforme technologique de l'entreprise  peut être étendu pour mapper la plateforme technologique aux composants d'application appropriés dans un domaine fonctionnel ou un processus spécifique.  peut afficher les détails des spécifications, tels que les versions de produits, le nombre de processeurs, etc. ou peut simplement être un « eye-chart» informel offrant un aperçu de l'environnement technique 95 ADM: Technology Architecture Sorties: Les sorties (outputs) peuvent inclure, sans toutefois être limitées à:  Vision de l'architecture (affinée et mise à jour, si applicable)  Déclaration des travaux d'architecture (mise à jour)  Principes business, objectifs, moteurs (validés)  Principes des données (validés ou nouveaux)  Document de définition de l'architecture (draft)  Spécification des exigences de l'architecture (draft)  Composants d'architecture technologique d'une feuille de route d'architecture 96 ADM: Opportunités & Solutions Objectifs:  Générer la version initiale complète de la feuille de route de l'architecture, sur la base de l'analyse des écarts et des composants candidats de la feuille de route de l'architecture des phases B, C et D  Déterminer si une approche incrémentale est nécessaire et, si tel est le cas, identifier les architectures de transition qui offriront une valeur business continue  Définir les blocs de construction de la solution (SBB) globaux pour finaliser l'architecture cible sur la base des blocs de construction de l'architecture (ABB) 97 ADM: Opportunités & Solutions Entrées:  Modèle organisationnel pour l‘Architecture Business (c-à-d. portée, contraintes, rôles, responsabilité, budget)  Framework d'architecture sur mesure (c-à-d. méthode, outils, livrables et artefacts, principes d'architecture)  Déclaration des travaux d'architecture  Vision de l‘Architecture  Repository d‘Architecture (c-à-d. blocs de construction d'architecture, modèles de référence, normes d'organisation)  Document de définition de l'architecture (draft)  Spécification des exigences d'architecture (draft)  Composants d'architecture business, data, application et technologie d'une feuille de route d'architecture (des phases B, C, D)  Demandes de changement pour les programmes et projets d'entreprise existants  Modèles et frameworks de gouvernance (c-à-d., portefeuille, programme, gestion de projet, planification des activités de l'entreprise, opérations/services) 98 ADM: Opportunités & Solutions Etapes : La phase E constitue le pont (bridge) entre l'architecture cible et la solution. Elle se concentre sur la manière de fournir (livrer) l'architecture.  Déterminer/confirmer les principaux attributs de changement de l'entreprise  Déterminer les contraintes business pour l’implémentation  Examiner et consolider les résultats de l'analyse des écarts des phases B à D  Examiner les exigences consolidées dans les fonctions business connexes  Consolider et rapprocher les exigences d'interopérabilité  Affiner et valider les dépendances  Confirmer l'état de préparation et le risque de transformation de l'entreprise  Formuler une stratégie d’implémentation et de migration  Identifier et regrouper les principaux lots de travail (work packages)  Identifier les architectures de transition  Créer la feuille de route de l'architecture et le plan d’implémentation et de migration 99 ADM: Opportunités & Solutions Etapes: Déterminer/confirmer les principaux attributs de changement de l'entreprise  Déterminer la meilleure façon d’implémentation de l'architecture d'entreprise pour tirer parti de la culture d'entreprise de l'organisation  Évaluer les capacités de transition des unités organisationnelles impliquées et de l'entreprise, y compris la culture, les capacités et les compétences  Créer un « catalogue de facteurs d’implémentation / Implementation Factor Catalog » servant de référentiel pour l’implémentation de l'architecture et les décisions de migration 100 ADM: Opportunités & Solutions Etapes: Déterminer les contraintes business pour l’implémentation  Identifier les facteurs business limitant la séquence de l’implémentation  Examen des plans business, des plans stratégiques et de l'évaluation de la maturité de l'AE  Les contraintes sont importantes pour l'élaboration de la feuille de route de l'architecture et du plan d’implémentation et de migration 101 ADM: Opportunités & Solutions Etapes: Examiner et consolider les résultats de l'analyse des écarts des phases B à D  Déterminer les dépendances à l'aide de la matrice d'interactions business, de la matrice d'entités de données/fonctions business et de la matrice d'applications/fonctions business  Identifier les blocs de construction de solutions (SBB) qui comblent une ou plusieurs lacunes et leurs blocs de construction d'architecture associés (ABB) à l'aide d'une matrice consolidée de lacunes, de solutions et de dépendances  Étudier les alternatives d'architecture cible avec les parties prenantes à l'aide de la méthode des alternatives d'architecture et des compromis (trade-offs) 102 ADM: Opportunités & Solutions Etapes: Examiner les exigences consolidées dans les fonctions business connexes  Évaluer les exigences, les lacunes, les solutions et les facteurs pour identifier un ensemble minimal d'exigences afin d'améliorer l'efficacité et l’implémentation effective de l'architecture cible  Regroupement fonctionnel des exigences en lots de travail pour satisfaire plusieurs exigences grâce à la fourniture de solutions et de services partagés Consolider et rapprocher les exigences d'interopérabilité  Consolider les exigences d'interopérabilité identifiées dans les phases précédentes  Examiner la vision de l'architecture, l'architecture cible, le catalogue des facteurs d'implémentation et la matrice des lacunes, des solutions et des dépendances consolidées pour identifier les contraintes d'interopérabilité requises par l'ensemble potentiel de solutions  Résoudre les conflits d'interopérabilité dans tous les domaines d'architecture en créant un bloc de construction de traduction (Translation Building Block) supplémentaire ou en modifiant un bloc de construction participant 103 ADM: Opportunités & Solutions Etapes: Affiner et valider les dépendances  Affiner les dépendances et identifier les contraintes sur les plans d’implémentation et de migration  Regrouper les activités en fonction de leurs dépendances pour créer une base pour les projets à établir  Déterminer la séquence d’implémentation, la coordination requise et le délai de livraison des incréments de solution en fonction des dépendances  Documenter les résultats dans la feuille de route de l'architecture et les architectures de transition Confirmer l'état de préparation et le risque de transformation de l'entreprise  Déterminer l'impact de l'évaluation de l'état de préparation à la transformation de l'entreprise sur la feuille de route de l'architecture et la stratégie d’implémentation et de migration  Identifier, classer et atténuer les risques associés à la transformation  Documenter les risques dans la matrice consolidée des lacunes, des solutions et des dépendances 104 ADM: Opportunités & Solutions Etapes: Formuler une stratégie d’implémentation et de migration  La stratégie d’implémentation et de migration guide la mise en œuvre de l'architecture cible et structure les architectures de transition 1. Déterminer une approche stratégique globale pour mettre en œuvre les solutions et/ou exploiter les opportunités ▪ Greenfield : mise en œuvre entièrement nouvelle ▪ Révolutionnaire : changement radical (i.e. switch on, switch off)) ▪ Évolutionnaire : stratégie de convergence (par exemple, fonctionnement parallèle, approche par phases pour introduire de nouvelles capacités) 2. Déterminer une méthodologie de mise en œuvre qui aborde et atténue les risques ▪ Gain rapide (Quick win / snapshots) ▪ Objectifs atteignables ▪ Méthode de la chaîne de valeur 3. Obtenir un accord sur la stratégie d’implémentation et de migration guidant la réalisation des transitions et des architectures cibles  Les approches et les dépendances constituent la base de la création de lots de travail. 105 ADM: Opportunités & Solutions Etapes: Identifier et regrouper les principaux lots de travail (work packages)  Évaluer les capacités business manquantes identifiées dans la vision de l'architecture et l'architecture cible  Regrouper les différentes activités de manière logique en lots de travail à l'aide de la matrice des lacunes, des solutions et des dépendances consolidées et du catalogue des facteurs d’implémentation  Décomposer les lots de travail de niveau supérieur en incréments réalisant une certaine capacité  Analyser les lots de travail et les incréments par rapport aux problèmes de transformation de l'entreprise et à l'approche d’implémentation (stratégique)  Regrouper les lots de travail en portefeuilles et projets au sein d'un portefeuille  Indiquer pour chaque lacune/activité si la solution doit: - être orientée vers un nouveau développement en interne ou via un contrat (externe) - être basée sur un produit existant avec des améliorations mineures et/ou - utiliser une solution qui peut être achetée  Classer chaque système actuel envisagé comme: - Mainstream : partie du futur système d'information - Contain : devrait être remplacé ou modifié dans l'horizon de planification (~ 3 ans) 106 - Replace : remplacé dans l'horizon de planification (~ 3 ans) ADM: Opportunités & Solutions Etapes: Identifier les architectures de transition  Utilisez des architectures de transition lorsque vous avez besoin d'une approche incrémentale  Assurez-vous qu'elles fournissent une valeur business mesurable  Développez des architectures de transition basées sur l'approche d’implémentation, la matrice consolidée des lacunes, des solutions et des dépendances, la liste des projets et des portefeuilles et la capacité de changement de l'entreprise  Implémentez des activités faciles qui fournissent les capacités manquantes avant les activités difficiles, à moins qu'il n'y ait des raisons impérieuses Créer la feuille de route de l'architecture et le plan d’implémentation et de migration  Consolider les lots de travail et les architectures de transition dans la feuille de route de l'architecture à un niveau de détail similaire à celui du document de définition de l'architecture  Créer le plan de mise en œuvre et de migration aligné sur les détails de la feuille de route de l'architecture  Mettre à jour la vision de l'architecture, le document de définition de l'architecture et la spécification des exigences de l'architecture 107 ADM: Opportunités & Solutions Approche: Quatre concepts pour passer du développement d'une architecture cible à la livraison d'une architecture cible : 1. Feuille de route de l'architecture: répertorie les lots de travaux dans un calendrier qui réaliseront l'architecture cible 2. Lots de travaux (work packages): regroupe les modifications nécessaires pour réaliser l'architecture cible 3. Architectures de transition: état significatif entre l'architecture de base et l'architecture cible (architectures cibles intermédiaires) 4. Plan d’implémentation et de migration: calendrier des projets qui réaliseront l'architecture cible 108 ADM: Opportunités & Solutions Sorties: Les sorties (outputs) peuvent inclure, sans toutefois être limitées à:  Vision de l'architecture (affinée et mise à jour)  Déclaration des travaux d'architecture (affinée et mise à jour)  Document de définition d'architecture (draft) comprenant les architectures de base et cibles pour tous les domaines BDAT (approuvés)  Évaluation des capacités  Feuille de route de l'architecture comprenant : - Work packages(y compris dépendances, valeur, …) - Architectures de transition - Recommandations d’implémentation (par exemple SBB, risques, …)  Plan d’implémentation et de migration (draft) comprenant une stratégie d’implémentation et de migration 109 ADM: Planning de Migration Objectifs:  Finaliser la feuille de route de l'architecture et le plan d’implémentation et de migration  Veiller à ce que le plan d’implémentation et de migration soit coordonné avec l'approche de l'entreprise en matière de gestion et d’implémentation des changements dans le portefeuille global des changements de l'entreprise  Veiller à ce que la valeur business et le coût des lots de travaux et des architectures de transition soient compris par les principales parties prenantes 110 ADM: Planning de Migration Etapes:  Confirmer les interactions du cadre de gestion pour le plan d’implémentation et de migration  Attribuer une valeur business à chaque lot de travail (work package)  Estimer les besoins en ressources, les délais du projet et les véhicules de disponibilité/livraison  Prioriser les projets de migration en effectuant une évaluation des coûts/bénéfices et une validation des risques  Confirmer la feuille de route de l'architecture et mettre à jour le document de la définition de l'architecture  Terminer le plan de d’implémentation et de migration  Terminer le cycle de développement de l'architecture et documenter les leçons apprises 111 ADM: Planning de Migration Etapes: Confirmer les interactions du cadre de gestion pour le plan d’implémentation et de migration  Coordonner le plan de mise en œuvre et de migration avec d'autres cadres de gestion (en particulier la planification d'entreprise, la gestion des processus, la gestion des projets/portefeuilles, la gestion des opérations)  Assurez-vous que le plan d’implémentation et de migration est coordonné avec les autres cadres de gestion dont vous avez besoin pour un changement réussi  Intégrer le plan d’implémentation et de migration dans les plans existants, si nécessaire 112 ADM: Planning de Migration Etapes: Attribuer une valeur business à chaque lot de travail  Établir ce qui constitue la valeur business et comment la valeur peut être mesurée  Établir et attribuer une valeur business à chacun des lots de travail  Identifier les projets qui figureront dans le plan d’implémentation et de migration en fonction des work packages  Estimer la valeur business de chaque projet et les incréments de projet à l'aide des techniques d'évaluation de la valeur business 113 ADM: Planning de Migration Etapes: Attribuer une valeur business à chaque lot de travail  Tenir compte de l'adéquation stratégique (strategic fit) lors de l'approbation de nouveaux projets et de la détermination de leur valeur  Définir la valeur business pour allouer des ressources afin de déterminer si un projet est à poursuivre, à retarder ou à annuler  Définir le succès d'un projet et/ou l'augmenter avec les facteurs critiques de réussite (Critical Success Factors / CSF)  Détailler et obtenir l'approbation des critères de retour sur investissement (Return On Investment / ROI)  Utiliser les mesures d'efficacité (Measures Of Effectiveness / MOE) comme critères de performance  Approuver et surveiller la progression de la transformation avec les critères d'évaluation des performances 114 ADM: Planning de Migration Etapes: Estimer les besoins en ressources, les délais du projet et les véhicules de disponibilité/livraison  Déterminer les ressources requises, les délais et les estimations de coûts initiaux (capital et opérations et maintenance) pour chaque projet et leurs incréments  Affecter des ressources à chaque projet et à chaque incrément de projet  Identifier les opportunités où les coûts peuvent être compensés par la mise hors service des systèmes existants 115 ADM: Planning de Migration Etapes: Prioriser les projets de migration en effectuant une évaluation des coûts/avantages et une validation des risques  Prioriser les projets en évaluant leur valeur business par rapport à leurs coûts 1. Déterminer le bénéfice net des blocs de construction de solutions (SBB) fournis par les projets 2. Vérifier que les coûts ont été pris en compte et que les risques ont été efficacement atténués 3. Obtenir un consensus sur une liste de projets prioritaires (y compris les commentaires liés aux risques) 4. Utiliser la priorisation des projets de migration comme base pour l'allocation des ressources  Examiner l'évaluation des risques pour s'assurer d'une compréhension complète du risque résiduel  Faire en sorte que les parties prenantes conviennent de la priorisation des projets et confirment les avantages, les coûts et les risques du projet 116 ADM: Planning de Migration Etapes: Confirmer la feuille de route de l'architecture et mettre à jour le document de la définition de l'architecture  Évaluer les délais idéaux entre les architectures de transition en fonction de la valeur, de la capacité et du risque des incréments et mettre à jour la feuille de route de l'architecture  Visualiser l'état proposé des architectures de domaine à différents niveaux de détail à l'aide du tableau d'évolution de l'état de l'architecture de transition  Aligner les projets et les architectures de transition à l'aide du tableau des incréments de définition de l'architecture  Mettre à jour le document de définition de l'architecture, si l'approche d’implémentation a changé suite à la confirmation des incréments d’implémentation  Réviser la feuille de route de l'architecture en consolidant les incréments par projet 117 ADM: Planning de Migration Etapes: Confirmer la feuille de route de l'architecture et mettre à jour le document de la définition de l'architecture Le tableau d'évolution de l'état de l'architecture de transition montre l'état proposé des architectures à différents niveaux 118 ADM: Planning de Migration Etapes: Confirmer la feuille de route de l'architecture et mettre à jour le document de la définition de l'architecture  Attribuer des objectifs de projet et aligner les projets sur les architectures de transition pour créer un tableau d'incréments de définition d'architecture  Le tableau d'incréments de définition d'architecture permet de planifier une série d'architectures de transition décrivant l'état de l'architecture d'entreprise à des moments précis 119 ADM: Planning de Migration Etapes: Terminer le plan de d’implémentation et de migration  Intégrer tous les projets, plans de projet, activités, dépendances internes et externes et l'impact du changement dans le plan d’implémentation et de migration  Assurer l'alignement sur les détails du document de définition de l'architecture  Effectuer une itération de planification de transition (cycle d'itération ADM entre les phases E et F) si les projets d’implémentation nécessitent un niveau de détail plus élevé. 120 ADM: Planning de Migration Etapes: Terminer le cycle de développement de l'architecture et documenter les leçons apprises  Gouvernance de transition « du développement à la réalisation » de l'architecture  Établir un modèle de gouvernance d’implémentation, si la maturité des capacités d'architecture le permet  Tirer les leçons et les informations apprises au cours du développement de l'architecture 121 ADM: Planning de Migration Approche:  Finaliser le plan d’implémentation et de migration en fonction de la feuille de route de l’architecture préliminaire et du plan d’implémentation et de migration préliminaire de la phase E  Intégrer les détails des niveaux portefeuille et projet au plan d’implémentation et de migration  Intégrer la feuille de route, le plan d’implémentation et de migration aux autres activités de changement de l'entreprise  Évaluer les dépendances, les coûts et les bénéfices des différents projets de migration  Documenter les leçons apprises pour permettre une amélioration continue des processus 122 ADM: Gouvernance de l’implémentation Objectifs:  Assurer la conformité des projets d'implémentation avec l'architecture cible  Mettre en place les fonctions de gouvernance d'architecture appropriées pour la solution et toute demande de changement d'architecture pilotée par l'implémentation 123 ADM: Gouvernance de l’implémentation Etapes:  Confirmer la portée et les priorités du déploiement avec le management du développement  Identifier les ressources et les compétences de déploiement  Guider le développement du déploiement des solutions  Effectuer des revues de conformité (compliance) de l'architecture d'entreprise  Implémenter les opérations business et IT  Effectuer une revue post-implémentation et clôturer l'implémentation 124 ADM: Gouvernance de l’implémentation Etapes: Confirmer la portée et les priorités du déploiement avec la direction du développement  Examiner les résultats de la planification de la migration et formuler des recommandations sur le déploiement  Identifier les priorités de l'EA, les problèmes de déploiement et les éléments de base à remplacer/mettre à jour  Effectuer une analyse des écarts sur l’EA et le framework des solutions et produire un rapport - Identifier les écarts et les SBB requises - S'assurer que les projets sont orchestrés s'ils fournissent une SBB ou une capacité ensemble 125 ADM: Gouvernance de l’implémentation Etapes: Identifier les ressources et les compétences de déploiement  Former les équipes de développement à l‘Architecture d‘Entreprise  Identifier les méthodes de développement système requises pour le développement des solutions  S'assurer que les méthodes permettent un retour d'information (feedback) à l'équipe d'architecture 126 ADM: Gouvernance de l’implémentation Etapes: Guider le développement du déploiement des solutions  Formuler des recommandations de projet et documenter les impacts (c-à-d. demandes de changement, changements de portée, changements de calendrier)  Documenter le contrat d'architecture  Mettre à jour le répertoire et le référentiel Enterprise Continuum pour les solutions  Guider le développement de modèles opérationnels business et IT pour les services  Fournir les exigences de service dérivées de l'architecture d'entreprise  Guider la définition des exigences opérationnelles business et IT  Effectuer une analyse des écarts entre l'architecture de la solution et les opérations  Produire le plan d’implémentation 127 ADM: Gouvernance de l’implémentation Etapes: Effectuer des revues de conformité de l'architecture d'entreprise  Examiner la conformité de l'architecture et implémenter la gouvernance des éléments constitutifs  Réaliser des revues post-développement  Clôturer le développement des projets de déploiement 128 ADM: Gouvernance de l’implémentation Etapes: Implémenter les opérations business et IT  Réaliser les projets de déploiement (y compris l’implémentation des services informatiques, des services business et des compétences et formations ainsi que la publication de la documentation)  Publier les nouvelles architectures de base dans le référentiel d'architecture 129 ADM: Gouvernance de l’implémentation Etapes: Effectuer une revue post-implémentation et clôturer l'implémentation  Réaliser des revues post-implémentation  Publier les revues et clôturer les projets  La clôture de la phase G aura lieu lorsque les solutions seront entièrement déployées 130 ADM: Gouvernance de l’implémentation Approche:  Étapes progressives / incrémentales vers l'architecture cible : - Chaque étape apporte de la valeur business - Réalisation précoce de la valeur business et des bénéfices - Minimiser les risques dans le programme de transformation et de migration  Établir un programme d’implémentation  Adopter un calendrier de déploiement par phases basé sur les priorités business  Suivre la norme de l'organisation en matière de gouvernance d'entreprise, IT et d'architecture  Utiliser l'approche de gestion des portefeuilles/programmes établie par l'organisation  Définir un framework opérationnel pour assurer la longue durée de vie efficace de la solution déployée  Développer les détails du projet (nom, descriptions, critères d'acceptation, mesures d'efficacité) 131 ADM: Gestion des Changements d‘Architecture Objectifs:  Assurer que le cycle de développement de l'architecture est maintenu  Assurer que le framework de gouvernance de l'architecture est exécuté  Assurer que la capacité d‘Architecture d‘Entreprise répond aux exigences actuelles 132 ADM: Gestion des Changements d’Architecture Etapes:  Établir un processus de réalisation de valeur  Déployer des outils de surveillance  Gérer les risques  Fournir une analyse pour la gestion des changements d'architecture  Élaborer des exigences de changement pour atteindre les objectifs de performance  Gérer le processus de gouvernance  Activer le processus d’implémentation du changement 133 ADM: Gestion des Changements d’Architecture Approche:  Le processus de gestion des changements détermine : - Les circonstances dans lesquelles l'architecture d'entreprise, ou des parties de celle-ci, seront autorisées à changer après l’implémentation, et le processus par lequel cela se produira - Les circonstances dans lesquelles le cycle de développement de l'architecture d'entreprise sera relancé pour développer une nouvelle architecture  Établir des critères pour juger si une demande de changement: - Mérite une mise à jour de l'architecture - Mérite le démarrage d'un nouveau cycle de l'ADM  Évaluer les changements en fonction de leur valeur business 134 ADM: Gestion des Changements d‘Architecture Approche:  Contenu d'une demande de changement : - Description du changement proposé - Justification du changement proposé - Évaluation de l'impact du changement proposé  Classification des changements : - Changement de simplification : géré via des techniques de gestion des changements - Changement incrémentiel : peut nécessiter une re-architecture partielle - Changement de re-architecture : nécessite un nouveau cycle de développement de l'architecture 135 ADM: Gestion des Exigences Objectifs:  Assurer que le processus de gestion des exigences est maintenu et fonctionne pour toutes les phases ADM pertinentes  Gérer les exigences d'architecture identifiées lors de toute exécution du cycle ADM ou d'une phase  Assurer que les exigences d'architecture pertinentes sont disponibles pour être utilisées par chaque phase au fur et à mesure de son exécution 136 ADM: Gestion des Exigences Approche:  Processus dynamique dans lequel les exigences de l‘Architecture d‘Entreprise et les modifications de ces exigences sont identifiées, stockées et alimentées dans et hors des phases ADM pertinentes, ainsi qu'entre les cycles de l'ADM  Les phases pertinentes de l'ADM éliminent, traitent ou hiérarchisent les exigences, et non le processus de gestion des exigences  Utiliser un référentiel d'exigences d'architecture pour enregistrer et gérer toutes les exigences d'architecture (recommandation)  Le référentiel d'exigences d'architecture peut contenir des informations provenant de plusieurs cycles ADM 137 ADM: Gestion des Exigences 138 ADM: Gestion des Exigences 139 TOGAF: Etude de cas 140 III.Transformation Digitale 141 Transformation Digitale: Concept ISO 56000 TOGAF Gartner TM Forum PMI (Innovation Management) La transformation digitale TOGAF considère la