|
RUPの拡張: エンタープライズ・アーキテクチャ作業分野 |
 |
このホワイトペーパーの題材は、Scott W. Ambler、John Nalbone、Michael Vizdosによる「エンタープライズ統一プロセス: IT 業務の全体最適化のためのプロセスフレームワーク」から抜粋したものです。 |
いくつものシステムを開発しサポートしている組織にとって、アーキテクチャを全社的な視点で考えることは有効です。エンタープライズアーキテクチャには、全社的な技術アーキテクチャを構成するフレームワーク、ネットワーク、配置構成 (deployment configurations)、ドメインアーキテクチャ、補助的インフラストラクチャが含まれます。その環境の中に、社内のすべてのアプリケーションが導入されるわけです。エンタープライズ統一プロセス ( EUP ) の長所の1つは、ラショナル統一プロセス ( RUP ) が拡張され、エンタープライズ・アーキテクチャ作業分野が含まれていることです。
有効なエンタープライズ・アーキテクチャがあると、開発チームがそれぞれのアプリケーション・アーキテクチャに実証済みの共通アプローチを採用するようになり、組織の複数のシステムにまたがる一貫性が向上します。それによって、システムをまたがった共通メカニズムや矛盾のないセマンティクスを実現でき、再利用とシステム統合の両方がやりやすくなります。エンタープライズ・アーキテクトは、自分の作業が、複数のシステムの現在(「as is」モデル)および将来(「to be」モデル)にどう影響するかに気を配ります。1つのアプリケーションのニーズだけでなく、アーキテクチャの会社全体への影響を見極め、現在の情報技術 ( IT ) のニーズだけでなくその先を見越して、今後の作業の基礎を据えていきます。
エンタープライズ・アーキテクトの責任は、エンタープライズ・アーキテクチャを公式に定め、検証し、サポートすることです。アーキテクチャ自体は、データや、セキュリティ、ネットワーク、ハードウェアなどのインフラストラクチャを担当するエンタープライズ・アドミニストレータの作業によって構築されます。また、エンタープライズ・アーキテクチャは、アプリケーションプロジェクトチームによっても作られていきます。エンタープライズ・アーキテクトは、これらの構築作業を支援するだけでなく、積極的に構築に参加しなければなりません。
エンタープライズ・アーキテクチャとアプリケーション・アーキテクチャとの大きな違いは、対象とする範囲です。開発プロジェクトのアプリケーション・アーキテクトが1つのシステムのアーキテクチャソリューションを洗い出すのに対して、エンタープライズ・アーキテクトは、組織内の複数のシステムで使用するアーキテクチャソリューションや、フレームワーク、パターン、参照アーキテクチャを定義します。アプリケーション・アーキテクトは、アプリケーションの設計や実装を担当する人たちのチームがアプリケーション・アーキテクチャを理解して応用するのを支援し、エンタープライズ・アーキテクトは、アプリケーション・アーキテクトがエンタープライズ・アーキテクチャを理解して応用するのを支援します。アプリケーション・アーキテクトがシステムの設計や実装の担当者より広く ( 一般に ) 浅い見方をするのと同じように、エンタープライズ・アーキテクトはアプリケーション・アーキテクトより広く ( 一般に ) 浅い見方をします。組織のアーキテクチャを制定するのはエンタープライズ・アーキテクトですが、実際の実装はアプリケーション開発チームやエンタープライズ・アドミニストレータ ( システムがリリースされる前にインフラストラクチャを構築することも多い ) が行います。
エンタープライズ・アーキテクチャ作業分野のワークフローを図1に示します。エンタープライズ・アーキテクチャは、｢全体像」をモデリングすることだけではありません。モデルはエンタープライズ・アーキテクチャを記述して伝えるのに役立つため、エンタープライズ・アーキテクチャの作業の重要な部分を占めはしますが、エンタープライズ・アーキテクチャは会社全体の技術的/業務的資産の構造と分散形態によって表されるといった方が正確です。
図1. エンタープライズ・アーキテクチャワークフロー
アプリケーション・アーキテクチャであれエンタープライズ・アーキテクチャであれ、アーキテクチャには一連の要求を反映させなければなりません。図2は、エンタープライズ・アーキテクチャに対する技術/業務からの要求を洗い出す方法を表したものです。アーキテクトの中には技術的な問題だけに集中したがる人もいますが、私たちの経験上、それだけでは不十分です。エンタープライズ・アーキテクチャの第一の目的は、会社が IT の目的や目標を達成できるようにすることであり、単に IT 担当者が使う「格好いい技術」を定義することではありません。ですから、技術と業務の両方に関する要求を洗い出す必要があるのです。
図2. 「アーキテクチャ要求を定義する」ワークフローの詳細
エンタープライズ・ビジネスモデルでは、ビジネスプロセス、ビジネスルール、ドメインエンティティなど、組織の基本的な業務の側面を明らかにします。このモデルには、エンタープライズ・アーキテクチャや開発対象のシステムが従わなければならない高いレベルのビジネス要求を記述します。エンタープライズ・アーキテクトは、この情報をもとに、IT ソリューションが変化するビジネス環境に遅れをとっていないか、その環境をサポートできているかを確認します。ポートフォリオ管理作業の一環として作成されるポートフォリオ計画は、アプリケーション作業が現在、そして今後どの方向に進むかをエンタープライズ・アーキテクトが理解する上で役立ちます。ポートフォリオ計画には、既に見つかって今後行われるプロジェクトと、それがいつ開始される予定かが示されています。たとえば、意思決定をサポートするための履歴データが必要なシステムが、長期的にいくつも計画されていることが分かれば、その作業の基礎とするためのデータウェアハウスについて検討を始めることができます。また、パフォーマンスや可用性に関するものなど、技術要求事項についても洗い出し、エンタープライズ・アーキテクチャに反映させなければなりません。
初めてエンタープライズ・アーキテクチャモデルを定めるときに、これらの問題すべてに一度に対処しようとするのは妥当ではありません。エンタープライズ・アーキテクチャの個々の側面に1つずつ対処していくべきです。このやり方はエンタープライズ・アーキテクチャモデルを進化させるときにも使うことができます。組織があまりリスクを負わないで新しいインフラストラクチャをうまく採用できるように、徐々に行うのです。まずいくつかのアーキテクチャ案を作成し、それを評価するとよいでしょう。それらの案を基本要素として使い、エンタープライズ・アーキテクチャを構築することができます。
アーキテクチャ案とは、完全に詳細化/実装されていないエンタープライズ・アーキテクチャに対する追加案や変更案であり、「もっと広範囲のユーザに、おそらく Web サービス経由で、アプリケーションの公開を始める」という文のように漠然としている場合もあれば、Hibernateといった永続化フレームワークを採用すべきだという案のように具体的な場合もあります。アーキテクチャ案は、アイデアを数行で書いたような簡単なものから、簡単なポジションペーパー、新しい技術について書かれた詳細なホワイトペーパーなど、さまざまな形式で記述することができます。アーキテクチャ案の対象範囲によっては、Webで調査する、カンファレンスやトレーニングに参加する、オンラインディスカッショングループに参加する、その技術を使ったことのある他の組織の人に話を聞くなどして、更に調査を行う必要があるかもしれません。
その次のステップでは、アーキテクチャ案が実際に動き、これまでのエンタープライズ・アーキテクチャとうまく調和することを検証します。もちろん、マーケティング資料にはどの製品も完璧に動くと書かれていますが、よく知らない技術ソリューションを採用するというリスクを組織に負わせるわけにはいきません。さらに、.NETや J2EE といった技術は非常に複雑で、「箱から出して」そのまま導入することはできず、それぞれの環境に合わせてカスタマイズする必要があります。その際、さまざまな疑問に答えを出さなければなりません。現在および今後の会社にとって、もっとも適したものはどれか。.NET を使って構築したアプリケーションは既存のアプリケーションやデータソースとうまく統合できるか。.NET はどのように導入しサポートすればよいか。.NET のどの部分をアプリケーションで使用することができ、どの部分を避けなければならないか。.NET ではセキュリティ機能をどう実現するか。これらをはじめとして、さまざまな問題について調査し、自分の環境で動くことを実証する必要があります。動くだろうと考えるだけでは不十分です。動くことを実際に確かめる必要があります。
適したアーキテクチャ案があれば、エンタープライズ・アーキテクトはそれをエンタープライズ・アーキテクチャモデルに統合します。図3を参照してください。エンタープライズ・アーキテクチャモデルは、エンタープライズ・アドミニストレータが保守・サポートする、セキュリティやデータに関する標準や指針などの、一般に認められたエンタープライズ・アドミニストレーションの手引きに沿っていなければなりません。また、エンタープライズ・アーキテクトが組織用に作成しサポートする、モデリングやエンタープライズ開発のための手引きにも沿っていなければなりません。エンタープライズ・アーキテクチャはたいてい非常に複雑なので、適切にモデリングを行うには、 Zachman フレームワークで推奨されているような複数のビューが必要になります。
図3. 「エンタープライズ・アーキテクチャを改良する」ワークフローの詳細
エンタープライズ・アーキテクチャモデルは、他のエンタープライズ管理作業分野でも使われる重要な成果物です。エンタープライズ・ビジネスモデラーは、それをもとにビジネスプロセスのどの部分を自動化できるかを判断し、最終的に新しいプロジェクトを提案します。エンタープライズ・アーキテクチャモデルは、戦略的再利用作業分野でも、組織の再利用計画構想を作成するときの情報として使われます。また、既存の資産を一般化して堅牢で再利用可能な資産とするべきかを判断するための情報として、あるいは、作成または購入する資産の基準を明確にするためにも、使われます。そのモデルでは、ネットワークアーキテクチャや、データアーキテクチャ、セキュリティアーキテクチャといった技術的な問題が明らかになっているため、そのような IT インフラストラクチャを構築し管理するエンタープライズ・アドミニストレータにとっても貴重な情報となります。
参照アーキテクチャとは、特定のドメインで使用するよう設計され、実証されたアーキテクチャパターンと、それを使えるようにするための補助成果物のことです。最低でも例として役立ちますし、うまくすればアプリケーション・アーキテクチャを作成するためのベースとなります。アプリケーションチームは、参照アーキテクチャを使って、エンタープライズ・アーキテクチャを利用したアプリケーションアーキテクチャを巧妙に作成することができます。それによって、アプリケーションのアーキテクチャが標準的な実証済みの方法で作成されるため、アプリケーション開発作業が大きくスピードアップし、サポートコストが最小限で済むようになります。参照アーキテクチャは、ものごとがどう動く可能性があるかを示す理論的なモデルではありません。ものごとが実際にどう動くかを示す実証済みのパターンなのです。それを示すには、チームが中を調べて適用方法を知ることができる動くコードほど適したものはありません。
参照アーキテクチャは、特定の技術やドメインに合わせて作られていることがあります。参照アーキテクチャは、アプリケーション開発者が使いやすいように文書化しなければなりません。その 1 つの方法が、RUP 標準のソフトウェアアーキテクチャ説明書 (SAD) を作成することです。文書は簡潔に分かりやすく書くことを忘れないでください。アジャイルに文書を作成することは可能です。
他のエンタープライズ管理作業分野と同じように、エンタープライズ・アーキテクチャ作業分野で重要なのは、プロジェクトチームを支援することです。素晴らしいエンタープライズ・アーキテクチャを定義しても、アプリケーションチームが理解できなかったり守らなかったりしたら意味がありません。エンタープライズ・アーキテクトはプロジェクトチームと協力し、エンタープライズ・アーキテクチャを採用してそれを守れるよう、支援しなければなりません。
エンタープライズ・アーキテクトは、アプリケーション・アーキテクト (RUP でいうソフトウェアアーキテクトの役割 ) と緊密に協力して、アプリケーションアーキテクトが特定のアプリケーション向けのアーキテクチャを定める支援をします。そのために、参照アーキテクチャを適用し、会社全体のニーズに留意しながらアプリケーション・アーキテクチャを作成するのを手伝います。優秀なエンタープライズ・アーキテクトは、自分の時間の大半を費やして、他の人に助言をしています。また、エンタープライズ・アーキテクトはトレーニングも行います。これは、教室で行う公式な講義という形を取ることもあれば、昼食を食べながら行うことも、プレゼンテーションとして行うこともあります。トレーニングが行われるのは、たいてい、エンタープライズ・アーキテクチャが大きく変更/追加され、それをIT組織全体に伝えなければならない場合です。エンタープライズ・アーキテクトがもっとも多くの人にすばやく情報を流すには、まず何らかのトレーニングを行い、その後で特定のアプリケーションチームや個人に対して指導をするとよいでしょう。
エンタープライズ・アーキテクトがプロジェクトチームと効果的に協力するには、次のアドバイスが役に立つと思います。(これについてはThe Practical Guide to Enterprise Architectureで詳しく説明しています。)
エンタープライズ・アーキテクチャ作業分野では、組織のエンタープライズ・アーキテクチャを定義するのに必要な作業を定めています。ここでは、エンタープライズ・アーキテクチャ(組織のアーキテクチャにかかわるインフラストラクチャを構成するフレームワーク、ネットワーク、配置構成 (deployment configurations)、ドメインの製品ライン、および補助的インフラストラクチャ ) を作成するプロセスについて記述しています。また、エンタープライズ・アーキテクトは、参照アーキテクチャ ( エンタープライズ・アーキテクチャで使えるよう設計/実証されたアーキテクチャパターンと、各アプリケーションが従うようにエンタープライズ・アーキテクトが定めた技術要求事項、標準、および指針)も提供します。
 |
本ページの原文（改訂されている可能性がありますのでご注意ください）: www.enterpriseunifiedprocess.com/essays/enterpriseArchitecture.html Copyright 2004-2007 Scott W. Ambler 元ページ更新日: 2004/11/17 |