1. Mapping Sakai Relevance

2. Publisher’s Note (1 or 2) These slides were prepared by Clay Fenlason, Boston University School of Management for the Sakai Strategy and Advocacy Discussion Group. “This discussion group is focused on providing support to those people interested in promoting Sakai on their campus.” He writes: “The first [four slides] tries to break the stakeholders down into 4 groups - students, faculty, university and school administrators, and the IT outfit itself - and it does so by trying to identify their key concerns and interests, both for the short and long term. The short-term concerns basically become migration issues, and the long-term interests become the major selling points. Of course there's more overlap than the table indicates, and I don't mean it to establish rigid categories so much as to identify emphases.Since my earliest focus is on my fellow IT people, most of the remaining slides go on to further subdivide that camp (using local terminology). "Infrastructure" is the province of system administrators, "App- Dev" that of developers, and "User Services" the purview of helpdesk support, trainers, etc. "App-Dev" is of course the toughest nut to crack, partly because this is where the implications of Sakai are most strongly felt, and partly because in recent years we've become something of a.NET shop. On the Sys Admin side we've also tilted toward the Windows side of the spectrum.”

3. Publisher’s Note (2 of 2) “The last slide indicates a point I keep trying to make to mollify fears - there are lots of different possible strategies for implementing Sakai. It doesn't necessarily mean throwing all your resources into it at the outset, in fact there are permissible "lazy" ways of Sakai implementation, as much as I'm convinced that might be squandered opportunity. One such path would be to project that the CLE [Collaborative Learning Environment] needs of the local institution are always going to roughly be a subset of the CLE needs of the actively-developing Sakai partners, and the local effort can go entirely into customizations or relatively minor tweaks to existing tools.” As quoted in the September 1, 2004 issue of the SEPP Update.

4. Sakai Relevance by Audience AudienceImmediate Concerns (Pain)Future Interest (Gain) Students (CMS + Portal) Integration with SIS Usability and performance Standards for Faculty usage SSO, unified functionality Better communication and group tools Faculty (CLE) Usability and performance Content migration Student satisfaction Training (and re-training?) Better class/group management tools Content management Research and collaboration Deans (Portal) ROI Prestige and Marketing/Branding Independence Faculty and student satisfaction Administrative applications (e.g. financial management, curriculum planning) Portal functionality for “school community” ITS (IT Strategy) Migration Staff resources/skillsets Stable product, long-term viability User satisfaction TCO App-dev effectiveness – productivity, leveraging external resources. – flexibility and modularity Application integration Control and independence Responsiveness to needs

5. Advantage Summary Infrastructure Integration of services allows a more unified back-end Flexibility (i.e. avoiding “lock-in”) User Services Unified environment for users – SSO, fewer account issues – reduced training and user confusion Greater responsiveness to needs (innovation through “theft”) Improved online help App-Dev Leveraging the work of others Deliverables more modular and smaller in scope (supported by Sakai services) Application flexibility/sustainability – change in service does not require change in tools

6. Questions and Concerns Infrastructure Unfamiliar OS: Linux or Solaris (or why not?) More hardware (and what kind?) More thorough support and maintenance Additional test and development environment New skills User Services Migration planning Selling to Deans and Faculty Documentation and Training New tasks – gathering feedback and requirements for new functionality – staying abreast of SEPP development App-Dev CMS would involve development (Blackboard doesn’t, right now) Collaboration with other schools can be inefficient Management site with portal? Context of future projects Unfamiliar technologies and new skills

7. Skills Infrastructure Tomcat Solaris/Linux – Clustering – Samba – Sendmail vs. Exchange User Services The Software Itself App-Dev Java-related: – Beans, Servlets, JSF, Eclipse, Maven XML and XSLT WSRP and JSR-168 (portals and portlets) Hibernate (object persistence) Spring (bean container) IMS standards (course content) OKI OSIDs (service API)

8. Implementation Approaches Commercially SupportedCommunity Supported Little or No In- house Development “Blackboard-like” + tool updating (SEPP) “Blackboard-like” + tool updating (SEPP) + Increased Infrastructure role Significant In-house Development “Blackboard-like” + tool updating (SEPP) + App-Dev projects “Blackboard-like” + tool updating (SEPP) + Increased Infrastructure role + App-Dev projects