OpenRegistry Scope and Goals

Summary

The primary goal is to build a repository that captures and manages identity data that is general enough to be used by other Universities. Example populations to be supported by the OpenRegistry include regular students, continuing education students, joint program students, alumni, new employees, faculty, staff, retirees, and guests.

The OpenRegistry will be comprised of component registries, including a person registry, a group registry, a course registry, an account registry and a credential registry. An installation of the registry may use some or all of the components. The OpenRegistry will also support the substitution of a component registry with an external implementation for that component. Interfaces will be provided to plugin an external component.

The OpenRegistry will accept feeds via web, batch, and real-time data transfer from source of record systems and will provide feeds to downstream systems such as LDAP. Additionally, the OpenRegistry will perform identity reconciliation when adding new people to the registry to enforce unique entries.

Scope and Goals

Provide identify data store for person data, group data, course data, account data and credentials data.
Keep role and role specific data.
Keep biodemographic data.
Provide audit capability.
Provide interfaces for web, batch, and real-time data transfer to add, modify and delete data in the registry.
Provide for faster propagation of data, real time where possible to subscribing downstream systems.
Provide identity reconciliation from multiple systems of record.
Provide identifier assignment for new, unique individuals.
Provide a directory builder.
Perform provisioning and deprovisioning.

Design Principles

Design based on supportable, end-user focused, efficient processes.
Provide general purpose open system solution appropriate for other Universities adhering to open standards where possible.
Leverage other higher education efforts.
Open source offering.
Implement highly available, highly scalable, cost efficient technologies.
Implementation is component based. OpenRegistry can be installed with only the components that are desired.
Additionally, external components can be substituted for OpenRegistry components. Interfaces will be provided to plugin external components.
Use Business rules engine to generate additional data in other OpenRegistry components based on incoming data to a particular OpenRegistry component.
Implementation should be DBMS independent.

Implementation Approach

OpenRegistry is designed to be a general solution, however development will be driven by member institution needs and resources. In order to accomplish this, an extensive survey of the problem space according to the institutions is needed to provide guidance for the overall design, while specific short term objectives must be identified to provide guidance for implementation.

Problem Space Scoping Documents

The complete list of known Rutgers Institutional Use Cases
- This is currently a high level list, additional details may be useful
The complete list of Functional Requirements, as derived from the Institutional Use Cases
- This list is intended to be a technology independent list of functions OpenRegistry needs to provide
The complete list of Technical Requirements, as derived from the Functional Requirements
- This list is intended to be a technology specific list of implementations OpenRegistry needs to include

Implementation Scoping Documents

Member Institution Requirements, in a release-oriented format
OpenRegistry development Roadmap, based on Member Institution release-oriented requirements

Browser not supported