Novell Doc: Identity Manager 4.0.1 架構安裝指南

2.2 需求和設計分析階段

採用在探查階段中建立的高階引導圖作為這個分析階段的起始點。文件及 Designer 專案都需要加入技術及商業詳細資料。這會產生資料模型，以及用來實作 Identity Manager 解決方案的高階 Identity Manager 架構設計。

設計的焦點應該是身分識別管理；不過，也可以處理許多一般與資源管理目錄相關聯的元素 (例如檔案和列印)。Identity Manager 會讓使用者帳戶與無權直接存取作業系統之檔案系統的目錄同步化。例如，您可以在 Active Directory 具有一個使用者帳戶，但如此不代表您就有權存取 Active Directory 伺服器上的檔案系統。

使用探查階段中收集到的資訊回答下列樣本問題，以查看還需要收集哪些資訊。這可能需要另外訪談共同工作人員。

正在使用哪個版本的系統軟體？
eDirectory 設計是否適合？例如，Identity Manager 伺服器是否包含正在同步化之使用者物件的「主檔案系統物件」或「讀/寫」複製本？如果沒有包含，eDirectory 設計就不適合。
所有系統中的資料品質適當嗎？(如果資料不具有可用的品質，則可能不會依需要來實作商業規則。)例如，可能在系統中有正在同步化的重複使用者帳戶，或資料的格式在每一個系統中可能不一致。在同步化資訊之前，必須評估每一個系統的資料。
您的環境需要資料管理嗎？例如，人力資源系統中的使用者雇用日期格式只能為 2008/02/23，但在 Identity Vault 中的雇用日期為 02-23-2008。這時便需要修改日期的格式才能進行同步化。

Identity Manager 提供了一個可協助您簡化分析和清理資料程序的工具。如需詳細資訊，請參閱《Analyzer 4.0.1 for Identity Manager Administration Guide》(Analyzer 1.2 for Identity Manager 管理指南)。

檢閱節 3.0, 技術指導方針中的資訊，以協助對您的環境做出正確的決策。

在分析需求之後，您可以建立實作的範圍及專案計劃，並判定是否需要進行任何必要活動。為了避免嚴重的錯誤，請儘量蒐集完整的資訊並記錄要求。以下是可能的需求清單：

資料模型，其中顯示 Identity Manager 內所有系統、授權資料來源、事件、資訊流程、資訊格式標準，以及已連接的系統與屬性之間的映射關係。
針對解決方案的適當 Identity Manager 架構。
其他系統連線需求的詳細資料。
資料驗證和記錄比對的策略。
設計為支援 Identity Manager 基礎結構的目錄。

下列任務應該在需求及設計評估期間完成：

2.2.1 定義業務需求

在探查階段中，您已收集組織的商業程序及定義這些商業程序的商業需求。建立這些商業需求的清單，然後完成下列任務來開始在 Designer 中映射這些程序：

建立商業需求的清單，並判定哪些系統會受到這個程序的影響。例如，終止員工的業務要求可能是必須在終止員工的同一天移除員工的網路和電子郵件帳戶存取。電子郵件系統及 Identity Vault 會受到這個終止程序的影響。
建立程序流程、程序觸發器和資料對應關係。

例如，如果特定的程序中將要發生某個事件，會觸發其他哪些程序？
對應應用程式之間的資料流程。Designer 可讓您查看這個資訊。如需詳細資訊，請參閱《Designer 4.0.1 for Identity Manager 4.0.1 Administration Guide》(Designer 4.0 for Identity Manager 4.0 管理指南) 中的「Managing the Flow of Data」(管理資料流程)。
定義需要進行格式轉換的資料轉換 (例如 2/25/2007 轉換為 2007 年 2 月 25 日)，以及使用 Analyzer 變更資料。如需詳細資訊，請參閱《Analyzer 4.0.1 for Identity Manager Administration Guide》(Analyzer 1.2 for Identity Manager 管理指南)。
記錄存在的資料相依性。

如果特定值變更，則瞭解該值是否存在相依性便十分重要。如果特定程序變更，則瞭解該程序是否存在依存性十分重要。

例如，在人力資源部門系統中選取「暫時」員工狀態值，可能表示 IT 部門需要在 eDirectory 中建立在特定時間期間對網路的權限和存取受限的使用者物件。
列出優先程度。

並非每一方的每個要求、希望或願望都可以立即實現。設計及部署供應系統的優先程度將有助於規劃引導圖。

將部署工作劃分成幾個階段或許很有幫助，這樣可以先實作一部分部署，以後再實作其他部分的部署，或者使用以組織內員工群組為基礎的階段式部署。
定義先決條件。

實作特定部署階段所需的先決條件都應該記錄下來。這包括對需要與 Identity Manager 連接之連接系統的存取。
識別授權資料來源。

較早地瞭解系統管理員和各個主管認為他們所要擁有的資訊項目，可以協助您取得並始終保持各方的認同。

例如，帳戶管理者可能要擁有授予員工特定檔案和目錄時所需的權限。可以藉由在帳戶系統中實作本地託管者指定來達成此目的。

在定義了商業需求之後，請繼續進行節 2.2.2, 分析業務程序。

2.2.2 分析業務程序

在完成業務需求的分析之後，您需要收集更多資訊，以幫助您使 Identity Manager 解決方案更為明確。您需要訪談最基本的人員 (如實際使用應用程式或系統的經理、管理員及員工)。要說明的問題包括：

資料源自何處？
資料去向何處？
誰來負責資料？
哪些人員擁有資料所屬之業務功能的所有權？
要變更資料需要聯絡哪些人員？
正在變更的資料具有哪些隱含項目？
資料處理要執行哪些工作 (蒐集和/或編輯)？
會執行哪種類型的操作？
使用何種方法來確保資料品質和完整性？
系統位於何處 (在哪個伺服器上，哪個部門中)？
哪些程序不適合於自動處理？

例如，您可對人力資源部門中 PeopleSoft 系統的管理員提出以下問題︰

哪些資料儲存在 PeopleSoft 資料庫中？
哪些項目會出現在員工帳戶的各種面板中？
在佈建系統中必須反映哪些動作 (例如新增、修改或刪除)？
其中哪些項目是必要的？哪些項目是選擇性的？
根據在 PeopleSoft 中執行的動作需要觸發哪些動作？
要忽略哪些操作/事件/動作？
如何轉換資料並將其對應至 Identity Manager？

會晤關鍵人員可以指向組織的其他區域，它們可提供整個程序的更清晰圖像。

在收集所有資訊之後，您就可以對環境設計正確的企業資料模型。請繼續進行節 2.2.3, 設計企業資料模型以開始設計。

2.2.3 設計企業資料模型

定義商業程序之後，您可以使用 Designer，開始設計反映目前商業程序的資料模型。

Designer 中的模型說明資料來自何處、移向何方，以及不能移向何方。它也可以說明重大事件如何影響資料流程。例如，圖 2-2顯示資料來自 PeopleSoft，但是沒有資料重新與 PeopleSoft 同步化。

圖 2-2 通過 Designer 的資料流程

您也可能想要設計圖表，說明提出的商業程序，以及在該程序中實作自動化供應的優點。

從回答下列問題

正在移動哪些類型的物件 (使用者、群組等)？
對哪些事件感興趣？
需要同步化哪些屬性？
需要針對正在管理的各種類型物件在整個業務期間儲存哪些資料？
同步化是單向還是雙向？
每個屬性的授權來源是哪個系統？

考量系統之間不同值的相互關係很重要。

例如，PeopleSoft 中的員工狀態欄位可能具有三個設定值：員工、約聘和實習生。不過，Active Directory 系統可能只有兩個值：永久和暫時。在此情況下，需要決定 PeopleSoft 中「約聘」狀態與 Active Directory 中「永久」和「暫時」值之間的關係。

此工作的焦點應該是瞭解每個目錄系統、各系統彼此之間的關係，以及需要跨系統同步化哪些物件和屬性。在完成設計之後，下一步就是建立概念驗證。繼續進行節 2.3, 概念驗證。