[Building Sakai] Migrating Sakai 2 to Sakai 3

[Clay Fenlason]

I don't think I share quite the same impression of migration suffering
(nor, I've found, does my faculty and student advisory committee) at
the prospect of a UX backed by two Sakai frameworks, but I gather
we're in a minority.  Still, I think this position merits some further
elucidation, if not some defense.  It is not unusual for Sakai to make
inroads in the form of project sites before it achieves buy-in as an
LMS.  We plan to echo this pattern in a shift from Sakai 2 to "Sakai
3" (more below about why I put this in quotes) as well - the
next-generation product is first experienced as a new site type, the
sort created for ad hoc purposes, while the course sites continue to
look and behave like Sakai 2.  This seems to us at GT a far more
graceful transition - allowing our users to move more at their own
pace, familiarizing themselves with the new interaction design by
opting in where they care to, increasingly so as further functionality
is rolled into place - than a sharp cutover of the entire system and
an abrupt spike in the training burden and technical risk for full
data migration, etc.  This actually looks to me like a kind of gradual
upgrade strategy that never would have been possible with a
proprietary product, and I once again am thankful for how Sakai
provides more options.

Before going any further, I'd be remiss in not pointing out that there
is, in fact, nothing settled on the question of what "Sakai 3" will
be.  There is no such animal as yet, strictly speaking.  There are two
very suggestive projects - one for the back-end (K2) and one for the
front-end (which Nathan has designed, and I'll call '3akai') - which
are in a state we might call "R&D" if we agree to the sort of process
Michael has recently surfaced, and which, when joined together, might
represent in embryonic form what "Sakai 3" will be.  Cambridge and
Georgia Tech seem perversely determined to risk putting this
experimental pairing into production before these questions have been
decided, but that also signals a certain momentum that it would be
disingenuous to shrug aside.  Not trying to be coy.  Just sayin'.
"Sakai 3" is a good placeholder indicating some future,
next-generation product.  There is good progress being made in areas
that we hope will eventually lead to a general Sakai 3 release, but
much remains to be worked out, and no one's in a position to be making
any release claims just yet.

As to "tools," the notion itself is somewhat suspect, and for the most
part will need to be taken on a case-by-case basis.  No one has yet
wrestled with all these cases.  We can hold out hope for a general
mechanism for tool and component porting (e.g. a K1-K2 compatibility
layer, which some seem prepared to chase down, and that would be a
pivotal development) but apart from that unrealized prospect some of
the considerations throughout will be:

a)  Is the tool simply obviated in its capabilities by the basic
interaction design of page authoring and assembly?  The legacy
"Syllabus" would be one obvious sort.  There may be less obvious sorts
that could have their goals satisfied by page templates.

b)  Is the tool really better understood as a general capability
(perhaps collapsing several "tools" onto a shared service) which can
support a variety of widgets better tailored to particular use cases?
Assignments, I'm looking at you ... of course imho.

c)  How does the functionality in question treat its core data, and if
it's not as "content," should it be reimagined (and then
re-developed)?  And I believe the answer to the latter will be "yes"
more often than one might think.  I'd posit that what we currently
think of as the Gradebook is perhaps a surprising yet pedagogically
deep case of precisely this sort of thing.

d)  Is the tool however so complex and critical that we need to work
out a way to run it in legacy form until we get it sorted out in all
its next-generation glory?  Again, a preferred strategy would be a
general compatibility layer for all tools, but if that doesn't get
worked out we may need to look at targeted ports for especially tough
cases (e.g. Gradebook or Tests & Quizzes).  Or maybe the tool
basically runs its own stack anyway (evaluation?) and can continue on
in that fashion.

... and so forth.  I don't mean to be alarming, but then neither would
I want to underestimate the challenge.  There will be options and
mitigating strategies (running two frameworks in parallel along with
the rest), but a great deal of thought is going to be called for in a
large number of cases.

I think there is a particularly strong need for the K2 project, if it
hopes to become the platform for Sakai 3 development, to document how
tool and component developers can work against it.  And we won't start
to have satisfactory answers to the sorts of questions you're asking,
Sean, until those laboring to achieve a *working* K2 in the next
several weeks can start to turn more attention to polishing off a
*usable* K2 for tool and component developers.

~Clay

On Wed, Mar 25, 2009 at 6:45 PM, Sean Keesler <sean at keesler.org> wrote:
> I was reading the Sakai3 proposal and came across this under the plans for
> 2010:
>
> A “hybrid” mode will be available. It will allow Sakai 2 and Sakai 3 to run
> side by side and appear as single system to users. Configuration settings
> will allow you to
> determine which capabilities are drawn from Sakai 2 and which are drawn from
> Sakai 3.
>
> That isn't very far in the future.
> I imagine that there will be a reasonable group of new schools that will
> decide to wait until Sakai 3 before they begin a Sakai implementation so
> that that they don't need to run two systems or suffer the migration.
> Has there been any discussion about which Sakai 2 tools will be "migratable"
> to Sakai 3? Are there features that can be built into Sakai 2 tools now to
> ensure that their data can be migrated to 3?
>
>
> -- Sean
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"
>



-- 
Clay Fenlason
Director, Educational Technology
Georgia Institute of Technology
(404) 385-6644