アーキテクチャの寿命とは？どの程度まで考慮しておけばいいのか？そしてどのようにビジネスに影響するのか？これらの質問に答えるためにDan Pritchett氏は自身で「あるパターンや技術の集合が新たなシステムを設計し始める際にも適用可能である期間」と定義する「アーキテクチャの有効期限」(リンク)という考え方を発表した。氏はアーキテクチャの有効期限は5年程度であると考え、それを2，3世代繰り返すとどんなアーキテクチャであっても少なくても一部は変更する必要が生じるとしている。さもなくば、そのアーキテクチャは廃れて、ビジネスの進化に適合するためのコストの増大を招くことになる。この話に基くと、Pritchett氏は「アーキテクチャは大概10年か、高々15年の有効な期間である」と提唱していることになる。この主張を裏付けるため氏は1990年以降に登場した一連の技術やアーキテクチャの進化について例示している。
Pritchett氏はアーキテクチャの寿命の最期の段階においてその更新に失敗するとビジネスに重大な影響を与えると主張している。しかし氏は、とりわけ「良好な顧客基盤を築き、ビジネス上の特色に溢れている」状態にあると、多大なコストを伴う大きなアーキテクチャのシフトが起こるということも認めている。複数の人がアーキテクチャの書換えについての意見交換(参考記事)で強調されたように、このアーキテクチャのシフトは、かなり破壊的なものになり得る。しかし、Pritchett氏は新しいアーキテクチャや技術を採用しないことはさらに高いコストを生むと主張する。新しいアーキテクチャは多くの場合、開発者の作業効率を向上しデプロイに要するコストを削減する。この潜在的な競争優位性の採用を断念することは競争相手に先行する機会を残すことになり、結果としてビジネスにとっては致命的となる。:
忘れがちなのはいずれにしろ、新しいパターンやプラットフォームはあなたのビジネスを崩壊するのに利用されるということです。もしあなたのビジネスが成功を収めているのなら、他の多くの人がその分け前を狙っています。そして技術は彼らがあなたのビジネスを追随するための道具となります。さらにあなたと同じサービスをより低コストで提供したり、より魅力的な特徴を持ったサービスを提供することで彼らがあなたのビジネスにもたらす崩壊は、内部のアーキテクチャのシフトによってもたらされるいかなる崩壊よりもはるかに大きなものとなるのです。
一つ目の記事に対する補足記事において、Pritchett氏はアーキテクチャの大きなシフトの必然性について新しいパターンと技術の出現という観点を持ち込んだ。既に述べたように、アーキテクチャの寿命はビジネス要求に対する拡張の容易性に依存するので氏はこれを専門用語を使って「新技術によってインクリメンタルに新しくなる」能力と翻訳した。この能力は「よいコンポーネントの設計に関するアーキテクチャの標準的な原理に従い、可能な限りコンポーネント間の結合度を低下する」ことによって強化することができ、これによって各コンポーネントは互いに独立して実装し、進化することが可能となる。確認された一般的な間違いを元にして、Pritchett氏はより長い寿命のアーキテクチャを構築する目的で、いくつかの原理を抽出した。(リンク):
1. 実装とインタフェースのプロトコルは切り離す。これによって「あるコンポーネントを代替技術による実装へ移行する柔軟性」が増す。これを実現する手段としてPritchett氏はコンポーネント間には、例えばXMLやJSONといった、テキスト・ベースのインタフェースを構築することを提案している。
2. 例え当初は二つの関心事の規模が異なっていても、関心事の分離に配慮する。これによって、既存のコンポーネントに新しい機能が追加になりこの機能が大きくなった場合に本来二つのコンポーネントがひどく結びついた一つのコンポーネントとして実装され「二つを切り離したのでは実現困難な機能を顧客が期待している」ので分離することがとても困難である、といった状況を避けることができる。
3. ベンダーの製品の挙動、アーキテクチャへ与える影響に関する深い知識が必要となる意図しないベンダー・ロックを避ける。
4. データベースのロックを避けるため永続化層のバインディングは極力最小化する。あらゆるエンティティに対するアクセス・パスはプライマリ・キー経由に限定し、他の全てのアクセス・パス全てリソース層に分離しすることによって将来別の形式で永続化した場合に別のアクセス・パスへ変更できる。
結合度を最小化するためにこれらのルールに従えば新しい技術やパターンを比較的簡単に統合できる柔軟なアーキテクチャを構築することができ、修正のコストを下げ、アーキテクチャの寿命を伸ばすこと出来る。
原文はこちらです：http://www.infoq.com/news/2008/09/architecture-life-span