On the Meeting with the Registrar

Notes from the meeting // Issues the meeting brought up

Notes from the meeting

Here is a general summary of my notes and observations from the meeting with David Wiley, MIT's registrar. Before you read on, I would like to include the following disclaimers:

• These notes provide additional background info for design project 2. Note, however, that your team's design does not have to follow the registrar's ideas about electronic student services.

• There are no guarantees that anything I say in these notes is accurate. It is entirely possible that I made mistakes in writing things down, or that I misheard, misquoted, or misinterpreted things that Mr. Wiley said.

• It is also possible that some of the things I say below may come out slanted due to my own biases. Please to not take anything I say here to be the "universal truth." (Although I have tried to report as objectively as possible.) Probably the same disclaimer should be made about the things Mr. Wiley said himself.

• Mr. Wiley started off saying that they have had a vision of electronic student services for quite a while now, and the first step towards this is was the prototype SIS system that has been available on Athena for 4 years now.

• Some of the things they have been considering for services include:
  • transcripts (official vs. unofficial?)
  • certifications for insurance discounts, etc...
  • bursar's information
  • financial aid information
  • temporary address to send term grades to
  • degree audit
  • what-if games (hypothetical schedules, "what if I change major?")
  • course evaluations

• The first question asked was about the purposes of signatures on forms. The registrar said that he does not determine the policy of who signs what form. Those policies are determined by the faculty rules. He just implements those rules. All changes to those rules require faculty approval. [See footnote 1]

• This lead him to say that he believes that in the case of add/drop cards, most of the activity (3/4'ths by his estimate) occurs in the first few weeks of the term. Although signatures are currently required on these forms even in the first few weeks, he wouldn't be surprised if that rule were changed by the faculty to allow for electronic add-drop. Paper forms (with signatures) could be required after the first few weeks, but this would only account for a small percentage of the activity. In the case of electronic add-drop, a system of after-the-fact notification could be used instead of signatures. (e.g., advisor could be informed by email and then raise a flag if he/she saw something unusual.)

• Someone asked about HASS forms: "Why do they require so many signatures when all you need to do is go around to a bunch of offices and just get signatures without actually talking to anyone?" Mr. Wiley responded first by saying that HASS forms aren't really in his domain of authority. Then he said that he believes that the original intent of those forms was to have students sit down and talk with professors. Perhaps the current system has deviated from the original intent. They should probably either revise it to once again encourage meetings with professors, or else to just not have so many signatures.

• Question: "How is preregistration information used by the registrar?"
  1. Departments use it for planning and to allocate/deallocate resources. They usually get this info within a week or so. E.g., for Fall term, they get info in late May and spend June planning for actual classes.
  2. It is used to prepare student schedules for registration day. These provide students with a "base schedule" to work with, instead of creating one from scratch.

• This last question led him to talk about the future plans for preregistration. The hope is that preregistration could become more of of an actual registration. If it were moved a bit further away from the end of the term, then people wouldn't be so busy and might have more time to meet with their advisors then (instead of on reg day) and spend a lot more time thinking about their schedules.

• Someone asked: "How long does it take for the registrar's office to type all the reg. forms in?" I think the answer was a bit surprising to most people: it is a really fast process, actually. It takes a couple of people working 4 or 5 days max. The implication of this is that going to electronic student services has nothing really to do with getting rid of a performance bottleneck (at least in their office), it has to do with providing more useful services (e.g., quick turnaround, end-user more in control of the process, etc...).

• Someone else asked about the possibility of students choosing their own recitations. He responded by saying that MIT has traditionally acted differently than most other schools by assigning recitations. (Most other schools use first-come-first-served.) This follows the philosophy of meeting the student demand for classes. It also balances out sections pretty evenly. And it is also supposed to help save the students the (supposed) hassle of figuring out which recitations they can fit into their schedules. Course 6 is different than most other courses because it allows students to choose. Perhaps this is because it has so many group projects and it wants students to have some control over who they work with as partners?

• Question: "So if the registrar doesn't spend so much time typing in forms, what do they spend most of their person-hours doing?" He said that they probably spend most of their time dealing with individual needs. Answering specific student questions and dealing with departments.

• Question: "How are grades submitted?" [See footnote 2] The basic answer is that the registrar's office prepares grade sheets for departments and sends them over to the departments or sometimes the professors individually. The professors fill them out, and return them by hand. (Some departments are more centralized in that the professors first return the grade sheets to the department.)

• "Do they accept electronic submission?" Yes they do, although a signed copy of the grade sheet still must be received by them for their paper records. (There was actually a case of fraud once with electronic submission. The paper record was used to verify this.) Electronic submission does not happen over email, it happens over their "secure network". [See footnote 3]

• He then talked about several other things concerning their electronic records. The system contains all records going back to the 1960s. (Before that, you must go to paper.) For all students since 1994, their records are only stored electronically. A full backup of the entire system is performed once a week.

• Question: "What is the behind the scenes process for getting a transcript?" Up until about a year ago, it was all done with paper records. To create a transcript, someone had to go make a xerox of your paper record from some huge file cabinet. Now it it is all done electronically. They service about 20,000-25,000 requests for transcripts every year.

• Question: "Is anything not stored electronically?" Probably the only thing is student signatures. (Which have been used to detect fraud several times.)

• Question: "What about the legal issues of requiring signatures? What about using kerberos/digital-signature authentication?" This hasn't really been resolved yet. For example, they accept signed fax submissions of transcript requests, but this must be followed up by an actual signed letter.

• Question: "What kind of database is used and is it shared between all the different offices?" Also, "Do you feel that the current system is a 'legacy' system in that the only reason you are still using it is because it is too hard to change?"
  • The current database being used is actually quite new. Several years ago they started the process of creating an entirely new system. They brought in consulting companies, and debated whether or not to buy a commercial system or to create their own system.
  • They ended up buying a commercial system from SCT Systems (?), and then modifying a lot of it to fit their needs. This was good in that they used the unmodified version to create a prototype, and then had people from all the different offices use it and make suggestions on how to change it. This was much easier than it would have been to create their own prototype.
  • They are extremely happy with the current system. Whereas the old system pretty much stored everything in files, the new system uses a state-of-the-art relational database.
  • The implication is that electronic student services would not involve designing a new back-end system. It would involve creating new and useful interfaces to that system.
  • All offices connect to the same back-end system, so in fact all information is shared. There is one exception though: there are several cases where certain offices are required to keep their own information separate. For example, the bursar's office keeps students' billing address separate and private because they are required to by law.

• "What about SIS?" SIS uses an extra kerberos password and encrypts all transmissions. It is not speaking to the live database itself, it is looking at a mirrored copy of the database that is transferred over nightly. [See footnote 4]

Footnotes

1) You can read some of the actual institute policies on the MIT Policies techinfo page. One useful one in particular is the "The Privacy of Student Records" policy page. Note that these policies are dated 1990 and may be slightly out of date.

2) Check out transaction number 102 on the 6.033 discuss meeting for some more information about submitting grades.

3) Most people were pretty confused whenever Mr. Wiley mentioned the "secure network." To the best of my knowledge (no guarantees here), the secure network consists of: a few IBM 3090 mainframes kept down in W91, and connections to these mainframes via MIT's internal phone system. I think that in order to connect to the mainframe, you need to plug your computer into the serial port on the back of those black AT&T ISDN phones. There may be other additional requirements (e.g., someone has to turn on your connection in a phone closet somewhere.) Of course, you also need a valid account and password. Either way, the general idea is that this all happens over MIT's internal phone network, and not MITnet, which is a broadcast packet network and a lot easier to abuse in terms of spying on traffic and breaking into machines.

4) Check out the 6.033 discuss meeting for some transactions that were posted about SIS.

Issues the meeting brought up

Some of the registrar's comments brought up some issues about the design project and added constraints to the problem we gave you. Here is one set of responses to those issues--one view of how to reconcile the registrar's opinions with the design project's goals. You should treat our responses as additional food for thought.

You should remember that the registrar is only one of the system's users, and has one particular view of what it should do. This doesn't mean that the registrar's view or needs will equal students' views or needs, or departments', or faculty's. This design project is turning out to be very realistic: the users may not know exactly what they want, and different users may have conflicting needs. You will encounter this many more times in your lives!

1. We are asked to "think through the processes behind the forms. Maybe you can simplify several forms into one...."

   However, the registrar cannot necessarily simplify the forms. The signatures required on each form, and the content of the forms in general, are mandated by faculty rules. The registrar only implement these rules.

   Response: You should make recommendations to the faculty concerning what forms should be changed and how, but be flexible enough to handle whatever decision they make.

2. State law (might actually be national law) mandates that a request for a transcript be physically signed by the student.

   Responses:

   1. The electronic request you implement might not be binding, but a "hint" for the registrar to start processing the transcript, much like fax requests-for-transcripts are now. (When a fax request is received, the registrar starts processing the form, but waits for actual written and signed notification before sending.)
   2. You could design a protocol secure enough to act as a legal test case for digital signatures!

      (For your browsing pleasure, here is a set of pages on Utah's Digital Signature Law. Do not worry about legal issues such as this law when doing your design project! This link is mostly for fun.)

3. The registrar is very happy with the back-end system in place now, and cannot think of anything that needs changing. (The back-end system is the mainframes currently handling the databases and forms.) Can't we just use the existing back end?

   Responses:

   1. It is not sufficient to simply say that you will use the registrar's existing computer system as a back end to your design. If you do use the existing system, you must convince your audience that the existing system will meet all proposed and future needs, and has no holes. Think about scalability (if enrollment quintuples or more), security (the current system is not directly connected to MITnet; yours may have to be), etc.

      If you do use the registrar's system, we don't expect you to understand it from the inside out. One way to meet our expectations would be to give a large set of explicit assumptions about how the current back end might work, and work only from those assumptions when creating the rest of your design. (Note that, if these assumptions are detailed enough, you will have essentially redesigned the back end!)

   2. It is not surprising he is happy with what the Registrar's Office built themselves: they know it, they control it, etc. However, this does not mean that the registrar's view coincides with the rest of the users of the system! They might agree, or not.

4. When someone brought up Issue 13,

   How will you make sure that your system continues to work, with minimal changes, when major Institute policy shifts (like intermediate grades, class-specific drop dates, or advisor-specific add and drop policies) are implemented?

   Mr. Wiley laughed out loud. "Class-specific drop dates? Advisor-specific add or drop policies? That would be a nightmare! The faculty would never go for that."

   Responses:

   1. We have subject-specific add dates now: you can add or reduce units for your thesis or UROP right up to the day that the grade is submitted.
   2. It might be easier to point to history than to second-guess the future. Over the last thirty-five years we added Freshman Pass/Fail, junior-senior Pass/Fail electives, and January IAP. The general Institute requirements have switched from counting hours to counting subjects. The science distribution requirement has gotten more complicated. Institute Laboratories were added. The humanities program has added concentration/distribution requirements. The writing program was added.

      Your system will have to be flexible enough to handle more changes like these: it would be foolish to assume that, after thirty-five years of often sweeping change, we have found the Right Way and will never make substantial changes again.

   3. Finally, it is interesting to note that Marty Schlecht, head of the FAST team and a faculty member, sees advisor- or class-specific add and drop dates as a selling point for the faculty on the new system! Again, remember that the registrar has only one view.

Top // 6.033 home // Probably last updated 4/27/96