Building APIs for the University and the Student
Brigham Young University is standardizing the way it exposes data and business processes to app developers — and taking the API concept to the student level.
A few years ago, three innovative Brigham Young University (UT) students decided to develop an improved version of the university registration system interface. They "screen-scraped" the official registration pages and created their own site. Some students used it to create their schedules, but they still had to enter their course selections into the official registration system.
"It showed that students wanted to build tools on top of the university system to make students' lives better, but we were forcing them to screen-scrape and not allowing them to actually interface with the university system," said Phil Windley, enterprise architect in BYU's Office of the CIO. He has helped develop the concept of a university-wide application programming interface (API) to standardize how BYU exposes its data and business processes to app developers — and make it easier to connect to campus systems.
"Part of the founding myth of the university API is that we want to create a situation where those three students would have been able to create their registration front end, have it work, and not be this kluge, but a real application they could let people use," Windley said. "Because, heaven knows, we have plenty to do. If students want to build registration systems better than the ones we have, we are happy to let them do it."
Creating a Standard University API
Windley has worked at BYU a few times, leaving to pursue other opportunities and later coming back to the university. He said that when he returned in 2014, he remembered thinking, "the good news is that BYU has 950 services in a registry; the bad news is it has 950 services in a registry."
What he meant by that was that while web services were a good thing, BYU's services had a wide variety of interaction methods. They might have five different identifiers that developers would have to coordinate. All had different return and error code formats. "The inconsistency was such that if you wanted to write a mobile app that dealt with a student, it was possible you would have to deal with 25 different APIs using five different identifiers, and multiple data formats," he said. "That kind of situation puts a developer off. They have a good idea, they see that the data is there, but they realize they are going to have to do all this work to incorporate that data and make use of it."
That was the launching point for the university API: the need to create a single interface that was consistent in how it operated and that spoke the language of the university.
IT staffers began by asking themselves what the core functionality of the university is and who their customers are, explained Kelly Flanagan, CIO and vice president of information technology. "We decided we would start simple and expand as we go." They started with five basic core resources: students, instructors, locations, courses and classes. (A course might be "Computer Science 101," while a class would be the individual sections or meetings of that course within each semester.) With those five resources, he said, the API exposes the core functionality that the university represents. "We admit students on the front end, get them into the right majors, have them take courses, make progress and graduate on the back end."
Flanagan believes that when you start down this path, the obvious thing to think is that your API exposes data, but he said that is misleading and a bit naïve. "It is exposing business resources, which could be data, but also could be processes, policies, etc.," he said. "We insist that all business processes associated with something like registration — who is allowed to register and how — all sits underneath the API. Then third-party developers can't violate the business practices of the unit because their business practices are embedded into the processes exposed through the API."
Another benefit envisioned with this approach is that BYU would be able to swap out underlying applications without disrupting the rest of the university: "This is an important idea," Windley said. "Think of the API as an interface language. It reduces friction both above and below. It will make it easier for us to redo a part of the financial system or student information system. As long as we keep the interface the same, the applications above it will just keep working."
Flanagan explained that if all the systems exposed to the campus community come through the API, as long as it stays consistent, none of them would care what happens underneath the covers. "We can feel free to switch out the back ends," he said. "We can put into place a new back end, and tell the API to send all transactions to both back ends, get a response, and compare for testing purposes, and only send responses back to the user from the in-place solution. We can continue doing that until we work out the bugs in the new version and then switch over the load 10 percent, 20 percent and then pretty soon we are done."
Creating a university API is not a one-time project that you finish off in a year and declare victory. It is an ongoing process. After about three years of work, BYU has completed version 1 of its university API, which describes in total the resources that should be in it. "As we change things out, whether it is the systems underneath or something that gets built on top of it, we want it to use the API," Windley said. For example, BYU's student mobile app is undergoing a revision to incorporate a course add/drop feature. The CIO's Office supplied extra funding to build out the university API pieces that support it.
The university is also getting ready to launch a developer portal, which is an important step to getting not only university developers but also third-party developers to use the API.
Developing a Personal API
In addition to the university API, BYU is working on some groundbreaking ideas involving students' personal APIs. First, it has adopted the Domain of One's Own concept originated at the University of Mary Washington (VA), which creates a personal web domain for each student. "We are at about 5,000 domains in our system, both student and faculty," Windley said. "We were interested in giving students a place where they could keep their own work and potentially take it with them when they leave the university."
The personal API could be what the university uses as the authoritative source for something as basic as a student's current address and contact information. But there are many other possibilities. Windley spoke about the concept of a learning record store, which is basically a database of learning transactions.
For instance, there is an API called the Experience API that can record all kinds of activities tied to learning: "Mike completed quiz 3 and got an A" or "Mary completed CS 462." This could all get saved in the learning record store. "What if the student owned the learning record store, and it was not a campus system we kept?" Windley asked. Not all learning happens in the classroom or in structured situations. "We could put the learning record store in the Domain of One's Own. That is something we are exploring."
Could that learning record store include transcript information that the student couldn't alter? "That is the next step," Windley said. "We are contemplating how to create a learning record store that the student owns, but that contains information that is verifiable as having come from BYU and is unchangeable by the student. That got us into the idea of verifiable claims." He mentioned there is a WC3 task force working on verifiable claims, as well as an effort under way at MIT called Blockcerts to create an open standard for digital academic certificates based on the blockchain concept used by Bitcoin. Windley is involved with an organization called the Sovrin Foundation, which also is working on a distributed ledger-based identity system.
"The next evolution of the internet will be the creation of a common identity layer that allows people and organizations to have their own self-sovereign identity — a digital identity they own and control, and which cannot be taken away from them," Windley said. "Self-sovereign identity is the natural evolution of an ecosystem that has moved faster than its supporting capabilities. There are quite a few people interested in this idea. Of course, there are Open Badges available from Mozilla. This idea of badges or certifications to record things people have done is interesting to us in its entirety."
In developing a personal API concept, Flanagan is looking beyond BYU's Provo campus. He also is CIO for all of the educational institutions belonging to the Church of Jesus Christ of Latter-day Saints (BYU campuses in Idaho, Hawaii, and the LDS Business College). The church would like to use those campus's programs to offer educational opportunities to its 15 million members wherever they happen to live in 188 different countries.
"In contemplating an architecture for that, we realized that the decentralized learning record store with verifiable claims was an interesting way to think about how you would integrate all these various systems," Windley said. "A student could get an English language certification from one institution and use it as a prerequisite for a bookkeeping program at another institution without having to make all those point-to-point integrations or creating a central hub."
Flanagan said BYU President Kevin Worthen is a big believer in a Domain of One's Own and personal APIs primarily because he agrees with Flanagan that their institution ought to be educating students not only on facts, figures and ideas, but also about data privacy and ownership and their sovereign identities. "We want our students to leave here as contributors to the internet, not just consumers," Flanagan said. "The more we help our students understand that they should own their own data and blog and write about things they believe in, I think that is a great thing for their future."
Although BYU is a pioneer in university API development, other universities are working on the concept, too. BYU has hosted several university API workshops in which a dozen universities have participated, including UC Berkeley, UC San Diego and Northwestern. The campuses are approaching it from different angles, Windley said. "Some are more grassroots and bottom-up. BYU was in a situation where we have a strong CIO and we were able to go more top-down. We have been collaborating with a number of universities in trying to understand how to push this all forward."