第2段階のEoDが失敗すると・・・
第2段階のEoDは，相当な洞察力が必要だということがわかってきた。
第1段階のEoDの後，各仕様はソフトウェアアーキテクチャのさまざまな部位に当てはめられる。第1段階のEoDによって，仕様が「軸」と「箱」により定型的に分類されているはずなので，ソフトウェア的にも整理がつきやすくなっているはずだ。
仕様の整理がソフトウェアアーキテクチャに従っていれば，それをコードに落とす際の迷いはほとんどなくなる。さらに，整理された仕様をソフトウェア的に入れる「箱」を自動的に生成させることが可能となる。EclipseなどのIDEは「クラス生成」や「メソッド生成」などの機能を持っているが，ドメインに依存したソースコード生成を行うための自動生成ツールを準備することで，さらにプログラマの作業を軽減させることができる。最も効果が期待できるのは，struts-config.xmlやSpring FrameworkのapplicationContext.xmlなどだろう。これらの記述や保守は，分割が困難で記述量が多くなるため，困難を極める。自動生成ツールによってこれらの記述を一切なくすことで，さらに生産性は向上する。第2段階のEoDだ。
ドメイン依存の自動生成ツールをプログラマに提供することによる生産性の向上は，アジャイルな開発になればなるほど，その効果を体感できる。第1段階のEoDがしっかりしていれば，第2段階のEoDはますます威力を発揮する。
しかし，第2段階のEoDは単純ではない。失敗したときのダメージは相当なものになる。
本実装の作業は，自動生成ツールに完全に頼ったものとして考える場合，自動生成ツールの開発は，一般的には本実装前のプロトタイピングの作成段階で行われる。プロトタイピングは，徐々にソフトウェアアーキテクチャを育てていく作業なので，もちろん自動生成ツールも徐々に育てていくことができる。
ただし，このプロトタイピング段階で，本実装に関するすべてのパターンが実践されなかった場合，本実装に耐えることができる機能が自動生成ツールに搭載されなくなる。もし機能不足があった場合，自動生成ツールに対して機能追加を「本実装の際に」行わなければならない。
これは本実装の作業に致命的なダメージを与える。言葉で表せないほど，状況は深刻なものになるのだ。
自動生成ツールの機能不足が発覚した場合，自動生成ツールの機能追加が行われるまで，本実装の作業は完全にストップする。一般的に，自動生成ツールの改修作業は本実装の工数に含まれていないため，スケジュールの直接的な遅延が現れる。自動生成ツールの機能不足があればあるほど，本実装を進めることができなくなる。複数のチームで並行開発していれば，それらのチームがすべて機能停止となる。
「自動生成せずに手作業でコードを書かせればいいじゃん」という意見もあるだろう。しかし，将来的に自動生成されるコードというものは，自動生成ツールがどのようなコードを出力するのか理解していないといけないため，限られた人間しか記述できない。そもそも，本来自動生成されるコードは，単純になかなか書く気がおきない(どうせ後で自動生成されるんだから)。
ウォーターフォールな開発であれば，本実装の立ち上がりでは「見れるもの」ができてこないために，自動生成ツールの改修が発生しても，なかなか表面化しにくい。うまく「ごまかす」ことができるため，さして問題にはならないだろう。
しかし，機能ごとにイテレーティブに開発を進めるアジャイルを実践するとなると，短ければ「見れるもの」を週単位で作らなければならない。アジャイルの場合は，顧客がソフトウェアを目にする機会が多いため，こんな状況を見られてしまえば，場合によっては「何やってんだ！」とお怒りを食らってしまうだろう。そして，この状況を言い訳するのは，はっきり言って無理だ。
では，第2段階のEoDの失敗を防ぐためには，どうしたらいいだろうか。
自動生成ツールの機能不足を避けるためには，第1段階のEoDの結果を深く考察し，ソフトウェアアーキテクチャの細部まで理解し，さらに本実装に必要な実装パターンすべてを見据えておく必要がある。単に頭の中で考えているだけでは明らかに足りない。深く広い洞察力により導き出した実装パターンを，ソフトウェアの形で証明しなければならない(そうでないと自動生成ツールのコード出力仕様に自信が持てない)。つまり，「プロトタイピングを真剣にやる」しかないのだ。
プロトタイピングに関して，多くの開発者はその作業を「甘く」見ているだろう。本実装ほどスケジュールがタイトだと認識しないだろうし，動作不良があっても，多くの場合はそのままで許される。予定された目標を達成できなかったとしても，「プロトタイプだから」という理由で問題とされないこともしばしばだ。
しかし，「第2段階のEoD」としてプロトタイピングの工程を捉えれば，そんないい加減な気持ちは吹っ飛んでしまうだろう。自動生成ツールの機能不足が招く本実装作業の混乱と顧客からのお怒りを考えたら，如何にプロトタイピングが大事なものなのかは簡単に想像できるはずだ。
アジャイルであればあるほど，第2段階のEoDの効果は絶大だし，失敗した場合の影響も絶大だ。第2段階のEoDは，単に技術的な興味として捉えるのではなく，アジャイルにおける初期イテレーションの混乱を避けるための作業として考えるべきである。アジャイルな開発を採用する際には，第2段階のEoDのための作業に対して，一切の妥協をすることなく望むことが必要だ。そうすることで，「任せておけば安心だ」と顧客に思わせることができるだろう。
