最近の記事で、Martin Fowler氏は、Extreme Programming (XP)で一般に使用されているプラクティスである、evolutionary design(リンク)をSOA実装へ適用する可能性を調査している。まず、plannedとevolutionary(リンク)の2つの一般的な設計パラダイムについて述べ ている。
planned designはソフトウェア設計の1段階において機能し、その後構築(プログラム)する。この場合、いったん構築を開始してしまっていたら、設計の変更は 難しい。evolutionary designは、意味のあるプログラミングをおこなったとしても、定期的に設計が変更されることを想定している。XPのプラクティスは、 evolutionary designに規律のあるアプローチを提供するので、理解しているよりもずっと現実的である。この変化によって、ソフトウェア設計を取り除かなかった(死 んでいない)が、われわれの設計についての考え方を著しく変えたことは事実である。
SOAの場合、planned designをサポートする主な根拠は、公開済みのインターフェイス(PDF)をエンタープライズに公表している再利用可能な相互接続サービスの形をとって、エン タープライズITシステムのアーキテクチャ設計図を作成している ということである。Martin氏によると以下のとおりである。
公開済みのインターフェイスは変更が難しく、それゆえに正しくするためにplanned designが必要である。そうすればそれを変更する必要がない。またplanned designは、たいていの組織で目にするカオス的システム相互接続に対する反応でもある。このカオスが、お粗末な設計の結果であるので、planned designが将来このようなことが起こるのを防ぐと言える。
しかし、それがSOA実装の真の安定性に関する疑問を投げかける。
そこで、SOAもしくはその他の設計コンテキストを見ると、「変化は予測可能なのか?」という基本的な質問をする。変化が予測可能の場合に限り、 planned designアプローチが有効である。単一アプリケーションのコンテキスト内で予測可能が難しい場合、エンタープライズ全体では二重に難しいと考えてい る。予測不可能なコンテキストでplanned designを使用する場合、その計画がなんとすばらしいと思うが、予測不可能な変更によって弱体化し、現在の状況と同じような混乱に陥ってしまう。しか しながら、その混乱はさらに悪化する。planned designに莫大なサンクコストがあるせいで、SOAの取り組みによって生み出そうとしているビジネスバリューがあっけなく減じられてしまう。製品化に 要する時間が重要な場合は特にそのことが言える。
結果として、SOA実装の基本的な側面の1つは、サービス契約を実装の変更に対する全体的な要求として展開する機能であるべきである(リンク)。Martin氏は、実装の段階を踏むごとに、ビジネスバリューを生む漸次的なSOA実装を提案して、この記事を完結している。
evolutionary designはSOAサイズに拡大することができるか?わたしの見解では、大掛かりなSOAの取り組みさえも凌ぐスケールの大きい、存在証明がある。 Webである。Webは、疎結合のもと、大量の予測不可能な変更で構築されている。色々な意味で、混乱である。しかし、それでも機能している。毎日のよう に多くのひとびとに真価を提供している。
SAO実装でevolutionary designを使用するのは、何も悪いことではない。ここでの問題は、plannedとevolutionaryの部分をうまく両立させる(リンク)ことができるか である。通常、evolutionaryボトムアップアプローチはSOAベースの統合へとつながり、長期的に見ると、真価を提供できなくなることがよくあ る(参考記事)。evolutionを見据えたplannedアプローチ(リンク)が、これまで以上の成功へと導く。
原文はこちらです：