A lot has gone on lately about the “Personal API.” Getting information on it gets to be a bit meta, with one link leading to another article to a blog post then all the way back around to the first reference but start off with a great post from Jim Groom that in turn links to an article by Tim Klapdor that really captures the key ideas, then check out some talk on the Indie Ed Tech discussion from
A massive oversimplification of an idea as expansive as a personal API is that it’s a way for the user to control how his or her own data is being used and accessed. An API in the software world is a defined interface for accessing data from a system like Twitter or Facebook. A personal API, therefore, is about controlling how personal data is accessed. It puts the power back into the hands of the individual, rather than the system. This discussion is taking place in higher ed, so the practical example would be a student deciding when personal data such as a phone number is available, rather than the institution controlling that information through access into, say, the Student Information System (this is the example Kelly Flanagan, the CIO at BYU, provides).
This is an amazing idea, and one worth pursuing regardless of your type of institution. It’s worth rethinking how you approach everything from digital learning in general to the LMS specifically. But it also has a flip-side challenge that is non-trivial.
Earlier this week, I was in a demo from an SIS vendor where we talked about ways to access data in the system. Not surprisingly, they discourage direct SQL database access, so the options were to either use reports (e.g. – giant Excel file, which requires more work to use) or build hooks into their APIs. The latter is preferred since it would inherently include getting the data into the right format for whatever the intended use, plus it would be more secure. The vendor was touting how they have well-documented and extensive APIs so that we can do what we wish in terms of software development.
APIs – whether for a Student Information System or a person – are great and indeed quite powerful. It’s like an extended hand in a way, but one that carries with it all the information about how high up the hand is from the floor, how far away it is from the body, whether it’s the right or left hand, etc. Taking this metaphor a bit further, the key is that the person extending the hand – the student in the personal API example – gets to decide all of those variables. The angle of the hand, the distance extended, etc. What data is included or excluded, and exactly how a secure exchange should take place.
However, having an API isn’t a complete solution. The problem with an API is that it’s only half of a two-part process. The hand is extended, but someone does indeed have to walk up, take hold, and offer that firm handshake. It’s great to offer access to data, and it’s even better to give control over that process to the individual, but it still takes two to tango.
Now, BYU and some schools involved in projects related to digital identity (see Domain of One’s Own – another Jim Groom brainchild – for a good starting point on this topic) are already or will soon be investing time and resources into the other half of this relationship. And this is undeniably something that every institution should explore as we find ways to empower students and create the Next Generation Digital Learning Environment, but there is part of me – the cynical half? – that keeps wondering about the resources needed. Looking with blinders on only at our department at Muhlenberg, I don’t see us being able to engage in a meaningful way for some time. We’ll take advantage of tools that others build, sure (and of course there is nothing wrong with that IMO). But as far as us being the other end of the handshake, building our own tools? I don’t know. Can we disaggregate the LMS on our own? Not likely in the near future.
Absolutely worth it, without a doubt, to work to find a way to get involved. But it will take work to get to a meaningful outcome with the personal API.