![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
専門性の所在を明らかにするためのパラダイム、Expertise Location を企業内で確立するソリューションは、ビジネスと同じく通常は多岐にわたる専門的トピックに対して、ビジネス全体の中でどこに専門家が存在するかを一目でわかるようにする場合には、非常に大きな効果を発揮します。企業規模の Expertise Location システムには、いくつかの重要な側面があります。具体的には、以下の側面です。
- 専門的トピックの分類 – 一般に、専門的トピックの分類をビジネスのさまざまな部門で作成し、フォークソノミー手法によって増補することで、専門的トピックが最新のものであること、そしてよく使われる専門的トピックが正確に表現されていることが確実になります。
- 専門性レベル、支援の責任レベル、および公開の範囲 (例えば、企業全体、コミュニティー内、またはグループ内など) を基準とした専門家の特定 – 専門性にはさまざまなレベルがあります。通常、専門家には特定の専門的トピックに関する専門レベル (図 1 および図 2 を参照) のいずれか 1 つが割り当てられて公開されます。
- 専門家の指名候補 – 専門家は特定の専門的トピックに対して自己推薦することも、ビジネスによって指名されることもあります。
- 専門家の関与方法 – 専門家が特定されると、その専門家は同期的な関与の仕方をすることも、非同期的な関与の仕方をすることもあります。例えばエンド・ユーザーは、専門家とチャット (インスタント・メッセージ) で直接やり取りする場合もあれば、システムに質問を送信すると、そのシステムから専門家グループまたは 1 人の専門家に質問が回される場合もあります。
- 専門家の特定に及ぼすソーシャル・メディアの影響 – ソーシャル・メディアは世間に広く普及しているだけでなく、あらゆる規模の企業でも、業務のさまざまな側面にソーシャル・メディアが採用されています。このことから、ソーシャル・メディアの 1 つの重要な使い道となるのは、潜在的な専門家を、企業内外のソーシャル・メディアでのその人物の活動または著名度に基づいて特定することです。例えば、ブログでクラウド・コンピューティングに関して広範な記事を書いている人物が、まさにクラウド・コンピューティングの専門家である可能性もあります。
- 専門家の評価システム – 専門家による継続的な支援を後押しするために、Expertise Location システムは評判の高い専門家を特定する手段と、エンド・ユーザーと専門家の対話を評定するためのメカニズムを提供しなければなりません。ここで重要になるのは、企業のプライバシーに関するガイドラインに従った実装でなければならないことです。
図 1. 専門性のレベル
図 2. Expertise Location コミットメント・レベル
Enterprise Expertise Location システムの要件は、企業全体のさまざまなビジネス利害関係者から示されます。「はじめに」のセクションで挙げた重要な側面とは別に、Expertise Location システムが実装しなければならない要件の概要を以下に記載します。
- REQ-01: 共通のユーザー・インターフェースおよびエクスペリエンス – エンド・ユーザー、専門家、管理者のすべてに共通したユーザー・インターフェースおよびエクスペリエンスを、Web アプリケーションという形で提供します。ただし、それとは別のイントラネット・サイトでは、専門家および専門家登録に関する情報を収集する機能も使用できるようにします。Web アプリケーションにはモバイル機器でアクセスする場合も考えられます。
- REQ-02: 専門性分類 – ビジネスの目標は、さまざまなビジネス部門 (販売、マーケティング、財務部門など) の専門家を企業全体のエンド・ユーザーに公開することです。ビジネス部門がそれぞれの部門に特有の専門的トピックを表現するために、固有の分類法を使用する場合もあります。
- REQ-03: 分類管理プロセスの自動化 – 外部マスター・データ・ソースからインポートされた専門性分類が自動的に同期されるようになることが、ビジネス目標となります。このプロセスには分類から除外される専門的トピックを考慮に入れなければなりません。したがって、システムはその変更内容を、分類の管理者ならびに該当する専門的トピックの専門家に通知する必要があります。
- REQ-04: コラボレーションの強化 – エンド・ユーザー、専門家、管理者の間に、高度なコラボレーション機能を提供する必要があります。こうすることにより、豊富な情報に基づくタイムリーな支援、ソーシャル・コラボレーション (タギング) を利用した検索の改善、そしてレポートの作成が容易になります。エンド・ユーザーと専門家の間には、リアルタイムでの対話と非同期の Q&A による対話が必要となります。また、対話に関する評価のフィードバックを専門家に提供できるようにするための機能も必要です。
- REQ-05: 複数のイントラネット・クライアントおよび外部クライアントがサービスにアクセスできるようにすること – Expertise Location サービスには、複数のサービス・コンシューマー (例えば、Web アプリケーションのプレゼンテーション層、イントラネットの Web ページ、外部 Web ページ、モバイル機器など) が、複数のバインディングを介してアクセスすることになります。そのため、Expertise Location システムはこれらのクライアントがサービスにアクセスできるようにしなければなりません。
- REQ-06: サービスの再利用 – 他のシステムからも使用できるサービスを特定します。
- REQ-07: 標準および共通ミドルウェアの採用 – 業界の標準技術を採用します。これには、推奨されるデプロイメント・インフラストラクチャーのミドルウェアおよびツールの選択も含まれます。
- REQ-08: 内部クライアントと外部クライアントにセキュアで信頼性の高いアクセス方法を提供すること – ソリューション・インフラストラクチャーを外部アクセスに公開することなく、内部クライアントと外部クライアントがセキュアかつ確実に Expertise Location サービスにアクセスできるようにします。
- REQ-09: 接続性ドメイン間の柔軟な通信 – Expertise Location 接続性ドメインには外部接続性ドメインを統合し、企業外部のサービス・コンシューマーが疎結合された形で Expertise Location システム内のサービスにアクセスできるようにします。したがって、メッセージ変換および複数のプロトコルに対するサポートを提供する必要があります。
- REQ-10: 変更がサービス・コンシューマーに及ぼす影響を最小限に抑えること – Expertise Discovery サービスの変更、あるいは Expertise Location システムでのインフラストラクチャーの変更がサービス・コンシューマーに及ぼす混乱を回避すること、あるいは最小限にとどめることが必要です。
- REQ-11: サービス・コンシューマーが API を介してデータにアクセスできるようにすること – イントラネットおよび外部サイトの Web ページには、リレーショナル・データベースに保管された情報を表示します。このリレーショナル・データベースに、専門性分類、専門家、および Q&A のナレッジ・ベースを格納します。リレーショナル・データベース内のデータを分析によって補強する場合には、この補強されたデータにサービス・コンシューマーからアクセスされるようにする必要があります。
- REQ-12: コンシューマーが多種多様なデータ・セットにリアルタイムでアクセスできるようにすること – Expertise Discovery システムは、さまざまなデータ・ソースに保管された専門性情報にアクセスできなければなりません。このシステムは、これらのソースにリアルタイムでアクセスし、IBM 内でのソーシャル・アクティビティーに基づき推奨される専門家を検索します。クエリーの処理時間は 5 秒を超えるようであってはなりません。
- REQ-13: 認証 – ユーザーが Web アプリケーションやその他のクライアントから Expertise Location サービスと対話する場合、認証による身元確認が必要です。したがって、ソリューションには認証サービスが必要となります。
- REQ-14: 承認 – システムは、ユーザーがアクセスできる情報を、そのユーザーの ID またはそのユーザーが使用するシステムの ID に基づいてアクセスが許可された情報に制限する必要があります。粒度の低いサービス・ベースの承認 (サービス・コンポーネント) から、粒度の高いサービス・レベルのデータ・アクセス制御に至るまで、多数のコンポーネントに承認が必要になることが考えられます。
- REQ-15: ワークフローに人間による対話を組み込むこと – 専門分野の設定、分類の設定、および専門家のサインアップの承認をサポートする堅牢なヒューマン・ワークフローを実装する必要があります。
- REQ-16: データのマスター管理を行うサービスを実装すること – システムは、専門的なデータの整合性を確実にするためのサービスを実装しなければなりません。システムはデータの整合性と品質を改善し、データが正確であることを確実にする必要があります。
SOA を定義するアーキテクチャー・スタイルは、ビジネスに合った疎結合のサービスを作成するための一連のパターンとガイドラインを表します。このアーキテクチャー・スタイルでは、記述、実装、バインディングの間に関心の分離があるため、ビジネスの新たな変化と機会への応答性に未曾有の柔軟性がもたらされます。この SOA の観点から見た全体的なソリューションを容易に理解できるようにするのが、SOA パターンです。SOA のパターンとベスト・プラクティスを適用することで、ソリューションのそれぞれの構成要素による影響を容易に理解できるようになるため、ソリューションを段階的に導入しやすくなります。以下の表に、SOA のエントリー・ポイントと、Enterprise Expertise Location システムの要件に関連する SOA パターンを記載します。
| SOA エントリー・ポイント/分野 | SOA シナリオ | SOA パターン |
|---|---|---|
| 人のエントリー・ポイント | 対話とコラボレーション | リッチ Web アプリケーション |
| サービス | 明瞭なサービス呼び出し | |
| 情報エントリー・ポイント | サービスとしての情報のシナリオ | マスター・データ管理 |
| ビジネス・インテリジェンス | ||
| 統合 | ||
| 接続性エントリー・ポイント | サービス接続性の SOA のシナリオ | 内部接続性 |
| エンタープライズ・サービス・バス | ||
| SOA 設計エントリー・ポイント | SOA 設計のシナリオ | SOMA によるサービス設計 |
| SOA セキュリティー、ガバナンス、管理の分野 | SOA セキュリティーおよび管理のシナリオ | サービス・セキュリティー |
| SOA ガバナンスのシナリオ | SOA ガバナンス | |
| エンドツーエンドのサービス管理 |
このパターンは、従来のクライアントや単純なクライアントに代わる、AJAX クライアントの価値ある提案を実証するものです。その価値には、パフォーマンと応答性におけるメリットも含まれます。
- 技術的な問題: ユーザー間のコラボレーションと共有を促進すると同時に、Web インターフェースの応答性を向上させるユーザー・インターフェースを提供しなければなりません。エンド・ユーザーが専門家を検索または参照したり、ナレッジ・ベースを検索したりするときには、ページ全体を更新することなく、結果が更新されるようにする必要があります。
- このパターンの適用方法: Expertise Location ソリューションに、AJAX ベースのユーザー・インターフェースを使用します。AJAX ベースのユーザー・インターフェースを使用して、例えばユーザーがシステムと対話している間、動的にコンテンツをロードするという仕組みです。コンテンツを更新するには、ページ全体を更新するのではなく、変更されたコンテンツだけを更新します。
図 3. リッチ Web アプリケーションの SOA シナリオ
- 導入によるビジネス価値: ユーザー・インターフェースの応答時間が短縮されることにより、エンド・ユーザー、専門家、管理者の作業効率が向上します。これにより、最終的にはユーザー・エクスペリエンスが改善されることになります。
明瞭なサービス呼び出しのパターンは、共通のユーザー・インターフェースおよびエクスペリエンスによって 1 つの場所から個々のアプリケーションにアクセスできるようにする方法を表しています。
- 技術的な問題: 従業員のソーシャル・アクティビティーに基づく専門的な情報は、複数のアプリケーション内にあります。エンド・ユーザーが登録済み専門家を素早く見つけられるようにするとともに、候補となる専門家をそれぞれのソーシャル・アクティビティーに基づいて検索できるようにするためには、さまざまなアプリケーション内にある専門的な情報を 1 つに統合する必要があります。
- このパターンの適用方法: 提案されるソリューションは、Web ベースのインターフェースによって、エンド・ユーザーが専門家を検索する機能を統合するというものです。このソリューションでは、あらゆるフロント・エンドがチャネルに依存しない共通のサービスに対応できるオープン・インターフェースを提供します。イントラネット・サイトに表示されるウィジェットで、コンテキストに依存した形で専門家を登録し、エンド・ユーザーがその情報を Web アプリケーションから入手できるようにします。
図 4. 明瞭なサービス呼び出しの SOA シナリオ
- 導入によるビジネス価値: このソリューション案は、Web アプリケーションを使用するすべてのエンド・ユーザーの生産性だけでなく、イントラネット・サイトのユーザーの生産性も向上させることになります。イントラネット・サイトでは、コンテキストに依存した形で専門家が表示され、さらにエンド・ユーザーが専門家としてサインアップできるため、専門家登録の面倒が大幅に削減されるからです。
専門性情報は複数のソースに存在することがあります。そのため、マスター・データ管理のパターンでは、外部ソースからの専門性分類および専門性キーワードを、基準ソースとなる単一の決定的なマスター・ソースとどのように調整するかを説明します。
- 技術的な問題: 専門性分類と専門性キーワードは、一般に複数の異種混合のシステムに分散されています。これらのソース内の情報は、多様なフォーマットで存在することから、いくつかのバッチ・プログラムによって定期的に情報を同期させなければならない場合があります。
- このパターンの適用方法: 提案されるソリューションは、中央マスター・データ管理 (MDM) リレーショナル・データベース・リポジトリーを組み込み、そこに一貫性した専門性分類および専門性キーワードの一式を保管することです。MDM リポジトリーに最初にデータを取り込む際は、抽出/変換/ロード (ETL) パターンを使用します。MDM 内のデータは、サービスを介して定期的に外部ソースから同期化します。他のシステムも、サービスを介して MDM の情報を抽出します。
図 5. マスター・データ管理の SOA シナリオ
- 導入によるビジネス価値: 提案されるソリューションでは、マスター・データ管理パターンを導入することにより、専門性分類における不一致を排除することができます。さらに、正確かつリアルタイムの専門家情報を他のシステムに提供することにもなります。
ビジネス・インテリジェンスのパターンが表すのは、専門性分類、専門家登録、ナレッジ・ベース、ソーシャル・アクティビティーを基に提案される専門家の情報を利用して、情報に基づく専門家登録の決定を行う方法です。
- 技術的な問題: Expertise Discovery ソリューションは、さまざまなビジネス分野での専門家登録パターンと専門家登録の格差を理解するために、詳細でインテリジェントな分析を行い、レポートを作成できなければなりません。また、専門家に関する質問を分析することのできるソリューションである必要もあります。
- このパターンの適用方法:
図 6. ビジネス・インテリジェンスの SOA シナリオ
- 導入によるビジネス価値: このアーキテクチャーによって、企業全体のビジネス・ユーザーが専門家登録における重大な格差を容易に把握できるようになります。また、どのような質問がされているのかに関するインテリジェントなレポートを入手して、目標とする専門家登録を決定する際の参考にするという点に関しても、このアークテクチャーが容易にします。
内部接続性のパターンは、組織内の複数のクライアントが Expertise Discovery サービスにアクセスできるようにする方法を表します。
- 技術的な問題: Expertise Location サービスには、ブラウザーやモバイル機器、あるいはポータルなど、さまざまな環境からアクセスしなければなりません。これらの環境は複数のプロトコルを使用してサービスにアクセスすることになるでしょうが、サービスにアクセスする新しい環境が増えるたびに、開発者がコードを作成したり、変更したりするようであってはなりません。
- このパターンの適用方法: Expertise Location アーキテクチャーが、SCA (Service Component Architecture) 実装を追加します。SCA は SOA に登場した標準で、そこに意図されているのは、開発者がビジネス・ロジックの開発だけに専念できるようにして、SCA がコンポーネントを呼び出すための単一のプログラミング・モデルを提供することです。さらに、SCA では 1 つのコンポーネントが複数の構成可能なバインティングを使用することもできます。
図 7. 内部接続性の SOA シナリオ
- 導入によるビジネス価値: SCA (Service Component Architecture) による内部接続性を導入すると、ソリューションは新たにサービスにアクセスするクライアントに適応しやすくなります。それは、開発者がビジネス・ロジックを一度作成すれば、インフラストラクチャー・ロジックを懸念することなく、さまざまなクライアントがそのロジックにアクセスできるためです。
包括的な SOA に必要となる多種多様な対話パターン (例えば、リクエスト/レスポンス、パブリッシュ/サブスクライブ、イベントなど) を完全にサポートするためには、エンタープライズ・サービス・バスが 1 つのインフラストラクチャーで 3 つの主要なエンタープライズ統合形式をサポートする必要があります。その 3 つの形式とは、サービス指向アーキテクチャー、メッセージ駆動型アーキテクチャー、そしてイベント駆動型アーキテクチャーです。
- 技術的な問題: Expertise Location システムに外部クライアントを統合することになるため、以下の要件が生じることになります。
- ローケーションが透過的になるようにし、サービスの置き換えをサポートすること
- 異種混合の環境での統合をサポートし、サービスの置き換えをサポートすること
- SOA の原則をサポートして、アプリケーションのコードを特定のサービス・プロトコルおよび実装から切り離すこと
- サービスのアドレス指定および命名を 1 ヶ所で制御すること
- このパターンの適用方法: 疎結合、基本ルーティング、そして多くの外部クライアントとの容易な統合および適応を目的としたアーキテクチャーに、ESB アーキテクチャーを組み込みます。ESB はさまざまなプロトコルと、システムと外部クライアントの間でのメッセージ交換フォーマットをサポートします。
図 8. エンタープライズ・サービス・バスの SOA シナリオ
- 導入によるビジネス価値: ESB を導入することで、システムは外部クライアントとの統合形式の変更に適応しやすくなります。特殊な統合要件が発生しても、システムはその要件に応じることができるようになるはずです。ESB によって、Expertise Location サービスを外部クライアントから分離することにもなります。
プロセス・オートメーションのパターンは、自動化されたヒューマン・タスクの統合を含め、ワークフローをどのようにして自動化するかという問題に対処します。また、複数のアプリケーションとバックエンド・リポジトリーとの統合を自動化するための機能にも対処します。
- 技術的な問題: 専門家がある専門的トピックに登録されている場合、その専門的トピックを管理者が変更する際には、その専門家に通知しなければなりません。また、外部ソースからの専門性分類は定期的に同期させる必要があります。さらにグローバル企業の場合には、プライバシー・コンプライアンスに関するプロセスは国によって異なるはずなので、その違いに実装で対処することも必要です。支援を提供する専門家を既存の従業員認識プロセスで認識し、統合しなければなりません。企業の販売プロセスには要件として、「販売前」業務を行う間、企業内の専門家を自由に活用できること、というものがあります。
- このパターンの適用方法: 提案されるソリューションでは、より効率的で、Expertise Location の要件にも十分同調した専門性分類管理プロセスを使用します。(専門家が登録された) 専門的トピックが変更された場合、専門家には自動的に通知が行われ、その変更の影響を受ける専門分野の管理者が、Web アプリケーションで変更の影響をモニタリングできるようにします。管理者には、専門性分類の同期状態が通知されるようにもします。このソリューションは既存の従業員認識プログラムおよび販売システムともインターフェースを取ります。
図 9. プロセス・オートメーションの SOA シナリオ
- 導入によるビジネス価値: 専門家には、専門的トピックの変更が自動的に通知されるようになります。管理者は、変更およびその変更が専門分野に与える影響をモニタリングするよう通知されるため、業務を効率化することができます。プライバシー法 (米国) が遵守され、専門家がそれぞれの貢献を認識されることにより専門家の参加継続が促され、時機を得た専門家の特定によって販売機会が支援されます。
サービス・セキュリティーのパターンは、承認、メッセージ・セキュリティー、およびアクセス制御を提供する一連のエンドポイントでのセキュリティー・ポリシーやセキュリティー構成を重点としたセキュリティー管理の側面に対処します。
- 技術的な問題: 提案されるソリューションには、サービス・リクエスターおよびサービス・プロバイダーと対話するすべてのエンドポイントでの SOA セキュリティー・ポリシー管理を 1 ヶ所に統合、集約することが求められます。ソリューションが効率的に ID を管理し、この ID 情報をリクエスト・フロー全体で利用できるようにする必要があります。現在、データ暗号化の要件はありません。
- このパターンの適用方法: 提案されるソリューションは、Java セキュリティー、LDAP、ファイアウォール・セキュリティー (外部サービス・コンシューマー用)、そして Web ベースのセキュリティーを組み合わせたフェデレーテッド・セキュリティー・フレームワークを採用することです。認証の実施は、エンタープライズ・ディレクトリー・サービスによって管理します。アクセス制御に関わらず、ユーザー (エンド・ユーザー、専門家、管理者) は、それぞれのロールに許可された機能にだけアクセスできるようにします。そして SCA 実装によって、ロール・ベースのアクセス制御をサービス・レベル、またはコンポーネント (サービスのグループ化) レベルでサポートします。
- 導入によるビジネス価値: フェデレーテッド・セキュリティー手法の導入により、提案されるソリューションはサービスをエンドツーエンドでセキュアにし、バックエンド・システムへのアクセスを制御して、企業のセキュリティー・ポリシーを遵守することができます。
SOA ガバナンス・パターンは、新しいサービスの作成の規制、サービス再利用の促進、標準およびベスト・プロクティスの実施、サービス変更管理、サービス・バージョン管理を組み込みます。
- 技術的な問題: 他のアプリケーションと統合しなければならないことから、オープン・スタンダード・ベースの通信プロトコルが必要となります。さらに、複数のクライアントからサービスにアクセスすることになるため、ビジネス・サービスの識別および仕様決定についてのガバナンスも必要です。
- このパターンの適用方法: ガバナンス・ポリシーを使用して、内部クライアントおよび外部クライアントによるサービスへのアクセスに一貫してセキュリティー認証ポリシーを実施します。さらに、各種サービス・コンシューマーがアクセスする必要のあるサービスの識別および仕様決定に対するガバナンスも行います。サービスの識別、仕様決定、実現では SOMA を使用します。
- 導入によるビジネス価値: SOA ガバナンス導入の最大のメリットは、サービスの再利用によるコスト削減です。また、重複したサービスが作成されないことから、ベスト・プラクティスと業界標準に準拠したより多くのサービスが再利用されることになります。
SOMA 手法とは、ターゲットとするビジネス・プロセスを実現するために SOA を設計および構築することを目的とした分析および設計手法のことです。SOMA ではこの目的を実現するために、サービス、コンポーネント、フローの識別、仕様決定、実現という手段を用います。SOMA については、「参考文献」セクションに記載されているリンクを参照してください。
サービスの識別ステップで目標とするのは、Enterprise Expertise Location にとって有意義なサービスの候補とそれぞれに関連する処理の初期セットを作成することです。サービスを識別するための主な入力情報には以下のものがあります。
- ユース・ケース・シナリオ、システム・ユース・ケース、およびユーザー・ニーズ・モデル (「参考文献」セクションを参照)
- 既存のシステムから再利用できるサービス
Expertise Location システムを構築するには、ドメインを分解し、既存の資産を分析するという手法を用いてサービスを識別します。最終目標のサービス・モデリングは使用しません。ビジネスの業績評価基準は、Expertise Location では定義されないためです。
- ドメインの分解 – ドメインの分解では、Expertise Location ビジネス・ドメインが主要な機能分野とサブシステムに分解されます。次のレベルでは、機能分野がさらにプロセス、サブプロセス、および上位レベルのビジネス・ユース・ケースに分解されます。
- 既存の資産の分析 – 既存の資産を分析する主な目的は、現行ソリューションでのアプリケーション・モジュールを最大限に再利用することです。既存のサービスを再利用できるかどうかを判別するための既存の資産分析を識別するには、ボトムアップ方式を採用することができます。
以下に、Enterprise Expertise Location システムの要件を満たすための主要なサービスとして認識されているサービスをリストアップします。これらのサービスは、SOMA のサービスの仕様決定ステップや、サービスの実現ステップで、さらに細かいサービスに分解される場合があります。これについては、記事の第 2 回で説明します。
| # | サービス名 | サービスの説明 |
|---|---|---|
| 1 | 専門性分類 | 専門分野のトピック分類は、企業の標準分類法から取り掛かることでビジネスが管理することも、ユーザー・ベースで作成することもできます。また、ソーシャル・タギングやフォークソノミーによって分類することもできます。 |
| 2 | 専門家のサインアップ | 専門家のサインアップ・サービスは、専門性分類 (タクソノミー) での特定の専門的トピックに対して、ビジネスによる管理でサインアップされる場合 (ビジネスによって指名される場合) と専門家が自ら選択してサインアップする場合 (自己推薦による場合) があります。 専門性レベルおよび支援のコミットメントも、このサービスによって処理されます。専門家が自己を表現するために使用する専門的トピックの語彙は次第に増えていくので、それによってサービスの検索が容易になります。 |
| 3 | 予定管理 | 専門家はこのサービスを利用して、自分の予定や、システムの役に立つ可能性のある他の専門知識を明らかにすることで、エンド・ユーザーが専門家を特定できるようにします。 |
| 4 | 管理された対話 | エンド・ユーザーからの質問に答えることを目的に、エンド・ユーザーと専門家の間での同期形式の対話 (チャット) と非同期形式の対話 (E メール、Web UI) を管理します。対話に関するフィードバックも、このサービスによって管理されます。 |
| 5 | 情報の収集 | 専門家が対話から情報を収集してナレッジ・ベースを拡充できるようにするためのサービスです。 |
| 6 | パブリッシュ/サブスクライブ | 専門家に関する情報を他のイントラネット・サイトに表示するとともに、エンド・ユーザーが「ウォッチ」している専門的トピックに専門家がサインアップした際に、そのエンド・ユーザーに通知が届くようにします。 |
| 7 | 検索 | エンド・ユーザーが、それぞれの要求 (専門的トピック、タグ、専門家の評価、専門家の予定、ビジネスの場所、専門家による訪問の可否など) に応じて専門家を決定できるようにします。 |
| 8 | 委譲 | 同僚を支援する場合に備え、専門家が別の専門家に回答を委任できるようにします。管理においては、専門分野の管理者がその権限を他の人に委譲することができます。 |
| 9 | 分析 | 専門家の登録とナレッジ・ベースに基づき、ビジネスの洞察を行い、インテリジェントな分析を行うサービスです。 |
| 10 | レポート作成 | 専門家と管理者が、Q&A タグや専門分野の管理に関するさまざまなレポートを表示することができます。 |
| 11 | データ・アクセス | エンド・ユーザー、管理者、専門家が他のイントラネットや外部ポータルからデータにアクセスする必要がある場合に備えたサービスです。 |
| 12 | ブロードキャスト | エンド・ユーザーはブロードキャスト・モードを使用して、多数の専門家に一斉に質問を送ることができます。 |
図 10 に示すリファレンス・アーキテクチャーは、SOA パターン、SOA リファレンス・アーキテクチャーに関して公開されている OASIS ガイダンス、そして Expertise Location システムの実装成功例から引用したソリューション・アーキテクチャーを使用して作成したものです。
指針となる原則には、以下の 4 つがあります。
- 技術の中立性: 特定の技術に依存しないことを意味します。SOA ベースのシステムの基礎となる原則は、そのシステムを実現するために使用されている特定の技術が使われなくなっても、有効な原則として使われ続ける可能性があるためです。
- 節約: 設計を簡潔にし、できるだけ複雑さをなくし、必要なコンポーネントと相互関係の数を最小限にすることを意味します。
- 関心の分離: 個々の利害関係者、あるいは一連の利害関係者たちが、その対象とする分野に直接関連するモデルだけを検討できるように、それぞれのアーキテクチャー・モデルを明確に線引きすることです。これは主に、モデルの疎結合を意味します。
- 適用性: 関連するものを指しています。このアーキテクチャーは、SOA ベースのシステムが持つできるだけ多くの側面およびアプリケーションに関連しています。
図 10. Enterprise Expertise Location のリファレンス・アーキテクチャー
Expertise Location システムは、多くの企業で極めて重要になりつつあります。この記事では、Expertise Location システムに SOA パターンを適用する方法を説明するとともに、SOA パターンからリファレンス・アーキテクチャーをどのように導き出したかを説明しました。記事の第 2 回では、ソリューション・アーキテクチャー、データ・モデル、実装技術、そしてアーキテクチャー上の意思決定について説明します。
この記事を作成するにあたって協力してくれた以下の方々に感謝いたします
- John Bosma 氏と Vicky Griffiths-Fisher 氏は、Expertise Location サービスの識別に関する作業に協力してくれました。
- Michael Ticknor 氏と Vicky Griffiths-Fisher 氏は、Expertise Location コミットメント・レベルに関する作業に協力してくれました。
- John Bosma 氏、Galina Grunin 氏、Michael Ticknor 氏、Erich Walls 氏、Sandy Yarchin 氏は、IBM 内での Expertise Location ソリューションに対する洞察で貢献してくれました。
学ぶために
- OASIS: SOA リファレンス・アーキテクチャーについて詳しく調べてください。
- IBM Redbooks - SOA パターン: SOA パターンおよび事例研究に関する有益な本が揃っています。
- Expertise Location に関する MIT の記事: Expertise Location に関する優れた記事です。
- developerWorks の XML エリアで、DTD、スキーマ、XSLT を含め、XML のスキルを伸ばすために必要な資料を入手してください。
- さまざまな IBM 製品および IT 業界についての話題に絞った developerWorks の Technical events and webcasts で時代の流れをキャッチしてください。
- 無料の developerWorks Live! briefing に参加して、IBM 製品およびツール、そして IT 業界の傾向を素早く学んでください。
- Twitter で developerWorks をフォローしてください。
- developerWorks の on-demand demos で、初心者向けの製品のインストールおよびセットアップから熟練開発者向けの高度な機能に至るまで、さまざまに揃ったデモを見てください。
製品や技術を入手するために
- ご自分に最適な方法で IBM 製品を評価してください。評価の方法としては、製品の試用版をダウンロードすることも、オンラインで製品を試してみることも、クラウド環境で製品を使用することもできます。また、SOA Sandbox では、数時間でサービス指向アーキテクチャーの実装方法を効率的に学ぶことができます。
議論するために
- My developerWorks コミュニティーに加わってください。ここでは他の developerWorks ユーザーとのつながりを持てる他、開発者が主導するブログ、フォーラム、グループ、ウィキを調べることができます。
