Comprendre le développement agile et l'architecture d'entreprise
L'Agile et l'Architecture d'Entreprise s'accordent à 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.
- architecte d'une entreprise agile
- pratiques de travail agiles pour développer une architecture d'entreprise conforme aux meilleures pratiques
- développement logiciel agile et architecture d'entreprise
La plupart des architectes sautent jusqu'au dernier. Ils essaient d'assembler deux mondes extrêmement divergents, généralement sans s'arrêter pour comprendre non plus.
J'ai eu une conversation amusante avec le nouvel ingénieur en fiabilité des systèmes. Le spécialiste SRE était excité. Nous avons finalement commencé les pratiques modernes de CI/CD. Elle m'a demandé ce que l'équipe EA faisait pour aider ?
J'ai dû sourire quand elle a demandé, 'que fait l'équipe EA pour aider?' Ce qu'elle voulait vraiment dire, c'était "que faites-vous pour me soutenir aujourd'hui?' Aujourd'hui, face à ses défis immédiats, cela pourrait être - rien. Elle a sauté sur la façon dont l'équipe EA a soutenu son travail au jour le jour.
Elle n'a jamais vu la feuille de route du portefeuille qui impliquait des conteneurs, la gestion des données de test et, franchement, une suite de tests automatisés ridiculement insuffisante. Elle ne s'est pas rendu compte que la même vieille feuille de route identifiait un point de transition qui finançait son travail.
Équipes EA performantes réaliser leur objectif. Ils ne livrent rien d'autre. Même s'ils le pouvaient.
Six cas d'utilisation couvrent tous les aspects de l'architecture agile et d'entreprise
Un cadre simple pour réfléchir à l'architecture d'entreprise consiste à se demander ce qu'ils prennent en charge ?
- stratégie de soutien
- portefeuille de soutien
- projet de soutien
- soutenir la livraison de la solution
Développement agile et architecture d'entreprise
Lors du lien avec le développement logiciel agile, la même question est posée, à quoi l'équipe devrait-elle aider à répondre. Une partie de l'alignement est motivée par ce que l'équipe d'architecture d'entreprise est conçue pour prendre en charge.
- définir l'approche agile
- guider le backlog en sprint
- limiter les sprints
- résolution de la dépendance croisée des produits
Agile et architecture d'entreprise : définir l'approche agile
En règle générale, une équipe d'évaluation environnementale qui s'occupe de la stratégie et du portefeuille définir l'approche agile.
Produit
Les produits apparaissent sur une feuille de route sous forme d'écarts ou de lots de travaux. L'équipe EA peut parler de capacité ou de service commercial. Lorsqu'ils le font, attendez-vous à voir les produits nouveaux ou retravaillés.
Plateformes
Les praticiens les plus faibles se focaliseront sur la définition de termes tels que "Plateforme". Une définition nette et trop précise est un piège. Prenez quelques secondes de réflexion, il est parfaitement raisonnable que quelqu'un parle de SAP, 0365, Facebook, Pega ou même Angular et Containers en tant que plateformes. Le terme a besoin d'un contexte pour une définition étroite. Tout ce dont vous avez besoin, c'est que le consommateur et l'opérateur soient d'accord. J'ai succombé à la tentation de spécifier un produit qui était une plateforme consommée par d'autres. Les pédants ont tenté de déterminer s'il s'agissait d'un produit ou d'une plate-forme.
Stratégie de prestation de services
Les feuilles de route de niveau supérieur doivent être plus claires sur la manière de mettre en œuvre la transformation. Les exemples comprennent.
- Construire une capacité interne robuste ou utiliser des tiers ?
- Garantir des systèmes durables à longue durée de vie ou traiter certains ou tous les produits comme des Kleenex jetables ?
Points de repos de valeur majeure
Nous utilisons régulièrement les points de repos de valeur comme synonyme de transitions d'architecture. Fournissez toujours à vos parties prenantes une bretelle de sortie. Nous utilisons les bretelles de sortie pour deux raisons :
- Lorsque l'effort pour atteindre le prochain point de repos dépasse la valeur incrémentale.
Il s'agit d'une conversation sur le retour sur investissement. Les conversations sur le retour sur investissement conduisent généralement à un changement de priorité. - Lorsque l'effort pour atteindre un point de repos pourrait atteindre un repos plus excitant ou gratifiant.
Les conversations sur les compromis fournissent l'un des résultats les plus précieux d'un exercice de stratégie ou de feuille de route de portefeuille. Les ressources sont limitées. Les hauts dirigeants sont toujours à la recherche de la meilleure voie à suivre, et non du rendement potentiel le plus élevé. Le meilleur chemin. Les considérations incluent la valeur comparative au repos et la valeur potentielle comme tremplin pour d'autres activités.
Les responsables de la mise en œuvre comprennent rarement ces conversations. Ils deviennent émotionnellement investis dans un chemin ou un point de repos. Surtout lorsque l'existence du produit, ou de la prochaine version, est à l'étude.
Architecture agile et d'entreprise : guider le backlog dans le sprint
Les praticiens de l'EA qui prennent en charge le portefeuille et le projet s'engagent souvent avec des équipes agiles en guidant le backlog dans Sprint.
J'ai observé qu'il surprend trop d'évangélistes agiles que les organisations profondément attachées aux avantages du développement logiciel agile restent profondément attachées à la planification et à la budgétisation à plus long terme. Habituellement, la conversation confond une préférence culturelle mythique pour une chute d'eau.
Pensez plutôt au problème. La planification et la budgétisation à plus long terme existent en raison de la complexité de l'écosystème. Chaque organisation a plusieurs voies à suivre et des contraintes différentes. Les organisations qui réussissent effectuent des priorités et des compromis. Sans atteindre l'avenir préféré dans les contraintes de temps et de ressources, aucun travail ne devrait commencer.
L'Architecture d'Entreprise se résume à des contraintes. Chaque contrainte limite la créativité d'une équipe de développement logiciel agile. Sans un besoin impérieux de contrainte, ne le faites pas. Ne le faites pas.
Feuille de route pour guider le produit
La feuille de route pour guider le produit est l'un des livrables les plus difficiles pour une équipe EA talentueuse. La tension fondamentale de savoir où l'on va sans savoir comment s'y rendre est un point chaud.
Trop d'équipes d'architectes tombent dans le piège de la précision artificielle ou de l'omniscience imaginée. Les deux sont des façons fantaisistes de dire la pensée en cascade.
Le développement agile donne des résultats époustouflants lorsque l'équipe dispose de tous les degrés de liberté. Pensez simplement au point idéal d'un produit autonome entièrement nouveau.
Souvent, une bonne architecture se résume à fournir les contraintes minimales pour s'assurer que les décisions n'échouent pas à un test qui n'est pas apparent pour le décideur. Si le décideur peut voir le test, vous n'avez pas besoin d'architecture pour le contraindre. L'architecture existe pour guider ou contraindre le choix lorsque le facteur est en dehors du champ de vision des architectes.
Une feuille de route EA classique parlera des transitions, des lacunes et des modules de travail. Ce sera incompréhensible pour une équipe produit. Faites passer la feuille de route dans les bons termes avec le propriétaire du produit. Le propriétaire du produit doit comprendre les contraintes dans lesquelles il opère.
Attendez-vous à des tensions
Feuille de route pour guider l'épopée
La feuille de route pour guider l'épopée est le livrable le plus difficile pour une équipe EA talentueuse. Je pense toujours à être coincé dans un champ de mines lors d'un bombardement. Il n'y a nulle part où aller en toute sécurité.
Les attentes en matière de chronologie aggravent le piège commun de la pensée en cascade. Prendre de l'avance sur le parcours de découverte d'une équipe agile avec une précision artificielle et une omniscience imaginée sape tout dans le développement agile. Ne le faites pas!
Sans produits étroitement intégrés ou étroitement limités, les feuilles de route pour epic sont vouées à l'échec. Les exemples, lorsque cela est nécessaire, incluent plusieurs produits coexistant au sein d'un écosystème et partageant des données de référence. Consommer l'épuisement des données de l'autre nécessitera souvent des épopées associées ou une réglementation punitive complexe.
Sans pression extérieure, n'effectuez pas cette activité. La sur-spécification et la sur-conception par des praticiens omniscients autoproclamés sont une chose dont nous avons inventé l'agilité pour nous en passer. Si vous vous retrouvez obligé de suivre des feuilles de route vers des épopées, assurez-vous de comprendre exactement pourquoi il est nécessaire de limiter la créativité de vos développeurs de logiciels. Chaque contrainte qui restreint leur liberté et leur créativité a intérêt à remplacer la valeur ajoutée qui découle d'une créativité débridée.
Attendez-vous à un échec.
Lorsque nous avons réussi, nous avons activement adopté le langage de méthodes comme SaFE et cadré la feuille de route en termes de thèmes stratégiques et de pistes d'architecture.
Valeur d'entreprise
Une architecture supérieure répondra toujours aux préoccupations communes des parties prenantes. Il devrait fournir un ensemble de principes cohérents en interne qui limitent la définition de la valeur. Ici, l'architecture garantit que la négligence dans l'évaluation de la valeur ne crée pas de coûts en aval.
L'évaluation bâclée de la valeur est le problème le plus courant auquel une bonne architecture s'attaque. Règle des considérations transitoires. Une dichotomie classique est la distinction entre le temps de mise sur le marché tactique et la sécurité, la résilience ou la stabilité. Lorsque votre organisation a des impératifs, les chefs de produit et les équipes Scrum doivent être informés. Sinon, ils ne peuvent pas évaluer correctement l'arriéré par rapport aux paramètres qui comptent vraiment.
Contraignez les Product Owners "ascendants"
Trop de Product Owners n'ont pas de visibilité sur la raison pour laquelle leur produit existe ou Trop de Product Owners n'ont pas de visibilité sur la raison pour laquelle leur produit existe, ou quel est le rôle de l'écosystème. Limitez la liberté d'un propriétaire de produit ascendant soit en interdisant le choix, soit en imposant une notation et une évaluation.
Architecture agile et d'entreprise : limiter les sprints
Les praticiens de l'EA développant une architecture pour soutenir la livraison de projets et de solutions doivent s'attendre à limiter les sprints. Les praticiens axés sur le portefeuille qui développent un écosystème ou une plate-forme doivent également s'attendre à travailler avec les équipes agiles ici.
Les sprints contraignants peuvent être émotionnellement difficiles pour les nouveaux architectes qui étaient actifs dans le développement. Il est difficile de quitter son ancien emploi. Souvent, l'expertise en la matière conduit à une sur-spécification et à une sur-conception rampantes. Chaque contrainte qui restreint leur liberté et leur créativité doit démontrer qu'elle l'emporte sur la valeur ajoutée qui découle d'une créativité débridée.
La difficulté de quitter votre ancien emploi est la raison pour laquelle nous traitons tous ceux qui découvrent l'architecture d'entreprise comme des nouveau. Le jeune diplômé et la personne ayant 30 ans d'expérience dans autre chose que l'architecture d'entreprise sont de nouveaux architectes.
Je regarde de nouveaux architectes avec des années de autre expérience plus proche. Ils ont de nombreuses mauvaises habitudes qui les empêchent d'être des architectes de haut niveau.
Nathan et Sam parlent de développer de nouveaux architectes d'entreprise. Il est très important que tout architectes d'entreprise comprendre les droits de décision et servir les parties prenantes.
Critères d'acceptation
Un lien très simple dans un sprint est un critère d'acceptation défini en externe. Si l'architecture exige quelque chose, encadrez-le comme critère d'acceptation. À moins que le niveau de détail ne soit très proche d'interférer dans la créativité agile, la contrainte sera quelque chose de cohérent. Il y aura une demande de l'architecture d'entreprise, de l'architecture des applications de l'architecture des données ou de l'architecture de l'infrastructure. La spécification d'architecture sera un principal, un modèle ou une norme. Fournissez la contrainte comme critère d'acceptation. Alignez-vous sur un Sprint ou relâchez. Alors sortez du chemin et observez la créativité
Ont-ils raisonnablement interprété les orientations et les contraintes de l'architecture cible ?
- Si oui, leur interprétation doit être acceptée comme conformité. C'est un point clé. Une bonne architecture peut avoir plusieurs choix d'implémentation. L'exécutant n'est pas tenu d'adhérer à l'opinion. Si le choix d'implémentation est une interprétation raisonnable, il est conforme.
Valeur (mesures et points de repos)
Un point de conflit récurrent est la compréhension de la valeur.
Le développement de logiciels agiles selon les meilleures pratiques est axé sur la valeur. Malheureusement, la plupart des praticiens ont une compréhension limitée de la valeur. Le raccourci rapide est que la valeur est exprimée en termes de quelque chose a été livré. La valeur est évidente dans la livraison.
Dans un monde complexe, la chose livrée pourrait facilement dégrader la valeur. Un exemple simple sont les fonctionnalités destinées à s'éloigner des clients cibles ou le mouvement du travail entre les unités de travail. Ceci est courant lorsqu'un groupe est desservi par le produit. Nous vous recommandons fortement d'apprendre les pratiques de base Lean et Six-Sigma sur l'optimisation et la valeur locales. De plus, les concepts Business Model Canvas de Target Customer et Value Proposition sont utiles.
Pour relever ces défis, nous nous attendons à ce que l'architecture d'entreprise soit définitive quant à la manière dont la valeur est évaluée. L'architecture doit fournir des critères d'évaluation de la valeur aux équipes de développement.
Greenfield, évolution ou révolution
Dans Phase E de TOGAF, il y a une étape cool. Examinez le lot de travaux et sélectionnez une stratégie appropriée.
Le travail sera-t-il entièrement nouveau, évolutif ou révolutionnaire ? Voulons-nous conserver le plus possible, refactoriser radicalement ou repartir de zéro ? Il s'agit d'un accompagnement essentiel et d'une contrainte forte pour une équipe agile. Vont-ils repartir de zéro (Greenfield) ? Améliorer progressivement les systèmes existants (évolution) ? Ou effectuer un changement radical en vue d'éliminer les frictions et les tracas avec lesquels nous vivons (révolutionnaire) ?
Le choix de l'approche n'est peut-être pas le leur. Lorsqu'ils n'ont pas le choix, ce sera toujours motivé par des choix supérieurs à leur niveau de rémunération.
Contraindre les interfaces
Lorsqu'un produit doit s'adapter à un environnement d'entreprise existant ou prendre en charge un environnement d'entreprise en évolution, les interfaces sont essentielles. Les interfaces seront pilotées par les données et la méthode. Même lorsque le produit émerge, dans un monde complexe, il n'y aura pas de liberté pour permettre à la structure de données ou à l'interface d'émerger. Les données de référence, les données de référence et les systèmes existants limiteront tous le développement agile.
Les systèmes existants ne seront pas modifiés. Même le F-22 Raptor a dû se connecter à des systèmes hérités à l'aide d'interfaces développées dans les années 1970. Même un avion aussi cher ne pourrait pas faire remodeler les systèmes hérités. Le Raptor s'intègre à l'interface et à la structure de données existantes.
Une contrainte commune négligée par les équipes en mouvement rapide est la façon dont une législation multi-juridictionnelle, ou un plan d'affaires, affectera le produit. Dans ces cas, l'équipe EA a le devoir de creuser et de développer les contraintes minimales nécessaires pour éviter que le produit ne nécessite une refactorisation radicale à un moment inopportun. Comme toutes les contraintes sur la créativité, les bons praticiens de l'évaluation environnementale comprennent l'importance du juste assez.
Architecture d'entreprise et Agile : résoudre les dépendances
Nous pouvons nous attendre à ce que les praticiens de l'eA travaillant dans une entreprise aient besoin d'intervenir et de résoudre les dépendances et les conflits qui surviennent entre les produits, les solutions et les systèmes. Il suffit de regarder la phase G de TOGAF, elle met en évidence le besoin d'orientation et de changement d'architecture. Le développement agile et l'intégration moderne rendent ce service de longue date plus important qu'il ne l'a jamais été.
Débloquer le portefeuille
Même si vous n'êtes pas limité par l'héritage, il y aura plusieurs produits à l'avenir. Les équipes de développement agile des meilleures pratiques créatives vont trouver différentes façons de résoudre les problèmes. Il est insensé de s'attendre à ce que la créativité ne crée pas de conflit. On peut s'attendre à ce qu'une bonne équipe d'EA travaillant dans la phase G, où tous les développements logiciels agiles se produisent, débloque le conflit dans le portefeuille de l'entreprise.
Identifier les véritables parties prenantes
Les véritables parties prenantes sont souvent difficiles à trouver. De nombreuses décisions tactiques sont déléguées. Lorsque la délégation est formelle, l'équipe agile peut s'attendre à avoir un accès raisonnable. Lorsque la délégation est informelle, on peut s'attendre à ce que les experts locaux en la matière et les utilisateurs conduisent un programme non aligné.
L'équipe d'architecture d'entreprise n'a pas de capacité particulière à s'engager. Ils ont la capacité de représenter les préoccupations des parties prenantes grâce à une architecture supérieure.
Traverser le portefeuille
Les propriétaires de produits et les autres membres d'une équipe de développement sont amenés à livrer progressivement un produit. Un produit viable minimal et une livraison incrémentielle sont au cœur de la proposition de valeur agile.
Toute l'approche agile vient de l'échec observé d'essayer d'imaginer chaque interaction à travers un portefeuille complexe, c'est le chemin de l'échec. Une conception d'entreprise descendante détaillée peut fonctionner pour des systèmes isolés. Dans un écosystème qui change, la conception descendante échoue toujours. Ce chemin d'échec est la raison pour laquelle agile existe et pourquoi agile est préféré.
Il est presque impossible d'imaginer un avenir complexe, les efforts pour le faire tournent souvent à la farce. Pourtant, nous devons en faire juste assez. Au fur et à mesure que de multiples produits émergent, de nouveaux conflits et synergies émergeront. Une bonne équipe d'AE, avec une bonne compréhension des changements dans les priorités de leur entreprise, aidera à résoudre les synergies et les conflits.
Lorsque l'équipe EA découvre des intersections, elle doit utiliser sa perspicacité et son engagement pour obtenir la meilleure réponse. Il s'agira souvent d'une approche de gestion des risques. Évaluer rapidement le conflit pour déterminer si la résolution peut être différée est la première étape. Profiter de la synergie et éviter les conflits coûtent cher. Cher et chronophage. Ils interfèrent directement avec le time-to-market.
On parle en termes de forces du marché et de destruction créatrice quand on doit traverser le portefeuille.
Impact de la libération
Une architecture juste suffisante signifie que chaque éventualité, chaque contrainte, chaque conflit n'a pas été découvert avant la publication.
Il y a un cas où une équipe d'architecture a une urgence. C'est la crise de l'après-libération. Les rares cas où les implications s'étendent au-delà du produit. Le produit est à l'état sauvage. Les utilisateurs finaux à l'intérieur et à l'extérieur de notre organisation l'utilisent. Ils traitent soit d'un défaut, soit pire, créent un risque et une responsabilité imprévus pour notre organisation.
Conclusion de l'architecture agile et d'entreprise
Développement agile et l'architecture d'entreprise souffrent d'une mauvaise application chronique. Trop souvent en même temps.
Six cas d'utilisation couvrent tous les aspects de l'architecture agile et d'entreprise. L'architecture d'entreprise guide et contraint le développement logiciel agile.
Lorsqu'ils sont liés au développement logiciel agile, les architectes d'entreprise doivent :
- définir l'approche agile
- guider le backlog en sprint
- limiter les sprints
- résolution de la dépendance croisée des produits
L'architecture d'entreprise se résume à des limites - faites ceci, ne faites pas cela. Chaque limite limite la créativité d'une équipe de développement logiciel agile. Sans un besoin impérieux de contrainte, ne le faites pas. Ne le faites pas.
le Ensemble de connaissances TOGAF appuie l'élaboration d'une approche de gouvernance efficace.
Rejoignez le Kickstart de l'Architecture d'Entreprise
Programme gratuit de 12 semaines pour devenir un meilleur architecte d'entreprise