「Building Evolutionary Architectures」を読んだ

Building Evolutionary Architectures: Support Constant Changeを読みました。

“Evolutionary”というものをどう表現しているのか、そのケーススタディを知ってみたいと思ったからです。

Evolutionaryとは、小さく変更をくわえながら、フィードバックループを回し、どのようにシステムを開発していくかを学ぶというところをいっているようです。その要素としてCI/CDの環境を作っていたり、例えばMicroservicesなどの話が出たり、チーム構成の話にも及んでいるところがあり、なかなか面白いものでした。チームの話だと、そういえば”Culture”という言葉も度々出てきたので、そういう環境づくり含めた全体の、文字通り”システム”（複雑系）を対象として設計するというものという印象を持ちました。

Fitness Functionと表現している、拡張していくような機能を対象に、その機能を壊さずに変化させていくか、というところでどのようなプラクティスがあるかとか書かれていました。そのように変化させていくことを”incremental change”というような表現を使ってたりします。Microservicesの文脈で度々目にするConsumer-Drivern Contractsの話も出ていました。この書籍を読んでいると、様々な小さなチームの責任範囲が重なる(もしくは重ならない)、システムの境目となるところを横断的な、例えば横断組織としてのテストチームがケアする、などにも言及していて、Consumer-Drivern Contractsが単なるツールの話ではなく、むしろそういう境目に対する話に絞っていたのはよかったです。（Pactガーというような言葉だけで終わらなかった）
もちろん、そういうテスト/品質をみる人は各々の責任領域ベースでのチームにいたりしてるけれど、横断的な人の役割などを別途明言しているところがよかったですね。

Re-engineering Legacy Softwareなど読んでいると、色々なところで話が重なっているところが見えたりするかと思います。また、Servive Oriented ArchitecturesやEvent Driven Architectures、Service Based Architectures、Serverless Architecturesなどのツール側の設計の話もありました。これらの説明、システム間の関係、要素技術などを整理してたりします。ある程度知ってる人には良い要点整理になるかと思います。

Amazonの有名な2枚のビザの話もコラムにありました。

Each team is cross-functional, and they also embrace the philosophy of “you build it, you run it,” meaning each team has complete ownership of their service, including operationalizing it.

ということをいっていて、それを最適化するような活動までを責任持つことを意味すると書いているところが個人的には好きだった。

そういえば、”Culture of Automation”という言葉も出てきていて、やはりどこまで自動で(短時間で)実行できる環境を作るかは基盤要素なのだなと感じました。