Six cas d'utilisation d'architecture d'entreprise agile

Six cas d'utilisation Agile EA identifient comment concevoir une équipe EA pour différentes conditions. Méthodes agiles pour EA, EA soutenant le développement agile et une 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 traitent de 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 pensée. Les modèles de cadrage nous aident à isoler explicitement les conditions dans lesquelles nous devons faire des choix de configuration.

Six cas d'utilisation pour Agile EA L'agilité, l'architecture d'entreprise et le développement logiciel agile vont de pair.

  1. Agilité d'entreprise
  2. Développement logiciel agile et architecture d'entreprise
  3. L'architecture d'entreprise en utilisant des méthodes agiles

Les conditions d'isolement vous permettent de concevoir votre équipe EA en toute confiance. Notre Services de capacité EA Utilisez le Naviguer Architecture de référence des capacités EA. Les équipes EA hautement fonctionnelles sont configurées de manière optimale.

Architecture agile et d'entreprise s'emboîtent à merveille. Les deux résolvent différentes parties du problème.

Le développement logiciel agile excelle dans la construction de quelque chose que nous n'avons jamais eu auparavant et que nous ne savons pas comment faire. L'architecture d'entreprise excelle avant les décisions lorsque vous ne savez pas quoi faire.

Mettre Développement logiciel agile et architecture d'entreprise ensemble pour optimiser le changement.

La plupart des architectes sautent sur la relation entre l'entreprise et le développement agile. Nous avons vu beaucoup de gens essayer de concilier deux mondes extrêmement divergents, généralement sans s'arrêter pour comprendre non plus.

Nous optimisons l'architecture d'entreprise et le développement agile en les alignant sur leurs points forts. Le raccourci que nous utilisons est que l'architecture d'entreprise excelle avant les décisions lorsque vous ne savez pas quoi faire. Le développement logiciel agile excelle dans la construction de quelque chose que nous n'avons jamais eu auparavant.

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 de crop circle ADM et voient le processus. Il est si facile de voir une cascade dans le diagramme ADM. Faux, mais facile. De plus, le saut désorganisé sur le chemin de la découverte du développement agile cache leur désorganisation.

Le monde réel est désordonné. À moins que nous ne parlions d'un simple greenfield à un 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 inscrivant.

C'est dans la complexité du monde réel que le développement agile efficace et l'architecture d'entreprise brillent. Jouez sur leurs points forts. Nous basons une solide pratique de développement logiciel agile sur la résolution d'une tension essentielle.

Tension agile
Vous savez où vous allez. Tu ne sais pas comment y arriver

Guide de l'architecte d'entreprise

Télécharger 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 Agile EA

Cas d'utilisation 1 : Architecturer une entreprise agile

Dans ce cas d'utilisation, l'objectif de l'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 de changement agiles.

Nous nous appuyons fortement sur la chaîne d'approvisionnement et la réponse aux catastrophes en tant que pierres de touche de haute agilité. Nous utilisons 5 attributs pour l'agilité (tirés de la recherche sportive et militaire) :

  • Vigilance
  • Accessibilité
  • Décisivité
  • Rapidité
  • La flexibilité

Ce cas d'utilisation exerce Navigate Agile Enterprise Atlas de Conexiam. Il optimise le développement de l'architecture pour l'agilité grâce à une bibliothèque de points de vue spécialisée, à l'engagement et aux préoccupations des parties prenantes.

Franchement, ce cas d'utilisation est dangereux s'il ne correspond pas aux véritables préférences des parties prenantes puissantes d'une organisation.

Sur le plan de TOGAF, ce cas d'utilisation est plus axé sur le SMA TOGAF Activité de réalisation de valeur de la phase G et de la 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 pour le changement

Produit de travail Agile et architecture d'entreprise Dans ce cas d'utilisation, l'architecture d'entreprise est utilisée pour structurer la façon dont l'entreprise effectue le changement. Les produits, la structure de l'équipe Sprint, la vélocité, l'alignement avec toutes les approches de changement sont effectués.

Les questions à aborder sont de savoir quel changement, quel développement doit suivre quelle approche. Dans le cas des méthodes agiles, des questions telles que le produit, la structure de l'équipe Sprint, la vélocité trouvent toutes une réponse.

Ce cas d'utilisation exerce en grande partie le SMA TOGAF Phase F, G & H basée 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 & TOGAF, toute la mise en œuvre, le prototypage, le pilote, le projet et les sprints agiles se produisent avec la phase G. Meilleure pratique EA produira une architecture d'entreprise remplie d'un cahier de livraison de solution, d'écart, de contrôle, de spécification d'architecture et de lot de travaux. Ce matériel doit être décrit en termes adaptés au backlog : Epic, User Story et Architecture Runway.

L'architecture d'entreprise contiendra un ensemble de lacunes, des modules de travail pour combler ces lacunes et des limites à la liberté de créativité des équipes de mise en œuvre pour effectuer le changement. Cela inclura la traçabilité des pilotes, des objectifs et des priorités en dehors de la compétence du chef de produit et du client.

Dans l'agile classique, les histoires d'épopées et d'utilisateurs axées sur le client remplissent le back-log. Le client fournit des 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 hiérarchisation dans la planification de sprint.

Dans ce cas, utilisez les épopées d'écart et les histoires d'utilisateurs dérivées des écarts et des packages de travail. La dépendance externe limite la priorisation, les critères d'acceptation et les critères de sortie. Des priorités prioritaires peuvent être fournies.

Ce cas d'utilisation exerce principalement le SMA TOGAF Phase G, Gouvernance de la mise en œuvre : en langage clair, dans la phase G, une équipe de mise en œuvre est informée du travail qu'elle doit effectuer et des contraintes externes sur sa liberté d'effectuer le travail. La façon dont l'équipe d'EA communique dépend de l'organisation de l'équipe de mise en œuvre.

L'élément critique est d'aligner l'activité de gouvernance de l'AE sur le modèle de changement agile. L'élan de l'équipe de sprint ne doit pas être altéré.

Cas d'utilisation 4 : Utiliser EA pour limiter les sprints agiles

Ce cas d'utilisation exerce en grande partie la phase G du TOGAF ADM, la gouvernance de la mise en œuvre.

Suivant meilleures pratiques Gouvernance EA la question essentielle est :

L'équipe agile a-t-elle raisonnablement interprété les directives et les contraintes documentées de l'architecture cible ?

    • Si oui, leur interprétation doit être acceptée comme conformité et tout problème doit être résolu par une modification de l'architecture
    • Si non, élaborez une recommandation pour corriger la situation.

C'est un point clé. Une bonne architecture peut avoir plusieurs choix de mise en œuvre, et l'équipe agile n'est pas tenue d'adhérer à l'opinion. Si le choix d'implémentation est une interprétation raisonnable, il doit être jugé conforme. Si quelque chose a été omis dans la spécification de l'architecture, ce n'est pas le problème de l'équipe agile. C'est le problème de l'équipe EA, ils ont besoin d'un changement à l'architecture approuvée.

L'élément critique est l'alignement Gouvernance de l'EE activité avec un modèle de changement agile. L'élan de l'équipe de sprint ne doit pas être altéré.

Les lacunes, la stratégie de lot 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 utilisables par l'équipe agile. Les contrôles et les spécifications d'architecture sont généralement rendus 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 est distinct du cas d'utilisation 4, car il modifie la façon dont l'équipe EA s'engage. Souvent, là où il y a dépendance, ce sera entre différentes méthodes de changement (agile et cascade) et où les choix au sein d'un sprint peuvent avoir des impacts en cascade.

Un rôle clé dans le développement architecture pour prendre en charge la livraison de solutions est d'identifier et de traiter ces dépendances avant qu'une équipe agile ne les survole.

Dans le cas d'utilisation 4, une mesure de réussite consiste à s'assurer que l'élan n'est pas altéré. Dans ce cas d'utilisation, la dynamique d'une équipe doit être équilibrée par rapport à d'autres équipes agiles, des unités opérationnelles et des équipes qui utilisent d'autres méthodes de changement.

Ce cas d'utilisation exerce en grande partie l'activité de gouvernance et d'ordre de modification de TOGAF ADM Phase G. Franchement, meilleures pratiques Gouvernance EA évite d'accorder des exemptions à la dépendance inter-équipes de l'architecture. Les défis qui n'ont pas été identifiés sont le domaine le plus courant des exemptions d'architecture.

Les problèmes de dépendance sont le problème de l'équipe EA. Ils devront effectuer un travail pour sortir l'organisation de ces trous le plus efficacement possible. La résolution de ces problèmes nécessite une attention particulière à l'architecture supérieure, aux contrôles et aux spécifications d'architecture exprimées dans les principes.

Cas d'utilisation 6 : Utiliser des méthodes agiles pour développer une 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.

EA prévisible Conexiam est un exemple de ce cas d'utilisation. Pour aider à comprendre qu'une architecture est utilisée pour soutenir la prise de décision, nous nous référons régulièrement au produit de travail utile sous le nom de "Relieur de conseils". Ce classeur est optimisé pour le but et le problème. Il sera consommé de plusieurs manières différentes.

Ce cas d'utilisation aura un impact important sur l'exécution de toutes les phases ADM pour développer l'architecture. Ce cas d'utilisation dépend du résultat de la phase préliminaire, ainsi que de la structure et de l'exécution de la capacité EA.

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 produit du travail de l'autre. La tension essentielle est dans leur relation les uns avec les autres.

Lorsque vous vous arrêtez et considérez l'alignement des meilleures pratiques d'EA et des meilleures pratiques de développement de logiciels agiles pour les domaines de base où ils 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 personne travaille pour l'entreprise, ils peuvent ne pas voir le produit du travail de l'autre.

Un praticien EA travaillant pour soutenir la stratégie et un responsable technique d'une équipe logicielle agile travaillent à distance. Le responsable technique vit une fenêtre d'exécution mesurée en semaines ou en mois. Les plans de sortie ou les pistes d'architecture sont une réflexion à long terme. Le praticien stratégique de l'EA aurait pu travailler des années auparavant sur la feuille de route qui définissait le développement de la capacité de développement logiciel agile.

Guide de l'architecte d'entreprise

Télécharger le Guide de l'architecte d'entreprise un guide de la série TOGAF sur le développement d'une architecture d'entreprise utile.

Objectif de l'architecture d'entreprise

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

Retour haut de page