Problem
A hierarchy of organizational units and groupings and the people associated with them is to be reflected from a system of record into an operational system which uses this roster information for access management or for distribution lists.
Organizational hierarchy is a common source of both authority and access privilege, and is frequently the basis for determining membership in groups and/or inclusion in distribution lists. Workgroups combine to form units which form divisions; departments combine to form schools and colleges. The authority and access afforded individuals is often scoped based on organizational hierarchy (eg., a department head may have privileges scoped to cover all faculty in the department, while dean may have the same privileges, but scoped to cover all faculty within the departments comprised by an entire school). In the electronic world, systems that manage or use access privileges need to reflect real-world organizational hierarchies.
A variation on this basic problem often occurs in Higher Ed environments -- the hierarchy of the organisation does not fully match the access control requirements of a system or a set of data; minor adjustments of the group membership are required. The official hierarchy is often a representation derived from HR/finance systems. This hierarchy is more representative of financial and line management concerns than it is of how other concerns such as research and teaching is organised and structured. While this official hierarchy is often the best available representation it often requires some adjusting to make it useful for representing the research or teaching structure. A blended hierarchy builds on an official hieararchy with some adjustments made so that it represents the actual access control needs of the application.
Blended requirements often arise in administrative applications when rosters are derived from payroll systems. Individuals may have authority or membership in campus departments, centers, and institutes that are not their primary funding source. Blended requirements arise most often, however, in the instructional and research space, where the central business systems have no interest in tracking the detailed role information instructors want to apply to systems supporting instruction.
Solution
The simplest solution to implement technically is to take a snapshot view of the organisational hierarchy at a point in time, import it into an access control list for the resource and then have an administrator manually update it on a regular basis. However this solution does not scale well and over time leads to increasing duplication of effort as changes in membership have to be updated in the organisational hierarchy and the access control list. Experience shows that more effort is invested in adding people than in removing them when access is no longer authorized.
MACE Grouper provides a more scaleable and robust solution. Hierarchy informationis used to manually create a set of structured groups -- eg departments, colleges, comunity, etc. Provisioning software then uses information provided by institutional HR and ERP systems associating individual faculty and staff with their respective departments to maintain the membership of departmentally-oriented groups; provisioning software can perform the same task for course-related groups. This means that any changes to the official rosters are automatically propogated to the group and adminstrators only have to manually update the additional cases. Each department typically has three groups: a provisioned one, a manually maintained one (for the adjustments), and the "effective" one (which is the union of the first two).
Courses provide a slight variant of the department scenario. A Student Information System can provide identifiers for the official instructor(s) and students, and sometimes Teaching Assistants. This information can be used to provision the appropriate groups. However, identities for guest lecturers, some TA's, students auditing the course, and content managers (often students) supporting the instructor's use of technology are usually manually maintained. The "three groups" approach is then used to create an effective group for each category.
Examples
Within MACE Grouper, the Groups Manager creates a Departments container, and creates a set of groups for each administrative and academic department. Provisioning software is then used to regularly maintain the membership of a group representing the ERP roster for each department.
We are currently working with the authors of our current homegrown faculty management system to negotiate the development of something similar to this. We are finding that representing organizational hierarchy through group membership can be very flexible and effective (faculty may be appointed in multiple departments, which may map into multiple group memberships in LDAP; groups can be constructed for interdisciplinary programs which may in turn fit into the organizational hierarchy in a similar fashion to traditional departments). The model has its limitations, but the more complex problem seems to be that of defining and maintaining the organizational hierarchy information itself - we are finding that in some cases the institutional hierarchy may be reported differently depending on context (eg., the Institute for Environmental Policy may be considered part of the College of Arts and Sciences by the Dean of that college, but may be viewed as part of the School of the Environment by the dean of that school), or may be entirely undefined except by unpublished agreements between academic administrators and the Provost.
Professor Jones is a member of the Microbiology group, and Dean Johnson is a member of the Anatomy group. A supergroup is constructed for the Division of Basic Sciences by conjoining Microbiology Anatomy Cell Biology Pharmacology. Another is constructed for the School of Medicine by conjoining the Division of Basic Sciences with other Divisions (Neurology, Cardiology, Hematology, Oncology, etc.). Members of the Microbiology group are automatically members of the supergroups. The relevant groups and supergroups are projected into an LDAP directory as LDAP groups (possibly in a separate LDAP OU reserved for groups that reflect organizational hierarchy). The faculty management system and the budgeting system then consult the LDAP for group membership information when making access decisions - user roles ("Chair", "Dean", etc.) have their privileges scoped based on group memberships - department chairs are granted rights scoped to the members of their departmental groups, while divisional deans are granted rights scoped to their divisional supergroups.
An example of the need for a blended organisational hierarchy is room booking and timetabling systems. In Newcastle student interview/contact rooms used by support staff (careers, student welfare etc ) are owned by a particular service. For instance careers owns and controls the rooms on their floor in the student services building. However some other departments such as student welfare or accessibility support are able to book the rooms as they occasionaly need to use the unique facilites offered by the room. We are using the MACE Grouper group management tool to nightly import the official hierarchy into it from our HR records system. We then setup a group which includes the careers group from the official hierarchy and has other users that are added by hand. This then feeds into the Sylabus plus web based room booking system to authorize who can book which rooms.
Access to teaching materials in VLEs and repositories is another example of the need for a blended organizational hierarchy. Courses are often the responsibility of a organisational unit in the official hierarchy (e.g. biology is taught by the biology department staff) but then have adhoc input from people in other units, (e.g. the biology course may have lectures on statistics given by a mathematician, another example is that non staff members such as postgrad students may act as tutors on courses) In order to grant access to course materials it is necessary to take the organisational group (e.g. biology) from the official hierarchy and add these additional adhoc members.
Another blended example is the provision of collaborative tools such as wikis to research groups. A research group is often largely based in an organisational unit as represented by the organisational hierarchy however it will often include additional members from other parts of the organisation. For instance a research group studying biomaterails will draw it's memebership from the biomaterials research group but may also include members from the chemistry or physics department.