Flipping the Model: The Campus API

Note: While I generally prefer to keep work and life separate to the extent possible, this is one of those occasions where my professional experience, personal interests, and graduate student coursework happen to intersect. This post reflects neither the thoughts nor opinions of my employer.

Though I found out about it too late to attend, I was excited to learn about the recent University API workshop hosted by BYU. It’s the first time I’ve heard of such an event having a distinct focus specifically on APIs and universities. Thank you to those institutions who are providing some initial momentum here. One of my previous jobs was as a developer who helped educators and software engineers to use APIs to integrate with LMSs, and over the past two years I’ve been fortunate to work for UMUC where I do very much the same on a much more local and meaningful level. Over this time, the team I work on has replaced the university’s home-grown LMS with a commercial one, and in doing so rebuilt and rewired integrations with many new and existing back-and-front-end systems.

Needless to say, open standards have played a critical role in achieving this vision. But while they help in many ways, they aren’t best-suited for every application that we want to build, and a standards-compliant LMS alone does not an online student experience make. To address these needs, one of my team’s more recent projects has been to develop a REST API that could be used by anyone at the university to build apps. It slurps in data from a whole array of back-end systems – including those that don’t currently and don’t ever plan to support open standards. For example, these APIs can retrieve user profile data from the identity management system, enrollment data from the SIS, and even the balance due from the financial system. By unifying all of these systems behind the facade of an easy-to-use API, other teams around the university (ie: not just “central IT”) have been experimenting with rapid prototypes of apps and portals that will soon modernize a number of random legacy applications and begin to facilitate the creation of new ones.

Previously, getting at this data required clunky point integrations with the SIS, LMS financial, authentication, identity management, and other administrative systems. These integrations often require designing for complexity and specialized skill sets to use each vendor’s API. They are also brittle and prone to breaking with each upgrade, increasing risk and the level of ongoing QA effort required.

current_state
Legacy architecture. Point to point integrations mean increased QA efforts whenever any one system is modified or upgraded.

By inserting an API into the architecture, we can now provide logged-in users all of these details using simple calls that abstract away the behind-the-scenes complexity. It is enabling us to find ways not only to build new applications but also swap out legacy back-end systems behind the scenes without changing the nature of how these APIs are used on the front-end.

future_state
API-based architecture. Systems can be built on top of stable APIs and upgraded/replaced independent of each other with reduced QA effort.

There are many universities including Berkeley, University of Michigan, and University of Washington that have been experimenting with API efforts recently. Perhaps the most interesting ones I’ve come across are the efforts undertaken by BYU and University of Waterloo.  Their designs offer (what I think at this time are) the most complete assemblage of useful data aggregated across all of the systems a university would typically use.

Which brings me to my next thought.

What would happen if a university flipped the model of integrating its systems and instead of writing individual connectors to each vendor’s system, the university itself provided a standardized API for each of its vendors to use? This changes the dynamic of the relationship significantly. No longer does a vendor need to ask which SIS or LMS a particular institution uses. Rather, it only needs to know which version of the “campus API” or “university API” it implements. It also means that you don’t need to wait for a specific product to implement a specific version of a specific standard to move forward with an integration. You just write your implementation to the interface using whatever capability a given product offers and in doing so provide a facade that avoids this factor altogether.

Suddenly, universities can become much more flexible in how they can swap in/out, upgrade, and rearrange all of their systems behind the scenes. The overhead of implementing and QAing product integrations decreases by shifting the development responsibility for the integration to each vendor. Vendors benefit from a uniform way to connect to any university that implements the API.  Universities become better positioned to supply and control access to application data. Students receive an easier way to access their own data. The API itself then becomes a platform for innovation rather than any specific vendor’s product. Imagine different vendors offering competing course catalogs that adapt to a student’s major, academic progress, and personal interests – or the ability for students to slurp data feeds into any mobile app, not just the one offered by the university. Or imagine an enterprising capstone project team building the cafeteria menu app that your students always wanted but never received high enough priority to build – or even the ability for a student (or adult professional) to register for a specific class using a “Take My Class” button on a professor’s personal blog rather than logging in and searching through the cumbersome UI of most SISs. (Also imagine a university with a business model where you don’t need to become a full-blown student just to audit one class.) This is exciting stuff.

There are many resources to help universities understand APIs better. First, the EDUCAUSE ITANA Constituent Group hosts a subgroup focused solely on APIs and API governance. Kin Lane has written a helpful white paper that describes some of the above university API efforts (and their benefits) in greater detail. (Seriously, consult with him if you consider going down this path.) Finally,  the notes from BYU’s recent API workshop are hosted here.

There are also a pair of organizations who appear best-poised to tackle this challenge specifically in a higher-education-focused context.  Lingk is a very new startup that is focused on building a SaaS-style product with the ability to interoperate with a number of systems typically used on college campuses and expose their data in different, more-modern ways. Apidapter is a more-established startup that centralizes LTI launch requests within a single management framework so that usage details and error messages can be logged and trended. Apidapter also allows standards-based transactions to be transformed “mid-flight,” sometimes to augment the capability of the standard and other times to pull in additional data from other systems, such as an LDAP server, and adding these as LTI launch parameters before reaching the target system. (Disclosure, UMUC uses Apidapter under-the-covers for some of its LTI-based integrations. This is not a product recommendation. But seriously, it is cool, and you should go check it out.)

In my opinion, administrative systems are one of the greatest limiters of IT agility at colleges and universities specifically because of their complexity and inflexibility, whether real or perceived. Universities will face continued pressures to adapt more quickly to constant change, and an API could provide a stable, unified approach to better support innovation and accommodate IT change more easily so that we can collectively free ourselves from legacy IT challenges. Let’s get to it.

This post written by George Kroner

 

LMS Data – Spring 2015 Updates

For this spring’s update (though, can we really call it spring yet?), the Edutechnica team has increased our data set to include all US higher education institutions with more than 700 students, improved our ability to detect pilot and co-production LMSs, and improved our ability to categorize “other” LMSs.  This is what we’ve found:

  • Uptake of the latest version of Moodle (2.8) is steady and in-line with historical trends. Blackboard upgraded its Moodlerooms Joule product to Moodle 2.7 giving this more-recent Moodle version a bump this quarter as well.
  • Several D2L institutions appear to be running Brightspace version 10.4. This version has been rumored to be D2L’s continuous delivery release featuring automatic monthly updates. This is an encouraging sign of progress for the company which first announced the new model in summer of 2013.
  • The share of Blackboard Learn has increased slightly, driven primarily by institutions converting from ANGEL. Almost half of Blackboard’s Learn customers are on the April or October 2014 releases at this time. The other half appears to be using a long-tail of older versions with a handful still running Blackboard Academic Suite version 8. At long last, no school appears to still be running WebCT as their only  production LMS.
  • Uptake of Sakai 10 is minimal, although it is (in our opinion) the most game-changing release for this LMS to-date. About one third of the Sakai client base appears to be actively pursuing an alternate LMS at this time.
  • Instructure Canvas usage has soared to over 400 institutions. The company has still retained its ability to keep every one of its hosted customers in lock-step on the most recent release of Canvas.
  • The top “other” LMSs are: custom, Jenzabar, ed2go, Campus Cruiser, and WebStudy. Of custom LMSs, PlumTree and SharePoint appear to be the top 2 identifiable CMS platforms on top of which LMS-like capabilities have been developed.

Blackboard is an interesting case study for this update given its most recent M&A activities. By considering unique ANGEL, Blackboard Learn, and Moodlerooms installations and then de-duplicating institutions, Blackboard’s overall LMS market share has dropped to 44.1% of institutions from an estimated 80-90% following the WebCT acquisition in 2006. Of the remaining ANGEL installations, fewer than one third are currently investigating Blackboard Learn (more than one third but less than half are exploring non-Blackboard solutions; the final third has until October 2016 to migrate to another LMS). The US higher education market for LMS products has clearly become very saturated.  Blackboard must know this, as it has been taking significant actions to more rapidly build a K12 presence, first by its merging with Edline during the private equity takeover and most recently by its acquisitions of ParentLink and Schoolwires.  When a market becomes saturated, dominant companies need to choose from a variety of alternative strategies to sustain growth.  During the past decade, the company has employed many strategies to do so including:

  • Forward integration, or gaining ownership of distributors, as evidenced by the the acquisition of NetSpot, a Blackboard Collaborate re-seller
  • Backward integration, or gaining ownership of suppliers, as evidenced by the acquisitions of  Xythos, the underlying CMS technology for Blackboard Learn, and Requestec, a supplier of WebRTC technology, presumably to be used for Blackboard Collaborate
  • Horizontal integration, or gaining ownership of competitors, such as the acquisitions of ANGEL, WebCT, and Moodlerooms
  • Market development, or introducing current products into new geographic areas, as evidenced by ramping up international expansion
  • Product development, or the improvement of existing products such as the new UX in-development, or the development of new products such as xpLor
  • Related diversification, or adding new but related products, such as SafeAssign plagiarism detection or the mobile campus app product that is now called Blackboard Mosaic
  • Unrelated diversification, or adding new but unrelated products, such as the acquisition of NTI Group which provides a product that allows for mass text and voice notifications typically used in emergency situations. Another example of this which straddles the line of related/unrelated is the acquisition of Presidium which gave the organization a leg up in building a new student services line of business.
  • Retrenchment, or regrouping through cost and asset reduction to reverse declining sales and profit, as evidenced by several recent rounds of layoffs.

It is with good reason, though, that Blackboard is actively expanding into K12 given the waning presence of its cash-cow LMS product at the university level. The K12 market is significantly bigger, representing almost 100,000 individual US schools compared to higher education’s roughly 7000, and presents greater opportunities for continued growth. The biggest challenge for Blackboard is that procurement processes and preferences for K12 schools vary widely down to the local level.  And keeping many focuses within a single company could prove to be challenging to coordinate. Acquiring companies who specialize in K12 needs and who have gone through the tremendous legal, contractual, and procedural efforts required to be added to each school district’s approved vendor list is a smart move.

Anyhow, apologies for meandering down business school lane. But we believe that the data this quarter provides an artifact to a case study of how a market-leading company has needed to change and evolve over time. Here are your spring 2015 US higher education LMS stats.

LMSs_by_the_numbers_2015Spring_700FTEThis post written by the Edutechnica team and sponsored by Client Stat.