Thoughts about modularity

The Engineering and Physics departments provide us with a unique set up in which to design a modular system. Engineering has a working module to manage teaching duty allocations (Teaching Office DataBase). This module is being rolled out to the Judge Business School these days. There are some differences between the version rolled out to JBS and the original system, but crucially only one minor change at database level. This allows us to think of the Engineering module as the nucleus of a larger system, and of the JBS roll-out as the most basic extension to this module. Further deployments into other departments in the univeristy will test the suitability of this module and the degree to which its robust, simple design is sufficient to meet their needs. The challenge here is organise the code and the database schema so as to allow other modules to be added to it while maintaining it design. We might add tables to the database but will aim not to change existing ones.

The Physics department's Teaching Information System is larger and more complex, and will be redesigned as a whole. The first module to be written there will be the second deliverable of the eAdmin project, managing student registrations for courses and examinations. The challenge in this case is to incorporate the Engineering TODB within this new system as is, while developing the second module around it. This will serve as a more serious test for the modularity of the emerging system.

If we can demonstrate that the new system lends itself to the above two types of modular extension we will have achieved a lot. Proper documentation will then pave the way for future extensions of the same modular nature.