Skip to end of metadata
Go to start of metadata

Introduction

This page provides the basic information about IDM deployment projects.

TODO

Methodology

TODO

Estimating the Effort

Identity Management projects are not the usual download-install-operate projects. IDM product customization is not a simple configuration. It can be said that it is somewhere halfway between configuration and programming. Therefore the usual deployment project estimate techniques do not apply to IDM projects well.

MidPoint is a product which is designed to be deployed very efficiently and vast majority of common IDM requirements can be easily configured. But the devil is in the details. It is the minority of the unusual requirements that may complicate the project. Therefore even with midPoint estimating the project effort is still no easy task.

Input Data

There are few things that any IDM expert needs to know before he can provide even a rough estimate of project effort. These are the data that the expert usually needs:

  • Number of managed identities: This usually means number of physical persons that will be maintained by the system. E.g. the number of employees, temporary workers, customers, etc.
  • Type of managed identities: whether the identities are employees, temporary workers, contractors, partners, suppliers, customers, volunteers, subscribers, general (self-registered) users, etc. If the system has to manage more identity types also try to estimate how many identities of each type are there (in absolute numbers or as a percentage).
  • Total number of connected resource types: In IDM parlance a "resource" is a system connector to the IDM solution. It can be a target system (system into which IDM provisions identity) or a source system (such as HR database).
  • Number of custom resource types: The number of systems that are not "stock" systems that can usually be found in all organizations. I.e. systems that are not LDAP servers, Active Directory, databases, popular operating systems, etc. We expect that a custom connector will be needed for such resources. Of course, there is no strict boundary between custom and non-custom system. Therefore use your instinct. Or have a look at list of available connectors. But even that is still a bit risky as some connectors are very generic and need to always be customized. If you want really precise estimate then please enumerate all the types of connected resources and we will decide if we need a custom connector for it or not.
  • Number of resource instances: The number of connected systems (servers) for each type. E.g. the number of database servers or Linux servers that the IDM solution has to manage. If there are one or two instances of a particular resource then you do not need to know this number. We also do not need to know if the servers are managed indirectly (e.g. through LDAP server). Please specify this only if there is a high number of server instances that the IDM solution has to manage directly.
  • Information sources: Please specify which resources has authoritative information about your identities (if any). It is OK to have several sources of information.
  • Number of organizational units: If you plan to manage or use organizational structure please estimate the total number of organizational units (divisions, sections, projects, teams, etc.)
  • Expected number of roles: Please try to roughly estimate the number of roles that you expect in your solution. We know that this is very early to know for sure and this is fine. It does not need to be precise. We will only use it as an estimate about how complex the role model is going to be. If you are not sure then try to use the number of job types or positions as a rough estimate.
  • Do you plan to use approval workflows? Do you plan that your users will request privileges and someone else will approve the request?
  • Do you plan to use self-service? Do you want your regular (non-administrator) users to interact with the IDM solution? E.g. Do you want your users to reset their passwords using automated password reset process? Do you want your users to self-register to gain access to the system?

The number of identities, organizational units and roles does not need to be precise. It does not make much difference if there is 4000 identities or 7300 identities. We mostly care about the rough magnitude of the user base. E.g. if it is a couple of thousands, tens of thousands or a million.

Other data also does not need to be exactly precise. But please keep in mind that the less precise data you provide the less precise the estimate will be. Garbage in, garbage out.

Note: The number of identities itself is actually not very important for estimate. The IDM system that works for 100 identities will also work for 3000 identities if all of them are the same. But the number is important in an indirect fashion. The deployments that manage more identities also tend to be more complicated - as every rule has exceptions and the exceptions tend to accumulate in large user bases.

IDM Is Not a Project, It Is a Program

Even though this page describes the IDM projects, it is important to remember that Identity Management is not a project. Identity Management is similar to information security. It has no beginning and no end. It has to be implemented continually.It has to be deployed and maintained, policy definitions needs to be updated, reviewed, adjusted and so on. All the time. If anyone claims that "you just buy product X and it will solve all your problems" he is probably not telling the truth. The product matters a great deal. But no product can be deployed and then it "just runs". It has to be continually maintained. If you do not have the capacity to maintain it yourself then make sure you have the budget for IDM program every year.

Therefore we strongly propose to deploy the IDM in a series of iterations. Each iteration delivers a particular quantity (features) and/or quality. It is the first few iterations that we call IDM project. And undoubtedly, these iterations are the most demanding and most costly. But the effort does not end after "the project" is finished. It just transforms to a continuous and sustainable form.

External links

 

  • No labels