This section outlines high-level political and project management aspects of implementing Identity Manager. (For the technical aspects, see Planning the Technical Aspects of Identity Manager Implementation.)
This planning material provides an overview of the type of activities that would normally be taken from the inception of an Identity Manager project to its full production deployment. Implementing an identity management strategy requires you to discover what the needs are and who the stakeholders are in your environment, design a solution, get buy-in from stakeholders, and test and roll out the solution. This section is intended to provide you with sufficient understanding of the process so that you can maximize the benefit from working with Identity Manager.
We strongly recommend that an Identity Manager expert be engaged to assist in each phase of the solution deployment. For more information about partnership options, see the Novell® NsureTM Solution Partner Web site. Novell Education also offers courses that address Identity Manager implementation.
This section is not exhaustive; it is not intended to address all possible configurations, nor is it intended to be rigid in its execution. Each environment is different and requires flexibility in the type of activities to be used.
There are several activities suggested as best practices when deploying Identity Manager:
You might want to begin your Identity Manager implementation with a discovery process that can do the following:
Discovery provides a common understanding of the issues and solutions for all stakeholders. It provides an excellent primer for the analysis phase that requires stakeholders to have a basic knowledge of directories, Novell eDirectoryTM, Novell Nsure Identity Manager, and XML integration in general.
The discovery also identifies immediate next steps, which might include the following:
This analysis phase captures both technical and business aspects of the project in detail and produces the data model and high-level Identity Manager architecture design. This activity is a crucial first step from which the solution is implemented.
The focus of the design will 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. Here is a sample of items that you may want to assess:
After the requirements analysis, you can establish the scope and project plan for the implementation, and can determine if any prerequisite activities need to occur. To avoid costly mistakes, be as complete as possible in gathering information and documenting requirements.
The following tasks might be completed during the requirements assessment:
Gather your organization's business processes and the business requirements that define these business processes.
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 following tasks can guide you in defining the business requirements:
For example, if something is going to happen in a certain process, what will happen because of that process? What other processes are triggered?
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.
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 roadmap.
It might be advantageous to divide the deployment into phases that will enable implementation of a portion of the deployment earlier and other portions of the deployment later.
The prerequisites required for implementing a particular phase of the deployment should be documented.
Learning early on which items of information 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.
The analysis of business processes often commences by interviewing essential individuals such as managers, administrators, and employees who actually use the application or system. Issues to be addressed include:
For example, questions that might be posed to an administrator for a PeopleSoft system in Human Resources may include
Interviewing key people can lead to other areas of the organization that can provide a more clear picture of the entire process.
After your business processes have been defined, you can begin to design a data model that reflects your current business process.
The model should illustrate where data originates, where they move to, and where they can't move. It should also account for how critical events affect the data flow.
You might also wish 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:
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.
The outcome of this activity is to have a sample implementation in a lab environment that reflects your company's business policy and data flow. It is based on the design of the data model developed during the requirement analysis and design and is a final step before the production pilot.
NOTE: This step is often beneficial in gaining management support and funding for a final implementation effort.
The data in production systems can be of varying quality and consistency and therefore may introduce inconsistencies when synchronizing systems. This phase presents an obvious point of separation between the Nsure Resources implementation team and the business units or groups who "own" or manage the data in the systems to be integrated. At times, the associated risk and cost factors might not belong in a provisioning project.
The purpose of this activity is to begin the migration into a production environment. During this phase, there may be additional customization that occurs. In this limited introduction, desired outcomes of the preceding activities can be confirmed and agreement obtained for production rollout.
NOTE: This phase might provide the acceptance criteria for the solution and/or the necessary milestone en route to full production.
This phase is where the production deployment is planned. The plan should:
This phase is where the pilot solution is expanded to affect all live data in the production environment. It typically follows agreement that the production pilot meets all the technical and business requirements.