bavatuesdays

Having just blogged about the overall experience of the University API conference I spent the last two days at, and I wanted to get down some of the more focused discussions and thoughts around how the University API might intersect with some of the work we’ve been doing around Domain of One’s Own. First and foremost, what is a University API? Well Phil Windley breaks it down brilliantly in this post on the topic, and this is the pull quote for me.

We’re…designing and implementing a University API. The idea is simple: identify the fundamental resources that make up the business of the university and design a single, consistent API around them. A facade layer will sit between the University API and the underlying systems to do the translation and deal with format, identifier, and other issues.

BYU’s Doug Walker provided an excellent overview of how they’re designing their University API template in terms of URL structures and JSON. I came in and out of the conversation based on my limited understanding (though it’s getting better), but the discussion followed the concepts discussed in this tutorial—a work in progress.

This was an important session because it connected with the conversation I had with BYU’s  Troy Martin about the idea of a Personal API after the session I convened around Domain of One’s Own on Wednesday. We got to discussing how domains can be understood within the context of the University API—and this is where things started getting kind of interesting because BYU is running a Domain of One’s Own pilot starting this fall. As Troy said, what if one’s personal domain becomes the space where students can make their own calls to the University API? What if they have a personal API that enables them to decide what they share, with whom, and for how long. For example, what if you had a Portfolio site with a robust API (which was the use case we were discussing) that was installed on student’s personal domain at portfolio.mydomain.com, and enabled them to do a few basic things via API:

• It called the University API and populated the students classes for that semester.
• It enabled them to pull in their assignments from a variety of sources (and even version them).
• it also let them “submit” those assignment to the campus LMS.
• This would effectively be enabling the instructor to access and provide feedback that the student would now have as metadata on that assignment in their portfolio.
• It can also track course events, discussions, etc.

The Personal API, through a very focused use-case of the personal portfolio, provides the means for students to have greater control over their data. A de-coupled application running on their own server yet seamlessly connecting to the University’s various services. A scenario wherein students can manage their learning in relationship to a broader University API. And the portfolio is just one use case, you can imagine a blog, resume, financial aid, transcripts, university applications and forms, etc.

The idea of controlling one’s personal data as well as providing a platform for literacy became the prevailing “why” of a personal API during the conversations, and that was very cool. The how is to start small with a simple portfolio program that connects to some of BYU’s  APIs to see how it works. Doug Walker noted it might be a bit hairy because the idea of personal API in some ways resists any set structure imposed on a student’s domain. I agree with that, and I think that’s why you wrap some of that structure and basic framework for the API in a single application, like a portfolio, before trying to map out some kind of Personal API spec that every student must adhere to.

In some ways I am blurring two sessions we had on Thursday around the Personal API. The first was a broad discussion of what it means, it was focused around questions of how we control the permissions of our data, rather than hand that power over to others. There’s  a pretty free range set of notes from the session, but I think this was the groundwork for the session in the afternoon when a handful of us sat down and tried to imagine the basics of this portfolio.  We pulled Tim Owens into that discussion, and I think we have a rough idea of what a very small piece of a Personal API might look like.

What’s more, Kelly, Phil, Troy, hopefully Kin, and any other interested party are going to form a loose working group to hammer on this before the next University API conference in January 2016. I’m really looking forward to this idea. Not only does it deal with questions of student empowerment when it comes to their data, but it could also mean a whole knew way of allowing us, and anyone else with access to the data via the API, to imagine new ways of aggregating, visualizing, and mashing up the data.

The University API & Domains (UAD) workshop covers topics on developing API’s, implementing DevOps practices, deploying Domain of One’s Own projects, improving the use of digital identity technologies, and framing digital fluency on University campuses, This workshop is focused on addressing current issues and best practices experienced in building out conceptual models and example real-life use cases. Attendees include IT architects, educational technologists, faculty, and software engineers from many universities. – From Phil Windley’s post about the event.

I spent the last two days in Salt Lake City at the University API inaugural conference. This conference is so fresh it doesn’t even have a website yet, but it does have a Twitter account. I had an awesome experience, and spent some serious time locking in and thinking about APIs, which is something I’ve been trying to do for a while. I’ll share some thoughts about this (un)conference in this post before I explore some of the ideas that surfaced and my thoughts about how APIs intersect with the work we’ve been doing with Domain of One’s Own in my next. Capiche?

Agenda wall from the 1st day of the #univAPI unconference. This is going to be good. pic.twitter.com/IUyQBcduMP

— Paul D. Eden (@pauldeden) June 3, 2015

The conference was relaxed, intimate, and intense all at once–is that possible? There were only 40 people, but we had 33 sessions over two days. We got to know each other fairly well, and spent a lot of time thinking and talking about APIs, but in a low-key environment. Major props to Heidi Nobantu Saul for framing and facilitating the unconference approach beautifully. It reminded me of the 2007 Northern Voice Moose Camp, just with fewer people. A lot of serendipitous discussions, in-betweeness, and conversational sessions. I also have to give major props to Kelly Flanagan, BYU’s CIO, for creating a truly convivial and comfortable atmosphere. He’s a remarkable person, bringing a sense of humor to everything he does. But don’t let that lull you, he’s spearheading what might be the single most important development in Higher Ed IT: BYU’s thinking through and building of a University API for their campus, and beyond.

This conference was BYU’s first attempt to articulate and share the vision undergirding the heads down work they’ve been doing over the last year to architect this conceptual shift. No small undertaking for what is a very large Higher Ed IT organization. For all the talk about “disruption” and “innovation” at EDUCAUSE and their IT organizational ilk, you’re always gonna find the most compelling work on the fringes. If you’re looking, I would train your eye on the work BYU is doing around the University API—it’s amazing on many levels. How do I know they’re serious about APIs and doing this the right way? Well, look who they brought to keynote….

No, not me! The API Evangelist, Kin Lane, a Mather amongst evangelists (Increase to my Cotton?). He brought the fire and brimstone Wednesday morning, inspiring hearts and blowing minds. He is legend. I could listen to him talk for days on end. SO. MUCH. KNOWLEDGE. He opened up with an overview of APIs, and why they’re the building blocks for re-imagining the ways we can collectively build the web, not to mention their implications for sharing, managing, and reclaiming one’s personal data. He then spent the rest of the morning running sessions about the future of APIs, giving an overview of Swagger, and generally being a force of good. I feel better knowing he’s out there. What’s more, he set a tone that talking about APIs is not only technical, it’s social, political, economic, educational, etc.

The fact that Kelly and Phil Windley brought Kin in to frame this event speaks volumes about their approach. They have been working with Kin for a while now to help them work through the shift to making BYU’s data more accessible, malleable, and easily shared across campus via the University API. What could be more important for an IT organization? The University API conference is a space to interrogate how we create, share, and manipulate data across an institution, which means its relevant for just about anyone on campus. The problem is most people can’t get beyond the acronym API, and I totally understand that obstacle. I would love it if in the next iteration we ran an API 101 track that helped folks both understand and wrap their heads around how APIs effect the whole university.

I also have to take moment to mention how much I admire and respect the thinking Phil Windley is doing more generally in the space of technology as a domain (his session on Blockchain and decentralized identity management was truly amazing), but specifically in thinking through the complex architecture of what this means for BYU both technically and culturally. I’ll write more about Phil, Kelly, and several other amazing BYU folks in my next post on the Personal API, but for now let me stop here and simply say I’m truly thrilled that a high-profile institution like BYU is leading the conversation around APIs in higher ed in a thoughtful, engaged, and open way. I’m fired up for the next University API (un)conference that will be happening, tentatively, in January of 2016. I guess we’ll know more once they get a website—Mormon hippies! 🙂