Imagine you wanted to create a virtual university (VU)¹. VU admits students and allows them to take courses in programs that lead to certificates, degrees, and other credentials. But VU doesn't have any faculty or even any courses of its own. VU's programs are constructed from courses at other universities. VU's students take courses at whichever university offers it. In an extreme version of this model, VU doesn't even credential students. Rather, those come from participating institutions who have agreed, on a program-by-program basis, to accept certain transfer credits from other participating universities to fulfill program requirements.

Tom Goodwin writes

Uber, the world’s largest taxi company, owns no vehicles. Facebook, the world’s most popular media owner, creates no content. Alibaba, the most valuable retailer, has no inventory. And Airbnb, the world’s largest accommodation provider, owns no real estate.

These companies are thin layers sitting on an abundance of supply. They connect customers to that supply. VU follows a similar pattern. VU has no faculty, no campus, no buildings, no sports teams. VU doesn't have any classes of its own. Moreover, as we'll see, VU doesn't even have much student data. VU provides a thin layer of software that connects students anywhere in the world with a vast supply of courses and degree programs available.

There are a lot of questions about how VU would work, but what I'd like to focus on in this post is how we could construct (or, as we'll see later, deconstruct) IT systems that support this model.

Traditional University IT System

Before we consider how VU can operate, let's look at a simple block model of how traditional university IT systems work.

Universities operate three primary IT systems in support of their core business: a learning management system (LMS), a student information system (SIS), and a course management system.²

The LMS is used to host courses and is the primary place that students use course material, take quizzes, and submit assignments. Faculty build courses in the LMS and use it to evaluate student work and assign grades.

The SIS is the system of record for the university and tracks most of the important data about students. The SIS handles student admissions, registrations, and transcripts. The SIS is also the system that a university uses to ensure compliance with various university and government policies, rules, and regulations. The SIS works hand-in-hand with the course management system that the university uses to manage its offerings.

The SIS tells the LMS who's signed up for a particular course. The LMS tells the SIS what grades each student got. The course management system tells the SIS and LMS what courses are being offered.

Students usually interact with the LMS and SIS through Web pages and dedicated mobile apps.

VU presents some challenges to the traditional university IT model. Since these university IT systems are monoliths, you might be able to do some back-end integrations between VU's systems and the SIS and LMS of each participating university. The student would have to then use VU's systems and those of each participating universities.

The Personal API and Learning Records

I've written before about BYU's efforts to build a university API. A university API exposes resources that are directly related to the business of the university such as /students, /instructors, /classes, /enrollments, and so on. Using a standard, consistent API developers can interact with any relevant university system in a way that protects university and student data and ensures that university processes are followed.

We've also been exploring how a personal API functions in a university setting. For purposes or this discussion, let's imagine a personal API that provides an interface to two primary repositories of personal data: the student profile and the learning record store (LRS). The profile is straightforward and contains personal information that the student needs to share with the university in order to be admitted, register for and take courses, and complete program requirements.

The LRS stores the stream of all learning activities by the student. These learning activities include things like being admitted to a program, registering for a class, completing a reading assignment, taking a quiz, attending class, getting a B+ in a class, or completing a program of study. In short there is no learning activity that is too small or too large to be recorded in the LRS. The LRS stores a detailed transcript of learning events.³

One significant contrast between the traditional SIS/LMS that students have used and the LRS is this: the SIS/LMS is primarily a record of the current status of the student that records only course-grained achievements whereas the LRS represents the stream of learning activities, large and small. The distinction is significant. My last book was called The Live Web because it explored the differences between systems that make dynamic queries against static data (the traditional SIS/LMS) and those that perform static queries on dynamic streams of data. The LRS is decidedly part of the live web.

The personal API, as it's name suggests, may provide an interface to any data that the person who owns, but right now, we're primarily interested in the profile and LRS data. For purposes of this discussion, we'll refer to the combination profile and LRS as the "student profile."

We can construct the student profile such that it can be hosted. By hosted, I mean that the student profile is built in a way that each profile could, potentially, be run on different machines in different administrative domains, without loss of functionality. One group of students might be running their profiles inside their university's Domain of One's Own system, another group might be using student profiles hosted by their school, other students might be using a commercial product, and some, intrepid students might choose to self-host. Regardless, the API provides the same functionality independent of the domain in which the student profile operates.

Even when the profile is self hosted, the information can still be trusted because institutions can digitally sign accomplishments so others can be assured they're legitimate.

Deconstructing the SIS

With the personal-API-enabled student profile, we're in a position to deconstruct the University IT systems we discussed above. As shown in the following diagram, the student profile can be separated from the university system. They interact via their APIs. Students interact with both of them through their respective APIs using applications and Web sites.

The university API and the student profile portions of the personal API are interoperable. Each is built so that it knows about and can use the other. For example, the university API knows how to connect to a student profile API, can understand the schema within, respects the student profile's permissioning structures, and sends accomplishments to the LRS along with other important updates.

For its part, the student profile API knows how to find classes, see what classes the student is registered for, receive university notifications, check grades, connect with classmates, and sends important events to the university API.

VU can use both the university systems and the student profile. Students can access all three via their APIs using whatever applications are appropriate.

The VU must manage programs made from courses that other universities teach and keep track of who is enrolled in what (the traditional student records function). But VU can rely on the university's LMS, major functions of its SIS, and information in the student profile to get its job done. For example, if VU trusted that the student profile would be consistently available, it would need to know who its students are, but could evaluate student progress using transcript records written by the university to the student profile.

Building the Virtual University

With this final picture in mind, it's easy to see how multiple universities and different student profile systems could work together as part of VU's overall offerings.

With these systems in place, VU can build programs from courses taught at many universities, relying on them to do much of the work in teaching students and certifying student work. Here is what VU must do:

• VU still has the traditional college responsibility of determining what programs to offer, selecting courses that make up those programs, and offering those to its students.
• VU must run a student admissions process to determine who to admit to which programs.
• VU has the additional task of coordinating with the various universities that are part of the consortium to ensure they will accept each others courses as pre-requisites and, if necessary, as equivalent transfer credits.
• VU must evaluate student completion of programs and either issue certifications (degrees, certificates of completion, etc.) itself or through one of its member institutions.

Universities aren't responsible for anything more than they already do. Their IT systems are architected differently to have an API and to interact with the student profile, but otherwise they are very similar in functionality to what is in place now. Accomplishments at each participating institution can be recorded in the student profile.

VU students apply to and are admitted by VU. They register for classes with VU. They look to VU for program guidance. When they take a class, they use the LMS at the university hosting the course. The LMS posts calendar and notifications to their student profile. The student profile becomes the primary system the student uses to interact with both VU and the various university LMSs. They have little to no interaction with the SIS of the respective universities.

One of the advantages of the hosted model for student repositories is that they don't have to be centrally located or administered. As a result student data can be located in different political domains in accordance with data privacy laws.

Note that the student profile is more than a passive repository of data that has limited functionality. The student profile is an active participant in the student's experience, managing notifications and other communications, scheduling calendar items, and even managing student course registration and progress evaluation. The student profile becomes a personal learning environment working on the student's behalf in conjunction with the various learning systems the student uses.

Since the best place to integrate student data is in the student profile, it ought to exist long before college. Then students could use their profile to create their application. There's no reason high school activities and results from standardized testing shouldn't be in the LRS. Student-centric learning requires student-centric information management.

We can imagine that this personal learning environment would be useful outside the context of VU and provide the basis for the student's learning even after she graduates. By extending it to allow programs of learning to be created by the student or others, independent of VU, the student profile becomes a tool that students can use over a lifetime.

The design presented here follows the simple maxim that the student is the best place to integrate information about the student. By deconstructing the traditional centralized university systems, we can create a system that supports a much more flexible model of education. APIs provide the means of modularizing university IT systems and creating a student-centric system that sits at the heart of a new university experience.

Related Reading:

• Building a Personal API
• Personal APIs in a University Setting
• Personal Learning Systems and Life-Long Learning
• A University API

---

1. Don't construe this post to be "anti-university." In fact, I'm very pro-university and believe that there is great power in the traditional university model. Students get more when they are face-to-face with other learners in a physical space. But that is not always feasible and once students leave the university, their learning is usually much less structured. The tools developed in this post empower students to be life-long learners by making them more responsible for managing their own learning environment.
2. Universities, like all large organizations, also use things like financial systems, HR systems, and customer management systems, along with a host of other smaller and support IT systems. But I'm going to ignore those in this post since they're really boring and not usually specialized from those used by other businesses.
3. The xAPI is the proposed way that LRSs interact with each other and other learning systems. xAPI is an event-based protocol that communicates triples that have a subject, verb, and object. Using xAPI, systems can communicate information such as "Phillip completed reading assignment 10." In my more loose interpretation, an LRS might also store information from Activity Streams or other ways that event-like information can be conveyed.