2.2 Requirements and Design Analysis Phase

Take the high-level road map that was created in the discovery phase as a starting point for this analysis phase. The document and the Designer project both need technical and business details added. This produces the data model and high-level Identity Manager architecture design used to implement the Identity Manager solution.

The focus of the design should be specifically on identity management; however, many of the elements traditionally associated with a resource management directory, such as file and print, can also be addressed. Identity Manager synchronizes user accounts to directories that do not have direct access to the operating system’s file system. For example, you can have a user account in Active Directory, but that does not grant you access to the file system on the Active Directory server.

Using the information gathered in the discovery phase, answer the following sample questions to see what other information needs to be gathered. This might require additional interviews with stakeholders.

Identity Manager contains a tool to help you simplify the process of analyzing and cleaning your data. For more information, see Analyzer 1.2 for Identity Manager Administration Guide.

Review the information in Section 3.0, Technical Guidelines to help make the correct decisions for your environment.

After the requirements analysis, you can establish the scope and project plan for the implementation, and determine if any prerequisite activities need to occur. To avoid costly mistakes, be as complete as possible in gathering information and documenting requirements. Here is a list of possible requirements:

The following tasks should be completed during the requirements and design assessment:

2.2.1 Defining the Business Requirements

In the discovery phase, you gathered your organization’s business processes and the business requirements that define these business processes. Create a list of these business requirements and then start mapping these processes in Designer by completing the following tasks:

  • Create a list of the business requirements and determine which systems are affected by this process. For example, a business requirement for terminating an employee might be that the employee’s network and e-mail account access must be removed the same day the employee is terminated. The e-mail system and the Identity Vault are affected by this termination process.

  • Establish the process flows, process triggers, and data mapping relationships.

    For example, if something is going to happen in a certain process, what other processes are triggered?

  • Map data flows between applications. Designer allows you to see this information. For more information, see Managing the Flow of Data in the Designer 4.0 for Identity Manager 4.0 Administration Guide.

  • Identify data transformations that need to take place from one format to another, such as 2/25/2007 to 25 Feb 2007, and use Analyzer to change the data. For more information, see the Analyzer 1.2 for Identity Manager Administration Guide.

  • Document the data dependencies that exist.

    If a certain value is changed, it is important to know if there is a dependency on that value. If a particular process is changed, it is important to know if there is a dependency on that process.

    For example, selecting a “temporary” employee status value in a human resources system might mean that the IT department needs to create a user object in eDirectory with restricted rights and access to the network during certain hours.

  • List the priorities.

    Not every requirement, wish, or desire of every party can be immediately fulfilled. Priorities for designing and deploying the provisioning system will help plan a road map.

    It might be advantageous to divide the deployment into phases that enable implementation of a portion of the deployment earlier and other portions of the deployment later, or use a phased deployment that is based on groups of people within the organization.

  • Define the prerequisites.

    The prerequisites required for implementing a particular phase of the deployment should be documented. This includes access to the connected systems that need to interface with Identity Manager.

  • Identify authoritative data sources.

    Learning early on which items of information that system administrators and managers feel belong to them can help in obtaining and keeping buy-in from all parties.

    For example, the account administrator might want ownership over granting rights to specific files and directories for an employee. This can be accommodated by implementing local trustee assignments in the account system.

After you have defined your business requirements, proceed to Section 2.2.2, Analyzing Your Business Processes.

2.2.2 Analyzing Your Business Processes

After you complete the analysis of your business requirements, there is more information you need to gather to help focus the Identity Manager solution. You need to interview essential individuals such as managers, administrators, and employees who actually use the application or system. Issues to be addressed include:

  • Where does the data originate?

  • Where does the data go?

  • Who is responsible for the data?

  • Who has ownership for the business function to which the data belongs?

  • Who needs to be contacted to change the data?

  • What are all the implications of the data being changed?

  • What work practices exist for data handling (gathering and/or editing)?

  • What types of operations take place?

  • What methods are used to ensure data quality and integrity?

  • Where do the systems reside (on what servers, in which departments)?

  • What processes are not suitable for automated handling?

For example, you could use the following questions for an administrator for a PeopleSoft system in Human Resources:

  • What data are stored in the PeopleSoft database?

  • What appears in the various panels for an employee account?

  • What actions must be reflected across the provisioning system (such as add, modify, or delete)?

  • Which of these are required? Which are optional?

  • What actions need to be triggered based on actions taken in PeopleSoft?

  • What operations/events/actions are to be ignored?

  • How is the data to be transformed and mapped to Identity Manager?

Interviewing key people can lead to other areas of the organization that can provide a more clear picture of the entire process.

After you have gathered all of this information, you can design a correct enterprise data model for your environment. Proceed to Section 2.2.3, Designing an Enterprise Data Model to start the design.

2.2.3 Designing an Enterprise Data Model

After your business processes have been defined, you can use Designer to begin to design a data model that reflects your current business processes.

The model in Designer illustrates where data originates, where it moves to, and where it can’t move. It can also account for how critical events affect the data flow. For example, Figure 2-2 shows that the data flows from the PeopleSoft, but no data synchronizes back into PeopleSoft.

Figure 2-2 Data Flow through Designer

You might also want to develop a diagram that illustrates the proposed business process and the advantages of implementing automated provisioning in that process.

The development of this model begins by answering questions such as the following:

  • What types of objects (users, groups, etc.) are being moved?

  • Which events are of interest?

  • Which attributes need to be synchronized?

  • What data is stored throughout your business for the various types of objects being managed?

  • Is the synchronization one-way or two-way?

  • Which system is the authoritative source for which attributes?

It is also important to consider the interrelationships of different values between systems.

For example, an employee status field in PeopleSoft might have three set values: employee, contractor, and intern. However, the Active Directory system might have only two values: permanent and temporary. In this situation, the relationship between the “contractor” status in PeopleSoft and the “permanent” and “temporary” values in Active Directory needs to be determined.

The focus of this work should be to understand each directory system, how they relate to each other, and what objects and attributes need to be synchronized across the systems. After the design is complete, the next step is to create a proof of concept. Proceed to Section 2.3, Proof of Concept.