今回この記事で紹介するのは，プロジェクト開始に必要なシステム構造情報を提供し，アーキテクトのビジョンにチームを統一して，想定されるリスクを評価するためには，十分な事前設計を行うべきだ，とするアドバイスだ。
完全な事前設計を必要としていたウォーターフォールの時代は過ぎ去った。しかしそれは，設計を一切行わずに新しいソフトウェアプロジェクトを始める時代が来た，ということを意味するのだろうか？ もしも十分な検討を行わずに，いきなりコードを打ち込み始めてから何週間も経った後に，最初に選択したテクノロジがまったくの誤りであったと気付いたとしたら，いったいどうなるのだろう？ 設計指針もパターンも何も考えず，その結果，大きな泥団子のようなコードができたならば，どうなってしまうのだろうか？
また，UMLが開発者のコーディングする上での障害でしかないと言うのなら，チームとしては，自分たちが開発しようとしているシステムの設計について意見を交わす手段として，グラフィカルな方法を一切使うべきではないということなのか？ 開発者の負担になることなく，チーム全体がプロジェクトの成功に向かう道を確実に見出すことのできるような，必要にして十分な事前設計を行う方法はないのだろうか？ この設計をすべてのチームメンバに伝えて，彼らが同じものを開発していると確信できるような方法はあるのだろうか？
ブタペストのCraft Conferenceで行われたプレゼンテーション"Agility and the Essence of Software Architecture"では，ヨーロッパでソフトウェアアーキテクト兼コンサルタントを営むSimon Brown氏が，これらの疑問への回答として，最小限の設計とその伝達手段に関するアドバイスを行った。
"アーキテクチャなくしてソリューションなし"という前提からプレゼンテーションは始まった。そこで氏が推奨したのは，コンポーネントのレベルまでの十分な事前設計を行うことだ。氏はC4モデルに基づいて，システムを下図のような層に分割して見せた (セッションのスライド - PDFより引用)。
まず最初に，システムがどのように使用されるのか，他のシステムに依存する部分が何であるかを検討する必要がある。それから，コンテナのスケッチを作成しなければならない。コンテナとは，Webサーバやアプリケーションサーバ，データベース，ブラウザプラグインなど，デプロイ可能なユニットだ。ここでは採用するテクノロジに関して，いくつかの決断が必要になる。システムの実装が"テクノロジ非依存"なことはあり得ないからだ。その次には，コンテナ内に配置されるコンポーネントを検討する。コンポーネントは一般的に，システムのある機能を実装するための，高度に関連したクラスのコレクションである。コンポーネント自体はモジュールないしパッケージとして表現される。氏はそのようなコンポーネントを，自身のプロジェクトである"techtribesje"を例に，次のようなイメージで示している。
イメージの左側は２つの層，すなわちサービス層とデータアクセス層で構成されていた初期のコンポーネントを示している。初期の設計ではそれぞれ独自のパッケージだったが，後になって右側に示すような単一のパッケージに統合された。DAOインターフェースと２つの層とパッケージの分離が必要な場合もあるが，氏はこの例で，簡略化のため２層を結合してひとつにする決定をした。図ではインターフェースとクラスが描かれているが，事前設計でこのレベルまで詳細を示す必要はないだろう。コンポーネントそれ自体を決めるだけで，インターフェースやクラスは含まれない。
システムの全体構造をコンポーネントのレベルまで設計したならば，事前設計のプロセスとしては，この図に示すような２つのフェーズが残っている。
アーキテクトにとって重要なのは，チーム全体で同じものを構築できるように，自身のビジョンを共有することだ。ここでは図が役に立つ。ツールで描いてもよいし，ハンドスケッチでも構わない。 大切なのはシステムの構造を含み，コンテナとコンポーネントを含んだグラフィカルな表現を，後日いつでも参照できるような形で残しておくことだ。
もうひとつ重要なフェーズは，システム構築において考えられるリスクの評価だ。このようなリスクを顕在化するために，氏はリスクストーミングの利用を提唱する。チーム全体でアーキテクチャモデルを解析して，実装上問題になり得る部分を全員で指摘するのである。コンセプトの実証やシステムのプロトタイプも，このフェーズで行っておくとよいだろう。
最後のアドバイスはリーダシップに関するものだ。一般的なチームは，システムのアーキテクチャを行うひとりのリーダが存在する場合に最高のパフォーマンスを示すものだ。しかし氏は，より成熟したチームならば，システムがそれを正当化するに十分な規模さえあれば，複数の人々に役割を分担することが可能だという。