Architecture d'entreprise

De nombreuses activités/processus d'affaires sont associés à une entreprise ; cependant, son objectif est de se concentrer sur les activités qui lui permettent d'atteindre ses objectifs actuels et futurs. Un processus d'affaires (business process) est une série d'étapes qu'un groupe de parties prenantes exécute pour atteindre un objectif concret ou un ensemble d'objectifs d'entreprise. Les objectifs actuels reflètent la mission et les stratégies à court terme d'une entreprise, tandis que les objectifs futurs reflètent sa vision et ses stratégies à long terme. Pour assurer le développement et l'exécution réussis de ces stratégies à court ou à long terme, une entreprise s'appuiera sur l'EA, comme le montre la Figure 10.10.

Figure 10.10 L'objectif de la EAM est de fournir des capacités d'entreprise pour maintenir les solutions d'affaires alignées avec la stratégie de l'entreprise. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Comme illustré à la Figure 10.11, l'EA suit les exigences d'un modèle d'exploitation préétabli, aide à établir des limites stratégiques significatives, soutient la gestion des capacités d'affaires essentielles qui permettent le développement d'une plateforme d'affaires pour l'exécution des tâches d'affaires courantes, et permet aux gens de se concentrer sur l'amélioration de l'entreprise plutôt que de simplement la gérer. Une base pour l'exécution est une combinaison d'infrastructure IT (c'est-à-dire matériel, logiciel, communication et données) et de processus numérisés qui automatisent les capacités d'affaires essentielles de l'entreprise. L'objectif de la base pour l'exécution est de développer l'alignement entre la stratégie d'affaires et la stratégie IT. La création et le maintien d'une base pour l'exécution reposent sur le modèle d'exploitation de l'entreprise, la feuille de route d'adoption de la stratégie et une vue de son architecture de référence. Une feuille de route (road map) est utilisée pour guider une organisation dans la planification et la réalisation des objectifs d'affaires au fil du temps grâce à la technologie.

Figure 10.11 Cette figure représente la conception de la base de l'EA pour l'exécution. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Figure 10.12 illustre divers modèles d'exploitation connus sous les noms de diversification, coordination, réplication et unification. Ces modèles correspondent à des variations dans la manière dont les processus d'affaires sont standardisés et intégrés.

Figure 10.12 Les modèles d'exploitation connus sous les noms de diversification, coordination, réplication et unification correspondent à la manière dont les processus d'affaires sont standardisés et intégrés. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

La stratégie IT de l'entreprise est basée sur un ensemble collectif de principes. Ces principes forment un cadriciel cohérent pour la prise de décision technologique et reflètent un niveau de consensus parmi les groupes technologiques de parties prenantes clés. Les groupes technologiques comprennent la haute direction, le conseil d'architecture et les architectes principaux. La Figure 10.13 montre que les principes sont destinés à guider la prise de décision à tous les niveaux et sont organisés en affaires, information, application et infrastructure.

Figure 10.13 Le cadre d'organisation comprend les principes de sécurité de l'information, les principes de livraison technologique, les principes d'architecture d'entreprise, les principes de conception architecturale et les principes de gouvernance IT. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Figure 10.14 résume les capacités d'entreprise typiques au sein de diverses unités d'affaires telles que la fabrication, l'entreprise et la technologie.

Figure 10.14 Les capacités d'entreprise typiques au sein de diverses unités d'affaires telles que la fabrication, l'entreprise et la technologie sont présentées. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

L'investissement dans la technologie peut avoir des impacts possibles, tels que des objectifs, des attentes souhaitées et des métriques. En ce qui concerne les objectifs, nous estimons de nombreux facteurs, tels que le temps requis, les informations sur les livrables, le coût de la qualité et les extrants. Dans l'attente souhaitée, nous évaluons le projet (par exemple, bon projet, bon coût, bon calendrier et bonnes ressources). Dans les métriques, nous mesurons la demande d'investissement, la satisfaction des employés et la qualité de service (c'est-à-dire la disponibilité et le coût). La Figure 10.15 illustre l'impact possible des initiatives d'investissement dans les capacités technologiques telles qu'elles sont organisées dans la section plan et solution, intégrées dans la section solutions et déployées dans des produits livrés aux clients. Le processus commencera par la planification des solutions et des investissements, puis la construction des solutions, et, enfin, l'exécution des solutions.

Figure 10.15 Il existe de nombreux impacts possibles des initiatives d'investissement dans les capacités technologiques. Chaque section liste les capacités et/ou impacts assignés. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Les dirigeants d'affaires et technologiques sont responsables de s'assurer qu'un projet IT atteint les objectifs de la division et de l'entreprise en collaborant avec les architectes d'entreprise. L'EA est une pratique évolutive qui demande du temps, des investissements et de la patience. Elle devrait fournir un cadre stratégique aux organisations pour gérer les perturbations technologiques en alignant les systèmes IT sur les objectifs d'affaires, tout en aidant les décideurs à mettre en œuvre des changements qui favorisent l'innovation, la résilience et l'efficacité pour garantir que les initiatives à court terme et les projets à long terme peuvent contribuer au succès de l'entreprise.

Une organisation de soins de santé de premier plan visait à réduire les coûts opérationnels tout en rationalisant les soins aux patients. Ils ont utilisé les EA pour identifier le besoin d'un système de données unifié. Le système devait intégrer les dossiers des patients, la facturation et les services de télémédecine. L'équipe EA a présenté des recommandations, notamment l'adoption de plateformes basées sur l'infonuage et de flux de travail automatisés. Cela a aidé l'organisation à gérer les perturbations d'affaires, à minimiser les silos de données et à améliorer la prestation de services. Le projet s'est aligné sur les objectifs de la division, démontrant comment les pratiques d'EA peuvent stimuler la transformation stratégique en réponse aux défis de l'industrie.

Alignement des stratégies d'affaires et technologiques

L'alignement des stratégies d'affaires et technologiques est généralement difficile de manière continue en raison du manque d'alignement avec les initiatives axées sur l'entreprise. L'architecture d'entreprise aide à aligner les stratégies d'affaires et technologiques, comme illustré à la Figure 10.16. Cet alignement est un processus continu et est réalisé à travers le cycle de vie de l'alignement affaires-IT.

Figure 10.16 Le cycle de vie de l'alignement affaires-IT est un processus d'amélioration continue qui aide à aligner les stratégies d'affaires et technologiques. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Le cycle de vie de l'alignement affaires-IT aide les organisations à aligner leurs objectifs d'affaires sur les stratégies IT à travers différentes étapes. La première étape est l'initiation, qui implique la vérification du problème auquel l'entreprise est confrontée ou des opportunités disponibles. La deuxième étape est la stratégie, qui implique la conception de solutions. La troisième étape est la planification, qui implique de planifier comment implémenter la solution. La quatrième étape est l'exécution, et elle implique l'implémentation de la solution. La dernière étape est l'évaluation, qui implique l'évaluation de la solution.

L'équipe d'entreprise doit être prudente lors du développement de l'alignement affaires-IT car les solutions d'affaires de l'entreprise peuvent manquer d'alignement avec l'initiative axée sur l'entreprise. En d'autres termes, les solutions d'affaires devraient prendre en compte les directives architecturales établies au niveau de l'entreprise et ne pas simplement réinventer la roue. La Figure 10.17 montre les quatre symptômes qui peuvent conduire au manque d'alignement.

Figure 10.17 Lorsque les quatre symptômes ne se chevauchent pas, les solutions d'affaires de l'entreprise manquent d'alignement avec les initiatives axées sur l'entreprise. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Le premier symptôme apparaît lorsque la solution créée n'est pas alignée avec l'objectif de l'entreprise. Le deuxième apparaît lorsque les solutions d'affaires ne sont pas livrées à temps et dans le respect du budget ou si le résultat n'atteint pas la qualité attendue. Le troisième apparaît lorsqu'il est difficile de maintenir le système ou la solution. Le quatrième symptôme apparaît lorsqu'il est difficile de faire évoluer les solutions d'affaires.

En plus de l'alignement, la gestion de l'architecture d'entreprise utilise des facilitateurs pour fournir des capacités d'entreprise afin de maintenir les solutions d'affaires alignées avec la stratégie de l'entreprise. Un facilitateur (enabler) soutient les activités nécessaires pour étendre la piste architecturale afin de fournir des fonctionnalités d'affaires futures. La Figure 10.18 montre cinq types différents de facilitateurs, qui sont listés dans le Tableau 10.1.

Figure 10.18 La gestion de l'architecture d'entreprise fournit des capacités d'entreprise, appelées facilitateurs, pour maintenir les solutions d'affaires alignées avec la stratégie de l'entreprise. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Figure 10.19 Cette figure montre comment la méthodologie générique de gestion du changement Conscience-Désir-Connaissance-Capacité-Renforcement de la EAM s'applique dans le contexte d'un motif de processus de modélisation axée sur les motifs d'affaires. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Cadriciels d'architecture d'entreprise

La EAM est une pratique de gestion qui établit, maintient et utilise un ensemble cohérent de lignes directrices, de principes d'architecture et de régimes de gouvernance qui fournissent une direction et une aide pratique dans la conception et le développement de l'architecture d'une entreprise pour atteindre sa vision et sa stratégie. La EAM rassemble les connaissances hautement distribuées de tous les experts et permet à chaque participant de fournir ces connaissances et ces entrées dans des termes qui correspondent le mieux à l'expérience et aux attentes des parties prenantes contributrices.

Comme l'EA et la EAM considèrent l'entreprise comme un système vaste et complexe ou un système de systèmes,3 il est nécessaire de gérer l'échelle et la complexité de ce système. Pour répondre à cette exigence, un cadre d'architecture d'entreprise (EAF) (enterprise architecture framework (EAF)) fournit des outils et des approches qui garantissent que les solutions d'entreprise sont en alignement avec la vision et la stratégie évolutives des organisations qui utilisent ces solutions pour fonctionner et mener leurs activités quotidiennes. Les EAF fournissent des orientations structurées qui sont divisées en trois domaines principaux :

1. Descriptions de l'architecture : comment documenter l'entreprise en tant que système
2. Méthodes de conception de l'architecture : processus d'architecture d'entreprise global composé de phases et décomposé en processus de niveau inférieur composés d'activités plus granulaires
3. Organisation des architectes : conseils sur la structure de l'équipe et la gouvernance de l'équipe, y compris les compétences, l'expérience et la formation nécessaires

Pour décrire les architectures, les EAF emploient des modèles de données flexibles construits sur des métamodèles qui fournissent des aperçus évolutifs des capacités et des relations. À un niveau élevé, les EAF fournissent des principes fondamentaux, un cadre d'organisation, une méthode complète et cohérente, ainsi qu'un ensemble de processus et de structures de gouvernance, comme illustré à la Figure 10.20.

Figure 10.20 Cette vue de haut niveau de l'architecture de référence EAF montre les principaux composants : principes, cadriciel, méthode et gouvernance. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

L'architecture de référence est construite sur des principes. Un principe (principle) forme les règles fondamentales qui guident sa conception et son implémentation. L'architecture de référence utilise des termes architecturaux ainsi que de nombreux principes, politiques et lignes directrices pour gouverner l'architecture. Le cadriciel sert de structure d'organisation et décrit les domaines et disciplines architecturaux pour assurer la séparation des préoccupations et l'alignement entre les objectifs d'affaires et l'IT. La méthode (method) consiste en des processus définis et reproductibles qui assurent une exécution cohérente et contrôlée de l'architecture de référence. Les processus et les structures organisationnelles qui assurent l'adhérence à l'architecture de référence sont considérés comme de la gouvernance (governance).

À mesure que la pratique de l'EA évolue, les cadriciels EAF de soutien qui permettent aux communautés et aux entreprises d'appliquer l'EA évoluent également. En effet, à mesure que la complexité des solutions augmente, l'ingéniosité nécessaire pour la maîtriser doit s'améliorer continuellement. En fait, les stratégies d'architecture jouent un rôle énorme et toujours croissant dans la détermination du succès d'une entreprise. La prochaine génération de EAF est axée sur la création d'écosystèmes dynamiques et d'architectures connexes qui apportent de la valeur à tous les participants d'affaires via des systèmes d'information qui intègrent et facilitent les décisions à travers les systèmes d'enregistrement (c'est-à-dire, axés sur les coûts), les systèmes d'opérations/automatisation (c'est-à-dire, axés sur les dépenses d'exploitation [Opex]), les systèmes de conception (c'est-à-dire, axés sur l'innovation) et les systèmes d'engagement (c'est-à-dire, axés sur l'expérience client). La Figure 10.21 montre l'évolution des cadriciels d'EA qui a eu lieu au fil des ans.

Figure 10.21 Ce graphique montre la représentation des relations entre les facteurs IT/d'affaires et l'évolution IT au fil du temps. L'évolution s'étend du mainframe à l'informatique intelligente. Le cadriciel d'EA de nouvelle génération optimisera les actifs humains, physiques et environnementaux. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

L'architecture englobée par cette nouvelle génération d'écosystèmes est illustrée à la Figure 10.22. Elle repose sur diverses couches qui peuvent être modélisées (à l'aide de EAF de nouvelle génération) comme suit :

• Les modèles de confiance garantissent que tous les participants au sein de l'écosystème partagent et s'accordent sur des valeurs supplémentaires plutôt que de fonctionner uniquement pour des profits financiers (par exemple, respecter la confidentialité, garantir la sécurité, fournir une valeur orientée client et des valeurs sociales, améliorer le niveau de qualité) ainsi que des résultats partagés, y compris des externalités telles que la pollution ou la réglementation.
• Les modèles d'affaires garantissent que les valeurs identifiées dans les modèles de confiance sont partagées et que des modèles d'affaires peuvent être établis qui répartissent la marge et les revenus entre les participants de l'écosystème.
• Les modèles d'orchestration optimisent la répartition des responsabilités et orchestrent les services pour offrir les meilleures valeurs aux clients au juste prix/qualité (par exemple, le parcours d'expérience numérique de navigation des liens ou les cartes de parcours des flux de connaissances vers les services et processus au niveau de l'écosystème). Les modèles de services partagés incluent les services de données et d'applications de support.
• Les réseaux d'affaires permettent le partage des processus et des données ; par exemple, les applications infonuagiques partagées entre partenaires dans les réseaux d'affaires numériques via un mélange d'architectures partagées et multi-locataires.

Figure 10.22 À l'aide des EAF de nouvelle génération, diverses couches peuvent être modélisées comme des modèles de confiance, des modèles d'affaires, des modèles d'orchestration, des modèles de services partagés et des réseaux d'affaires. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Pour fournir un support adéquat, les EAF de nouvelle génération doivent fournir un ensemble étendu de capacités génériques dans le cadre d'un méta-cadriciel sous-jacent. Un méta-cadriciel (meta-framework) décrit le cadriciel plus en détail, comme illustré à la Figure 10.23. Clairement, ces capacités vont au-delà de la modélisation et des fonctionnalités connexes et doivent s'étendre aux exigences des EAF en matière d'automatisation IT, de gouvernance IT et de gestion du contexte IT. L'automatisation IT (IT automation) est le processus de création de systèmes pour réduire l'intervention manuelle. La gouvernance IT (IT governance) est le processus qui assure l'utilisation efficace et efficiente de l'IT pour permettre à une organisation d'atteindre ses objectifs. La gestion du contexte IT (IT context management) est un processus IT dynamique qui utilise les données d'une application pour pointer vers des données résidant dans une application distincte.

Figure 10.23 Les exigences des EAF en matière d'automatisation IT, de gouvernance IT et de gestion du contexte IT sont présentées. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Il existe de nombreux exemples de EAF, tels que TOGAF, Gartner Enterprise Architecture, C4ISR, CORBA, Federal Enterprise Architecture, Zachman Framework, et bien d'autres. Chacun des EAF suit un format spécifique et utilise une spécification différente.

Le Tableau 10.2 présente des exemples de EAF et leurs spécifications.

Le Cadre d'architecture de l'Open Group

Le Cadre d'architecture de l'Open Group (TOGAF) (The Open Group Architecture Framework (TOGAF)) est une méthodologie d'EA et un cadriciel utilisé par les organisations de premier plan pour améliorer l'efficacité d'affaires. TOGAF se concentre sur les éléments de méthodes cohérentes, de normes et de communication. TOGAF permet aux organisations de suivre une approche systématique du processus de développement afin de réduire les erreurs, de gérer les délais, de respecter le budget planifié et les éléments de portée, et de disposer de processus efficaces pour produire des résultats de qualité. TOGAF aide les praticiens à éviter d'être enfermés dans des méthodes propriétaires, à utiliser les ressources plus efficacement et à réaliser un meilleur retour sur investissement.

En 1995, le développement original de TOGAF Version 1 a été publié en tant que modèle de référence pour l'architecture d'entreprise, offrant une compréhension de l'infrastructure technique propre au Département de la Défense des États-Unis, y compris sa structure, sa maintenance et sa configuration pour s'aligner sur des exigences spécifiques (Figure 10.24). À ce jour, TOGAF est une méthode détaillée et un ensemble d'outils de support pour le développement d'une architecture d'entreprise. Il peut être utilisé librement par toute organisation souhaitant développer une architecture d'entreprise pour une utilisation au sein de cette organisation.

Figure 10.24 Cette chronologie montre le développement de TOGAF au fil du temps. La première version date de 1995, et la version la plus récente de 2018. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

TOGAF est le cadriciel largement utilisé pour établir et définir l'architecture d'entreprise ; il présente une approche de planification, de conception, d'implémentation et de gouvernance de l'architecture des technologies de l'information au niveau de l'entreprise. Il se concentre principalement sur quatre structures modulaires, qui incluent l'application, les affaires, la technologie et les données. L'objectif principal de la définition du cadriciel TOGAF était d'avoir un modèle architectural qui peut être répliqué avec peu d'erreurs à chaque phase progressive. L'établissement d'un langage commun et d'un mécanisme de compréhensibilité comble le fossé entre l'IT et les affaires en apportant de la clarté à l'information, en établissant une méthodologie et en fournissant des guides d'implémentation pratiques.

La norme TOGAF inclut la méthode d'élaboration d'architecture (ADM) (Architecture Development Method (ADM)), qui est un processus détaillé étape par étape pour développer ou modifier une architecture d'entreprise. Elle permet également de modifier un cadriciel de contenu pour aider à accroître la cohérence des extrants créés lors de l'utilisation de l'ADM (Figure 10.25). Le cadriciel de contenu TOGAF fournit un modèle détaillé des produits de travail architecturaux. Les architectures de systèmes communs sont utilisées par de nombreuses entreprises. Les architectures industrielles sont spécifiques à l'industrie, tandis que les architectures organisationnelles sont spécifiques à l'entreprise.

Figure 10.25 Le composant le plus générique du continuum est l'architecture de fondation, qui est utilisable par toute organisation IT. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Les catégories de motifs sont les motifs de spécification, les motifs de vision, les motifs de processus, les motifs de gouvernance, les motifs de migration, les motifs d'utilisabilité, les motifs d'information, les motifs d'affaires et les motifs d'interopérabilité. Les phases suggérées par l'ADM sont les suivantes :

• Phase Préliminaire. Cette phase définit les principes d'entreprise, les principes IT et les principes d'architecture (c'est-à-dire, comment faisons-nous l'architecture ?). Elle n'est pas considérée comme faisant partie du cycle ADM, car elle peut être revisitée à tout moment du cycle. Cette phase implique l'organisation et la gouvernance de l'architecture, ses principes généraux, ses méthodes, ses outils et le dépôt d'architecture, et constitue le point de départ à partir duquel une organisation entame un cycle ADM. Les extrants de cette phase sont la définition du cadriciel, les principes d'architecture et la référence aux principes et objectifs d'une organisation.
• Phase A : Vision de l'architecture. C'est la première phase du cycle ADM et elle commence par la réception d'une demande de travail d'architecture au sein d'une organisation commanditaire. Au cours de cette phase, une organisation établit le projet, identifie les objectifs d'affaires, examine les principes d'architecture et d'affaires, définit la portée et les contraintes d'un effort d'architecture basé sur une évaluation de la disponibilité des ressources et des compétences, et identifie les parties prenantes et les exigences d'affaires. Une vision est développée concernant l'organisation, l'orientation, la feuille de route, l'architecture de référence et les risques du projet. Au final, une entreprise dispose d'un document d'énoncé de travail d'architecture à soumettre pour approbation. La phase A est celle où l'organisation répond aux questions de savoir où nous allons, comment nous y arrivons et avec qui.
• Phase B : Architecture d'affaires. Au cours de cette phase, une organisation décrit l'architecture d'affaires de référence qui existe actuellement et l'architecture d'affaires cible qu'elle s'efforcera d'implémenter. L'étape suivante consiste à créer des modèles d'architecture d'affaires, la structure organisationnelle, les buts et objectifs d'affaires, les fonctions d'affaires, les services d'affaires, les processus d'affaires, les règles d'affaires, la corrélation de l'organisation et de la fonction, et les rapports d'analyse des compromis. Pour ce faire, une analyse des écarts et une modélisation doivent être effectuées pour et entre les architectures d'affaires de référence et cibles. L'analyse des écarts comprend les personnes, les processus, les outils, l'information, la mesure, les aspects financiers et les installations. Une telle modélisation peut inclure une variété d'outils, y compris des modèles d'activité, des modèles de cas d'utilisation, des modèles de classes, des diagrammes de connectivité de nœuds et des matrices d'échange d'informations. La Figure 10.26 illustre les activités communes à plusieurs phases.

Figure 10.26 Les phases B, C et D de l'ADM de TOGAF représentent de multiples activités qui incluent la description de l'architecture de référence, la description de l'architecture cible, la mesure des écarts, l'évaluation de l'impact et l'élaboration de la feuille de route. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

• Phase C : Architecture des systèmes d'information. L'architecture des systèmes d'information est composée des sous-phases d'architecture de données et d'architecture d'application. Le cadre de conception qui structure la manière dont les données sont collectées, stockées, gérées et utilisées au sein d'un système est appelé architecture de données (data architecture). Les motifs utilisés pour concevoir et implémenter une application sont considérés comme son architecture d'application. L'objectif de cette phase est de développer des architectures cibles couvrant l'une ou l'autre des sous-phases, ou les deux, selon la portée du projet. Les processus d'affaires pris en charge dans cette phase sont ceux qui sont pris en charge par l'informatique, ainsi que les interfaces de ces processus avec les processus non liés à l'informatique.
  L'architecture de données examine et sélectionne les principes, les modèles de référence, les points de vue et les outils. Elle crée des modèles d'architecture de données pour chaque point de vue, tels que le cadre d'architecture C4ISR et la carte du modèle de données conceptuel vers l'architecture d'affaires. Ensuite, elle effectue une analyse des compromis, de la complétude et de la conformité. Après cela, elle sélectionne les blocs de construction de l'architecture de données, effectue une révision de point de contrôle du modèle d'architecture, examine les critères qualitatifs, complète l'architecture de données, effectue une analyse de point de contrôle/d'impact, réalise une analyse des écarts et crée des rapports.
  Les sous-phases d'architecture d'application développent une description de l'architecture d'applications de base ; examinent et valident les principes d'application en sélectionnant des modèles de référence, des points de vue et des outils ; créent des modèles d'architecture pour chaque point de vue ; identifient les applications candidates (c'est-à-dire l'architecture d'affaires et l'architecture de données) ; effectuent une révision de point de contrôle ; examinent les critères qualitatifs ; complètent l'architecture d'applications ; réalisent une analyse des écarts ; et créent un rapport.
• Phase D : Architecture technologique. Le but de cette phase est de développer une architecture technique qui définit les plateformes et les environnements d'exécution sur lesquels les applications de l'organisation s'exécutent et les sources de données sont hébergées. Les étapes clés de cette phase sont :
  1. Développer la description de l'architecture technique de base dans la mesure requise pour soutenir l'architecture technique cible.
  2. Développer l'architecture technique cible en considérant différents modèles de référence d'architecture, points de vue et outils. Ensuite, créer un modèle d'architecture de blocs de construction, sélectionner le portefeuille de services requis par bloc de construction, confirmer que les buts et objectifs d'affaires sont atteints, choisir les critères de sélection des spécifications, compléter la définition de l'architecture et réaliser une analyse des écarts.
• Phase E : Opportunités et solutions. La phase E identifie les principaux moteurs d'affaires, les paramètres de changement, les phases majeures requises et les projets entrepris pour faire évoluer l'organisation vers l'environnement cible. La phase E examine l'analyse des écarts (c'est-à-dire l'étude de l'écart entre le système actuel et le système futur), réalise une évaluation de l'architecture et identifie les progiciels pour les projets. Cette phase implique également l'étude des exigences et contraintes techniques, organisationnelles et financières du projet.
• Phase F : Planification de la migration. Au cours de cette phase, les différents projets nécessaires à la mise en œuvre de l'architecture sont classés par ordre de priorité en fonction des dépendances et de l'évaluation coûts-avantages des différents projets. Les calendriers de migration (c'est-à-dire décrivant le calendrier, les tâches et les ressources nécessaires), l'évaluation des risques (c'est-à-dire l'identification et l'analyse des risques potentiels), les objectifs du projet (c'est-à-dire définissant les buts et les résultats), les constitutions du projet (c'est-à-dire décrivant les principes principaux du système), la feuille de route de mise en œuvre (c'est-à-dire les étapes à suivre dans la mise en œuvre) et les organisations de projet sont établis.
• Phase G : Gouvernance de l'implémentation. Cette phase établit la version finale des contrats d'architecture qui régissent le processus global d'implémentation et de déploiement et implique l'élaboration de recommandations pour chaque projet d'implémentation. La gouvernance de l'implémentation a pour fonction de garantir que les projets d'implémentation sont conformes à l'architecture cible définie. Les étapes de cette phase sont :
  1. Formuler des recommandations de projet
  2. Documenter le contrat d'architecture
  3. Établir un processus d'examen de la conformité de l'architecture
• Phase H : Gestion des changements d'architecture. Cette phase établit le processus par lequel le déploiement de l'architecture est géré. La gestion des changements d'architecture assure une surveillance continue des facteurs susceptibles d'affecter le processus de mise en œuvre, tels que les demandes de changement, les nouveaux développements technologiques ou les changements dans l'environnement d'affaires. De tels facteurs peuvent déclencher de nouveaux cycles ADM à mesure que le projet évolue. Les étapes impliquées sont :
  1. Surveiller les changements technologiques
  2. Surveiller les changements d'affaires
  3. Évaluer les changements
  4. Tenir des réunions du comité d'architecture

L'architecture de fondation de TOGAF énonce ce qui suit :

• Blocs de construction d'architecture et normes
• Services et fonctions génériques pour construire des services spécifiques
• Modèle de référence technique
• Base d'informations sur les normes

TOGAF fournit également un continuum d'entreprise qui aborde le continuum d'architecture (Architecture Continuum) et le continuum de solutions, ainsi qu'une gouvernance de l'architecture avec des lignes directrices relatives à ce qui suit :

• Gestion et contrôle des travaux d'architecture au niveau de l'entreprise
• Référentiels
• Contrôle du flux de processus
• Comité d'architecture, y compris la conformité de l'architecture et les contrats
• Détails du processus et du contenu (Tableau 10.3)

Feuille de route d'adoption stratégique

L'EA est généralement utilisée par les entreprises pour produire un plan (blueprint) de l'état futur et une feuille de route pour y parvenir.

Le passage des entreprises à des modèles opérationnels allégés et flexibles affecte directement la manière dont leurs architectes informatiques conçoivent les futures solutions d'affaires, où il est nécessaire de permettre le nouveau modèle opérationnel en faisant progresser les capacités d'affaires grâce à des processus d'affaires et des solutions correspondantes efficacement intégrés et standardisés. L'EA assure l'alignement des architectures d'affaires avec les architectures de solution en fournissant une vue holistique qui relie tous les domaines d'architecture par le biais d'une architecture de référence d'entreprise.

Le résultat de ce travail, produit par un processus et une méthodologie de planification intégrés, aligne et séquence les investissements informatiques pour atteindre de manière optimale les stratégies des entreprises. L'élaboration de la feuille de route s'appuie sur trois domaines architecturaux distincts :

• Architecture d'affaires
• Architecture de solutions d'affaires
• Architecture de solutions informatiques

La feuille de route d'adoption résulte de la planification de l'implémentation, comme illustré à l'étape 8 de la Figure 10.27. La création d'une feuille de route nécessite une évaluation de l'état actuel, une définition de l'état futur et une analyse des écarts.

Figure 10.27 Voici les étapes d'adoption d'une feuille de route. La première étape est l'évaluation de l'état actuel, suivie de la définition de l'état futur, et la dernière étape est la mise en œuvre de la feuille de route. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

La création d'une définition de modèle d'état futur nécessite une compréhension des besoins de l'état futur et la définition d'une stratégie cible basée sur divers moteurs d'affaires et informatiques, comme illustré à la Figure 10.28.

Figure 10.28 Les moteurs d'affaires et informatiques définissent le besoin de l'état futur et la manière dont il sera validé par les individus et les parties prenantes. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Le développement des moteurs d'affaires nécessite une évaluation de la dynamique du changement nécessaire pour maintenir l'activité. Les entreprises utilisent souvent les cinq forces de Porter illustrées à la Figure 10.29 pour analyser la dynamique d'affaires. Pour garantir qu'un produit est compétitif sur le marché, vous devez étudier ces facteurs : existe-t-il une barrière à l'entrée sur le marché ? Y a-t-il des concurrents qui rivalisent avec le prix de votre produit ? Existe-t-il une menace de produits de substitution ? Quel est le pouvoir des acheteurs et des fournisseurs ?

Figure 10.29 La dynamique d'affaires peut être analysée à l'aide des cinq forces de Porter : les barrières à l'entrée, la rivalité interne, les menaces de substitution, le pouvoir des fournisseurs et le pouvoir des acheteurs. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Architectures d'affaires et techniques d'entreprise

Un diagramme d'architecture de référence peut être utilisé pour créer une vue de l'architecture d'entreprise d'une société. Par exemple, la compagnie aérienne fictive Airlines a opté pour un modèle opérationnel d'unification, et son architecture de référence est représentée à la Figure 10.30. Dans l'environnement concurrentiel actuel, Airlines se concentre sur les produits et services à travers la chaîne de valeur pour augmenter la satisfaction client et le profit de l'entreprise.

Figure 10.30 L'architecture d'entreprise d'Airlines comprend le pipeline d'expérience client pour prendre en charge le système Airlines avec des événements et pour créer des relations entre les enregistrements. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

La Figure 10.31 illustre comment divers actifs d'architecture technique d'affaires et d'entreprise peuvent être représentés. L'architecture technique est divisée en trois couches : les modèles de capacités d'affaires de l'état futur (par exemple, responsabilité de gestion, réclamations, finance et parties prenantes MIS), les besoins d'affaires pour les trois à cinq prochaines années, et le modèle d'architecture technologique pour soutenir les besoins d'affaires évolutifs en ce qui concerne les bonnes pratiques et les objectifs stratégiques informatiques.

Figure 10.31 L'architecture technique est divisée en trois couches : les modèles de capacités d'affaires de l'état futur, les besoins d'affaires et le modèle d'architecture technologique. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Ces actifs sont des dessins architecturaux appelés plans (blueprints) et sont stockés dans un catalogue d'actifs selon leurs domaines et niveaux d'abstraction. Différents modèles UML et plans fournissent des détails architecturaux de haut niveau destinés à aider à visualiser la vue d'ensemble. La Figure 10.32 montre différents niveaux d'abstraction, y compris conceptuel, logique et physique.

Figure 10.32 Se concentrer davantage sur un domaine d'application dans l'entreprise fournit plus de détails sur le niveau d'abstraction. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Cadres de processus d'architecture d'entreprise et motifs associés

Divers motifs (patterns) de processus peuvent être appliqués pour créer des actifs d'architecture d'entreprise. Les EAF tels que TOGAF implémentent des processus spécifiques et fournissent des motifs et des modèles qui peuvent être suivis pour dériver des actifs d'architecture d'entreprise. TOGAF fournit un métamodèle d'architecture qui permet des adaptations de contenu afin de répondre aux exigences spécifiques de l'entreprise. Un métamodèle (metamodel) fournit des aperçus évolutifs des capacités et des relations. La Figure 10.33 illustre un plan d'architecture d'affaires. Le plan représente l'orientation client, la gestion des risques et financière, la gestion et le support d'affaires basés sur le produit, et les ventes et/ou services.

Figure 10.33 La gestion d'affaires se concentre sur le client et gère le risque pour les produits, les ventes et les services. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

La Figure 10.34 illustre un exemple de plan d'architecture d'application (système d'information). Le plan représente les participants, l'interaction via des passerelles d'affaires électroniques, les processus, les services, les composants (components), les données sur tous les composants, les règles et les services techniques.

Figure 10.34 Cette représentation d'exemple du plan d'un système d'information montre tous les composants et leurs relations mutuelles. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

La Figure 10.35 illustre un exemple de plan d'architecture de l'information. Le plan montre les relations entre les magasins de données transactionnelles (par exemple, base de données qui suit les transactions quotidiennes pour un magasin), le magasin de données opérationnelles (par exemple, base de données qui suit les transactions quotidiennes pour tous les magasins), l'entrepôt de données (par exemple, système de gestion des données qui facilite les requêtes d'analyse et de veille stratégique au niveau de l'entreprise), et les magasins de données (par exemple, système de gestion des données qui facilite les requêtes d'analyse et de veille stratégique au niveau d'une unité commerciale ou d'un département). Après l'exécution du bus de données, l'étape de rapport et d'analyse commence à produire des rapports opérationnels, des rapports de gestion, des rapports analytiques et des fichiers de commerce électronique. Le plan pour l'architecture d'entreprise aide à aligner la stratégie d'affaires et informatique, et fournit une vision claire de la façon dont la technologie soutient les objectifs de l'entreprise. De plus, c'est un outil de référence principal pour coordonner la collaboration entre les différents composants de l'entreprise.

Figure 10.35 Cette représentation d'exemple du plan pour l'architecture de l'information montre les relations entre les composants. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

La Figure 10.36 illustre un exemple de plan d'architecture d'infrastructure technologique. Ce plan (blueprint) montre trois types de clients différents :

1. Client navigateur qui utilise le navigateur pour accéder au service web Internet
2. Client omniprésent qui utilise un réseau public/privé pour accéder à la passerelle
3. Service partenaire avec une base de données qui utilise un réseau public/privé pour accéder à la passerelle

De plus, le plan représente le niveau d'interaction et de sécurité pour chaque utilisateur afin d'accéder à l'application d'intégration et au bus de données.

Figure 10.36 Cette conception montre une représentation d'exemple du plan d'architecture d'infrastructure technologique. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Modèles de plans

Un plan d'architecture d'entreprise est une visualisation de l'architecture aux niveaux conceptuel, logique et physique d'une entreprise, montrant les concepts, leurs éléments, et les composants qui implémentent les éléments et leurs interrelations. Divers modèles de plans sont disponibles pour aider à dériver des diagrammes d'architecture. La Figure 10.37 illustre un modèle qui peut être utilisé pour créer des architectures d'affaires conceptuelles. Le diagramme montre comment le modèle peut être appliqué dans le contexte de l'industrie de l'assurance. Le diagramme représente la chaîne de valeur de l'entreprise, qui comprend les ventes et le marketing, le développement de produits, la souscription, la finance et la comptabilité, le service et le traitement des réclamations. Le plan comprend de nombreux composants et services, tels que les processus BPM, les capacités d'affaires et les services d'affaires.

Figure 10.37 Le diagramme représente la chaîne de valeur de l'entreprise, qui comprend les ventes et le marketing, le développement de produits, la souscription, la finance et la comptabilité, le service et le traitement des réclamations. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Pour spécifier l'architecture d'affaires conceptuelle de l'élément de la chaîne de valeur de souscription, la Figure 10.38 approfondit l'élément de la chaîne de valeur "souscription".

Figure 10.38 La souscription est un élément de la chaîne de valeur et intègre les nouvelles affaires et l'exécution. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

La représentation des modèles d'architecture logique à l'aide d'un modèle de plan est différente. La Figure 10.39 illustre un plan pour le modèle d'architecture logique, montre la séparation des préoccupations par la superposition, et permet une forte cohésion et un faible couplage à travers le composant d'application. Ce plan représente l'intégration d'interaction, l'intégration de processus de bus, l'intégration d'applications, l'intégration de services, l'intégration de données et l'intégration d'infrastructure. L'utilisation de ce modèle aide à créer un modèle d'architecture logique détaillé qui peut ensuite être divisé en couches séparées pour transmettre des détails plus lisibles.

Figure 10.39 Ce plan représente l'intégration d'interaction, l'intégration de processus d'affaires, l'intégration d'applications, l'intégration de services, l'intégration de données et l'intégration d'infrastructure. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Styles architecturaux et d'implémentation

Comme vous vous en souvenez peut-être, la spécification des architectures commence à un niveau élevé au sein de l'entreprise pour aider à aligner la stratégie d'affaires et informatique. Les stratégies principales visent généralement à atteindre l'excellence opérationnelle ainsi que la compétitivité. La Figure 10.40 représente la relation entre le client et l'entreprise pour améliorer l'expérience client numérique et l'excellence opérationnelle numérique. Les rôles d'architecte de l'expérience client numérique développent la stratégie d'architecture pour un cycle de vie client, collaborent à la conception de produits et services numériques, et guident le choix technologique du client. Les rôles d'excellence opérationnelle numérique guident l'intégration avec les partenaires de l'écosystème, soutiennent l'innovation technologique et co-développent la stratégie d'agilité.

Figure 10.40 La relation entre le client et l'entreprise peut améliorer l'expérience client numérique et l'excellence opérationnelle numérique. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Cela conduit à la création d'architectures de référence d'entreprise et de plans d'architecture d'affaires et technique spécifiques qui représentent les différentes vues de l'architecture au sein des domaines d'affaires, d'application, d'information et de technologie. La portée de ces vues peut ensuite être affinée pour approfondir des unités d'affaires spécifiques et des architectures au niveau du projet. Au sein de chaque niveau de portée, il est possible d'appliquer des styles architecturaux (architectural styles) et des styles d'implémentation correspondants disponibles dans un catalogue de motifs (pattern catalog). Comme nous l'avons appris, les motifs peuvent être appliqués aux architectures au niveau du projet dans le cadre de la conception de haut niveau et en tirant parti de l'activité cadre de gestion de l'architecture.

Les styles architecturaux et d'implémentation peuvent être reflétés dans les plans. Par exemple, la Figure 10.41 représente comment un plan d'architecture technique conceptuelle tire parti du style architectural de gestion des processus d'affaires. Le diagramme répond à six questions :

1. Qui initie l'événement d'affaires ?
2. Quelle est la classification du type d'événement d'affaires ?
3. Quels canaux sont fournis pour initier l'événement d'affaires ?
4. Quelle est la méthode utilisée pour numériser les événements d'affaires reconnus ?
5. Comment les événements d'affaires sont-ils gérés numériquement pendant leur cycle de vie ?
6. Quelles automatisations, organisations et processus sont nécessaires pour soutenir la gestion numérique des événements d'affaires ?

Figure 10.41 Un plan d'architecture technique conceptuelle tire parti du style architectural de gestion des processus d'affaires. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

La Figure 10.42 illustre un plan d'architecture d'implémentation technique qui tire parti de styles d'implémentation spécifiques, et la Figure 10.43 illustre la même chose avec des légendes identifiant les produits spécifiques et les fournisseurs associés sélectionnés pour implémenter et déployer la solution.

Figure 10.42 Un plan d'architecture d'implémentation technique tire parti de styles d'implémentation spécifiques. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Figure 10.43 Les légendes ajoutées à l'architecture d'implémentation technique présentée précédemment spécifient les produits et les fournisseurs associés sélectionnés pour implémenter et déployer la solution. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Architectures informatiques centrées sur l'humain et motifs associés

L'informatique centrée sur l'humain est un terme plus récent qui englobe l'interaction humain-machine et inclut l'informatique sociale et l'HCI. La HCC étudie la conception, le développement et le déploiement de systèmes humain-machine à initiative mixte. La HCC/HCI est un sous-domaine de l'informatique qui s'intéresse à l'étude de l'interaction entre les personnes et les ordinateurs.

L'objectif principal de la HCC/HCI est de rendre les systèmes informatiques plus conviviaux et plus utilisables. L'HCI étudie la conception, l'évaluation et l'implémentation d'interfaces utilisateur pour des systèmes informatiques réceptifs aux besoins et aux habitudes de l'utilisateur. C'est un domaine multidisciplinaire, qui intègre l'informatique, les sciences comportementales et le design. Le domaine de l'informatique cherche fondamentalement à fournir un cadriciel (framework) pour l'intégration des sciences humaines et de l'informatique d'une manière qui favorise le progrès des activités humaines. À cet égard, les modèles d'informatique centrée sur l'humain conçoivent des systèmes informatiques qui soutiennent et enrichissent l'existence humaine.

Les utilisateurs interagissent avec les systèmes informatiques par le biais d'une interface utilisateur, qui se compose de matériel et de logiciel qui fournit des moyens d'entrée, permettant aux utilisateurs de manipuler le système, et de sortie, permettant au système de fournir des informations à l'utilisateur. La conception, l'implémentation et l'évaluation des interfaces sont donc un objectif central de la HCC/HCI. Des motifs de processus correspondants sont appliqués lors de la conception des architectures HCC/HCI. Des cadriciels basés sur des motifs peuvent être utilisés pour étudier, analyser et traduire les interactions des personnes avec leur environnement en architectures de solution collaboratives.

Architectures basées sur l'infonuage et motifs associés

De grands infonuages sont disponibles aujourd'hui pour aider à assembler des solutions complexes dans un contexte d'entreprise en fournissant des capacités de plateforme en tant que service (Platform as a Service) qui peuvent être assemblées très rapidement. Par exemple, l'architecture d'implémentation basée sur l'infonuage présentée à la Figure 10.44 utilise trois infonuages différents (infonuage de médias sociaux pour la collecte de données, nuage privé pour l'analyse prédictive et nuage public pour l'exploration de données). Ces infonuages collaborent dans une configuration de mashup et offrent un moyen rentable de concevoir et d'implémenter des architectures de solution qui tirent parti des motifs (patterns) de collecte de données, d'exploration de données sécurisée et d'analyse intelligente. Des implémentations de cadriciels de traitement de données évolutifs sont également facilement disponibles sur les grands infonuages pour fournir des moyens efficaces de gérer de grandes quantités de données.

Figure 10.44 Trois infonuages différents, comprenant un infonuage de médias sociaux pour la collecte de données, un nuage privé pour l'analyse prédictive et un nuage public pour l'exploration de données, collaborent dans une configuration de mashup. (source : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Architectures de microservices et motifs associés

Une architecture de microservices, appelée microservice (microservice), est une approche de construction d'une solution logicielle comme un ensemble de petits services (c'est-à-dire des parties indépendantes) qui peuvent être déployés localement ou sur l'infonuage. L'infonuage (cloud) contient des données, des logiciels et des services qui s'exécutent sur Internet au lieu d'un ordinateur local. Bien que les architectures de microservices soient principalement orientées vers la fourniture de services backend, l'approche est également utilisée pour activer les frontaux des solutions. Chaque service s'exécute dans son propre processus et communique avec d'autres processus en utilisant des protocoles tels que HTTP/HTTPS, WebSockets ou AMPQ. Chaque microservice implémente une capacité d'affaires spécifique dans une certaine limite de contexte, et chacun doit être développé de manière autonome et être déployable indépendamment. Enfin, chaque microservice devrait posséder son modèle de données de domaine et sa logique de domaine associés et pourrait être basé sur différentes technologies de stockage de données telles que SQL ou NoSQL, et différents langages de programmation. La Figure 10.45 illustre de nombreux motifs associés aux architectures de microservices tels que les motifs de motivation et les motifs de solution. Plusieurs hôtes de service, base de données par service, jeton d'accès et API de vérification de l'état de santé sont des exemples de microservices. À un niveau élevé, les microservices offrent une agilité à long terme et permettent une meilleure maintenabilité dans les systèmes complexes, grands et hautement évolutifs en rendant possible la création d'applications basées sur de nombreux services déployables indépendamment qui ont chacun des cycles de vie granulaires et autonomes.

Figure 10.45 Plusieurs hôtes de service, base de données par service, jeton d'accès et API de vérification de l'état de santé sont des exemples de microservices. (source de données : C. Richardson, "Microservice Architecture pattern," https://microservices.io/patterns/microservices.html; attribution : Copyright Rice University, OpenStax, sous licence CC BY 4.0)

Un avantage supplémentaire est que les microservices peuvent être mis à l'échelle indépendamment. Au lieu d'avoir des applications monolithiques uniques qui doivent être mises à l'échelle en tant qu'unités, des microservices spécifiques peuvent être mis à l'échelle à la place. Cela permet de mettre à l'échelle uniquement la zone fonctionnelle qui a besoin de plus de puissance de traitement ou de bande passante réseau pour répondre à la demande, plutôt que de mettre à l'échelle d'autres zones de l'application qui n'ont pas besoin d'être mises à l'échelle, ce qui entraîne des économies de coûts car moins de matériel est requis.