You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 2
Next »
DRAFT - August 13, 2012
Outcome of Registry Evaluation
The Registry Workstream conducted detailed reviews of the Kuali, Central Person Registry (CPR) and Open Registry (jasig) projects.
The group concluded that both Open Registry are well-developed projects that meet (or will soon meet) key CIFER criteria, this is, they are:
- Open Source (PSU working on licensing now)
- Designed to work in loosely-coupled, standards-based environment
- Targeted to meet the needs of higher education
The group debated a length the relative pros and cons of picking a single Registry solution as the CIFER registry. In the end, the group decided not to choose one. It was acknowledged that significant investment in CPR and Open Registry have already been made at Penn State and Rutgers respectively, and that both solutions will continue to live in the marketplace. Some felt that endorsing both solutions would shift the focus to developing common interfaces over time, which would benefit the CIFER project in the long run. It was also acknowledged that each product had different features and there were legitimate reasons why any given campus might choose one product over the other. Some expressed concern that CIFER should not spread its resources (limited as they are) over two products with near identical functionality, rather than focusing investment in one Registry product alone. The conversation then came back to the point that even if CIFER chose only one Registry (OR or CPR), the other would still exist and might be the best solution for some campuses, and would receive additional investment whether through CIFER or not.
Towards the end of the evaluation meetings, our thought leader RL "Bob" Morgan noted that the highest priority was to get both projects in a state where other campuses could "click and download" them, which is noted below as a priority next step.
Below is a table which outlines at a high level what the group identified as some of the pros and cons of each solution. Of course, a feature that is a pro for one campus could be a con for another, so campuses seriously considering new registry solutions should review the materials collected, in writing and the presentations, on each of the Registry solutions on the main Registry Evaluation page.
Central Person Registry (CPR)
Pros |
Cons |
- Mature, well-developed product
- Very well documented
- Imposes unique id at the time an individual is enrolled in any system of reference (SOR).
- Has a good identity matching process.
- Has a process that normalizes addresses.
|
- Business model based on a very tight coupling between Registry and SORs, where Registry generates IDs to be used by SORs. This works well in an environment which supports tight technical and functional owner integration between SORs and IDMS. Can be very challenging to adapt to an environment where SORs are managed outside IAM teams and in technology that does not support real-time integration with IDMS for unique ID generation.
- Identity matching and address normalization software are not open source and are expensive.
- All data for an individual is stored in a single set of tables (database) with effective dates and end dates indicating which record is current, historic or future. This might make the check for the current data less intuitive.
- Not yet released as an open source project
|
Open Registry
Pros |
Cons |
- Keeps a set of tables with the data received from the SOR for each individual.
- Current data and historic data are kept separately.
- Already an Open Source project hosted by Jasig (currently still in incubation)
- Rutgers has a UI now that does a lot of what we would want to do (even though it is not part of the open source code base)
- Does not assume it is the source of IDs (which would give us more flexibility - for example since it is not the source of IDs, we could very easily add the PeopleSoft emplid from UCPath's PeopleSoft implementation, also UCB and UCSF have different ID requirements, and OpenRegistry could accommodate both)
|
- Identity match is rudimentary (this won’t be a big issue for campuses that want to run ID match externally, anyway).
- Still a new project, not yet in production.
- While it is an incubation project of jasig, Rutgers is the only campus that has been contributing for some time and migrating to a community support/development model will take some time and effort.
- It appears that some of the UI that Rutgers is using is not open source and is developed against OpenRegistry directly, and not against the API.
- API will need to be expanded as it currently does not implement all of the functionality that the Rutgers UI can do.
|