TOGAF ADM Phase D – Développer l'architecture technologique
En un coup d'oeil
- Présentation de TOGAF ADM
- Qu'est-ce que TOGAF Phase D ?
- Qu'est-ce qu'une architecture technologique ?
- Architecture technologique vs architecture cloud
- L’appelle-t-on architecture technologique, architecture d’infrastructure ou architecture informatique ?
- Livrables de la phase D de TOGAF ADM
- Quelle est la différence entre un architecte d’entreprise et un architecte technologique ?
- Quel est le rôle de l’architecte d’entreprise dans la phase D ?
- Quel est le rôle de l’architecte technologique ?
- Modèles, outils et techniques d'architecture technologique
- Modèles d'architecture technologique
- Outils et techniques d'architecture technologique
- Comment la phase D de TOGAF s'aligne-t-elle sur Agile ?
- Réflexions finales sur TOGAF ADM Phase D - Architecture technologique
Présentation de TOGAF ADM
Utilisez le TOGAF ADM Développer les connaissances nécessaires à la meilleure architecture technologique. Chaque phase ADM fournit les données et les activités nécessaires au développement des connaissances sur un sujet spécifique. L'ADM TOGAF est au cœur de la norme TOGAF. C'est la seule méthode universelle et évolutive pour développer architecture d'entreprise. Il convient à tous les niveaux de détail. Comme tout modèle logique, il doit être étendu pour couvrir différents niveaux de détail : stratégie, portefeuille, projet et livraison de solutions.
Si vous avez besoin d'un aperçu du TOGAF ADM, veuillez lire le Explication des phases de TOGAF ADM.
Qu'est-ce que TOGAF Phase D ?
Dans la phase D de TOGAF, Architectes technologiques Piloter le développement de l'architecture technologique. Pour ce faire, ils cherchent à rendre possible l'architecture des systèmes d'information, et non à obéir à des ordres et à satisfaire des espoirs. Les architectes technologiques comprennent qu'une infrastructure durable fournit son environnement. Ils doivent anticiper et être prêts. Ils doivent veiller à ce que les espoirs à court terme ne créent pas de difficultés à long terme.
Quand nous sommes développer des équipes d'architecture d'entreprise, nous expliquons aux architectes deux faits essentiels sur TOGAF Phase D - Architecture technologique. Tout d'abord, jusqu'à ce que vous ayez un Modèle de développement d'applications, Vous ne pouvez pas continuer. Développer les détails de votre infrastructure avant de comprendre les besoins de votre architecture applicative est inutile. Deuxièmement, s'ils se lancent dans un programme informatique ou d'infrastructure, ils développeront systématiquement une architecture technologique de faible qualité. Les concepteurs et les opérateurs d'infrastructure doivent se sentir limités par l'architecture technologique.
Dans une entreprise moderne en pleine transformation numérique, tous les domaines d'architecture interagissent. Les choix effectués dans un domaine activent, produisent ou bloquent les résultats d'un autre domaine. La plupart des objectifs métier dépendent de bonne architecture informatique. Nous ne pouvons développer la bonne architecture technologique que si nous disposons d’une architecture d’application solide.
La véritable difficulté de l'architecture technologique réside dans la pérennité de l'infrastructure. Sans une architecture technologique imposant des contraintes, les choix d'infrastructure tactiques engendreront toujours des résultats défavorables pour l'entreprise.
Il existe une corrélation directe entre une bonne architecture technologique et le PaaS moderne, ou la plupart des architectures cloud. Toutes deux identifient les services d'infrastructure, fournissent des contraintes et permettent des choix de données et d'applications, et isolent les applications de l'infrastructure sous-jacente.
Quel est l’objectif de TOGAF ADM Phase D ?
Le TOGAF ADM commence par Phase A. Il délivre un architecture cible simplifiée - la vision architecturale. La vision de l'architecture devrait inclure les activités, les applications, les données, et domaines technologiques. Trop souvent, on voit des gens prétendre développer une vision architecturale. Ils se présentent avec un fantasme opérationnel et considèrent la phase D comme un exercice de réalisation de fantasmes. L'architecture d'entreprise réelle a développé une architecture cible simplifiée. L'activité de la phase D développe davantage les domaines de l'architecture technologique. La réussite exige :
- Vous abordez le problème de la façon dont l’infrastructure actuelle ne répond pas aux préférences des parties prenantes
- Vous apprenez ce qui doit changer pour permettre à l'infrastructure de répondre aux préférences des parties prenantes ? (Lacunes)
- Vous avez une compréhension suffisante du travail nécessaire pour apporter des modifications (Work Package)
- Vous comprenez l'interaction entre les changements et les contraintes dans d'autres domaines d'architecture pour protéger la valeur attendue (Spécifications des exigences d'architecture)
Le résultat principal de la phase D est l'architecture technologique candidate. Les architectes technologiques collaborent avec les autres architectes de domaine. Attendez-vous à des échanges d'espoirs et de contraintes. Tout développement d'architecture nécessite de trouver la meilleure solution pour l'entreprise. Cette solution optimale comprend les limites et fonctionne dans tous les domaines.
L'objectif du TOGAF ADM est d'explorer les changements possibles. Ces changements sont équilibrés en termes de travail, de valeur et risque. Modifications sélectionnées ou supprimées. L'ensemble des modifications crée l'architecture cible et la feuille de route de l'architecture.
Les architectes technologiques travaillent avec l'infrastructure. L'infrastructure est le maillon le plus difficile à modifier d'une organisation. Ils doivent anticiper chaque changement potentiel et rester attentifs aux solutions de contournement. La solution la moins coûteuse se situe lors du développement de l'architecture. Il faut stopper rapidement les mauvaises idées. Éliminer les mauvaises idées permet de réaliser des économies et de réussir le changement. La nécessité d'anticiper l'infrastructure exige des architectes technologiques qu'ils imposent des contraintes aux concepteurs et aux implémenteurs.
Interaction avec Phase B de TOGAF, Phase C, et Phase E
‘'‘L'entreprise’ L'entreprise est au cœur de nos préoccupations. Elle l'a toujours été. Les entreprises numériques modernes ne peuvent pas compter sur des collaborateurs dévoués pour surmonter les limites des applications et de l'infrastructure. Ces limites réduisent l'agilité de l'entreprise et freinent les transformations numériques. ».
Ils ont conçu le diagramme TOGAF ADM autour du défi de la fragmentation des processus de préparation et de la nécessité de collaborer. Malheureusement, le diagramme TOGAF ADM classique illustre le flux d'informations nécessaires. Veuillez ne pas l'interpréter comme une cascade.
Ceux qui prétendent que l'architecture d'entreprise peut être développée séquentiellement ont tort. Ceux qui préconisent de se lancer dans l'architecture de l'entreprise entière ont également tort. La complexité et la spécialisation des compétences nécessitent des domaines. Leur développement commence et se poursuit ensemble. Il est nécessaire d'adopter une approche agile, juste assez pour tester les contraintes en cascade. TOGAF appelle cela l'itération.
Décisions architecturales traversera plusieurs domaines d'architecture nécessite l'utilisation de alternatives architecturales.
Qu'est-ce que l'architecture technologique ?
Architecture technologique L'architecture technologique est l'un des quatre domaines fondamentaux de l'architecture d'entreprise. Elle décrit l'ensemble de votre portefeuille d'infrastructures et vous indique quand acheter une infrastructure, quand utiliser le PaaS et quand l'inventer. Elle vous indique également où placer les frontières entre les systèmes et comment aborder le cycle de vie de votre infrastructure.
Nous pouvons garantir que votre architecture technologique actuelle n'est pas alignée. Nous sommes convaincus que vous partirez d'une situation où la planification de l'infrastructure ne reposait pas sur une base solide. architecture d'application ou l'architecture d'entreprise.
Lorsque vous disposez d'une architecture technologique, vous disposez de l'ensemble des services d'infrastructure requis par vos applications. Vous disposez d'un ensemble de lignes directrices et contraintes Pour la conception et l'exploitation de votre infrastructure, vous disposez d'une feuille de route technologique comprise par vos parties prenantes.
Pour développer l'architecture technologique, ses services, ses directives et ses contraintes, l'architecte technologique doit collaborer avec ses pairs et les parties prenantes. Il doit explorer comment les différents choix d'infrastructure favorisent ou freinent les choix métier et logiciels. Il doit comprendre comment l'ensemble des choix favorise et limite les objectifs de l'organisation. Il doit abandonner les modifications potentielles qui n'apportent pas suffisamment de résultats, nécessitent trop de travail ou sont trop incertaines. Les bonnes feuilles de route d'architecture incluent les changements nécessaires et sont dérisquées.
À quoi sert une architecture technologique ?
L’architecture technologique aidera à répondre aux questions suivantes :
- Comment le portefeuille d’infrastructures permet de capturer de la valeur – Modèle de service d'infrastructure
- Comment l’infrastructure est fournie – Modèle de fournisseur d'infrastructure
- Où le coût est injecté dans le portefeuille informatique - Modèle d'interface
- Là où la rigidité est injectée dans le portefeuille informatique - Modèle de cycle de vie
- Les choses qu’une infrastructure doit être capable de faire – Modèle de système d'infrastructure
- Contraintes à l’acquisition et à l’utilisation de la technologie – Catalogue des normes
- Comment utiliser l'infrastructure pour réaliser les activités d'une entreprise – Modèle d'interface
- Les activités complètes qu'une infrastructure effectue sont regroupées pour montrer comment elles sont liées les unes aux autres. Modèle de service
- Qu'est-ce que le portefeuille d'infrastructures ? Modèle d'infrastructure physique
Architecture technologique vs architecture cloud
Nous ne voyons presque aucune différence entre un bon PaaS ou un bon Architecture de cloud privé, et une bonne architecture technologique. Les principaux produits de travail, Modèle de système et Modèle de service, sont identiques. La différence réside dans le fait que, lorsque vous utilisez un PaaS ou un cloud public, vous n'avez pas à vous soucier de l'infrastructure sous-jacente.
Ironiquement, si vous avez mis en place une architecture technologique performante depuis TOGAF 8, vous avez fourni un ensemble clair de services d'infrastructure. Vous avez spécifié les interfaces et les normes pour ces services. Nous pensons que votre travail est facilement transférable vers un catalogue de services PaaS de cloud public.
TOGAF 8 préconisait des services technologiques permettant d'abstraire l'infrastructure détaillée afin de permettre la portabilité, de gérer les ‘ ilités ’ et de garantir le cycle de vie de l'infrastructure. C'est la même raison pour laquelle tous les fournisseurs de PaaS de cloud public encouragent leurs clients à utiliser ces services. Si nous avions tous mis en place une architecture technologique performante, nous aurions évité l'impasse des applications immobiles, des ‘ ilités ’ non livrées et de la dette technique.
>>> Accéder à Les bases de l'architecture du cloud privé
L’appelle-t-on architecture technologique, architecture d’infrastructure ou architecture informatique ?
La norme TOGAF l'appelle Architecture Technologique. Notre cabinet de conseil en architecture d'entreprise utilise généralement une infrastructure. Beaucoup d'autres nécessitent une architecture informatique. Les efforts visant à élaborer une définition universelle et précise échouent systématiquement. Nous vous conseillons vivement de vous concentrer sur l'objectif plutôt que sur la définition.
La distinction entre les domaines d'architecture nous aide à réunir les compétences et les échanges pertinents. Réfléchir à cet objectif nous permet de rester concentrés sur le développement d'une architecture utile.
Réfléchir à la définition vous mènera inévitablement à une discussion inutile. L'IA, c'est-à-dire une application de chatbot, une IA ou une entreprise ? Le courrier électronique est-il une application ou une infrastructure ? Qu'en est-il de la reconnaissance faciale utilisée pour le contrôle d'accès ? Les possibilités sont infinies.
Tous les domaines de l'architecture d'entreprise sont interdépendants. Ensemble, ils couvrent l'architecture d'entreprise dans son intégralité. Nous créons un domaine afin qu'un architecte spécialisé puisse exploiter ses techniques et compétences. De nouveaux domaines d’architecture d’entreprise apparaissent continuellement. La plupart sont absorbés dans un domaine d'architecture d'entreprise classique à mesure qu’ils deviennent courants.
Notre conseil : ne vous souciez pas de ce qui est juste. Assurez-vous plutôt de comprendre ce que votre interlocuteur veut dire. Sachez toujours ce que vos interlocuteurs supposent que vous voulez dire. Soyez responsable de votre compréhension et adaptez vos termes.
Quelle est la différence entre un architecte d’entreprise et un architecte informatique ?
Beaucoup pensent qu'un architecte d'entreprise doit se concentrer sur l'infrastructure informatique. Dans le cadre de plusieurs missions de conseil, nous avons rebaptisé nos architectes d'entreprise afin d'éviter ce problème. La profession d'architecte d'entreprise est claire : l'architecture informatique est un sous-ensemble de l'architecture d'entreprise. La technologie est un sous-ensemble de l'architecture informatique.
Nous concentrons nos efforts sur l'interaction entre tous les domaines d'architecture pour les architectes d'entreprise. De nombreuses équipes comptent des architectes de données, d'applications, de sécurité, d'affaires et de technologies. Ils peuvent être désignés par leur fonction ou par le titre général d'architecte d'entreprise.
Livrables de l'architecture technologique TOGAF ADM Phase D
L'un des principaux résultats de la phase D est l'architecture technologique. Celle-ci constitue un élément de l'architecture d'entreprise complète. Ainsi, de manière indirecte, la phase D de TOGAF ADM comporte cinq livrables utiles :
- Modèles qui composent l'architecture technologique
- Écarts entre l'architecture technologique actuelle et l'architecture cible
- Lots de travaux candidats qui combleront les lacunes
- Spécifications d'architecture candidates qui vous permettront de gérer le développement et la mise en œuvre de l'architecture future
- Influence sur l'architecture d'entreprise, l'architecture des applications, l'architecture des données et l'architecture de sécurité
Gardez toujours à l'esprit que vous cherchez à améliorer l'organisation. L'amélioration exige du changement. Ce changement est source de valeur. La valeur et le coût du changement sont mesurables. L'incertitude diminue toujours la valeur potentielle. Lorsque le succès est incertain, les coûts augmentent considérablement. Une très faible incertitude éliminera les attentes.
La plupart du temps, lorsqu'on parle d'architecture technologique, on fait référence aux modèles et aux spécifications d'architecture. Différents modèles expliquent différents aspects de l'infrastructure complète. Ensemble, les modèles et les modifications nécessaires forment l'architecture technologique.
Lorsque vous examinez différents types de modèles, gardez à l'esprit que les mêmes termes ont de nombreuses utilisations. Nous insistons sur la nécessité de ne pas se fier à l'appellation du modèle. Ce que vous appelez un modèle de décomposition fonctionnelle, quelqu'un d'autre l'appellera un service. Notre conseil en architecture d'entreprise se concentre sur l'objectif, et non sur le nom du modèle. Vous pouvez l'appeler décomposition fonctionnelle, modèle système ou modèle de service. Seule l'objectif du modèle nous importe : que cherchez-vous à apprendre et votre modèle explique-t-il efficacement le fonctionnement de cet aspect du travail réel ?
Achèvement de l'architecture technologique de la phase D
Toutes les phases de TOGAF ADM comportent les informations et les activités nécessaires au développement des connaissances nécessaires. La phase D aboutit au développement d'une architecture technologique candidate.
| Résultats et résultats | Connaissances essentielles |
| L'architecture du domaine technologique approuvée par les parties prenantes pour le problème traité, avec un ensemble de lacunes, et le travail visant à combler les lacunes comprises par les parties prenantes. | Comment le portefeuille technologique actuel ne parvient-il pas à répondre aux préférences des parties prenantes ?
Que faut-il changer pour que le portefeuille de logiciels réponde aux préférences des parties prenantes ? (Lacunes) Quels travaux sont nécessaires pour réaliser les changements qui sont cohérents avec la valeur ajoutée créée ? (Lot de travaux) Comment les priorités et les préférences des parties prenantes s'ajustent en fonction de la valeur, de l'effort et du risque du changement. (Exigences des parties prenantes) |
Tableau du guide de la série TOGAF 10 : Guide de l'architecte d'entreprise pour le développement de l'architecture
Phase D Bare Bones
En phase D, le travail d'un architecte technologique consiste à déterminer les changements technologiques à apporter pour permettre aux systèmes d'information de fonctionner au mieux de l'entreprise. Cela paraît simple. Il suffit de comprendre ce que l'organisation cherche à améliorer, ses lacunes et les changements à apporter.
Les éléments essentiels de la phase D sont les suivants :
- Connaître comment le portefeuille d'infrastructures permet de capter de la valeur
Les organisations créent de la valeur lorsqu'elles réalisent quelque chose pour lequel un client est prêt à payer plus cher. La valeur est généralement générée lorsqu'un matériau est modifié, lorsqu'un service est rendu ou lorsqu'une information est utilisée. Du minerai de fer à l'acier, des alertes météorologiques sont émises, ou encore des pièces, des commandes et des capacités de production permettent de créer un ordre de production.
La technologie joue généralement un rôle de soutien. Elle permet aux personnes et aux applications de générer de la valeur. En tant que fonction de soutien, nous optimisons l'efficacité. La réponse à cette question cruciale réside dans la connaissance des services minimaux requis.
- Savoir comment les infrastructures seront livrées
Auparavant, nous devions posséder et exploiter notre technologie. Grâce aux fournisseurs de PaaS de cloud public, nous pouvons gérer des organisations mondiales évolutives sans posséder de technologie. La plupart des organisations disposent d'une combinaison d'infrastructures qu'elles possèdent et exploitent, d'infrastructures qu'elles confient à d'autres, et d'un ensemble de services d'infrastructure.
- Connaître la source du coût, de la complexité et de la rigidité
Tout portefeuille d'infrastructures souffre de rigidité. L'infrastructure est difficile à modifier. Complexité et rigidité engendrent coûts et complexité. Votre infrastructure ressemble à un mécanisme d'horlogerie complexe, composé de pièces presque aléatoires. Modifier un élément entraîne généralement des changements en cascade dans l'ensemble du portefeuille.
L’architecture technologique doit réduire la rigidité pour permettre agilité de l'entreprise. Vous devez optimiser votre portefeuille d'infrastructures de base pour réduire les coûts et la complexité. La course au PaaS dans le cloud public n'est qu'une tentative d'acquérir de l'agilité. Comprendre l'ITFM et maintenir un modèle de coûts pour les produits numériques et les services informatiques est essentiel.
- Savoir sélectionner les infrastructures
Il existe quatre modèles d'infrastructure : PaaS, systèmes d'entreprise, systèmes spécialisés et développement personnalisé. Chacun possède un modèle de coût et d'optimisation différent. Il est donc essentiel d'appliquer le bon modèle d'acquisition d'infrastructure aux endroits appropriés.
- Connaître les attentes en matière d'infrastructures
Parfois, nous avons besoin d'un service d'infrastructure générique. Parfois, nous avons besoin de matériel spécialisé. La plupart du temps, nous avons besoin d'un service sans trop de frais généraux. Nous exploitons les concepts et les attributs de modèles de capacité Pour guider les choix concernant notre architecture technologique. Notre Guide d'évaluation des capacités d'architecture d'entreprise présente un ensemble d'attributs facilement adaptables.
- Savoir utiliser l'infrastructure
Quelle interface choisirez-vous ? Choisirez-vous d'utiliser une norme industrielle ou d'opter pour une interface spécialisée ? Masquerez-vous l'interface par l'abstraction ?
Vient ensuite l'exploitation de l'infrastructure. Quelles sont les attentes opérationnelles ? Qu'en est-il de la disponibilité ou de la capacité à absorber les pannes de composants ? Quelles sont les exigences pour pouvoir modifier l'infrastructure ?
- Que faut-il changer pour offrir le meilleur portefeuille d’infrastructures ?
Nous développons une architecture technologique pour améliorer une organisation. Le rythme et la réalité des changements d'infrastructure impliquent que la plupart des changements sont réalisés hors cycle. Les changements opérationnels actuels doivent s'appuyer sur l'infrastructure existante. En tant qu'architecte technologique, vous travaillez souvent sur le cinquième aspect de la modèle d'agilité d'entreprise Flexibilité. Sans un travail préalable visant à réduire les obstacles à l'action, votre organisation se heurte à des contraintes face aux changements imprévus.
La plupart des changements souhaités ne sont que des ajustements mineurs. En termes de Six Sigma, il s'agit d'optimisation locale : améliorer une petite partie du système, même au détriment de l'ensemble. En tant qu'architecte technologique, utilisez les conseils de la phase D de TOGAF ADM pour vous concentrer sur les changements matériels qui favorisent l'agilité de l'entreprise, la réduction des coûts ou la création de valeur.
Les trois éléments essentiels de l’achèvement de la phase D :
- Premièrement, que faut-il changer ? Des changements de service, d'exécutant, d'interface, d'exploitation, d'externalisation, d'internalisation ou d'automatisation. Ce sont tous des changements. Nous les mettons en œuvre pour améliorer une organisation. Optimisez votre portefeuille d'infrastructures.
- Deuxièmement, quand faut-il modifier les choses ? Y a-t-il des dépendances ? Qu'en est-il des conditions préalables ? Changez-vous les conditions préalables à une modification ultérieure ?
- Troisièmement, comment saurez-vous si le changement a réussi ? Quel est votre critère de gouvernance pour en évaluer la réussite ? Comment préserverez-vous la valeur ?
Approbation par les parties prenantes de toutes les modifications d'architecture. L'architecte technologique est tenu de décrire les modifications en termes qu'il comprend et qui répondent à ses préoccupations. Il doit également fournir les tests de gouvernance permettant aux parties prenantes de piloter le projet de changement.
Livrables de l'architecture technologique TOGAF Phase D et objectifs de l'architecture d'entreprise
Le développement d'une architecture d'entreprise répond à quatre objectifs principaux. Les livrables de la phase D ont chacun une importance différente.
| Architecture pour soutenir la stratégie | Architecture pour soutenir le portefeuille | Architecture pour soutenir le projet | Architecture pour soutenir la livraison de solutions | |
| Produit de travail de phase D : architecture technologique candidate | Livrable clé
L’utilisation principale est la compréhension de la cible et du travail par les parties prenantes. L'utilisation secondaire est la création de spécifications d'exigences architecturales pour les architectes |
Livrable clé
L’utilisation principale est la compréhension de la cible et du travail par les parties prenantes. L'utilisation secondaire est la création de spécifications d'exigences architecturales pour les architectes |
Avant le lancement du projet et la finalisation du business case
L'utilisation principale est la création de spécifications d'exigences d'architecture pour les implémenteurs |
Avant l'engagement des partenaires d'exécution (y compris les prestataires internes)
L'utilisation principale est la création de spécifications d'exigences d'architecture pour les implémenteurs |
| Produit de travail de la phase D : éléments de la feuille de route des candidats | Livrable clé
L’utilisation principale est la compréhension du travail par les parties prenantes. L'utilisation secondaire est la création de contraintes pour les architectes |
Livrable clé
L’utilisation principale est la compréhension du travail et de la dépendance par les parties prenantes. L'utilisation secondaire est la création de contraintes pour les architectes |
Utilisation limitée Peut être utilisé comme entrée pour des projets avec plusieurs changements interactifs |
Avant l’engagement des partenaires d’exécution (y compris les prestataires internes).
L'utilisation principale est l'identification du changement requis et des préférences quant à la manière d'exécuter le changement, afin de gérer la sélection et l'engagement des partenaires de fourniture de solutions. |
| Produit de travail de phase D : Spécification des exigences d'architecture | Utilisation limitée
Habituellement, les architectes peuvent déduire des contraintes d’une architecture supérieure. |
Utilisation limitée
Habituellement, les architectes peuvent déduire des contraintes d’une architecture supérieure. |
Livrable clé
Avant l'achèvement du lancement du projet |
Livrable clé
Avant l'engagement et la conclusion du contrat |
Tableau de Cadre TOGAF Guide de la série TOGAF : Guide de l'architecte d'entreprise pour le développement de l'architecture
Architecture technologique candidate
Le développement d'une architecture d'entreprise répond à quatre objectifs principaux. L'importance des différents modèles varie selon l'objectif.
>>> Accéder au commun Modèles d'architecture technologique
Composants de la feuille de route de l'architecture technologique candidate
Quels sont les changements minimaux ? Si vous envisagez de changer de fournisseur d'infrastructure, il est peu probable qu'il s'agisse d'un changement significatif. Si vous passez d'un système d'entreprise générique à une infrastructure spécialisée, la modification des composants et des spécifications du modèle de fournisseur d'infrastructure constitue le candidat à la feuille de route. N'oubliez pas les changements en cascade. Le passage à une infrastructure spécialisée nécessitera des changements dans l'ensemble de l'architecture métier et applicative, même s'il ne s'agit que de changements au sein de l'équipe qui exploite le matériel spécialisé.
Nous utilisons souvent un Modèle de système d'infrastructure Pour résumer les changements. Les modèles système offrent suffisamment d'abstraction pour les discussions de planification et d'exécution. Nous recommandons l'utilisation de scores et de lots de travaux pour expliquer les changements. Pour plus d'informations sur l'utilisation des scores, consultez le Guide d'évaluation des capacités d'architecture d'entreprise.
Nous utilisons tous les composants de la feuille de route de l'architecture dans TOGAF Phase E - Feuille de route architecturale.
Spécification des exigences d'architecture technologique candidate
Expliquez les contraintes imposées aux concepteurs, acheteurs et implémenteurs d'infrastructures. Expliquez comment vous évaluerez l'amélioration.
Nous utilisons souvent des scores et des énoncés simplifiés pour décrire les exigences. Il peut s'agir d'une mesure d'automatisation, d'une déclaration précisant que l'infrastructure sera un PaaS de cloud public ou du matériel spécialisé. Ces exigences servent à orienter et contrôler un projet de changement dans la phase G de TOGAF.
Quel est le rôle de l’architecte technologique dans la phase D ?
Nous attendons de l'architecte technologique qu'il dirige la phase D de TOGAF et fournisse l'architecture du domaine. Il doit développer les modèles qui mettent en évidence l'origine de la déficience. Il doit exercer ses modèles pour démontrer comment un changement permet de pallier cette déficience. Nous attendons de lui qu'il guide les parties prenantes, les experts métier et les autres architectes du domaine dans l'analyse des compromis.
Les architectes technologiques doivent collaborer étroitement avec les architectes métier et les architectes d'application. L'architecture technologique engendre souvent des lacunes dans leur domaine. De plus, la simplification et la rigidité de l'architecture technologique nécessitent généralement des modifications.
Nous attendons de l'architecte technologique qu'il définisse l'architecture métier. Il doit comprendre Modèle opérationnel et les attributs Compétence et Automatisation du Modèle de capacité. Nous nous attendons également à ce qu’ils comprennent la Modèle de développement d'applications, les attributs de compétence et d'automatisation de tout Modèle de système d'application, et le Modèle de produit numérique.
>>> Accéder au commun Modèles d'architecture d'entreprise et commun Modèles d'architecture d'application
>>> Accéder au commun Modèles d'architecture technologique
Les équipes d'architecture d'entreprise ne peuvent réussir sans architectes technologiques. Les entreprises numériques modernes semblent fonctionner uniquement grâce à des logiciels. Elles fonctionnent grâce à une infrastructure. Rien ne se passe sans infrastructure. Des choix technologiques inadéquats entraveront l'agilité et la création de valeur de l'entreprise. Les architectes technologiques se spécialisent dans le domaine technologique. Ils ne peuvent accomplir leur travail sans collaborer efficacement avec architectes d'entreprise, architectes de données, de technologie et de sécurité.
Quel est le rôle de l’architecte d’entreprise dans la phase D ?
L'architecte d'entreprise joue le même rôle dans la phase D de TOGAF. Il doit intervenir là où un architecte de domaine a besoin d'aide, que ce soit pour développer l'architecture technologique, interpréter d'autres domaines ou préserver la valeur. De nombreux architectes technologiques ne perçoivent pas l'impact de l'architecture métier. Ou ils peuvent ne pas formuler une exigence de manière à ce que l'architecte de sécurité puisse agir.
Le rôle le plus important de l'architecte d'entreprise est de dépasser les limites. Qu'il s'agisse de domaines, de compétences ou d'autorités, il doit les dépasser.
Modèles, outils et techniques d'architecture technologique
La phase D de TOGAF ADM fournit l'architecture des systèmes d'information. Cette phase vise à développer l'architecture technologique et l'architecture des données qui composent les systèmes d'information. Dans TOGAF, la première étape consiste à déterminer les vues et les modèles requis.
Les préoccupations des parties prenantes permettront d'identifier les points de vue. Il existe sept modèles d'architecture technologique centraux.
- Modèle de fournisseur d'infrastructure précise comment l'infrastructure sera fournie
- Modèle de système d'infrastructure capture les grands systèmes de votre portefeuille d'infrastructures
- Modèle de service d'infrastructure décompose le portefeuille d'infrastructures en boîtes noires et se concentre sur les résultats et les attributs du service
- Modèle d'interface décrit comment vous vous connectez à l'infrastructure ou l'utilisez
- Modèle de cycle de vie identifie les attributs de cycle de vie requis de votre portefeuille d'infrastructures
- Catalogue des normes identifie les normes d'acquisition pour votre portefeuille d'infrastructures
- Modèle physique de l'infrastructure explique quelles infrastructures réelles existent dans le portefeuille d'infrastructures
Modèles d'architecture technologique
Modèles d'architecture constituent une approche cohérente face à un problème prévisible. Notre Modèle de modèle met en évidence le Problème prévisible, Approche, et le Morceaux durs. Lorsque nous envisageons un modèle, nous devons évaluer le travail requis, les contraintes et les limites.
Exemples de modèles d'architecture technologique
- 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 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èles d'architecture technologique
Développer une architecture technologique utile nécessite plusieurs modèles d'architecture d'entreprise. Chaque type de modèle décrit un aspect différent du portefeuille d'infrastructures. L'architecture technologique TOGAF Phase D explique les grandes étapes de développement de l'architecture cible. Différents types de modèles permettent d'analyser le portefeuille d'infrastructures sous différents angles.
En utilisant un nombre minimal de liens, ces modèles décrivent l'architecture technologique. Avec un ensemble minimal de liens vers d'autres domaines, une architecture d'entreprise complète est décrite.
Modèle de fournisseur d'infrastructure
Le modèle de fournisseur d'infrastructure décrit la manière dont l'infrastructure sera fournie. Ce modèle nécessite un modèle de service d'infrastructure ou un modèle de système d'infrastructure.
Il existe quatre types de fournisseurs de base :
- PaaS Cloud public, peuvent être assemblés sous forme de services d'infrastructure ponctuels. Les restrictions et limitations d'interopérabilité nécessitent une sélection au sein des offres groupées des fournisseurs.
- Systèmes d'entreprise, Infrastructure courante. Elle est généralement fournie sous forme de systèmes étendus intégrant diverses fonctionnalités. L'intégration des systèmes d'entreprise dans les services d'infrastructure nécessite des efforts.
- Systèmes spécialisés Ils excellent dans différents créneaux. Généralement, les systèmes spécialisés prennent en charge des cas d'utilisation spécifiques. Par exemple, les infrastructures certifiées pour l'aviation, les plages de résistance aux chocs et aux températures étendues, ou encore l'informatique quantique.
- Infrastructure personnalisée, que vous avez conçu pour votre organisation. Généralement, les solutions personnalisées répondent aux exigences spécifiques de votre architecture métier ou applicative.
Modèle de système d'infrastructure
Le modèle système résume l'infrastructure nécessaire pour fournir une fonctionnalité. La plupart Architectures de référence technique S'appuient sur un modèle système. Ils identifient les différentes caractéristiques de l'infrastructure.
Imaginez un environnement applicatif avec serveurs d'applications, équilibreurs de charge et stockage. La conception de votre modèle système limitera votre capacité à identifier les doublons, la rigidité et la complexité.
Les modèles système vous permettent d'orienter votre réflexion vers les domaines de votre infrastructure où les coûts opérationnels, la rigidité et les doublons doivent être traités. Ils déplacent la réflexion des variantes spécifiques du système vers le compromis entre l'impact sur d'autres domaines, l'agilité, les coûts et les opérations.
FEAF, OPAS et IndEA fournissent tous des modèles de systèmes d'infrastructure. Ces modèles sont indispensables à la planification du portefeuille d'infrastructures. La duplication et la spécialisation complexifient et augmentent les coûts du portefeuille d'infrastructures.
Modèle de service d'infrastructure
Un modèle de service d'infrastructure est une version spécialisée d'un modèle de système d'infrastructure. Il regroupe l'ensemble dans une boîte noire avec des attributs et des interfaces connus. Vous ne pouvez pas utiliser de PaaS de cloud public, ni Architecture PaaS de cloud privé sans modèle de service.
Un modèle de service d'infrastructure est indispensable pour développer le modèle de fournisseur d'infrastructure et valider la cible dans un modèle de système d'infrastructure. Les interfaces de votre modèle de service doivent toutes être clairement identifiées dans votre modèle d'interface.
L'agilité de l'entreprise nécessite un modèle de services d'infrastructure performant. Il est essentiel de savoir identifier et supprimer les obstacles au changement.
Modèle d'interface
Un modèle d'interface identifie la manière dont vous connectez les différents composants de votre infrastructure entre eux, ainsi que la manière dont les applications et les données y accèdent. Développer une architecture PaaS de cloud privé sans modèle d'interface est impossible. Vous pourrez désormais connecter des services de plusieurs fournisseurs PaaS de cloud public.
Vous poursuivez les frontières entre les systèmes. Vous devez préciser si et comment une frontière peut être franchie. Trop souvent, les architectes technologiques omettent de préciser les limites infranchissables. La plupart des infrastructures rigides et immuables résultent de cet échec.
Le modèle d’interface est essentiel pour permettre l’agilité de l’entreprise, gérer le portefeuille d’infrastructures et réduire les coûts informatiques.
Modèle de cycle de vie
Un modèle de cycle de vie identifie les exigences qui sous-tendent la conception de l'infrastructure et la réalité de l'infrastructure physique. Nous utilisons ce modèle pour identifier le cycle de vie dont nous disposons et dont nous avons besoin. Il y a des années, nous avons développé une architecture de communication dans une zone montagneuse et protégée. Cette architecture comportait un ensemble d'exigences spécifiques en matière de cycle de vie, qui ont guidé la conception et les exigences opérationnelles.
Catalogue des normes
Trop souvent, les architectes avec lesquels nous collaborons partent du principe qu'un catalogue de normes technologiques dictera les préférences opérationnelles de l'infrastructure dans l'architecture. Ils supposent que les autres domaines seront informés des normes technologiques. Cela n'est vrai qu'après l'approbation de l'architecture technologique par les parties prenantes. Tant que ces dernières n'ont pas approuvé l'architecture, la gouvernance de l'architecture est impossible.
La première utilisation d'un catalogue de normes d'architecture est d'identifier les infrastructures non conformes, lesquelles ajoutent rigidité, coût, complexité et déficiences à l'architecture technologique de base et à tous les autres domaines.
Votre catalogue de normes orientera l'approvisionnement en infrastructures. En l'absence de modèles de services d'infrastructure ou d'interfaces d'infrastructure efficaces, il fournira des orientations et des contraintes aux autres domaines et aux implémenteurs.
Modèle physique de l'infrastructure
Un modèle physique décrit le portefeuille d'infrastructures réel. Utilisez toujours la terminologie des fournisseurs d'infrastructures commerciales. Vous devrez l'associer aux autres modèles d'architecture technologique pour intégrer la cible au monde réel.
Le modèle physique identifie de nombreuses lacunes dans les modèles d'architecture technologique plus abstraits. Il constitue également la base de Plan de mise en œuvre et de migration élaboré au cours de la phase F.
Techniques d'architecture technologique
Nous utilisons un large éventail de techniques pour développer et communiquer notre architecture d’entreprise.
- Architectures de référence technique
- UML est omniprésent dans un développement piloté par les modèles performant. Si vous travaillez en architecture pour soutenir le développement de solutions, un modèle système et un modèle d'interface doivent être développés conformément aux pratiques UML.
- Les vues 4+1 permettent d'identifier les implications de la cible pour différentes communautés. Développer des modèles 4+1 permet de s'assurer de prendre en compte tous les changements pertinents.
Modèles d'architecture technologique alignés sur l'objectif de l'architecture d'entreprise
Le niveau de questionnement auquel répond votre architecture métier influencera l'utilisation de différents modèles d'architecture métier. Par exemple, l'architecture de soutien au portefeuille ne développera souvent pas de modèle de chaîne de valeur. Au contraire, une chaîne de valeur constituera généralement une architecture supérieure et limitera votre liberté.
| Architecture pour soutenir la stratégie | Architecture pour soutenir le portefeuille | Architecture pour soutenir le projet | Architecture pour soutenir la livraison de solutions | |
| Modèle de fournisseur d'infrastructure | Livrable clé | Livrable clé | Architecture supérieure | Architecture supérieure |
| Modèle de système d'infrastructure | Livrable régulier | Livrable clé | Architecture supérieure | Architecture supérieure |
| Modèle de service d'infrastructure | Livrable régulier | Livrable clé | Livrable clé & Architecture supérieure | Livrable clé & Architecture supérieure |
| Modèle d'interface | Rarement utilisé | Livrable occasionnel
Un niveau de détail approprié diminue souvent la valeur |
Livrable clé | Livrable clé & Architecture supérieure |
| Modèle de cycle de vie | Livrable occasionnel
Un niveau de détail approprié diminue souvent la valeur |
Livrable clé
Un niveau de détail approprié diminue souvent la valeur |
Livrable clé & Architecture supérieure | Architecture supérieure |
| Catalogue des normes | Rarement utilisé | Livrable occasionnel
Un niveau de détail approprié diminue souvent la valeur |
Livrable clé & Architecture supérieure | Architecture supérieure |
| Modèle physique de l'infrastructure | Rarement utilisé | Livrable occasionnel
Un niveau de détail approprié diminue souvent la valeur |
Livrable clé & Architecture supérieure | Livrable clé & Architecture supérieure |
Influence des modèles d'architecture d'application sur les modèles d'architecture technologique
| Mode de développement d'application | Modèle de système | Modèle de produit | Modèle d'intégration | Service d'application | |
| Modèle de fournisseur d'infrastructure | Entrée majeure | Entrée majeure | Entrée majeure | Entrée majeure
Nécessite un système ou un modèle fonctionnel |
Entrée majeure
Nécessite un système ou un modèle fonctionnel |
| Modèle de système d'infrastructure | Entrée majeure | Entrée majeure | Entrée majeure | Entrée limitée | Entrée limitée |
| Modèle de service d'infrastructure | Entrée majeure | Entrée majeure | Entrée majeure | Meilleure entrée
Un lien direct est difficile à établir. Le travail en vaut la peine. |
Meilleure entrée
Un lien direct est difficile à établir. Le travail en vaut la peine. |
| Modèle d'interface | Entrée majeure | Entrée majeure | Meilleure entrée
Un lien direct est difficile à établir. Le travail en vaut la peine. |
Meilleure entrée
Un lien direct est difficile à établir. Le travail en vaut la peine. |
|
| Modèle d'infrastructure physique | Saisir | Entrée majeure
Nécessite un modèle de fournisseur |
Entrée limitée
Les liens sont importants, mais un lien direct est difficile à voir |
Entrée limitée
Les liens sont importants, mais un lien direct est difficile à voir |
Influence des modèles d'architecture d'entreprise sur les modèles d'architecture technologique
| Modèle d'affaires | Modèle opérationnel | Chaîne de valeur | Modèle de capacité | Modèle de processus | Modèle fonctionnel | Modèle d'information | Modèle d'organisation | |
| Modèle de fournisseur d'infrastructure | Entrée majeure
Nécessite un système ou un modèle fonctionnel |
Entrée majeure
Nécessite un système ou un modèle fonctionnel |
Entrée majeure
Nécessite un système ou un modèle fonctionnel |
Entrée majeure
Nécessite un système ou un modèle fonctionnel |
Entrée majeure
Nécessite un système ou un modèle fonctionnel |
Entrée majeure
Nécessite un système ou un modèle fonctionnel |
Entrée limitée | Entrée limitée |
| Modèle de système d'infrastructure | Entrée limitée | Entrée limitée | Entrée limitée | Entrée limitée | Entrée limitée | Entrée majeure | Entrée limitée | Entrée majeure |
| Modèle de service d'infrastructure | Entrée limitée
Les liens sont importants, mais un lien direct est difficile à voir |
Entrée limitée
Les liens sont importants, mais un lien direct est difficile à voir |
Entrée limitée
Les liens sont importants, mais un lien direct est difficile à voir |
Meilleure entrée
Un lien direct est difficile à établir. Le travail en vaut la peine. |
Utilisé comme test d'exhaustivité | Entrée majeure
Un lien direct est difficile à établir. Le travail en vaut la peine. |
Entrée majeure | |
| Modèle d'interface | Contribution majeure sur l'existence de l'interface
Nécessite un système ou un modèle fonctionnel |
Entrée limitée
Les liens sont importants, mais un lien direct est difficile à voir |
Contribution majeure sur l'existence de l'interface
Nécessite un système ou un modèle fonctionnel |
Contribution majeure à la conception du noyau | Contribution majeure à la conception du noyau
Nécessite un système ou un modèle fonctionnel |
|||
| Modèle d'infrastructure physique | Contribution majeure à l'existence de l'emplacement de l'infrastructure
Nécessite un modèle de fournisseur |
Contribution majeure à l'existence de l'emplacement de l'infrastructure
Nécessite un modèle de fournisseur |
Entrée limitée
Les liens sont importants, mais un lien direct est difficile à voir |
Entrée limitée
Les liens sont importants, mais un lien direct est difficile à voir |
Contribution à la conception du noyau | Entrée limitée
Les liens sont importants, mais un lien direct est difficile à voir |
Modèles d'architecture technologique pour les cas d'utilisation de l'architecture d'entreprise
Chaque cas d'utilisation d'architecture d'entreprise Il s'agit de favoriser un changement efficace. Il existe de nombreux types de changement. Nos cas d'utilisation d'architecture d'entreprise répondent à des questions courantes.
Quel que soit le cas d'utilisation, les architectes technologiques poursuivent le même objectif : aider leurs parties prenantes à prendre de meilleures décisions et à mener à bien des initiatives de changement.
| Changement stratégique | Changement progressif | Améliorer les coûts | Améliorer la qualité | Améliorer l'agilité de l'entreprise | Atténuer les risques technologiques | Modernisation des TI | Transformation numérique | Rationalisation du portefeuille d'applications | Intégration des acquisitions | |
| Modèle de fournisseur d'infrastructure | Très utile | Principales contraintes | Lignes directrices clés | Contraintes critiques | Lacunes et contraintes critiques | Lacunes et contraintes critiques | Lacunes et contraintes critiques | Lacunes et contraintes critiques | Lacunes et contraintes critiques | Lacunes et contraintes critiques |
| Modèle de système d'infrastructure | Très utile
Lacunes et contraintes critiques |
Lacunes et contraintes critiques | Lacunes et contraintes critiques | Lacunes et contraintes critiques | Lacunes et contraintes critiques | Lacunes et contraintes critiques | ||||
| Modèle de service d'infrastructure | Très utile
Lacunes et contraintes critiques |
Très utile
Lacunes et contraintes critiques |
Très utile
Lacunes et contraintes critiques |
Très utile
Lacunes et contraintes critiques |
Très utile
Lacunes et contraintes critiques |
Très utile
Lacunes et contraintes critiques |
Très utile
Lacunes et contraintes critiques |
Très utile
Lacunes et contraintes critiques |
Très utile
Lacunes et contraintes critiques |
Très utile
Lacunes et contraintes critiques |
| Modèle de cycle de vie | Très utile
Lacunes et contraintes critiques |
Lacunes et contraintes critiques | Très utile
Lacunes et contraintes critiques |
Très utile
Lacunes et contraintes critiques |
Lacunes et contraintes critiques | Lacunes et contraintes critiques | Très utile
Lacunes et contraintes critiques |
Lacunes et contraintes critiques | Lacunes et contraintes critiques | Lacunes et contraintes critiques |
| Modèle de catalogue de normes | Très utile pour les lacunes et les contraintes | Très utile
Contraintes critiques |
Très utile
Contraintes critiques |
Très utile
Contraintes critiques |
Contraintes | Lacunes et contraintes | Lacunes et contraintes | Très utile pour les lacunes et les contraintes |
Application des principes de l'architecture d'entreprise à l'architecture technologique
Il y a 7 principes d'architecture que tout architecte d'entreprise devrait connaître. Les principes sont une architecture supérieure et limitent votre liberté lors du développement de l'architecture. Chacun de vos principes d'architecture limiter le développement de votre architecture technologique. Testez toujours votre architecture candidate ; ne trouvez pas d'affirmation d'alignement. Prouvez que vous respectez la lettre et l'esprit. Vous savez que le principe est correct. Dans la phase D de TOGAF ADM, vous devez prouver la conformité de l'architecture technologique.
| Implications de l'architecture technologique | |
| Ne jouez pas avec le succès | Chercher à éliminer le changement. Oui, éliminer tout changement qui n'est pas explicitement justifié. |
| Se concentrer sur l'excellence | Tirez parti de la Modèle de capacité et le Modèle de développement d'applications pour garantir que la technologie permette l’excellence de l’entreprise.
Alignez-vous avec le Modèle de produit numérique. Le produit et le service sont directement destinés au client et ont des normes minimales très différentes. |
| Pourquoi pas un ? | Tirez parti de la Modèle de développement d'applications et le modèle de service d'infrastructure pour identifier les doublons interdits, puis les éliminer. |
| Les données sont un atout | Assurer que l’infrastructure répond aux exigences de gestion et d’utilisation des actifs. |
| Les systèmes fonctionnent là où nous travaillons | Le lieu et le style de travail déterminent l’infrastructure. |
| Expérience utilisateur sans douleur | Les programmes de différenciation, de transformation et d'efficacité nécessitent des modèles de coûts générateurs de productivité. La plupart du temps, on élimine la dégradation de la productivité, au lieu de l'améliorer. |
| En libre service | Les activités d'administration et de déploiement d'infrastructures sont coûteuses lorsqu'elles ne sont pas accessibles en libre-service. Tout obstacle à l'accès libre-service nuit à la productivité et aux changements. |
Comment TOGAF Phase D s'aligne-t-il sur le développement Agile ?
L'infrastructure favorise ou freine la valeur potentielle du développement agile. Si votre organisation a besoin d'une solide capacité de développement agile, vous devez structurer votre infrastructure autour de cette capacité. Modèle de développement d'applications identifiera la portée et si le développement agile est utile ou essentiel.
Appuyez-vous sur votre modèle de fournisseur d’infrastructure et votre modèle de service d’infrastructure pour aligner l’architecture technologique sur vos besoins Agile.
Aucun des quatre domaines où l'architecture d'entreprise interagit avec le développement agile ne s'aligne toujours sur l'architecture technologique. L'alignement direct provient de Modèle de produit. Outre l’alignement direct, examinez toujours les services d’infrastructure.
Comment TOGAF Phase D permet-il l’agilité de l’entreprise ?
Comme nous le savons, l'agilité d'entreprise n'a rien à voir avec la façon dont on développe des logiciels. Elle correspond à la capacité de votre entreprise à réagir aux menaces et opportunités inattendues. C'est aussi simple que ça : pouvez-vous réagir à l'inattendu ?
Le modèle d'agilité d'entreprise comporte cinq points :
- Vigilance – Pouvez-vous détecter les opportunités et les menaces ?
- Accessibilité – Pouvez-vous accéder aux informations pertinentes à temps pour répondre ?
- Capacité de décision – Pouvez-vous décider en utilisant les informations disponibles ?
- Rapidité – Pouvez-vous mettre en œuvre vos décisions dans le temps imparti ?
- Flexibilité – Que faites-vous pour réduire les obstacles à l’action ?
La plupart du temps, l'architecture d'entreprise repose sur la flexibilité (#5). Identifiez chaque point source de rigidité et supprimez-le. Dans notre planification du cycle de vie de l'infrastructure, nous ne prenons pas en compte chaque avantage non réalisé dans les deux ans. Cela représente une charge importante pour l'architecture technologique et illustre l'attrait du PaaS de cloud public.
Réflexions finales sur TOGAF ADM Phase D
Réussi équipes d'architecture d'entreprise Ne gaspillez pas vos architectes technologiques à concevoir et à guider la mise en œuvre de l'infrastructure. Cela confond un architecte technologique avec un architecte de solutions. Cela nuit à la architecture d'entreprise.
Les architectes technologiques doivent élaborer des lignes directrices et des garde-fous pour les personnes qui conçoivent, mettent en œuvre et, potentiellement, inventent le portefeuille d'infrastructures de l'entreprise. En bref, l'architecte technologique d'entreprise n'est pas un architecte de solutions ni un spécialiste en technologie appelé architecte technologique. Bien que ces rôles soient importants, ils ne contribuent pas à une équipe EA.
Dans la phase D de TOGAF ADM, vous développez l'un des quatre domaines fondamentaux de l'architecture d'entreprise. TOGAF précise que vous développez cette architecture avec les autres domaines. La différence réside dans le fait que l'architecture technologique entraîne souvent des changements en dehors de la plupart des initiatives de changement. Votre infrastructure est un actif immobilisé à long terme qui évolue à un rythme très différent. Elle doit être opérationnelle avant même d'être nécessaire et mise à jour selon son cycle.
Les architectes technologiques à succès guident et limitent :
- L'architecte d'entreprise, les architectes de domaine à l'art du possible
- Les planificateurs d'infrastructures sur les critères de réussite
- Architectes de solutions et architectes technologiques spécialisés sur les critères de jugement, les critères de réussite et les priorités
Les grands architectes technologiques favorisent l'agilité de l'entreprise et le développement agile de logiciels. Ils privilégient l'équilibre entre efficacité et agilité.
TOGAF ADM Phase D développe l'architecture technologique. Cette architecture est le fondement de toute entreprise numérique moderne. Utilisez TOGAF Phase D pour concentrer les ressources limitées en matière de changement sur l'efficacité et l'agilité. Cela permet de générer une valeur durable pour l'entreprise grâce aux investissements en infrastructure.
