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 de 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 la manière de le résoudre.
Nous utiliserons deux modèles :Modèle opérationnel du CISR et motif étrangleur—pour explorer une approche commune et un problème prévisible.
Quiconque a tenté de migrer un portefeuille informatique a été confronté au problème des applications, de l'infrastructure et des données héritées. L'ancienneté des processus, de l'organisation et de la gestion complique la transition des services. Le problème prévisible est de savoir comment progresser tout en préservant l'activité. Le modèle de l'étrangleur offre une approche courante : l'ancienne approche est dissimulée derrière une façade. Au fil du temps, de nouveaux services remplacent les anciens.
Aucun modèle opérationnel ne s'applique partout. Le problème prévisible est de savoir comment organiser les départements, les produits et les services. Le modèle opérationnel du CISR propose une approche commune : unification, coordination, diversification ou réplication.
Aucun de ces modèles ne vous indique précisément comment procéder. Ils vous proposent une approche commune, identifient les défis spécifiques de l'approche et 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 sera probablement utile dans d'autres.”
Pourquoi les modèles d’architecture d’entreprise sont-ils importants ?
Les modèles d'architecture d'entreprise sont importants pour la productivité. Nous savons que les architectes d'entreprise les plus productifs sont 50 à 100 fois plus efficace que la moyenne. La racine est la réutilisation. Utiliser des modèles signifie que l'architecte n'a pas repartir de zéro. Comme un modèle n’est pas une solution complète, il permet d’éviter le piège courant des experts en la matière qui appliquent la même réponse dans des situations diverses.
L'utilisation de modèles d'architecture permet d'équilibrer une l'individualité de l'organisation et les défis sectoriels partagés. Les modèles d'architecture d'entreprise facilitent la prise de décision en offrant certitude et compréhension.
Avantages de l'utilisation des 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 :
- Travailler sur le changement le plus efficace, sans réinventer la roue
- Améliorer la confiance que l'architecture couvre les difficultés et apporte des réponses efficaces
- Simplifier compromis architectural
- Réponses et approches préférées de Cascade
- Améliorer la confiance dans le succès des mises en œuvre
- Simplifier l'évaluation des solutions lors de la gouvernance de la mise en œuvre
Les modèles d'architecture d'entreprise constituent un modèle pour résoudre les problèmes. Ils peuvent être utilisés dans différents contextes et offrent des solutions robustes aux problèmes courants. Ils offrent un certain niveau d'assurance et guident la prise de décision.
Quel que soit le modèle d'architecture d'entreprise utilisé, des inconvénients sont inévitables. Lorsqu'on examine les modèles, il est important de comprendre les compromis qui en découlent.
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— entreprises, applications, données, technologie et sécurité. Les modèles d'architecture sont généralement associés à l'architecture applicative ou logicielle.
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 architectural évoluent. Un modèle applicable à architecture pour soutenir la stratégie, ou portefeuille, ressemble à une architecture de référence pour la réalisation de projets et de solutions. En résumé, les principales différences sont :
- Étendue du problème: les modèles d'architecture posent toujours problème. L'architecture de référence pourrait ne pas poser de problème. Motif étrangleur ne sera jamais considérée comme une architecture de référence.
- AdaptabilitéLes modèles d'architecture peuvent être adaptés à de multiples projets et domaines. Les architectures de référence sont souvent liées à un contexte spécifique. L'architecture de référence d'une chaîne d'approvisionnement de biens de consommation sera difficile à adapter.
- Spécificité du domaineLes architectures de référence sont généralement conçues pour des secteurs ou des technologies spécifiques. Les modèles d'architecture sont plus universels.
En résumé, les modèles d'architecture offrent des orientations et des approches de haut niveau pour résoudre les défis architecturaux courants. Notre objectif est création d'une architecture d'entreprise il s’agit de fournir des conseils utiles plutôt que de se soucier des différences sémantiques.
La puissance des modèles d'architecture d'entreprise
Un modèle d'architecture d'entreprise vous propose une approche commune et éprouvée pour résoudre un problème prévisible. Les descriptions de modèle vous indiquent où se situent les difficultés liées à son utilisation. 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 consacrez votre temps et vos compétences à exploiter les 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 de l'importance 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 difficiles : quel travail est requis 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 que l'architecture logicielle et applicative. Appliquez cette technique : une 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 d’application :
- Modèles d'architecture d'entrepriseFace à 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 proposent des approches différentes pour résoudre le même problème.
Modèles de fusions et acquisitions (M&A)Face à un problème tel qu'une fusion, ils proposent des approches communes. Le modèle de diversification du marché définira les processus opérationnels, l'organisation, les capacités clés, les relations et les flux d'information différemment du modèle d'expansion géographique.
- Modèles d'architecture technologiqueFace à un problème comme 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 pour une infrastructure évolutive et fiable, dont l'efficacité est avérée. Le choix entre ces modèles se fera en fonction du contexte et des éléments clés.
- Modèles d'architecture de donnéesFace à un problème comme la protection des données personnelles et nationales, ils proposent un modèle de masquage des données. Ce modèle offre des approches cohérentes pour remplacer et masquer les données inaccessibles.
- Modèles d'architecture de sécuritéFace à un problème de protection des systèmes informatiques contre les menaces, ils proposent des modèles tels que le modèle Zero Trust ou le modèle d'infrastructure immuable. Ces modèles répondent à des problèmes de sécurité communs.
- Modèles d'architecture d'applicationIl existe un large éventail de modèles d'architecture applicative, à commencer par le Gang of Four. De nombreux modèles applicatifs classiques résolvent les problèmes de conception logicielle. Les modèles d'architecture applicative peuvent être basés sur la conception, comme le modèle Bridge, la modernisation, comme le modèle Strangler, ou l'acquisition, comme le modèle d'acquisition de systèmes modulaires. Les modèles de modernisation et d'acquisition s'adaptent facilement aux problématiques métier et d'infrastructure.
- Modèles d'acquisition de système: Face à un problème comme la gestion des coûts, ils proposent des approches différentes pour l'acquisition de 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 pour la gestion des coûts informatiques. Comme d'autres alternatives architecturales, la sélection entre ces modèles sera basée sur le contexte et les éléments matériels.
- Architecture d'entreprise et modèles d'engagement agiles:Nous les utilisons lorsque développer des équipes EA. Selon la cas d'utilisation d'architecture d'entreprise et le besoin de gouvernance, il existe différents modèles d'engagement avec Agile.
Bien que la terminologie et les spécificités puissent varier d’un domaine à l’autre, le concept de modèles d’architecture – fournissant des approches réutilisables et éprouvées aux problèmes courants – est universel.
Pour les architectes d'entreprise, l'avantage réside toujours dans la productivité et la qualité. Ils peuvent rationaliser leur travail, gagner en efficacité et garantir le respect des meilleures pratiques. L'essentiel est d'adapter et de personnaliser ces modèles aux exigences et contraintes spécifiques du domaine concerné.
Modèles d'architecture d'entreprise
Les modèles d'architecture métier sont des approches réutilisables pour structurer une organisation. Les organisations les utilisent pour aligner leurs objectifs métier, leurs opérations et leurs technologies afin de stimuler l'efficacité et l'innovation. Voici quelques modèles d'architecture métier courants :
- Modèle de numérisation (automatisation des processus métier)
Problème prévisible—améliorer l'efficacité
Approche—automatiser les activités routinières 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 les partenaires externes, les fournisseurs, les clients et les 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 pour répondre à leurs objectifs et défis spécifiques.
Modèles d'architecture d'entreprise pour les fusions et acquisitions (M&A)
Les modèles d'acquisition d'entreprises sont des moyens par lesquels les entreprises acquièrent d'autres contrats. Ces modèles aident les organisations dans leurs fusions-acquisitions et leurs objectifs stratégiques. Voici quelques exemples de modèles d'acquisition d'entreprises :
- 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 garantir le contrôle de chaque étape, ajuster la chaîne d'approvisionnement pour utiliser les étapes internes et rechercher l'efficacité de bout en bout - Modèle de diversification du marché
Problème prévisible—risques lié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 à un seul segment de marché, puis effectuer des ventes croisées - Modèle d'acquisition de technologie
Problème prévisible—risques et temps associés au développement de technologies innovantes et au retard pris par 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, temps et coût liés à la croissance de la clientèle
Approche-acquérir des organisations avec des bases de clientèle établies dans de nouvelles zones géographiques et sur de nouveaux marchés Les entreprises acquièrent des sociétés avec 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-se concentrer sur les acquisitions remportées par des organisations similaires en termes de marché, de produit et de proposition de valeur, puis normaliser les opérations pour plus d'évolutivité 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. Ensuite, rationaliser les produits, les services et les opérations. - Modèle de redressement (actif en difficulté)
Problème prévisible—accroître la valeur actionnariale à un rythme acceptable
Approche-Acquérir des entreprises en difficulté ou en difficulté, puis appliquer l'expertise en gestion et le capital pour les redresser - Modèle de capacité
Problème prévisible—risques, coûts et 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 la capacité, puis remplacer l’organisation, le processus, la technologie et la propriété intellectuelle existants par la capacité acquise
Ces modèles d'acquisition d'entreprises constituent des approches connues pour résoudre des problèmes prévisibles. Le choix du modèle dépend des objectifs stratégiques de l'entreprise et du contexte sectoriel.
Nous utilisons ces modèles pour vous aider analyse de scénario. Ces modèles représentent des pratiques commerciales courantes choix utilisés pour développer un scénario.
Architecture d'entreprise et modèles d'engagement agiles
L'architecture d'entreprise et l'agilité réduisent les risques. L'architecture permet de réduire les risques et les coûts avant la mise en œuvre. L'agilité réduit les risques et les coûts après la mise en œuvre.
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 internes et un ensemble de mesures de valeur pour ces produits. Les produits devraient apparaître sur la feuille de route architecturale. - Modèle de plate-forme
Problème prévisible:Quand faut-il utiliser une plateforme et quand faut-il que le produit soit 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. Se demander comment le développement agile sera rendu possible. - Modèle de point de repos de valeur majeure
Problème prévisible:Connaître le point de repos de valeur pour arrêter ou changer de focus.
ApprocheUtiliser des feuilles de route d'architecture pour explorer d'autres points de création de valeur. Créer des rapports sur l'activité vers les états de transition.
- Modèle de produit
- Guide Backlog dans le modèle Sprint
- Feuille de route pour guider le modèle de produit
Problème prévisible:Avoir une feuille de route inter-produits intégrée.
Approche: En utilisant un technique de feuille de route architecturale Où le produit, ou la famille de produits, remplace le portefeuille. Veiller à ce que les rapports habituels sur les produits incluent l'activité vers les états de transition. - Feuille de route pour guider le modèle Epic
Problème prévisible:Utiliser des épopées pour implémenter des résultats et des contraintes descendants dans le produit.
Approche:Utiliser des états de transition bien construits dans un technique de feuille de route architecturale Où le produit, ou la famille de produits, remplace le portefeuille. Veiller à ce que les rapports habituels sur les produits incluent l'activité vers les états de transition. - Modèle de valeur d'entreprise
Problème prévisible: Assurer que les facteurs critiques de succès inclus dans les états de transition et cibles guident la préparation agile du backlog et la planification épique.
ApprocheTraduire les mesures et objectifs descendants en critères exploitables pour la préparation agile du backlog. Veiller à ce que les rapports produits habituels incluent la sélection et la réalisation des activités en vue de la valeur annoncée. - Limiter le modèle ‘ ascendant ’ des propriétaires de produits
Problème prévisible:Les propriétaires de produits qui considèrent l’ensemble de l’entreprise à travers le prisme de leur produit et de ses utilisateurs directs.
ApprocheDocumenter le produit et son rôle au sein de l'écosystème. Documenter les contraintes applicables au produit. Documenter les critères d'évaluation. S'assurer que les rapports habituels sur le produit incluent la progression 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
- Modèle de sprints contraints
- Modèle de critères d'acceptation
Problème prévisible:Assurer que le logiciel est conforme aux spécifications et aux normes de l'architecture d'entreprise.
Approche: Fournir des critères d'acceptation obligatoires applicables à la fin des épopées et avant leur publication. Nous avons souvent utilisé Modèles d'architecture d'application et Modèles d'architecture de données Créer des critères d'acceptation. Inclure 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.
ApprocheL'architecture d'entreprise doit définir clairement la manière dont la valeur est décrite et mesurée. Les énoncés de valeur nécessitent des facteurs critiques de succès (FCS) et des mesures d'efficacité (ME). 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 Revolution
Problème prévisible:Assurer que la stratégie de mise en œuvre est suivie.
Approche:Utilisez la feuille de route du produit et les cycles de publication pour appliquer des changements radicaux d’approche. - Modèle de contrainte d'interfaces
Problème prévisible:Identifier les interfaces requises et s’assurer qu’elles sont utilisées.
Approche: Concentrez le travail descendant sur les interfaces et les structures de données partagées. Intégrez les exigences aux cycles d'épopée 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 Pour des interfaces légèrement spécifiques. Inclure la conformité des interfaces dans tous les rapports de test.
- Modèle de critères d'acceptation
- Résoudre le modèle de dépendance
- Débloquer 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:Utilisez les techniques d’architecture d’entreprise pour trouver les changements minimaux permettant de progresser. - Identifier les modèles de parties prenantes réelles
Problème prévisible:Identifier la véritable partie prenante qui peut fournir une orientation et une approbation sur un portefeuille de produits interne complexe.
Approche: Utiliser des techniques d'architecture d'entreprise pour identifier les parties prenantes et leurs agents, leurs préoccupations et leurs préférences. Utiliser des techniques d'architecture d'entreprise de alternatives et compromis Guider les parties prenantes vers une décision qui orientera le portefeuille de produits. Assurer une gouvernance efficace du portefeuille numérique. - Croiser 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 d'application et Architecture des données. Orienter les priorités organisationnelles dans cette architecture. L'architecture applicative doit être axée sur les services et interfaces partagés. L'architecture des données doit se concentrer sur les données maîtres, les données de référence et les données hautement classifiées. Exiger des descriptions de métadonnées. Utiliser des modèles d'architecture spécifiant l'approche écosystémique. - Modèle d'impact de la version
Problème prévisible:Une architecture juste suffisante signifie que chaque éventualité, chaque contrainte, chaque conflit, n'a pas été découvert avant la sortie.
ApprocheGardez les mains dans vos poches et attendez d'être appelé lors de la résolution. Sauf appel, attendez d'intervenir pendant l'analyse de l'incident pour identifier où vous avez omis d'identifier un problème prévisible, sous-estimé un risque ou manqué une exigence de test.
- Débloquer 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 courants liés aux données au sein d'une organisation. Ces modèles offrent 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 (stockage de données brutes volumineuses, catalogue de données, traitement des données et couche d'accès aux données) et la capacité d'analyse des 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 des entreprises
Approche—développer des données de base 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égration de 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 des données
Problème prévisible—intégration de données entre des systèmes disparates avec 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 les utilisent pour résoudre leurs problèmes de gestion des données.
Modèles d'architecture de sécurité
Les modèles d'architecture de sécurité sont des approches réutilisables permettant de résoudre les problèmes de sécurité des systèmes et réseaux informatiques. Les organisations les utilisent pour mettre en œuvre des mesures de sécurité protégeant 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 Zero Trust
Problème prévisible—protéger contre les accès non autorisés et les cyberattaques
Approche-micro-segmentation du réseau et des applications, établissement d'une gestion des identités et des accès (IAM), authentification continue et 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—traiter l’infrastructure comme du code et remplacer (reconstruire) l’infrastructure déployée au lieu de la corriger ou de la 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—remplacer ou rédiger des 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 la base de la conception de systèmes et de réseaux sécurisés. Les organisations peuvent les utiliser pour répondre à leurs besoins de sécurité spécifiques.
Modèles d'architecture d'infrastructure
L'architecture d'infrastructure consiste à concevoir les composants et systèmes technologiques qui soutiennent l'infrastructure informatique d'une organisation. Ces modèles aident les organisations à créer des environnements technologiques évolutifs, fiables et performants. 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 responsable de fonctions spécifiques, telles que la présentation, la logique d'application et le stockage de données. - Modèle de haute disponibilité (HA) et 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—évoluer en ajoutant plus 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 dimensionner 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 des 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 les utilisent pour répondre à leurs besoins et objectifs d'infrastructure spécifiques.
Modèles d'architecture d'application
La plupart des modèles d'architecture applicative classiques sont des modèles de conception logicielle. Les modèles de conception applicative “ Gang of Four ” sont bien connus en génie logiciel. Ils sont présentés dans l'ouvrage « Design Patterns : Elements of Reusable 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 de manière indépendante - Modèle MVC (Modèle-Vue-Contrôleur)
Problème prévisible—organisation du code, maintenabilité et testabilité
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 utilisateur et met à jour le Modèle et la Vue en conséquence) - Motif d'étranglement / Motif d'étranglement
Problème prévisible—remplacer les systèmes existants
Approche—remplacer progressivement ou “ étrangler ” un système existant en construisant de nouveaux composants autour de lui pour remplacer progressivement le système
Il existe trois types de modèles de conception d'applications Gang of Four : les modèles de création, les modèles structurels et les modèles comportementaux. Voici un aperçu de chacun d'eux :
Modèles de création d'applications Gang of Four
- 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
Modèles structurels d'application Gang of Four
- Modèle d'adaptateur—permet à l'interface d'une classe existante d'être utilisée comme une autre interface, la rendant ainsi 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
- Motif composite— compose des objets en arborescences pour représenter des hiérarchies partielles et complètes. Les clients peuvent traiter les objets individuels et les compositions d'objets de manière uniforme.
- Motif de décoration—attache des responsabilités supplémentaires à un objet de manière dynamique Les décorateurs offrent une alternative flexible à la sous-classification pour étendre les fonctionnalités
- Motif de façade—fournit une interface simplifiée à un ensemble d'interfaces dans un sous-système, le rendant plus facile à utiliser
- Modèle Flyweight : minimise l'utilisation de la mémoire ou les dépenses de calcul en partageant autant que possible avec des objets similaires
Modèles comportementaux des applications Gang of Four
- Modèle d'observateur—définit une dépendance un-à-plusieurs entre les objets de sorte que lorsqu'un objet change d'état, tous ses dépendants sont notifiés et mis à jour automatiquement
- Modèle de commande—encapsule une requête sous forme d'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, les encapsule et les rend interchangeables. Les clients peuvent choisir l'algorithme à utiliser dynamiquement.
- Modèle de chaîne de responsabilité— transmet une requête à une chaîne de gestionnaires. À la réception d'une requête, chaque gestionnaire décide de la traiter ou de la transmettre au gestionnaire suivant dans 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 sous forme d'objet, permettant le paramétrage des clients avec des files d'attente, des requêtes et des opérations
- Modèle d'interprétation—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 le développement d'applications logicielles répondant à des exigences et des défis spécifiques. Les modèles « Gang of Four » constituent des solutions de conception aux problèmes logiciels courants. Les architectes spécifier ces modèles comme une contrainte.
Modèles d'acquisition de système
Les modèles d'acquisition désignent généralement des approches établies pour acquérir de nouvelles technologies, de nouveaux systèmes ou de nouveaux actifs afin de soutenir les objectifs d'une organisation. Ils sont généralement utilisés dans les stratégies d'architecture d'entreprise et les cas d'utilisation de portefeuille. Ils 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 technologie en consolidant 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 l'extension et la 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. Ils améliorent également la qualité de leur travail. La réutilisation est essentielle à la productivité et à la qualité. Un modèle d'architecture fournit une approche éprouvée et efficace face à un problème prévisible. Grâce aux modèles d'architecture, vous pouvez vous concentrer sur la détermination du changement optimal 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 disposons de plus de temps pour examiner différentes options d'architecture et aider les parties prenantes à choisir la plus adaptée. Nous avons le temps de répondre aux critères des parties prenantes et de développer les vues d'architecture qui améliorent la prise de décision. Le plus partie précieuse 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 d'architecture. Exploitez leur puissance modèles d'architecture d'entreprise dans votre travail. Votre première étape consiste à examiner votre cas d'utilisation d'architecture d'entreprise et commencez par les problèmes prévisibles de votre L'équipe EA est conçue pour répondre.