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?"
- 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.
- 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
- 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
- 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
- "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]
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
discuss meeting for some more information about submitting
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!
- 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
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.
- State law (might actually be national law) mandates that a request
for a transcript be physically signed by the student.
- 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.)
- 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.)
- 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?
- 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!)
- 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.
- 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."
- 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
- 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
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.
- 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.
6.033 home //
Probably last updated 4/27/96