Le d\u00e9veloppement logiciel agile excelle dans la cr\u00e9ation de solutions in\u00e9dites, dont la conception nous est inconnue. R\u00e9ussir la construction d'un syst\u00e8me complexe est d\u00e9j\u00e0 une t\u00e2che ardue, et la premi\u00e8re tentative est rarement couronn\u00e9e de succ\u00e8s. L'approche agile r\u00e9duit les risques li\u00e9s \u00e0 la mise en \u0153uvre. Elle proc\u00e8de par it\u00e9rations courtes et it\u00e9ratives, en cas d'\u00e9chec, puis recommence. Et finalement, elle r\u00e9ussit.<\/p>\n
L\u2019approche agile r\u00e9duit les risques en raccourcissant le cycle d\u2019essais.<\/p>\n
Le r\u00f4le d'un architecte d'entreprise<\/a> est d'aider les parties prenantes \u00e0 trouver la voie \u00e0 suivre en cas d'incertitude. L'architecture d'entreprise r\u00e9duit les risques lors de la d\u00e9finition des orientations et de la planification. Les architectures d'entreprise anticipent davantage que l'agilit\u00e9.\u00a0 comparer les changements potentiels<\/a> \u00e0 travers domaines d'architecture<\/a>.<\/p>\n L\u2019architecture d\u2019entreprise est con\u00e7ue pour \u00e9clairer la prise de d\u00e9cision et r\u00e9duire le co\u00fbt des efforts de changement vou\u00e9s \u00e0 l\u2019\u00e9chec.<\/p>\n L'architecture d'entreprise et l'agilit\u00e9 r\u00e9duisent les risques. L'architecture permet de r\u00e9duire les risques et les co\u00fbts avant la mise en \u0153uvre. L'agilit\u00e9 r\u00e9duit les risques et les co\u00fbts apr\u00e8s la mise en \u0153uvre.<\/p>\n\t\t\t\n\t\t\t\t\t\t\tEn savoir plus sur la certification TOGAF\n\t\t\t<\/a>\n\t Comment l\u2019architecture d\u2019entreprise et l\u2019Agile s\u2019articulent-elles ?<\/a><\/p>\n Architecture d'entreprise et agilit\u00e9 \u2013 D\u00e9finir l'approche agile<\/a><\/p>\n Architecture d'entreprise et Agile \u2013 Guide du backlog dans le sprint<\/a><\/p>\n Architecture d'entreprise et agilit\u00e9 \u2013 Limiter les sprints<\/a><\/p>\n Architecture d'entreprise et Agile \u2013 R\u00e9soudre les d\u00e9pendances<\/a><\/p>\n Architecture d'entreprise et conclusion agile<\/a><\/p>\n\t\t\t\t L'architecture d'entreprise et l'agilit\u00e9 s'int\u00e8grent de mani\u00e8re inattendue. La m\u00e9thode agile est au c\u0153ur de nos pr\u00e9occupations actuelles\u00a0: les \u00e9tapes de cr\u00e9ation de logiciels d'exp\u00e9dition viables. De ce point de vue, la question est de savoir quel est le r\u00f4le de l'architecture d'entreprise aujourd'hui\u00a0? Comment acc\u00e9l\u00e9rer l'exp\u00e9dition des logiciels\u00a0?<\/p>\n L'architecture d'entreprise et l'agilit\u00e9 ne s'int\u00e8grent pas au sein du sprint. Elles s'int\u00e8grent en dehors du cycle de d\u00e9veloppement. Elles s'int\u00e8grent gr\u00e2ce aux architectes d'entreprise et aux d\u00e9veloppeurs agiles dans l'exercice de leurs fonctions. Les \u00e9quipes d'architecture d'entreprise performantes respectent leurs engagements. cas d'utilisation<\/a>. Ils ne tiennent aucun autre engagement. M\u00eame s'ils le pouvaient.<\/p>\n Nous disposons d'une architecture d'entreprise simple et d'un mod\u00e8le de r\u00e9f\u00e9rence agile. Il existe quatre principaux mod\u00e8les d'engagement en mati\u00e8re d'architecture d'entreprise\u00a0:<\/p>\n Au cours des derni\u00e8res ann\u00e9es, j'ai travaill\u00e9 sur Transformation num\u00e9rique<\/a> initiatives, nous avons d\u00e9velopp\u00e9 un ensemble de mod\u00e8les d\u2019engagement.<\/p>\n\t\t\t\t <\/p>\n Commencez par analyser votre cas d'utilisation d'AE. Quels conseils \u00eates-vous cens\u00e9 fournir\u00a0? \u00c0 qui vous adressez-vous\u00a0? Ensuite, examinez les mod\u00e8les d'engagement qui r\u00e9pondent \u00e0 vos d\u00e9fis professionnels. Int\u00e9grez-les \u00e0 vos interactions.<\/p>\n Notre mod\u00e8le de mod\u00e8le d'architecture<\/a> comporte deux \u00e9l\u00e9ments cl\u00e9s : le probl\u00e8me pr\u00e9visible<\/em> et le approche<\/em> pour r\u00e9soudre le probl\u00e8me. Nous recueillons \u00e9galement les morceaux durs<\/em>. Lorsque nous examinons un mod\u00e8le, nous examinons dans quelle mesure il r\u00e9sout le probl\u00e8me et la quantit\u00e9 de travail suppl\u00e9mentaire n\u00e9cessaire pour appliquer le mod\u00e8le avec succ\u00e8s.<\/p>\n Examinons les mod\u00e8les d'engagement\u00a0: le probl\u00e8me qu'ils r\u00e9solvent, l'approche adopt\u00e9e et les difficult\u00e9s rencontr\u00e9es.<\/p>\n J'ai eu une conversation amusante avec l'ing\u00e9nieure en fiabilit\u00e9 des syst\u00e8mes nouvellement embauch\u00e9e. La sp\u00e9cialiste SRE \u00e9tait ravie. Nous avons enfin mis en place des pratiques modernes\u00a0: CI\/CD et tests automatis\u00e9s. Elle m'a demand\u00e9 ce que l'\u00e9quipe EA faisait pour nous aider.<\/p>\n J'ai d\u00fb sourire quand elle a demand\u00e9 : \u2018que fait l'\u00e9quipe EA pour aider ?<\/em>\u2018 Ce qu'elle voulait vraiment dire, c'est\u2026 \u2018que fais-tu pour me soutenir aujourd'hui ?<\/em>\u2018 Aujourd'hui, concernant ses d\u00e9fis imm\u00e9diats, rien. Elle \u00e9tait impliqu\u00e9e dans la mise en \u0153uvre. Elle observait les aspects li\u00e9s \u00e0 la mise en \u0153uvre. \u00bb.<\/p>\n Elle ne comprenait pas comment l'organisation \u00e9voluait. Elle n'\u00e9tait pas au courant de feuille de route du portefeuille<\/a>. La feuille de route pr\u00e9voyait une \u00e9tape de transition que nous venions d'atteindre. Nous avions mis en place des conteneurs, la gestion des donn\u00e9es de test et une suite de tests automatis\u00e9s rudimentaire. Elle ne se rendait pas compte que cette planification verticale et d\u00e9pass\u00e9e avait cr\u00e9\u00e9 les conditions de son nouveau poste.<\/p>\n Elle pensait au d\u00e9veloppement imm\u00e9diat. Je pensais \u00e0 l'ensemble transformation num\u00e9rique<\/a>. Son r\u00f4le consistait \u00e0 aider l'organisation \u00e0 traverser la prochaine transition. Elle d\u00e9veloppait capacit\u00e9s critiques<\/a>. Les tests automatis\u00e9s devaient fournir la preuve du respect des contraintes d'architecture. Je passais de d\u00e9finir l'approche agile<\/a>. J'avais besoin d'aide pour guider l'arri\u00e9r\u00e9<\/a>.<\/p>\n Dix ponts et routes de liaison valent plus que 500 demi-ponts qui ne m\u00e8nent nulle part<\/em><\/strong><\/p>\n490 constructeurs de ponts seront m\u00e9contents Agile est un choix. Il pr\u00e9sente des avantages et des inconv\u00e9nients. Adopter Agile n\u00e9cessite des choix concernant le produit, la plateforme, la strat\u00e9gie de prestation de services et les points de transition descendants.<\/p>\n Une \u00e9quipe EA doit avoir la capacit\u00e9 de soutenir Strat\u00e9gie<\/a> et Portefeuille<\/a> \u00e0 d\u00e9finir l'approche agile.<\/em><\/strong><\/p>\n Probl\u00e8me pr\u00e9visible<\/strong>:Quand utilisez-vous Agile ?<\/p>\n Les produits externes sont plus faciles \u00e0 g\u00e9rer que les produits internes. En bref, il existe un march\u00e9. En interne, l'utilisation de l'agilit\u00e9 transforme le syst\u00e8me interne en produits num\u00e9riques. Il est n\u00e9cessaire de d\u00e9terminer l'existence, le p\u00e9rim\u00e8tre et l'approche de d\u00e9veloppement des syst\u00e8mes internes.<\/p>\n Probl\u00e8me pr\u00e9visible<\/strong>:D'o\u00f9 vient le produit ?<\/p>\n Approche<\/strong>Adapter la d\u00e9finition des \u2018 solutions \u2019 utilis\u00e9es pour combler les lacunes et des r\u00e9sultats des lots de travaux afin de les aligner sur des produits autonomes. D\u00e9velopper un portefeuille de produits internes et un ensemble de mesures de valeur pour ces produits. Les produits doivent figurer sur le feuille de route architecturale<\/a>.<\/p>\n Les plateformes peuvent am\u00e9liorer la rapidit\u00e9 et la p\u00e9rennit\u00e9 du d\u00e9veloppement. Cependant, une plateforme mal choisie aura l'effet inverse. Le choix d'utiliser une plateforme, et encore moins sa nature, ne rel\u00e8ve pas de la comp\u00e9tence d'une \u00e9quipe agile. Nous avons utilis\u00e9 le terme \u00ab\u00a0plateforme\u00a0\u00bb pour d\u00e9signer des solutions telles que SAP, M365, Facebook, Pega, ou encore OpenShift Containers.<\/p>\n Architectures de r\u00e9f\u00e9rence<\/a>\u00a0jouent un r\u00f4le essentiel dans la d\u00e9finition, la s\u00e9lection et gouvernant<\/a>\u00a0l'utilisation des plateformes.<\/p>\n Probl\u00e8me pr\u00e9visible<\/strong>:Quand faut-il utiliser une plateforme et quand faut-il que le produit soit sans contrainte ?<\/p>\n Approche<\/strong>:Approches multiples<\/p>\n Morceaux durs<\/strong>:Question de support et de p\u00e9rennit\u00e9 du produit et de la plateforme.<\/p>\n Une strat\u00e9gie de prestation de services d\u00e9signe l'approche utilis\u00e9e par les organisations pour fournir des produits ou des services. Il n'est pas certain que vous choisirez votre approche actuelle\u00a0: interne, contractuelle, renforcement des effectifs.<\/p>\n Probl\u00e8me pr\u00e9visible<\/strong>:Comment votre organisation va-t-elle assurer un d\u00e9veloppement agile ?<\/p>\n Approche<\/strong>:Suivez les approches de l'architecture pour soutenir la strat\u00e9gie. Posez la question de savoir comment le d\u00e9veloppement agile sera rendu possible. Utilisez un Mod\u00e8le op\u00e9rationnel<\/a> pour d\u00e9finir la valeur et une Organigramme<\/a> d\u00e9finir comment les diff\u00e9rents consommateurs, d\u00e9veloppeurs et op\u00e9rateurs d\u2019un produit travailleront ensemble.<\/p>\n Le d\u00e9veloppement agile est tout aussi susceptible que toute autre approche de savoir quand s'arr\u00eater. Les points de repos de valeur sont synonymes de transitions d'architecture. Nous utilisons ce terme pour souligner que les parties prenantes disposent d'une porte de sortie et peuvent cesser d'investir. Les parties prenantes utiliseront ces portes de sortie pour plusieurs raisons\u00a0:<\/p>\n Probl\u00e8me pr\u00e9visible<\/strong>:Conna\u00eetre le point de repos de la valeur pour arr\u00eater ou changer de focus<\/p>\n Approche<\/strong>Utiliser des feuilles de route d'architecture pour explorer d'autres points de cr\u00e9ation de valeur. Cr\u00e9er des rapports sur l'activit\u00e9 vers les \u00e9tats de transition.<\/p>\n Morceaux durs<\/strong>Les consid\u00e9rations incluent la valeur comparative au repos et la valeur potentielle comme tremplin pour d'autres activit\u00e9s. Les impl\u00e9menteurs comprennent rarement ces conversations. Ils s'investissent \u00e9motionnellement dans une voie ou un point de repos, surtout lorsque l'existence du produit, ou la prochaine version, est en jeu. Les dirigeants recherchent toujours la meilleure voie \u00e0 suivre, et non le rendement potentiel le plus \u00e9lev\u00e9. Ils recherchent la meilleure voie.<\/p>\n L'exploration des points de repos de la valeur constitue la premi\u00e8re \u00e9tape. Les d\u00e9cideurs doivent comprendre les options (s\u00e9lection selon diff\u00e9rents crit\u00e8res et report des d\u00e9cisions incertaines). Ensuite, ils doivent identifier les moyens d'atteindre les diff\u00e9rents points de repos de la valeur s\u00e9lectionn\u00e9s.<\/p>\n Meilleures pratiques architecture d'entreprise<\/a> depuis Conexiam Naviguer<\/a><\/p>\n\t\t\t\n\t\t\t\t\t\t\tPlanifiez une formation personnalis\u00e9e en architecture d'entreprise pour dynamiser votre \u00e9quipe\n\t\t\t<\/a>\n\t Les \u00e9quipes agiles performantes trouvent la voie la plus efficace. La planification et la budg\u00e9tisation \u00e0 long terme sont n\u00e9cessaires en raison de la complexit\u00e9 de l'\u00e9cosyst\u00e8me. Le d\u00e9fi consiste \u00e0 concilier planification \u00e0 long terme et cr\u00e9ativit\u00e9 agile. Il s'agit de concilier planification descendante et ex\u00e9cution ascendante.<\/p>\n Il faut leur expliquer les priorit\u00e9s organisationnelles dans des termes qui peuvent \u00eatre int\u00e9gr\u00e9s \u00e0 la gestion des arri\u00e9r\u00e9s.<\/p>\n L'agilit\u00e9 existe parce que les personnes les plus proches de la solution peuvent trouver la voie la plus efficace. Les organisations performantes priorisent et font des compromis. Sans atteindre l'objectif souhait\u00e9 dans les d\u00e9lais et les ressources limit\u00e9s, aucun travail ne devrait \u00eatre entrepris.<\/p>\n Une \u00e9quipe EA doit avoir la capacit\u00e9 de soutenir Portefeuille<\/a> et projet \u00e0 guide du backlog dans le sprint<\/em><\/strong>.<\/p>\n Probl\u00e8me pr\u00e9visible<\/strong>:Assurer que les r\u00e9sultats attendus, la valeur, les attentes en mati\u00e8re de performances en cascade et les contraintes guident la publication et le d\u00e9veloppement du produit.<\/p>\n Morceau dur<\/strong>Trop d'\u00e9vang\u00e9listes agiles s'\u00e9tonnent que les organisations adoptant l'agilit\u00e9 restent profond\u00e9ment attach\u00e9es \u00e0 la planification et \u00e0 la budg\u00e9tisation \u00e0 long terme. Il nous faut souvent surmonter l'id\u00e9e re\u00e7ue selon laquelle il existe une pr\u00e9f\u00e9rence culturelle pour la m\u00e9thode en cascade.<\/p>\n Probl\u00e8me pr\u00e9visible<\/strong>:Avoir une feuille de route produit compl\u00e8te, au lieu d'un cycle de publication de fonctionnalit\u00e9s.<\/p>\n Approche<\/strong>: En utilisant un technique de feuille de route architecturale<\/a> O\u00f9 le produit, ou la famille de produits, remplace le portefeuille. Veiller \u00e0 ce que les rapports habituels sur les produits incluent l'activit\u00e9 vers les \u00e9tats de transition.<\/p>\n Morceaux durs<\/strong>Une excellente gestion de produit permettra d'\u00e9tablir une feuille de route compl\u00e8te. Trop de responsables produits ascendants manquent d'exp\u00e9rience en gestion du cycle de vie ou de l'int\u00e9gration d'une suite de produits int\u00e9gr\u00e9e. L'\u00e9quipe d'architecture d'entreprise devra prendre le relais, ou se replier sur elle-m\u00eame, en fonction des comp\u00e9tences de l'organisation produit.<\/p>\n Trop d'\u00e9quipes d'architecture tombent dans le pi\u00e8ge de la pr\u00e9cision artificielle ou de l'omniscience imaginaire. Ce sont deux fa\u00e7ons sophistiqu\u00e9es de parler de \u00ab\u00a0pens\u00e9e en cascade\u00a0\u00bb. Une feuille de route d'architecture classique parlera de transitions, d'\u00e9carts et de lots de travaux. Cela sera incompr\u00e9hensible pour une \u00e9quipe produit. Adoptez un langage produit et agile. Le responsable produit doit comprendre les contraintes auxquelles il est soumis.<\/p>\n L'\u00e9laboration de la feuille de route n\u00e9cessite une architecture suffisante. La seule approche \u00e9volutive est \u2018juste assez<\/em>.\u2019\u00a0Le juste assez\u00a0\u00bb signifie faire respecter les priorit\u00e9s organisationnelles et \u00e9viter les probl\u00e8mes pr\u00e9visibles. \u00ab\u00a0Le juste assez\u00a0\u00bb signifie ne pas intervenir dans la conception du produit. Privil\u00e9giez des mod\u00e8les d'architecture performants pour l'ensemble du portefeuille. \u00ab\u00a0Le juste assez\u00a0\u00bb signifie ignorer les synergies potentielles. \u00ab\u00a0Le juste assez\u00a0\u00bb signifie se concentrer sur les probl\u00e8mes pr\u00e9visibles. \u00c9viter les probl\u00e8mes pr\u00e9visibles est crucial. \u00ab\u00a0Le juste assez\u00a0\u00bb signifie ne pas craindre la destruction cr\u00e9atrice. Utilisez un concept de cycle de vie pr\u00e9vu pour impulser une refactorisation agressive (approches novatrices et r\u00e9volutionnaires).<\/p>\n L\u2019utilisation des techniques avec le propri\u00e9taire du produit permet d\u2019int\u00e9grer les priorit\u00e9s et les contraintes organisationnelles dans la feuille de route du produit.<\/p>\n Probl\u00e8me pr\u00e9visible<\/strong>:Utiliser des \u00e9pop\u00e9es pour impl\u00e9menter des r\u00e9sultats et des contraintes descendants dans le produit.<\/p>\n Approche<\/strong>:Utiliser des \u00e9tats de transition bien construits dans un technique de feuille de route architecturale<\/a> O\u00f9 le produit, ou la famille de produits, remplace le portefeuille. Veiller \u00e0 ce que les rapports habituels sur les produits incluent l'activit\u00e9 vers les \u00e9tats de transition.<\/p>\n Morceaux durs<\/strong>N\u00e9cessite des produits \u00e9troitement int\u00e9gr\u00e9s ou soumis \u00e0 des contraintes strictes. L'accent doit \u00eatre mis sur l'int\u00e9gration ou les points de contrainte. La coexistence de plusieurs produits au sein d'un \u00e9cosyst\u00e8me et le partage de donn\u00e9es de r\u00e9f\u00e9rence en sont un exemple simple.<\/p>\n Il est fr\u00e9quent de tomber dans le pi\u00e8ge de la conception en amont. Il faut se concentrer sur les domaines o\u00f9 vos d\u00e9veloppeurs logiciels doivent limiter leur cr\u00e9ativit\u00e9 en raison d'exigences li\u00e9es \u00e0 l'\u00e9cosyst\u00e8me ou externes. Id\u00e9alement, cette approche devrait \u00eatre mise en place en amont plut\u00f4t qu'en r\u00e9action \u00e0 une dette technique.<\/p>\n Une fois ce projet r\u00e9ussi, nous avons activement adopt\u00e9 le langage de m\u00e9thodes comme SaFE et d\u00e9fini la feuille de route en termes de th\u00e8mes strat\u00e9giques et de pistes d\u2019architecture.<\/p>\n Probl\u00e8me pr\u00e9visible<\/strong>: Assurer que les facteurs critiques de succ\u00e8s inclus dans les \u00e9tats de transition et cibles guident la pr\u00e9paration agile du backlog et la planification \u00e9pique.<\/p>\n Approche<\/strong>Traduire les mesures et objectifs descendants en crit\u00e8res exploitables pour la pr\u00e9paration agile du backlog. Veiller \u00e0 ce que les rapports produits habituels incluent la s\u00e9lection et la r\u00e9alisation des activit\u00e9s en vue de la valeur annonc\u00e9e.<\/p>\n Morceaux durs<\/strong>Les mesures descendantes doivent \u00eatre d\u00e9finitives et faciles \u00e0 \u00e9valuer. Par exemple, on ne peut pas demander \u00e0 l'\u00e9quipe agile de trouver un \u00e9quilibre subtil entre d\u00e9lai de mise sur le march\u00e9 et r\u00e9silience. Une terminologie claire est requise.<\/p>\n Toute modification des mesures descendantes entra\u00eenera une certaine confusion, notamment lorsqu'un \u00e9tat de transition a \u00e9t\u00e9 atteint.<\/p>\n Pour les produits internes, nous nous assurons toujours de disposer d'un mod\u00e8le de co\u00fbts solide pour les produits num\u00e9riques avant d'introduire des mesures de r\u00e9duction des co\u00fbts. Sans mod\u00e8le de co\u00fbts, les co\u00fbts op\u00e9rationnels et de plateforme seront perdus, et tous les co\u00fbts seront justifi\u00e9s par les co\u00fbts de mise en \u0153uvre. Nous pr\u00e9voyons d'aider le chef de produit interne \u00e0 comprendre l'ITFM<\/a>. En revanche, les chefs de produit de produits num\u00e9riques externes ont g\u00e9n\u00e9ralement une tr\u00e8s bonne compr\u00e9hension des co\u00fbts.<\/p>\n Probl\u00e8me pr\u00e9visible<\/strong>:Les propri\u00e9taires de produits qui consid\u00e8rent l\u2019ensemble de l\u2019entreprise \u00e0 travers le prisme de leur produit et de ses utilisateurs directs.<\/p>\n Approche<\/strong>Documenter le produit et son r\u00f4le au sein de l'\u00e9cosyst\u00e8me. Documenter les contraintes applicables au produit. Documenter les crit\u00e8res d'\u00e9valuation. S'assurer que les rapports habituels sur le produit incluent la progression vers les \u00e9tats de transition et les activit\u00e9s align\u00e9es sur la valeur de l'entreprise.<\/p>\n Morceaux durs<\/strong>Les responsables de produits num\u00e9riques internes constituent souvent un maillon faible. Parmi les difficult\u00e9s courantes, on compte l'incompr\u00e9hension\u00a0:<\/p>\n Les \u00e9quipes d'architecture d'entreprise en charge du portefeuille et des projets sont les plus susceptibles d'avoir besoin de contraindre les Product Owners \u2018\u00a0ascendants\u00a0\u2019. Cela n\u00e9cessite un effort concert\u00e9 et une affectation de personnel.<\/p>\n Nous passons de l'aide \u00e0 la gestion du dos \u00e0 l'int\u00e9gration au sprint. Il s'agit d'int\u00e9grer les sp\u00e9cifications d'architecture au logiciel, sans interf\u00e9rer avec la cr\u00e9ativit\u00e9 et l'innovation de l'\u00e9quipe agile.<\/p>\n Chaque sp\u00e9cification d'architecture supprime un degr\u00e9 de libert\u00e9. En limitant cette libert\u00e9, nous rendons plus difficile pour l'\u00e9quipe agile de trouver la voie la plus efficace. Lorsque ces contraintes influencent les priorit\u00e9s de l'entreprise, nous facilitons la recherche de la meilleure voie.<\/p>\n Probl\u00e8me pr\u00e9visible<\/strong>:S'assurer que les d\u00e9cisions prises au cours du sprint, essentielles au succ\u00e8s agile, sont conscientes et orient\u00e9es par les priorit\u00e9s, les pr\u00e9f\u00e9rences et les contraintes de l'organisation.<\/p>\n Morceaux durs<\/strong>Trouver un \u00e9quilibre entre les exigences de l'entreprise et l'interf\u00e9rence avec la libert\u00e9 de conception et d'approche requise. Ceci est particuli\u00e8rement vrai pour les architectes issus du d\u00e9veloppement. L'expertise m\u00e9tier cr\u00e9e une pente glissante, allant des sp\u00e9cifications de l'entreprise \u00e0 la conception. Cela conduit \u00e0 une architecture \u00ab\u00a0big-in-front\u00a0\u00bb de mauvaise qualit\u00e9.<\/p>\n Les architectes d'entreprise qui soutiennent la livraison de projets et de solutions doivent s'attendre \u00e0 des contraintes de sprints. Les architectes qui se concentrent sur un \u00e9cosyst\u00e8me ou une plateforme de produits doivent \u00e9galement s'attendre \u00e0 collaborer avec les \u00e9quipes agiles.<\/p>\n Probl\u00e8me pr\u00e9visible<\/strong>:Assurer que le logiciel est conforme aux sp\u00e9cifications et aux normes de l'architecture d'entreprise.<\/p>\n Approche<\/strong>: Fournir des crit\u00e8res d'acceptation obligatoires applicables \u00e0 la fin des \u00e9pop\u00e9es et avant leur publication. Nous avons souvent utilis\u00e9 Mod\u00e8les d'architecture d'application<\/a> et Mod\u00e8les d'architecture de donn\u00e9es<\/a> Cr\u00e9er des crit\u00e8res d'acceptation. Inclure des crit\u00e8res d'acceptation obligatoires dans tous les rapports de test.<\/p>\n Morceaux durs<\/strong>Savoir quand appliquer les crit\u00e8res d'acceptation obligatoires. Trop t\u00f4t fausse le d\u00e9veloppement. Trop tard entra\u00eene des pressions pour des exceptions de publication. Cela est particuli\u00e8rement vrai pour les produits num\u00e9riques internes qui ne b\u00e9n\u00e9ficient pas de cycles de publication r\u00e9ellement pr\u00e9visibles.<\/p>\n Nous classons nos sp\u00e9cifications d\u2019architecture comme suit\u00a0:<\/p>\n La plupart des crit\u00e8res d\u2019acceptation obligatoires doivent \u00eatre des mod\u00e8les d\u2019architecture ou des normes.<\/p>\n N'oubliez jamais de vous \u00e9carter du chemin et de r\u00e9colter la cr\u00e9ativit\u00e9.<\/p>\n Probl\u00e8me pr\u00e9visible<\/strong>:Comprendre ce qui est valoris\u00e9 et comment la valeur est mesur\u00e9e.<\/p>\n Approche<\/strong>L'architecture d'entreprise doit d\u00e9finir clairement la mani\u00e8re dont la valeur est d\u00e9crite et mesur\u00e9e. Les \u00e9nonc\u00e9s de valeur n\u00e9cessitent des facteurs critiques de succ\u00e8s (FCS) et des mesures d'efficacit\u00e9 (ME). Assurez-vous que les mesures de valeur sont incluses dans les rapports sur les produits, les \u00e9pop\u00e9es et les versions.<\/p>\n Morceaux durs<\/strong>: Trop de professionnels de l'informatique ont une compr\u00e9hension limit\u00e9e de la valeur. Ils utilisent un raccourci rapide qui exprime la valeur en termes de prestation. Or, la valeur est \u00e9vidente dans la prestation.<\/p>\n Dans un monde complexe, la moindre livraison peut d\u00e9grader la valeur. Prenons l'exemple simple des fonctionnalit\u00e9s destin\u00e9es \u00e0 des utilisateurs qui ne sont pas des clients cibles. Ou encore, lorsqu'une unit\u00e9 de travail demande des fonctionnalit\u00e9s simplifiant son activit\u00e9 au d\u00e9triment du syst\u00e8me.<\/p>\n Nous recommandons vivement l'adoption des principes fondamentaux du Lean et du Six Sigma. Approfondissez la d\u00e9finition et la quantification de la valeur. Recherchez l'optimisation locale. Les concepts de client cible et de proposition de valeur du Business Model Canvas sont tr\u00e8s utiles.<\/p>\n Dans Phase E de TOGAF<\/a>, Il existe une \u00e9tape int\u00e9ressante. Examinez le lot de travaux et choisissez une strat\u00e9gie appropri\u00e9e\u00a0: Greenfield, \u00c9volutionnaire ou R\u00e9volutionnaire. Pr\u00e9voyez-vous de pr\u00e9server au maximum l\u2019existant, de proc\u00e9der \u00e0 une refonte radicale ou de repartir de z\u00e9ro\u00a0?<\/p>\n Cela se fait dans le cadre de la planification du portefeuille de produits et de l'\u00e9cosyst\u00e8me. Il s'agit d'une orientation essentielle et d'une contrainte forte pour une \u00e9quipe agile. Leur demandez-vous de partir de z\u00e9ro (Greenfield)\u00a0? D'am\u00e9liorer progressivement les syst\u00e8mes existants (\u00e9volution)\u00a0? Ou d'op\u00e9rer un changement radical cens\u00e9 \u00e9liminer les frictions et les tracas auxquels nous sommes confront\u00e9s (r\u00e9volution)\u00a0?<\/p>\n Probl\u00e8me pr\u00e9visible<\/strong>:Assurer que la strat\u00e9gie de mise en \u0153uvre est suivie.<\/p>\n Approche<\/strong>:Utilisez la feuille de route du produit et les cycles de publication pour appliquer des changements radicaux d\u2019approche.<\/p>\n Morceau dur<\/strong>Aligner les changements d'architecture descendante sur la feuille de route produit. Cette t\u00e2che est particuli\u00e8rement difficile lorsque les d\u00e9cisions visant \u00e0 soutenir la strat\u00e9gie ou le portefeuille n\u00e9cessitent une modification de l'approche produit. Nous avons d\u00fb consacrer beaucoup de temps \u00e0 rassurer les responsables produits num\u00e9riques et, par leur interm\u00e9diaire, leurs \u00e9quipes, sur le fait que les efforts d\u00e9ploy\u00e9s n'avaient pas \u00e9t\u00e9 vains.<\/p>\n Lorsqu'un produit doit s'int\u00e9grer \u00e0 un environnement d'entreprise existant ou prendre en charge un environnement en \u00e9volution, les interfaces sont essentielles. Ces interfaces sont pilot\u00e9es par les donn\u00e9es et les m\u00e9thodes. Dans un monde complexe, m\u00eame les produits \u00e9mergents ne pourront pas laisser \u00e9merger une structure de donn\u00e9es et une interface. Les donn\u00e9es de base, les donn\u00e9es de r\u00e9f\u00e9rence et les syst\u00e8mes existants freineront le d\u00e9veloppement agile.<\/p>\n Les syst\u00e8mes existants ne changeront pas. L'investissement est ax\u00e9 sur de nouveaux syst\u00e8mes. C'est le nouveau syst\u00e8me qui doit s'int\u00e9grer. M\u00eame le F-22 Raptor a d\u00fb se connecter \u00e0 des syst\u00e8mes existants gr\u00e2ce \u00e0 des interfaces d\u00e9velopp\u00e9es dans les ann\u00e9es 1970. M\u00eame un avion aussi co\u00fbteux ne pouvait b\u00e9n\u00e9ficier de la modernisation de ses syst\u00e8mes existants.<\/p>\n Probl\u00e8me pr\u00e9visible<\/strong>:Identifier les interfaces requises et s\u2019assurer qu\u2019elles sont utilis\u00e9es.<\/p>\n Approche<\/strong>: Concentrez le travail descendant sur les interfaces et les structures de donn\u00e9es partag\u00e9es. Int\u00e9grez les exigences aux cycles d'\u00e9pop\u00e9e et de publication. Utilisez des crit\u00e8res d'acceptation. Nous avons souvent utilis\u00e9 Mod\u00e8les d'architecture d'application<\/a> et Mod\u00e8les d'architecture de donn\u00e9es<\/a> Pour des interfaces l\u00e9g\u00e8rement sp\u00e9cifiques. Inclure la conformit\u00e9 des interfaces dans tous les rapports de test.<\/p>\n Morceau dur<\/strong>Les interfaces constituent l'un des points o\u00f9 une planification descendante et prospective est g\u00e9n\u00e9ralement n\u00e9cessaire. Il est essentiel de garantir une infrastructure API solide, des API publi\u00e9es et des structures de donn\u00e9es pour les donn\u00e9es de base, les donn\u00e9es de r\u00e9f\u00e9rence et les enregistrements transactionnels.<\/p>\n Les \u00e9quipes produit qui \u00e9voluent rapidement n\u00e9gligent souvent la l\u00e9gislation multijuridictionnelle ou un plan d'affaires en pleine expansion. Dans ce cas, l'\u00e9quipe d'architecture d'entreprise se doit d'anticiper. En r\u00e8gle g\u00e9n\u00e9rale, nous sommes plus \u00e0 l'aise avec une refonte radicale qu'avec une planification prospective, notamment si nous avons mis en place une modularit\u00e9 et des interfaces renforc\u00e9es.<\/p>\n Les \u00e9quipes agiles et le d\u00e9veloppement ax\u00e9 sur les produits num\u00e9riques sont mal adapt\u00e9s \u00e0 la r\u00e9solution de probl\u00e8mes au sein d'un \u00e9cosyst\u00e8me ou d'un portefeuille de produits. L'approche agile repose sur la capacit\u00e9 d'une seule \u00e9quipe \u00e0 d\u00e9composer les probl\u00e8mes et \u00e0 les r\u00e9soudre directement. Il existe des concepts d'\u00e9quipes d'\u00e9quipes, mais ils peinent \u00e0 s'adapter au contexte actuel.<\/p>\n Toute \u00e9quipe d'architecture doit assumer la responsabilit\u00e9 de r\u00e9soudre les probl\u00e8mes inter-produits. Le d\u00e9veloppement agile et l'int\u00e9gration moderne rendent ce besoin plus important que jamais.<\/p>\n Probl\u00e8me pr\u00e9visible<\/strong>:Un conflit au sein du portefeuille de produits num\u00e9riques bloque la progression de plusieurs produits.<\/p>\n Approche<\/strong>:Utilisez les techniques d\u2019architecture d\u2019entreprise pour trouver les changements minimaux permettant de progresser.<\/p>\n Morceaux durs<\/strong>Le d\u00e9fi le plus crucial est le timing. Des \u00e9quipes de d\u00e9veloppement agiles et cr\u00e9atives, appliquant les meilleures pratiques, s'efforceront de r\u00e9soudre le probl\u00e8me. Lorsque le probl\u00e8me surgit, il constitue g\u00e9n\u00e9ralement un obstacle majeur, avec une dette technique importante.<\/p>\n L\u2019\u00e9quipe EA devra se concentrer sur les \u00e9tats de transition progressifs pour permettre des progr\u00e8s dans l\u2019ensemble du portefeuille de produits.<\/p>\n Probl\u00e8me pr\u00e9visible<\/strong>:Identifier la v\u00e9ritable partie prenante qui peut fournir une orientation et une approbation sur un portefeuille de produits interne complexe.<\/p>\n Approche<\/strong>: Utiliser des techniques d'architecture d'entreprise pour identifier les parties prenantes et leurs agents, leurs pr\u00e9occupations et leurs pr\u00e9f\u00e9rences. Utiliser des techniques d'architecture d'entreprise de alternatives<\/a> et compromis<\/a> Guider les parties prenantes vers une d\u00e9cision qui orientera le portefeuille de produits. Assurer une gouvernance efficace du portefeuille num\u00e9rique.<\/p>\n Morceaux durs<\/strong>On peut s'attendre \u00e0 ce que les \u00e9quipes de produits num\u00e9riques disposent de sources d'autorit\u00e9 locales et d'un mod\u00e8le simplifi\u00e9 de prise de d\u00e9cision et d'autorit\u00e9 d\u00e9cisionnelle. De plus, leur communication et leur \u00e9valuation seront orient\u00e9es vers les technologies de l'information et la strat\u00e9gie.<\/p>\n L'\u00e9quipe d'architecture d'entreprise devra veiller \u00e0 une gouvernance efficace de l'ensemble du portefeuille num\u00e9rique et collaborer avec les instances d\u00e9cisionnelles en charge des produits num\u00e9riques. Par ailleurs, les \u00e9quipes d'architecture d'entreprise ne disposent pas de comp\u00e9tences particuli\u00e8res pour mobiliser les parties prenantes. Elles peuvent en revanche repr\u00e9senter leurs pr\u00e9occupations gr\u00e2ce \u00e0 une architecture de qualit\u00e9 sup\u00e9rieure.<\/p>\n Probl\u00e8me pr\u00e9visible<\/strong>:Les d\u00e9cisions tactiques optimis\u00e9es localement ne peuvent pas \u00e9merger comme un \u00e9cosyst\u00e8me num\u00e9rique efficace et durable.<\/p>\n Approche<\/strong>:Maintenir juste assez Architecture d'application<\/a> et Architecture des donn\u00e9es<\/a>. Orienter les priorit\u00e9s organisationnelles dans cette architecture. L'architecture applicative doit \u00eatre ax\u00e9e sur les services et interfaces partag\u00e9s. L'architecture des donn\u00e9es doit se concentrer sur les donn\u00e9es ma\u00eetres, les donn\u00e9es de r\u00e9f\u00e9rence et les donn\u00e9es hautement classifi\u00e9es. Exiger des descriptions de m\u00e9tadonn\u00e9es. Utiliser des mod\u00e8les d'architecture sp\u00e9cifiant l'approche \u00e9cosyst\u00e9mique.<\/p>\n Morceaux durs<\/strong>La gestion transversale du portefeuille exige de concilier deux r\u00e9alit\u00e9s contradictoires. Premi\u00e8rement, l'approche agile est n\u00e9e de l'\u00e9chec observ\u00e9 d'une conception d'entreprise descendante d\u00e9taill\u00e9e. Deuxi\u00e8mement, les solutions optimis\u00e9es localement \u00e9mergentes ne permettent pas de construire des syst\u00e8mes complexes et performants sans une forte pression \u00e9volutive et du temps pour \u00e9voluer.<\/p>\n La seule approche \u00e9volutive est \u2018juste assez<\/em>.\u2019\u00a0Juste ce qu\u2019il faut\u00a0\u00bb signifie respecter les priorit\u00e9s de l\u2019organisation et \u00e9viter les probl\u00e8mes pr\u00e9visibles. Par exemple, si la priorit\u00e9 de votre organisation est la durabilit\u00e9, l\u2019architecture de votre application doit privil\u00e9gier la modularit\u00e9 et l\u2019utilisation d\u2019une infrastructure d\u2019isolation comme une passerelle API.<\/p>\n Il faut juste rester en dehors de la conception du produit. Il faut plut\u00f4t utiliser des mod\u00e8les d'architecture performants pour l'ensemble du portefeuille.<\/p>\n Le juste n\u00e9cessaire revient \u00e0 ignorer les synergies potentielles. Il est fr\u00e9quent que les efforts visant \u00e0 imaginer un avenir complexe tournent \u00e0 la farce. La synergie est la chose la plus difficile \u00e0 trouver. Tous nos travaux sur les feuilles de route d'architecture d\u00e9montrent que l'on paie toujours la facture pour quelque chose, et l'on peut en tirer un b\u00e9n\u00e9fice. La valeur de la synergie est faible en cas d'incertitude.<\/p>\n Juste assez signifie se concentrer sur les probl\u00e8mes pr\u00e9visibles. Personne n'a jamais construit de base de donn\u00e9es clients distribu\u00e9e sans donn\u00e9es de r\u00e9f\u00e9rence. Jamais. C'est un probl\u00e8me de donn\u00e9es pr\u00e9visibles. R\u00e9solvez-le rapidement. \u00c9viter les probl\u00e8mes pr\u00e9visibles a un grand int\u00e9r\u00eat.<\/p>\n Juste assez signifie ne pas craindre d'utiliser les forces du march\u00e9 et la destruction cr\u00e9atrice. Nous utilisons un concept de cycle de vie attendu pour identifier les secteurs de l'\u00e9cosyst\u00e8me o\u00f9 nous pr\u00e9voyons de proc\u00e9der r\u00e9guli\u00e8rement \u00e0 des refactorisations agressives (approches greenfield et r\u00e9volutionnaires).<\/p>\n Probl\u00e8me pr\u00e9visible<\/strong>:Une architecture juste suffisante signifie que chaque \u00e9ventualit\u00e9, chaque contrainte, chaque conflit, n'a pas \u00e9t\u00e9 d\u00e9couvert avant la sortie.<\/p>\n Approche<\/strong>Gardez les mains dans vos poches et attendez d'\u00eatre appel\u00e9 lors de la r\u00e9solution. Sauf appel, attendez d'intervenir pendant l'analyse de l'incident pour identifier o\u00f9 vous avez omis d'identifier un probl\u00e8me pr\u00e9visible, sous-estim\u00e9 un risque ou manqu\u00e9 une exigence de test.<\/p>\n Morceaux durs<\/strong>Il existe un cas o\u00f9 une \u00e9quipe d'architecture peut se trouver en situation d'urgence\u00a0: celui o\u00f9 les cons\u00e9quences d\u00e9passent le cadre du produit. Si les utilisateurs finaux contournent le probl\u00e8me, il n'y a pas d'urgence. En revanche, s'ils cr\u00e9ent une vuln\u00e9rabilit\u00e9 et engagent la responsabilit\u00e9 des utilisateurs, il y a urgence.<\/p>\nComprendre l'architecture d'entreprise et Agile<\/h2>\n
\n
![\"architecture](\"https:\/\/conexiam.com\/wp-content\/uploads\/2023\/09\/AdobeStock_437654262.jpeg\" "\\"architecture")
\n\t\t\t\n\t\t\t\t\t\t\tContactez-nous pour obtenir notre conseil en architecture d'entreprise pour vous aider\n\t\t\t<\/a>\n\tComment l\u2019architecture d\u2019entreprise et l\u2019Agile s\u2019articulent-elles ?<\/h2>\n
\n
![\"Architecture](\"https:\/\/conexiam.com\/wp-content\/uploads\/2020\/05\/EA-supporting-Agile-Development-Work-Product-600x408.png\" "\\"Architecture")
\n\tComment utiliser ces mod\u00e8les d\u2019engagement\u00a0?<\/h2>\n
\n
Exemple pratique\u00a0: D\u00e9veloppement agile sur la feuille de route de l'architecture d'entreprise<\/strong><\/h3>\n
\n
\n<\/em><\/strong>490 b\u00e2tisseurs de ponts qui pensaient apporter de la valeur<\/em><\/strong>\n
\n\t\t\t\n\t\t\t\t\t\t\tFormation personnalis\u00e9e en architecture d'entreprise pour dynamiser votre \u00e9quipe\n\t\t\t<\/a>\n\tT\u00e9l\u00e9chargements et exemples d'architecture d'entreprise<\/a><\/h2>\n\t
Architecture d'entreprise et agilit\u00e9 \u2013 D\u00e9finir l'approche agile<\/h2>\n
Mod\u00e8le de produit<\/h3>\n
Mod\u00e8le de plate-forme<\/h3>\n
\n
\n
Mod\u00e8le de strat\u00e9gie de prestation de services<\/h3>\n
Mod\u00e8le de point de repos de valeur majeure<\/h3>\n
\n
\n
\nIl s'agit d'une discussion sur le retour sur investissement (ROI). Les discussions sur le ROI conduisent g\u00e9n\u00e9ralement \u00e0 un changement de priorit\u00e9.<\/li>\n\n
\n
Allez plus loin avec les meilleures pratiques en mati\u00e8re de processus et de m\u00e9thodes d'architecture d'entreprise<\/h2>\n
Architecture d'entreprise et Agile \u2013 Guide du backlog dans le sprint<\/h2>\n
Feuille de route pour guider le mod\u00e8le de produit<\/h3>\n
\n
\n
Feuille de route pour guider le mod\u00e8le Epic<\/h3>\n
Mod\u00e8le de valeur d'entreprise<\/h3>\n
Limiter le mod\u00e8le de propri\u00e9taire de produit \u2018\u00a0ascendant\u00a0\u2019<\/h3>\n
\n
\n
![\"Architecture](\"https:\/\/conexiam.com\/wp-content\/uploads\/2020\/05\/EA-supporting-Agile-Development-Work-Product.png\" "\\"Comprendre")
<\/p>\n\t\t\t\n\t\t\t\t\t\t\tT\u00e9l\u00e9chargez le guide pratique pour le d\u00e9veloppement d'une architecture d'entreprise\n\t\t\t<\/a>\n\tFormation en architecture d'entreprise et formation TOGAF<\/h2>\n\t
Architecture d'entreprise et agilit\u00e9 \u2013 Limiter les sprints<\/h2>\n
\nIl y a une r\u00e8gle de base<\/strong><\/em>: ne supprimez jamais un degr\u00e9 de libert\u00e9 si ce n'est pas n\u00e9cessaire.
\nLa libert\u00e9 d'innover et de cr\u00e9er est l'\u00e9l\u00e9ment vital du d\u00e9veloppement logiciel agile<\/em>\nIl existe une r\u00e8gle avanc\u00e9e<\/strong>:n'ayez jamais peur de donner \u00e0 une \u00e9quipe agile un probl\u00e8me vraiment difficile
\nL'innovation et la cr\u00e9ativit\u00e9 cr\u00e9eront des solutions que vous ne pouvez pas imaginer<\/em>\n
\nMod\u00e8le de crit\u00e8res d'acceptation<\/h3>\n
\n
\n
Valeur (mesures et points de repos) Mod\u00e8le<\/h3>\n
Greenfield, \u00e9volution ou r\u00e9volution<\/a><\/h3>\n
Contraindre les mod\u00e8les d'interface<\/h3>\n
<\/p>\n\t\t\t\n\t\t\t\t\t\t\tT\u00e9l\u00e9chargez le Guide de gouvernance de l'architecture d'entreprise\n\t\t\t<\/a>\n\tArchitecture d'entreprise et Agile \u2013 R\u00e9soudre les d\u00e9pendances<\/h2>\n
D\u00e9bloquer le mod\u00e8le de portefeuille<\/h3>\n
Identifier les v\u00e9ritables mod\u00e8les de parties prenantes<\/h3>\n
Croiser le mod\u00e8le de portefeuille<\/h3>\n
Mod\u00e8le d'impact de la version<\/h3>\n