book

Faciliter l'architecture logicielle

by Andrew Harmel-Law

March 2025

Intermediate to advanced

512 pages

18h 48m

French

O'Reilly Media, Inc.

Book available

Read now

Unlock full access

Qui devrait lire ce livre ?Pourquoi j'ai écrit ce livreNaviguer dans ce livreConventions utilisées dans ce livreMatériel supplémentaireApprentissage en ligne O'ReillyComment nous contacterRemerciements
La pratique et le résultat final de l'architecture logicielle sont essentiels pour réussirQuelles sont les pratiques de l'architecture traditionnelle ?Architectes de la tour d'ivoireArchitectes de terrainQu'est-ce qui ne va pas avec les deux approches traditionnelles ?Cinq révolutions ont débloqué le pouvoir des logicielsLes effets des cinq révolutions sur la pratique de l'architectureL'essor de la décentralisationLa chute des pratiques d'architecture centraliséesQue doit offrir toute nouvelle pratique de l'architecture ?Aucune approche ne peut protéger contre les forces du chaosLes architectures doivent intégrer l'incertitudeLes architectures doivent permettre l'émergenceConclusion
Les décisions sont au cœur de l'architecture logicielleQu'est-ce qui constitue une décision architecturale ?StructureCaractéristiques transversalesDépendancesInterfacesTechniques de constructionQuelques exemples de décisions architecturales et non architecturalesQui prend ces décisions architecturales ?Décisions importantes sur le plan architecturalQu'est-ce qui rend une décision architecturale "significative" ?Qu'est-ce qui ne devrait pas être pris en considération en ce qui concerne l'importance architecturale ?Importance de l'architecture par rapport au logiciel déployéQuelques exemples de décisions architecturales importantesConclusion
Processus de décisionÉtape 1 : Décision requiseÉtape 2 : L'acte de décisionÉtape 3 : Mise en œuvre de la décisionOù se situe l'équilibre des pouvoirs dans les processus de décision ?Les approches architecturales traditionnelles n'exposent pas suffisamment les équipes à l'étape de prise d'options du processus de décision.Processus de décision à l'échelleApproches standard des décisions à l'échelleLes processus de décision dans un monde révolutionnéConclusion
La nécessité d'un processus de décision plus rapide et décentraliséLe processus de conseil en architecture : Une règle, deux groupes de conseil et un contratLe processus de conseil en architecture est rapideLe processus de conseil en architecture est décentraliséLe processus de conseil en architecture donne naissance à un contrat socialDeux exemples du processus de conseil en architecture en actionHistoire 1 : Une équipe de développement décide d'utiliser des bascules de mise à jourHistoire 2 : Un architecte décide de résoudre un problème de flux de travailLe rôle central du conseilLes conseils sont des suggestions d'orientation et de raisonnementLes conseils donnent de l'énergie aux faiseurs d'options et aux preneurs de décisionsDonner des conseils ne te rend pas responsable - prendre des décisions, siL'importance des conversationsL'importance de la confianceConclusion
Premiers pasSi tu as déjà le pouvoir de prendre des décisionsSi tu manques actuellement de pouvoir de décisionQuel que soit ton point de départ, commence petitSurmonter les défis des premières étapesExplique le processus de conseil en architecture à toutes les personnes concernéesDemande conseil aux bonnes personnesDemande aux bonnes personnes et découvre le "pourquoi".Explique qui est responsable de chaque décisionPréoccupations en matière de confiance découlant du processus de conseil en architectureManque de confiance en tes capacités de décision et en celles des autresManque de confiance dans la recherche et l'offre de conseilsManque de confiance pour savoir tout ce qui se passeConclusion
Présentation des enregistrements de décisions architecturalesLa structure d'un ADRTitreMéta-élémentsDécisionContexteOptionsConséquencesConseilsRédiger un ADR pour soutenir la prise de décisionÉtape 1 : Créer ton ADR vide et définir ses métadonnéesÉtape 2 : Rédiger le contexteÉtape 3 : Fais des choix et recueille leurs conséquencesÉtape 4 : Proposer une option choisieUtiliser les ADR pour faciliter le processus de conseilQuand et comment demander conseilMise en place de la section ConseilsRassembler des conseilsMettre à jour l'ADR pour refléter les contributions des autresPrends ta décision et termine le MARCSélectionne l'option de décisionRédige ta section de décision et mets à jour ton titreChange le statut de l'EIM en AcceptéPartage la décisionLe cycle de vie de l'ADRStatut des normes : Projet, Proposé, Accepté et RemplacéStatuts ADR non standardGérer les ADRAspects fondamentaux de la gestion des ADREIM sur les wikis et les fichiers de texte enrichi dans Source ControlLes EIM dans les systèmes d'enregistrement des travauxCurating ADRs (en anglais)Conclusion

La responsabilité et l'obligation de rendre des comptes ont évoluéLes pratiques de gouvernance les plus traditionnelles deviennent obsolètesLe processus de conseil est compatible avec les cadres d'architecture d'entreprise existantsLa responsabilité explicite de l'ADR est un frein à l'imprudenceLes équipes ne sont pas obligées de déciderL'espace d'exercice de l'architecture s'ouvreGarder de l'espace pour une culture de l'apprentissage et de la confianceDeux exemples de confiance (ou de manque de confiance) en actionTu ne peux pas supposer qu'une culture de confiance et d'apprentissage apparaîtra.Une culture de confiance et d'apprentissage doit être soigneusement entretenueComprendre la dynamique changeante des différentes tailles d'organisationsAdopter des éléments de soutien pour protéger l'espace de confianceProtéger l'espace d'exercice de l'architectureIl n'y a pas de prescription standard pour les éléments de soutienFais de n'importe quel élément de soutien le tienVérifie ta motivation avant d'ajouter quoi que ce soitNetflix : Un exemple de l'état d'esprit de recherche de fluxMéfie-toi des chants de sirène de la certitude et de la prévisibilitéExpérimente pour trouver le flux de ton organisationConclusion
Présentation du forum de conseil en architectureUn ordre du jour simple et permanentEn quoi un forum de conseil diffère-t-il des réunions d'architecture traditionnelles ?Animer un forum de conseil en architectureAvant un forum de conseil en architecturePartager l'agendaOuverture d'une session du forum de conseil en architectureIntroduction d'un ADRProposer et recevoir des conseilsEnregistrer les conseilsDynamique sociale au forum de conseilLes interactions architecturales sont antagonistes et hiérarchiques par défautArgumentation coalescente : Une alternative à l'argumentation contradictoireLe processus de conseil en architecture et les ADR en tant qu'approche coalescente de la prise de décisionLes forums de discussion catalysent une dynamique de groupe puissanteL'expérience des prestataires de services de conseilL'expérience des demandeurs de conseilsL'expérience des observateurs d'apprentissageParticipation partagée à la créativité concrèteLes forums de conseil en architecture favorisent l'intégrité conceptuelle et la cohésion socialeDécentraliser l'exécution tout en centralisant la coordinationExpertise approfondie du domaine : Quand la centralisation est la meilleure solutionLa transparence au service de la cohésion sociale et de la confianceLe rituel de renforcement de la cadenceLance le processus de conseil avec un forum de conseilMandatSi tu utilises le forum de conseil pour lancer le processus de conseilQui organise le forum des premiers conseils ?En quoi le premier forum de discussion sera-t-il différent des suivants ?Conclusion
L'importance de l'alignement organisationnelL'alignement ne garantit pas l'efficacitéDétecter un alignement organisationnel insuffisantQuatre moyens d'alignementTu es aligné quand tu n'es pas surprisAccord minimum viableExigences interfonctionnellesStratégie technologiqueVers un accord minimal viable pour ton organisationConclusion
Source Principes architecturaux de toutes les personnes impliquéesExemples de principes architecturauxCaractéristiques des bons principes architecturauxCaractéristiques des mauvais principes architecturauxLes principes peuvent être des exigences transversales déguiséesLes principes architecturaux complètent le processus de conseil et les ADRSaisis tes principes architecturaux grâce à un atelier sur les principesPréparer les intrants pour ton atelier sur les principesAtelier sur la mise en place de tes principesAtelier sur l'application de tes principesPrésente tes principes prêts à l'emploiGarder les principes utilesLa rétroaction des décisions devrait affecter les principes architecturauxMise à jour et maintien des principesLe retour d'information sur les décisions peut affecter la stratégie techniqueConclusion
Tendances technologiques de Sense et directives de captureLes radars technologiques recueillent et partagent continuellement des conseilsComment fonctionne le radar technologique de ThoughtworksTon radar technologique interne sera structuré différemmentLa place de ton radar dans un processus de conseilCréer ton radar technologiqueRassemblement BlipTri et validation des blipsBlip FocusingPositionnement du blipBlip DocumentingRadar PublishingMise à jour de tes BlipsBalayages périodiquesMises à jour ad hoc basées sur l'expérience partagéeCapturer les blips précédents et leur historiqueConclusion
L'importance du côté le plus douxDéfinir le contexteL'exclusion est aussi importante que l'inclusionQuestions qui améliorent le jugement autour de l'encadrementImplique les bonnes parties prenantesDiscerner les options et leurs conséquencesNe laisse pas le cadre limiter ta créativitéCherche l'inspirationAffine le contexte et les options grâce aux conseilsDéveloppe ta métacognitionExercice 1 : Partage tes raisonsExercice 2 : es-tu en train de réagir ou de répondre ?Exercice 3 : Cherche intentionnellement des conseils qui te mettent au défiFaire face aux personnes non coopérativesSélectionner une option de décisionVaincre la peurSurmonter les préjugésPrendre la décisionQuand tu prends la décisionQuand d'autres prennent la décisionConclusion
L'effet de la variabilité sur la pratique de l'architectureLa variabilité rend le développement des systèmes difficileLa variabilité est l'élément vital du développement de logicielsTravailler efficacement avec la variabilité architecturaleS'attaquer à la variabilité en prenant et en testant rapidement les décisionsTeste les décisions en profondeur en utilisant leur contexte fonctionnelUtilise des squelettes ambulants pour tester tes décisions les plus anciennes dans leur contexte fonctionnel.S'attaquer à la variabilité avec des décisions plus petitesL'impact des décisions architecturales sur le débit futurUne bonne infrastructure technique permet de prendre de petites décisionsUne bonne infrastructure sociotechnique permet aussi de prendre de petites décisionsUtilise le processus de conseil pour dissocier les décisions du flux.Faire appel à la variabilité pour combattre le risque et découvrir la valeurMieux vaut être rapide et mauvais que lent et correctObserve les aberrationsPrends d'abord les décisions les plus importantesConclusion
Trouver un chemin à travers la variabilitéPrésentation des pointesLes pointes peuvent s'attaquer à la variabilité architecturale à moindre coûtOù se situent les pointes dans un processus de décision ?Des ADR qui montent en flècheLes EIM en hausse suivent toujours le processus de conseilExaminer l'interconnexion des décisionsLes décisions sont une sérieLes décisions sont une hiérarchie inverséeLes décisions sont atomiquesLes décisions sont des conversations à deux voiesLes décisions interdépendantes sont socialement compliquéesConclusion
Les transitions de pouvoir ne sont jamais simplesLa transition pour ceux qui accèdent au pouvoirEst-ce que tout le monde croit avoir le pouvoir de décider ?Est-ce que tout le monde comprend ses responsabilités ?Pourquoi les gens n'utilisent-ils pas le pouvoir qui leur est offert ?L'importance de la sécuritéLa transition pour ceux qui doivent partager leur pouvoirLa peur chez ceux qui ont abandonné le pouvoirLe comportement de ceux qui n'aiment pas que le pouvoir soit partagéLes transitions sont inconfortablesConclusion
Idées fausses sur le leadershipIdée reçue 1 : le leadership est innéIdée reçue n°2 : le leadership est lié à la hiérarchieIdée fausse 3 : le leadership est unidirectionnelIdée reçue n°4 : le leadership, c'est de la gestionCe qu'est le leadershipLes 14 points de DemingLe leadership au service des autresLeadership adaptatifLeader-Leader LeadershipDéfis liés à la transition vers le leadership de chef de fileLa nécessité d'un leadership moral permanentRépondre aux défis morauxSois sensible à toutes tes cultures actuelles, mais n'y sois pas insensible.Il n'y a pas de "leaders permanents"Conclusion
La sous-culture du génie logicielRaison 1 : Le développement de logiciels ne suit pas les modèles mentaux standard de créationRaison 2 : Les taux de changement dans les services informatiques sont beaucoup plus élevés que partout ailleurs.Raison 3 : Les points de contact entre l'ingénierie logicielle et le reste de l'organisation sont peu nombreux et distincts.Raison 4 : Le fossé culturel entre le génie logiciel et le reste de l'organisation est déjà accepté.Conseils Bulles de processusLes bulles ne sont évidentes que pour ceux qui les cherchentLes bulles s'organisent d'elles-mêmesLes bulles sont perméablesAttentes externes sur les personnes à l'intérieur de la bulleAttentes évidentesAttentes moins évidentesLes bulles présentent une interface indépendante de la mise en œuvreLe contrat d'interface de la bulleRends explicite le travail de traduction qui a de la valeurFaire pousser des bullesCroissance progressive, équipe par équipeVeille à protéger les objectifs fondamentaux de ton cabinet d'architecteDiviser les bulles lorsqu'elles deviennent trop grossesRien ne peut pousser éternellementDiviser une bulle lorsque les objectifs fondamentaux de ton cabinet d'architecte sont menacésComment diviser ta bulleRester aligné d'une bulle à l'autreProtège et encourage les différences entre les bullesConclusion

Overview

Cet ouvrage a été traduit à l'aide de l'IA. Tes réactions et tes commentaires sont les bienvenus : translation-feedback@oreilly.com

Le rôle de l'architecte logiciel évolue. À mesure que les systèmes et leurs interactions avec les équipes qui les construisent, les exécutent et les font évoluer deviennent plus complexes, il est souvent impossible pour ceux qui jouent les rôles d'architectes traditionnels d'être partout où ils doivent être. Il y a tout simplement trop d'architecture à faire, et la situation a atteint un point de rupture. Il existe une meilleure façon de faire. L'auteur Andrew Harmel-Law vous montre comment les architectes et les équipes de développement peuvent collaborer pour créer et faire évoluer des architectures plus efficaces pour leurs systèmes. Les techniques présentées dans ce livre vous aideront à apprendre comment créer un état d'esprit qui permet à chacun

Il existe une meilleure solution. L'auteur Andrew Harmel-Law vous montre comment les architectes et les équipes de développement peuvent collaborer pour créer et faire évoluer des architectures plus efficaces pour leurs systèmes. Les techniques présentées dans ce livre vous aideront à apprendre comment créer un état d'esprit qui permet à chacun de pratiquer l'architecture et de construire les meilleurs systèmes qu'ils aient jamais expérimentés.

Avec ce livre, tu pourras :

Comprendre les nouvelles dynamiques qui affectent la livraison de logiciels modernes
Apprendre une méthodologie qui associe l'architecture logicielle et le développement
Nourrir l'interaction fondamentale entre les décisions, les conseils, l'architecture et le retour d'information des systèmes en fonctionnement
Initier des pratiques qui maximisent les avantages et atténuent les risques
Créer une approche adaptée à l'architecture, aux compétences de chacun et à la culture de ton organisation