Phase C de TOGAF ADM : développement de l'architecture de l'application
En bref
- 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 applicative ?
- 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 création de connaissances. Connaissances utilisées pour développer une architecture d'entreprise qui guide le changement efficace. Ensuite, les connaissances permettent de 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électionnez 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'architectureCette 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 de données et le domaine d'architecture d'application sont individuels.
Comme la phase B, la phase C s'appuie sur la vision de l'architecture. Il y a toutefois une différence : la phase C a pour autre obligation de permettre l'architecture métier. Il ne s'agit pas de traiter l'architecture métier comme des exigences, mais plutôt de confirmer que les objectifs récapitulatifs en développement sont cohérents.
Les changements dans un domaine entraînent des contraintes et des exigences dans d'autres domaines. L'objectif est de trouver le meilleur ensemble de changements dans 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 de l'application 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 d'œuvres centrales 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 dans l'architecture des applications
- produits de travail des candidats qui changent l'entreprise
La phase C se concentre sur des éléments tels que la conception de l'application, le flux de données, l'intégration, l'approche de développement, la conception ou l'achat et la planification des modifications. Une évaluation et une compréhension appropriées 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. Le décisions architecturales réalisés lors de la phase C pour l'architecture des applications interagissent avec les décisions prises dans chaque domaine de l'architecture d'entreprise.
Phase C en action
L'architecture d'application aidera à répondre aux questions suivantes :
- Comment le portefeuille d'applications permet la capture de 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 requis pour fournir le produit ou le service – modèle du produit
- Les choses qu'une organisation doit être capable de faire - Modèle fonctionnel
- Le flux d'informations nécessaires à l'exécution des activités d'une entreprise - Modèle d'intégration
- Les activités complètes 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
- Qu'est-ce que le portefeuille de logiciels - Modèle physique
Gardez toujours à l'esprit que vous cherchez à améliorer l'organisation. L'amélioration nécessite des changements et apporte de la valeur. La valeur et le coût du changement peuvent être mesurés. 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 petite incertitude diminue beaucoup la valeur potentielle.
Lors de la lecture, gardez à l'esprit qu'il existe de nombreuses utilisations des mêmes termes. Recherchez l'objectif du modèle et ne vous laissez pas piéger lorsque l'étiquette diffère de ce que vous appelleriez. Par exemple, ce que vous appelez un modèle fonctionnel, quelqu'un d'autre l'appellera un service. Dans notre conseil en architecture d'entreprise, nous nous concentrons toujours sur ce que nous essayons de comprendre, pas sur le nom du modèle.
Différents modèles expliqueront différents aspects de l'entreprise. Ensemble, les modèles et les modifications nécessaires forment l'architecture de l'application.
Qu'est-ce que l'architecture applicative ?
Une architecture d'application est une description de votre portefeuille logiciel complet qui vous indique quand acheter, quand utiliser SaaS et quand créer. Il vous indique où placer les limites entre les systèmes. Il vous indique comment vous aborderez le cycle de vie de votre logiciel.
Nous pouvons garantir que votre architecture d'application actuelle n'est pas alignée sur votre architecture d'entreprise. Une architecture d'application nécessite une architecture d'entreprise. Le développement de l'architecture métier nécessite que les architectes d'applications les rejoignent en s'engageant avec les parties prenantes.
Avec la partie prenante et l'architecte métier, l'architecte d'application explore comment les choix logiciels permettent et limitent les objectifs de l'organisation. Nous examinons les améliorations potentielles pour comprendre l'impact immédiat et à moyen terme. Ensemble, les modifications potentielles qui fournissent trop peu, nécessitent trop de travail ou comportent trop d'incertitudes sont supprimées 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 centraux sur TOGAF Phase C - Application Architecture. Tout d'abord, jusqu'à ce que vous ayez un Modèle de développement d'applications, vous ne pouvez pas continuer. Tant que vous ne savez pas comment vos choix d'applications activent et limitent votre architecture d'entreprise, les détails de vos applications sont inutiles. Deuxièmement, s'ils pensent qu'ils doivent se lancer dans la fonctionnalité et l'intégration des applications, ils développeront toujours une architecture d'application de mauvaise qualité.
Dans un style moderne entreprise transformée numériquement, tous les domaines de l'architecture interagissent. Les choix dans un domaine activent, fournissent ou bloquent les résultats dans un autre domaine. La plupart des objectifs commerciaux dépendent de bonne architecture informatiqueIroniquement, nous ne pouvons développer la bonne architecture d’application que si nous disposons d’une architecture métier 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 protéger l'intégralité de la valeur. Selon les compétences des architectes de domaine, l'architecte d'entreprise doit compléter. Par exemple, un architecte d'application peut ne pas voir l'impact des changements dans l'architecture métier. Ou ils peuvent ne pas articuler une exigence en termes sur lesquels l'architecte de sécurité peut agir.
Le rôle le plus important de l'architecte d'entreprise est de franchir les frontières. Qu'il s'agisse de limites de domaine, de compétence ou d'autorité, l'architecte d'entreprise doit les franchir.
Quel est le rôle de l'architecte d'application dans la phase C ?
Dans la phase C de TOGAF, nous attendons de l'architecte d'application qu'il fournisse l'architecture du domaine. Cela nécessite de développer des modèles qui montrent la source de la déficience et comment la surmonter. Ils mèneront une analyse des compromis avec les parties prenantes pour déterminer l'architecture cible.
L'architecte d'application devra collaborer avec les autres architectes de domaine.
Clé de l'architecture d'entreprise. Connaître et comprendre les Modèle de fonctionnement 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 ?
Dans la phase C de TOGAF, nous attendons de l'architecte d'application qu'il fournisse l'architecture du domaine. Cela nécessite de développer des modèles qui montrent la source de la déficience et comment la surmonter. Ils mèneront une analyse des compromis avec les parties prenantes pour déterminer l'architecture cible.
L'architecte d'application devra collaborer avec les autres architectes de domaine.
Clé de l'architecture d'entreprise. Connaître et comprendre les Modèle de fonctionnement et les attributs Compétence et Automatisation du Modèle de capacité.
Gardez à l'esprit que les lacunes 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 lacunes 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 fonctionnent pas. L'architecture d'entreprise des meilleures pratiques n'est pas une activité en cascade. La seule approche réussie consiste à développer l'architecture métier, l'architecture des applications, l'architecture des données, 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 fermer le développement de l'architecture, et non le démarrer.
Ne tombez pas dans l'illusion que « l'entreprise » est en quelque sorte séparée de ses applications, de ses données et de son infrastructure. Ce n'était pas vrai dans le passé, et dans une entreprise numérique moderne, c'est risible. Cette illusion est le moyen le plus rapide d'éliminer agilité d'entreprise ou la possibilité de transformation numérique Succès.
Les architectes d'applications ont un rôle essentiel dans une équipe d'architecture d'entreprise. Rien ne se passe dans une entreprise numérique moderne sans logiciel. De mauvais choix d'application paralyseront 'les affaires.' Les architectes d'applications sont des spécialistes d'un domaine d'architecture. Ils ne peuvent pas concevoir leur domaine sans un engagement régulier avec architectes d'entreprise, les données, la technologie et architectes de sécurité.
Téléchargez le guide de l'IA pour les chefs d'entreprise
Téléchargez le Guide du chef d’entreprise sur l’intelligence artificielle Les organisations qui appliquent avec succès une technologie innovante bénéficient d’un avantage concurrentiel. La technologie innovante ne s’accompagne pas de modèles de réussite établis ni de meilleures pratiques. La technologie innovante est nouvelle et […]
Télécharger l'introduction à la norme TOGAF, 10e édition
Télécharger Introduction à la norme TOGAF®, 10e édition La norme TOGAF, 10e édition facilite l'adoption des meilleures pratiques d'architecture d'entreprise. Il sépare les concepts universels des meilleures pratiques éprouvées. Le soulignement standard où […]
Télécharger le guide de planification basée sur les capacités
Téléchargez le guide de planification basée sur les capacités. Toujours déterminé à réaliser de la valeur. Une demi-amélioration représente un déchet 100% ! 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 de l'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 basée sur les capacités est l'une des techniques d'amélioration de l'architecture d'entreprise les plus puissantes. La meilleure pratique de la planification basée sur les capacités utilise les capacités comme outil de gestion […]
Télécharger des exemples de principes d'architecture d'entreprise
Télécharger des exemples de principes d'architecture Téléchargez un exemple de principes d'architecture d'entreprise. Les principes de l'Architecture d'Entreprise identifient comment aborder un problème ou une décision. L'approche vous pousse toujours vers vos priorités durables. Télécharger des exemples 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 pour diriger et contrôler le développement de l'architecture, et changer pour obtenir les résultats attendus. Téléchargez le guide de gouvernance de l'architecture d'entreprise […]
Télécharger l'intégration TOGAF et SABSA
Télécharger l'intégration TOGAF et SABSA Réunissez SABSA, le meilleur cadre d'architecture de sécurité au monde, et TOGAF, le cadre d'architecture d'entreprise standard de l'industrie. Télécharger l'intégration TOGAF et SABSA L'intégration TOGAF et SABSA comprend que SABSA utilise un […]
Télécharger l'architecture de référence des capacités d'architecture d'entreprise
Télécharger Architecture de référence des capacités d'architecture d'entreprise L'architecture de référence des capacités d'architecture d'entreprise accélérera la création et l'amélioration de votre équipe EA. Concevez votre équipe d'architecture d'entreprise pour réussir. Identifiez et améliorez l'architecture de votre entreprise […]
Télécharger le rapport sur l'architecture d'entreprise agile
Téléchargez le rapport sur l'architecture d'entreprise agile Le rapport sur l'architecture d'entreprise agile couvre notre expérience - l'architecture d'entreprise agile est réelle, pratique et précieuse. Nous le faisons tous les jours. Les rapports de terrain font le pont entre les concepts théoriques et […]
Télécharger l'étude de cas sur l'architecture d'entreprise agile
Télécharger l'étude de cas sur l'architecture d'entreprise agile Téléchargez l'étude de cas sur l'architecture d'entreprise agile pour voir un exemple de développement d'une capacité EA et d'une architecture utile en même temps. Nous couvrons les six cas d'utilisation […]
Connaissances essentielles de la phase C
Toutes les phases TOGAF ADM vous amènent à développer les connaissances dont vous avez besoin. Le résultat de la phase C est l'architecture d'application candidate incluse dans l'architecture des systèmes d'information candidats.
| Sortie et résultat | 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 un travail pour combler les lacunes comprises par les parties prenantes. | Comment le portefeuille de logiciels actuel ne répond-il pas aux préférences des parties prenantes ?
Que faut-il changer pour permettre au portefeuille logiciel de répondre aux préférences des parties prenantes ? (lacunes) Quel travail est nécessaire pour réaliser les changements qui sont cohérents avec la valeur ajoutée créée ? (Lot de travaux) Comment la priorité et la préférence des parties prenantes s'ajustent en réponse à la valeur, à l'effort et au risque de 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
Os nus de la phase C
Dans la phase C, nous pouvons simplifier le travail d'un architecte d'application pour déterminer comment une entreprise devrait être meilleure. Cela nécessite de comprendre dans quoi il essaie d'être bon, où il est en deçà du meilleur et ce qui doit changer pour permettre d'être le meilleur.
Les os nus de la phase C sont :
- Savoir comment le portefeuille d'applications permet de capturer de la valeur
Chaque organisation a une chaîne de valeur. Activité qui transforme un intrant en quelque chose de plus précieux pour ses clients. Les applications effectuent soit une création de valeur, soit elles assurent la tenue de registres. Traditionnellement, presque tous les logiciels fournissaient la tenue de registres.
Vous devez optimiser votre logiciel pour le rôle - création de valeur ou tenue de registres. Supposons la tenue de registres. Ne confondez pas le rôle important de la tenue de registres avec la création de valeur.
Connaître la source du coût et de la complexité
Chaque portefeuille d'applications crée des coûts et de la complexité. Nous considérons le logiciel comme une montre complexe qui s'est assemblée au fil du temps. Nous avons tout connecté à tout. Avec des produits numériques un service informatique omniprésent comprendre l'ITFM est une compétence fondamentale.
Vous devez optimiser votre portefeuille de base pour éliminer les coûts et la complexité soutenus. Vous devez activer agilité d'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 de logiciels : SaaS, suites d'entreprise, packages commerciaux spécialisés et développement personnalisé. Chacun a un modèle de coût et d'optimisation différent. Vous devez appliquer le bon modèle de logiciel aux bons endroits.
- Savoir quand le logiciel fait partie de 'le produit'
Nos organisations fournissent un produit ou un service. Logiciel qui est 'le produit' diffère grandement du logiciel qui prend en charge l'entreprise.
- Connaître le flux d'informations
Les gens sont infiniment flexibles. Nous pouvons décider de partager des informations. Nous pouvons voir une situation de manière proactive et réagir. Le logiciel fait exactement ce qu'on lui dit. Le logiciel ne fait que ce qu'on lui dit.
Le flux d'informations se produit autour du logiciel pour faire ce qu'il faut. Ce type de flux d'informations brise l'agilité de l'entreprise. Ils paralysent l'efficacité. Ces flux entraînent des coûts.
- Connaître les attentes du logiciel
Parfois, nous avons besoin d'un secrétaire occasionnel. Parfois, nous avons besoin d'un système autonome. La plupart du temps, nous avons besoin de quelque chose qui aide sans trop de frais généraux. Nous exploitons les concepts et les attributs dans modèles de capacité pour guider les choix concernant notre architecture applicative. Voir le Guide d'évaluation des capacités d'architecture d'entreprise.
- Savoir ce que l'organisation doit faire
Chaque entreprise a un ensemble de processus qu'elle doit exécuter : création de valeur primaire, support et administration. Chacun d'entre eux a besoin d'un logiciel. Chacun d'eux crée et produit de l'information. Vous devez savoir ce qu'ils sont, les informations qu'ils consomment et qui les fait.
- Que faut-il changer pour offrir le meilleur portefeuille d'applications ?
Nous développons une architecture applicative pour améliorer une organisation. La plupart des changements ne font pas de différence matérielle. La plupart des changements bricolent sur les bords. Concentrez votre temps sur les changements importants qui stimulent l'agilité, les coûts ou la création de valeur de l'entreprise.
Les trois éléments essentiels de l'achèvement de la phase C :
- Première, que faut-il changer ? Changement d'orientation, de conception organisationnelle, de perfectionnement, d'externalisation, d'internalisation, d'automatisation. Ce sont tous des changements. Nous les mettons en œuvre pour améliorer une organisation.
- Seconde, quand faut-il le changer ? Y a-t-il des dépendances ? Qu'en est-il des conditions préalables ? Changez-vous le décor pour un changement ultérieur ?
- La troisièmeComment saurez-vous si le changement a réussi ? Quel est votre test de gouvernance pour é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 ce qui doit changer et quand. L'architecte d'application est responsable de la description des tests de gouvernance pour permettre aux parties prenantes de diriger le projet de changement, les deuxième et troisième résultats.
Formation Architecture d'Entreprise et Formation TOGAF
Éducation en ligne efficace
Une formation en ligne efficace fonctionne. Les étudiants ont accès au meilleur instructeur disponible. Les étudiants contrôlent le rythme de leur apprentissage. Les instructeurs peuvent partager du matériel complémentaire riche sans détourner l’attention du sujet principal. La formation à distance efficace […]
Cours de formation en architecture d'entreprise
Formation en architecture d'entreprise Une architecture d'entreprise efficace repose sur l'architecture d'entreprise. Le cours donne 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 du […]
Cours de formation sur l'architecture d'entreprise TOGAF
Vous souhaitez une formation pour la Certification TOGAF ? Démontrez vos connaissances en architecture d'entreprise avec la certification TOGAF Cours de formation TOGAF® Enterprise Architecture Faites un pas majeur pour devenir un meilleur architecte d'entreprise avec la norme TOGAF, 10e […]
Formation personnalisée sur l'architecture d'entreprise
Formation personnalisée en architecture d'entreprise La formation personnalisée en architecture d'entreprise répond aux besoins de développement professionnel de votre équipe EA. Les bons architectes d'entreprise utilisent un large éventail de compétences, de méthodes, en plus de connaissances spécialisées dans le domaine pour développer l'entreprise […]
Démarrage rapide de l'architecte d'entreprise
Le Kickstart de l'architecte d'entreprise Nous devons maintenir nos compétences à jour. Plus que jamais. Utilisez le Kickstart de l'architecture d'entreprise pour améliorer votre capacité à fournir une architecture d'entreprise transformatrice. Ce Kickstart 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 une modélisation et une analyse formelles. Nous proposons une formation Avolution ABACUS dispensée par des architectes d'entreprise expérimentés. Les étudiants acquièrent des compétences et des connaissances pour créer des architectures d'entreprise et de domaine intégrées dans ce […]
Livrables de l'architecture d'application TOGAF ADM Phase C
Un résultat central de la phase C est une architecture d'application. Il s'agit d'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
Il existe quatre objectifs principaux pour développer une architecture d'entreprise. Différents livrables TOGAF Phase C ont une importance différente dans chaque objectif.
| Architecture pour soutenir la stratégie | Architecture pour prendre en charge le portefeuille | Architecture pour soutenir le projet | Architecture pour prendre en charge la livraison de solutions | |
| Produit de travail de la phase C : architecture d'application candidate | Livrable clé
L'utilisation principale est la compréhension des parties prenantes de la cible et du travail. L'utilisation secondaire est la création de spécifications d'exigences d'architecture pour les architectes |
Livrable clé
L'utilisation principale est la compréhension des parties prenantes de la cible et du travail. L'utilisation secondaire est la création de spécifications d'exigences d'architecture 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 fournisseurs 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 du candidat | 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 des parties prenantes du travail et de la dépendance. 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 modifications interactives |
Avant l'engagement des partenaires d'exécution (y compris les prestataires internes).
L'utilisation principale est l'identification du changement requis et les préférences sur la façon d'exécuter le changement, pour gérer la sélection et l'engagement des partenaires de livraison de solutions |
| Produit de travail de la phase C : spécification des exigences d'architecture | Utilisation limitée
Habituellement, les architectes peuvent déduire les contraintes d'une architecture supérieure. |
Utilisation limitée
Habituellement, les architectes peuvent déduire les contraintes d'une architecture supérieure. |
Livrable clé
Avant la fin du lancement du projet |
Livrable clé
Avant l'engagement et la contractualisation |
Tableau 3 Guide de la série TOGAF : Guide de l'architecte d'entreprise pour le développement de l'architecture
Architecture d'application des candidats
Il existe quatre objectifs principaux pour développer une architecture d'entreprise. Différents modèles ont une importance différente dans chaque objectif.
Composants de la feuille de route de l'architecture des applications candidates
Qu'est-ce qui doit changer ? Si vous modifiez le modèle de développement d'applications, la différence entre l'actuel et la cible est le candidat de la feuille de route. Il en va de même pour tout ce qui est nécessaire pour permettre ce changement.
Nous utilisons souvent un modèle de système pour résumer le changement. Le modèle de système permet juste assez d'abstraction à partir d'un logiciel réel pour avoir une conversation de planification et d'exécution. Nous utilisons généralement des partitions et des modules de travail 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 d'architecture dans Phase E de TOGAF - Feuille de route architecturale.
Spécification des exigences de l'architecture de l'application candidate
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 étant une mesure d'efficacité, d'automatisation, d'agilité ou d'exécution. Ensuite, lorsque nous travaillons dans TOGAF Phase G effectuer gouvernance de l'architecture avec un projet de changement nous utilisons ces scores pour évaluer les conceptions et les implémentations.
Allez plus loin avec les meilleures pratiques en matière de processus et de méthodes d'architecture d'entreprise
Meilleur entrainement l'architecture d'entreprise de Conexiam Naviguer
Faire des choix plus intelligents : pourquoi votre entreprise a besoin de décisions architecturales
Faire des choix plus intelligents : pourquoi votre entreprise a besoin de décisions architecturales Les entreprises sont constamment confrontées au défi de prendre des décisions cruciales. Chaque jour, les décisions, y compris les pratiques opérationnelles et les choix technologiques, ont un impact significatif sur un […]
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 parvenons à un futur plausible et comment différents scénarios impactent nos choix actuels. Les scénarios aident les dirigeants […]
Création d'un comité d'évaluation de l'architecture moderne
Créer un comité d’évaluation d’architecture moderne La création d’un comité d’évaluation d’architecture moderne nécessite la création d’un processus de gouvernance dynamique et la mise en place d’un organe décisionnel de haut niveau. L’objectif est d’établir une gouvernance d’architecture efficace sans bureaucratie. […]
Meilleures pratiques pour mettre en œuvre des outils de gestion d'architecture d'entreprise
Meilleures pratiques pour mettre en œuvre des outils de gestion d'architecture d'entreprise Les outils de gestion d'architecture d'entreprise sont conçus pour prendre en charge la planification, la conception, l'analyse et l'exécution de l'architecture d'entreprise. Ils permettent aux architectes d'entreprise d'examiner la nécessité d'un changement […]
Comment définir les principes de l'architecture d'entreprise
Comment définir les principes de l’architecture d’entreprise Pour définir les principes de l’architecture d’entreprise, il faut commencer par comprendre ce qu’est un principe et comment l’appliquer. Nous pouvons ensuite développer des principes d’architecture solides qui contribuent à améliorer notre organisation. […]
Libérer le potentiel de votre entreprise : comment créer une carte de capacité efficace
Libérer le potentiel de votre entreprise : comment créer une cartographie efficace des capacités Avez-vous du mal à identifier les capacités nécessaires pour faire passer votre entreprise au niveau supérieur ? Trouvez-vous difficile d'aligner les ressources [...]
Feuille de route de l'architecture d'entreprise en tant que conception
Feuille de route d'architecture d'entreprise en tant que conception Une feuille de route d'architecture est un outil de planification qui aide les décideurs d'une organisation. Une feuille de route d'architecture dynamique est conçue pour les aider à développer et à parcourir le meilleur chemin à suivre. Elle […]
Développer une vue d'architecture
Développer une architecture View Enterprise est une boussole essentielle. Il aide les organisations à gérer les complexités de la technologie, de la stratégie et des opérations. Le cœur de l’architecture d’entreprise est une approche systématique. L’objectif est de garantir […]
Gestion du travail d'architecture d'entreprise
Gestion du travail d’architecture d’entreprise La gestion du travail d’architecture d’entreprise est essentielle au succès quotidien d’une équipe d’architecture d’entreprise. Les architectes doivent fournir des conseils utiles avant que les parties prenantes ne prennent des décisions éclairées. Les architectes d’entreprise doivent traduire […]
Comprendre l'architecture d'entreprise et Agile
Comprendre l'architecture d'entreprise et l'agilité Les architectures agile et d'entreprise sont conçues pour réduire les risques. Le développement logiciel agile excelle dans la création de quelque chose que nous n'avons jamais eu auparavant et que nous ne savons pas comment construire. […]
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 existe pour développer l'architecture d'application et l'architecture de données qui composent les systèmes d'information. Dans TOGAF, la première étape consiste à déterminer les vues requises et les modèles requis.
Les préoccupations des parties prenantes identifieront les points de vue. Il existe sept modèles d'architecture d'application centrale.
- Modèle de développement d'applications qui décrit la méthode acceptable qu'un système sera développé
- 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 dont votre portefeuille de logiciels a besoin pour fonctionner
- 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 comment 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 vous assurer que chaque service possède l'agilité, l'automatisation et les autres attributs requis
- Le modèle physique identifie les applications réelles, commerciales, SaaS ou personnalisées, dans votre portefeuille d'applications
L'architecture d'application aidera à répondre aux questions suivantes :
- Comment le portefeuille d'applications permet la capture de 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 requis pour fournir le produit ou le service – modèle du produit
- Les choses qu'une organisation doit être capable de faire - Modèle fonctionnel
- Le flux d'informations nécessaires à l'exécution des activités d'une entreprise - Modèle d'intégration
- Les activités complètes 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
- Qu'est-ce que le portefeuille de logiciels - Modèle physique
Gardez toujours à l'esprit que vous cherchez à améliorer l'organisation. L'amélioration nécessite des changements et apporte de la valeur. La valeur et le coût du changement peuvent être mesurés. 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 petite incertitude diminue beaucoup la valeur potentielle.
Lors de la lecture, gardez à l'esprit qu'il existe de nombreuses utilisations des mêmes termes. Recherchez l'objectif du modèle et ne vous laissez pas piéger lorsque l'étiquette diffère de ce que vous appelleriez. Par exemple, ce que vous appelez un modèle fonctionnel, quelqu'un d'autre l'appellera un service. Dans notre conseil en architecture d'entreprise, nous nous concentrons toujours sur ce que nous essayons de comprendre, pas sur le nom du modèle.
Différents modèles expliqueront différents aspects de l'entreprise. Ensemble, les modèles et les modifications nécessaires forment l'architecture de l'application.
Modèles d'architecture d'application
Nous utilisons Modèles d'architecture pour 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 modèle, et le Morceaux durs. Le succès avec le modèle nécessite de s'attaquer aux Morceaux durs (travaux nécessaires, contraintes et limitations).
Exemples de modèles d'architecture d'application
Les exemples de modèles d'architecture d'application couvrent le problème de la structure des applications, de la migration et de la conception des applications.
- Structure des candidatures
- Modèle MVC (Modèle-Vue-Contrôleur)
Problème prévisible—organisation, maintenabilité et testabilité du code
Approche- sépare une application en trois composants interconnectés : modèle (données et logique métier), vue (interface utilisateur) et contrôleur (gère les entrées de l'utilisateur et met à jour le modèle et la vue en conséquence)
- Modèle MVC (Modèle-Vue-Contrôleur)
- Migration d'applications
- Modèle d'étrangleur
Problème prévisible— remplacement des systèmes existants
Approche— remplacer ou « étrangler » progressivement un système existant en construisant de nouveaux composants autour de celui-ci pour remplacer progressivement le système
- Modèle d'étrangleur
- Conception d'applications (groupe de quatre modèles d'application)
En tant qu'architectes d'entreprise, nous utilisons les modèles de conception comme contraintes à 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'applications
Développer une architecture d'application nécessitera de développer plusieurs modèles d'architecture d'entreprise. Chacun explique différemment le portefeuille de logiciels de l'entreprise. L'architecture d'application TOGAF Phase C consiste à développer l'architecture cible à travers ces modèles. S'assurer que l'architecte de l'application cible travaille avec les autres domaines pour permettre la meilleure amélioration pour votre entreprise.
Pris ensemble, les modèles décrivent l'architecture de l'application. Dans l'architecture d'entreprise complète, ces modèles seront liés à d'autres modèles qui décrivent 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 comment le logiciel sera développé. Le modèle nécessite un modèle fonctionnel ou physique. Le modèle fonctionnel est bien meilleur car il s'agit d'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 a des caractéristiques et des implications uniques.
- Les caractéristiques 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 disponible.
Idéal pour les activités commerciales qui sont administratives et qui soutiennent indirectement une activité génératrice de valeur. Les restrictions logicielles strictes entraînent des restrictions dans l'activité commerciale et contribuent à forcer l'adoption des pratiques standard de l'industrie.
- Les caractéristiques des suites d'entreprise incluent plusieurs modèles fonctionnels qui se chevauchent, avec un modèle de données défini. Les interfaces et les fonctionnalités peuvent être configurées ou personnalisées. Les personnalisations créent invariablement des coûts supplémentaires au cours du cycle de vie. Le cycle de vie est influencé par un tiers.
- Les caractéristiques des packages commerciaux spécialisés incluent la focalisation ponctuelle et l'optimisation fonctionnelle pour l'activité spécialisée. Généralement conçu autour d'une façon d'aborder l'activité commerciale. Possède généralement un modèle de données unique et bien défini. Les interfaces et les fonctionnalités peuvent être configurées. Une personnalisation est peut-être possible. Les personnalisations créent invariablement des coûts importants au cours du cycle de vie. Le cycle de vie est fortement influencé par un tiers.
- Les caractéristiques de développement personnalisées incluent un alignement direct entre les limites et les activités organisationnelles héritées de votre organisation. Invariablement conçu pour prendre en charge le modèle de communication existant de votre organisation. Focus ponctuel et optimisation fonctionnelle pour l'activité de spécialiste. 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 ignorée et entraîne un coût permanent élevé.
Idéal pour les activités commerciales dans la chaîne de valeur primaire. La flexibilité permet d'optimiser la façon dont la valeur est générée. Une utilisation efficace nécessite de comprendre la génération de valeur aujourd'hui et à l'avenir.
Modèle de développement d'applications
Le modèle de développement d'applications décrit comment le logiciel sera développé. Le modèle nécessite un modèle fonctionnel ou physique. Le modèle fonctionnel est bien meilleur car il s'agit d'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 a des caractéristiques et des implications uniques.
- Les caractéristiques 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 disponible.
Idéal pour les activités commerciales qui sont administratives et qui soutiennent indirectement une activité génératrice de valeur. Les restrictions logicielles strictes entraînent des restrictions dans l'activité commerciale et contribuent à forcer l'adoption des pratiques standard de l'industrie.
- Les caractéristiques des suites d'entreprise incluent plusieurs modèles fonctionnels qui se chevauchent, avec un modèle de données défini. Les interfaces et les fonctionnalités peuvent être configurées ou personnalisées. Les personnalisations créent invariablement des coûts supplémentaires au cours du cycle de vie. Le cycle de vie est influencé par un tiers.
- Les caractéristiques des packages commerciaux spécialisés incluent la focalisation ponctuelle et l'optimisation fonctionnelle pour l'activité spécialisée. Généralement conçu autour d'une façon d'aborder l'activité commerciale. Possède généralement un modèle de données unique et bien défini. Les interfaces et les fonctionnalités peuvent être configurées. Une personnalisation est peut-être possible. Les personnalisations créent invariablement des coûts importants au cours du cycle de vie. Le cycle de vie est fortement influencé par un tiers.
- Les caractéristiques de développement personnalisées incluent un alignement direct entre les limites et les activités organisationnelles héritées de votre organisation. Invariablement conçu pour prendre en charge le modèle de communication existant de votre organisation. Focus ponctuel et optimisation fonctionnelle pour l'activité de spécialiste. 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 ignorée et entraîne un coût permanent élevé.
Idéal pour les activités commerciales dans la chaîne de valeur primaire. La flexibilité permet d'optimiser la façon dont la valeur est générée. Une utilisation efficace nécessite de comprendre la génération de valeur aujourd'hui et à l'avenir.
Modèle de système
Le modèle système est une abstraction du logiciel autour d'une activité. Pensez au « système de chaîne d'approvisionnement » et à tout ce qui est impliqué dans la chaîne d'approvisionnement. La conception de votre modèle de système s'alignera sur le fonctionnement de votre entreprise.
À l'instar du modèle de capacité de l'architecte métier, un modèle de système vous permet d'orienter la réflexion vers un système. Vous pouvez envisager d'améliorer un système complet, puis concentrer les changements requis sur tout ce qui compose le système et interagit avec lui.
modèle du 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 ce qui est exécuté en termes comparables.
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 informera les choix du modèle de développement d'applications. Vous avez besoin d'un développement personnalisé, d'une 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 de logiciels en fonctionnalités. Il identifie toutes les choses que votre logiciel doit faire. De bons modèles fonctionnels offrent une large couverture.
Tout comme le modèle de processus de l'architecte d'entreprise, un modèle fonctionnel est souvent une architecture de référence. Il est très efficace lorsque vous recherchez la duplication et l'intégration. Il constitue souvent la base d'un modèle de développement d'application, où différents blocs fonctionnels se voient attribuer un type de développement d'application cible.
Critique dans la planification du portefeuille d'applications. La duplication et l'intégration augmentent la complexité et les coûts du 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 de franchissement de la limite. N'ayez pas peur de préciser que la limite ne peut pas être franchie ou doit être franchie manuellement. Beaucoup d'intégration d'applications faibles n'apporte que de la rigidité. Le développement d'un modèle d'intégration utile nécessite une itération avec le travail d'un architecte métier développant un Carte organisationnelle et Modèle d'informations. 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 réduit la fonctionnalité dans une boîte noire avec des interfaces connues. Un bon modèle de service est inestimable pour développer le modèle de développement d'applications et valider la cible dans un modèle de système. Les interfaces de votre modèle de service doivent toutes être bien identifiées dans votre modèle d'intégration.
Un bon modèle de service permettra l'agilité de l'entreprise. Pas à partir du développement de services applicatifs, mais en libérant le changement d'une partie de votre entreprise d'une autre.
Modèle physique
Un modèle physique est le véritable portefeuille de logiciels. Nous le décrirons en 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 faire passer la cible dans le monde réel.
Vous utilisez le modèle physique comme contrainte sur les modèles abstraits d'architecture d'application. Il constitue également la base de la Plan de mise en œuvre et de migration élaboré au cours de la phase F.
Techniques d'architecture d'applications
Nous utilisons un large éventail de techniques pour développer et communiquer notre architecture d'application.
- UML est omniprésent dans un bon développement piloté par les modèles. Lorsque vous travaillez dans l'architecture pour prendre en charge 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 l'implication de la cible pour différentes communautés. Le développement de modèles 4+1 permet de s'assurer que vous envisagez tous les changements pertinents.
- Les lignes de besoin d'information du DODAF extraient tous les flux d'informations nécessaires. Peu importe que le nœud soit une personne, une organisation ou un système. Les informations vont et viennent. Le moyen le plus rapide d'éliminer l'automatisation consiste à placer des étapes manuelles au milieu d'un flux d'informations.
Modèles d'architecture d'application alignés sur le cas d'utilisation de l'architecture d'entreprise
Le niveau de question auquel vous répondez avec votre architecture d'application déterminera l'utilisation de différents modèles d'architecture d'application. Par exemple, l'architecture de support du portefeuille ne développera souvent pas de modèle de chaîne de valeur. Au lieu de cela, 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 prendre en charge le portefeuille | Architecture pour soutenir le projet | Architecture pour prendre en charge 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 du 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 de fonctionnement | Chaîne de valeur | Modèle de capacité | Modèle de processus | Modèle fonctionnel | Modèle d'informations | Modèle d'organisation | |
| Modèle de développement d'applications | Intrant majeur
Nécessite un système ou un modèle fonctionnel |
Intrant majeur
Nécessite un système ou un modèle fonctionnel |
Intrant majeur
Nécessite un système ou un modèle fonctionnel |
Intrant majeur
Nécessite un système ou un modèle fonctionnel |
Intrant majeur
Nécessite un système ou un modèle fonctionnel |
Intrant majeur
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 du 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 de base
Nécessite un système ou un modèle fonctionnel |
Contribution majeure à la conception de base
Nécessite un système ou un modèle fonctionnel |
Meilleure entrée
Un lien direct est très difficile à voir. Cela vaut la peine de faire le travail. |
Contribution majeure à la conception de base
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 de base
Nécessite un système ou un modèle fonctionnel |
Contribution majeure à la conception de base
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 à voir. Cela vaut la peine de faire le travail. |
Utilisé comme test de complétude | Entrée majeure
Un lien direct est très difficile à voir. Cela vaut la peine de faire le travail. |
Entrée majeure |
Modèles d'architecture d'application pour les cas d'utilisation de l'architecture d'entreprise
Tout cas d'utilisation de l'architecture d'entreprise concernent le changement. Ils examinent tous les types de changement et comment un architecte d'entreprise aide les décideurs à tracer la 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 effectuons la même fonction. Nous aidons les parties prenantes à prendre de meilleures décisions et à mener des initiatives de changement réussies. Tout ce qui change, c'est la question.
| Changement stratégique | Changement progressif | Améliorer le coût | Améliorer la qualité | Améliorer l'agilité de l'entreprise | Atténuation des risques technologiques | Modernisation informatique | 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 du 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 d'architecture d'entreprise à l'architecture d'application
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 sur l'architecture d'application. Lors de l'exécution gouvernance de l'architecture d'entreprise, vous devez tester votre architecture d'application pour vous assurer qu'elle est conforme à une architecture supérieure. Ici, est-ce conforme aux principes de l'architecture d'entreprise ?
| Implication de l'architecture d'application | |
| Ne plaisante pas avec le succès | Si le programme n'est pas la différenciation ou la transformation, cherchez à éliminer le changement. Cherchez à éviter tout changement de processus ou de système qui n'est pas explicitement justifié par les coûts et les résultats. |
| Concentrez-vous sur l'excellence | Aligner avec le Modèle de fonctionnement la Modèle de capacité.
Tirez parti du modèle de développement d'applications pour concentrer vos dépenses sur la différenciation. Tirez parti du modèle de produit pour vous concentrer sur la livraison du produit et du service. |
| Pourquoi pas un ? | Tirez parti du modèle de développement d'applications et du modèle de produit pour identifier les domaines où 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 de l'actif de données. |
| Les systèmes fonctionnent là où nous travaillons | Interface d'entraînement de lieu de travail et de style de travail et modèle d'application. |
| Expérience utilisateur indolore | Les programmes d'efficacité se concentrent sur les processus métier existants.
Les programmes de différenciation et de transformation nécessitent une modification de l'interface utilisateur et de l'engagement à mesure que l'expérience avec le nouveau processus est développée. |
| En libre service | Les activités d'administration et le déploiement des applications coûtent cher lorsqu'ils ne sont pas en libre-service
Une UX faible est un coût élevé. |
Comment la phase C de TOGAF s'aligne-t-elle sur le développement agile ?
L'architecture d'application fournira de multiples contraintes et conseils pour un développement agile. Les conseils fondamentaux proviennent du modèle de développement d'applications. Il identifie les domaines dans lesquels vous ne souhaitez pas de développement agile.
Architecture d'entreprise et développement agile se croiseront sur quatre zones. La l'architecture d'entreprise va :
- définir l'approche agile
- guider le backlog en sprint
- limiter les choix dans les sprints
- résoudre la dépendance croisée des produits
Nous concentrons toujours le développement agile sur de nouvelles activités différenciantes et suivons impitoyablement les meilleures pratiques établies ailleurs. Les meilleures pratiques proviennent de logiciels commerciaux établis. Assurez-vous d'aligner l'architecture de votre application sur l'architecture de votre entreprise et concentrez-vous sur la manière dont vous acquérez les systèmes.
Comment TOGAF Phase C s'active-t-il avec Enterprise Agility ?
L'agilité d'entreprise n'a rien à voir avec la façon dont vous écrivez un logiciel. L'agilité d'entreprise concerne la capacité de votre entreprise à réagir aux menaces et aux opportunités inattendues. Si vous devez écrire du code, votre capacité à répondre à une menace ou une opportunité est à risque.
Un architecte d'application se concentrera sur le cinquième aspect de la modèle d'agilité d'entreprise - Souplesse. 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 qui doivent pouvoir évoluer rapidement. Ensuite, nous concevons pour permettre le changement.
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 disponible ?
- 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 de l'architecture. La vision de l'architecture incluait tous les domaines. L'activité de la phase C développe davantage les domaines de l'architecture des applications et des données. Le succès nécessite :
- 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 (lot de travaux)
- Vous comprenez l'interaction entre les changements et les contraintes dans d'autres domaines de l'architecture pour protéger la valeur attendue (Spécifications des exigences d'architecture)
Le résultat central de la phase C est l'architecture de l'application candidate. Les architectes d'application travaillent avec d'autres architectes de domaine pour comprendre les contraintes imposées à l'architecture de l'application et les contraintes imposées aux 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 bretelle de sortie la moins chère. Les mauvaises idées ne signifient pas que vous ne résolvez pas le problème. Vous devriez jeter faible alternatives architecturales. Arrêter les mauvaises idées plus tôt permet d'économiser de l'argent et permet des changements réussis. Au moment où une idée tourne mal, arrêtez net dans votre élan. Tuez l'idée. Célébrez votre victoire ! Célébrez le fait que vous permettez un changement réussi !
Modèles d'architecture d'application
Nous utilisons Modèles d'architecture pour augmenter considérablement la productivité et la qualité de notre développement d’architecture. Nous utilisons une version simplifiée Modèle de modèle d'architecture qui nous pousse à comprendre problème prévisible, approche modèle, et le Morceaux durs. L'applicabilité du modèle dépend généralement du travail requis, des contraintes et des limites.
Exemples de modèles d'architecture d'application
Les exemples de modèles d'architecture d'application couvrent le problème de la structure des applications, de la migration et de la conception des applications.
- Structure des candidatures
- Modèle MVC (Modèle-Vue-Contrôleur)
Problème prévisible—organisation, maintenabilité et testabilité du code
Approche- sépare une application en trois composants interconnectés : modèle (données et logique métier), vue (interface utilisateur) et contrôleur (gère les entrées de l'utilisateur et met à jour le modèle et la vue en conséquence)
- Modèle MVC (Modèle-Vue-Contrôleur)
- Migration d'applications
- Modèle d'étrangleur
Problème prévisible— remplacement des systèmes existants
Approche— remplacer ou « étrangler » progressivement un système existant en construisant de nouveaux composants autour de celui-ci pour remplacer progressivement le système
- Modèle d'étrangleur
- Conception d'applications (groupe de quatre modèles d'application)
En tant qu'architectes d'entreprise, nous utilisons les modèles de conception comme contraintes à 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 la phase C du TOGAF ADM
Les architectes d'applications travaillant avec un Équipe d'architecture d'entreprise ont un ensemble de responsabilités plus importantes que la conception d'une application. Ils doivent développer les directives et les garde-fous pour que les personnes puissent concevoir, concevoir, mettre en œuvre et développer le portefeuille d'applications de l'entreprise. Bref, le 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 son pair 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
- travailler avec les parties prenantes pour éliminer les changements dans le portefeuille d'applications qui fournissent trop peu ou coûtent trop cher. Éliminez également les modifications dans d'autres domaines qui entraînent des coûts inacceptables et modifient le portefeuille d'applications
Dans TOGAF ADM Phase C, l'un des quatre domaines d'architecture d'entreprise est développé. TOGAF est très clair que vous développez cette architecture lors du développement des autres domaines. Les changements dans un domaine activeront, forceront ou bloqueront les changements dans un autre domaine.
Les équipes EA performantes n'utilisent pas leurs architectes d'application comme concepteurs d'une seule application. Ce rôle est nécessaire, mais sans une architecture d'application qui couvre des parties importantes de l'entreprise, vous ne pouvez pas optimiser l'entreprise.
TOGAF ADM Phase C développe l'architecture de l'application. L'architecture des applications est la base de toutes les entreprises numériques modernes. Utilisez TOGAF Phase C pour concentrer les rares ressources de changement sur l'obtention de la plus grande valeur d'entreprise.
