この分析フェーズの開始点として、検出フェーズで作成した高レベルロードマップを入手します。このドキュメントおよびDesignerプロジェクトの両方に、技術的およびビジネス上の詳細を追加する必要があります。これにより、Identity Managerソリューションの実装に使用するデータモデルおよび高レベルのIdentity Managerアーキテクチャ設計が作成されます。
設計の焦点は特に識別情報管理にありますが、ファイルと印刷など、従来、リソース管理ディレクトリに関連付けられていた要素の多くにも対応できます。Identity Managerは、オペレーティングシステムのファイルシステムに直接アクセスできないディレクトリとユーザアカウントを同期します。たとえば、Active Directoryにユーザアカウントを持っていても、それだけではActive Directoryサーバのファイルシステムへのアクセス権は付与されません。
検出フェーズで収集した情報を使用して、次の質問例に回答し、収集する必要がある他の情報を確認します。このためには、利害関係者への追加インタビューが必要になることがあります。
使用されているシステムソフトウェアのバージョン。
eDirectoryの設計は適切か。たとえば、同期するユーザオブジェクトのマスタレプリカまたは読み書き可能レプリカがIdentity Managerサーバにあるかどうか。ない場合、eDirectoryの設計は適切ではありません。
すべてのシステムのデータの品質が適切かどうか(データの品質が使用に適さない場合、ビジネスポリシーを目的どおりに実装できません)。たとえば、同期するシステムに重複するユーザアカウントがあったり、各システム全体でデータ形式が統一されていなかったりする可能性があります。情報を同期する前に、各システムのデータを評価する必要があります。
現在の環境用にデータの操作が必要か。たとえば、人事システムではユーザ雇用日付形式は2008/02/23のみで、識別ボールトでは02-23-2008である可能性があります。この場合、同期を実行するにはデータを操作する必要があります。
Identity Managerには、データの分析およびクリーニングのプロセスを簡素化するためのツールが含まれています。詳細については、『Analyzer 4.0.1 for Identity Manager管理ガイド』を参照してください。
現在の環境に適切な決定を下せるよう、セクション 3.0, 技術上のガイドラインの情報をレビューします。
要件を分析したら、実装のスコープおよびプロジェクト計画を設定し、必要条件のアクティビティを実施する必要があるかどうかを決定します。大きなミスを防ぐために、情報の収集および要件の文書化はできる限り完全に行ってください。以下は、考えられる要件リストを示しています。
すべてのシステム、信頼されたデータソース、イベント、情報の流れ、データ形式の基準、接続システムとIdentity Manager内の属性間のマッピング関係を示すデータモデル。
ソリューションに適したIdentity Managerアーキテクチャ。
追加のシステム接続要件の詳細。
データ検証およびレコード照合の方針。
Identity Managerインフラストラクチャをサポートするディレクトリ設計。
次のタスクは、要件および設計の評価中に完了する必要があります。
検出フェーズでは、組織のビジネスプロセス、およびビジネスプロセスを定義するビジネス要件を収集しました。ビジネス要件のリストを作成してから、次のタスクを完了し、Designerプロセスのマッピングを開始します。
ビジネス要件のリストを作成し、このプロセスの影響を受けるプロセスを特定します。たとえば、従業員の解雇に関するビジネス要件として、その従業員のネットワークおよび電子メールアカウントのアクセス権を必ず解雇日と同じ日に削除するようにします。この解雇プロセスの影響を受けるのは、電子メールシステムおよび識別ボールトです。
プロセスフロー、プロセストリガ、およびデータマッピング関係を確立します。
たとえば、特定のプロセスで何かが発生する場合に、他にどのようなプロセスがトリガされるか、などです。
アプリケーション間のデータフローをマッピングします。Designerを使用すると、この情報を表示できます。詳細については、『Designer 4.0.1 for Identity Manager 4.0.1管理ガイド
』の「データフローの管理」を参照してください。
たとえば、2/25/2007から25 Feb 2007などにフォーマットを変換する必要がある場合のデータ変換を特定し、Analyzerを使用してデータを変更します。詳細については、『Analyzer 4.0.1 for Identity Manager Administration Guide』を参照してください。
存在するデータの従属関係を文書化します。
特定の値が変更された場合、その値に従属関係があるかどうかを調べるのは重要なことです。特定のプロセスが変更された場合、そのプロセスに従属関係があるかどうか知っておくことも重要です。
たとえば、人事システムで「一時的な」従業員ステータス値を選択することは、制限された権限と特定の勤務時間のネットワークへのアクセス権を持つユーザオブジェクトを、IT部署がeDirectoryで作成する必要があることを意味しています。
優先度を一覧表示します。
関係者全員のすべての要求、要望を即座に満たせるわけではありません。プロビジョニングシステムの設計および展開の優先度はロードマップの計画に役立ちます。
展開の一部を先に実装し、他の部分を後から実装することで展開を分割するか、組織内部の人員グループに基づく段階的な展開を使用すると有利になる場合があります。
前提条件を定義します。
展開の特定のフェーズを実行するのに必要な前提条件は、文書化する必要があります。これには、Identity Managerとのインタフェースを持つ接続システムへのアクセス権も含まれます。
信頼されるデータソースを特定します。
システム管理者やマネージャが自分の担当範囲と思われる項目を早期に明らかにすることで、関係者全員の同意を得て、円滑に作業を進めることができます。
たとえば、アカウント管理者には、特定のファイルおよびディレクトリに対する権限を従業員に付与するため、所有権が必要な場合があります。これは、アカウントシステムでローカルトラスティの割り当てを実装することにより行うことができます。
ビジネス要件を定義したら、セクション 2.2.2, ビジネスプロセスの分析に進みます。
ビジネス要件の分析が完了したら、Identity Managerソリューションの範囲を絞り込めるよう、追加の情報を収集する必要があります。アプリケーションまたはシステムを実際に使用しているマネージャ、管理者、および従業員などの主要なユーザにインタビューする必要があります。想定される問題としては、次のようなものが上げられます。
データの送信元はどこか。
データの送信先はどこか。
データの責任者は誰か。
データが属すビジネス機能の所有権を持っているのは誰か。
データの変更時に連絡しなければならないのは誰か。
データの変更がもたらす影響は何か。
データ処理(収集や編集)にはどのような作業方法が存在するか。
どのような種類の操作が実行されるか。
データの品質と整合性を保証するために取られている方法は何か。
システムはどこにあるか(どの部署のどのサーバか)。
自動処理に適していないプロセスは何か。
たとえば、人事におけるPeopleSoftシステムの管理者には次のような質問をするとよいでしょう。
PeopleSoftデータベースに保存されているデータは何か。
従業員アカウントの各種パネルに表示される内容は何か。
プロビジョニングシステム全体に反映するのに必要なアクションは何か(追加、変更、または削除など)。
これらのうち、どれが必須で、どれがオプションか。
PeopleSoftで実行されたアクションに基づいてトリガするのに必要なアクションは何か。
無視すべき操作、イベント、アクションは何か。
データはどのように変換されてIdentity Managerにマップされるか。
主要な人へのインタビューにより、プロセス全体をよりはっきりと把握できる、組織の他の領域を導き出すこともあります。
これら情報をすべて収集したら、現在の環境に適したエンタープライズデータモデルを設計することができます。セクション 2.2.3, エンタープライズデータモデルの設計に進み、設計を開始します。
ビジネスプロセスを定義したら、Designerを使用して、現在のビジネスプロセスを反映したデータモデルの設計を開始できます。
Designerのモデルは、データの作成場所、移動先、および移動できない場所を図示しています。重要なイベントがデータフローに与える影響の程度についても考慮することができます。たとえば、図 2-2は、データはPeopleSoftから流れていますが、逆にPeopleSoftへ同期するデータはないことを示しています。
図 2-2 Designerによるデータフロー
提案したビジネスプロセスと、そのプロセスに自動プロビジョニングを実装する利点について説明した図を作成することもできます。
モデルの開発は、次のような質問に回答することから始めます。
移動されるオブジェクトの種類(ユーザ、グループなど)は何か。
どのイベントが重要か。
同期が必要な属性はどれか。
管理対象のさまざまな種類のオブジェクトに対し、ビジネス全体で保存されるデータは何か。
同期は一方向か双方向か。
各属性に対して、信頼されるソースであるシステムはどれか。
システム間のさまざまな値の相互関係について考慮することも重要です。
たとえば、PeopleSoftの従業員ステータスフィールドには、従業員、契約社員、およびインターンの3つの設定値があるとします。一方、Active Directoryシステムには、常駐および臨時の2つの値しかないとします。この場合では、PeopleSoftの「契約業者」ステータスと、Active Directoryの「常駐」および「臨時」の値の間の関係を決定する必要があります。
この作業では、各ディレクトリシステム、システムを互いに関連付ける方法、および複数のシステム全体で同期する必要のあるオブジェクトと属性を理解することに焦点を当てます。設計が完了したら、次のステップでは提案検証を作成します。セクション 2.3, 概念の検証に進みます。