2.2 需求和設計分析階段

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

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

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

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

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

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

2.2.1 定義業務要求

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

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

  • 建立程序流程、程序觸發和資料對應關係。

    例如，如果特定程序發生某些問題，則該任務將因此造成何種問題？會觸發何種其他程序？

  • 對應應用程式之間的資料流程。Designer 可讓您查看這個資訊。如需詳細資訊，請參閱《Designer 3.0.1 for Identity Manager 3.6 管理指南》中的「管理資料流程」。

  • 識別從一種格式變成另一種格式所要發生的資料轉換，例如從 2/25/2007 轉換為 25 Feb 2007。

  • 記錄存在的資料相依性。

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

    例如，在人力資源部門系統中選取「暫時」員工狀態值，可能表示 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, 概念檢驗。