Community Source Student Services System – Birds of Feather Session Notes
June 5, 2006
Participants
- Richard Spencer, UBC (note taker)
- Bob Allen, Alameda County Office of Education
- Adam Rybicki, Unicon
- Rose Thorsen, Informs
- Mike Underwood, Informs
- Paul Zablosky, UBC
- Janet Backe, Simon Fraser University
- Jack Gunter, consultant
- Jens Haeusser, UBC
- Mike Lim, UBC
- Kent Fong, UBC
- Mike Lim, UBC
- Dave Alderson, University of Maryland
- James Watkin, UCLA business school
- Steve Jeyes, doing contract work at University of Hull
- Leo Fernig, UBC
- Charles Severance, Exec director, Sakai Foundation
Opening comments
Richard Spencer gave a brief summary of the points he and Leo Fernig made in the presentation they gave earlier in the day.
How did you solve the problem of keeping a developer community?
Response:
New technology is attractive to staff. Experience at UBC has shown that working near the leading edge in a particular technology (Java in the mid '90s, SOA today) will make it easier to attract good staff. Although they may move on after a year or two, they make very valuable contributions.
The technology being considered is new. For example, Axis 2.0 has just been released.
If you don't have expertise in architecture, where is it going to come from?
Response:
The infrastructure is largely going to involve using off the shelf applications and products
How will the architecture get developed?
Response:
The business architecture is more important than the technical architecture. Functional staff or business analysts will have to understand service oriented business analysis, and apply this to student services business processes.
One short term goal of the SSS project is a reference open source technical architecture.
Where do you see the need for work on the SSS project?
e.g.:
mapping process flows?
developing connectors to enable SSS modules to connect with existing applications?
Response:
A large top down effort will be required initially, to establish the main SSS modules and produce the high level service analyses. Next, we will have to build services.
For the SSS project, we plan on using Java, but this is not a requirement, and modules can be developed using other languages.
Finally, we have to use orchestration to assemble business processes that span modules, or systems.
Response:
Many services exist already as applications. These can be given a web services wrapper, and made available for use in an SSS as either services or modules.
Response:
A good SOA analysis should make it easier to develop applications and services.
Response:
The SSS team is not approaching this as a greenfield exercise. We expect to use many existing modules.
Will there be performance issues?
Discussion:
It was pointed out that the proposed architecture, using web services and XML documents, will generate lots of transactions. There will need to be an ability to monitor where constrictions and bottlenecks are occurring.
Some open source BEPL engines, such as Active Endpoints don't scale.
Response:
There will need to be ways of monitoring process flow, and carefully managing how it is distributed.
Response:
With a current, monolithic SIS, registration is buried inside the system. As a result, you have to scale the entire SIS to get registration to scale. At UBC this would have to be done across 5 servers
Response:
The goal is to be able to build a process based on a business analysis, and assemble a system from available components. The use of rules engines and work flow will help.
How do you get the functional people to put in the time to analyze their processes?
Response:
We can use the fact that this is a new approach to encourage more people to participate.
How many schools have done BPR?
Observation:
Experience from IT in the newspaper publishing business was that applications used by all companies were pretty much the same. This limited the competitive pressure to introduce new applications, and controlled the pace of change. Newspapers didn't have the staff to implement new processes, even when these would produce obvious savings. The result was that there was much less innovation than advances in IT would have allowed.
Response:
ERP implementations tend to consume all available resources, and there is often nothing left for re-engineering processes. In addition, a "successful" ERP implementation is usually one in which processes are changed to conform to the way those processes are implemented in the ERP. However, we do have the resources to do re-engineering, if we choose to deploy them for that purpose.
Response:
The SSS project will be a success if some institutions participate, and take advantage of the flexibility inherent in service oriented design to implement new processes. Although it would be great if every institution did this, that is not likely, nor is it needed for the project to be successful.
Who should be involved?
Response:
Don't limit it to higher ed. If the SSS has the general, extensible design that has been discussed, it should work for other levels of education, such as high schools.
Observation:
Developers find it hard to write to general purpose code, but they can do it with the right management and auditing of code.
Observation:
We want this to be for education at all levels, and we want to reuse existing standards wherever possible.
XML schema vs RDF
Comment
XML schema requires too many pair-wise connections.
Any data model will change over time. The Sakai data model can evolve over time. This allows the addition of data elements without going back to all users and renegotiating. Sakai is looking at RDF, using RSS, which would allow new information to be added without breaking old applications.