How my work might change: my skill set

(How my work might change if Notre Dame chose Sakai as its next LMS)

As alluded to by Kim Thanos in a comment on this series original posting, if Notre Dame were to choose Sakai over Blackboard Learn or any other LMS, the skill sets I bring to my workplace would have to change.

Currently my day looks like this: 30% ad hoc requests from the crosslist-related access to how can I do this or that variety; 20% application maintenance, that is, certifying one of our 3 environments after an infrastructure change (patches, updates, networking, virtual farm resource allocations, firewall/load balancer); 20% communication and FAQ writing; 30% reading/answering listserves and email.

I’m an IT generalist at the moment. At one time I had a higher skillset in networking/operating systems. Then I became more adept at application troubleshooting in Weblogic and a log crawler. Then I became a browser troubleshooter and an HTML manipulator. And an educational technology consultant, I can’t forget that.

The good news is that I see the skill sets needed to bring Sakai to campus (from where we are now) to be so diverse, that I would hopefully get to choose which part I wanted, train rigously (did I mention I’m a lifetime learner? Good thing too!)  and then make a recommendation for how big the transition team should be, their skill sets, and just how many bodies are we talking about. After the transition, I expect we would be able to scale back some.

First pass at skill set list for Transition Team (partially based on ND tech standards and on our school size and on our adoption rate so far):

  1. Experienced application engineer, good with Linux. Apache, Tomcat, and java experience preferred. Disaster recovery. High availability. Virtual non-production environments at least. Lots of testing iterations once 3 environments are established. 1 FTE. Forever.
  2. Java developer. 25% FTE. I think the developer consults with the app engineer on different build / install decision points.
  3. Platform agnostic developer. 1.5 FTE. Or not. This person is going to have a list of Notre Dame interfaces to test/rewrite/convert. These will include Banner Self-Service Forms to create ad hoc crosslists, and to copy content from last semester’s class (or any class really) to this semester’s class section or sections; a Orientation to Notre Dame’s honor code which feeds back to Banner whether students have completed it and sets a role accordingingly; Graded Voice Tools (Wimba); Secure Electronic Exams (Respondus LockDown Assessment; iTunesU interface; Library eReserves interface; real-time event synchronization between Sakai and Banner (maybe get a SunGard consultant on this?).
  4. Learning Management Thought Leader. 1 FTE. This skill set is something like planner, architect of new service roll out, liasion to Academic committees. This role is increasingly crucial everywhere regardless of ones LMS. ND currently has no cradle-to-grave service policies, no content repositories or ePortfolios alumns can take with them, no federated ID management (working on it!), no repeatable method for inter-institutional collaborations… Also ND currently has no decentralized end user support structure except in a couple of EXCEPTIONAL colleges, while central IT has only an Academic Technologies R&D group and a Center for Teaching and Learning which must lead the charge in all the ways a School of Education would if our institution had one. I do alot of this kind of work already so I would have to decide whether this is my full time destiny or whether I would like to become #1 full time instead. Also, I have NO IDEA how to ‘rank up’ in these skills while continuing to ‘hold down the fort.’ Ideas?
  5. End User Documentation/Support materials. 1 FTE on the transition team but potentially could be scaled back. I understand this could be a serious giveback to the Sakai community because they don’t do this well at the moment.
  6. DBA. Typically we implement in Oracle and we pull from a pool of DBAs. We might be able to get 1/2 FTE for a short burst and then drop down to a 1/4 time DBA.

8 thoughts on “How my work might change: my skill set

  1. Do you really think 1/4 of a developer is enough? I would think several full time positons is more realistic just to maintain your environment.

  2. “Maintain” our environment. You’ve pointed out potentially where the current paradigm could shift. I do need to look at this more closely. Currently maintaining our LMS has to do with responding to defects. And it doesn’t have anything to do with giveback to a community or taking ownership of our own tool enhancements. Maybe a quarter FTE could to this. Some kind of Notre Dame LMS governance body would prioritize their work on bugs identified by students and faculty at Notre Dame. They’d work at a steady ‘trickle’. Doesn’t sound like much of a teamplayer with the Sakai community. Doesn’t sound responsive to immediate needs on campus (although our user community isn’t accustomed to being able to have a rapid turnaround on defects or feature requests).

  3. This statement causes me the biggest headache and probably is the most common reason why Sakai gets screwed by people sticking with Blackboard: “I would think several full time positons is more realistic just to maintain your environment.”

  4. Since posting this, I’ve come across the advanced edit feature on the site which let me search on PROD as a project type, when in fact it is deployment data by institutions using Sakai. Among other things they often list are staffing levels. These staffing levels are all over the map – what they do confirm for me is that the staffing levels I indicated above are not unreasonable. It seems to depend on how the institution is using Sakai. Check it out. Use this string (“project = PROD AND status = Open ORDER BY priority DESC”) as your advanced filter and then check the “general” tab under each school’s deployment.

  5. It’s great to see you thinking out loud through this series, and engaging the community to think with you.

    I think there are some assumptions you’ve made about the transition from Blackboard to Sakai that would be worthwhile to make explicit. One assumption that stands out to me is the assumption that as part of the transition from Blackboard to Sakai, Notre Dame will also go through a bit of a cultural transition from consuming an off-the-shelf product, to more of a DIY / building software culture. While this is a new possibility if Notre Dame chooses to go down the Sakai path, it’s not the only way to traverse that path.

    In other words, with Sakai you have to choose “how” as well as “whether to.” And sometimes these choices are inter-related. I blogged about these choices recently.

    Good luck. I look forward to following your thinking as you consider the possibilities.

    1. Welcome Chris! Thanks for commenting. Yes, I admit I am hypothesizing a cultural transition at Notre Dame that could result as a conscious choice in conjunction with a change to open source software, but I am not doing so because I believe it to be necessary or automatically tied to that choice. In other words, I do agree with you that moving to Sakai would not necessitate the change. The reason I’m hypothesizing a change in culture is because it would make strategic sense. Recently the University of Notre Dame articulated our strategic direction in this fashion, “to become a premier Catholic research institution.” So while it isn’t strictly necessary, as you say, to undergo a cultural or policy transition to manage an electronic collaborative learning environment that is open sourced, you’ve called me out, I have been putting the two together.

  6. Have you considered that these staff might be useful regardless of your ultimate choice of technologies? Princeton and Northwestern (both Blackboard customers) have done very powerful things using the Blackboard Building Blocks Framework. I’m not sure why the choice of technology determines if you have a Learning Management Thought Leader.

    In fact it is my view that the costs of development and maintenance are much lower for Blackboard than other platforms. The reason for this is we have an API that has been maintained and developed over 10 years. With only slight modifications Building Blocks going back as far as Blackboard 5.5 can be run against 9.1. Software Engineering studies have shown that as much as 90% of the costs of software development is in the maintenance of changes vs. the initial development. By reducing the number of changes required as the core software stack changes; we can create more resources for innovation.

Comments are closed.