This section outlines high-level political and project management aspects of implementing Identity Manager. (For the technical aspects, see Section 2.3, Planning the Technical Aspects of Identity Manager Implementation.)
This planning material provides an overview of the type of activities that are normally 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® Solution Partner Web site. Novell Education also offers courses that address Identity Manager implementation.
We also strongly recommend setting up a test/development environment where you can test, analyze, and develop your solutions. After things are working the way you want, deploy the final product into your production environment.
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:
Identify the primary objectives in managing identity information
Define or clarify the business issues being addressed
Determine what initiatives are required to address outstanding issues
Determine what it would take to carry out one or more of these initiatives
Develop a high-level strategy or “solution roadmap” and an agreed execution path
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 eDirectory™, Novell Identity Manager, and XML integration in general.
It can establish a base level understanding among all stakeholders
It can capture key business and systems information from stakeholders
It can enable a solution roadmap to be developed
The discovery also identifies immediate next steps, which might include the following:
Identifying planning activities in preparation for a requirements and design phase
Defining additional education for stakeholders
Structured interviews with key business and technical stakeholders
High-level summary report of the business and technical issues
Recommendations for the next steps
An executive presentation outlining the outcome of the discovery
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 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. Here is a sample of items that you might want to assess:
What versions of system software are being used?
Is the directory design appropriate?
Is the directory being used to host the Identity Vault and Identity Manager or is it being used to extend other services?
Is the quality of the data in all systems appropriate? (If the data is not of usable quality, business policy might not be implemented as desired.)
Is data manipulation required for your environment?
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:
Establish the process flows, process triggers, and data mapping relationships.
For example, if something is going to happen in a certain process, what will happen because of that process? What other processes are triggered?
Map data flows between applications.
Identify data transformations that need to take place from one format to another, such as 2/25/2007 to 25 Feb 2007.
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 roadmap.
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. You can do a phased deployment approach as well. It should be 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 you are wanting to interface with Identity Manager.
Identify authoritative data sources.
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:
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, questions that might be posed to an administrator for a PeopleSoft system in Human Resources might include
What data are stored in the PeopleSoft database?
What appears in the various panels for an employee account?
What actions are required to 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 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 it moves to, and where it 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:
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.
Data model showing all systems, authoritative data sources, events, information flow and data format standards, and mapping relationships between connected systems and attributes within Identity Manager.
Appropriate Identity Manager architecture for the solution
Detail for additional system connection requirements
Strategies for data validation and record matching
Directory design to support the Identity Manager infrastructure
Staff familiar with all external systems (such as HR database administrator, network and messaging system administrator)
Availability of system schemas and sample data
Data model from the analysis and design phase
Availability of basic information such as organizational chart, and WAN and server infrastructure
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.
A functioning Identity Manager proof of concept with all system connections operational
Hardware platform and equipment
Necessary software
Analysis and design phase that identifies the required connections
Availability and access to other systems for testing purposes
Data model from the analysis and design phase
The data in production systems can be of varying quality and consistency and therefore might introduce inconsistencies when synchronizing systems. This phase presents an obvious point of separation between the 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.
Production data sets appropriate for loading into the Identity Vault (as identified in the analysis and design activities). This includes the likely method of loading (either bulk load or via connectors). The requirement for data that is validated or otherwise formatted is also identified.
Performance factors are also identified and validated against equipment being used and the overall distributed architecture of the deployment of Identity Manager.
Data model from analysis and design phase (proposed record matching and data format strategy)
Access to production data sets
The purpose of this activity is to begin the migration into a production environment. During this phase, there might 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 the necessary milestone en route to full production.
Pilot solution providing live proof of concept and validation for the data model and desired process outcomes
All previous activities (analysis and design, Identity Manager technology platform).
This phase is where the production deployment is planned. The plan should:
Confirm server platforms, software revisions, and service packs
Confirm the general environment
Confirm introduction of Identity Vault in a mixed coexistence
Confirm partitioning and replication strategies
Confirm Identity Manager implementation
Plan the legacy process cutover
Plan a rollback contingency strategy
Production rollout plan
Legacy process cutover plan
Rollback contingency plan
All previous activities
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.
Production solution ready for transition
All previous activities