「データモデルにもとづいて動作するプロトタイプ」を「本番システム」の実装に先行して組み立てることで、システム仕様の妥当性を早期に確立する。このスタイルを「モデリング＆プロトタイピング手法」と呼んで実践している。的確なデータモデルをまとめあげることの難しさを考えた場合、実際に動作するプロトタイプを動かしながらモデルの妥当性を見極めるやり方には合理性がある。データモデルは情報システムの骨格に相当するものであるからだ。
とはいえ、プロトタイピングするだけで適切なデータモデルが完成するわけではない。じっさいのところ、プロトタイプが完成した後の「本番開発」においても、データモデルは変化を止めない。それはデータモデルが鍛錬されつつ成長し続けていることの（十分条件ではないが）必要条件である。当初からほとんど変化していないとしたら、むしろ危険な兆候だ。
いっぽうで、データモデルが「変化し続けているが、いつまでたってもまとまらない」といった状況も生じ得る。上述した「変化し続けているが、着実に成長している」や「当初からほとんど変化していない」との違いはどこにあるのだろう。直観的には次図のような違いとして説明できる。縦軸はデータモデルが取り得る仕様のバリエーション（仕様空間）で横軸は時間だ。
▼データモデルの変化の３パターン 
「成長型変化(a)」では、変化の振幅が次第に小さくなって一定の場所に落ち着くような動きを示す。いっぽう「乱数型変化(b)」では、変化の振幅がランダムに変化し、目指す場所もわからないような動きを示す。「緩慢型変化(c)」ではほとんど変化が起こらないまま時間が過ぎてゆく。換言すれば、(a)はゴールが次第に明確になってゆくような自律的な動きで、(b)は粒子のブラウン運動のように他律的だ。(c)は当初のゴールを着実に目指しているように見えるが、そもそもそのゴールが妥当であるかどうかわからない。
これらは、目指すべきゴールが明確でないような活動、すなわち「創作活動」がたどる一般的なパターンだ。言うまでもなく、(a)をたどればプロジェクトは成功で、(b)や(c)をたどれば失敗である。それらがなぜ失敗といえるのか。探索的失敗（変化）の蓄積によって、向かうべき方向性が明らかにされていないからだ。生み出された仕様を「これではない」とみなして捨てて考え直す。これを何度も繰り返すことで、成果物の方向性は見えてくる。「数多くの失敗」と、それらを失敗とみなしてバッサリ捨てるための「一貫した美意識」のようなものが、この種の創作活動には欠かせないということだ。もちろん、システム設計も創作活動に分類される。
ちなみに、(b)はアジャイルプロジェクトが陥りやすいパターンである。全体で100個のテーブルを含む情報システムをいくつかのイテレーション単位に分割し、それぞれについて「いい感じのUI/UXを具えたアプリ」を組み立て、その動きを支えるようなテーブル定義をあてがう。このやり方では、それぞれの単位がそれなりに良く出来ていても、広域のデータモデルとしてまとまることが保証されない。単位毎の仕様は、システム設計に関して素人であるユーザやプロダクトオーナーの意向にしたがって他律的に決まってゆく。結果的に、全体感や統一感に欠けた鵺（ぬえ）のような情報システムが出来上がる（出来上がればの話だが）。
現実に頻出するのは(c)で、とくにシステム刷新プロジェクトが陥りやすい。グラフで表されている動きが「データモデルの変化の度合い」であることを思い出してほしい。なぜ(c)でモデルが緩慢にしか変化しないかというと、DB構造について旧システムを必要以上に順守してしまうためだ。
じっさい、顧客は情報システムの問題がDB構造にあることをふつうは認識できないので、UI/UXの古臭さや使いにくさばかりが話題にされやすい。業者としてもDB構造を見直すノウハウがないうえにデータ移行の手間も引き受けたくない。それゆえ、「これまで蓄えたデータは御社の貴重な資産です。DB構造の変更には慎重であったほうがいい」なんてアドバイスさえして、DB構造については現行踏襲するように顧客を誘導する。かくして、大枚をはたいたあげくに「最新の建材で刷新された竪穴式住居」が完成する。
なお、(a)において変化の振幅が小さくなる過程で、用いる道具立ても変わってくる点に注意したい。データモデルの妥当性を高めるためにプロトタイプを用いることが有効だと説明したが、プロジェクトのごく初期ではホワイトボードや紙の上での「手書き」が最強である。その段階でより多くの派手な失敗を繰り返すには、PCのような機械では鈍重すぎるからだ。手書きで失敗を十分に繰り返してから、モデリングツールに移行し、その上でさらに失敗を繰り返す。プロトタイピングはその後でいい（次図）。アジャイル手法でいきなりアプリを作り始めることの異常さがおわかりだろうか。
▼データモデルの変化度合いに応じたフェーズ分け 
アプリ開発は、この図の「プロトタイピング」と「本番実装」の２つのフェーズでなされる。それらにおいて決定的に重要なのは、振幅が小さくなるとはいえ、データモデルの変化にともなってアプリ群を容易に修正できることだ。関連するアプリを作り替えるための調査や作業が面倒だから、データモデルを変化させられない――そうなっては元も子もない。それゆえ実装基盤には、それぞれのテーブルやフィールドがどのアプリにどのように利用されているかを示す「リポジトリ」や「使途要素分析（インパクト分析）」の機能が欠かせない。
また、なるべくコードを書かずにアプリを組み立てるための仕掛けも要る。そうでないと、手間暇かけて書いた大量のコードに対して「捨てるのがもったいない」といったケチくさい感情を持つようになるからだ。情報システムにとってアプリは泡沫（うたかた）のような存在で、データモデルの変化に追随してそれは生み出され、修正され、時にはばっさり捨てられる。アジャイル手法で言う「変化を抱擁せよ」は、まさにデータモデルのためにあると考えてほしい。
