Get best of the week

Agile nous apprend le vrai sens de l'architecture

image

Qu'est-ce que l'architecture? Pas des villes ou des bâtiments, mais une version organisationnelle: architecture d'entreprise, architecture de solution, architecture d'application, architecture logicielle, architecture d'entreprise, architecture d'infrastructure? Les cheveux sur ma tête commencent à bouger lorsque nous, architectes, nous tournons vers ce sujet avec nos tours d'ivoire ennuyeuses, créées pour la pensée qui amusent notre fierté. Mais cette fois, je dois aborder cette question, car elle est une condition préalable à l'examen du sujet de la dette (architecturale, technique) et de l'architecture, tous ensemble deviendront une histoire de trois articles.

Agile et ce qu'il dit de l'architecture


L'architecture est officiellement mentionnée dans le Manifeste Agile , qui stipule que l'un des principes fondamentaux est: "Les meilleures architectures, exigences et décisions de conception naissent dans des équipes auto-organisées."
Les meilleures architectures, exigences et conceptions émergent d'équipes auto-organisées.
(Tiré des principes du Manifeste Agile )

Le problème n'est pas seulement qu'il ne donne pas une définition de ce qu'est l'architecture, mais seulement d'où elle vient, mais aussi qu'elle est plutôt naïve .

Agile a non seulement des partisans sérieux (et je me considère parmi eux), mais aussi sa juste part de fanatiques qui ont tendance à croire (et parfois à forcer leurs dirigeants à croire) que «travailler sur l'agile» vous donne une capacité infinie de changement et que vous pouvez apporter toutes sortes de modifications , y compris de grosses conversions. Nous avons même des cadres assez grands tels que le cadre Agile à l'échelle (SAFe), qui peut être appliqué pour des changements basés sur des principes flexibles pour les niveaux stratégiques les plus élevés.

Ces cadres ont quelque chose en commun avec les cadres complets qui ont été créés précédemment (FEAF, MODAF, TOGAF, etc.). Personne n'utilise vraiment le tout. La portée des cadres n'est généralement pas facilement comprise par tous ceux qui travaillent dans leur contexte étroit. Il me semble que les fondements des pratiques de travail actuelles ont été extrapolés pour créer un cadre complet. Bien que le «remplisseur» n'ait jamais été testé, néanmoins, tout est entièrement vendu comme «meilleure pratique».

Regardons TOGAF et SAFe, ils sont fermement basés sur le monde du développement d'applications. Cela est évident lorsque TOGAF fonde l'une de ses deux définitions d'architecture sur la définition de l'architecture logicielle ISO.
– , , .
(: ISO/IEC/IEEE 42010:2011)

Ou, lorsque SAFe nous dit qu'il existe des fonctionnalités et des facilitateurs, et l'un des facilitateurs est l '"infrastructure" (bien que vous puissiez, bien sûr, résumer ce concept). Les cadres sont souvent un peu lourds de définitions et de détails, ils essaient d'être exhaustifs. Par conséquent, ils grandissent souvent avec le temps pour définir et embrasser de plus en plus. Mais les grands cadres ne sont généralement que partiellement utilisés, car le cadre complet dans la plupart des situations est un excès bureaucratique. Ce que l'on voit souvent dans la «maladie de la définition», le désir de créer des définitions strictes pour tout, y compris pour des choses qui ignoreront ces définitions dans la réalité ( Ludwig Wittgenstein ).

Alors que les grands cadres peuvent être considérés avec un œil critique, le concept Agile lui-même (mais pas nouveau) est en effet une réponse très pratique (au moins en partie) à la complexité et, surtout, à la variabilité. Agile est la réaction à la plupart des changements et transformations dans les organisations complexes d'aujourd'hui. Complexité car l'informatique permettait d'être complexe . Variabilité, car par rapport aux usines remplies d'équipements lourds, l'informatique est assez facile à changer. C'est encore du logiciel , et même du matérieln'a pas une telle durée de vie, par exemple, comme les murs d'un bâtiment. Les organisations complexes produisent aujourd'hui des changements plus autonomes que les organisations «papier» du passé. La cascade avec Big Up-Front Design (BUFD) est devenue si peu pratique que dans le monde d'aujourd'hui avec une charge informatique, elle est devenue presque impossible. Ainsi, nous obtenons une évolution parallèle de masse permanente dans nos organisations sur la base de nombreuses équipes (Agiles) travaillant en parallèle.
, - . - , , , . - — , — .
( , )



Comme je l'ai dit plus haut, les discussions sur «Qu'est-ce que l'architecture» sont généralement un gaspillage d'énergie, il est préférable de le dépenser pour développer de bonnes solutions de conception pour votre organisation. Il existe de nombreuses définitions de l'architecture, j'ai indiqué les plus largement utilisées ci-dessus. La maîtrise d'ArchiMate a une définition différente, et j'avoue que je l'aime en partie: l'

architecture d'entreprise consiste à comprendre tous les différents éléments qui composent une entreprise, et comment ces éléments sont interconnectés.

Il s'agit de l'Institute For Enterprise Architecture Developments. Ce n'est pas que je ne suis pas d'accord avec tout ce qu'ils écrivent, mais ce "O" ne dit pas "Comment" pour une raison quelconque. Et «comprendre» est un mot tout aussi glissant. Tout cela ne vous aide donc pas vraiment. Il existe de nombreuses autres définitions, issues du MIT, du gouvernement américain, etc. ".

Mais la définition qui correspond à mes propres sentiments était que Martin Fowler, dans son article bien connu de 2003, « Qui a besoin d'un architecte?". Là, il finit de définir l'architecture comme «des choses difficiles à changer». Ce n'est pas différent de la définition de Grad Buch, qui a dit:

Toutes les architectures sont des décisions de conception, mais toutes les décisions de conception ne sont pas de l'architecture. L'architecture représente des décisions importantes qui forment un système où l'importance est mesurée par le coût du changement.

(Remarque: une citation plus complète a un bon point sur «la science et l'art»). Je crois aussi fermement que l'architecture n'est, après tout, rien de plus que des décisions de conception, et que le désir de vraiment les séparer vient en partie de «[le désir] de parler des décisions de conception, mais [de vouloir] les gonfler pour que ils semblaient importants »(Fowler). Ainsi, dans notre monde de l'architecture, nous pouvons dire:L'architecture est des décisions de conception difficiles à modifier . Bien sûr, il est vraiment difficile de les changer uniquement lorsqu'ils ont été mis en œuvre. Le papier endurera tout et les lettres changeront facilement (sauf si vous êtes dans une discussion architecturale infernale de 6 mois). Mais l'architecture, en tant que mesure de l'importance des décisions de conception, est une bonne définition, et bien meilleure que dans ISO, ArchiMate, TOGAF, etc.

Cependant, il y a une subtilité avec la caractéristique «difficile à changer».

Supposons que vous ayez une solution de conception qui décrit à vos développeurs comment ils doivent structurer leur code Python. Si vous avez beaucoup de code, il faudra beaucoup de travail pour changer tout ce code d'une structure à une autre. En d'autres termes, c'est difficile. Par conséquent, cette solution choisie est «l'architecture», dans ce cas, l'architecture logicielle. Mais un développeur peut facilement ignorer cette décision et écrire du code qui fait les choses différemment. En fin de compte, il est facile d'apporter des «modifications» au logiciel. Bien qu'il soit difficile de changer toute l'architecture mise en œuvre, il est souvent assez facile de ne changer que des parties individuelles (voir Ralph Johnson ci-dessus). L'architecture est donc quelque chose de "lourd" qui se compose de beaucoup de "lumière". Vous le voyez à tous les niveaux, par exemple,si votre décision de conception consiste à utiliser uniquement des bases de données Oracle, et que tout à coup, des bases de données PostgreSQL distinctes apparaissent assez faciles à configurer et donc facilement visibles (ce qui rend votre paysage plus complexe, cela n'est généralement pas approuvé). Mais remplaceztout Oracle sur PostgreSQL dans votre paysage est lourd (et cela peut même ne pas être entièrement réalisable). Par conséquent, la définition suivante est formée:

Architecture - décisions de conception difficiles à supprimer complètement des implémentations.

(Bien que la contraction de Fowler soit «difficile à changer» dans la plupart des cas). Autre remarque concernant les «difficiles à changer», il peut être difficile de les supprimer en raison de la dépendance à l'égard des autres, par conséquent le sens du mot «mise en œuvre» est large, par exemple, changeant à la fois les fabricants et les consommateurs du service. Le «lourd» doit toujours être considéré du point de vue de votre organisation, un bon exemple de la raison pour laquelle le domaine de l'architecture est généralement plus large que celui d'une solution, d'un projet ou d'un produit.
Remarque: 1) Cette définition ne dépend pas du service informatique. 2) On peut affirmer que j'ai ainsi révélé le sens du mot "fondamental" dans la définition de "l'architecture" selon l'ISO.

Agile et Architecture, des extrémités différentes de la même échelle


Il s'avère une relation très intéressante entre le monde de l'Agile et le monde de l'Architecture. Agile est conçu pour apporter des changements le plus possible, pour rendre les changements faciles (ou du moins pas difficiles ). Et d'autre part: l'architecture, comme nous l'avons remarqué, est l'endroit où les changements sont difficiles . En d'autres termes, ils se situent aux extrémités opposées du spectre; ils représentent une oscillation fondamentale dans votre organisation.

Je soutiens Agile et déclare que c'est la meilleure façon d'apporter des changements à nos environnements commerciaux complexes chargés en TI. Mais cela signifie que tout ce que nous trouvons difficile à réaliser en utilisant des approches Agiles est de facto l '«Architecture». Agile nous apprend donc ce qu'est l'architecture .

Remarque: Il est important de noter que Agile prend beaucoup de Lean, qui était basé sur l'approche de Toyota pour les usines physiques. Toyota voulait rendre la production plus flexible pour faire face à la complexité. Mais il existe de nombreux aspects de cette configuration qui ne sont pas facilement traduits dans le monde de silex des logiciels. Par exemple, Toyota supportait une variabilité très limitée et la plupart des choses ne pouvaient pas changer. Dans le logiciel, tout peut changer, et il n'est pas vrai par définition qu'une méthode qui (légèrement, mais avec beaucoup d'effet) sous-optimise le processus de production physique puisse être la base d'un autre processus de production.

Alors, où trouvons-nous l'architecture, où Agile a-t-il des ennuis? Il existe plusieurs exemples évidents:

  1. feature/defect «», , . ( , , ESB ), . , . , , ( ), .
  2. Agile , , YAGNI (You Ain’t Gonna Need It) (just in time). SAFe Architectural Runway, features defects. SAFe , . SAFe « Runway», features «». YAGNI ( , «»). – , – . , , Agile , « , DevOps» (DRDC). , , Tomcat, JBoss, Session state storage , File sharing, Redis, MongoDB, MQ, IIS .. Lean ( ) YAGNI, , , «» («muda» « » Lean). , , , , ( «muru» «»). , , Runway , , .
  3. Agile , . , , , . , , Agile ( «muri» «»). , . Agile ( : ...) – .

Je m'excuse d'avoir utilisé librement les termes japonais ici. Ainsi, Agile se concentre sur le fait que l'architecture est un objet, pas une pratique, et l'esprit dit que: L'

architecture est chaque décision de conception mise en œuvre qui rend Agile difficile.

Le choix de ce que vous mettez dans votre «plan d'extension de piste» dépend de la difficulté de faire la transformation: c'est le choix de l'architecture. Et vous ne pouvez pas simplement laisser les propriétaires de produits sous la pression des utilisateurs. Le choix doit également être fait avec la participation des acteurs de l'architecture, il y a donc des freins et contrepoids contre les «bunkers» et «court terme». Plus d'informations sur l'architecture (en tant que pratique) dans la deuxième partie de cette mini-série d'articles.

Définir l'architecture comme une combinaison de «choses lourdes» n'est pas tout ce dont nous avons besoin. Parce qu'en plus d'être «dur», nous avons besoin de quelques recommandations quant à ce que nous devons viser avec l'architecture. On dit souvent que l'idée de l'architecture est de fournir de la flexibilité en créant des solutions flexibles. En fait, Fowler a déclaré que la tâche de l'architecte était de supprimer l'architecture. Mais c'est trop simple. La flexibilité est généralement coûteuse et ces «coûts» (temps et argent) ne peuvent pas augmenter indéfiniment (voir Johnson ci-dessus). Tout le monde veut que les solutions soient complètement flexibles, mais ce n'est pas bon marché (et personne ne veut payer les factures), ce n'est pas rapide, et même pas toujours possible. Parfois, la situation est simple: vous devez faire des choix qui seront difficiles à changer, vous ne pouvez pasprendre en charge toutes les options (par exemple, en choisissant une plate-forme, vous ne pouvez pas tout prendre en charge). Bien sûr, si le choix n'est pas très cher, choisissez des solutions flexibles ou repoussez le choix le plus longtemps possible (comme le suggère SAFe: ne limitez pas vos options). Mais en pratique, il faut souvent faire un choix. Un choix qui sera difficile à changer est un choix architectural. L'architecture cherche à minimiser l'inflexibilité inutile, car il est naïf de penser qu'il y aura un monde où tous les changements seront faciles et où rien ne sera difficile. Il y a des choses non moins importantes, et plus souvent encore plus importantes que la flexibilité. Je pense qu'il y en a trois: Fiabilité, efficacité et flexibilité - Robustesse, efficacité, flexibilité (REF).

En savoir plus sur REF, la pratique de l'architecture et la dette.dans la deuxième partie, mais je me souviens de la vidéo «Pourquoi l'architecture d'entreprise», que nous avons créée il y a de nombreuses années, à l'époque où nous faisions de l'architecture la plus flexible du monde de BUFD:


Écoutez votre médecin et votre avocat


Et en conclusion, l'architecture (en tant qu'objet) est celle qui est «lourde», mais on peut aussi dire que «l'architecture (en tant que pratique) est lourde». Ils sont étroitement liés, l'architecture (en tant que pratique) est difficile, car la complexité d'aujourd'hui rend le changement difficile et l'inconstance d'aujourd'hui rend le changement puissant. C'est pourquoi vous devez payer de bons architectes mégaoctets. Eh bien, peut - être pas , mais vous devriez certainement écouter de bons architectes et prendre leurs conseils très, très au sérieux. Il ne reste qu'une question simple: comment reconnaître un bon architecte?

More articles:


All Articles