Comprendre l'architecture d'entreprise et Agile
Comment l’architecture d’entreprise et l’Agile s’articulent-elles ?
Architecture d'entreprise et Agile - Définir l'approche Agile
Architecture d'entreprise et Agile - Guide du backlog en Sprint
Architecture d'entreprise et Agile - Contraindre les sprints
Architecture d'entreprise et Agile - Résoudre les dépendances
Comment l’architecture d’entreprise et l’Agile s’articulent-elles ?
L'architecture d'entreprise et l'agilité s'intègrent de manière inattendue. La méthode agile est au cœur de nos préoccupations actuelles : les étapes de création de logiciels d'expédition viables. De ce point de vue, la question est de savoir quel est le rôle de l'architecture d'entreprise aujourd'hui ? Comment accélérer l'expédition des logiciels ?
L'architecture d'entreprise et l'agilité ne s'intègrent pas au sein du sprint. Elles s'intègrent en dehors du cycle de développement. Elles s'intègrent grâce aux architectes d'entreprise et aux développeurs agiles dans l'exercice de leurs fonctions. Les équipes d'architecture d'entreprise performantes respectent leurs engagements. cas d'utilisation. Ils ne tiennent aucun autre engagement. Même s'ils le pouvaient.
Nous disposons d'une architecture d'entreprise simple et d'un modèle de référence agile. Il existe quatre principaux modèles d'engagement en matière d'architecture d'entreprise :
- définir l'approche agile
- guider le backlog dans le sprint
- contraindre les sprints agiles
- résolution de la dépendance du produit vectoriel
Au cours des dernières années, j'ai travaillé sur Transformation numérique initiatives, nous avons développé un ensemble de modèles d’engagement.
Comment utiliser ces modèles d’engagement ?
Commencez par analyser votre cas d'utilisation d'AE. Quels conseils êtes-vous censé fournir ? À qui vous adressez-vous ? Ensuite, examinez les modèles d'engagement qui répondent à vos défis professionnels. Intégrez-les à vos interactions.
Notre modèle de modèle d'architecture comporte deux éléments clés : le problème prévisible et le approche pour résoudre le problème. Nous recueillons également les morceaux durs. Lorsque nous examinons un modèle, nous examinons dans quelle mesure il résout le problème et la quantité de travail supplémentaire nécessaire pour appliquer le modèle avec succès.
Examinons les modèles d'engagement : le problème qu'ils résolvent, l'approche et les aspects difficiles.
- définir l'approche agile
- guider le backlog dans le sprint
- contraindre les sprints agiles
- résolution de la dépendance du produit vectoriel
Exemple pratique : Développement agile sur la feuille de route de l'architecture d'entreprise
J'ai eu une conversation amusante avec l'ingénieure en fiabilité des systèmes nouvellement embauchée. La spécialiste SRE était ravie. Nous avons enfin mis en place des pratiques modernes : CI/CD et tests automatisés. Elle m'a demandé ce que l'équipe EA faisait pour nous aider.
J'ai dû sourire quand elle a demandé : ‘que fait l'équipe EA pour aider ?’ Ce qu'elle voulait vraiment dire, c'est : ‘que fais-tu pour me soutenir aujourd'hui ?’Aujourd'hui, concernant ses défis immédiats, rien. Elle était impliquée dans la mise en œuvre. Elle observait les évolutions en termes de mise en œuvre.
Elle ne comprenait pas comment l'organisation se développait. Elle n'était pas au courant de la feuille de route du portefeuille. La feuille de route comportait un point de transition que nous venions d'atteindre. Nous avions introduit des conteneurs, la gestion des données de test et une suite de tests automatisés peu performante. Elle ne réalisait pas que la planification descendante à l'ancienne avait créé les conditions nécessaires à son nouveau poste.
Elle pensait au développement immédiat. Je pensais à l'ensemble transformation numérique. Son rôle consistait à aider l'organisation à traverser la prochaine transition. Elle développait capacités critiques. Les tests automatisés devaient fournir la preuve du respect des contraintes d'architecture. Je passais de définir l'approche agile. J'avais besoin d'aide pour guider l'arriéré.
Dix ponts et routes de liaison valent plus que 500 demi-ponts qui ne mènent nulle part
490 constructeurs de ponts seront mécontents
490 bâtisseurs de ponts qui pensaient apporter de la valeur
Conversations sur le plan de jeu de l'IA agentique
Conversations autour du guide pratique de l'IA agentique : Nous nous sommes pleinement investis dans l'évolution du paysage de l'adoption de l'IA, en abordant à la fois les complexités techniques et la transformation numérique au sens large. Nous avons élaboré le Guide du dirigeant d'entreprise […]
Télécharger l'architecture de référence des capacités critiques d'adoption de l'IA
Téléchargez l'architecture de référence des capacités critiques pour l'adoption de l'IA. L'adoption de l'IA exige une réflexion novatrice. Aujourd'hui, nous ne disposons pas de bonnes pratiques éprouvées pour une adoption généralisée de l'IA qui améliorent systématiquement nos organisations. Nous devons être capables de repenser notre […]
Téléchargez le guide du chef d'entreprise sur l'IA
Téléchargez le Guide du chef d'entreprise sur l'intelligence artificielle. Les organisations qui utilisent avec succès des technologies innovantes bénéficient d'un avantage concurrentiel. Une technologie innovante ne s'accompagne pas de modèles de réussite établis ni de bonnes pratiques. Une technologie innovante est nouvelle et […]
Téléchargez l'introduction à la norme TOGAF, 10e édition
Téléchargez l'introduction à la norme TOGAF®, 10e édition. La norme TOGAF, 10e édition, facilite l'adoption des meilleures pratiques d'architecture d'entreprise. Elle distingue les concepts universels des meilleures pratiques éprouvées. La norme souligne où […]
Télécharger le guide de planification basé sur les capacités
Téléchargez le guide de planification basée sur les capacités. Cherchez toujours à créer de la valeur. Une demi-amélioration, c'est 100% de gaspillage ! 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 d'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 par les capacités est l'une des techniques d'amélioration de l'architecture métier les plus efficaces. Les bonnes pratiques de planification par les capacités utilisent les capacités comme un outil de gestion.
Télécharger un exemple de principes d'architecture d'entreprise
Téléchargez un exemple de principes d'architecture d'entreprise. Ces principes identifient la manière d'aborder un problème ou une décision. Cette approche vous guide toujours vers vos priorités. Téléchargez un exemple 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 permettant de piloter et de contrôler le développement de l'architecture, ainsi que les modifications nécessaires pour obtenir les résultats escomptés. Téléchargez le Guide de gouvernance de l'architecture d'entreprise […]
Télécharger l'intégration TOGAF et SABSA
Téléchargez l'intégration TOGAF et SABSA. Associez SABSA, le meilleur framework d'architecture de sécurité au monde, et TOGAF, le framework d'architecture d'entreprise standard du secteur. Téléchargez l'intégration TOGAF et SABSA. L'intégration TOGAF et SABSA inclut : SABSA utilise […]
Télécharger l'architecture de référence des capacités d'architecture d'entreprise
Téléchargez l'architecture de référence des capacités d'architecture d'entreprise. Cette architecture accélérera la mise en place et le développement de votre équipe d'architecture d'entreprise. Concevez votre équipe d'architecture d'entreprise pour réussir. Identifiez et améliorez votre architecture d'entreprise […]
Architecture d'entreprise et Agile - Définir l'approche Agile
Agile est un choix. Il présente des avantages et des inconvénients. Adopter Agile nécessite des choix concernant le produit, la plateforme, la stratégie de prestation de services et les points de transition descendants.
Une équipe EA doit avoir la capacité de soutenir Stratégie et Portefeuille à définir l'approche agile.
Problème prévisible:Quand utilisez-vous Agile ?
Modèle de produit
Les produits externes sont plus faciles à gérer que les produits internes. En bref, il existe un marché. En interne, l'utilisation de l'agilité transforme le système interne en produits numériques. Il est nécessaire de déterminer l'existence, le périmètre et l'approche de développement des systèmes internes.
Problème prévisible:D'où vient le produit ?
Approche: Ajuster la définition des ‘ solutions ’ utilisées pour combler les lacunes et les résultats des lots de travaux afin de les aligner sur les produits autonomes. Développer un portefeuille de produits internes et un ensemble de mesures de valeur pour ces produits. Les produits devraient apparaître sur la feuille de route architecturale.
Modèle de plate-forme
Les plateformes peuvent améliorer la vitesse de développement et la durabilité. Cependant, une plateforme mal choisie aura l'effet inverse. Ce n'est pas à une équipe agile de choisir d'utiliser une plateforme, et encore moins de choisir laquelle. Nous avons utilisé le terme plateforme pour désigner SAP, M365, Facebook, Pega ou même Open Shift Containers.
Architectures de référence jouent un rôle essentiel dans la définition, la sélection et gouvernant l'utilisation des plateformes.
Problème prévisible:Quand faut-il utiliser une plateforme et quand faut-il que le produit soit sans contrainte ?
Approche:Approches multiples
-
- Utiliser une architecture alternative pour sélectionner. Les principales préoccupations seront la confiance, la durabilité, les délais de commercialisation et la continuité des activités.
- Utiliser la plateforme architecture de référence pour garantir l'exhaustivité de la conception du produit et évaluer le comblement de toutes les lacunes
Morceaux durs:Question de support et de pérennité du produit et de la plateforme.
Modèle de stratégie de prestation de services
Une stratégie de prestation de services désigne l'approche utilisée par les organisations pour fournir des produits ou des services. Il n'est pas certain que vous choisirez votre approche actuelle : interne, contractuelle, renforcement des effectifs.
Problème prévisible:Comment votre organisation va-t-elle assurer un développement agile ?
Approche:Suivez les approches de l'architecture pour soutenir la stratégie. Posez la question de savoir comment le développement agile sera rendu possible. Utilisez un Modèle opérationnel pour définir la valeur et une Organigramme définir comment les différents consommateurs, développeurs et opérateurs d’un produit travailleront ensemble.
Modèle de point de repos de valeur majeure
Le développement agile est tout aussi susceptible que toute autre approche de savoir quand s'arrêter. 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 :
-
- Lorsque l’effort pour atteindre le prochain point de repos dépasse la valeur incrémentale.
Il s'agit d'une discussion sur le retour sur investissement (ROI). Les discussions sur le ROI conduisent généralement à un changement de priorité. - Lorsque le même effort peut être utilisé pour atteindre un résultat plus précieux
- Lorsque les priorités organisationnelles ont changé (gouvernance)
- Lorsqu'il y a une menace ou une opportunité inattendue (agilité de l'entreprise)
- Lorsque l’effort pour atteindre le prochain point de repos dépasse la valeur incrémentale.
Problème prévisible:Connaître le point de repos de la valeur pour arrêter ou changer de focus
ApprocheUtiliser des feuilles de route d'architecture pour explorer d'autres points de création de valeur. Créer des rapports sur l'activité vers les états de transition.
Morceaux dursLes considérations incluent la valeur comparative au repos et la valeur potentielle comme tremplin pour d'autres activités. Les implémenteurs comprennent rarement ces conversations. Ils s'investissent émotionnellement 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 à suivre, et non le rendement potentiel le plus élevé. Ils recherchent la meilleure voie.
L'exploration des points de repos de la valeur constitue la première étape. Les décideurs doivent comprendre les options (sélection selon différents critères et report des décisions incertaines). Ensuite, ils doivent identifier les moyens d'atteindre les différents points de repos de la valeur sélectionnés.
-
- Quel changement rechercher compte tenu des différents critères ?Feuille de route architecturale de type 4 : scénarios
- Quel travail apportera de la valeur, et quel en sera le coût et l’incertitude ?Feuille de route architecturale de type 1 : carte thermique
- Quelles décisions sont différées ?Feuille de route architecturale de type 4 : scénarios
- Quand la valeur sera-t-elle délivrée ?États en transition
Allez plus loin avec les meilleures pratiques en matière de processus et de méthodes d'architecture d'entreprise
Meilleures pratiques architecture d'entreprise depuis Conexiam Naviguer
Tout ce que vous devez savoir sur l'utilisation des alternatives architecturales
Tout ce que vous devez savoir sur l'utilisation d'alternatives d'architecture. Les alternatives d'architecture sont indispensables au bon développement d'une architecture d'entreprise. Lorsque vous démarrez le développement d'une architecture, votre entreprise présente des faiblesses. Des points restent à améliorer. Vous devez […]
Faire des choix plus intelligents : pourquoi votre entreprise a besoin de décisions architecturales
Faire des choix plus judicieux : 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, notamment en matière de pratiques opérationnelles et de choix technologiques, ont un impact significatif sur […]
Développer une vue d'architecture
Développer une vision architecturale. L'architecture d'entreprise est une boussole essentielle. Elle aide les organisations à naviguer dans les complexités de la technologie, de la stratégie et des opérations. L'architecture d'entreprise repose sur une approche systématique. L'objectif est de garantir […]
Comment définir les principes de l'architecture d'entreprise
Comment définir les principes d'architecture d'entreprise ? Pour définir les principes d'architecture d'entreprise, il faut commencer par comprendre ce qu'est un principe et comment l'appliquer. Nous pourrons ensuite élaborer des principes d'architecture solides qui contribueront à améliorer notre organisation. […]
Comparaison des cadres d’architecture d’entreprise : lequel vous convient le mieux ?
Comparaison des frameworks d'architecture d'entreprise : lequel vous convient le mieux ? Il n'existe pas de solution universelle en entreprise, ni en matière de frameworks d'architecture d'entreprise. Comparez les avantages des frameworks les plus répandus pour déterminer celui optimisé qui vous convient le mieux. […]
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 pouvons atteindre un futur plausible et comment différents scénarios influencent nos choix actuels. Les scénarios aident les dirigeants […]
Comprendre l'architecture d'entreprise et Agile
Comprendre l'architecture d'entreprise et l'agilité. L'agilité et l'architecture d'entreprise visent toutes deux à réduire les risques. Le développement logiciel agile excelle à créer des solutions inédites et insaisissables. […]
Création d'un comité d'évaluation de l'architecture moderne
Mise en place d'un comité d'évaluation d'architecture moderne : la mise en place d'un comité d'évaluation d'architecture moderne nécessite la mise en place d'un processus de gouvernance dynamique et la création d'un organe décisionnel de haut niveau. L'objectif est d'instaurer une gouvernance architecturale efficace et sans bureaucratie. […]
Libérez le potentiel de votre entreprise : comment créer une cartographie des capacités efficace
Libérer le potentiel de votre entreprise : Comment créer une cartographie des capacités efficace ? Vous avez du mal à identifier les compétences nécessaires pour propulser votre entreprise vers le niveau supérieur ? Trouvez-vous difficile d’aligner les ressources […]
Meilleures pratiques pour mettre en œuvre des outils de gestion de l'architecture d'entreprise
Bonnes pratiques pour la mise en œuvre d'outils de gestion de l'architecture d'entreprise. Ces outils sont conçus pour soutenir la planification, la conception, l'analyse et la mise en œuvre de l'architecture d'entreprise. Ils permettent aux architectes d'entreprise d'évaluer les besoins de changement […]
Architecture d'entreprise et Agile - Guide du backlog en Sprint
Les équipes agiles performantes trouvent la voie la plus efficace. La planification et la budgétisation à long terme sont nécessaires en raison de la complexité de l'écosystème. Le défi consiste à concilier planification à long terme et créativité agile. Il s'agit de concilier planification descendante et exécution ascendante.
Il faut leur expliquer les priorités organisationnelles dans des termes qui peuvent être intégrés à la gestion des arriérés.
L'agilité 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é dans les délais et les ressources limités, aucun travail ne devrait être entrepris.
Une équipe EA doit avoir la capacité de soutenir Portefeuille et projet à guide du backlog dans le sprint.
Problème prévisible:Assurer que les résultats attendus, la valeur, les attentes en matière de performances en cascade et les contraintes guident la publication et le développement du produit.
Morceau durTrop d'évangélistes agiles s'étonnent que les organisations adoptant l'agilité restent profondément attachées à la planification et à la budgétisation à long terme. Il nous faut souvent surmonter l'idée reçue selon laquelle il existe une préférence culturelle pour la méthode en cascade.
Feuille de route pour guider le modèle de produit
Problème prévisible:Avoir une feuille de route produit complète, au lieu d'un cycle de publication de fonctionnalités.
Approche: En utilisant un technique de feuille de route architecturale Où le produit, ou la famille de produits, remplace le portefeuille. Veiller à ce que les rapports habituels sur les produits incluent l'activité vers les états de transition.
Morceaux dursUne excellente gestion de produit permettra d'établir une feuille de route complète. Trop de responsables produits ascendants manquent d'expérience en gestion du cycle de vie ou de l'intégration d'une suite de produits intégrée. L'équipe d'architecture d'entreprise devra prendre le relais, ou se replier sur elle-même, en fonction des compétences de l'organisation produit.
Trop d'équipes d'architecture tombent dans le piège de la précision artificielle ou de l'omniscience imaginaire. Ce sont deux façons sophistiquées de parler de « pensée en cascade ». Une feuille de route d'architecture classique parlera de transitions, d'écarts et de lots de travaux. Cela sera incompréhensible pour une équipe produit. Adoptez un langage produit et agile. Le responsable produit doit comprendre les contraintes auxquelles il est soumis.
L'élaboration de la feuille de route nécessite une architecture suffisante. La seule approche évolutive est ‘juste assez. ’ Juste assez » signifie imposer la priorité organisationnelle et éviter les problèmes prévisibles. Juste assez signifie rester en dehors de la conception du produit. Utiliser des modèles d'architecture performants pour l'ensemble du portefeuille. Juste assez signifie ignorer les synergies potentielles. Juste assez signifie se concentrer sur les problèmes prévisibles. Éviter les problèmes prévisibles a un grand intérêt. Juste assez signifie ne pas avoir peur de recourir à la destruction créatrice. Utiliser un concept de cycle de vie attendu pour mener une refactorisation agressive (approches greenfield et révolutionnaires).
L’utilisation des techniques avec le propriétaire du produit permet d’intégrer les priorités et les contraintes organisationnelles dans la feuille de route du produit.
-
- Quel produit ou quelles fonctionnalités clés rechercher compte tenu des différents critères ? Feuille de route architecturale de type 4 : scénarios
- Quels produits ou fonctionnalités apporteront de la valeur (avantage, travail et incertitude – Feuille de route architecturale de type 1 : carte thermique
- Quand des changements de produit et de plateforme sont-ils nécessaires ? Feuille de route d'architecture de type 2 : cycle de vie
- Quelle est la dépendance et l’impact du travail et du changement – Feuille de route d'architecture de type 3 : Impact et dépendance
Feuille de route pour guider le modèle Epic
Problème prévisible:Utiliser des épopées pour implémenter des résultats et des contraintes descendants dans le produit.
Approche:Utiliser des états de transition bien construits dans un technique de feuille de route architecturale Où le produit, ou la famille de produits, remplace le portefeuille. Veiller à ce que les rapports habituels sur les produits incluent l'activité vers les états de transition.
Morceaux dursNécessite des produits étroitement intégrés ou soumis à des contraintes strictes. L'accent doit être mis sur l'intégration ou les points de contrainte. La coexistence de plusieurs produits au sein d'un écosystème et le partage de données de référence en sont un exemple simple.
Il est fréquent de tomber dans le piège de la conception en amont. Il faut se concentrer sur les domaines où vos développeurs logiciels doivent limiter leur créativité en raison d'exigences liées à l'écosystème ou externes. Idéalement, cette approche devrait être mise en place en amont plutôt qu'en réaction à une dette technique.
Une fois ce projet réussi, nous avons activement adopté le langage de méthodes comme SaFE et défini la feuille de route en termes de thèmes stratégiques et de pistes d’architecture.
Modèle de valeur d'entreprise
Problème prévisible: Assurer que les facteurs critiques de succès inclus dans les états de transition et cibles guident la préparation agile du backlog et la planification épique.
ApprocheTraduire les mesures et objectifs descendants en critères exploitables pour la préparation agile du backlog. Veiller à ce que les rapports produits habituels incluent la sélection et la réalisation des activités en vue de la valeur annoncée.
Morceaux dursLes mesures descendantes doivent être définitives et faciles à évaluer. Par exemple, on ne peut pas demander à l'équipe agile de trouver un équilibre subtil entre délai de mise sur le marché et résilience. Une terminologie claire est requise.
Toute modification des mesures descendantes entraînera une certaine confusion, notamment lorsqu'un état de transition a été atteint.
Pour les produits internes, nous nous assurons toujours de disposer d'un modèle de coûts solide pour les produits numériques avant d'introduire des mesures de réduction des coûts. Sans modèle de coûts, les coûts opérationnels et de plateforme seront perdus, et tous les coûts seront justifiés par les coûts de mise en œuvre. Nous prévoyons d'aider le chef de produit interne à comprendre l'ITFM. En revanche, les chefs de produit de produits numériques externes ont généralement une très bonne compréhension des coûts.
Limiter le modèle de propriétaire de produit ‘ ascendant ’
Problème prévisible:Les propriétaires de produits qui considèrent l’ensemble de l’entreprise à travers le prisme de leur produit et de ses utilisateurs directs.
ApprocheDocumenter le produit et son rôle au sein de l'écosystème. Documenter les contraintes applicables au produit. Documenter les critères d'évaluation. S'assurer que les rapports habituels sur le produit incluent la progression vers les états de transition et les activités alignées sur la valeur de l'entreprise.
Morceaux dursLes responsables de produits numériques internes constituent souvent un maillon faible. Parmi les difficultés courantes, on compte l'incompréhension :
-
- pourquoi leur produit existe
- rôle du produit dans l'écosystème
- criticité des contraintes de l'entreprise
- qui sont les décideurs (bailleurs de fonds)
- comment obtenir des conseils sur les mesures de priorité et de valeur de l'entreprise
Les équipes d'architecture d'entreprise (EA) en charge des portefeuilles et des projets devront probablement limiter les responsables de produits ‘ bottom-up ’. Cela nécessite un effort délibéré et une affectation de personnel.
Formation en architecture d'entreprise et formation TOGAF
Cours de formation Avolution ABACUS
Formation Avolution ABACUS : une architecture d'entreprise efficace repose sur la modélisation et l'analyse formelles. Nous proposons des formations Avolution ABACUS dispensées par des architectes d'entreprise expérimentés. Les étudiants acquièrent les compétences et les connaissances nécessaires pour créer des architectures d'entreprise et de domaine intégrées dans ce domaine.
Cours de formation en architecture d'entreprise
Formation en architecture d'entreprise : une architecture d'entreprise efficace repose sur l'architecture d'entreprise. Ce cours apporte 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 de […]
Kickstart d'Enterprise Architect
Programme de démarrage rapide pour les architectes d'entreprise. Nous devons maintenir nos compétences à jour. Plus que jamais. Utilisez le programme de démarrage rapide pour l'architecture d'entreprise afin d'améliorer votre capacité à déployer une architecture d'entreprise transformatrice. Ce programme de démarrage rapide de 90 jours est la façon dont Conexiam Consulting […]
Cours de formation à l'architecture d'entreprise TOGAF
Souhaitez-vous obtenir une formation pour la certification TOGAF ? Démontrez vos connaissances en architecture d'entreprise avec la certification TOGAF. Formation TOGAF® en architecture d'entreprise. Faites un pas de géant pour devenir un meilleur architecte d'entreprise avec la norme TOGAF, 10e […]
Éducation en ligne efficace
Formation en ligne efficace : une formation en ligne efficace fonctionne. Les étudiants ont accès au meilleur instructeur disponible. Ils maîtrisent leur rythme d'apprentissage. Les enseignants peuvent partager des ressources complémentaires riches sans détourner l'attention du sujet principal. Une formation à distance efficace […]
Formation personnalisée à l'architecture d'entreprise
Formation personnalisée en architecture d'entreprise. Cette formation répond aux besoins de développement professionnel de votre équipe d'architectes d'entreprise. Les bons architectes d'entreprise utilisent un large éventail de compétences, de méthodes et une connaissance pointue du domaine pour développer l'architecture d'entreprise.
Architecture d'entreprise et Agile - Contraindre les sprints
Nous passons de l'aide à la gestion du dos à l'intégration au sprint. Il s'agit d'intégrer les spécifications d'architecture au logiciel, sans interférer avec la créativité et l'innovation de l'équipe agile.
Chaque spécification d'architecture supprime un degré de liberté. En limitant cette liberté, nous rendons plus difficile pour l'équipe agile de trouver la voie la plus efficace. Lorsque ces contraintes influencent les priorités de l'entreprise, nous facilitons la recherche de la meilleure voie.
Il y a une règle de base:ne supprimez jamais un degré de liberté si vous n'y êtes pas obligé
La liberté d'innover et de créer est l'élément vital du développement logiciel agile
Il existe une règle avancée:n'ayez jamais peur de donner à une équipe agile un problème vraiment difficile
L'innovation et la créativité créeront des solutions que vous ne pouvez pas imaginer
Problème prévisible:S'assurer que les décisions prises au cours du sprint, essentielles au succès agile, sont conscientes et orientées par les priorités, les préférences et les contraintes de l'organisation.
Morceaux dursTrouver un équilibre entre les exigences de l'entreprise et l'interférence avec la liberté de conception et d'approche requise. Ceci est particulièrement vrai pour les architectes issus du développement. L'expertise métier crée une pente glissante, allant des spécifications de l'entreprise à la conception. Cela conduit à une architecture « big-in-front » de mauvaise qualité.
Les architectes d'entreprise qui soutiennent la livraison de projets et de solutions doivent s'attendre à des contraintes de sprints. Les architectes qui se concentrent sur un écosystème ou une plateforme de produits doivent également s'attendre à collaborer avec les équipes agiles.
Modèle de critères d'acceptation
Problème prévisible:Assurer que le logiciel est conforme aux spécifications et aux normes de l'architecture d'entreprise.
Approche: Fournir des critères d'acceptation obligatoires applicables à la fin des épopées et avant leur publication. Nous avons souvent utilisé Modèles d'architecture d'application et Modèles d'architecture de données Créer des critères d'acceptation. Inclure des critères d'acceptation obligatoires dans tous les rapports de test.
Morceaux dursSavoir quand appliquer les critères d'acceptation obligatoires. Trop tôt fausse le développement. Trop tard entraîne des pressions pour des exceptions de publication. Cela est particulièrement vrai pour les produits numériques internes qui ne bénéficient pas de cycles de publication réellement prévisibles.
Nous classons nos spécifications d’architecture comme suit :
-
- principe d'architecture
- modèle d'architecture
- standard
- règle
La plupart des critères d’acceptation obligatoires doivent être des modèles d’architecture ou des normes.
N'oubliez jamais de vous écarter du chemin et de récolter la créativité.
Valeur (mesures et points de repos) Modèle
Problème prévisible:Comprendre ce qui est valorisé et comment la valeur est mesurée.
ApprocheL'architecture d'entreprise doit définir clairement la manière dont la valeur est décrite et mesurée. Les énoncés de valeur nécessitent des facteurs critiques de succès (FCS) et des mesures d'efficacité (ME). Assurez-vous que les mesures de valeur sont incluses dans les rapports sur les produits, les épopées et les versions.
Morceaux durs: Trop de professionnels de l'informatique ont une compréhension limitée de la valeur. Ils utilisent un raccourci rapide qui exprime la valeur en termes de prestation. Or, la valeur est évidente dans la prestation.
Dans un monde complexe, la moindre livraison peut dégrader la valeur. Prenons l'exemple simple des fonctionnalités destinées à des utilisateurs qui ne sont pas des clients cibles. Ou encore, lorsqu'une unité de travail demande des fonctionnalités simplifiant son activité au détriment du système.
Nous recommandons vivement les pratiques de base du Lean et du Six Sigma. Examinez la définition 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ès utiles.
Greenfield, évolution ou révolution
Dans Phase E de TOGAF, Il y a une étape intéressante. Examinez le lot de travaux et sélectionnez une stratégie appropriée : Greenfield, Évolutionnaire ou Révolutionnaire. Prévoyez-vous de préserver autant que possible, de remanier radicalement ou de repartir de zéro ?
Cela se fait dans le cadre de la planification du portefeuille de produits et de l'écosystème. Il s'agit d'une orientation essentielle et d'une contrainte forte pour une équipe agile. Leur demandez-vous de partir de zéro (Greenfield) ? D'améliorer progressivement les systèmes existants (évolution) ? Ou d'opérer un changement radical censé éliminer les frictions et les tracas auxquels nous sommes confrontés (révolution) ?
Problème prévisible:Assurer que la stratégie de mise en œuvre est suivie.
Approche:Utilisez la feuille de route du produit et les cycles de publication pour appliquer des changements radicaux d’approche.
Morceau durAligner les changements d'architecture descendante sur la feuille de route produit. Cette tâche est particulièrement difficile lorsque les décisions visant à soutenir la stratégie ou le portefeuille nécessitent une modification de l'approche produit. Nous avons dû consacrer beaucoup de temps à rassurer les responsables produits numériques et, par leur intermédiaire, leurs équipes, sur le fait que les efforts déployés n'avaient pas été vains.
Contraindre les modèles d'interface
Lorsqu'un produit doit s'intégrer à un environnement d'entreprise existant ou prendre en charge un environnement en évolution, les interfaces sont essentielles. Ces interfaces sont pilotées par les données et les méthodes. Dans un monde complexe, même les produits émergents ne pourront pas laisser émerger une structure de données et une interface. Les données de base, les données de référence et les systèmes existants freineront le développement agile.
Les systèmes existants ne changeront pas. L'investissement est axé sur de nouveaux systèmes. C'est le nouveau système qui doit s'intégrer. Même le F-22 Raptor a dû se connecter à des systèmes existants grâce à des interfaces développées dans les années 1970. Même un avion aussi coûteux ne pouvait bénéficier de la modernisation de ses systèmes existants.
Problème prévisible:Identifier les interfaces requises et s’assurer qu’elles sont utilisées.
Approche: Concentrez le travail descendant sur les interfaces et les structures de données partagées. Intégrez les exigences aux cycles d'épopée et de publication. Utilisez des critères d'acceptation. Nous avons souvent utilisé Modèles d'architecture d'application et Modèles d'architecture de données Pour des interfaces légèrement spécifiques. Inclure la conformité des interfaces dans tous les rapports de test.
Morceau durLes interfaces constituent l'un des points où une planification descendante et prospective est généralement nécessaire. Il est essentiel de garantir une infrastructure API solide, des API publiées et des structures de données pour les données de base, les données de référence et les enregistrements transactionnels.
Les équipes produit qui évoluent rapidement négligent souvent la législation multijuridictionnelle ou un plan d'affaires en pleine expansion. Dans ce cas, l'équipe d'architecture d'entreprise se doit d'anticiper. En règle générale, nous sommes plus à l'aise avec une refonte radicale qu'avec une planification prospective, notamment si nous avons mis en place une modularité et des interfaces renforcées.
Architecture d'entreprise et Agile - Résoudre les dépendances
Les équipes agiles et le développement axé sur les produits numériques sont mal adaptés à la résolution de problèmes au sein d'un écosystème ou d'un portefeuille de produits. L'approche agile repose sur la capacité d'une seule équipe à décomposer les problèmes et à les résoudre directement. Il existe des concepts d'équipes d'équipes, mais ils peinent à s'adapter au contexte actuel.
Toute équipe d'architecture doit assumer la responsabilité de résoudre les problèmes inter-produits. Le développement agile et l'intégration moderne rendent ce besoin plus important que jamais.
Débloquer le modèle de portefeuille
Problème prévisible:Un conflit au sein du portefeuille de produits numériques bloque la progression de plusieurs produits.
Approche:Utilisez les techniques d’architecture d’entreprise pour trouver les changements minimaux permettant de progresser.
Morceaux dursLe défi le plus crucial est le timing. Des équipes de développement agiles et créatives, appliquant les meilleures pratiques, s'efforceront de résoudre le problème. Lorsque le problème surgit, il constitue généralement un obstacle majeur, avec une dette technique importante.
L’équipe EA devra se concentrer sur les états de transition progressifs pour permettre des progrès dans l’ensemble du portefeuille de produits.
Identifier les véritables modèles de parties prenantes
Problème prévisible:Identifier la véritable partie prenante qui peut fournir une orientation et une approbation sur un portefeuille de produits interne complexe.
Approche: Utiliser des techniques d'architecture d'entreprise pour identifier les parties prenantes et leurs agents, leurs préoccupations et leurs préférences. Utiliser des techniques d'architecture d'entreprise de alternatives et compromis Guider les parties prenantes vers une décision qui orientera le portefeuille de produits. Assurer une gouvernance efficace du portefeuille numérique.
Morceaux dursOn peut s'attendre à ce que les équipes de produits numériques disposent de sources d'autorité locales et d'un modèle simplifié de prise de décision et d'autorité décisionnelle. De plus, leur communication et leur évaluation seront orientées vers les technologies de l'information et la stratégie.
L'équipe d'architecture d'entreprise devra veiller à ce qu'une gouvernance efficace soit mise en place au sein du portefeuille numérique et s'articule avec les structures d'autorité des produits numériques. De plus, les équipes d'architecture d'entreprise ne disposent pas de compétences spécifiques pour mobiliser les parties prenantes. Elles peuvent toutefois représenter leurs préoccupations grâce à une architecture performante.
Croiser le modèle de portefeuille
Problème prévisible:Les décisions tactiques optimisées localement ne peuvent pas émerger comme un écosystème numérique efficace et durable.
Approche:Maintenir juste assez Architecture d'application et Architecture des données. Orienter les priorités organisationnelles dans cette architecture. L'architecture applicative doit être axée sur les services et interfaces partagés. L'architecture des données doit se concentrer sur les données maîtres, les données de référence et les données hautement classifiées. Exiger des descriptions de métadonnées. Utiliser des modèles d'architecture spécifiant l'approche écosystémique.
Morceaux dursLa gestion transversale du portefeuille exige de concilier deux réalités contradictoires. Premièrement, l'approche agile est née de l'échec observé d'une conception d'entreprise descendante détaillée. Deuxièmement, les solutions optimisées localement émergentes ne permettent pas de construire des systèmes complexes et performants sans une forte pression évolutive et du temps pour évoluer.
La seule approche évolutive est ‘juste assez. ’ Juste suffisant » signifie respecter la priorité organisationnelle et éviter les problèmes prévisibles. Par exemple, si votre priorité organisationnelle est la durabilité, votre architecture applicative doit privilégier la modularité et l'utilisation d'une infrastructure d'isolation comme une passerelle API.
Il faut juste rester en dehors de la conception du produit. Il faut plutôt utiliser des modèles d'architecture performants pour l'ensemble du portefeuille.
Le juste nécessaire revient à ignorer les synergies potentielles. Il est fréquent que les efforts visant à imaginer un avenir complexe tournent à la farce. La synergie est la chose la plus difficile à trouver. Tous nos travaux sur les feuilles de route d'architecture démontrent que l'on paie toujours la facture pour quelque chose, et l'on peut en tirer un bénéfice. La valeur de la synergie est faible en cas d'incertitude.
Juste assez signifie se concentrer sur les problèmes prévisibles. Personne n'a jamais construit de base de données clients distribuée sans données de référence. Jamais. C'est un problème de données prévisibles. Résolvez-le rapidement. Éviter les problèmes prévisibles a un grand intérêt.
Juste assez signifie ne pas craindre d'utiliser les forces du marché et la destruction créatrice. Nous utilisons un concept de cycle de vie attendu pour identifier les secteurs de l'écosystème où nous prévoyons de procéder régulièrement à des refactorisations agressives (approches greenfield et révolutionnaires).
Modèle d'impact de la version
Problème prévisible:Une architecture juste suffisante signifie que chaque éventualité, chaque contrainte, chaque conflit, n'a pas été découvert avant la sortie.
ApprocheGardez les mains dans vos poches et attendez d'être appelé lors de la résolution. Sauf appel, attendez d'intervenir pendant l'analyse de l'incident pour identifier où vous avez omis d'identifier un problème prévisible, sous-estimé un risque ou manqué une exigence de test.
Morceaux dursIl existe un cas où une équipe d'architecture peut être confrontée à une urgence. Il s'agit des rares cas où les implications dépassent le cadre du produit. Si les utilisateurs finaux contournent le défaut, il n'y a pas d'urgence. En revanche, s'ils créent une vulnérabilité et une responsabilité, il y a urgence.
Utilisez une bonne technique d'écart, de lot de travaux et de point de repos de la valeur. Recherchez le plus petit changement qui génère une valeur exploitable. Dans ce cas, la valeur élimine la menace et la responsabilité.
Conclusion sur l'architecture d'entreprise et l'agilité
L'architecture d'entreprise et l'agilité souffrent toutes deux d'une mauvaise application chronique. Trop souvent simultanément. Ajustez votre approche afin que vos méthodes agiles et architecture d'entreprise les efforts réduisent l’incertitude du succès.
En tant qu'architecte d'entreprise, privilégiez une approche incrémentale pour réduire la probabilité et le coût des erreurs. En réduisant le coût des changements infructueux, vous éliminez le gaspillage. 100 % de vos efforts de changement inutiles réduisent la valeur du changement.
Le calcul est simple : le bénéfice est resté le même, le travail a augmenté. La valeur nette est moindre.
La réponse est simple : exploitez vos atouts et attendez-vous à ce que l'équipe agile exploite les siens.
L'architecture d'entreprise et l'agilité ont quatre modèles d'engagement de haut niveau :
- définir l'approche agile
- guider le backlog dans le sprint
- contraindre les sprints agiles
- résolution de la dépendance du produit vectoriel
La sélection du modèle est déterminée par votre cas d'utilisation d'architecture d'entreprise le conception de votre équipe EA.
Aller plus loin avec l'architecture d'entreprise et l'agilité
Aller plus loin Agilité Se distingue du développement logiciel agile. L'architecture d'entreprise et l'agilité se combinent dans trois domaines :
- concevoir 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
