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.

Alternatives

• Use only one site

The main benefit is that data access is simple (see the Data Storage and Access section), but there are two problems:

a) The site admin has to keep all the user groups (i.e. faculty, chair, and IAC for each department, associate dean for each college, members of each university committee and so on) up to date. It's lots of work for one person, and it also creates additional work for department staff because they now have to report any department-level committee membership change to the university.

b) This does not make creating the workflow any easier (see Q3 in the Workflow section).

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?

??

Alternatives

• Each subsite has its own course proposal library.

There are some obvious problems if we do this. For example, we cannot simply move a document around because a) once a document is moved out of a subsite library, the users of the subsite can no longer see the document status, and b) during the "collecting feedback" stage, multiple copies of the document need to be created to send to all the colleges, and once we have multiple copies of the document, we have to deal with problems like keeping status consistent on all copies and consolidating comments from multiple copies.

Workflow

Ideally we want to have a big workflow at the parent site that handles everything. 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.

It's kind of difficult to formulate this into a "googlable" question but I'll give it a try:

Q3. Is it possible to create a workflow that determines the users (or user groups) at each stage based on some columns of  the document (or item)?

??

Alternatives

• Each department subsite has two workflows, one for submitting their own proposals, and one for reviewing proposals of other departments.

Considering that we have 6 colleges, 40+ departments, and a number of university-level committees, we'll be dealing with over 100 workflows just for course proposal review. It's going to be a maintenance nightmare, and it'll be difficult to implement other university processes if for each process we have to add 100+ workflows. And on top of that we have to figure out how to chain multiple workflows together.

• Create a workflow for each department at the parent site.

It still a pain to have to create and maintain 40+ workflows, but it's not too terrible and it can kind of serve as a fallback plan if "one big workflow" is not possible. If we do this, the question is

Q4. Can a workflow refer to user groups defined in its subsites?

??