ソフトウェアを開発するチームには，寿命の長いソフトウェアアーキテクチャを選択する傾向がある。しかしながら，ハードウェアとソフトウェアの技術動向とネットワーク速度の急速な変化は，アーキテクチャの大きな変更やコードベース全体の廃棄を必要とする。同じ文脈で，Thoughtworksのコンサルタントで著作者のMartin Fowler氏は，先日のブログ記事に"犠牲的アーキテクチャ(Sacrificial Architecture)"という考え方を紹介した。
犠牲的アーキテクチャとは，チームが現在開発しているものが，数年後には破棄しなければならなくなる(そうなってほしい)という事実を，現時点で受け入れるという意味だ。その時のリプレースが容易になるように今から考慮しておく，それが犠牲的アーキテクチャだ，と氏は言う。しかしソフトウェアの設計において，ソフトウェア技術者がリプレースのサポート方法を考えることはほとんどない。
多くの人々にとって，コードベースの廃棄とは失敗の象徴なのです。ソフトウェア開発が生来持っている調査的性質を考慮すれば，理解できない状況ではありませんが，それでも失敗であることに変わりありません。しかしながら，現時点で作成可能な最善のコードが数年後に廃棄されるというのは，決して珍しいことではないのです。
氏はeBayを例に挙げ，同社がperlスクリプトからC++コードへ，そしてjavaコードへと移行したことを，犠牲的アーキテクチャに関連付ける。1996年のe-bayをサポートするのに適切であったアーキテクチャは，2006年のe-bayにとっては適切なものではない。1996年のアーキテクチャでは2006年のロードを処理できないし，2006年のバージョンは1996年時点のニーズに対して，開発，保守，そして発展性の点で複雑に過ぎるのだ。
EPAM Systemsの開発者であるDmitry Cheryasov氏も同じく，変化するビジネスニーズのための犠牲的アーキテクチャを支持する。氏はY Combinatorの議論で，次のような自身の見解を公開している。
適当な時期の再構築を意識しながら開発を行うのです。使い捨てのプロトタイプを実運用しているようなものです。ビジネスが拡大すれば，それまでのコードベースの一部，あるいはすべてを捨てなければならないかも知れません(eBayが２回やったように)。それまでのソリューションが間違っていたのではありません。その時点では，それで十分だったのです。
Google上級研究員のJeff Dean氏は，自身のプレゼンテーションで，コードが古くなり過ぎる前に再設計ないし破棄を行うということを述べている。
Xに対して適切な設計は，10Xないし100Xについては非常に不都合かも知れません ... ～10Xの成長を前提として設計して，～100Xの前に再開発を計画しておくべきでしょう。
ソフトウェアシステムの初期においては，ソフトウェアが本当に行うべきことがまだ不確実である，従ってパフォーマンスや可用性よりも機能変更に対する柔軟性を重視するべきだ，とMartinは言う。Stack OverflowとStack Exchange Networkの創設者のひとりであるJeff Atwood氏は，”パフォーマンスはひとつの機能”というフレーズを作り出した。すなわちパフォーマンスは，他の機能に対して優先順位を付けることが可能なのだ。当初はそれほど高い優先順位ではないが，開発ステージの後半になると順位が高くなってくる。
犠牲的アーキテクチャは品質の欠如にはつながらない，とMartinは言う。優れたコードベースの鍵となるのはモジュール性だ。
適切なモジュール性は，優れたコードベースのための重要な部分であると同時に，一般論としてはシステムのリプレースにも非常に有効です。リプレースの基礎知識として活用する上で，最善のモジュール構造がどうあるべきかを探求することが，システムの初期バージョンにおいて最も行うべきもののひとつであることに疑いはありません。システムの初期段階においては，システム全体を犠牲にすることも合理的かも知れません。しかし，システムが成長するにつれて，個々のモジュールを破棄する方がより効率的になってきます。そして，それが可能なのは，モジュールのバウンダリが適切である場合に限られるのです。
JavaScriptMVC，CanJS，jQueryPPの作者のひとりでjQueryコンサルタントのJustin Meyer氏は，先日のブログ記事に，モジュール化することの重要性を次のように書いている。
モジュール性は，メンテナンス可能なアプリにとって，最も重要な特性です。モジュール化されたアプリは無駄になりません。パーツの変更や交換，あるいは破棄といった操作を，アプリの他の部分に影響することなく行うことができるのです。
犠牲的アーキテクチャを開発しているチームは，その時間を犠牲にすることを決意したのであって，そのコードが将来的に破棄されるものであることを知っておいた方がよい，とMartinは述べている。