projects: core user directory - further information
Core User Directory Project - Project Profile
The Core User Directory Project consists of two parts: a requirements gathering exercise to determine the needs of University administrators and ICT service providers in terms of their management and use of user attributes, and the deployment of a University Core User Directory.
Project Objectives and Key Objectives
The CUD project lays the foundations for a future programme of activities to deliver a coherent Identity and Access Management framework for the University of Oxford. The goal is to deliver an enterprise Core User Directory by the end of calendar year 2008.
Although the project is stand-alone, it will be important to recognise that decisions taken may have implications for the wider Identity and Access Management programme, and as a consequence the requirements gathering will have to be comprehensive.
- Month 1: Identify dedicated staff to undertake requirements gathering; specify detailed work-plan for first 6 months; set up interviews; gather information for initial use cases/scenarios.
- Month 2: Create use cases/scenarios built on needs identified across the University and developed through interviews with staff responsible for applications that will interact with the CUD in due course.
- Month 3: Hold a facilitated workshop for the members of the CUD working party. Appraise the use cases/scenarios generated in month 2, extract requirements for the CUD (employing external expertise), and prepare for work in months 4-6. Validate the use cases.
- Months 4-6: Undertake detailed requirements gathering and analysis of identity work flows, how these would relate to the CUD, and which would be supported. If resource available, also create a first CUD pilot and experiment with transferring data from some of the key enterprise databases. Determine the business rules to match and clean user attributes.
- Months 7-9: Develop the architecture and agree the content for a CUD; identify solutions and hardware infrastructure; pilot service with selected applications (e.g. Student System, OULS cardholders; University contact search). Decide whether the CUD is based on an irreducible set of attributes or whether it is effectively a 'data warehouse'.
- Months 10-12: Implement CUD, build connections to selected enterprise databases, populate CUD with clean user attributes.
- Our administration processes that relate to people and their identities are complex, costly, potentially error-prone and do not enhance the experience of someone joining the University community. Errors to do with access to services are hard and time-consuming to troubleshoot and rectify.
- It is difficult, cumbersome, sometimes impossible, to join together identity attributes held in heterogeneous databases in order to provide key ICT services, whether centrally or within departments and colleges.
- Other Universities are significantly further ahead in resolving these problems than we are.
The Project has three phases: A, B and C. A corresponds to months 1-6, B to 4-8 and C to 7-12.
A. Detailed requirements gathering and analysis of user identity management:
1. Investigate how other large organisations with greater than 20,000 people have tackled similar issues.
2. Analyse and map key processes within the University that deal with the administration of people whether they are staff,
students, library service readers, consultants, contractors etc.
3. Identify and catalogue centrally-provided applications and databases that hold information about individuals, including keys and
attributes, software vendor details, supporting technology platforms and versions [include a sample of dept/college applications?].
4. Identify and catalogue existing and planned applications that require access to authoritative sources of user attributes in order to function;
document required or preferred interfaces for attribute retrieval.
5. Identify departmental roles involved in the administration of people and the level of access to data that they require to fulfil their roles.
6. Arrange interviews with relevant staff, both administrative managers, and users, of databases that are responsible for attributes
relating to people or require access to attributes relating to people.
7. Understand their current practices, and identify improvements that could be made.
8. Construct use cases that represent typical examples of manipulating the data that relate to user attributes.
9. On the basis of the requirements gathered, the improvements needed, and the use cases, determine the specification of a
CUD that will be the single master user directory for the University of Oxford, containing a minimum set of
attributes and a globally unique ID for each user.
10. Determine the business rules that are required to match and clean user attributes.
11. Identify current Data protection and security issues.
12. Document findings.
B. Architecture and content for CUD:
1. Design the architecture for the CUD, the protocols required, the interfaces, and the structure of the Directory - including a specification
of the attributes (determining which attributes are held in the CUD, and which can be referenced from elsewhere, and how this will be done).
2. Identify any technology barriers that would prevent or preclude interoperability between the applications and databases identified in A.
3. Select solution, including hardware infrastructure, to provide CUD and interoperate with the databases identified in A.
4. Document findings.
C. Implementation of an initial Core User Directory:
1. Based on the work described under B., implement a CUD that has the attributes that are required in order for it to serve its purpose
as the definitive access point for user attributes and identifiers for people connected with the University of Oxford.
2. Identify some of the key enterprise activities in the University (e.g. student data, registration, card database and HR database)
and create the connections between these applications and the CUD.
3. Document findings.
- A report that specifies use cases/scenarios of providers that manage data relating to people or require access to attributes relating to people, specifies work flows, determines which can be supported, and highlights deficiencies of the current arrangement [months 1-3].
- A report from the facilitated workshop, which includes validation of the use cases [month 3].
- A report specifying detailed requirements from staff dealing with identity and an analysis of the implications for the CUD [months 4-6].
- If sufficient resources, implementation of a pilot CUD, and a report on the work flows, importing and exporting [months 4-6].
- Specification for a Core User Directory, in terms of its architecture, structure and the protocols it uses [months 7-9].
- Implementation of a Core User Directory that will be the hub for future identity and access management developments in the University [months 10-12].
- Interoperation of the implemented Core User Directory with a selection of key enterprise application databases [months 10-12].
- A report that describes the implementation of the CUD and its interoperation with a selection of enterprise databases [month 12].
- Lack of access to or cooperation from key people within the University.
- Lack of adequate resources allocated to the project will cause lengthy delays and may affect the quality of the deliverable.
- Duplication of effort with other projects (e.g. within OUCS or BSP).
- Inability to reach agreement over how data are imported into, or exported from, the CUD.
First 6 months:
- Two 0.5 FTE posts from within the University, backfilled for 6 months (£37.5K)
- External Project Advisor to ensure approach correct and to facilitate workshop (£5k)
- Resource for pilot implementation of CUD?
- External Project Advisor to ensure approach is correct and to facilitate workshop (£5k)
- One 0.5 FTE business analyst from within the University, backfilled with a contractor (£20K)
- Project manager (£25k) (may be external)
- Consultancy (£25k) (may be external - or should this be allocated to technical implementation?)
[nb - this doesn't include the technical staff costs associated with implementation]
Total c. £120K. Note: the backfill costs may look high but contain provision for bringing one of the two roles in on contract if the role can't be filled from within the University.
The project manager would be expected to be very hands-on during this phase and undertake a significant amount of business analysis as well.
- A clear understanding of key administrative processes and applications that manage or make use of user attributes, and how those processes could be streamlined and automated in some areas to simplify provisioning and de-provisioning of services to those individuals, given the use of suitable technology.
- A Core User Directory comprising a minimum set of attributes and globally unique identifiers to serve as a hub for the future development of an Identity and Access Management framework for the University.
[The above text is taken from the Project Profile, the full version is available: CUD Project Profile (PDF 50 KB) ]