Six cas d'utilisation d'architecture d'entreprise agile
Six cas d'utilisation d'une AE agile expliquent comment concevoir une équipe AE adaptée à différentes situations. Méthodes agiles pour l'AE, AE soutenant le développement agile et entreprise agile.
Il s'agit d'un sous-ensemble de la norme Cas d'utilisation de l'architecture d'entreprise. Les cas d’utilisation standard abordent tout, du changement stratégique à l’atténuation des risques et des acquisitions au développement agile.
Nous recherchons des modèles de cadrage simples pour clarifier notre réflexion. Ces modèles nous aident à isoler explicitement les conditions nécessitant des choix de configuration.
L'agilité, l'architecture d'entreprise et le développement agile de logiciels vont de pair.
- Agilité d'entreprise
- Développement logiciel agile et architecture d'entreprise
- Architecture d'entreprise en utilisant des méthodes agiles
L'isolement des conditions vous permet de concevoir votre équipe EA en toute confiance. Notre Services de capacité EA utiliser le Naviguer Architecture de référence des capacités EA. Les équipes EA hautement performantes sont configurées de manière optimale.
Architecture agile et d'entreprise s'accordent à merveille. Les deux résolvent différentes parties du problème.
Le développement logiciel agile excelle dans la création de solutions inédites et inexplorées. L'architecture d'entreprise excelle avant les décisions à prendre lorsqu'on ne sait pas quoi faire.
Mettre Développement logiciel agile et architecture d'entreprise ensemble pour optimiser le changement.
La plupart des architectes s'intéressent immédiatement aux liens entre développement d'entreprise et développement agile. Nombreux sont ceux qui tentent de concilier deux mondes radicalement divergents, généralement sans prendre le temps de comprendre l'un ou l'autre.
Nous optimisons l'architecture d'entreprise et le développement agile en les alignant sur leurs points forts. En résumé, l'architecture d'entreprise excelle avant les décisions difficiles. Le développement logiciel agile excelle à créer des solutions inédites.
Les deux méthodes souffrent d'une mauvaise application chronique. Malgré le concept d'itération inhérent à TOGAF, trop d'architectes s'accrochent au diagramme des agroglyphes ADM et voient le processus comme un processus. Il est si facile d'y voir une cascade. Faux, mais facile. De même, le saut désorganisé dans le parcours de découverte du développement agile masque leur désorganisation.
Le monde actuel est complexe. À moins qu'il ne s'agisse d'une simple création d'entreprise à un seul tour, les produits logiciels doivent s'intégrer dans un écosystème complexe. Les processus, l'organisation, les partenaires et l'infrastructure existants permettent à l'entreprise de servir ses clients. Le nouveau produit doit enrichir l'écosystème tout en s'y intégrant.
C'est dans la complexité du monde réel que le développement agile et l'architecture d'entreprise s'illustrent efficacement. Exploitez leurs atouts. Nous fondons une pratique de développement logiciel agile solide sur la résolution d'une tension essentielle.
Tension agile
Tu sais où tu vas. Tu ne sais pas comment y arriver.
Guide de l'architecte d'entreprise
Téléchargez le Guide de l'architecte d'entreprise un guide de la série TOGAF sur le développement d'une architecture d'entreprise utile.
Exemples de cas d'utilisation d'Agile EA
Cas d'utilisation 1 : Architecture d'une entreprise agile
Dans ce cas d'utilisation, l'objectif EA est contraint d'exiger des architectures cibles acceptables pour donner la priorité à l'agilité.
Franchement, cela n'a rien à voir avec les méthodes agiles. De nombreuses organisations agiles avec lesquelles nous avons travaillé n'utilisent pas de méthodes agiles de changement.
Nous nous inspirons largement de la Supply Chain et de la Gestion des Catastrophes comme références en matière d'agilité. Nous utilisons cinq attributs d'agilité (issus de la recherche sportive et militaire) :
- Vigilance
- Accessibilité
- Esprit de décision
- Rapidité
- Flexibilité
Ce cas d'utilisation exerce Atlas d'entreprise agile Navigate de Conexiam. Il optimise le développement de l'architecture pour l'agilité grâce à une bibliothèque de points de vue spécialisés, à l'engagement et aux préoccupations des parties prenantes.
Pour parler franchement, ce cas d’utilisation est dangereux s’il ne correspond pas aux véritables préférences des puissantes parties prenantes d’une organisation.
En termes de TOGAF, ce cas d'utilisation est principalement axé sur le TOGAF ADM Activité de réalisation de valeur de phase G et de phase H, où le changement doit être aligné sur la création et le maintien d'une entreprise agile.
Cas d'utilisation 2 : Utiliser l'EA pour définir une approche agile du changement
Dans ce cas d'utilisation, l'architecture d'entreprise sert à structurer la manière dont l'entreprise exécute le changement. Les produits, la structure de l'équipe de sprint, la vélocité et l'alignement avec toutes les approches de changement sont pris en compte.
Les questions à aborder sont : quel changement ? Quel développement adopter et quelle approche ? Dans le cas des méthodes agiles, des questions telles que le produit, la structure de l'équipe de sprint et la vélocité sont toutes traitées.
Ce cas d'utilisation exerce en grande partie la TOGAF ADM Phase F, G et H basées sur une architecture stratégique ou de portefeuille.
Cas d'utilisation 3 : Utiliser EA pour guider la planification du backlog et du sprint
Du point de vue de l'architecture d'entreprise et TOGAF, Toutes les phases d'implémentation, de prototypage, de pilotage, de projet et de sprints agiles se déroulent en phase G. L'architecture d'entreprise (AE) conforme aux meilleures pratiques produira une architecture d'entreprise complète avec un cahier de livraison de solutions, des écarts, des contrôles, une spécification d'architecture et un lot de travaux. Ces éléments doivent être décrits en termes adaptés au backlog : épopée, récit utilisateur et piste d'architecture.
L'architecture d'entreprise comportera un ensemble de lacunes, des lots de travaux pour les combler et des limites à la créativité des équipes d'implémentation pour réaliser les changements. Elle inclura une traçabilité des moteurs, des objectifs et des priorités, hors du champ de compétence du chef de produit et du client.
En méthode agile classique, les épopées et les récits utilisateurs axés sur le client complètent le backlog. Le client fournit les critères de priorisation. L'équipe agile auto-organisée priorise le travail.
Ce cas d'utilisation utilise l'architecture d'entreprise pour fournir un backlog non basé sur le client et guider la priorisation dans la planification des sprints.
Dans ce contexte, les épopées et les récits utilisateurs sont dérivés des écarts et des lots de travaux. Les dépendances externes limitent la priorisation, les critères d'acceptation et les critères de sortie. Des priorités prioritaires peuvent être définies.
Ce cas d’utilisation exerce principalement la TOGAF ADM Phase G, Gouvernance de la mise en œuvre : en langage clair, au cours de la phase G, l'équipe de mise en œuvre est informée des tâches à accomplir et des contraintes externes qui pèsent sur sa liberté d'action. La communication de l'équipe d'architecture d'entreprise est déterminée par l'organisation de l'équipe de mise en œuvre.
L'élément crucial est d'aligner la gouvernance de l'AE sur le modèle de changement agile. La dynamique de l'équipe de sprint ne doit pas être entravée.
Cas d'utilisation 4 : Utiliser EA pour contraindre les sprints agiles
Ce cas d'utilisation exerce en grande partie la gouvernance de mise en œuvre de la phase G de TOGAF ADM.
Suivant meilleures pratiques de gouvernance de l'architecture d'entreprise la question essentielle est :
L'équipe agile a-t-elle interprété de manière raisonnable les directives et les contraintes documentées de l'architecture cible ?
-
- Si oui, leur interprétation doit être acceptée comme une conformité et tout problème doit être résolu par une modification de l'architecture.
- Si ce n’est pas le cas, élaborez une recommandation pour corriger la situation.
C'est un point essentiel. Une bonne architecture peut proposer plusieurs options d'implémentation, et l'équipe agile n'est pas tenue de se conformer à une opinion. Si le choix d'implémentation est une interprétation raisonnable, il doit être jugé conforme. Si un élément a été omis dans la spécification d'architecture, ce n'est pas le problème de l'équipe agile. C'est celui de l'équipe d'architecture d'entreprise, qui doit modifier l'architecture approuvée.
L'élément critique est l'alignement gouvernance de l'architecture d'entreprise Activité avec un modèle de changement agile. La dynamique de l'équipe de sprint ne doit pas être entravée.
Les lacunes, la stratégie des lots de travaux, les contrôles et les spécifications d'architecture guident et contraignent les sprints. Ils doivent être rédigés et présentés dans des termes compréhensibles par l'équipe agile. Les contrôles et les spécifications d'architecture sont généralement présentés sous forme de critères d'acceptation et de critères de sortie.
Cas d'utilisation 5 : Utiliser EA pour résoudre la dépendance
Dans ce cas d'utilisation, l'architecture d'entreprise est utilisée pour gérer la dépendance et l'impact sur les équipes agiles.
Ce cas d'utilisation diffère du cas d'utilisation 4, car il modifie la façon dont l'équipe d'architecture d'entreprise s'implique. Souvent, lorsqu'il existe une dépendance, elle se situe entre différentes méthodes de changement (agile et en cascade), et les choix effectués au cours d'un sprint peuvent avoir des conséquences en cascade.
Un rôle clé du développement architecture pour soutenir la livraison de solutions Il s’agit d’identifier et de traiter ces dépendances avant qu’une équipe agile ne trébuche dessus.
Dans le cas d'utilisation 4, une mesure de réussite consiste à s'assurer que la dynamique ne soit pas entravée. Dans ce cas d'utilisation, la dynamique d'une équipe doit être équilibrée par rapport à celle d'autres équipes agiles, d'unités opérationnelles et d'équipes utilisant d'autres méthodes de changement.
Ce cas d'utilisation exerce largement l'activité de gouvernance et de modification des ordres de modification de la phase G de TOGAF ADM. Franchement, meilleures pratiques de gouvernance de l'architecture d'entreprise Évite d'accorder des exemptions aux dépendances inter-équipes en matière d'architecture. Les défis non identifiés constituent le domaine le plus courant d'exemptions en matière d'architecture.
Les problèmes de dépendance constituent le problème principal de l'équipe AE. Elle devra s'efforcer de sortir l'organisation de ces impasses le plus efficacement possible. La résolution de ces problèmes nécessite une attention particulière à l'architecture, aux contrôles et aux spécifications d'architecture supérieurs, tels qu'exprimés dans les Principes.
Cas d'utilisation 6 : Utiliser des méthodes agiles pour développer l'architecture d'entreprise
Dans ce cas d'utilisation, la capacité EA est configurée pour utiliser des méthodes agiles pour développer une architecture d'entreprise.
Conexiam EA prévisible Voici un exemple de ce cas d'utilisation. Pour mieux comprendre qu'une architecture sert à soutenir la prise de décision, nous désignons couramment le produit de travail utile par le terme “ classeur de conseils ”. Ce classeur est optimisé en fonction de l'objectif et du problème. Il sera utilisé de différentes manières.
Ce cas d'utilisation aura un impact majeur sur l'exécution de toutes les phases ADM de développement de l'architecture. Il dépend des résultats de la phase préliminaire, ainsi que de la structure et de l'exécution de la capacité AE.
Les praticiens qui travaillent aux extrêmes du développement logiciel agile et de l'architecture d'entreprise ne se rencontreront probablement jamais. Ils pourraient même ne pas reconnaître le travail de l'autre. La tension essentielle réside dans leur relation mutuelle.
Lorsqu'on s'arrête et qu'on examine l'alignement des meilleures pratiques d'architecture d'entreprise et de développement logiciel agile dans les domaines fondamentaux où elles interagissent, cela devient évident. Les praticiens qui travaillent aux extrêmes de l'architecture d'entreprise ou du développement logiciel agile peuvent ne jamais savoir ce que l'autre travaille pour l'entreprise et ne pas voir le résultat de leurs travaux respectifs.
Un praticien AE soutenant la stratégie et un responsable technique au sein d'une équipe de développement logiciel agile travaillent à distance. Le responsable technique dispose d'une fenêtre d'exécution qui se mesure en semaines ou en mois. Les plans de déploiement ou les pistes d'architecture s'inscrivent dans une réflexion à long terme. Le praticien AE stratégique a peut-être travaillé des années à l'avance sur la feuille de route définissant le développement des capacités de développement logiciel agile.
Guide de l'architecte d'entreprise
Téléchargez le Guide de l'architecte d'entreprise un guide de la série TOGAF sur le développement d'une architecture d'entreprise utile.
L'alignement de votre équipe d'architecture d'entreprise sur différents cas d'utilisation agiles permet d'identifier les plus applicables Cas d'utilisation de l'architecture d'entreprise.
Rejoignez le Kickstart de l'architecture d'entreprise
Programme gratuit de 12 semaines pour devenir un meilleur architecte d'entreprise
