エンタープライズアーキテクチャ

http://martinfowler.com/bliki/EnterpriseArchitecture.html

つい最近、P of EAA についてアマゾンに投稿された二、三の的外れのレビューを見かけました。（的外れというのは）この本にはエンタープライズアーキテクチャについては何も書いていないからです。勿論、それには理由があります。この本のテーマは、エンタープライズ’‘アプリケーション’‘アーキテクチャ、つまり、エンタープライズアプリケーションの「設計方法」なのです。エンタープライズアーキテクチャはまた別の話で、一企業内の複数のアプリケーションを首尾一貫したひとつのものにまとめ上げる方法のことを指します。

読み進めばおわかりになると思いますが、私はエンタープライズアーキテクチャに対してかなり冷淡な態度をとることがあります。冷淡である理由は、エンタープライズアーキテクチャに関する取り組みに共通のライフサイクルにあります。普通、そうした取り組みは、栄光のきらめきに包まれ、人々の注目を集めて始まります。ITグループが音頭をとって、重要プロジェクトを立ち上げるのです。そのプロジェクトは、アプリケーションの島々に建つストーブの煙突をバラバラにすること*1（他にもぴったりしたたとえがあるでしょう）により得られる、シナジー、再利用性、その他のあらゆる利益をもたらすものとされます。しかし、二、三年たってもあまり多くのことはなされず、エンタープライズアーキテクチャグループは、電話をかけても返事をよこしてもらえなくなってきます。それから一、二年後には、プロジェクトは人知れず幕を閉じます。しかし、すぐに別のプロジェクトがスタートし、ブームと崩壊のサイクルが再び始まるのです。

では、このサイクルがこんなに規則正しく起こるのはなぜでしょうか。これらの取り組みに係わった人々は、失敗は主に政治的理由だと言うと思います。しかし、彼らが見落としているのは、そういった政治的影響力は避けられない、ということです。こうした取り組みで成功するためには、まず、こうした政治的影響力の強さを認識しなければならないのです。

アーキテクチャ統括グループにとっての問題点は、統括グループがIT部門のマネジメントによって推進される一方で、まとめ上げようとしているアプリケーション群はユーザの業務ニーズにより推進されているという点です。アプリケーションチームが仕事の指示を受けたとします。その仕事は、自分たちのアプリケーションにとって直接の役に立つものではなく、アプリケーションがエンタープライズアーキテクチャに適合することを助けるためのものであるとしましょう。アプリケーションチームがその仕事を避けようとするのはごく自然なことです。しかも、アプリケーションチームには切り札があります−業務部門というスポンサーです。エンタープライズアーキテクチャ計画に準拠するようにすると、アプリケーションの稼動は四ヶ月遅れると言われれば、業務部門は、アプリケーションチームが「統括グループからの仕事は、後で何とか時間を見つけてやるよ（そんなもんやってられっかよ）」というときに、アプリケーションチームを「そんなのやらなくていいよ。アプリケーションを早く作ってよ。」と支援したくなるものです。アプリケーションは業務上の価値と直接に結びついており、一方アーキテクチャ統括チームはそうではないのだから、アプリケーションチームが勝つわけです。こうした（アプリケーション側の）勝利が重なって、エンタープライズアーキテクチャへの取り組みは崩壊するのです。

こうした結果を避けるためには、エンタープライズアーキテクチャへの取り組みにおいては政治的現実を認識し、それを受け入れなければなりません。

エンタープライズアーキテクチャへの取り組みがどのような業務上の価値をもたらすのかを理解する。
どんな仕事についても、業務上の価値という点からみて短期的に利益を付け加えるという裏づけがあるようにする。
アプリケーション側でのコストを最小化する。

こういった取り組みは、アプリケーション群を支配する計画を作りあげることよりも、どんな結合方法でもよいからアプリケーション群を統合する「テクニック」を見つけ出すことに力点を置くべきでしょう（結局、アプリケーション境界とは、元来、社会的な構成概念であって、前もって誰かが立てた計画に境界が適合するということはありそうにもないのです）。この統合アーキテクチャが各アプリケーションチームに与える影響は最小にすべきです。そうすれば、各チームは、業務上の価値という視点から正当化されるのに応じて、小さい単位で（徐々に）機能を提供することができます。私は、アプリケーション間の結合度を最小化するアプローチに集中することも必要になると思います。そのようなアプローチは、もっと緊密な結合をもたらすアプローチより、効率性において劣るかもしれませんが。

これらの理由で、私は、メッセージングアプローチによる統合に惹きつけられることが多いのです。欠点もありますが、メッセージングアプローチは、既存アプリケーションに与える影響を最小にして適用できる方法なのです。

ところで、エンタープライズアプリケーションアーキテクチャ（アプリケーションの設計方法）は、アプリケーション統合に対して大きな影響を与える可能性があります。うまく階層化されたアプリケーション、とりわけ、プレゼンテーションとドメインの分離がうまく行われたものでは、サービスの形式でアプリケーション機能を公開することが容易であるため、互いに縫い合わせることもずっと簡単になります。対象アプリケーション側ではコストはかかりません。というのは、きれいな階層化によって、そのアプリケーション自体もメンテナンスが容易になるからです。しかしながら、プレゼンテーションとドメインの分離を行う方法を理解しているアプリケーション開発者は少なすぎます。統合グループはアプリケーション開発者がこうしたことをできるよう、教育とトレーニングを通じて支援するとよいでしょう(Architectus Reloadus ではなくArchitectus Oryzus の役割を務めるのであれば*2、これが、最も支持されるアプローチです)。ですから、そのような意味であれば、私の本はエンタープライズアーキテクチャと大いに関係があるということになります。

[訳注]

比喩がよくわからないが、「アプリケーションの島々に建つストーブの煙突(the stovepipes of application islands)」とは業務機能単位で開発された既存アプリケーションプログラムのことを指し、それらを「バラバラにする(break down)」とは、業務機能横断的にそれらを整理して、標準化や共通化を図ることではないか。–keis
Architectus Reloadus と　Architectus Oryzus　は、論文 “Who Needs an Architect”でファウラー氏が描いたアーキテクトの二つの類型。ファウラー氏が冗談でラテン語の学名風に命名している。Architectus Reloadus は「マトリックスリローデッド」にでてくる、マトリックスを設計したアーキテクトのイメージ。プロジェクトの初期段階であらゆる重要な事柄について一人で意思決定する、常人に隔絶した存在。Architectus Oryzus　はファウラー氏の同僚のデイブ・ライス氏がモデル(“Oryzus” はラテン語で「米」。Riceと掛けている)。プロジェクトの間中、メンバと密接に協力しながら活動し、問題を少し早めに見つけて深刻な状況になる前に対処したり、メンバが抱えている問題を解決するのを支援したり、バックグラウンドの異なる人々の間のコミュニケーションを助けたりする。–keis

update

2004-02-11 (水) 20:35:12 ‘’[[keis]]’’ : 訳してみました。
2004-02-12 (木) 11:26:31 ‘’[[kdmsnr]]’’ : 少々、修正させていただきました。注釈、素晴らしいです!!!ありがとうございます。
2004-02-12 (木) 23:23:29 ‘’[[keis]]’’ : 修正ありがとうございました。表現が硬かったところがすっきりしましたね！
2004-02-23 (月) 21:59:06 ‘’[[ogino.]]’’ : この場合にあてはまるかどうかわからないんですが、コンピュータ界隈でstovepipe applicationと言うときは、メインフレームのような単体で独立していて融通がきかないもの、というような意味で使います。
2004-02-23 (月) 22:51:03 ‘’[[kdmsnr]]’’ : なるほど。いちおうリンクhttp://c2.com/cgi/wiki?StovepipeAntiPattern