10.4 大規模で長寿命なシステムの維持

概要と動機

ソフトウェアエンジニアリングについての文章の多くは、新しいものを築くことについてです。しかし世界の重要なソフトウェアの大半は、古く、大きく、いまも動いています。税のシステム、給付の支払い、航空管制、基幹の銀行業務、産業制御、日常生活のインフラストラクチャ。これらのシステムは、日常的に10年、20年、30年動きます。それは、築いた誰の在職期間よりもはるかに長く、それらを生んだ企業や言語よりも長いことがしばしばです。そうしたシステムを維持するとは、数十年と世代をまたぐ職員を通じて、信頼でき、安全で、理解され、変更できる状態に保つことを意味します。それは、この分野で最も難しく最も地味な規律の一つで、大企業と政府が最も重い負担を負う所です。

なぜ大きな組織にとってより重要なのでしょうか。義務の継続性です。スタートアップはソフトウェアを書き直したり放棄したりできます。国の政府は、リファクタリングしている間、年金の支払いを止められません。企業と機関は、失敗の結果が生計、安全、公的な信頼で測られるシステムを所有しています。そしてそれらの多くを同時に所有し、数十年にわたって入れ替わる人々が担当しています。中心的な脅威は特別なものではありません。システムを理解する人々の緩やかな侵食(バスファクター、つまりシステムの知識が失われるまでに何人が去るだけでよいか)、文書化されない知識が少数の頭に積み上がること、技術スタックが寿命の終わりに向かって朽ちること、そしてシステムが重要すぎて触れず、理解が乏しすぎて安全に変更できなくなったときに訪れる麻痺です。

この章はスチュワードシップについてです。システムがその作者より優雅に長生きするのを助ける、意図した地味な仕事。所有の継続とバスファクターの緩和、計画された廃止とサンセット、知識の移転、数十年にわたるシステムの特有の課題、そして市民と顧客が依存する安定性を、革新することと保つことの間の絶え間ないバランスの取り方を扱います。

主要原則

すべての重要なシステムには、常に所有者が必要である。 所有は継続的な割り当てであって、誰が書いたかの記憶ではありません。
一つの頭にある知識は資産ではなくリスクである。 その人が去る前に理解を制度化します。
退屈は機能である。 長寿命で重要なシステムでは、安定性と予測可能性が新しさをしばしば上回ります。
終わりは最初に計画する。 すべてのシステムはいずれ廃止または置き換えられます。その日のために設計し、文書化します。
変更こそ安全を保つ方法である。 触れるには恐ろしすぎるシステムはすでに失敗しています。変更する能力は生存の特性です。
継続性は個人より長く続く。 一人の離脱が危機にならないよう、チーム、文書、プロセスを設計します。
信頼こそ真のプロダクトである。 市民と顧客に向き合うシステムでは、時間をかけて保たれる信頼性と公正さが使命です。

推奨事項

スチュワードシップと所有の継続性を確立する

重要なすべてのシステムに、明示的で最新の所有を割り当てます。所有が離脱を生き延びるよう、個人ではなくチームの水準で所有します。各システムについて、誰が所有し、何をし、何に依存し、どれだけ重要かを記録するサービスカタログを保守します。所有を定期的にレビューし、システムが孤児になるのを決して許さないでください。所有者のいない重要なシステムは、起こるのを待っている緊急事態です。チームが再編されるときは、想定によってではなく、引き継ぎを伴って、意図して所有を移します。最も重要な長寿命のシステムでは、所有が運用だけでなく、システムを理解して変更する能力を含むようにして、スチュワードシップが単なる子守りに朽ちないようにします。

バスファクターと属人化のリスクを緩和する

知識の集中を積極的に測定して減らします。デプロイ、デバッグ、変更ができるのが一人だけなら、それはどんなハードウェアとも同じくらい現実の単一障害点です。ペアリングとローテーション、必須のコードレビュー、共有のオンコール、そして重要なタスクにちょうど一人の有能な人しかいないことがないという意図したルールで減らします。各必須の機能を少なくとも二人(できれば三人)が実行できるよう、相互訓練します。重要な人物の離脱を、吸収する衝撃ではなく、継続的に準備する予見可能な出来事として扱います。文書は役立ちます。しかし、実際の実践を通じてチームに広がった作業知識は、誰も演習していない文書よりはるかに耐久性があります。

知識の移転を制度化する

そうでなければ人とともに去る知識を捉えます。まず、再構成が難しい知識に集中します。なぜ決定がなされたか、どの代替案がなぜ却下されたか、鋭い縁とシステムの残りが静かに頼っている重大なハックがどこにあるか、ストレス下でシステムがどう振る舞うか。選択だけでなく選択の背後の推論を保つために、アーキテクチャ決定記録を使います。ランブックと運用文書をシステムの近くに保ち、真実であり続けるよう定期的に演習します。新しいスチュワードを本物の能力にまで導くオンボーディングの経路を築きます。離脱を、本物の引き継ぎ時間を伴う知識移転の出来事として扱います。システムの感覚である暗黙知は、それを持つ人の隣で一緒に行うことで主に移転されることを忘れないでください。可能な所では、去るスチュワードと着任するスチュワードを重ねます。

廃止、サンセット、寿命の終わりを管理する

終わりを意図して計画します。システムを廃止または置き換えると決めたとき、サンセットをそれ自体のプロジェクトとして扱います。すべての利用者と依存関係を特定し、移行の経路と現実的なタイムラインを用意し、明確に繰り返し伝え、移行の間、利用者を支援します。誰も古いものを止める難しい仕事をしないために、古いシステムと新しいシステムを永遠に並行して動かす罠を避けます。廃止を完了させる明示的な説明責任を割り当てます。システムが動かなくなったずっと後も、データ、記録、廃止されたシステムについての問いに答える能力を、特に法定の保持規則が適用される所で保ちます。まずく行われたサンセットは、保守されないがなお頼られるゾンビのシステムを残します。最悪の状態です。

数十年にわたってシステムを維持する

20年、30年動かなければならないシステムでは、すべてよりも長生きする計画を立てます。元のチーム、ベンダー、言語のエコシステム、ハードウェア。将来のメンテナーに機会があるよう、独自のブラックボックスよりもオープン標準と文書化されたインターフェースを好みます。リスクが高すぎて試みられない全部かゼロかの書き直しではなく、部品を一つずつ置き換えられるようにモジュール化します。システムを継続的に保守し続けます。小さなステップで最新に保たれたシステムは持続可能であり続けます。「動くから」と凍結されたシステムは、スタックがサポートから外れるにつれて、静かに保守不能になります。それを動かす技能も保ちます。本当に古い技術では、最後の専門家が引退しないことを願うのではなく、後継者を意図して訓練します。

革新と、安定と信頼のバランスをとる

新しさが価値を生む資産群の部分と、安定性が価値である部分を見分けます。市民と顧客が日々依存する中核のシステムは、通常、刺激的な書き直しよりも、信頼性、後方互換性、慎重な変更に報います。革新は縁(新しいチャネル、新しい機能、新しいインターフェース)に投資し、持続する中核を安定して十分に理解された状態に保ちます。中核も変えますが、英雄的な飛躍ではなく、小さく、元に戻せる、よくテストされた増分で。目標は、頼りになり、かつ進化できるシステムです。腐るほど凍結されることも、信頼できなくなるほど揺さぶられることもありません。

トレードオフ: 長所と短所

アプローチ	長所	短所
古いシステムを保って保守する	組織の知識を保つ。混乱が少ない。実証された信頼性	老朽化するスタック。乏しい技能。保守しなければリスクが積み上がる
一斉の書き直し	新しいスタック。蓄積した余計なものを捨てる	非常に高い失敗率。苦労して得た端のケースの知識を失う
増分的な近代化	継続的なリスクの低減。動き続ける	遅い。持続的な資金と規律が必要
文書重視の移転	明示的で検索可能な記録	保守しなければ朽ちる。暗黙知を見逃す
人ベースの移転(ペアリング/ローテーション)	持続的な作業知識。強靭なチーム	現在の生産性を費やす。意図した予定が必要
重要な中核を凍結する	短期的に最大の安定性	スタックが保守不能に老朽化する。触れるには怖すぎるようになる

決定的なトレードオフは安定性対進化で、素朴な解決はどちらも失敗します。重要なシステムを守るために凍結すれば、それが最終的に保守不能で安全でなくなることを保証します。近代化のために全面的に書き直せば、一斉の置き換えが悪名高い高い失敗率を招き、誰もそこにあると覚えていない、何十年分もの符号化された端のケースの知識を捨てます。持続的な道は、継続的で増分的な変更です。システムを小さなステップで生かして動かし続け、サポートから外れることも、恐ろしい飛躍を要することも決してないようにします。知識の移転にも似たトレードオフがあります。文書の容易さと、生きた経験の耐久性の間です。答えは両方です。生きた、チームが持つ知識を背骨に、文書を参照に。

チームで議論すべき問い

重要なシステムのうち、いま現在、名指しされたチームの所有者がいないものはどれですか。 所有は継続的な割り当てで、誰がコードを書いたかの記憶ではなく、所有者のいない重要なシステムは、壊れて初めて気づかれる、起こるのを待っている緊急事態です。サービスカタログを歩き(なければ作り)、すべてのシステムが、誰が所有し、何に依存し、どれだけ重要かを記録していることを確かめてください。証拠を持ち込んでください。重要なシステムを三つ選び、説明責任のあるチームと、所有が最後にレビューされた時を挙げてみます。システムが孤児になっている、あるいは再編で静かに落とされた所では、想定ではなく本物の引き継ぎを伴って、意図して所有を割り当てます。所有が、システムを理解して変更する能力を含むようにして、スチュワードシップが単なる子守りに朽ちないようにします。
システムを置き換えるとき、古いものを実際に止めることに、誰が説明責任を負いますか。 永遠の並行運用は、よくある高くつく失敗です。誰も停止を所有しないために、古いシステムと新しいシステムが無期限に並んで動き、二つのシステムを保守しながら、どちらの安全も得られなくなります。すべてのサンセットを、廃止を完了させる名指しされた説明責任、利用者の地図、移行の経路、現実的なタイムラインを伴う管理されたプロジェクトとして扱ってください。証拠を持ち込んでください。あなたの資産群で、「一時的な」並行運用や半分廃止されたシステムのうち、いくつが今日も保守を引き出していますか。システムが動かなくなったずっと後も、法定の保持規則を満たすためにデータと記録を保ちますが、保持を、決して終えないための言い訳にしないでください。まずく行われたサンセットは、保守されないがなお頼られるゾンビのシステムを残し、最悪の状態です。
長寿命のシステムのどの技能を、労働市場が供給しなくなり、後継の計画は何ですか。 20年、30年動くシステムは、その言語のエコシステム、ベンダー、古いスタックを理解する人々のキャリアより長生きし、市場が確実に代わりの人を渡してくれるとは限りません。重要な機能にちょうど一人の有能な人しかいないことがないよう、バスファクターを意図して減らし、各必須のタスクを少なくとも二人、できれば三人が実行できるよう相互訓練します。証拠を持ち込んでください。老朽化する各重要なシステムについて、安全に変更できる人の数と、最も知識のある人々が引退にどれだけ近いかを数えます。答えは、後継者の意図した訓練と、去るスチュワードと着任するスチュワードの本物の重なりを駆動すべきです。暗黙知(システムの感覚)は、それを持つ人の隣で行うことで主に移転されるからです。文書は参照で、生きた、チームが持つ知識が背骨です。
最も重要な長寿命のシステムを最後に変更したのはいつで、誰かまだ敢えてそうしますか。 1年誰も触れていないシステムは安定しているのではなく、「触るには怖すぎる」罠へとずれています。すべての変更が恐れられ、だからスタックが静かにサポートから外れていく罠です。大きな組織では、麻痺は複合するのでこれが重要です。凍結が長いほど、知識は薄れ、いずれ避けられない変更のリスクは高まります。証拠を持ち込んでください。各重要なシステムについて、最後の意図した変更の日付、今日誰かが試みるであろう最小の変更の大きさ、通常の依存関係やセキュリティのパッチが、英雄的行為なしに今週出荷できるか。相反する考慮は本物で、変更もリスクを持ち込むので、目標は揺さぶりではなく、小さく、元に戻せる、よくテストされたステップの安定した周期です。凍結された中核が市民サービスの下に10年座りうる企業と政府の資産群では、「決して変えない」を安心ではなく警告のサインとして扱い、変更する選択肢を生かし続ける継続的な保守に資金を出してください。
資産群のどれだけが、寿命の終わりあるいはその近くの技術で動いていて、その時計を誰が追跡していますか。 老朽化したランタイム、サポートされないデータベース、保守の切れたフレームワークは、セキュリティパッチが届かなくなった日に突然の危機に変わる、緩やかな失敗の様式です。大きなチームでは、危険は誰も地平線を所有しないことです。個々のチームは壊れたものにパッチを当てますが、どのスタックがいつベンダーのサポートを失うかのポートフォリオの視点を誰も保ちません。証拠を持ち込んでください。各重要なシステムの中核の技術、公表された寿命の終わりあるいはサポート終了の日付、動かしているものとまだサポートされているものとの現在の隔たりの目録。緊張は、継続的なアップグレードのコストと、先送りのリスクの間にあり、先送りは、壊滅的に負けるまでは通常勝ちます。調達と認定のサイクルが1年以上かかりうる企業と政府の設定では、遠く見える寿命の終わりの日付は、しばしばすでにリードタイムの内側にあるので、後継とアップグレードの仕事は、時計が尽きるずっと前に始めなければなりません。
資産群のどこで安定性が価値で、新しさが負債であり、その境界をどう誠実に保ちますか。 すべてのシステムが同じ扱いに報われるわけではありません。市民と顧客が日々依存する中核のシステムは、通常、信頼性と慎重な変更に報い、縁は実験に報いるので、二つを混同することはお金を無駄にするか、停止を招きます。大きな組織では、リスクは、野心とキャリアのインセンティブが、退屈であり続けるべきまさに持続する中核に、刺激的な書き直しを押し込むことです。証拠を持ち込んでください。信頼性が使命である所と、新しさが価値を生む所に印を付けた資産群の地図に加え、その線をどちらの方向にも越えた最近の変更と、それが何を代価にしたか。相反する考慮は、安定した中核でも進化しなければならないので、「安定」を凍結の言い訳にしてはならないことです。企業と政府の文脈では、この境界を、明示的な重要性の階層と、公衆が失敗を見る余裕のないシステムの危険な書き直しに拒否権を持つ名指しされた権限に結びつけ、判断が、今四半期に最も声の大きい人とともにずれないようにしてください。

セクター別の視点

スタートアップ。 少数のエンジニアとわずかな滑走路では、維持のリスクは、請求や認証のように、失うわけにいかないシステムを書いた一人か二人に集中しています。プロセスにはほとんど使わず、安く価値の高いことを今行ってください。各重要なシステムを通じて二人目をペアで付け、意外な部分について1ページのアーキテクチャ決定記録を書き、実際に使うランブックを保ちます。古いというだけで何かを書き直したい衝動に抵抗してください。あなたの規模では、中核のシステムの失敗した書き直しが会社を終わらせうるからです。

小規模事業者。 専任の保守チームはおらず予算も厳しいので、自分で維持しなければならないものを築くより、買ってホストすることを好んでください。離れることを可能にするベンダーとオープン標準を好み、どの外部システムがどの重要な機能を動かし、壊れたときに誰に電話するかの平易な記録を保ちます。自社でカスタムコードを所有する所では、一人の離脱やサポート契約の失効で取り残されないよう、少なくとも二人(または信頼できる請負業者と従業員一人)がそれを理解するようにします。

大企業。 課題はポートフォリオの規模です。多くの長寿命のシステム、多くのチーム、数十年にわたって入れ替わる職員。チームの水準の所有をサービスカタログで標準化し、資産群全体でバスファクターを測定し、一斉の書き直しに賭けるのではなく、継続的で増分的な近代化に資金を出してください。重要なスタックが静かにサポートから外れないよう、寿命の終わりの地平線を中央で統治し、すべてのサンセットを、廃止を完了させる名指しされた説明責任を伴う監査されるプロジェクトとして運営します。

政府。 義務の継続性は絶対です。リファクタリングしている間、給付を止めたり航空管制を止めたりはできず、失敗は公的で重大です。調達規則は、将来のメンテナーと将来のベンダーに機会があるよう、オープン標準、データの可搬性、文書化されたインターフェースへと導きます。労働市場がもはや供給しない古い技術のために、意図した後継の訓練に資金を出し、法定の保持を満たすために廃止されたシステムの記録を保ち、市民サービスの持続的な信頼性を、間接費ではなく説明責任のある使命として扱ってください。

事例

スタートアップ。 5人のスタートアップには、すでに失うわけにいかないシステムがあります。一人の創業者が最初の月に書き、いま顧客のすべての課金を動かしている請求サービスです。その創業者だけがそれを理解しているので、チームはバスファクターを、称賛ではなく本物のリスクとして扱います。二人目のエンジニアを完全な請求サイクルを通じてペアで付け、変わったリトライのロジックがなぜあるかを説明する短いアーキテクチャ決定記録を書き、インシデントの間に実際に演習するランブックをコードの隣に保ちます。古くて地味だからというだけで書き直すことには抵抗し、代わりに小さな元に戻せるステップで改善するので、会社を生かしているサービスが、一つ以上の頭に理解されています。

大企業。 大手の保険会社は、数十年前に最初に書かれ、いまも事業の中心にある保険契約管理システムを動かします。危険な全面的な書き直しを試みる代わりに、システムを明確に定義されたインターフェースの背後にモジュール化し、いまは一度に一つのコンポーネントを置き換えます。各変更は小さく元に戻せます。すべての重要な機能を実行できる人が少なくとも三人います。オンコールは共有されています。アーキテクチャ決定記録が、システムがなぜそう動くかを捉えます。選り抜きの社内コースが新しいエンジニアをレガシースタックの能力に導き、去る専門家は後継者と重なるので、暗黙知は行うことで移転されます。

政府。 国の社会保障機関は、30年以上動き、止められない給付支払いのシステムを運営します。サービスカタログに明示的なチームの所有を記録します。システムを凍結するのではなく、継続的な保守に資金を出します。労働市場がそれらを供給しないので、古い技術の後継者を意図して訓練します。時代遅れのサブシステムを廃止するとき、サンセットを管理されたプロジェクトとして運営します。すべての利用者を地図にし、移行の支援を提供し、法定の保持規則を満たすために記録を保ち、廃止を実際に完了させる説明責任を割り当てるので、ゾンビのシステムが残りません。

ビジネスケース: 動機、ROI、TCO

長寿命のシステムを維持する見返りは、その総所有コストを支配する二つの壊滅的な失敗の様式を避けることから来ます。第一は突然の危機です。重要な人が去る、サポートのないコンポーネントが侵害される、あるいは孤児のシステムが、それを理解する人がいないまま失敗する。第二は失敗した巨大プロジェクトです。超過し、期待に届かず、あるいは崩壊する、急いだ全面的な書き直し。どちらも莫大に高価で、どちらも着実なスチュワードシップで大部分は防げます。避けられた一度の書き直しの失敗のコスト、あるいは重要な市民サービスの避けられた一度の長期の停止は、通常、何年もの持続的な保守の投資を上回ります。

採用のコストは継続的で地味です。新しい機能を生まない保守に資金を出し、短期的な生産を減らす相互訓練と文書化の時間に払い、見出しにならない増分的な近代化に投資します。採用しないコストは、先送りされてより大きくなります。スタックが老朽化するにつれて増すリスク、膨らむ属人化の露出、そして最終的に緊急事態のもとでの強制された、高リスクで高コストな置き換え。リーダーシップに論拠を示すときは、保守を「コストセンター」から「組織が失うわけにいかないシステムのためのリスク管理」へと捉え直してください。構築だけでなく、維持と最終的な廃止を含む、数十年にわたる全寿命の総所有コストを示します。そして次のことを強調してください。市民と顧客に向き合うシステムでは、持続的な信頼性は間接費ではありません。実際のプロダクトである信頼です。

アンチパターンと落とし穴

英雄のメンテナー。 システムを理解する、代えのきかない一人。その離脱は存在に関わる出来事であること。
凍結して忘れる。 重要なシステムを「完成」と宣言して保守を止め、そのスタックが保守不能に老朽化するのを見ること。
運命づけられた書き直し。 符号化された知識を捨て、通常は超過あるいは失敗する全面的な置き換えに組織を賭けること。
孤児のシステム。 現在の所有者がなく、壊れて初めて気づかれる重要なソフトウェア。
文書の劇場。 古く、演習されず、誰も信頼しない大量の文書。
永遠の並行運用。 停止に誰も説明責任を負わないため、古いシステムと新しいシステムが無期限に並んで動くこと。
暗黙知の喪失。 重なりなしに専門家を去らせ、システムの感覚が蒸発すること。
触れるには怖すぎる。 あまりに理解が乏しく、どんな変更も恐れられるシステム。それが朽ちることを保証すること。

成熟度モデル

レベル1: 開始。 維持はその場しのぎで反応的です。システムは個々の英雄に依存し、所有は割り当てられるのではなく記憶され、知識は文書化されずに少数の頭に住んでいます。古いシステムは壊れるまで凍結され、老朽化するスタックは気づかれずに寿命の終わりへとずれ、廃止は告知されるが完了されません。

レベル2: 発展。 基本的な実践が現れますが、チームごとに異なります。所有は最も明白な主要なシステムについて書き出され、いくつかのランブックと文書が存在し、少数の重要な機能に二人目の有能な人がいます。保守には資金が出ているが反応的で、相互訓練は誰かが思い出したときに起こり、組織全体でそのどれにも共有の方法がありません。

レベル3: 標準化。 スチュワードシップの実践が文書化され、組織全体で徹底されます。チームの水準の所有がサービスカタログに記録され、再編を生き延びます。ローテーションと相互訓練によるバスファクターの緩和は常設のルールで、アーキテクチャ決定記録と演習されたランブックが期待され、近代化は方針として増分的で、すべてのサンセットは、廃止を完了させる名指しされた説明責任を伴う管理されたプロジェクトとして運営されます。

レベル4: 管理。 維持が、ベースラインに対するデータで測定され制御されます。重要なシステムごとのバスファクター、それぞれを安全に変更できる人の数、すべての中核の技術の寿命の終わりの日付に対する古さ、継続的な保守対先送りの保守にある資産群の割合、停滞した並行運用と半分終わった廃止の数を追跡します。これらの指標には、行動を引き起こす閾値があります。バスファクターの下限を下回る、あるいはサポート終了の地平線を越えたシステムには、資金のある是正が行われ、スチュワードシップの健全性が、デリバリーと並んでリーダーシップに報告されます。

レベル5: オーケストレーション。 スチュワードシップは継続的に改善され、組織全体に統合されています。どの重要なシステムも、人間の単一障害点ではなく、重なりを通じた暗黙知を含む知識の移転は日常的で、システムは小さく元に戻せるステップで進化するので、サポートから外れるものはありません。所有、寿命の終わりの追跡、後継、サンセットの計画は、ポートフォリオとリスクの計画に織り込まれ、技術と義務が移るにつれて資産群が再均衡され、数十年にわたるシステムが、それに依存する人々の信頼を保ちながら維持されます。

議論のためのアイデア

バスファクターをどう意味ある形で測定し、重要性の水準ごとに正しい目標は何ですか。
増分的な近代化が本当に実現不可能で、書き直しのほうが小さなリスクになるのはいつですか。
スチュワードシップが行き止まりではなく尊敬されるキャリアの道になるよう、保守の仕事にどう資金を出して報いますか。
最後の専門家が引退しようとしていて重なりが不可能なとき、暗黙知を保つ正しい方法は何ですか。
廃止されたシステムについての問いに答える能力を、どれだけの期間保つべきで、誰がそれに払いますか。
資産群のどこで安定性が価値で新しさが負債であり、その判断を時間とともにどう誠実に保ちますか。

要点

重要なソフトウェアの多くは古く長寿命です。数十年とスタッフの世代をまたいでそれを維持することは、第一級の規律です。
すべての重要なシステムには、最新のチームの水準の所有が必要です。孤児の重要なシステムは潜在的な緊急事態です。
バスファクターを意図して減らし(重要なタスクにちょうど一人の有能な人しかいないことがあってはならない)、文書だけでなく重なりを通じて暗黙知を移転します。
長寿命のシステムを継続的かつ増分的に保守し続けます。凍結することも、全面的な書き直しに賭けることも、どちらも失敗の様式です。
終わりを、説明責任のある完了を伴う管理されたプロジェクトとして計画し、義務を満たすためにデータと記録を保ちます。
市民と顧客に向き合うシステムでは、持続的な信頼性と公正さが使命であり、保守は失うわけにいかないもののためのリスク管理です。

参考文献とさらなる読み物

Michael Feathers, Working Effectively with Legacy Code
Titus Winters, Tom Manshreck, and Hyrum Wright, Software Engineering at Google
Frederick P. Brooks Jr., The Mythical Man-Month
Nat Pryce and Steve Freeman, Growing Object-Oriented Software, Guided by Tests
Sam Newman, Monolith to Microservices
Martin Fowler, Refactoring and writings on the Strangler Fig pattern
Betsy Beyer et al., Site Reliability Engineering and The Site Reliability Workbook (Google)
Diomidis Spinellis, Code Reading: The Open Source Perspective
U.S. Government Accountability Office, reports on federal legacy IT modernisation