A Nexus

As far as I understand it, a Nexus is a central connector or hub of something.

We’ve signed a contract with Finalsite and are now moving through the first stages of planning a migration of our school website to the new Finalsite infrastructure. Overall, it’s a great opportunity to rethink a lot of information services for the school community.

For example, one of the first needs of the revised website are improved directories—of faculty and staff, of parents, and of alumni. In total, that’s about 20,000 individuals. The design of Finalsite is to have a single user list with different or multiple roles. Thus, we need to work out an integrated database that combines all of these groups, assigned unique IDs, and is capable of being updated from multiple databases on campus without overlap. The next challenge was to determine how all these users would authenticate to the new web site, of which 80% of the content will be behind a password.

For the data unification, we had long discussions about how to create a Human ID for every individual, as well as a sensible household or family interrelationship ID (so that parents could be linked to students, students to siblings and alumni, etc.). Our solution at this point is to create a new “Nexus” database on campus using FileMaker Pro that will pull core demographic data about all 20,000 individuals from various databases on campus, assign a unique Human ID that is permanent but interconnected with other IDs on campus (in Raisers’ Edge, in Personnel, in the Student Information System). This Nexus database pre-combines information from multiple sources and is the sole source of data for updates to Finalsite.

As for authentication, it’s a combination of options. Currently faculty and staff will authenticate by unique username and LDAP, because that is a core password for multiple services. For current parents, the authentication will be by unique username through the Finalsite database itself for a year, and then change over to an integrated Student Information System paired with Finalsite. Alumni will authenticate by a last name look up interface, paired with a unique password, through the Finalsite database They will have unique usernames, but will never see them, because the conventions used will be too complicated. (Also, this means that the 14,000 alumni don’t need to have usernames that complete with current student/faculty/parent usernames).

In the end, the real Nexus database may be Finalsite itself. Not just the single user list and directories, but the way we enable authentication into the portal to hand off role-based and unique sources of information. The concept of documents, news stories, calendar events, and other information being shared out by roles (student, parent, faculty, staff, alumni, board member, Tech Team, etc.) is something we’re just getting our minds around. Beyond that is single login authentication, to hand off direct access into the Student Information System for students, parents and faculty, or even VPN access to their network file shares (personal and course shares) via the portal.

3 visitors online now
0 guests, 3 bots, 0 members
Max visitors today: 7 at 03:22 pm UTC
This month: 9 at 09-20-2017 05:23 pm UTC
This year: 38 at 05-27-2017 07:36 am UTC
All time: 84 at 05-06-2013 07:12 am UTC