先日 SATURN 2011 で行ったプレゼンテーションで Eric Richardson 氏は，アジャイル環境におけるアーキテクトとハリケーンを予報する気象学者との類似点をいくつか挙げてみせた。どちらもさまざまな予測をしてそれぞれ資料を作成する，多種多様なデータソースを入力として使用する，データ取得のために数々の手法を駆使する，といった具合だ。筆者の考えでは，利用可能なアジャイルアーキテクチャのプラクティスの数はわずかである。それらは従来のアーキテクチャとはまったく異なっている。それにも関わらず，アジャイルアーキテクチャの計画を定義する上でも，準備や更新に対処する上でも，信頼性の高い方法が存在するのだ。
Richardson 氏は，アメリカ化学会 (American Chemical Society) の一部門である CAS で編集システムに従事するアーキテクトである。そこでは化学者たちがデータベースの信頼性確保のために，科学情報の解析と索引作成を行っている。IT 専門家の役割はデータベースの配信をサポートするソフトウェアと，それを検索するプロダクトの開発である。
氏が気象学とアーキテクチャの類似性を紹介するのは，どちらも同じように複雑であるからだ。ただし気象学者の方が，はるかに昔から不確実性に対処してきている。さらに言えば，システムの部分部分が思いもよらぬ方法で相互作用しているため，正確な予測が不可能に近い点も同じだ。一見すると，アジャイル開発の原則とソフトウェアアーキテクチャは相反しているようだ，と Richardson 氏は言う。アジャイル実践者とアーキテクトの間にある種の緊張関係が存在するのはそのためだ，というのだ。しかしながら，事前に大規模設計 (Big Design Up Front) を行うのと何も行わない (No Design Up Front) のとでは，どちらも間違った方向に進む結果になることに違いはない。
この課題に対処するために氏は，最初からアーキテクチャを導入するように提案している。長期的に見れば間違いが判明することが確実であっても，少なくとも短期的には正確であると考えられる「予測」としてそれを扱うのだ。したがってそれを再評価し変更する作業には，アジャイルアーキテクトが責任を持つことになる。予測が不正確になった場合の変更は避けられないものであるから，アジャイルアーキテクチャは，求められる結果を達成するために柔軟に変更可能でなければならない。技術革新が証明しているように，進化するアーキテクチャにはある種の不確実性があり，経験を積んだアーキテクトのみがそれに対応できるのだ。
変化に対処するために，アーキテクトは予想進路図 (projected path) を作成して，変化の内容と発生順序を判断できるようにしておく必要がある。変化は結果的にアーキテクトを目標に近づけると予想されるが，もし多少外れたとしても気にする必要はない，と Richardson 氏は強調する。予想進路図は進化に適応し，柔軟であり，革新的変化のリスクに対処し，想定外の事態に対するヘッジの役を果たすものだからだ。
このような事情から，アーキテクトには補助者が必要である。 アーキテクトが自身の計画の実現性をチェックするには，実装される内容について知っていなければならない。場合によってはコードに直接当たらなければならないこともある。ただしそれが可能で，かつ実行する意思があればの話であって，誰かの助けを求める方が自分自身で行うより効率的だろう。
アジャイルアーキテクトの役目は，チームのハリケーンハンターを見つけ出して確保することにある。例えば一番適した人にその仕事を任せるべきだ。もうひとつの役割は気象判断ネットワーク，つまり開発・販売・マーケティングのネットワークを構築することだ。最後に重要なこととして，初期の誤った判断をリカバーするための監視と調整の実行がある。主要なアーキテクチャ上の判断に対しては，他のステークホルダの賛同を得ることも必要だ。
氏のプレゼンテーションでは，アジャイルアーキテクチャと気象学の共通点について，新鮮で面白い考察が披露された。プレゼンテーションの詳細をぜひご覧頂きたい。一見に値する内容だ。