Is distributed software the answer to making our university faster?

So, in all of the deluge of learning I've done this semester, I have formally come across the concept of distributed computing. I've been looking at it for a couple of years now, but I finally have the resources to make efficient use of it. Interestingly, I see it as a way to make our university faster, more efficient, and overall, more organized.

The housing situation, for example, could have been remedied by a nice set up of constantly synchronously communicating software programs in different areas of the university. Software at Residence Life could have maintained a count of how many housing spots were available and software in the cashier's office could have kept a count of how many housing deposits have been paid. The two software programs could have formed a synchronous system that eventually kept everyone abreast of the housing situation. Students could have tapped into this information resource simply by keeping a small ticker on their desktop that is updated when the rest of the information in the system is updated.

This continuous flow of constantly updating information can be enabled quickly by creating distributed software. The architecture for the system would be simple to draw up, as would the protocols and the various pieces of software that would make the system work. The biggest concerns, I foresee, are network reliability issues and security.

If there is a network failure somewhere in the system, such as someone's computer in Slowe Hall becomes a zombie and crowds the network with spam, how would that affect the system that manages the housing information? Secondly, what keeps someone from editing the information that the system has stored thus far?

This way of managing information via distributed systems is highly feasible. How is it distributed, though? My understanding of distributed computing is different computers providing services to clients on a network. In this particular case, different kinds of information are kept on two separate systems in quite possibly, two different buildings on campus. However, when the system is stripped down to the primary user, the student, the information from the other two disparate systems is aggregated into one place, the ticker sitting on the student's desktop, which can be updated as long as that student is anywhere on campus.

How does this solve the ticket problem though?

The ticket problem was an interesting problem simply because it was an information problem. Those who held tickets were pretty sure they were entitled to pay their housing deposit. The fundamental issue behind this, however, was that how were people supposed to know exactly how many tickets had been given out? Even though administration emphasized that they were only letting 1,550 people register for housing, how were people really supposed to know that the ticket they received while skipping English really entitled them to anything? In all reality, what kept people from making their own tickets, complete with the "official stamping on the back"?

To make a long story short, paying the housing deposit should have been something that was subordinated to BisonWeb. The problem with that, however, is being sure that the network would have been able to fight off the inevitable congestion. We all saw how someone was reportedly trampled outside the A-building in an attempt to get a ticket. It was a riot. Literally. Could our network sustain that type of traffic? That has yet to be seen...

But, the engineering of minute services such as a housing tracker, etc. could be done with a bit of planning and the cooperation of the University. I'll see what I can do.