Downside of the small pieces model

“Now afficionados of small pieces will argue that services are improving all the time and such things are a temporary hitch but what happens when you’ve recommended a service to a student who needs it for an assignment and the service is down for maintenance?”

😉

Hmmm – now, [rubs chin once or twice], shall I start posting to my public blog the messages I see from time to time from OUr students, who can’t get in to one OU system or another because it’s down? (Does the Library catalogue still go down in the early hours of the morning for its regular backup, I wonder? I guess it does…)

Now I’m not saying I’ve got one or two stories from Friday outages that won’t be fixed till the Monday after when the ONE person who knows how to fix whatever is back in work; and the story I was told on Friday about a production matter that couldn’t be acted on till the ONE person who could make the required change was back in work was probably just hearsay…

…but one thing I’d hazard a guess at is that I could mail the Slideshare developers and maybe get something back from them… but if I was an OU student, would the same be true re: getting in touch with an OU developer?

tony

And of course a “small pieces model” doesn’t absolve you from having contingency plans. In fact it’s got the potential to deal with disasters rather better. Slideshare goes down? No problem: here are some alternative sites that can similarly communicate with the other online services you’re using… X, Y, Z

It’s got to be Slideshare rather than anything else for some specific course reason? No problem: here’s the temporary mirror… because when we decided to specify Slideshare and only Slideshare for that specific course reason, we negotiated with Slideshare that we could host such a temporary mirror for when disaster happens. Sure this costs us money, but then we’re not bearing the huge ongoing costs that we would have done for developing and maintaining an in-house presentation-sharing system.

Sure, such workarounds are far from perfect, but as we all know from bitter experience, even mission-critical systems such as institutional email can go down for several weeks, despite every kind of backup and failsafe imaginable and despite all hands to battle stations trying to fix things.

With a VLE, there’s a reassurance in disaster planning that everything will be ok in the event of a major failure because (a) a commercial supplier has a huge motivation to minimise the likelihood of such failures; (b) a commercial supplier has a huge motivation to get you back on the rails asap; (c) if there’s not much competition in the VLE marketplace (e.g. there’s a dominant free open source solution), there’ll be lots of people in the same boat and therefore more people to help.

The price you pay for this reassurance is a development cycle that has a tendency to be sluggish, play-safe, expensive, and monolithic.

However, an advantage of the “small pieces model” is that if you’ve truly got the capability to swap one piece for another at all times, then a failure of a single piece is less likely to result in a failure of the whole student experience.