TOGAF ADM Phase C — Développer l'architecture de l'application
En un coup d'oeil
- TOGAF Phase C en action
- Qu'est-ce que l'architecture d'application
- Quel est le rôle de l’architecte d’entreprise dans la phase C ?
- Quel est le rôle de l'architecte d'application ?
- Quel est le rôle de l’architecte de sécurité dans l’architecture des applications ?
- Quel est le rôle de l’équipe EA dans l’architecture des applications ?
Connaissances essentielles de la phase C
Réflexions finales sur TOGAF ADM Phase C - Architecture d'application
Présentation de TOGAF ADM
Le TOGAF ADM est une approche logique de la création de connaissances. Connaissances utilisées pour développer une architecture d'entreprise qui guide le changement efficace. Ensuite, les connaissances pour garantir que la valeur attendue est atteinte.
Le TOGAF ADM est divisé en phases, chaque phase étant axée sur la création de connaissances utilisées pour :
- sélectionner le chemin à suivre et la cible
- effectuer gouvernance de la mise en œuvre
- évaluer le chemin à parcourir et corriger le cap
Qu'est-ce que TOGAF Phase C ?
La phase C approfondit le concept de domaines d'architecture. Cette phase développe l'architecture de l'application et l'architecture des données. Formellement, la phase C se divise en deux parties : Domaine d'architecture des données et le domaine d'architecture d'application sont individuels.
Comme la phase B, la phase C s'appuie sur la vision architecturale. Cependant, la phase C a également pour mission de mettre en œuvre l'architecture métier. Il ne s'agit pas de traiter l'architecture métier comme des exigences, mais de confirmer la cohérence des objectifs récapitulatifs en développement.
Les changements dans un domaine imposent des contraintes et des exigences aux autres domaines. L'objectif est de trouver le meilleur ensemble de changements pour tous les domaines.
En suivant les étapes de la phase C, les architectes développent les connaissances suivantes :
- quelle architecture de référence accélérera le développement de l'architecture
- quels points de vue guideront l'analyse pertinente pour permettre aux parties prenantes de choisir entre différentes alternatives architecturales
- quels modèles d'architecture d'application et modèles de données aideront à trouver la source de la déficience et les changements qui y remédieront
- où les changements dans l'architecture des applications entraînent des changements dans d'autres domaines
- où les changements dans d'autres domaines entraînent des changements dans l'architecture de l'application
Elle crée les produits centraux suivants :
- des points de vue qui analysent l'architecture des systèmes d'information candidats en fonction des préoccupations des parties prenantes
- qu'une architecture d'application cible actuelle et candidate
- lacunes de l'architecture des applications
- produits de travail des candidats qui changent l'entreprise
La phase C se concentre sur des aspects tels que la conception de l'application, le flux de données, l'intégration, l'approche de développement, la conception et l'achat, et la planification des modifications. Une évaluation et une compréhension approfondies de cette phase sont essentielles.
Qu'est-ce que TOGAF Phase C ?
Dans TOGAF Phase C, vous créez l’architecture de l’application. Architectes d'applications diriger le développement de votre architecture applicative. décisions architecturales réalisé en phase C pour l'architecture d'application interagissent avec les décisions prises dans chaque domaine d'architecture d'entreprise.
Phase C en action
L'architecture de l'application aidera à répondre aux questions suivantes :
- Comment le portefeuille d’applications permet de capturer de la valeur – Modèle de développement d'applications
- Où le coût est injecté dans le portefeuille informatique - Modèle fonctionnel
- Là où la rigidité est injectée dans le portefeuille informatique - Modèle d'intégration
- Comment fonctionne l'entreprise – Modèle de système
- Systèmes nécessaires pour fournir le produit ou le service – Modèle de produit
- Les choses qu'une organisation doit être capable de faire - Modèle fonctionnel
- Le flux d'informations nécessaires à la réalisation des activités d'une entreprise - Modèle d'intégration
- L'ensemble des activités qu'une entreprise exécute, généralement regroupées pour montrer comment elles sont liées les unes aux autres. Modèle de service
- Quel est le portefeuille de logiciels ? Modèle physique
Gardez toujours à l'esprit que vous cherchez à améliorer l'organisation. L'amélioration exige du changement et crée de la valeur. La valeur et le coût du changement sont mesurables. L'incertitude diminue toujours la valeur potentielle. L'incertitude augmente toujours les coûts. Nous traitons l'incertitude comme un impact géométrique. Une légère incertitude diminue considérablement la valeur potentielle.
Lors de votre lecture, gardez à l'esprit que les mêmes termes peuvent être utilisés de nombreuses fois. Recherchez l'objectif du modèle et ne vous laissez pas piéger par une appellation différente de celle que vous lui donneriez. Par exemple, ce que vous appelez un modèle fonctionnel sera appelé un service par quelqu'un d'autre. conseil en architecture d'entreprise, nous nous concentrons toujours sur ce que nous essayons de comprendre, et non sur le nom du modèle.
Différents modèles expliqueront différents aspects de l'entreprise. Ensemble, ces modèles et les modifications nécessaires forment l'architecture applicative.
Qu'est-ce que l'architecture d'application ?
Une architecture applicative est une description de votre portefeuille logiciel complet qui vous indique quand acheter, quand utiliser le SaaS et quand développer. Elle vous indique où placer les limites entre les systèmes et comment aborder le cycle de vie de vos logiciels.
Nous pouvons garantir que votre architecture applicative actuelle n'est pas alignée avec votre architecture métier. Une architecture applicative nécessite architecture d'entreprise. Le développement de l’architecture d’entreprise nécessite que les architectes d’applications se joignent à eux et interagissent avec les parties prenantes.
Avec les parties prenantes et l'architecte métier, l'architecte applicatif explore comment les choix logiciels favorisent et limitent la réalisation des objectifs de l'organisation. Nous étudions les améliorations potentielles afin d'en comprendre l'impact immédiat et à moyen terme. Ensemble, les changements potentiels qui n'apportent pas suffisamment de résultats, nécessitent trop de travail ou comportent trop d'incertitudes sont supprimés de la feuille de route de l'architecture.
Quand nous sommes développer des équipes d'architecture d'entreprise, nous disons au architectes d'entreprise deux faits essentiels concernant TOGAF Phase C - Architecture d'application. Premièrement, jusqu'à ce que vous ayez une Modèle de développement d'applications, Vous ne pouvez pas continuer. Tant que vous ne savez pas comment vos choix d'applications optimisent et limitent votre architecture métier, les détails de vos applications sont inutiles. Deuxièmement, s'ils pensent devoir se lancer dans les fonctionnalités et l'intégration des applications, ils développeront toujours une architecture applicative de faible qualité.
Dans un style moderne entreprise transformée numériquement, tous les domaines d'architecture interagissent. Les choix effectués dans un domaine activent, fournissent ou bloquent les résultats d'un autre domaine. La plupart des objectifs métier dépendent de bonne architecture informatique. Ironiquement, nous ne pouvons développer la bonne architecture d’application que si nous disposons d’une architecture d’entreprise solide.
Quel est le rôle de l’architecte d’entreprise dans la phase C ?
Dans la phase C de TOGAF, le rôle de l'architecte d'entreprise est de préserver la valeur totale. Selon les compétences des architectes de domaine, il doit intervenir. Par exemple, un architecte d'application peut ne pas percevoir l'impact des changements sur l'architecture métier. Il peut également 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.
Quel est le rôle de l’architecte d’application dans la phase C ?
Lors de la phase C de TOGAF, l'architecte d'applications doit fournir l'architecture du domaine. Cela nécessite de développer des modèles qui identifient l'origine du problème et les solutions pour le résoudre. Il mènera une analyse des compromis avec les parties prenantes afin de déterminer l'architecture cible.
L'architecte d'application devra collaborer avec les autres architectes de domaine.
Démarrez l'architecture métier. Connaissez et comprenez Modèle opérationnel et les attributs Compétence et Automatisation du Modèle de capacité.
Quel est le rôle de l’architecte de sécurité en phase C ?
Lors de la phase C de TOGAF, l'architecte d'applications doit fournir l'architecture du domaine. Cela nécessite de développer des modèles qui identifient l'origine du problème et les solutions pour le résoudre. Il mènera une analyse des compromis avec les parties prenantes afin de déterminer l'architecture cible.
L'architecte d'application devra collaborer avec les autres architectes de domaine.
Démarrez l'architecture métier. Connaissez et comprenez Modèle opérationnel et les attributs Compétence et Automatisation du Modèle de capacité.
Gardez à l’esprit que les déficiences dans un domaine sont souvent résolues dans un autre, et que les changements dans un domaine imposent souvent des coûts et des changements dans un autre.
Quel est le rôle de l'équipe EA dans l'architecture des applications
Gardez à l’esprit que les déficiences dans un domaine sont souvent résolues dans un autre, et que les changements dans un domaine imposent souvent des coûts et des changements dans un autre.
Interaction avec TOGAF Phase B, Phase D et Phase E
Les approches en cascade ne sont pas efficaces. Les meilleures pratiques en matière d'architecture d'entreprise ne se résument pas à une activité en cascade. La seule approche réussie nécessite le développement de l'architecture métier, de l'architecture applicative, de l'architecture des données, de l'architecture technologique et architecture de sécurité simultanément. Le développement simultané nécessite une approche agile juste assez pour tester les contraintes en cascade.
La séquence classique impliquée dans de nombreux diagrammes TOGAF ADM est l'ordre dans lequel nous pouvons clôturer le développement de l'architecture, et non le démarrer.
Ne vous laissez pas berner par l'illusion que l'entreprise est séparée de ses applications, données et infrastructures. Ce n'était pas vrai autrefois, et dans une entreprise numérique moderne, c'est ridicule. Cette illusion est le moyen le plus rapide d'éliminer les risques. agilité de l'entreprise ou la chance de transformation numérique succès.
Les architectes d'applications jouent un rôle essentiel au sein d'une équipe d'architecture d'entreprise. Dans une entreprise numérique moderne, rien ne se passe sans logiciels. De mauvais choix d'applications peuvent paralyser…'l'entreprise.Les architectes d'applications sont des spécialistes d'un domaine d'architecture. Ils ne peuvent concevoir leur domaine sans un engagement régulier avec architectes d'entreprise, données, technologie et architectes de sécurité.
Conversations sur le plan de jeu de l'IA agentique
Conversations autour du guide pratique de l'IA agentique : Nous nous sommes pleinement investis dans l'évolution du paysage de l'adoption de l'IA, en abordant à la fois les complexités techniques et la transformation numérique au sens large. Nous avons élaboré le Guide du dirigeant d'entreprise […]
Télécharger l'architecture de référence des capacités critiques d'adoption de l'IA
Téléchargez l'architecture de référence des capacités critiques pour l'adoption de l'IA. L'adoption de l'IA exige une réflexion novatrice. Aujourd'hui, nous ne disposons pas de bonnes pratiques éprouvées pour une adoption généralisée de l'IA qui améliorent systématiquement nos organisations. Nous devons être capables de repenser notre […]
Téléchargez le guide du chef d'entreprise sur l'IA
Téléchargez le Guide du chef d'entreprise sur l'intelligence artificielle. Les organisations qui utilisent avec succès des technologies innovantes bénéficient d'un avantage concurrentiel. Une technologie innovante ne s'accompagne pas de modèles de réussite établis ni de bonnes pratiques. Une technologie innovante est nouvelle et […]
Téléchargez l'introduction à la norme TOGAF, 10e édition
Téléchargez l'introduction à la norme TOGAF®, 10e édition. La norme TOGAF, 10e édition, facilite l'adoption des meilleures pratiques d'architecture d'entreprise. Elle distingue les concepts universels des meilleures pratiques éprouvées. La norme souligne où […]
Télécharger le guide de planification basé sur les capacités
Téléchargez le guide de planification basée sur les capacités. Cherchez toujours à créer de la valeur. Une demi-amélioration, c'est 100% de gaspillage ! Personne n'apprend à un aigle à ramper, marcher ou courir. Les aigles volent ! Téléchargez « Apprenez à vos aigles à voler » : Planification basée sur les capacités […]
Télécharger le guide d'évaluation des capacités d'architecture d'entreprise
Téléchargez le guide d'évaluation des capacités de l'architecture métier. Téléchargez un guide d'évaluation des capacités de l'architecture métier. La planification par les capacités est l'une des techniques d'amélioration de l'architecture métier les plus efficaces. Les bonnes pratiques de planification par les capacités utilisent les capacités comme un outil de gestion.
Télécharger un exemple de principes d'architecture d'entreprise
Téléchargez un exemple de principes d'architecture d'entreprise. Ces principes identifient la manière d'aborder un problème ou une décision. Cette approche vous guide toujours vers vos priorités. Téléchargez un exemple de principes d'architecture d'entreprise […]
Télécharger le guide de gouvernance de l'architecture d'entreprise
Téléchargez le Guide de gouvernance de l'architecture d'entreprise. Téléchargez le Guide de gouvernance de l'architecture d'entreprise pour comprendre les meilleures pratiques permettant de piloter et de contrôler le développement de l'architecture, ainsi que les modifications nécessaires pour obtenir les résultats escomptés. Téléchargez le Guide de gouvernance de l'architecture d'entreprise […]
Télécharger l'intégration TOGAF et SABSA
Téléchargez l'intégration TOGAF et SABSA. Associez SABSA, le meilleur framework d'architecture de sécurité au monde, et TOGAF, le framework d'architecture d'entreprise standard du secteur. Téléchargez l'intégration TOGAF et SABSA. L'intégration TOGAF et SABSA inclut : SABSA utilise […]
Télécharger l'architecture de référence des capacités d'architecture d'entreprise
Téléchargez l'architecture de référence des capacités d'architecture d'entreprise. Cette architecture accélérera la mise en place et le développement de votre équipe d'architecture d'entreprise. Concevez votre équipe d'architecture d'entreprise pour réussir. Identifiez et améliorez votre architecture d'entreprise […]
Connaissances essentielles de la phase C
Toutes les phases du programme TOGAF ADM vous permettent de développer les connaissances nécessaires. La phase C aboutit à l'architecture de l'application candidate, intégrée à l'architecture des systèmes d'information candidats.
| Résultats et résultats | Connaissances essentielles |
| Le architecture d'application architecture de domaine approuvé par les parties prenantes pour le problème traité, avec un ensemble de lacunes, et travailler pour combler les lacunes comprises par les parties prenantes. | Comment le portefeuille de logiciels 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 4 de Guide de la série TOGAF : Guide de l'architecte d'entreprise pour le développement de l'architecture
Phase C Bare Bones
La phase C permet de simplifier le travail d'un architecte d'applications et de déterminer les axes d'amélioration d'une entreprise. Cela nécessite de comprendre ses objectifs, ses points faibles et les changements nécessaires pour atteindre l'excellence.
Les éléments essentiels de la phase C sont :
- Connaître comment le portefeuille d'applications permet de capter de la valeur
Chaque organisation possède une chaîne de valeur. Cette activité transforme un intrant en quelque chose de plus précieux pour ses clients. Les applications créent de la valeur ou assurent la tenue de registres. Traditionnellement, la quasi-totalité des logiciels assuraient la tenue de registres.
Vous devez optimiser votre logiciel pour la création de valeur ou la tenue de registres. Tenez compte de la tenue de registres. Ne confondez pas le rôle important de la tenue de registres avec celui de la création de valeur.
Connaître la source des coûts et de la complexité
Chaque portefeuille d'applications engendre des coûts et de la complexité. Nous considérons le logiciel comme un mécanisme complexe, assemblé au fil du temps. Nous avons tout connecté à tout. Avec les produits numériques, les services informatiques sont omniprésents. comprendre l'ITFM est une compétence fondamentale.
Vous devez optimiser votre portefeuille principal pour éliminer les coûts et la complexité persistants. Vous devez permettre agilité de l'entreprise. Les organisations numériques modernes ne peuvent s’améliorer qu’au rythme des logiciels.
- Savoir sélectionner un logiciel
Il existe quatre modèles logiciels : SaaS, suites d'entreprise, packages commerciaux spécialisés et développement personnalisé. Chacun possède un modèle de coût et d'optimisation différent. Il est essentiel d'appliquer le bon modèle logiciel aux bons endroits.
- Savoir quand le logiciel fait partie de ''le produit'
Nos organisations fournissent un produit ou un service. Un logiciel qui est 'le produit' diffère grandement des logiciels qui soutiennent l'entreprise.
- Connaître le flux d'informations
Les gens sont infiniment flexibles. Nous pouvons décider de partager des informations. Nous pouvons anticiper une situation et réagir. Les logiciels font exactement ce qu'on leur dit. Ils ne font que ce qu'on leur dit.
Les flux d'informations circulent autour des logiciels pour accomplir les tâches nécessaires. Ce type de flux nuit à l'agilité de l'entreprise, entrave son efficacité et engendre des coûts.
- Connaître les attentes des logiciels
Parfois, nous avons besoin d'un archiviste occasionnel. Parfois, nous avons besoin d'un système autonome. La plupart du temps, nous avons besoin d'un outil qui facilite les choses sans imposer de frais supplémentaires. Nous exploitons les concepts et les attributs de modèles de capacité pour guider les choix concernant l'architecture de nos applications. Voir le Guide d'évaluation des capacités d'architecture d'entreprise.
- Savoir ce que l'organisation doit faire
Chaque entreprise doit exécuter un ensemble de processus : création de valeur primaire, support et administration. Chacune d'entre elles a besoin de logiciels. Chacune crée et produit des informations. Il est essentiel de savoir de quoi il s'agit, quelles informations elles consomment et qui les utilise.
- Que faut-il changer pour offrir le meilleur portefeuille d’applications ?
Nous développons des architectures applicatives pour améliorer une organisation. La plupart des changements n'ont pas d'impact significatif. La plupart restent superficiels. Concentrez-vous sur les changements concrets qui favorisent l'agilité, la réduction des coûts et la création de valeur pour l'entreprise.
Les trois éléments essentiels de l’achèvement de la phase C :
- D'abord, Que faut-il changer ? Changement d'orientation, de structure organisationnelle, montée en compétences, externalisation, internalisation, automatisation. Autant de changements. Nous les mettons en œuvre pour améliorer une organisation.
- Deuxième, Quand faut-il le modifier ? Y a-t-il des dépendances ? Qu'en est-il des conditions préalables ? Prévoyez-vous de modifier les paramètres pour un changement ultérieur ?
- Troisième, 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 ?
Les parties prenantes de l'architecture d'entreprise sont responsables de toutes les décisions concernant les changements à apporter et leur calendrier. L'architecte applicatif décrit les tests de gouvernance pour permettre aux parties prenantes de piloter le projet de changement, ainsi que les deuxième et troisième résultats.
Formation en architecture d'entreprise et formation TOGAF
Kickstart d'Enterprise Architect
Programme de démarrage rapide pour les architectes d'entreprise. Nous devons maintenir nos compétences à jour. Plus que jamais. Utilisez le programme de démarrage rapide pour l'architecture d'entreprise afin d'améliorer votre capacité à déployer une architecture d'entreprise transformatrice. Ce programme de démarrage rapide de 90 jours est la façon dont Conexiam Consulting […]
Cours de formation Avolution ABACUS
Formation Avolution ABACUS : une architecture d'entreprise efficace repose sur la modélisation et l'analyse formelles. Nous proposons des formations Avolution ABACUS dispensées par des architectes d'entreprise expérimentés. Les étudiants acquièrent les compétences et les connaissances nécessaires pour créer des architectures d'entreprise et de domaine intégrées dans ce domaine.
Éducation en ligne efficace
Formation en ligne efficace : une formation en ligne efficace fonctionne. Les étudiants ont accès au meilleur instructeur disponible. Ils maîtrisent leur rythme d'apprentissage. Les enseignants peuvent partager des ressources complémentaires riches sans détourner l'attention du sujet principal. Une formation à distance efficace […]
Formation personnalisée à l'architecture d'entreprise
Formation personnalisée en architecture d'entreprise. Cette formation répond aux besoins de développement professionnel de votre équipe d'architectes d'entreprise. Les bons architectes d'entreprise utilisent un large éventail de compétences, de méthodes et une connaissance pointue du domaine pour développer l'architecture d'entreprise.
Cours de formation à l'architecture d'entreprise TOGAF
Souhaitez-vous obtenir une formation pour la certification TOGAF ? Démontrez vos connaissances en architecture d'entreprise avec la certification TOGAF. Formation TOGAF® en architecture d'entreprise. Faites un pas de géant pour devenir un meilleur architecte d'entreprise avec la norme TOGAF, 10e […]
Cours de formation en architecture d'entreprise
Formation en architecture d'entreprise : une architecture d'entreprise efficace repose sur l'architecture d'entreprise. Ce cours apporte aux étudiants les compétences et les connaissances nécessaires pour développer une architecture d'entreprise dans un contexte d'architecture d'entreprise. L'architecture d'entreprise consiste à décrire la structure de […]
Livrables de l'architecture d'application TOGAF ADM Phase C
L'un des principaux résultats de la phase C est l'architecture applicative. Celle-ci constitue une partie de l'architecture d'entreprise complète.
Livrables de l'architecture d'application TOGAF Phase C et cas d'utilisation de l'architecture d'entreprise
Le développement d'une architecture d'entreprise répond à quatre objectifs principaux. Les livrables de la Phase C de TOGAF 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 C : Architecture d'application 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 C : é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 C : 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 3 Guide de la série TOGAF : Guide de l'architecte d'entreprise pour le développement de l'architecture
Architecture des candidatures
Le développement d'une architecture d'entreprise répond à quatre objectifs principaux. L'importance des différents modèles varie selon l'objectif.
Composants de la feuille de route de l'architecture des applications candidates
Que faut-il changer ? Si vous modifiez le modèle de développement d'applications, la différence entre la version actuelle et la version cible correspond à la feuille de route candidate. Il en va de même pour tout ce qui est nécessaire pour permettre ce changement.
Nous utilisons souvent un modèle système pour synthétiser le changement. Ce modèle offre juste assez d'abstraction par rapport aux logiciels réels pour permettre une discussion sur la planification et l'exécution. Nous utilisons généralement des scores et des lots de travaux pour articuler un changement. 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 des applications candidates
Définissez comment vous évaluerez le changement. Comment l'amélioration sera-t-elle évaluée ?
Nous utilisons souvent des scores dans nos modèles pour décrire les exigences. Chaque exigence est une mesure d'efficacité, d'automatisation, d'agilité ou de performance. Ensuite, lorsque nous travaillons dans Phase G de TOGAF exécution gouvernance de l'architecture avec un projet de changement nous utilisons ces scores pour évaluer les conceptions et les mises en œuvre.
Allez plus loin avec les meilleures pratiques en matière de processus et de méthodes d'architecture d'entreprise
Meilleures pratiques architecture d'entreprise depuis Conexiam Naviguer
Découvrez la puissance des modèles d'architecture d'entreprise
Découvrir la puissance des modèles d'architecture d'entreprise : un guide complet. Toute organisation souhaite s'améliorer. Rationaliser ses opérations. Améliorer son agilité. Aligner le changement sur ses stratégies. Réussir sa transformation numérique. L'architecture d'entreprise, une discipline […]
Comprendre l'architecture d'entreprise et Agile
Comprendre l'architecture d'entreprise et l'agilité. L'agilité et l'architecture d'entreprise visent toutes deux à réduire les risques. Le développement logiciel agile excelle à créer des solutions inédites et insaisissables. […]
Feuille de route de l'architecture d'entreprise en tant que conception
Feuille de route d'architecture d'entreprise (FDA) comme outil de conception. Une FDA est un outil de planification qui aide les décideurs d'une organisation. Une FDA dynamique est conçue pour les aider à développer et à optimiser leur stratégie. Elle […]
Exploiter la puissance de la planification basée sur les capacités : un guide rapide
Exploiter le potentiel de la planification par les capacités : Guide rapide. Vous cherchez une méthode plus efficace pour planifier et exécuter votre stratégie d'entreprise ? Ne cherchez plus : la planification par les capacités est la solution. Identifier et exploiter les capacités de votre organisation […]
Libérez le potentiel de votre entreprise : comment créer une cartographie des capacités efficace
Libérer le potentiel de votre entreprise : Comment créer une cartographie des capacités efficace ? Vous avez du mal à identifier les compétences nécessaires pour propulser votre entreprise vers le niveau supérieur ? Trouvez-vous difficile d’aligner les ressources […]
Meilleures pratiques pour mettre en œuvre des outils de gestion de l'architecture d'entreprise
Bonnes pratiques pour la mise en œuvre d'outils de gestion de l'architecture d'entreprise. Ces outils sont conçus pour soutenir la planification, la conception, l'analyse et la mise en œuvre de l'architecture d'entreprise. Ils permettent aux architectes d'entreprise d'évaluer les besoins de changement […]
Tout ce que vous devez savoir sur l'utilisation des alternatives architecturales
Tout ce que vous devez savoir sur l'utilisation d'alternatives d'architecture. Les alternatives d'architecture sont indispensables au bon développement d'une architecture d'entreprise. Lorsque vous démarrez le développement d'une architecture, votre entreprise présente des faiblesses. Des points restent à améliorer. Vous devez […]
Utilisation de l'analyse de scénarios pour l'architecture d'entreprise
Utilisation de l'analyse de scénarios pour l'architecture d'entreprise. Un scénario est simplement un futur plausible. L'analyse de scénarios examine comment nous pouvons atteindre un futur plausible et comment différents scénarios influencent nos choix actuels. Les scénarios aident les dirigeants […]
Développer une stratégie d'architecture d'entreprise
Élaboration d'une stratégie d'architecture d'entreprise : Plan stratégique de changement. La stratégie d'architecture d'entreprise est une action concrète. Les actions que votre organisation mettra en œuvre et les changements que vous apporterez pour atteindre vos objectifs stratégiques. L'élaboration d'une stratégie est une question de choix. […]
Création d'un comité d'évaluation de l'architecture moderne
Mise en place d'un comité d'évaluation d'architecture moderne : la mise en place d'un comité d'évaluation d'architecture moderne nécessite la mise en place d'un processus de gouvernance dynamique et la création d'un organe décisionnel de haut niveau. L'objectif est d'instaurer une gouvernance architecturale efficace et sans bureaucratie. […]
Modèles, outils et techniques d'architecture d'application
La phase C de TOGAF ADM fournit l'architecture des systèmes d'information. Cette phase vise à développer l'architecture des applications et 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 applicative centraux.
- Modèle de développement d'application qui décrit la méthode acceptable pour développer un système
- Modèle de système qui capture les grands systèmes autour desquels votre portefeuille d'applications est conçu
- Modèle fonctionnel qui décrit tout ce que vous souhaitez que votre portefeuille de logiciels exécute
- Modèle de produit qui identifie les fonctionnalités utilisées dans les produits et services de votre organisation, ainsi que ceux qui les administrent
- Le modèle d'intégration décrit la manière dont les informations circulent dans votre portefeuille d'applications
- Le modèle de service décompose votre portefeuille d'applications en boîtes noires et vous permet de garantir que chaque service dispose de l'agilité, de l'automatisation et des autres attributs requis
- Le modèle physique identifie les applications réelles, commerciales, SaaS ou personnalisées, dans votre portefeuille d'applications
L'architecture de l'application aidera à répondre aux questions suivantes :
- Comment le portefeuille d’applications permet de capturer de la valeur – Modèle de développement d'applications
- Où le coût est injecté dans le portefeuille informatique - Modèle fonctionnel
- Là où la rigidité est injectée dans le portefeuille informatique - Modèle d'intégration
- Comment fonctionne l'entreprise – Modèle de système
- Systèmes nécessaires pour fournir le produit ou le service – Modèle de produit
- Les choses qu'une organisation doit être capable de faire - Modèle fonctionnel
- Le flux d'informations nécessaires à la réalisation des activités d'une entreprise - Modèle d'intégration
- L'ensemble des activités qu'une entreprise exécute, généralement regroupées pour montrer comment elles sont liées les unes aux autres. Modèle de service
- Quel est le portefeuille de logiciels ? Modèle physique
Gardez toujours à l'esprit que vous cherchez à améliorer l'organisation. L'amélioration exige du changement et crée de la valeur. La valeur et le coût du changement sont mesurables. L'incertitude diminue toujours la valeur potentielle. L'incertitude augmente toujours les coûts. Nous traitons l'incertitude comme un impact géométrique. Une légère incertitude diminue considérablement la valeur potentielle.
Lors de votre lecture, gardez à l'esprit que les mêmes termes peuvent être utilisés de nombreuses fois. Recherchez l'objectif du modèle et ne vous laissez pas piéger par une appellation différente de celle que vous lui donneriez. Par exemple, ce que vous appelez un modèle fonctionnel sera appelé un service par quelqu'un d'autre. conseil en architecture d'entreprise, nous nous concentrons toujours sur ce que nous essayons de comprendre, et non sur le nom du modèle.
Différents modèles expliqueront différents aspects de l'entreprise. Ensemble, ces modèles et les modifications nécessaires forment l'architecture applicative.
Modèles d'architecture d'application
Nous utilisons modèles d'architecture d'augmenter considérablement la productivité et la qualité de notre développement architectural. Modèle de modèle d'architecture nous pousse à comprendre la problème prévisible, approche par modèle, et le Morceaux durs. Le succès avec le modèle nécessite de s'attaquer aux Morceaux durs (travaux requis, contraintes et limitations).
Exemples de modèles d'architecture d'application
Les modèles d'architecture d'application d'exemple couvrent le problème de la structure des applications, de la migration et de la conception des applications.
- Structure de l'application
- 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)
- Modèle MVC (Modèle-Vue-Contrôleur)
- Migration d'applications
- Motif étrangleur
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
- Motif étrangleur
- Conception d'applications (Gang of Four Application Patterns)
En tant qu'architectes d'entreprise, nous utilisons des modèles de conception comme contraintes sur la liberté des équipes de développement d'applications. (Voir Architecture d'entreprise et Agile - Contraindre les sprints)- Modèle Singleton- garantit qu'une classe n'a qu'une seule instance et fournit un point d'accès global à cette instance
Modèles d'architecture d'application
Développer une architecture d'application nécessitera de développer plusieurs modèles d'architecture d'entreprise. Chacun explique différemment le portefeuille logiciel de l'entreprise. L'architecture applicative TOGAF Phase C vise à développer l'architecture cible à travers ces modèles. L'architecte de l'application cible collabore avec les autres domaines pour optimiser les améliorations de votre entreprise.
Ensemble, ces modèles décrivent l'architecture applicative. Dans l'architecture d'entreprise complète, ils seront liés à d'autres modèles décrivant les autres domaines de l'architecture d'entreprise.
Modèle de développement d'applications
Le modèle de développement d'applications décrit le développement du logiciel. Il nécessite un modèle fonctionnel ou physique. Le modèle fonctionnel est bien plus performant, car il constitue un logiciel d'identification logique.
Il existe quatre types de développement d'applications : SaaS, suites d'entreprise, packages commerciaux spécialisés et développement personnalisé. Chaque type possède des caractéristiques et des implications uniques.
- Les caractéristiques du SaaS incluent des logiciels packagés avec des interfaces bien définies. Un tiers contrôle le cycle de vie. La personnalisation n'est pas possible.
Idéal pour les activités administratives et contribuant indirectement à la création de valeur. Les restrictions logicielles strictes imposent des restrictions à l'activité commerciale et favorisent l'adoption de pratiques sectorielles standard.
- Les suites d'entreprise se caractérisent par la présence de multiples modèles fonctionnels superposés, avec un modèle de données défini. Les interfaces et fonctionnalités sont configurables ou personnalisables. Ces personnalisations engendrent inévitablement des coûts supplémentaires tout au long du cycle de vie. Ce cycle de vie est influencé par un tiers.
- Les progiciels commerciaux spécialisés se caractérisent par une focalisation et une optimisation fonctionnelle spécifiques à l'activité spécialisée. Ils sont généralement conçus autour d'une approche unique de l'activité métier. Ils disposent généralement d'un modèle de données unique et bien défini. Les interfaces et fonctionnalités sont configurables. Une personnalisation est possible. Celle-ci engendre inévitablement des coûts importants tout au long du cycle de vie, lequel est fortement influencé par un tiers.
- Les caractéristiques du développement personnalisé incluent une harmonisation directe avec les périmètres et activités existants de votre organisation. Invariablement conçu pour soutenir le modèle de communication existant de votre organisation. L'optimisation fonctionnelle et la focalisation sur l'activité spécialisée sont essentielles. Attendez-vous à un modèle de données mal défini. Les interfaces et les fonctionnalités doivent être personnalisées. La gestion du cycle de vie est généralement négligée et engendre des coûts permanents élevés.
Idéal pour les activités commerciales de la chaîne de valeur primaire. Sa flexibilité permet d'optimiser la création de valeur. Une utilisation efficace nécessite une compréhension de la création de valeur actuelle et future.
Modèle de développement d'applications
Le modèle de développement d'applications décrit le développement du logiciel. Il nécessite un modèle fonctionnel ou physique. Le modèle fonctionnel est bien plus performant, car il constitue un logiciel d'identification logique.
Il existe quatre types de développement d'applications : SaaS, suites d'entreprise, packages commerciaux spécialisés et développement personnalisé. Chaque type possède des caractéristiques et des implications uniques.
- Les caractéristiques du SaaS incluent des logiciels packagés avec des interfaces bien définies. Un tiers contrôle le cycle de vie. La personnalisation n'est pas possible.
Idéal pour les activités administratives et contribuant indirectement à la création de valeur. Les restrictions logicielles strictes imposent des restrictions à l'activité commerciale et favorisent l'adoption de pratiques sectorielles standard.
- Les suites d'entreprise se caractérisent par la présence de multiples modèles fonctionnels superposés, avec un modèle de données défini. Les interfaces et fonctionnalités sont configurables ou personnalisables. Ces personnalisations engendrent inévitablement des coûts supplémentaires tout au long du cycle de vie. Ce cycle de vie est influencé par un tiers.
- Les progiciels commerciaux spécialisés se caractérisent par une focalisation et une optimisation fonctionnelle spécifiques à l'activité spécialisée. Ils sont généralement conçus autour d'une approche unique de l'activité métier. Ils disposent généralement d'un modèle de données unique et bien défini. Les interfaces et fonctionnalités sont configurables. Une personnalisation est possible. Celle-ci engendre inévitablement des coûts importants tout au long du cycle de vie, lequel est fortement influencé par un tiers.
- Les caractéristiques du développement personnalisé incluent une harmonisation directe avec les périmètres et activités existants de votre organisation. Invariablement conçu pour soutenir le modèle de communication existant de votre organisation. L'optimisation fonctionnelle et la focalisation sur l'activité spécialisée sont essentielles. Attendez-vous à un modèle de données mal défini. Les interfaces et les fonctionnalités doivent être personnalisées. La gestion du cycle de vie est généralement négligée et engendre des coûts permanents élevés.
Idéal pour les activités commerciales de la chaîne de valeur primaire. Sa flexibilité permet d'optimiser la création de valeur. Une utilisation efficace nécessite une compréhension de la création de valeur actuelle et future.
Modèle de système
Le modèle système est une abstraction logicielle autour d'une activité. Pensez au ‘ système de chaîne d'approvisionnement ’ et à tout ce qui y est impliqué. La conception de votre modèle système s'adaptera au fonctionnement de votre entreprise.
À l'instar du modèle de capacités de l'architecte métier, un modèle système permet d'orienter la réflexion vers un système. Vous pouvez ainsi envisager d'améliorer un système complet, puis concentrer les changements requis sur tous les éléments qui le composent et interagissent avec lui.
Modèle de produit
Un modèle de produit est une version spécialisée d'un modèle fonctionnel qui met en évidence les fonctions requises pour vos produits ou services. Un bon modèle de produit classera les performances de manière comparable.
Un bon modèle de produit constituera la base d'un architecture de référence Pour vos produits, vous devez spécifier les fonctions essentielles à la valeur, à l'utilisation et à l'administration du produit. Un modèle de produit éclairera les choix du modèle de développement d'applications. Vous avez besoin de développement personnalisé, de duplication et d'une capacité de modification nettement supérieure lorsque les fonctions sont associées à vos produits et services.
Modèle fonctionnel
Le modèle fonctionnel décompose votre portefeuille logiciel en fonctionnalités. Il identifie toutes les fonctions que votre logiciel doit remplir. Un bon modèle fonctionnel offre une couverture étendue.
À l'instar du modèle de processus de l'architecte métier, un modèle fonctionnel constitue souvent une architecture de référence. Il est performant pour la duplication et l'intégration. Il constitue souvent la base d'un modèle de développement d'applications, où différents blocs fonctionnels sont associés à un type de développement d'application cible.
Essentiel dans la planification du portefeuille d'applications. La duplication et l'intégration complexifient et coûtent cher au portefeuille informatique.
BIAN, FEAF, ODF de TMForum et IndEA fournissent tous des modèles fonctionnels.
Modèle d'intégration
Un modèle d'intégration identifie les limites de votre logiciel et la méthode utilisée pour les franchir. N'hésitez pas à préciser que la limite ne peut être franchie ou doit l'être manuellement. Une intégration applicative souvent faible n'engendre qu'une certaine rigidité. Développer un modèle d'intégration efficace nécessite des itérations avec le travail d'un architecte métier. Organigramme et Modèle d'information. Le modèle d’intégration, la carte organisationnelle et le modèle d’information s’informent et se contraignent mutuellement.
Le modèle d’intégration est essentiel pour permettre l’agilité de l’entreprise, gérer le portefeuille d’applications et réduire les coûts informatiques.
Modèle de service
Un modèle de service est une version spécialisée d'un modèle fonctionnel qui condense les fonctionnalités dans une boîte noire aux interfaces connues. Un bon modèle de service est indispensable pour développer le modèle de développement d'applications et valider la cible dans un modèle système. Les interfaces de votre modèle de service doivent toutes être clairement identifiées dans votre modèle d'intégration.
Un bon modèle de service favorisera l'agilité de l'entreprise, non pas au niveau du développement des services applicatifs, mais en libérant les changements d'un secteur de l'entreprise d'un autre.
Modèle physique
Un modèle physique constitue le véritable portefeuille logiciel. Nous le décrirons selon les termes utilisés par les éditeurs de logiciels commerciaux et votre programme de développement d'applications. Vous devrez l'associer aux autres modèles d'architecture d'application pour intégrer la cible au monde réel.
Le modèle physique est utilisé comme contrainte sur les modèles d'architecture d'application 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 d'application
Nous utilisons un large ensemble de techniques pour développer et communiquer notre architecture d’application.
- 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 fonctionnel et un modèle d'intégration doivent être développés conformément aux pratiques UML.
- Les vues 4+1 sont très utiles pour 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.
- Les lignes d'information du DODAF extraient tous les flux d'information nécessaires. Peu importe que le nœud soit une personne, une organisation ou un système. L'information circule en entrée et en sortie. Le moyen le plus rapide d'éliminer l'automatisation est d'intégrer des étapes manuelles au cœur d'un flux d'information.
Modèles d'architecture d'application alignés sur le cas d'utilisation de l'architecture d'entreprise
Le niveau de questionnement auquel répond votre architecture applicative influencera l'utilisation de différents modèles d'architecture applicative. Par exemple, l'architecture de support du portefeuille ne développera souvent pas de modèle de chaîne de valeur. Au contraire, une chaîne de valeur sera généralement une architecture supérieure et restreindre 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 développement d'applications | Livrable clé | Livrable clé | Architecture supérieure | Architecture supérieure |
| Modèle de système | Livrable régulier | Livrable clé | Architecture supérieure | Architecture supérieure |
| Modèle fonctionnel | Livrable régulier | Livrable clé | Livrable clé & Architecture supérieure | Livrable clé & Architecture supérieure |
| Modèle de produit | Livrable occasionnel
Un niveau de détail approprié diminue souvent la valeur |
Livrable régulier
Un niveau de détail approprié diminue souvent la valeur |
Livrable clé | Livrable clé |
| Modèle d'intégration | Livrable occasionnel
Un niveau de détail approprié diminue souvent la valeur |
Livrable régulier
Un niveau de détail approprié diminue souvent la valeur |
Livrable clé | Livrable clé & Architecture supérieure |
| Modèle de service | Livrable occasionnel
Un niveau de détail approprié diminue souvent la valeur |
Livrable régulier | Livrable clé & Architecture supérieure | Livrable clé & Architecture supérieure |
Influence des modèles d'architecture d'entreprise sur les modèles d'architecture d'application
| 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 développement d'applications | 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 | 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 produit | Entrée majeure | Entrée majeure | Entrée majeure | Entrée limitée | Entrée limitée | Entrée limitée | Entrée limitée | |
| Modèle d'intégration | Entrée très limitée | Contribution majeure à la conception du noyau
Nécessite un système ou un modèle fonctionnel |
Contribution majeure à la conception du noyau
Nécessite un système ou un modèle fonctionnel |
Meilleure entrée
Un lien direct est très difficile à identifier. Cela vaut la peine de faire le travail. |
Contribution majeure à la conception du noyau
Nécessite un système ou un modèle fonctionnel |
Entrée limitée
À utiliser uniquement si d'autres modèles ne sont pas disponibles |
Contribution majeure à la conception du noyau
Nécessite un système ou un modèle fonctionnel |
Contribution majeure à la conception du noyau
Nécessite un système ou un modèle fonctionnel |
| Modèle de service | Entrée limitée
Les liens sont importants, mais un lien direct est très difficile à voir |
Entrée limitée
Les liens sont importants, mais un lien direct est très difficile à voir |
Entrée limitée
Les liens sont importants, mais un lien direct est très difficile à voir |
Meilleure entrée
Un lien direct est très difficile à identifier. Cela vaut la peine de faire le travail. |
Utilisé comme test d'exhaustivité | Entrée majeure
Un lien direct est très difficile à identifier. Cela vaut la peine de faire le travail. |
Entrée majeure |
Modèles d'architecture d'application pour les cas d'utilisation d'architecture d'entreprise
Tous cas d'utilisation d'architecture d'entreprise portent sur le changement. Ils examinent tous les types de changement et la manière dont un architecte d'entreprise aide les décideurs à tracer une voie à suivre.
Je considère les cas d’utilisation de l’architecture d’entreprise comme le type de changement, l’objectif de l’équipe d’architecture d’entreprise ou les questions fréquemment posées.
Dans chaque cas d'utilisation d'architecture d'entreprise, nous remplissons la même fonction : nous aidons les parties prenantes à prendre de meilleures décisions et à mener des initiatives de changement réussies. La question est de savoir quel changement apporter.
| 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 développement d'applications | Principales contraintes | Lignes directrices clés | Contraintes critiques | Contraintes critiques | Lacunes et contraintes critiques | Lacunes et contraintes critiques | Lacunes et contraintes critiques | Lacunes et contraintes critiques | ||
| Modèle de système | Très utile
Lacunes et contraintes critiques |
Lacunes et contraintes critiques | Lacunes et contraintes critiques | Lacunes et contraintes critiques | Lacunes et contraintes critiques | |||||
| Modèle de produit | Lacunes et contraintes critiques | Lacunes et contraintes critiques | Lacunes et contraintes critiques | Lacunes et contraintes critiques | Lacunes et contraintes critiques | |||||
| Modèle d'intégration | Informer les contraintes | Lacunes et 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 | Lacunes et contraintes critiques | |
| Modèle de service | Très utile pour les lacunes et les contraintes | Très utile pour les lacunes et les contraintes | Très utile pour les lacunes et les contraintes | Très utile pour les lacunes et les contraintes | Très utile pour les lacunes et les contraintes | Très utile pour les lacunes et les contraintes | Très utile pour les lacunes et les contraintes |
Application des principes de l'architecture d'entreprise à l'architecture des applications
Nous avons identifié 7 principes d'architecture que tout architecte d'entreprise devrait connaître. Le tableau suivant identifie les implications de ces principes d'architecture pour l'architecture de l'application. Lors de l'exécution gouvernance de l'architecture d'entreprise, Vous devez tester votre architecture applicative pour vous assurer qu'elle est conforme à une architecture supérieure. Est-elle conforme aux principes de l'architecture d'entreprise ?
| Implications de l'architecture d'application | |
| Ne jouez pas avec le succès | Si le programme ne vise pas la différenciation ou la transformation, il faut chercher à éliminer tout changement. Il faut éviter tout changement de processus ou de système qui ne soit pas explicitement justifié en termes de coûts et de résultats. |
| Se concentrer sur l'excellence | Alignez-vous avec le Modèle opérationnel le Modèle de capacité.
Tirez parti du modèle de développement d’applications pour concentrer les dépenses sur la différenciation. Exploitez le modèle de produit pour vous concentrer sur la livraison de produits et de services. |
| Pourquoi pas un ? | Exploitez le modèle de développement d’applications et le modèle de produit pour identifier les domaines dans lesquels la duplication est interdite. |
| Les données sont un atout | Assurez-vous que le contrôle du modèle de données n’est pas abandonné d’une manière qui diminue la valeur des données. |
| Les systèmes fonctionnent là où nous travaillons | Le lieu de travail et le style de travail déterminent l'interface et le modèle d'application. |
| Expérience utilisateur sans douleur | Les programmes d’efficacité se concentrent sur les processus commerciaux existants.
Les programmes de différenciation et de transformation nécessitent des modifications de l'interface utilisateur et de l'engagement à mesure que l'expérience avec le nouveau processus se développe. |
| En libre service | Les activités administratives et de déploiement des applications sont coûteuses lorsqu'elles ne sont pas en libre-service
Une UX faible a un coût élevé. |
Comment TOGAF Phase C s'aligne-t-il sur le développement Agile ?
L'architecture applicative fournira de multiples contraintes et orientations pour le développement agile. Les orientations fondamentales proviennent du modèle de développement applicatif. Il identifie les domaines où le développement agile est déconseillé.
Architecture d'entreprise et développement agile se croiseront sur quatre zones. Le l'architecture d'entreprise va :
- définir l'approche agile
- guider le backlog dans le sprint
- restreindre les choix à l'intérieur des sprints
- résoudre la dépendance du produit vectoriel
Nous privilégions systématiquement le développement agile pour des activités innovantes et différenciantes et suivons rigoureusement les meilleures pratiques établies ailleurs. Ces meilleures pratiques proviennent de logiciels commerciaux reconnus. Veillez à aligner l'architecture de vos applications sur celle de votre entreprise et concentrez-vous sur la manière dont vous acquérez vos systèmes.
Comment TOGAF Phase C permet-il l'agilité d'entreprise ?
L’agilité de l’entreprise n’a rien à voir avec la façon dont vous écrivez des logiciels. L'agilité d'entreprise concerne la capacité de votre entreprise à réagir aux menaces et opportunités inattendues. Si vous devez écrire du code, votre capacité à répondre à une menace ou à une opportunité est en jeu.
Un architecte d’application se concentrera sur le cinquième aspect de l’ modèle d'agilité d'entreprise - Flexibilité. Nous utilisons le même attribut d'agilité et les mêmes scores dans le Guide d'évaluation des capacités identifier les systèmes d'information devant évoluer rapidement. Nous les structurons ensuite pour les rendre compatibles.
Modèle d'agilité d'entreprise
- 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 ?
Quel est l’objectif de TOGAF ADM Phase C ?
Dans Phase A, vous avez identifié un architecture cible simplifiée - la vision architecturale. La vision architecturale incluait tous les domaines. L'activité de la phase C développe davantage les domaines d'architecture des applications et des données. La réussite requiert :
- Vous abordez le problème de la façon dont l’entreprise actuelle ne peut pas répondre aux préférences des parties prenantes
- Vous apprenez ce qui doit changer pour permettre à l'entreprise 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 C est l'architecture de l'application candidate. Les architectes d'application collaborent avec d'autres architectes de domaine pour comprendre les contraintes imposées à l'architecture de l'application et celles qui pèsent sur les autres domaines.
N'oubliez pas que le TOGAF ADM explore les changements potentiels. Jusqu'à ce que vous développiez le Plan de mise en œuvre de la phase F, recherchez la solution la plus économique. Les mauvaises idées ne signifient pas que vous ne résolvez pas le problème. Vous devriez abandonner les idées faibles. alternatives architecturales. Arrêter les mauvaises idées plus tôt permet d'économiser de l'argent et de favoriser des changements positifs. Dès qu'une idée tourne mal, arrêtez-la net. Abandonnez-la. Célébrez votre victoire ! Célébrez le fait que vous permettez un changement positif !
Modèles d'architecture d'application
Nous utilisons modèles d'architecture pour accroître considérablement la productivité et la qualité de notre développement architectural. Nous utilisons une approche simplifiée Modèle de modèle d'architecture qui nous pousse à comprendre le problème prévisible, approche par modèle, et le Morceaux durs. L’applicabilité du modèle est généralement déterminée par le travail requis, les contraintes et les limitations.
Exemples de modèles d'architecture d'application
Les modèles d'architecture d'application d'exemple couvrent le problème de la structure des applications, de la migration et de la conception des applications.
- Structure de l'application
- 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)
- Modèle MVC (Modèle-Vue-Contrôleur)
- Migration d'applications
- Motif étrangleur
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
- Motif étrangleur
- Conception d'applications (Gang of Four Application Patterns)
En tant qu'architectes d'entreprise, nous utilisons des modèles de conception comme contraintes sur la liberté des équipes de développement d'applications. (Voir Architecture d'entreprise et Agile - Contraindre les sprints)- Modèle Singleton- garantit qu'une classe n'a qu'une seule instance et fournit un point d'accès global à cette instance
Réflexions finales sur TOGAF ADM Phase C
Architectes d'application travaillant avec un Équipe d'architecture d'entreprise Les équipes de développement ont des responsabilités plus importantes que la conception d'une application. Elles doivent élaborer les lignes directrices et les garde-fous nécessaires à l'architecture, la conception, la mise en œuvre et le développement du portefeuille d'applications de l'entreprise. En résumé, L'architecte d'applications d'entreprise est distinct d'un architecte de solutions ou d'un architecte d'applications qui ne travaille pas avec une équipe EA.
Les architectes d'application travaillant dans TOGAF ADM Phase C ont un rôle complexe.
- travailler avec les parties prenantes et les PME pour sélectionner les changements dans le portefeuille d'applications qui permettent la meilleure organisation future
- travailler avec leurs pairs architectes de domaine pour explorer comment les améliorations requises dans le domaine métier sont activées ou empêchées dans le domaine applicatif
- Collaborer avec les parties prenantes pour éliminer les modifications du portefeuille d'applications qui ne sont pas suffisamment performantes ou qui coûtent trop cher. Éliminer également les modifications dans d'autres domaines qui engendrent des coûts inacceptables et les réaffecter au portefeuille d'applications.
Dans la phase C de TOGAF ADM, l'un des quatre éléments fondamentaux domaines d'architecture d'entreprise est développé. TOGAF est très clair : cette architecture est développée en parallèle avec les autres domaines. Les modifications apportées à un domaine activeront, forceront ou bloqueront les modifications apportées à un autre domaine.
Les équipes d'architecture d'entreprise performantes n'utilisent pas leurs architectes d'applications comme concepteurs d'une application unique. Ce rôle est nécessaire, mais sans une architecture applicative couvrant des pans entiers de l'entreprise, l'optimisation de celle-ci est impossible.
TOGAF ADM Phase C développe l'architecture applicative. Cette architecture est le fondement de toute entreprise numérique moderne. Utilisez TOGAF Phase C pour concentrer les ressources limitées en matière de changement sur l’obtention de la plus grande valeur pour l’entreprise.
