犠牲的アーキテクチャ～リプレースを正当化するアーキテクチャ

「犠牲的アーキテクチャ」に関する記事をメモ。
ラフなメモ書き。

【元ネタ】
Martin Fowler氏の語る“犠牲的アーキテクチャ"

Martin Fowler's Bliki in Japanese - 犠牲的アーキテクチャ

akipiiさんはTwitterを使っています: "定期的なリプレースを正当化するアーキテクチャ。Martin Fowler氏の語る“犠牲的アーキテクチャ" http://t.co/cgjQXpf3v2"

神宮式年遷宮と犠牲的アーキテクチャ

Martin Fowler氏の語る“犠牲的アーキテクチャ” | InfoQ翻訳日記

Martin Fowler氏の語る“犠牲的アーキテクチャ"

【1】(引用開始)
システムあるいはアーキテクチャの陳腐化を前提として捉え、設計時からリプレースを意識しておくという、現実的ですが斬新な提案です。今後流行るかも知れません。

こうなると、ソフトウェアやシステムのコードも、資産というよりも負債になってきます。考え方を大きく変える必要がありそうですね。
(引用終了)

【2】昔は、基幹系業務システムを新規開発する時、１～３年かけて開発し、１０年かけて運用するような開発スタイルが多かった。
初期構築費や運用保守費用を考慮すると、５年で減価償却し、それから元を取っていくような原価管理になる。

このようなウォーターフォール型開発手法は、現代のように３年で技術革新がどんどん起きる時代には都合が悪い。
３年かけて頑張って作っても、開発当初から５年立つと、既にアーキテクチャやインフラが劣化ないし、陳腐化してしまっているからだ。

だから、業務システムは、サーバー増強ないしハード強化のタイミングで、OSやJavaやDBのVerUpも兼ねてリプレースする時も多い。
すると、数年かけて少し運用したら、すぐに全て壊して作り直すという開発を何度も繰り返すようになる。
ソフトウェアを作っている者としては、なにか無駄な気がする。

【3】しかし、「犠牲的アーキテクチャ」の概念を読んでみると、アーキテクチャを入れ替えてシステムをリプレースする手法を正当化する。
むしろ、アーキテクチャの寿命は短いから、数年でスクラップアンドビルドを前提として、システム開発すべきだ、と。

犠牲的アーキテクチャの事例としては、TwitterがRailsからScalaへ少しずつ切り替えた事例など、多々ある。
この辺りの事例を集めて、犠牲的アーキテクチャの本質を見出すのも面白いかも知れない。

【4】神宮式年遷宮と犠牲的アーキテクチャを読むと、犠牲的アーキテクチャは式年遷宮と同じ、という喩えがある。
式年遷宮の意図として、建物を定期的にリプレースして長持ちしやすくするだけでなく、建替えの技術の伝承を行うことがあるらしい。
その意図を踏まえると、「当時の寿命や実働年数から考えて、20年間隔が適当」ということらしい。
その意味では、「犠牲的アーキテクチャは式年遷宮と同じ」発想は面白い。

犠牲的アーキテクチャの考えを推し進めると、システムのロードマップや投資計画につながると思う。
長期間システムを運用する前提で、アーキテクチャをどのスパンで入れ替えて、最新技術を取り入れながら、初期構築コストを回収していくか。

つまり、単なる技術的観点だけでなく、システムのあるべき姿や開発コストも考慮して、初めてアーキテクチャが定まる。
アーキテクトの立場ならば、犠牲的アーキテクチャの考え方は重要になってくると思う。