Découvrir la puissance des modèles d'architecture d'entreprise : un guide complet
- Que sont les modèles d’architecture d’entreprise ?
- Pourquoi les modèles d’architecture sont-ils importants ?
- Modèles d'architecture d'entreprise TOGAF
- Modèle de modèle d'architecture d'entreprise
- Les modèles d'architecture existent dans tous les domaines d'architecture
- Modèles d'architecture d'entreprise
- Modèles d'architecture de données
- Modèles d'architecture de sécurité
- Modèles d'architecture d'infrastructure
- Modèles d'architecture d'application
- Modèles d'acquisition du système
- Conclusion du modèle d'architecture

Que sont les modèles d'architecture d'entreprise ?
Un modèle d'architecture fournit une approche commune à un problème prévisible. Il décrit le problème et comment le problème peut être résolu.
Nous utiliserons deux modèles :Modèle opérationnel CISR et motif étrangleur—pour explorer une approche commune et un problème prévisible.
Tous ceux qui ont tenté de migrer un portefeuille informatique ont été confrontés au problème des applications, des infrastructures et des données héritées. Les anciens processus, organisation et gestion rendent difficile le changement de département. Le problème prévisible est de savoir comment avancer tout en restant en affaires ? Le modèle étrangleur propose une approche commune : l’ancienne approche est placée derrière une façade. Au fil du temps, de nouveaux services remplacent les anciens.
Aucun modèle opérationnel unique ne s’applique partout. Le problème prévisible est le suivant : comment organisez-vous les départements, les produits et les services ? Le modèle opérationnel du CISR propose une approche commune : choisissez d'être unifié, coordonné, diversifié ou répliqué.
Aucun de ces modèles ne vous indique exactement comment procéder. Ils vous donnent une approche commune. Ils identifient les défis spécifiques de l’approche. Ils fournissent un modèle d'architecture.
Les modèles d'architecture sont décrits comme "une idée qui a été utile dans un contexte pratique et qui le sera probablement dans d’autres.»
Pourquoi les modèles d'architecture d'entreprise sont-ils importants ?
Les modèles d'architecture d'entreprise sont importants en raison de la productivité. Nous savons que les architectes d'entreprise les plus productifs sont 50 à 100 fois plus efficace que la moyenne. La racine est réutilisée. L'utilisation de modèles signifie que l'architecte ne commencer à partir de zéro. Comme un modèle n’est pas une solution globale, il permet d’éviter le piège courant des experts en la matière appliquant la même réponse dans diverses situations.
L'utilisation de modèles d'architecture permet d'équilibrer un l'individualité de l'organisation et les défis partagés de l’industrie. Les modèles d'architecture d'entreprise facilitent la prise de décision en apportant certitude et compréhension.
Avantages de l'utilisation de modèles d'architecture
Les modèles d'architecture offrent des avantages similaires à ceux architectures de référence et cadres d'architecture d'entreprise. Les modèles d'architecture augmentent la productivité et la confiance.
Nous utilisons des modèles d'architecture pour :
- Travaillez sur le changement le plus efficace, sans réinventer la roue
- Améliorer la confiance dans le fait que l'architecture couvre les difficultés et propose des réponses efficaces
- Simplifier compromis architectural
- Réponses et approches préférées en cascade
- Améliorer la confiance dans la réussite des mises en œuvre
- Simplifiez l’évaluation de la solution lors de la gouvernance de la mise en œuvre
Les modèles d'architecture d'entreprise vous fournissent un modèle pour résoudre les problèmes. Ils peuvent être utilisés dans différents contextes et apporter des solutions solides à des problèmes courants. Ils fournissent un certain niveau d’assurance et aident à orienter la prise de décision.
Quel que soit le modèle d’architecture d’entreprise utilisé, les inconvénients sont inévitables. Lorsque l’on examine des modèles, il est important de comprendre quels compromis sont faits.
Différence entre l'architecture de référence et les modèles d'architecture
Les modèles d'architecture et les architectures de référence sont des concepts utilisés dans tous les domaines. domaines d'architecture d'entreprise— les affaires, les applications, les données, la technologie et la sécurité. Les modèles d'architecture sont le plus souvent associés à l'architecture d'application ou de logiciel.
Des distinctions techniques existent entre architecture de référence et un modèle d'architecture. Cependant, les distinctions s'estompent à mesure que les détails du projet d'architecture changent. Un modèle applicable à architecture pour soutenir la stratégie, ou portefeuille, ressemble à une architecture de référence pour la livraison de projets et de solutions. En bref, les principales différences sont :
- Portée du problème: les modèles d'architecture ont toujours un problème. L'architecture de référence n'a peut-être pas de problème. Le Modèle d'étrangleur ne sera jamais considérée comme une architecture de référence.
- Adaptabilité: Les modèles d'architecture peuvent être adaptés à plusieurs projets et domaines. Les architectures de référence sont souvent liées à un contexte spécifique. Une architecture de référence pour la chaîne d’approvisionnement des biens de consommation sera difficile à adapter.
- Spécificité du domaine: Les architectures de référence sont généralement conçues pour des industries ou des technologies spécifiques. Les modèles d'architecture sont plus universels.
En résumé, les modèles d'architecture offrent des conseils et des approches de haut niveau pour résoudre les défis architecturaux courants. Notre concentration pendant créer une architecture d'entreprise est de fournir des conseils utiles plutôt que de se soucier des différences sémantiques.
Puissance des modèles d'architecture d'entreprise
Un modèle d'architecture d'entreprise vous indique une approche commune et éprouvée pour résoudre un problème prévisible. Les descriptions de modèle vous indiquent où se situe le défi lié à l'utilisation du modèle. Vous n'avez pas besoin d'inventer une solution. Vous examinez les solutions connues et déterminez celle qui convient le mieux à votre entreprise. Vous concentrez votre temps et vos compétences sur la fourniture des avantages de l'architecture d'entreprise.
Modèle de modèle d'architecture d'entreprise
Dans Naviguer, nous avons un modèle simple pour documenter les modèles d'architecture :
- Nom : une étiquette qui a une signification et reste gravé dans votre mémoire
- Problème prévisible (cas d'utilisation) : quel problème commun est en train d'être résolu
- Approche: Une description de la manière d'atteindre les buts et objectifs visés
- Morceaux durs : quels travaux sont nécessaires ou quelles limitations ont un impact sur la réussite de l'utilisation du modèle

Les modèles d'architecture existent dans tous les domaines d'architecture
Les modèles d'architecture peuvent être utilisés dans d'autres domaines au-delà de l'architecture des logiciels et des applications. Appliquez la technique – approche courante à un problème prévisible.
Voici quelques exemples de la manière dont les modèles d’architecture peuvent être appliqués en dehors de l’architecture des applications :
- Modèles d'architecture d'entreprise: Face à un problème tel que l'amélioration de l'efficacité, ils proposent des approches communes. Le modèle de numérisation et le modèle d’amélioration Lean ont des approches différentes pour résoudre le même problème.
Modèles de fusion et acquisition (M&A): Face à un problème comme une fusion, ils proposent des approches communes. Le modèle de diversification du marché définira les processus commerciaux, l'organisation, les capacités clés, les relations et les flux d'informations différemment du modèle d'expansion géographique.
- Modèles d'architecture technologique: Face à un problème tel que la modernisation informatique, ils proposent des approches de conception d'infrastructure telles que le modèle à trois niveaux ou le modèle sans serveur. Ces modèles définissent des approches très différentes d’une infrastructure évolutive et fiable dont on sait qu’elle fonctionne. La sélection entre ces modèles sera basée sur le contexte et les bits durs.
- Modèles d'architecture de données: Étant donné un problème tel que les informations personnelles et la protection des données nationales, ils fournissent un modèle tel que le modèle de masquage des données. Ce modèle fournit des approches cohérentes pour remplacer et masquer les données là où elles ne sont pas accessibles.
- Modèles d'architecture de sécurité: Face à une problématique de protection des systèmes informatiques contre les menaces, ils proposent des modèles comme Zero Trust Pattern ou Immutable Infrastructure Pattern. Ces modèles répondent à des problèmes de sécurité qui se chevauchent.
- Modèles d'architecture d'application: Il existe un riche ensemble de modèles d’architecture d’application. À commencer par la Bande des Quatre. De nombreux modèles d'application classiques résolvent des problèmes de conception logicielle. Les modèles d'architecture d'application peuvent être basés sur la conception, comme le modèle de pont ; approche de modernisation, comme le modèle Strangler, ou d'acquisition, comme le modèle d'acquisition de système modulaire. Les modèles de modernisation et d’acquisition peuvent être facilement adaptés aux problèmes commerciaux et d’infrastructure.
- Modèles d'acquisition du système: Face à un problème tel que la gestion des coûts, ils proposent différentes approches pour acquérir des systèmes informatiques. Le modèle de consolidation des fournisseurs et le modèle d'adoption de l'Open Source proposent des approches très différentes de gestion des coûts informatiques. Comme les autres alternatives architecturales, la sélection entre ces modèles sera basée sur le contexte et les bits durs.
- Architecture d'entreprise et modèles d'engagement agiles: Nous les utilisons lorsque développer des équipes EA. En fonction de la cas d'utilisation de l'architecture d'entreprise et le besoin de gouvernance, il existe différents modèles d'engagement avec Agile.
Même si la terminologie et les spécificités peuvent varier d'un domaine à l'autre, le concept de modèles d'architecture, fournissant des approches réutilisables et éprouvées pour résoudre des problèmes courants, est universel.
L’avantage pour les architectes d’entreprise est toujours la productivité et la qualité. Un architecte peut rationaliser son travail, améliorer son efficacité et garantir le respect des meilleures pratiques. La clé est d’adapter et de personnaliser ces modèles pour répondre aux exigences et contraintes uniques du domaine spécifique.
Modèles d'architecture d'entreprise
Les modèles d'architecture métier sont des approches réutilisables pour structurer une organisation. Les organisations utilisent ces modèles pour aligner leurs objectifs commerciaux, leurs opérations et leur technologie afin de favoriser l'efficacité et l'innovation. Voici quelques modèles d’architecture d’entreprise courants :
- Modèle de numérisation (automatisation des processus métier)
Problème prévisible-améliorer l'efficacité
Approche—automatiser les activités de routine et manuelles - Modèle d'amélioration Lean
Problème prévisible—améliorer l'efficacité et la qualité
Approche—suivre les principes Lean et les méthodologies Six Sigma pour améliorer progressivement les processus métier. - Modèle de collaboration écosystémique
Problème prévisible— méthode de collaboration avec des partenaires externes, des fournisseurs, des clients et des parties prenantes
Approche—collaborer au sein d'un écosystème
Ces modèles aident les entreprises à comprendre, à améliorer et à aligner leurs opérations et leurs stratégies. Les organisations peuvent adapter et combiner ces modèles en fonction de leurs objectifs et défis commerciaux spécifiques.
Modèles de fusion et d'acquisition (M&A) d'architecture d'entreprise
Les modèles d’acquisition d’entreprises sont des moyens par lesquels les entreprises acquièrent d’autres activités. Ces modèles aident les organisations dans leurs démarches de fusions et acquisitions et leurs objectifs stratégiques. Voici quelques exemples de modèles d’acquisition d’entreprise :
- Modèle d'intégration verticale
Problème prévisible—améliorer le contrôle de la chaîne d'approvisionnement, réduire les coûts et améliorer l'efficacité
Approche— rechercher des acquisitions tout au long de la chaîne d'approvisionnement pour assurer le contrôle de chaque étape, ajuster la chaîne d'approvisionnement pour utiliser les étapes internes et rechercher une efficacité de bout en bout - Modèle de diversification du marché
Problème prévisible—risques associés aux fluctuations du marché et aux ralentissements économiques
Approche-acquérir des entreprises sur différents marchés ou secteurs pour réduire la dépendance à l'égard d'un seul segment de marché, puis effectuer des ventes croisées - Modèle d'acquisition de technologie
Problème prévisible—les risques et le temps associés au développement de technologies innovantes et au retard sur les concurrents
Approche — concentrer les acquisitions sur les organisations développant de nouvelles technologies, puis intégrer la technologie dans les opérations existantes et nouvelles - Modèle d'expansion de la base de clientèle
Problème prévisible—risques, délais et coûts liés à la croissance de la clientèle
Approche-acquérir des organisations ayant une clientèle établie dans de nouvelles zones géographiques et de nouveaux marchés. Les entreprises acquièrent des sociétés ayant une forte notoriété de marque ou une grande - Modèle axé sur la synergie
Problème prévisible— gagner en efficacité d'échelle
Approche-concentrer les acquisitions sur des organisations similaires en termes de marché, de produits et de proposition de valeur, puis standardiser les opérations pour plus d'échelle et d'efficacité - Modèle d'expansion géographique
Problème prévisible : risque, temps et coûts liés à l'expansion des opérations dans une nouvelle zone géographique
Approche— concentrer les acquisitions sur des cibles proposant des produits et services similaires et une proposition de valeur dans de nouvelles zones géographiques. Puis rationalisez les produits, les services et les opérations - Modèle de redressement (actifs en difficulté)
Problème prévisible—croissance de la valeur actionnariale à un rythme acceptable
Approche-Acquérir des entreprises en difficulté ou en difficulté, puis appliquer leur expertise en gestion et leurs capitaux pour les redresser - Modèle de capacité
Problème prévisible—les risques, les coûts et le temps associés au développement des capacités commerciales
Approche —identifier les principales lacunes en matière de capacités et concentrer l'acquisition sur les organisations qui démontrent leurs capacités, puis remplacer l'organisation, les processus, la technologie et la propriété intellectuelle existants par les capacités acquises
Ces modèles d’acquisition d’entreprises servent d’approches connues à des problèmes prévisibles. Le choix du modèle dépend des objectifs stratégiques de l'entreprise et du paysage industriel.
Nous utilisons ces modèles pour vous aider analyse de scénarioCes modèles représentent des activités courantes choix utilisés pour développer un scénario.
Architecture d'entreprise et modèles d'engagement agiles
Ensemble, l'architecture d'entreprise et l'agilité réduisent les risques. L'architecture est utilisée pour réduire les risques et les coûts avant de commencer la mise en œuvre. Agile réduit les risques et les coûts une fois la mise en œuvre commencée.
Nous avons créé des modèles d'architecture d'entreprise et d'engagement Agile tout en travaillant sur Transformation numérique projets:
- Définir le modèle d'approche agile
- Modèle de produit
Problème prévisible: D'où vient le produit ?
Approche: Ajuster la définition des « solutions » utilisées pour combler les lacunes et les résultats des lots de travaux afin de les aligner sur les produits autonomes. Développer un portefeuille de produits interne et un ensemble de mesures de valeur pour les produits internes. Les produits doivent apparaître sur le feuille de route architecturale. - Modèle de plate-forme
Problème prévisible: Quand faut-il utiliser une plateforme et quand le produit doit-il être sans contrainte ?
Approche: Approches multiples - Modèle de stratégie de prestation de services
Problème prévisible: Comment votre organisation va-t-elle assurer un développement agile ?
Approche: Suivre les approches de l'Architecture pour soutenir la Stratégie. Posez la question de savoir comment le développement agile sera activé. - Modèle de point de repos de valeur majeure
Problème prévisible: Connaître la valeur du point de repos pour arrêter ou changer de focus.
Approche : utilisez les feuilles de route de l'architecture pour explorer des points de livraison de valeur alternatifs. Créer des rapports sur l'activité vers les états de transition.
- Modèle de produit
- Guider le backlog dans le modèle de sprint
- Feuille de route pour guider le modèle de produit
Problème prévisible: Avoir une feuille de route multi-produits intégrée.
Approche: Utilisation d'un technique de feuille de route d'architecture où le produit, ou la famille de produits, remplace le portefeuille. Veiller à ce que les rapports normaux sur les produits incluent les activités vers les états de transition. - Feuille de route pour guider le modèle épique
Problème prévisible: Utiliser des épopées pour implémenter des résultats et des contraintes descendantes dans le produit.
Approche: Utiliser des états de transition bien construits dans un technique de feuille de route d'architecture où le produit, ou la famille de produits, remplace le portefeuille. Veiller à ce que les rapports normaux sur les produits incluent les activités vers les états de transition. - Modèle de valeur d'entreprise
Problème prévisible: Veiller à ce que les facteurs critiques de succès inclus dans les états de transition et les états cibles guident la préparation agile du backlog et la planification épique.
Approche: Traduisez les mesures et les objectifs descendants en critères consommables pour une gestion agile du backlog. Veiller à ce que les rapports normaux sur les produits incluent la sélection des activités et leur réalisation par rapport à la valeur indiquée. - Contraindre le modèle de Product Owners « ascendant »
Problème prévisible: Les propriétaires de produits voient l'ensemble de l'entreprise à travers le prisme de leur produit et de ses utilisateurs directs.
Approche: Documenter le produit et le rôle au sein de l'écosystème. Documenter les contraintes qui s'appliquent au produit. Documenter les critères d’évaluation. Veiller à ce que les rapports normaux sur les produits incluent les progrès vers les états de transition et les activités alignées sur la valeur de l'entreprise.
- Feuille de route pour guider le modèle de produit
- Contraindre le modèle de sprints
- Modèle de critères d'acceptation
Problème prévisible: Garantir que les logiciels sont conformes aux spécifications et aux normes de l'architecture d'entreprise.
Approche: Fournir des critères d'acceptation obligatoires applicables à la fin des epics et avant la sortie. Nous avons souvent utilisé Modèles d'architecture d'application et Modèles d'architecture de données pour créer des critères d’acceptation. Incluez des critères d’acceptation obligatoires dans tous les rapports de test. - Modèle de valeur (mesures et points de repos)
Problème prévisible: Comprendre ce qui est valorisé et comment la valeur est mesurée.
Approche: L'architecture d'entreprise doit être définitive sur la façon dont la valeur est décrite et mesurée. Les énoncés de valeurs nécessitent des facteurs critiques de succès (CSF) et des mesures d'efficacité (MoE). Assurez-vous que les mesures de valeur sont incluses dans les rapports sur les produits, les épopées et les versions. - Modèle Greenfield, Evolution ou Révolution
Problème prévisible: S'assurer que la stratégie de mise en œuvre est suivie.
Approche: Utiliser la feuille de route du produit et les cycles de publication pour imposer des changements radicaux d'approche. - Contraindre le modèle d'interfaces
Problème prévisible: Identifier les interfaces requises et s'assurer qu'elles sont utilisées.
Approche: Concentrer le travail descendant sur les interfaces et les structures de données partagées. Introduisez les exigences à travers les cycles épiques et de publication. Utilisez des critères d’acceptation. Nous avons souvent utilisé Modèles d'architecture d'application et Modèles d'architecture de données à des interfaces légèrement spécifiques. Incluez la conformité de l’interface dans tous les rapports de tests.
- Modèle de critères d'acceptation
- Résoudre le modèle de dépendance
- Débloquez le modèle de portefeuille
Problème prévisible: Un conflit au sein du portefeuille de produits numériques bloque la progression de plusieurs produits.
Approche: Utiliser les techniques d'architecture d'entreprise pour trouver les changements minimaux pour permettre de progresser. - Identifier le modèle réel des parties prenantes
Problème prévisible: Identifier la véritable partie prenante qui peut fournir une orientation et une approbation à travers un portefeuille de produits interne complexe.
Approche: Utiliser des techniques d'architecture d'entreprise pour identifier les parties prenantes et les agents des parties prenantes, leurs préoccupations et leurs préférences. Utiliser les techniques d'architecture d'entreprise de alternatives et troquer pour guider les parties prenantes vers une décision qui orientera le portefeuille de produits. Assurer une gouvernance efficace du portefeuille numérique. - Traverser le modèle de portefeuille
Problème prévisible: Les décisions tactiques optimisées localement ne peuvent pas émerger comme un écosystème numérique efficace et durable.
Approche: Maintenir juste assez Architecture des applications et Architecture de données. Pilotez la priorité organisationnelle dans cette architecture. L'architecture des applications doit être axée sur les services et les interfaces partagés. L'architecture des données doit se concentrer sur les données de base, les données de référence et les données avec une classification de sécurité élevée. Exiger des descriptions de métadonnées. Utilisez des modèles d'architecture qui spécifient l'approche écosystémique. - Modèle d'impact de la version
Problème prévisible: Juste assez d'architecture signifie que chaque éventualité, chaque contrainte, chaque conflit n'a pas été découvert avant la sortie.
Approche: Mettez vos mains dans vos poches et attendez d'être appelé pendant la résolution. À moins d'être appelé, attendez de vous engager lors de l'examen de l'incident pour découvrir où vous n'avez pas réussi à identifier un problème prévisible, sous-estimé le risque ou manqué une exigence de test.
- Débloquez le modèle de portefeuille
Ces modèles d'engagement sont utilisés pour guider l'engagement des équipes EA.
Modèles d'architecture de données
Les modèles d'architecture de données sont des techniques permettant de résoudre les problèmes de données courants dans une organisation. Ces modèles fournissent une approche structurée de la modélisation, du stockage, du traitement et de l'intégration des données. Voici quelques modèles d’architecture de données standard :
- Modèle de lac de données
Problème prévisible—transformer de gros blocs de données en informations utiles et en informations exploitables
Approche— développer un lac de données (grand stockage de données brutes, catalogue de données, traitement des données et couche d'accès aux données) et la capacité d'analyse de données pour utiliser le lac de données - Modèle de gestion des données de référence (MDM)
Problème prévisible—améliorer l'intégration et la réutilisation des données dans les systèmes opérationnels de l'entreprise
Approche— développer des données de référence et des données de référence, la gouvernance des données et la qualité des données pour les systèmes opérationnels de bout en bout - Modèle de hub de données
Problème prévisible—intégrer des données entre des systèmes disparates
Approche— centraliser la logique d’intégration et de transformation des données, en fournissant un point d’accès unique aux consommateurs de données. - Modèle de réplication de données
Problème prévisible—intégration de données entre des systèmes disparates présentant des problèmes d'accès géographique et de performances
Approche: copier des données d'une source vers un ou plusieurs systèmes cibles en temps quasi réel.
Voici quelques-uns des modèles d'architecture de données standard utilisés dans divers secteurs et contextes. Les architectes d'entreprise utilisent ces modèles pour résoudre leurs problèmes de gestion de données.
Modèles d'architecture de sécurité
Les modèles d'architecture de sécurité sont des approches réutilisables pour résoudre les problèmes de sécurité des systèmes et des réseaux informatiques. Les organisations utilisent ces modèles pour mettre en œuvre des mesures de sécurité qui protègent leurs actifs, leurs données et leurs opérations. Voici quelques modèles d’architecture de sécurité courants :
- Modèle de sécurité du périmètre
Problème prévisible—protéger contre les accès non autorisés et les cyberattaques
Approche—Établit un périmètre de sécurité autour du réseau ou du système pour le protéger des menaces externes - Modèle de confiance zéro
Problème prévisible—protéger contre les accès non autorisés et les cyberattaques
Approche-réseau et applications de micro-segmentation, établir une gestion des identités et des accès (IAM), une authentification continue et des contrôles d'accès stricts. - Modèle d'infrastructure immuable
Problème prévisible—protéger contre les accès non autorisés et les cyberattaques
Approche— traite l'infrastructure comme du code et remplace (reconstruit) l'infrastructure déployée au lieu de les corriger ou de les modifier, réduisant ainsi les vulnérabilités. - Modèle de masquage et de rédaction des données
Problème prévisible—protéger les données sensibles contre toute exposition
Approche—remplacez ou supprimez les données sensibles par des informations non sensibles tout en permettant aux utilisateurs autorisés d'effectuer leurs tâches.
Ces modèles d'architecture de sécurité constituent une base pour la conception de systèmes et de réseaux sécurisés. Les organisations peuvent utiliser ces modèles pour répondre à leurs besoins uniques en matière de sécurité.
Modèles d'architecture d'infrastructure
L'architecture d'infrastructure consiste à concevoir les composants et les systèmes technologiques qui prennent en charge l'infrastructure informatique d'une organisation. Ces modèles aident les organisations à créer des environnements technologiques évolutifs, fiables et efficaces. Voici quelques modèles d’architecture d’infrastructure courants :
- Modèle d'infrastructure en couches
Problème prévisible— modularité, maintenabilité et évolutivité des systèmes technologiques
Approche-sépare l'infrastructure en couches distinctes, chacune étant responsable de fonctions spécifiques, telles que la présentation, la logique d'application et le stockage des données. - Haute disponibilité (HA) et modèle de redondance
Problème prévisible—disponibilité du système, tolérance aux pannes et maintenabilité
Approche—dupliquer les composants et services critiques. - Modèle d'architecture évolutive
Problème prévisible— modularité, maintenabilité et évolutivité des systèmes technologiques
Approche—évoluez en ajoutant davantage d'instances ou de nœuds pour gérer des charges de travail accrues - Modèle d'architecture sans serveur
Problème prévisible— modularité, maintenabilité et évolutivité des systèmes technologiques
Approche- allouer et mettre à l'échelle automatiquement les ressources d'infrastructure en réponse aux événements - Modèle de cloud hybride
Problème prévisible—améliorer le développement d'applications et la modularité, la maintenabilité et l'évolutivité des systèmes technologiques
Approche—fournir une infrastructure sous forme de services automatisés via des environnements de cloud public et sur site
Ces modèles d'architecture d'infrastructure fournissent aux organisations des lignes directrices et des bonnes pratiques pour concevoir des environnements technologiques évolutifs, fiables et sécurisés. Les organisations utilisent ces modèles pour répondre à leurs exigences et objectifs spécifiques en matière d'infrastructure.
Modèles d'architecture d'application
La plupart des modèles d’architecture d’application classiques sont des modèles de conception logicielle. Les modèles de conception d’applications Gang of Four sont bien connus en génie logiciel. Ils sont présentés dans le livre « Design Patterns : Elements of Realistic Object-Oriented Software ».
- Modèle de microservices
Problème prévisible—agilité, évolutivité et maintenance du portefeuille d'applications
Approche—décomposer les applications en petits services indépendants qui peuvent être développés, déployés et mis à l'échelle indépendamment - Modèle MVC (Modèle-Vue-Contrôleur)
Problème prévisible—organisation, maintenabilité et testabilité du code
Approche- sépare une application en trois composants interconnectés : modèle (données et logique métier), vue (interface utilisateur) et contrôleur (gère les entrées de l'utilisateur et met à jour le modèle et la vue en conséquence) - Modèle d'étrangleur / Modèle d'étranglement
Problème prévisible— remplacement des systèmes existants
Approche— remplacer ou « étrangler » progressivement un système existant en construisant de nouveaux composants autour de celui-ci pour remplacer progressivement le système
Il existe trois types de modèles de conception d'applications Gang of Four : les modèles créationnels, structurels et comportementaux. Voici un aperçu de chacun des modèles de conception Gang of Four :
Groupe de quatre modèles de création d'applications
- Modèle Singleton- garantit qu'une classe n'a qu'une seule instance et fournit un point d'accès global à cette instance
- Modèle de méthode d'usine: définit une interface pour créer un objet mais permet aux sous-classes de modifier le type d'objets qui seront créés
- Modèle d'usine abstrait—fournit une interface pour créer des familles d'objets liés ou dépendants sans spécifier leurs classes concrètes
- Modèle de constructeur— sépare la construction d'un objet complexe de sa représentation, permettant au même processus de construction de créer différentes représentations
- Modèle de prototype: crée de nouveaux objets en copiant un objet existant, appelé prototype, plutôt que de les créer à partir de zéro
Groupe de quatre modèles structurels d'application
- Modèle d'adaptateur: permet à l'interface d'une classe existante d'être utilisée comme une autre interface, la rendant compatible avec les clients qui attendent une interface différente
- Modèle de pont— sépare l'abstraction d'un objet de son implémentation afin qu'elles puissent varier indépendamment
- Modèle composite: compose les objets en structures arborescentes pour représenter des hiérarchies partie-tout. Les clients peuvent traiter des objets individuels et des compositions d'objets de manière uniforme
- Modèle de décorateur—attache dynamiquement des responsabilités supplémentaires à un objet. Les décorateurs offrent une alternative flexible au sous-classement pour étendre les fonctionnalités.
- Modèle de façade—fournit une interface simplifiée à un ensemble d'interfaces dans un sous-système, ce qui facilite son utilisation
- Modèle de poids mouche : minimise l'utilisation de la mémoire ou les dépenses de calcul en partageant autant que possible avec des objets similaires
Groupe de quatre modèles de comportement d'application
- Modèle d'observateur: définit une dépendance un-à-plusieurs entre les objets de sorte que lorsqu'un objet change d'état, toutes ses dépendances sont notifiées et mises à jour automatiquement
- Modèle de commande— encapsule une requête en tant qu'objet, permettant ainsi le paramétrage des clients avec des files d'attente, des requêtes et des opérations
- Modèle de stratégie-définit une famille d'algorithmes, encapsule chacun d'eux et les rend interchangeables. Les clients peuvent choisir l'algorithme à utiliser de manière dynamique
- Modèle de chaîne de responsabilité- transmet une requête le long d'une chaîne de gestionnaires. Dès réception d'une requête, chaque gestionnaire décide soit de traiter la demande, soit de la transmettre au gestionnaire suivant de la chaîne.
- Modèle d'état: permet à un objet de modifier son comportement lorsque son état interne change. L'objet semble changer de classe.
- Modèle de commande: représente une opération en tant qu'objet, permettant le paramétrage des clients avec des files d'attente, des requêtes et des opérations
- Modèle d'interprète-définit une grammaire pour interpréter une langue et fournit un interprète pour interpréter les phrases dans cette langue
Ces modèles d'architecture d'application offrent des conseils et des bonnes pratiques pour développer des applications logicielles afin de répondre à des exigences et des défis spécifiques. Les modèles Gang of Four sont des solutions de conception aux problèmes logiciels courants. Les architectes vont spécifier ces modèles comme contrainte.
Modèles d'acquisition du système
Les modèles d'acquisition font généralement référence à des approches établies pour acquérir de nouvelles technologies, systèmes ou actifs pour soutenir les buts et objectifs d'une organisation. Ils sont généralement utilisés dans la stratégie d’architecture d’entreprise et les cas d’utilisation de portefeuille. Ces modèles aident les organisations à prendre des décisions éclairées concernant leurs investissements et acquisitions technologiques. Voici quelques exemples de modèles d’acquisition :
- Modèle de consolidation des fournisseurs
Problème prévisible—gestion complexe des fournisseurs, coûts croissants
Approche— réduire le nombre de fournisseurs de technologies en regroupant plusieurs contrats et services sous un ensemble plus restreint de fournisseurs - Modèle d'acquisition axé sur le cloud
Problème prévisible—évolutivité, complexité sur site et flexibilité
Approche— donner la priorité aux solutions et services basés sur le cloud lors de l'acquisition de nouvelles technologies ou du remplacement de systèmes existants. - Modèle d'adoption de l'Open Source
Problème prévisible—innovation, coût et flexibilité
Approche—rechercher activement des solutions logicielles open source - Modèle d'acquisition de système modulaire
Problème prévisible—agilité, intégration et évolutivité de l'entreprise
Approche—acquérir des systèmes ou des technologies conçus de manière modulaire, permettant une extension et une personnalisation - Modèle de partenariat stratégique
Problème prévisible-risque
Approche— former des partenariats stratégiques avec des fournisseurs de technologie ou d'autres organisations pour co-développer ou co-investir dans des solutions innovantes
Ces modèles d'acquisition offrent aux organisations un moyen systématique de prendre des décisions liées à la technologie.
Les modèles d'acquisition de systèmes représentent des activités courantes choix utilisés dans l'analyse de scénario.
Conclusion Modèles d'architecture d'entreprise
Les modèles d'architecture d'entreprise améliorent la productivité des architectes d'entreprise. Les modèles d'architecture améliorent également la qualité de leur travail. La réutilisation est la racine de la productivité et de la qualité. Un modèle d'architecture fournit une approche réussie connue à un problème prévisible. En utilisant des modèles d’architecture, vous pouvez vous concentrer sur la détermination du meilleur changement plutôt que sur les approches.
Dans notre conseil en architecture d'entreprise nous utilisons notre bibliothèque de modèles d'architecture d'entreprise. Nous travaillons constamment à améliorer la productivité de nos architectes d’entreprise. Nous avons plus de temps pour examiner différentes options d’architecture et aider les parties prenantes à choisir la bonne. Nous avons le temps de répondre aux critères des parties prenantes et d'élaborer le vues architecturales qui améliorent la prise de décision. Le plus élément précieux de l'architecture d'entreprise guide un changement efficace en améliorant la compréhension et la confiance dans le changement.
Les modèles d'architecture existent dans tous les domaines de l'architecture. Exploitez le pouvoir de modèles d'architecture d'entreprise dans votre travail. Votre première étape consiste à examiner votre cas d'utilisation de l'architecture d'entreprise et commencez par les problèmes prévisibles de votre L'équipe EA est conçue pour répondre.