What would a student information system designed around open XML formats rather than proprietary and arcane database tables look like? Consider, for example, using xCal (an XML format for iCalendar data) to store course schedules, so every student could get a personalized feed to subscribe to in Google Calendar or iCal or the PIM tool of their choice, with their schedule of classes automatically kept up-to-date. Similarly, contact information for professors and students can be stored using an XML representation of vCard, making it trivial for students and professors to add each other to their address books. Students could automatically get a vCard file every semester with their professors' contact information. More than simple conveniences like these, though, there is real transformational power in the use of open formats. Regional university consortia could offer students a "union catalog" of sorts, like libraries have offered for many years. For libraries, the enabling technologies were the MARC bibliographic data standard, and the Z39.50 protocol for exchanging MARC data. An open standard for student information systems could do the same thing. There are EDI transaction sets for exchanging transcript data, but from what I've seen they are not universally used. What's more, transcript data is only a tiny part of the problem.

There is also the related, but substantial issue of data ownership—even though a university unquestionably owns the data in its PeopleSoft or Banner installation, how much can it do with that data without PeopleSoft or Banner installed? These proprietary formats are inextricably linked to the systems that generated them, ensuring that universities are forever tied to those systems. Migration is a difficult and expensive proposition, a waste of money that could otherwise go to teaching and research. There is also the thorny issue of universities with home-grown student information systems, a common practice particularly at large, old institutions. Back in the day when universities had "computer centers", it was commonplace to develop these kinds of applications in-house. Many universities have moved on from their custom solutions, though, and in doing so they have lost fundamental control over their data—it is now stored in proprietary formats of the vendor's choosing, rather than formats of their own design. Providing an open data format would make it possible for universities to migrate data stored in their existing custom student information system to an open format that they control—and when the time comes to upgrade, they can choose any vendor's product, so long as it supports this open format.

I suspect that one of the major stumbling blocks will be that modern student information systems are in fact no longer standalone products; they have been integrated into gigantic enterprise resource planning systems like PeopleSoft. A system that deals solely with students and course catalogs and course registration will appear to be lacking a huge swath of features. Most of these, though, will be things that, at first glance, seem to have little to do with actually teaching courses: human resources, accounting, regulatory compliance, etc. The trend in modern ERP systems is to tightly couple all of these areas together in what essentially becomes a single package—and, in the case of an educational institution, bolt on a student information system. Even those systems not designed for general-purpose ERP (like SCT Banner) still grow to fulfill traditional ERP roles. A university which fully adopts Banner would end up using it not only as a student information system but also for financial management, human resources (not just for professors and academic staff, but all staff), financial aid, fundraising, and more.

For open formats to succeed, the prevailing design philosophy must shift towards the use of discrete modules which exchange information using open formats. Invariably the modules will need to communicate with each other; an accounting system must know how many credits a student is taking, and the rate per credit, before it can generate a bill (until we finally wise up and make education free). This should be simple to accomplish, though, as long as everything uses well-documented formats for data interchange. This is perhaps best described as a return to the Unix philosophy, the notion of writing software to do just one thing, but do it well.

Moreover, there are already many ancillary systems which are almost always external to a student information system, but which depend on its data: e-learning systems like Moodle and Blackboard, integrated library systems like Aleph (and quite a few more), and access control systems (to restrict access to a lab to students enrolled in particular courses, for example). All of these require data feeds from the SIS, and as such most require customization for every SIS out there. An open, neutral interchange format would negate the need to do this customization for every platform. Software vendors developing products designed to integrate with student information systems would be designed to ingest data in just one format, rather than needing customization for all of the various student information systems out there. Even seemingly simple things, like generating course catalogs for print and for the web can be made easier, with the use of XSLT and XSL-FO; (shockingly) at many institutions course catalogs are still prepared by hand, although the printed course catalog is rapidly dying.

In short, I would close with this: putting data into an XML-based format leads to gains in transparency and simplicity in infrastructure—and these are both key values which many student information systems (and ERP packages in general) are lacking.