アジャイルとは，必要最小限の要件と，必要最小限のアーキテクチャとのバランスである。対照的にウォーターフォール開発では，すべての要件を紙面に書き出した上で，それらの仕様に対してソフトウェアを構築する。これは長いプロセスである上に，実際のユーザからのフィードバックを欠いた製品が完成することも珍しくない。実行可能な最小限の製品を，最小限のアーキテクチャを使って開発することが必要なのは，そのためだ。
Kavis Technology社のブログにあるように，実行可能な最小限の製品を開発する上で課題となるのは，そのための適当なアーキテクチャが存在しないことだ。
私はまた，ひたすらアーキテクチャに注力する一連のスプリント(私たちは配管/plumbingと呼んでいます)へと進むチームを，いくつも見てきました。このアプローチでは行き過ぎとなり，エンドユーザに何の成果も見せられないまま，設計と開発に何ヶ月も費やすことがあります。これはアジャイルの目的に反しています。私たちに必要なのは，市場投入のスピードとアーキテクチャのバランスです。MVA(Minimum Viable Architecture/実行可能な最小限のアーキテクチャ)が必要なのです。
Kavis Technology社のブログの筆者は，アーキテクトが最小限のアーキテクチャを作る作業を支援する目的で，プロダクトオーナにいくつかの質問をするように推奨する。
- 最初のローンチ時点でシステムを利用するユーザの数は？当初６ヶ月は？年内では？
- ローンチ時のユーザは内部ユーザか外部ユーザか，その両方か？
- ローンチ時点で想定されるトランザクションは，1秒あたり何件か？当初６ヶ月は？年内では？
- ローンチ時点のプロダクトに期待されているのはアルファ版か，ベータ版か，あるいは製品準備版か？
- ローンチ時のシステムには，何人のユーザが追加される予定か？
- ローンチ時には，どのレベルのセキュリティと監査機能が要求されているのか？6ヶ月以内は？年内では？
Randy Shoup ConsultingのコンサルティングCTOであるRandy Shoup氏は，先日のプレゼンテーションで，実行可能な最小限のアーキテクチャについて説明した。氏はスタートアップする製品のアーキテクチャについて，製品調査，開発実施，スケーリングの各段階の面から説明する。
調査フェーズの間は"プロトタイプ"アーキテクチャを使用するべきだ，と氏は言う。可能な限り迅速かつ安価に，スペースを探ることが，ここでの作業の目標だ。実施フェーズでは"必要十分(Just Enough)"アーキテクチャを使用するとよい。この段階で目指すのは，ユーザの目標を最低限で満たすことだ。ここではモノシリックなアーキテクチャと，最小限のインフラストラクチャの利用が許可されている。"必要十分"アーキテクチャを使用することの利点は，次のとおりだ。
- 最初はシンプルに
- インプロセスのレイテンシ
- 単一のコードおよびデプロイユニット
- 最小限で効率的なリソース
必要最小限のアーキテクチャを使用している間は，モジュール性や詳細なログ，継続的デリバリなどを心がけるべきだ，と氏は言う。さらに，Thoughtworksのコンサルタントで著作者のMartin Fowler氏が提唱する犠牲的アーキテクチャ(Sacrificial Architecture)を引き合いに出しながら，必要十分なアーキテクチャのコンテキストにおいて，次のように述べている。
今書くことのできる最善のコードは，数年の後には破棄されることになるのです。
実施フェーズの後には，スタートアップのスケーリングフェーズが来る。このステージでチームが使うのは"次世代(Next-Gen)"アーキテクチャだ。目標は，急速に成長するビジネスの前を行くことにある。これにはチームのスケーリング，アーキテクチャのスケーリング，同時実効性と効率性への配慮などが含まれる。
完璧なシステムの構築が正しいアプローチであることはほとんどない。過剰設計のアーキテクチャを構築しようとしてはいけない。氏は言う。
当初の技術的判断を後悔することがないのであれば，おそらくそれは過剰設計です ... アーキテクチャの再設計は成功のサインです。その必要がないのならば，過剰開発だったのか，そもそも不要な開発だったのか，いずれかです。