Niall Sclater raises some issues around potential dangers of outsourcing your IT services, picking up on my recent decision to go all things Google. Niall is referring to a talk by Alan Bell and the two particular potential problems he raises are:
1. You tell your students to use a system hosted externally, maybe
one which downloads client software to the learners’ machine. A
student’s system gets corrupted and they claim that your institution is
2. You use a free externally hosted collaboration system for audio
conferencing for a tutorial and a student tells you during the session
that they can’t complete an assignment due to a bereavement. You take
no note of this and it slips your mind. Because there is no accessible
record of the session you’re again opening up your institution to a
I would say the first of these – not really an issue, since most of what we’re talking about are web based services anyway. The second might be an issue, and is part of the broader issue of having less direct control. A similar problem might be that a student claims a particular system was down, or the student says they haven’t read a message, etc. All of these are verifiable when you have integrated systems with monitoring. I would say that I think monitoring as an excuse to use internal systems is overplayed, since no-one actually uses it much, and you have other tools available, e.g. Google analytics, but let’s ignore that for now, and think about how this might be addressed.
The first way would be to decide on core services that you really need to host internally. Assignment handling might be one. I suspect the danger with this approach is that some people would soon argue that everything is a core service.
The second approach is to use reliable third party services who you have some level of partnership, or at least discussion with. So you can at least ask them if their system was down. The danger with this approach is that it would soon be pulled in to the institutional bureaucracy and before you know they would be demanding that Slideshare (or whoever) sign a service level agreement.
The third approach is to spread risk. By having a range of activities and systems, then failure in any one is mitigated as students can do something else. This is a definite advantage over the centralised system as when that goes down, everything is lost.
The fourth factor is to have a light integration touch between institutional systems and third party apps, that can at least offer a degree of monitoring. I’m not sure if institutionally hosted authorisation services would do the trick, but this kind of thing.
And the last approach is probably the most interesting and not related to technology at all. And that is to engage with, and trust, your students more and create more activity based courses. A lot of these ‘issues’ are only issues when you need to be directing students to do very specific tasks. If one adopts a more research, activity based pedagogy then some (not all) of these issues become legitimate problems for the student to work around.