Thoughts on System Design

Site Structure

We will use a parent site (the University Site) and a number of subsites, one for each organizational unit that a course proposal needs to travel through, e.g. a department, a college, a university office or committee. The main reason to choose this structure over a single-site structure is to distribute the administrative workload. For example, the CS department site admin will be responsible for keeping track of who is a CS faculty, who is the CS department chair, and who is in CS IAC.

The subsites can all be on the same level, or we could have two levels where the college subsites are parents to the department subsites. There seems to be no difference in terms of site administration and operation, so we will choose the one that is easier to implement, and right now that appears to be the one-level structure.

Data Storage and Access

All the data, which include all the course proposals, the lists of colleges and departments and so on, will be stored in the parent site. We avoid lots of problems by not copying or moving the course proposals around, and there seems to be no drawbacks whatsoever about keeping the data centralized.

The two questions we need to answer are:

Q1. Can the subsites "read" the data in the parent site?

The answer appears to be yes, using something called Content Query Web Page.

Q2. Can the subsites "write" date to the parent site, which may include creating new course proposal requests, uploading documents, adding comments, completing tasks and so on?

??

Workflow

Ideally we want to have a big workflow at the parent site that handles everything. The alternative would be having a number of department-level workflows. Considering that we have 6 colleges, 40+ departments, and a number of university-level committees, and most of them need at least two workflows (one for submitting their own proposals, and one for giving feedback to proposals from other department/college), we'll be dealing with over 100 workflows just for course proposal review. It's going to be a maintenance nightmare, and we won't be able to use the same model for other university processes.

The main difficulty seems to be that the users involved in the different stages of this workflow can not be fixed. For example, for a workflow at a specific department (like CS) we may have:

CS Faculty -> CS Department Chair -> CS IAC -> ECST Associate Dean ...

However, because the "big workflow" needs to deal with different departments, after a course proposal is created, it needs to determine the users (or user groups) involved in each stage based on the document's origin. In other words, the workflow needs to look like:

Faculty -> if(dept=='CS') CS Department Chair else if (dept == 'EE')  EE Department Chair ... -> ....

The logic is not particular complex (and we don't have to code it as a huge if-elseif-else statement), but it's not clear whether such logic can be implemented in a workflow.