simon-rohrer-modern-enterprise-architecture-architecting-for-outcomes

[00:00:25] chez nous quand on fait ça. D'accord les amis, allons-y. Je peux assurer, euhm c'est tout le français que vous entendrez de moi aussi.
[00:00:39] Ça marche ? Euh, bienvenue à tous. Uhm, quelle conférence géniale. Merci beaucoup à Evelyn et Kenny, euh pour leur échafaudage cognitif avec cinq éléments. J'en ai un autre. ce qui est entièrement fortuit. Euh, je vais parler de l'architecture axée sur les résultats. Uhm Je suis Simon, brièvement sur mon parcours euh au cours des 32 dernières années. Maintenant, j'ai commencé comme développeur. Je code encore un peu ou maintenant, ces jours-ci, je laisse mes agents coder pour moi, occasionnellement je le révise. Uhm, relativement tôt, et j'en discutais avec un ami vers mes vingt-cinq ans, je faisais de l'architecture d'entreprise. Euh les architectes d'entreprise sont censés avoir des barbes grises, mais j'avais réussi d'une manière ou d'une autre à le faire relativement tôt. Uhm, j'ai fait ça pendant assez longtemps. Uhm, j'étais architecte en chef euh euh pour la gestion de patrimoine chez Barclays au Royaume-Uni. Euh et puis en 2015, j'ai eu l'occasion de travailler avec John Smart. Il y avait un programme de transformation Agile, si ceux d'entre vous qui se souviennent, en 2015, ils étaient très à la mode. Euh et j'ai eu l'occasion de rejoindre le programme de transformation Agile du groupe chez Barclays. J'étais un agiliste passionné depuis que j'ai découvert le livre blanc XP en 1999. Alors, j'ai euh rejoint en tant que responsable de la transformation Agile. Nous avons ensuite décidé, euh et c'est important pour la présentation, qu'en fait la transformation Agile ne se concentrait pas sur les résultats. Elle s'est donc transformée en adoption Agile. Euh et puis en fait, nous avons décidé que ce n'était pas de l'Agile du tout, mais nous considérions cela comme des méthodes de travail. Uhm et puis en euh en 2016, la Grande-Bretagne euh où j'habitais a fait une chose très étrange. Euh comme les gens s'en souviennent il y a 10 ans, euh la Grande-Bretagne a voté pour quitter l'UE. Euh quelle chose étrange c'était. J'ai donc décidé de euh quitter la Grande-Bretagne à ce moment-là. Uhm, et maintenant je euh maintenant je travaille à Copenhague au Danemark. Euh et j'ai combiné mes euh deux rôles de carrière précédents dans un titre de poste que j'ai inventé pour moi-même, mais que j'aime, qui est euh responsable de l'architecture d'entreprise et des méthodes de travail. Uhm, et quand je travaillais avec John Smart euh à Londres, j'ai été invité à co-écrire un livre intitulé Sooner Safer Happier. Euh peut-être que l'un ou deux d'entre vous l'ont lu. Euh nous en sommes assez fiers. Donc, c'est l'architecture d'entreprise moderne et il s'agit de l'architecture au sein d'une entreprise moderne. Que disons-nous quand nous parlons d'une entreprise moderne ? Eh bien, c'est beaucoup de monde, ce sont des équipes d'équipes d'équipes. Euh, c'est euh interagir avec vos clients numériquement. C'est c'est la majeure partie du monde en ce moment, je pense. Euh le changement est une constante. Euh, c'est un c'est un mélange de systèmes. Donc, votre technologie est généralement un mélange hétérogène de systèmes prêts à l'emploi, de choses que vous avez achetées ou construites vous-mêmes, des choses qui changent lentement et rapidement, il peut y avoir des monolithes, peut-être des monolithes distribués et des microservices. Euh et un nid de systèmes, donc pas ceux qui sont autonomes et livrent des microproduits, mais typiquement vous avez des produits assez importants qui sont des systèmes de systèmes de systèmes. Donc, mon point de vue, mon échafaudage cognitif à cinq éléments pour l'architecture d'entreprise moderne, c'est un ABCDE. Euh, il s'agit d'aligner et de faire cohésionner les personnes, la valeur et la technologie. Avant, on disait simplement aligner. Euh, mais j'ai été frappé deux fois à ce sujet, donc maintenant c'est aligner et faire cohésionner. Uhm, le premier était de Diana Montallian qui, la première fois que j'ai donné cette conférence, la conférence juste avant, Diana a dit euh dans la communauté de la pensée systémique, nous n'aimons pas l'alignement. Nous utilisons la cohérence. Uhm, Sin aussi euh dans sa conférence hier et euh et de retour à Berlin a parlé de l'écart entre l'alignement et la cohérence. Donc, je vais parler de pourquoi c'est les deux. Uhm pour B, c'est une meilleure valeur plus tôt, plus sûre et plus heureuse, qui est le nom complet de Sooner Safer Happier, ce sont les cinq résultats. Euh et encore une fois, il s'agit d'une architecture axée sur les résultats. Uhm C concerne le continu et le conversationnel. Euh et comment l'architecture n'est pas ce processus unique et comment c'est un processus collaboratif, faisant écho à ce dont Evelyn et Kenny parlent. D concerne DevOps à l'échelle de l'entreprise. Euh plusieurs architectes ou architectes plus traditionnels à qui j'ai parlé pensent que l'architecture concerne le développement et la première partie du développement et ce n'est pas le cas. Et E concerne l'évolution, l'architecture d'entreprise évolutive.
[00:05:40] Il y aura beaucoup de réitérations de cela, donc vous pourrez choisir plus tard, mais je vais avancer. Uhm, donc un peu d'orientation, euh où en sommes-nous ? Euh encore une fois, j'ai commencé ma carrière dans les années 1990. Je me souviens du navigateur Netscape Navigator qui apparaissait sur mon Sun Microsystem.
[00:05:59] Uhm, j'ai lu plus tard le rapport Standish Chaos sur la façon dont plus de 70% des projets logiciels ont échoué. Uhm, en 95, le premier article sur Scrum a été publié. En 99, le tout premier, est-ce que quelqu'un, est-ce que quelqu'un est assez âgé pour avoir eu l'un de ces euh Nokia 7110, le premier téléphone mobile connecté à Internet Wap, le commercial. Uhm et en 99, le livre qui a vraiment changé ma carrière est sorti, le livre blanc sur la programmation extrême, la première édition.
[00:06:33] Et depuis lors, euh comme Mark Andresen, et je ne suis pas un grand fan de Mark Andresen, il est étrange et très d'extrême droite ces jours-ci, mais il a dit que le logiciel avait mangé le monde. Et dans une large mesure, c'est vrai. Uhm et un changement de paradigme s'est produit dans la façon dont nous avons développé des produits. Dans les années 1990, nous avions cette façon très basée sur les phases et les silos de développer des produits. Nous planifions pendant des mois, puis nous transmettions un tas de documents au-delà du mur, puis nous faisions peut-être une construction, peut-être du code, une conception, peut-être même la conception était en amont, puis nous la transmettions à une autre équipe qui serait généralement assez serrée, ayant prévu de tester pendant des mois, mais le code arriverait tard et ils auraient donc peut-être quelques semaines. Et puis nous le transmettions à une autre équipe qui serait ensuite chargée de trouver comment livrer ce truc en production, puis une autre pauvre équipe devrait l'opérer peut-être pour toujours.
[00:07:42] Et beaucoup de choses se sont produites, pas seulement Agile, mais DevOps, le cloud, la pensée systémique, tout un tas de pratiques qui n'étaient pas réellement nouvelles dans les années 90, elles étaient développées depuis les années 60. Mais ils sont devenus beaucoup plus à l'avant-garde de l'utilisation. Et puis nous avons eu notre ami la boucle, la boucle DevOps. Et au lieu de prendre des mois ou des années pour passer du concept à l'argent liquide, comme Chris en parlait hier, nous pouvions mettre les choses en ligne en quelques jours, voire quelques heures. Et au lieu d'avoir plusieurs équipes, nous avons une seule équipe capable et habilitée à effectuer toute cette boucle elle-même.
[00:08:30] Et cela nous fait passer d'un simple mode projet à ce que McKersten appelle ce cheminement vers le produit. Le logiciel n'est jamais terminé.
[00:08:41] Mais tout le monde ne l'a pas remarqué, et en particulier, beaucoup de personnes dans ma profession d'architecture d'entreprise pensent encore de cette manière très basée sur les phases. Donc, c'est un conseil pour ceux d'entre vous qui travaillent avec des architectes d'entreprise ou peut-être même certains d'entre vous le sont, de s'éloigner de la pensée basée sur les phases.
[00:09:01] Euh, un peu plus d'orientation. Uhm, la complexité dans ce que nous pourrions appeler l'héritage, mais effectivement le paysage des systèmes existants, en particulier pour les grandes entreprises modernes dont j'ai parlé, commence à dominer le rythme du changement. Ceci est un diagramme d'un gars appelé Roger Sessions. Euh et quand je parle de Roger Sessions, il était un écrivain superbe sur l'architecture d'entreprise et une architecture d'entreprise très pratique. Il est maintenant à la retraite, il a déménagé au Mexique, il gère une retraite de méditation. C'est une leçon peut-être pour nous tous dans la technologie. Uhm, et Roger Sessions a écrit un livre génial il y a, euh mon Dieu, presque 20 ans maintenant, sur les architectures simples pour les entreprises complexes, et il a en quelque sorte pré-inventé les microservices, son concept de limites basé à la fois sur l'équipe et le logiciel et le problème commercial. Un tas de modèles et de principes pour cela, mais pas tout le monde, en fait presque personne n'a repris cela. Et donc nos problèmes sont similaires mais différents de ceux des années 90, euh où Dan North parle de la façon dont nous avons adopté cette métaphore de l'ingénierie civile sur la façon dont nous devrions construire des logiciels et c'était la mauvaise métaphore.
[00:10:24] Mais dans les années 2020, nous avons de la complexité euh où nous devons utiliser ces techniques de gestion de projet pour orchestrer ces choses trop compliquées que nous avons construites. Et pour en revenir à Roger Sessions, il dit que l'architecture d'entreprise est essentielle pour cela. Et je vais essayer de soutenir cet argument, il dit que la complexité est l'ennemi et que l'architecture d'entreprise est la seule solution.
[00:10:53] Euh un petit mot sur la complexité ici, euh quelqu'un de Cannevin, familier avec Cannevin, bien sûr, presque tout le monde l'est. Donc, quand Roger Sessions et certaines des autres personnes que je cite parlent de complexité, ils parlent probablement dans le domaine du compliqué et du complexe. Certaines de ces choses et euh à la fois Sin et Bear Riley parlent de la façon dont la technologie elle-même, juste la technologie, n'est probablement que dans l'espace compliqué, mais une fois que vous commencez à ajouter des personnes dans l'équation, une fois que vous commencez à devenir sociotechnique, c'est là que vous commencez à devenir plus complexe. Et les gens sont presque toujours dans l'équation. D'accord, retour à notre euh petit cadre, notre ABCDE. Donc aligner et faire cohésionner les personnes, la valeur et la technologie. Je ne vais même pas demander car tout le monde connaît la loi de Con Conve, bien sûr, bien sûr. Donc, en gros, très très grossièrement, c'est que l'architecture organisationnelle pilote l'architecture système et je connais les choses à ce sujet, ce sont les structures de communication euh qui pilotent l'architecture système. Et Ruth Malan, que j'adore, que je vénère, Ruth Malan, euh elle dit que si l'architecture du système et l'architecture de l'organisation sont en désaccord, alors l'architecture de l'organisation va gagner.
[00:12:15] Mais euh Alan Kelly fait aussi un excellent point. Il dit que l'enfer se déchaîne vraiment quand la direction décide de réorganiser les choses. Vous essayez de changer l'organisation, mais le logiciel ne va pas le permettre. Il parle de la façon dont vous savez essayer de faire en sorte que les ingénieurs de mainframe se séparent en équipes et cela ne fonctionne tout simplement pas.
[00:12:38] Donc, l'architecture système pilote l'architecture organisationnelle. Comment concilier ces choses ?
[00:12:48] Encore une fois, retour à mon euh mon pays d'origine, le Royaume-Uni. Dans les années 1940 pendant la guerre, lorsque la Chambre des Communes au Royaume-Uni a été bombardée.
[00:13:00] Euh, il y a eu une offre de le reconstruire d'une manière légèrement différente. Donc pour ceux d'entre vous qui connaissent la Chambre des Communes, elle est construite de manière contradictoire. Il y a un ensemble de bancs face à un autre ensemble de bancs et apparemment c'est à deux longueurs d'épée. Euh, incroyablement contradictoire.
[00:13:19] Et il y a eu une offre de dire, regardez, la façon moderne de faire cela est dans une chambre incurvée comme tant de parlements européens. Faisons cela. Et Churchill a dit non, j'aime la façon dont c'est contradictoire. Nous façonnons nos bâtiments et ils nous façonnent, ainsi que notre façon de travailler.
[00:13:37] Et donc Jim Kim a repris cette citation et l'a appliquée aux architectures également. Et cela, je pense, parle de cette boucle de rétroaction. Eh bien, bien sûr, sur une feuille de papier vierge, nous façonnons l'architecture et la loi de Conway s'applique d'une certaine manière, mais ensuite l'architecture nous façonne en retour. C'est une boucle de rétroaction.
[00:13:57] Comme ça. Uhm et récemment, euh j'ai vu James Coplin donner une conférence et il a dit euh Grady Booch et lui se disputaient sur Twitter. Et Grady Booch pensait que c'était unilatéral et pensait que Mel Conway n'avait fait qu'insinuer que l'architecture organisationnelle façonnait l'architecture système. Et Jim Coplin a dit, non, c'est définitivement dans les deux sens. Et donc les deux sont allés voir Mel Conway. Et Mel Conway a dit, oui, bien sûr, j'ai toujours voulu dire que c'était bidirectionnel. et cela, je pense, parle de cette boucle de rétroaction. Eh bien, bien sûr, sur une feuille de papier vierge, nous avons façonné l'architecture et la loi de Conway s'applique d'une manière, mais ensuite l'architecture nous refaçonne. C'est une boucle de rétroaction.
[00:13:57] Comme ceci, euh, et récemment, euh, j'ai vu James Coplin faire une conférence et il a dit, euh, Grady Buch et lui se disputaient sur Twitter. Et Grady Buch pensait que c'était une voie et pensait que Mel Conway n'avait fait qu'impliquer que l'architecture organisationnelle façonne l'architecture système et Jim Coplin a dit, non, c'est définitivement dans les deux sens. Alors les deux sont allés voir Mel Conway. Mel Conway a dit, oui, bien sûr, j'ai toujours voulu dire que c'était bidirectionnel.
[00:14:29] De retour à Beth Mallen, elle dit que les architectes de systèmes que nous appelons architectes et les architectes organisationnels que nous appelons managers ne devraient pas travailler comme s'ils n'avaient aucun impact les uns sur les autres.
[00:14:42] Donc, c'est cette boucle de rétroaction et, encore une fois, typiquement dans les organisations, c'est un retour aux silos. Les architectes d'organisation, les managers sont ceux qui conçoivent les structures d'équipe. Et les architectes de systèmes sont ceux qui sont censés concevoir les systèmes. Ils doivent travailler ensemble pour obtenir de l'efficacité. Et puis, bien sûr, il y a un autre angle à cela. Gregor, que euh, nous avons vu pour la dernière fois à Berlin, mais il n'est pas là, Gregor Hopy, j'espère que tout le monde a rencontré Gregor et son travail incroyable sur l'ascenseur d'architecte. Il parle de la façon dont l'architecture d'entreprise est la jonction de l'architecture métier et de l'architecture technologique.
[00:15:24] Et puis, dans le monde moderne, encore une fois, dans ces récentes transformations Agile, vous avez eu l'architecture d'entreprise qui a essayé de façonner l'architecture de l'organisation, réorganisant les gens en flux de valeur ou en tribus ou quoi que ce soit. Boston Consulting ou McKinsey veulent l'appeler cette semaine.
[00:15:44] Donc, ce n'est pas seulement une boucle de rétroaction bidirectionnelle, c'est cette sorte d'interaction entre ces trois éléments. D'où le triangle contre le A, vous avez des architectes d'organisation d'un côté et des architectes de système et encore une fois, si cela doit bien fonctionner, il doit y avoir une collaboration entre eux. Je réfléchis à la façon dont ces trois éléments interagissent.
[00:16:09] Donc, vraiment pour un flux durable, c'est une conférence sur le flux.
[00:16:13] C'est là, pour moi, que l'alignement et la cohérence commencent à intervenir. Votre valeur, votre organisation et votre technologie et vos processus, vous avez besoin d'un degré élevé d'alignement afin d'atteindre un flux durable.
[00:16:31] À quoi ça ressemble ? Eh bien, l'équipe est l'unité de livraison.
[00:16:37] Donc, cela parle d'une équipe idéale de deux pizzas rationalisée pour ceux d'entre vous qui sont fans des typologies d'équipes et des façons de travailler d'Amazon.
[00:16:48] Une très courte digression, euh, en ce moment, euh, avec un ami, je travaille sur une présentation pour l'automne, euh, sur ce que l'IA fait aux équipes de deux pizzas. J'ai vraiment hâte, ça va être une discussion tellement intéressante. On parle d'équipes de deux pizzas qui se réduisent à deux personnes, euh, un spécialiste de l'IA et un chef de produit. Je ne pense pas que ce soit le cas. Cette discussion sur les équipes d'une seule pizza et le péché en parle. C'est un domaine tellement fascinant, mais pourquoi avons-nous encore des équipes dominées par les humains, alors une équipe de la taille de deux pizzas, elle possède une certaine valeur, un certain élément de valeur. C'est une équipe de deux pizzas et on peut discuter des chiffres jusqu'à ce que les vaches rentrent, est-ce quatre, est-ce sept plus ou moins deux, est-ce moins de 20 ? C'est un nombre relativement petit de personnes et peut-être de personnes et d'agents. Et c'est ce que Don North a commencé, puis Matthew Manuel de Team Topologies a étendu au logiciel qui tient dans la tête de l'équipe.
[00:17:52] Donc c'est finalement cohérent, c'est encore une super, euh, présentation de Matthew Manuel de, je crois, 20, 18 ou 19, appelée monolithe contre microservices, qui manque le point. Il s'agit de la propriété de l'équipe et de la compréhension du logiciel par l'équipe. Et c'est cette boucle DevOps, je pense que c'est un certain euh Newman qui a appelé les microservices la première architecture native DevOps parce que. Le but est que les systèmes distribués sont difficiles, Martin Fowler disait de vendre sa grand-mère avant de distribuer des objets. Mais l'intérêt du système distribué ici est qu'il permet à l'équipe elle-même de gérer l'intégralité du cycle de vie opérationnel et pas seulement le développement du logiciel. Et retour aux sessions Roger sur la capacité d'affaires autonome.
[00:18:40] Que signifie le burrito complet ?
[00:18:43] Désolé.
[00:18:46] Burrito complet.
[00:18:48] Burrito complet. Euh c'est une citation de l'article de Martin Fowler sur les topologies d'équipe. Donc il dit, euh c'est le cycle de vie complet, la pile complète euh et le cycle de vie complet. Il l'appelle le burrito complet. Donc effectivement l'équipe devrait être capable de tout faire. Front-end, back-end, base de données. Oui.
[00:19:11] Euh, personne ne sait d'où ça vient, euh, et je saute un peu ça ces jours-ci parce qu'il y a un sacré paquet de publications qui disent que c'est n'importe quoi. Tout le monde n'a pas besoin de parler à tout le monde tout le temps. Mais c'est effectivement la raison pour laquelle vous voulez garder votre équipe relativement petite à cause des frais généraux d'intercommunication. Plus vous ajoutez de personnes, plus vous ajoutez de chemins de communication exponentiellement.
[00:19:35] Euh, Martin Fowler encore, donc qui parle de l'architecture, qui fait de l'architecture, euh, eh bien, l'équipe elle-même fait l'architecture, elle possède l'architecture. Euh, et euh, juste avant que j'écrive cette conférence à l'origine, il y avait une publication sur les réseaux sociaux qui disait, euh, j'aimerais faire une conférence principalement sur le thème de Martin Fowler euh a résolu ce problème il y a 20 ans.
[00:20:04] Euh, donc il y a environ 20 ans, je pense que c'est peut-être même plus, Martin Fowler a écrit deux articles que je considère très similaires. L'un s'appelait "Qui a besoin d'un architecte" et l'autre "Le design est-il mort". Mais la conclusion des deux est fondamentalement que l'équipe doit posséder sa propre architecture. Il parle du rôle d'entraîneur en programmation extrême, euh, par opposition à l'architecte du type matrice qui sait tout. Le but de l'entraîneur XP n'est pas d'être l'architecte, mais de faciliter l'architecture avec son expérience au sein de l'équipe.
[00:20:39] Et c'est génial. Mais aucune équipe n'est une île. Et encore une fois, au sein de nos entreprises modernes, euh, il y a très peu d'organisations où une seule équipe livre un seul produit par elle-même, typiquement elles ont besoin de collaborer. Et il y a une sorte de couplage et le livre de Vlad Khononov sur le couplage équilibré, c'est un livre extrêmement pragmatique. Qui dit que le couplage en soi n'est pas nécessairement mauvais. C'est le degré de couplage combiné à la distance entre les décisions qui est quelque chose que vous devez surveiller. Donc, bien sûr, dans vos entreprises modernes, vous aurez une équipe d'équipes et cela commence à prendre cette nature fractale auto-similaire où, bien sûr, l'équipe d'équipes possède également quelque chose de valeur. Et encore une fois, étant sceptique quant aux chiffres, 150 est le nombre de Dunbar, mais encore une fois, les gens lancent des pierres en disant d'oublier le nombre de Dunbar, c'est euh, c'est presque, presque, presque insignifiant. Mais c'est une équipe d'équipes, ce qui est un certain nombre au-dessus de l'équipe de deux pizzas.
[00:21:46] Et encore une fois, c'est un système de systèmes et ces équipes doivent collaborer et elles doivent converser. Et encore une fois, pour en revenir au péché, nous pouvons découpler, euh, nous pouvons découpler la technologie, mais nous devons connecter les gens.
[00:22:02] Et encore une fois, le système de systèmes et un domaine d'une manière ou d'une autre ici qui tient dans la tête de l'équipe.
[00:22:12] Et, euh, encore une fois, l'auto-similarité fractale ici pour les entreprises, certainement celles avec lesquelles j'ai l'habitude de travailler, dans des endroits comme les services financiers, avec une ligne de métier, vous parlez typiquement d'équipes d'équipes d'équipes. Et de l'ordre de plusieurs centaines à plus de mille personnes collaborant et faisant la même chose, que ce soit la gestion de patrimoine ou les cartes de crédit dans mon domaine. Euh, mais alors vous êtes à un niveau de système de systèmes de systèmes. Est-ce que cela rentre dans la tête de quelqu'un ? Et ce que je dis ici, c'est que, typiquement non, mais ce qui rentre dans la tête des personnes qui opèrent à ce niveau, c'est l'organisation. Et qui sait quoi. C'est donc une sorte de niveau d'indirection. Certainement celui sur lequel j'essaie d'opérer. Dans mon monde, je ne connais pas tous les détails de l'élément paiements du système ou de l'élément tarification, mais je sais qui sait, et je sais à qui aller parler.
[00:23:19] Euh, et David Woods, euh, parlant de, euh, de la gestion des erreurs dans des systèmes complexes, et encore une fois, c'est probablement compliqué plutôt que strictement complexe. Mais David Woods dit, regardez, à mesure que cette complexité ou cette complication augmente, la précision de tout agent unique, donc votre architecte de niveau divin, euh, la précision de leur modèle du système diminue rapidement. Donc, au lieu de cela, vous devez faire confiance, vous devez faire confiance aux autres et savoir à qui faire confiance.
[00:23:53] Euh, retour à, euh, retour à l'alignement versus la cohérence. Ainsi, Ralph Stacy parle de la façon dont les organisations sont un ordre et un désordre entrelacés.
[00:24:07] Euh, et que typiquement les managers essaient de s'orienter vers l'ordre plutôt que le désordre, mais ils doivent être capables de gérer les deux. Donc pour moi, quand on parle d'alignement et de cohérence, le côté alignement concerne davantage le côté ordonné de l'organisation. Donc encore une fois, pour moi, travaillant dans les services financiers, je dois beaucoup travailler avec les réglementations. Elles sont assez ordonnées. Et donc, quand j'essaie de travailler avec les gens et de les aligner, c'est typiquement du côté ordonné de, euh, l'organisation. Mais, bien sûr, il y a du désordre, vous ne pouvez pas obtenir des gens avec ce genre d'alignement plutôt joli. Retour à la diapositive de Sin, l'alignement est joli et c'est excellent pour certains euh problèmes et situations qui sont ordonnés. Mais la cohérence n'est pas, elle a cette nature vivante. Et donc pour moi, dans ce modèle Stacy d'ordre et de désordre entrelacés et ordonnés, vous avez besoin d'un certain degré des deux.
[00:25:11] Euh, et finalement pour le A, euh, retour à, euh, retour à Conway encore. Il dit que des moyens doivent être trouvés pour récompenser les responsables de conception qui maintiennent leurs organisations agiles et flexibles. Et une philosophie de gestion de la conception de systèmes, qui n'est pas simplement basée sur l'hypothèse que l'ajout de main-d'œuvre augmente la productivité.
[00:25:31] Cool. Alors, quel est l'intérêt ici ? Donc, vous alignez en tant qu'architecte d'entreprise la valeur, les personnes et la technologie, les trois dans le triangle.
[00:25:44] Beaucoup d'organisations essaient de faire cet alignement bilatéral où les managers essaieront d'aligner les flux de valeur et les organisations, et les architectes d'entreprise essaieront d'aligner le business et la technologie, et c'est les trois ou rien.
[00:25:59] Cool. Euh, passons à B, meilleure valeur plus tôt, plus sûre, plus heureuse. Euh, il y a un anti-pattern ici des résultats d'architecture d'entreprise traditionnels autour de la standardisation, de la cohérence et de la planification prédictive, euh, et de la réduction des coûts. Et euh comme le dit l'homme, ce ne sont pas les résultats que vous recherchez.
[00:26:20] Certaines nouveautés comme euh, déplaçons tout vers le cloud ou Kubernetes ou les microservices ou l'IA. Ce ne sont pas des IA, ce ne sont pas des AE. Oui. biaiser mal oui, erreur de langage là. Ce ne sont pas non plus les résultats que vous recherchez. Et ce dont nous parlons dans le livre, c'est ce tableau de bord équilibré des résultats. La valeur est au centre bien sûr, et la valeur est ce qui vous rend unique, ce qui rend votre organisation spéciale. Mais vous devriez équilibrer cela avec mieux, plus tôt, plus sûr et plus heureux. Mieux, c'est la qualité. Plus tôt est ce dont nous parlons ici, c'est le flux. Plus sûr est agile et non fragile, c'est intégrer la sécurité, la confidentialité et si vous êtes une industrie réglementée, ce qui, encore une fois, est le cas de la plupart des gens de nos jours, c'est une conformité minimale viable. Et plus heureux est la préoccupation pour vos clients, mais pas seulement vos clients, aussi vos collègues, vos citoyens et le climat également.
[00:27:19] Et ce sont les résultats équilibrés que je pense que nous devrions rechercher dans l'ensemble. De retour à Jean, euh, nous façonnons notre architecture, puis notre architecture nous façonne, mais il continue en disant, à mesure que les systèmes que nous construisons deviennent plus grands, la coordination augmente et cela peut croître de sorte que juste notre temps de dépense est passé à coordonner plutôt qu'à livrer de la valeur.
[00:27:40] Donc nous voulons essayer d'éviter cela.
[00:27:43] Euh, et c'est un peu une sorte d'architecture pour le flux dans des choses que j'ai vues, des schémas que j'ai vus se reproduire encore et encore. Nous avons euh, le concept au paiement encore, nous voulons optimiser cela. Mais nous avons cette architecture héritée où nous avons une équipe qui s'occupe de l'interface utilisateur, une équipe qui construit les API, une équipe qui construit euh, un service de salutation et une équipe qui construit un service de planète et une autre équipe qui s'occupe de la base de données. Pour cela, vous avez besoin d'une équipe en dehors des équipes pour réaliser la solution. Comment distribuons-nous ce concept de Hello World à travers ces équipes ? Alors nous donnons "bonjour" au service de salutation, nous donnons "monde" au service planétaire, euh, nous donnons une petite API slash à la couche API et l'interface utilisateur y ajoute du Chrome. Et les DBA ont cette étrange convention de nommage pour les tables qui doit commencer par T_ et puis ça vous donne deux lettres, donc c'est T_H W.
[00:28:50] Euh, et puis après quelques mois de développement et de tests d'intégration, nous obtenons quelque chose qui dit Hello World, ce qui est assez proche. Ce n'est pas un défaut bloquant, donc nous pouvons le mettre en ligne. L'équipe de test est contente. Nous corrigerons cela plus tard. Euh, ce n'est pas optimal, ce n'est vraiment pas optimal pour quelque chose que nous pourrions faire légèrement différemment. Et euh, de retour à Gregor, et Gregor dit que le découpage en couches est parfois considéré comme nuisible, c'est un peu un anti-modèle.
[00:29:22] Donc ici, nous pouvons et on m'a dit que ce n'est pas de la refactorisation. Dave Thomas m'a réprimandé pour ça. C'est de la restructuration. Nous avons restructuré à la fois l'organisation et l'architecture comme nous l'avons appris, nous avons travaillé ensemble. Les managers et les architectes et nous disons, non, en fait une équipe peut posséder tout cela. C'est un nouveau monde où nous pouvons avoir une équipe full stack, full burrito qui peut posséder l'interface utilisateur, elle peut posséder la logique métier, elle peut posséder la base de données. Il n'est pas difficile de changer de base de données de nos jours, nous avons la technologie.
[00:29:56] Et donc le temps du concept au paiement et le temps de changer, c'est massivement réduit parce que, eh bien, nous n'avons pas seulement changé la technologie, mais nous nous sommes réorganisés autour de cette meilleure façon d'architecturer.
[00:30:12] Et, euh, il y a une excellente présentation du Sommet des leaders technologiques d'entreprise sur la façon dont les coûts de coordination nuisent à votre efficacité. Pour donner les chiffres, l'économie derrière cela, réduire la coordination peut radicalement changer à la fois votre profil de risque et aussi le coût du changement. la logique métier, ils peuvent posséder la base de données. Il n'est pas difficile de changer de base de données de nos jours. Nous avons la technologie. Et donc le temps du concept à l'argent et le temps de changer, est massivement réduit parce que, eh bien, nous n'avons pas seulement changé la technologie, mais nous nous sommes réorganisés autour de cette meilleure façon d'architecturer.
[00:30:12] Et, euh, il y a une excellente présentation du Sommet du Leadership Technologique d'Entreprise sur la façon dont les coûts de coordination tuent votre efficacité pour donner les chiffres, l'économie derrière cela, réduire la coordination peut radicalement changer à la fois votre profil de risque et aussi juste le coût du changement.
[00:30:36] Donc, revenons aux résultats et en particulier en se concentrant sur le flux,
[00:30:42] nous conseillons, en tant qu'auteurs de 'plus tôt dit pour plus heureux', que vous vous concentriez sur ces résultats. Une meilleure valeur plus tôt dit pour plus heureux est un ensemble équilibré, plutôt que les résultats traditionnellement attendus de l'architecture d'entreprise, qui ne recherchaient que la réduction des coûts, la standardisation pour elle-même ou la duplication. Ce sont peut-être de bons résultats mais pas pour leur propre bien.
[00:31:08] C concerne la gouvernance continue, conversationnelle et automatisée. Donc,
[00:31:16] pourquoi la gouvernance ? Eh bien,
[00:31:19] créer et réduire la complexité peut sembler être des opposés, mais ce n'est pas le cas. Ils sont asymétriques. C'est un article de la Harvard Business Review. Cela n'a rien à voir avec la technologie, c'est juste lié aux affaires en général.
[00:31:31] Donc, la gouvernance de l'architecture est une façon très traditionnelle de sauver cela et de dire, non, nous devons tout revoir, nous devons examiner en profondeur la complexité pour nous assurer que cela n'arrive pas.
[00:31:43] Mais les conseils d'examen de l'architecture dans le monde moderne, dans la situation dont nous avons parlé, c'est un anti-modèle. Nous faisions de nouveau de la gouvernance architecturale dans les années 90. Les gens le font-ils encore comme ça aujourd'hui ? Dans ce genre de cascade ou d'agile ou de 'water scrum fall', nous avons un cycle de vie de projet où nous initions, planifions, exécutons et clôturons, et ensuite nous avons un cycle de vie technologique parallèle où nous faisons l'analyse, nous initions, nous concevons, nous construisons et testons, et ensuite nous livrons, et puis nous avons terminé.
[00:32:20] Et c'était génial pour les promoteurs des comités d'examen de l'architecture parce que vous aviez un créneau pour eux à la fin de l'analyse, vous pouviez examiner un artefact. l'approuver et dire que c'est génial. et de même, vous obtiendriez quelque chose d'encore meilleur, de plus détaillé. C'est exactement ce que nous allons faire à l'avenir, un tampon en caoutchouc. C'est super. Cool.
[00:32:44] Dès que vous commencez à travailler de manière agile ou allégée, où vous faites ces choses en parallèle, vous planifiez et exécutez en continu. peut-être éventuellement parce que, encore une fois, c'est toujours un projet, vous allez clôturer. Bien sûr, vous faites un tout petit peu d'analyse préalable, mais vous analysez encore continuellement et regardez, vous livrez tôt et souvent.
[00:33:10] Alors, où se situe votre comité d'examen de l'architecture ? Eh bien, vous pourriez essayer de le faire à la fin de l'initialisation, mais vous n'avez fait qu'un peu d'analyse. Qu'est-ce que vous validez à ce stade ?
[00:33:21] Vous le faites ici ? Vous avez déjà publié deux logiciels. Vous avez déjà géré votre risque ici. Donc, tout ce concept de silos en cascade, de portes, de portes en particulier et de phases a disparu. Et donc le comité d'examen de l'architecture ne s'aligne pas du tout sur cela.
[00:33:37] Et certainement, une fois que vous passez d'un projet à un produit, ce n'est tout simplement pas possible. Donc, nous avons quelques modèles ici.
[00:33:51] cette complexité dont parle Roger Sessions, c'est quelque chose que vous pouvez examiner tôt. J'ai besoin d'un nouveau service. Donc pour nous, notre architecte d'entreprise dit, eh bien, super. Vous pensez avoir besoin d'un nouveau service, discutons-en. Cela va ajouter de la complexité, cela va ajouter de la complexité à long terme.
[00:34:11] Pourriez-vous faire cela d'une autre manière ? Pourriez-vous développer quelque chose que vous faites déjà ? Avez-vous même besoin de faire cela ? Si vous le faites, alors c'est génial. Vous pouvez le faire.
[00:34:22] La connectivité, si vous vous souvenez du diagramme en araignée au début des sessions, la connectivité est une... c'est une complication. Alors, c'est super. Vous devez vous connecter à un autre service. Euh,
[00:34:35] génial. Ayons une conversation à ce sujet. Avez-vous vraiment besoin de faire cela ? Devriez-vous vraiment gérer ces données vous-même ? Est-ce dans vos propres limites ? Génial.
[00:34:45] L'automatisation ici, c'est pratiquement de l'automatisation et de la gouvernance à la demande, non pas en validant une conception, mais en validant ce qui est réellement là. Et nous avons des chemins balisés si les équipes veulent faire des choses qui suivent les chemins dorés. C'est cool. C'est pré-approuvé pour eux.
[00:35:05] Désolé pour ceux qui prennent des photos. Je mettrai le lien plus tard. Et les conversations sont essentielles ici.
[00:35:15] Donc, la gouvernance est en quelque sorte entre guillemets ici parce qu'il s'agit plus de collaboration que de gouvernance à ce stade.
[00:35:23] Alors, super, nous avons une idée ici, mais les équipes ont cette sorte de conversation continue avec notre communauté de pratique de l'architecture. C'est très similaire au processus de conseil en architecture dont parle Kenny, qu'Andrew Hammarlaw du livre aborde, ce n'est pas la vue hiérarchique, ce sont des conversations avec vos pairs pour savoir si c'est le bon type de chose à faire, en espérant faire un peu de débiaisage ici.
[00:35:53] Euh, et honnêtement, c'est la seule façon de travailler si vous avez un produit continu, encore une fois, il n'y a pas de portes, pas de phases, il n'y a aucun moment où vous pouvez vous arrêter et dire, super, dites-nous les seules choses que vous allez faire à l'avenir.
[00:36:09] Et les échelles aussi, cela se produit à travers les chaînes de valeur. Nous avons la communauté de pratique de l'architecture. Pour nous, nous avons une petite équipe centrale d'architecture. Nous ne disons pas aux gens ce qu'il faut faire. Nous discutons avec eux de ce qu'ils vont faire.
[00:36:27] Et l'ingénierie de plateforme est également géniale ici, surtout lorsque vous avez des industries réglementées et que vous avez besoin d'une vue alignée sur certaines de vos vérifications. Charlie Betts écrit brillamment à ce sujet. Il dit que dans une stratégie de plateforme correctement exécutée, vos contrôles d'architecture et de sécurité ont eu lieu parce qu'ils sont tous intégrés à la plateforme. Et une liste de contrôle que vous auriez pu avoir à remplir pour vos collègues de la sécurité, pour chaque version ou pour chaque nouveau logiciel, c'est idiot. Ou du moins c'est fait à 90%.
[00:37:03] Et la voie à suivre dont Charlie parle ici est que les parties prenantes acceptent un niveau de standardisation et que les architectes ne font pas obstacle au progrès, et ils n'auraient jamais dû l'être en premier lieu.
[00:37:15] Donc, C est continu, conversationnel, aussi automatisé que possible, au lieu de cette sorte de méthode héritée consistant à supposer que vous avez des phases que vous pouvez verrouiller, que votre gouvernance concerne les documents, et qu'elle est contradictoire.
[00:37:33] D est DevOps à l'échelle de l'entreprise, donc reprenant cette idée de gouvernance conversationnelle continue.
[00:37:42] L'objectif principal de votre fonction d'architecture est de permettre à cette boucle de fonctionner à l'échelle de l'entreprise.
[00:37:51] Ce qui, bien sûr, a une portée beaucoup plus large que les équipes, c'est un système cohérent de systèmes de systèmes, c'est un ensemble cohérent de produits. Et les choses se déroulent sur une plus longue période également, donc les équipes livrent aussi vite que possible, mais il y a des changements qui se produisent à des cadences différentes au sein de l'organisation aussi.
[00:38:15] encore une fois, ce réalignement.
[00:38:18] Euh, certainement pour moi et ce que je conseille aux architectes d'entreprise, c'est qu'ils ne vivent pas en silo. Certains de mes plus proches collaborateurs travaillent dans la gestion de services et c'est un anathème pour les architectes d'entreprise traditionnels. Que faites-vous à parler aux gestionnaires de services ? Vous n'êtes pas impliqué dans le même genre de choses. Mais si vous, en tant qu'architectes d'entreprise, architectes d'entreprise modernes, vous souciez de la boucle, alors vous réfléchissez à ce qui est en direct aussi. Encore une fois, c'est le diagramme de Ruth Malan que j'ai un peu augmenté. Vous regardez l'intention, mais ensuite les choses sont déployées et vous y réfléchissez et vous les faites remonter.
[00:39:00] Donc, l'un des outils que mon équipe et moi utilisons le plus est l'outillage d'observabilité. Nous regardons ce qui se passe et nous ne nous contentons pas de regarder un seul sous-système ou microservice. Nous reculons et observons ce qui se passe dans toute l'entreprise. Cela nous donne des connaissances que nous n'aurions pas pu obtenir simplement en regardant les documents de conception, bien sûr que non.
[00:39:27] John Cutler euh parle de ceci euh sur la façon dont une sorte de euh façon ultime pour les équipes d'opérer et il y a beaucoup d'astérisques autour de cela mais une façon ultime pour les équipes d'opérer est de collaborer sur tout, depuis la sélection des opportunités jusqu'à la construction, les tests, le déploiement et l'exécution.
[00:39:50] Et pour moi, vous ajoutez les deux ensemble. Vous ajoutez la boucle DevOps, l'équipe, à ceci, vous le construisez, non seulement vous le construisez, vous l'exécutez, mais vous le 'toutiez', vous le 'toutiez'. Vous le développez, vous le construisez, vous le modifiez, vous l'exploitez, vous l'exécutez, mais vous faites aussi la sélection commerciale ici. C'est donc le BizDevOps poussé à l'extrême.
[00:40:17] Donc, encore une fois, l'architecture d'entreprise moderne est DevOps à l'échelle de l'entreprise. Ce n'est pas la concentration traditionnelle de l'architecte d'entreprise uniquement sur le changement, pas sur l'exécution, sur le dev et non sur les ops, et sur le projet et non sur le produit. En tant qu'architecte d'entreprise, vous tournez continuellement en boucle.
[00:40:35] Enfin, l'architecture d'entreprise évolutive, qui gère l'évolution de l'architecture d'entreprise et de l'organisation. en revenant au début. Euh, les architectes évolutionnistes, euh, Nick Ford, Rebecca Parsons, Pat Kua et Hamid Savaj, en parlent depuis, eh bien, aussi longtemps que je me souvienne, environ 20, plus de 20 ans qu'ils parlent d'architecture évolutionniste. Euh, et il y a un excellent podcast de ThoughtWorks où Neal Ford en parle.
[00:41:06] Euh, et il explique à quel point il devient réellement assez difficile de construire les fonctions de fitness dont ces gens parlent une fois que l'on dépasse un système individuel, un système en cours de traitement.
[00:41:21] Et nous parlons, dans 'plus tôt, plus heureux', de deux théories de l'évolution biologique réelle. La théorie originale de type darwinien dit que l'évolution se produit à une échelle progressive et de manière continue. La théorie numéro deux est venue beaucoup plus tard, elle a dit : non, en fait, tout reste à peu près pareil jusqu'à ce que quelque chose comme un astéroïde arrive et détruise un tas de flore et de faune, et alors un grand changement se produit et puis les choses restent les mêmes pendant un certain temps.
[00:41:55] Bien sûr, ces deux théories sont vraies. C'est un peu des deux. Il y a donc un changement progressif qui se produit continuellement. Et puis, occasionnellement, il y a un changement massif causé par un événement énorme. Et pour moi, nous devons nous inspirer de cela dans nos organisations.
[00:42:17] Nous devons donc, en tant qu'architectes d'entreprise et simplement en tant que leaders, accorder une attention continue à la dette de complexité, et la réduire. C'est donc là que nous conseillons environ 20% à 30% d'un budget
[00:42:35] pour que les équipes remboursent leur dette. Rembourser la dette de complexité, la dette technique, même la dette organisationnelle.
[00:42:45] mais aussi, cela ne va pas résoudre tous vos problèmes. Occasionnellement, vous devez financer un changement d'étape massif. C'est là que vous pourriez vouloir commencer à faire de la modernisation de l'architecture, le genre de choses dont parle Nick Tune. faire venir une équipe d'habilitation à la modernisation de l'architecture. Mais vous allez avoir besoin d'un dossier commercial pour cela, ou peut-être arrêtez-vous complètement de faire cette chose. Peut-être avez-vous fait une cartographie Wardley et avez-vous décidé que cette chose que vous faisiez est maintenant devenue un produit ou une commodité. Et vous n'avez pas du tout besoin de le faire. Mais c'est le grand changement occasionnel combiné à cette amélioration continue et à ce changement continu.
[00:43:28] Et bien sûr, Martin Fowler a écrit à ce sujet il y a 25 ans. Encore une fois, euh, l'une des meilleures façons de faire cela est d'adopter le modèle du ficus étrangleur. Vous n'allez pas réécrire tout votre système de système de systèmes. Alors, prenez-le morceau par morceau.
[00:43:45] étranglez-le, retirez-le.
[00:43:49] Et c'est ce que nous faisons. C'est mon parcours en sept ans depuis que j'ai fait mon propre Brexit personnel pour Saxo Bank. Quand je suis arrivé,
[00:44:00] J'ai vu un système ressemblant beaucoup à cela, un monolithe distribué, avec de nombreuses, nombreuses bases de données, plus de 1200 services, qui était difficile à changer. Et lentement mais sûrement, nous l'avons refactorisé. Nous avons commencé à travailler avec l'organisation et les systèmes pour les transformer en équipes autonomes qui possèdent des capacités autonomes. Nous n'avons pas tout fait. En sept ans, nous avons beaucoup progressé.
[00:44:27] Mais je prendrai probablement ma retraite avant que nous n'ayons terminé.
[00:44:31] Et c'est encore loin aussi.
[00:44:35] Continuez.
[00:44:38] Euh, de retour à Simon Wardley, encore une fois, je n'ai probablement pas besoin de lever la main pour cela. Cartographie Wardley, quelqu'un ?
[00:44:44] Tout le monde, presque. Cool. Donc Simon parle beaucoup, bien sûr, de l'évolution aussi.
[00:44:53] Euh, en fait, presque toute la euh, la stratégie dont Simon parle concerne le mouvement évolutionnaire, sur la façon dont l'agile est fort tout à gauche, sur la façon dont vous devriez commencer à penser à d'autres méthodes tout à droite.
[00:45:13] Et il parle aussi de ses, euh, de ses principes. Il dit que vous devez avoir des principes. Voici ceux que vous pourriez vouloir prendre sur étagère.
[00:45:25] il dit, faites-les par phases. Et il dit,
[00:45:30] commencez par la phase un.
[00:45:33] Commencez à vous concentrer sur les besoins des utilisateurs.
[00:45:36] Tant de gens ne se concentrent pas sur les besoins des utilisateurs. Donc les bases absolues. Mais tout en haut à droite en phase quatre, est ma préférée, qui est la conception pour une évolution constante.
[00:45:50] Parce que c'est le monde dans lequel vous allez vivre.
[00:45:54] Euh, nous avons parlé du rapport Chaos, du rapport Standish Chaos sur le fait que 70% des projets logiciels échouent. Euh, le groupe Standish a publié un dernier rapport Chaos sur les projets logiciels qui dit en gros d'arrêter de faire des projets logiciels. Ne faites pas de projets logiciels, construisez simplement. Passez au produit. Nous devons arrêter de faire, euh, d'artificiellement découper le logiciel en projets. Commencez par courir un demi-mile aujourd'hui, un mile demain et c'est comme ça que vous vous améliorez.
[00:46:26] Donc l'architecture évolutionnaire, c'est l'évolution continue,
[00:46:32] l'architecture d'entreprise évolutionnaire continue plutôt que d'attendre ces améliorations 'big bang' et de laisser l'entropie s'installer. Ainsi, notre architecture d'entreprise moderne, encore une fois, aligne et cohére la valeur des personnes et de la technologie plutôt que ces alignements bilatéraux. Une meilleure valeur plus tôt dit pour plus heureux plutôt que ces anciens résultats de l'architecture d'entreprise. Gouvernance conversationnelle continue plutôt que le jalonnement par phases. DevOps à l'échelle de l'entreprise, plutôt que de se concentrer uniquement sur le changement.
[00:47:03] Et l'architecture d'entreprise évolutive plutôt que l'entropie dans l'amélioration occasionnelle et radicale.
[00:47:11] C'est tout. Merci beaucoup.
[00:47:19] Je ne pense pas que nous ayons le temps pour les questions, n'est-ce pas ? Si, si.
[00:47:23] Quelqu'un ?
[00:47:28] Non. Pas de question.
[00:47:31] Oh, une.
[00:47:34] Avez-vous déjà vécu des situations où vous commencez une architecture, c'est extrême, et puis après un certain temps, vous réalisez que vous avez besoin d'une autre transformation pour cela ? Donc c'est comme deux thèmes.
[00:47:47] Donc la question était, avez-vous déjà commencé une transformation et fait ce genre de modèle de ficus étrangleur et ensuite réalisé que vous aviez besoin d'une autre transformation en plus de cela ? Euh,
[00:48:01] oui. Vous devez être continuellement humble et ne pas supposer, encore une fois, que vous avez le plan d'architecte de style Matrix de la façon dont les choses doivent vraiment être. Les architectures cibles sont géniales, mais elles ne sont jamais figées. Et donc, la conception pour un changement constant est la clé absolue ici, en ayant cette humilité. Euh, oui, donc oui, absolument, il faut juste supposer que cela va arriver.
[00:48:35] Cool. Mes amis, merci beaucoup. Passez une excellente fin de journée.

Transcription (Traduit)