Ian Boston, CARET’s technical director shares his take-home points from the Kuali Days conference, held last week in San Antonio.
We went to Kuali Days to strengthen ties between Kuali Student and the Curriculum Design project at Cambridge as well as strengthen ties between Sakai 3 and Kuali. Although the conference ran over Tuesday 17th and Wednesday 18th we were present from Sunday 15th. On Monday we had a constructive meeting with Leo Fernig (UBC, lead technical architect) and Scott Thorne (MIT, service architect) to discuss how the curriculum design project would work in Kuali Student.
Curriculum Design
It became apparent as we went into the detail that the headline datamodel of KS did not match the details. The main issue for Cambridge is that a learning unit (LU) is associated with many organizations. In Kuali, at the headline model level, an LU is associated with a single organization. Once the detail was unpacked it became apparent that an LU is associated with many organizations, each association annotated with metadata. In the case of Cambridge we have many stakeholder organizations associated with each LU, each organization with a different concern. There is a single coordinating organization for the LU which is equivalent to the headline organization-LU relationship visible from outside the project. The task now is to analyze the Cambridge LU model and map it into KS to determine the gaps.
Kuali Student like many of the Kuali projects has been driven by a analysis stage performed by 30 or more Business Analysts at the participating institutions. The output of their work can be found on the KS wiki (you will need to register for a login) where there are descriptions of the entire entity model and service descriptions. The use of that wiki in itself is interesting since each page contains markup from which much of the service framework and entity model is generated at build time. Although there is an entity model and service definition in KS much of this is abstract, concreted by a data dictionary that defines each type of entity within the model. This similar to most of the other Kuali products which require local implementation effort to adjust the data dictionary to describe the local environment. For instance there is an abstract definition of a LU, which may represent a course in North America or a Part of a Tripos at Cambridge. Changing the system to represent both of these concepts is a matter of changing some data within database to represent the Cambridge model. KS comes with a standard configuration known as “Kuali Reference University” which is close to most North American models. We will have to modify sections of that “University” to form a localized model.
In addition to the datamodel within Kuali there is a workflow engine, Kuali Enterprise Workflow (KEW) [part of the Kuali Rice middleware] and a rules engine, Drools. Both of these use the data dictionary to bind actions and rules to entities within the data model, consequently modifications to the data dictionary will require changes in the workflow and rules definitions. KEW is shared by other Kuali applications.
In conclusion it is felt that there is no reason why the Cambridge teaching model cannot be represented in KS, however we need to validate that assumption by attempting mapping.
Kuali Student UX
Many Kuali projects use Kuali Rice to create their UI. This is a highly data driven Forms creation environment that results in the rapid implementation of forms based systems which are closer to an administrative client server application than a web environment. Kuali Student is unique within Kuali by not adopting this approach to user interface. It has taken a more design focused approach that is apparent from the resulting user experience, although it is not nearly as UX driven as Sakai3. KS uses Google Web Toolkit (GWT) to deliver its UI. It is more interactive and responsive than the web 1.5 applications that typify the rest of Kuali, but the use of GWT and the development process restrains the UX process. They have a UX designer, Will Washington at University of Washington who is working within the constraints of the Java development team using GWT to deliver a UX. He is developing navigational components and detail components that are implemented in GWT to provide a UI constructed from those components. Kuali Student is intended for a wider user base than other Kuali products, which are focused squarely on serving central administrators, and this UX approach is light years ahead of those products in terms of usability. It does not come close to the freedom and flexibility available within the Sakai 3 UX process, but this can be seen as a reflection of different project priorities.
Sakai 3 and Kuali
The model of Sakai 3, with its reduction in code base by extensive use of components adopted from 3rd-party open source projects, was held up as a model for Kuali which like Sakai 2 had adopted the “not invented here” approach to third party libraries. Oddly the result of this approach is a mish-mash of dependencies in the centrally provided systems that does not always result a smaller or efficient footprint. For instance, the Kuali Coeus release is a 200MB download with about 30 – 40 jars all packaged into a single webapp. Much of that code base including components like Kuali Enterprise Workflow, Kuali Service Bus (KSB) and Kuali Nervous System (KNS) is maintained within the Kuali Foundation. The Sakai 3 model where the KSB would be represented by Apache Service Mix, and KNS by Apache ActiveMQ was of interest.
Sakai 3 and Kuali Student
There are obvious areas for integration between KS and S3. KS provides management of the structure of courses and a repository to store that structure and S3 provides an interface for the teaching and learning community to interact with that model. We had discussions surrounding how closer cooperation might work, including the concept of LU’s being derived from the authoring process of a course template within S3, and that the structure of LU’s being taken through an approval workflow within KS might result in a published course structure from which S3 would be able to generate course instances. Clearly this is very early stages but there are positive indications of both sides.
Kuali Coeus
Kuali Student addresses the administration of teaching, one half of a university’s core activity. Kuali Coeus is intended to address the other half – research.
I sat in on a number of Kuali Coeus sessions to gather information. Kuali Coeus was until recently called Kuali Research Administration. Coeus is a MIT driven project that addresses the needs of Research Administration. Coeus has been going for 15 years and has a community of adopters within North America. Kuali is attempting to achieve convergence between KRA and Coeus in the form of Kuali Coeus.
The history of KRA is checkered. The initial roadmap staked delivery dates for various feature sets, all of which have been missed, however there is new hope converging with Coeus as it represents of body of knowledge in the area. The Coeus product is a Java GUI bound to a Oracle back end, although there is a light version with a web based interface. KC will follow the standard Kuali Rice model, an abstract data model represented as Oracle Tables, a data dictionary to concrete that model and a forms based UI backed up with Kuali Enterprise Workflow. Although this produces a user interface that is unusable outside administrative circles, the implementation cost is low allowing resources to be allocated to analysis phases.
Unfortunately KC has many integration points and features that bind it closely to Research Administration and Grant management in North America (eg Government Forms). It is likely that any other region would have to expend significant effort in re-defining the Workflow, data dictionary, perhaps data model and certainly integration code to make it suitable for another region. It is debatable and unknown if the cost of that re-definition would be more expensive that doing the work from scratch.