It's important to realize that the Sakai community designs and builds more than one thing which are assembled and deployed in various ways. To date, Sakai is a bundle of tools, services, interface gadgets, stylesheets, resources, and adaptor elements. As more universities deploy Sakai (in pilot or in production), it is becoming more clear that one size doesn't fit all.
Tools
To most Sakai users, tools are the only thing that matter. Sakai tools provide functionality to students, instructors, administrators, and others via the web. Ideally, these tools should follow some kind of guidelines to make them compatible and uniform (this was the original idea behind the Tool Portability Profile). In pratice, this is very spotty. We have some tools that work well together (announcements, sectioning, chat, email notification, etc.). We have others that are partially integrated (Samigo, Gradebook, others). There are some that are special purpose (SuperUser) and some that just standalone (rWiki).
It would be useful, in the future, to be able to categorize and group tools. We should be able to describe how well integrated they are in the Sakai environment. This approach doesn't mandate that tool developers follow specifications or conventions, though there are advantages to that. Sakai should be a platform that supports all kinds of tools ranging from the very simple to the very complex, from completely standalone to highly integrated.
Sakai already has tools that are tightly integrated. Separating them is difficult, since there are interlocking dependencies. The legacy CHEF tools fall into this category. There is nothing wrong with this, in fact, there are many excellent reasons why some tools should be tightly integrated. Perhaps what is needed is a way to describe "tool suites" that are collections of tools that are designed to work together. For system configuration purposes, a tool suite should be added or removed as a block.
Sakai Tools are largely distributed as a block at this time. Other tools, like Melete, Message Center, Post'em, etc. can be added after Sakai installation. As the number of tools offered for the Sakai environment grow, this approach is going to break down. Even now, there are problably as many tools not distributed with Sakai as those included in the Enterprise Bundle. This will continue to grow to the point where there is a very large offering of Sakai tools outside of the standard distribution.
Two things will help. First, we need to simplify the installation of tools. Not that the existing approach is wrong or bad, but we need to be able to easily turn on and off available tools at run time. We need to be able to hot-deploy tools without restarting Tomcat. Second, we should consider other Sakai distribution bundles. If Sakai were modular in nature (it could certainly be better than it is now), it would be a simple matter to collect different sets of tools together and distribute them. We could envision a Sakai very focused on pedagogy or even specific disciplines such as Medicine. There could be an eResearch bundle, a project management bundled, etc.
Ideally, we should investigate being able specify what tools and services should be included in a new bundle and be able to automatically assemble the bundle (ready for installation) automatically. If the tools and services are well tested in isolation and specification of the bundle is done correctly, there shouldn't be a need for additional QA beyond testing the install process.
Services
To the casual observer, the Sakai platform is a mess. Legacy services are mixed with legacy tools. There is more than one architecture, services that duplicate functionality, etc. Looking deeper, things are not all that bad. The state of the platform (as of 2.1) is a system in transition. From the very early days of the project, we decided to take an evolutionary approach rather than designing a platform from scratch to meet well defined requirements.
Well, evolution is messy and we have to accept that. Perhaps what is lacking is a long term vision for the Sakai service architecture. This vision should consist of high level requirements and goals, including:
- Modular - services should be isolated from each other as much as possible.
- Layered - dependencies should be downward, not horizontal or up the stack.
- Consistent - naming conventions, access practices (covers?), API conventions, etc.
- Flexible - configurable via system parameters.
- Integratable - providers, adaptors, synchronization mechanisms, enterprise service APIs (OSIDs).
- Standards Based - data conventions, inport and export mechanisms, APIs where defined.
Many of the services in Sakai already meet some or all of these requirements while others are headed in that direction.
Dependencies are a problem for services, if we want to be able to add and remove them as needed. The Sakai legacy services are riddled with interlocking dependencies that make it difficult or impossible to split them up. In many (most?) cases, these dependencies add considerable functionality to the overall system, however they also increase the complexity and reduce modularity and the ability to extract elements of Sakai to meet specific purposes. We need to carefully examine these dependencies and weight the worth of them. Were such dependencies are valuable, service suites (similar to the tool suites mentioned above) could be defined and collected into a single Sakai module. Services that can and should be separable should be in their own modules.
Documentation is also a problem. Sakai has neither internal nor external documentation that describes key platform services. While the use of services can be deduced from object and method names, and use in existing tools, this puts a considerable burden on the part of the developer and is likely to lead to misassumptions, mistakes, and bugs. As in many projects like this one, documentation is a second thought, if at all.
User Interface Support
Portal
Gadgets
Stylesheets
Resources
Database definitions
Language Translations
Graphics
Integration Elements
Providers
Adaptors
OSIDs