Every institution that implements a new enterprise application or data system must choose how to integrate it with existing applications. Typically, the choice boils down to integrating the systems using in-house resources and staff or outsourcing aspects of the integration to a professional services firm.
Considering recent advancements in educational data APIs, institutions should base their integration approach on a concrete API strategy, not simply choosing to outsource. Choosing the right strategy can save significant time and money and increase confidence in the IT administration among faculty, staff, and student users.
The explosion of educational app, app store, cloud solution, and data analytic providers has placed a premium on high quality, consistent, and timely student outcomes data. Almost every higher education application we have profiled is “data hungry,” meaning that it requires near realtime access to student records, assessments, learning events, and measures of engagement. This has created a new set of data API requirements for institutions and application vendors. Nearly every provider has its own proprietary data API to exchange learner data collected within that application (the ProgrammableWeb maintains a searchable database of literally hundreds of education data APIs supported by application vendors). Each vendor uses its own proprietary API with no common language, data dictionary, or standard set of web services for institutions to use to query this data.
This diversity in data integration options results in three approaches for developing an API strategy for existing data systems and newly connected applications:
- The DIY Approach: Build interfaces to every API the vendor offers for each source of data required and pull the data required for your application on demand
- The Middleware Approach: Integrate once to a middleware provider and fully outsource the management of adaptors to data sources
- The Data Platform Approach: Standardize on a data platform and direct all vendor partners to write back critical data to a centralized data store using its unified API
The DIY Approach
We could also call this approach to data integration the status quo. Institutions and developers today must build one-off integrations for each source of data needed for any campus technology. When newer applications come to market, sometimes institutions have no other option but to roll up their sleeves, learn all they can about the product’s internal database and architecture, and integrate the application themselves.
This is quite expensive and requires duplicative effort for each data source and application. Only institutions with robust internal software development teams can support a DIY approach for very long. Institutions that attempt this approach quickly turn to other integration options or solicit outside consultants to keep up with the pace of new system integration requests. Managing the connected interfaces quickly becomes a nightmare scenario if—or more likely when—a vendor changes an API unexpectedly, causing a ripple effect across the institution as interfaces break and data from critical systems becomes unavailable.
The Middleware Approach
This approach relies on a separate software application that resides between applications as a data hub, commonly referred to as middleware, and abstracts data exchange between system providers. By leveraging a middleware application and set of APIs from a single provider that the institution installs locally, app developers can modify their code to receive data directly from the standardized API, with no data ever passing directly between applications. This approach is ideal for institutions that still want to control data locally and for all exchange to occur on-premise at the institution. Still, it presents yet another technology installation for the IT staff to manage.
Consider Apple’s recent acquisition of the middleware provider LearnSprout. Access to student outcomes data remains a serious pain point for app developers for Apple mobile devices. Without a common framework to access student records on systems under institutional control, app developers must build their own, separate interfaces for each SIS, LMS, or assessment system. During our 2015 research on iTunes U for our report on Learning Management Systems, Apple went on the record with Eduventures about not wanting to directly store or manage its clients’ educational data, which would make it a lightning rod for student data privacy advocates. Parent and educator groups would attempt to scrutinize Apple for managing education data at all, whether or not it had a solid approach to protecting those student records. Acquiring LearnSprout enables the educational giant to provide app developers with an integration path to access education data while staying out of the business of storing student records.
Many more middleware options exist in P-12 than in higher education. The most well known is Clever. We are routinely asked if there is a higher ed equivalent to Clever. The closest might be the newest solution from Lingk, which not only positions itself as an alternative to Clever for the P-12 market, but also directly markets its data integration services to both higher ed institutions and app developers. It provides a standardized set of APIs based on Common Education Data Standards (CEDS).This allows developers to focus on a single integration point for consistent data access, rather than learn the landscape of data system APIs from hundreds of other vendors and platforms. Its approach accounts for institutions’ existing investments in middleware, but this middleware isn’t required to get started, as they can use Lingk’s cloud services for data exchange instead. Its platform also provides situational awareness of what data elements are being shared with connected applications already in use on campus. Any data that is exchanged between applications can be routed through Lingk to audit scheduled file transfers and real-time API calls for data policy compliance.
The Data Platform Approach
This approach is based on moving all educational data into a single monolithic database, whether on-premise or in the cloud, and normalizing it to present all of the information that an institution knows about each student.
There are currently two schools of thought on the data platform approach. The first, more traditional view is that the student information system (SIS) maintains students’ “official records” and should be the centralized location for all student data. In this view, there should be a high bar set for which applications can access this data. The second, more emerging view is that ongoing student engagement is the primary source of data. We have identified two major platform vendors that are promoting new—and competing—educational data API standards that align with each of these viewpoints.
SIS as the Data Platform: Ellucian’s Ellucian Ethos Data Model
In October 2015, Ellucian announced its plan to standardize on a ”higher education data model,” which it is now referring to in marketing as the Ethos Data Model. Responding to institutions’ need for a single view of student outcomes and success metrics, Ellucian’s goal is to normalize data into a single student snapshot, tracking their progress from recruitment to career placement. At launch, Ellucian had aligned very few of its products with this new data model. In fact, a quick review of Ellucian’s current product roadmaps indicate that it will take two to three years to provide this unified data architecture for the majority of its solutions.
Ellucian also claims that it is seeking patents on its data model and approach, even though Ethos is based at least in part on CEDS. There still seems to be some internal debate at Ellucian about the balancing the proprietary lock-in to Ellucian’s data model approach and its recent adoption of an open integration strategy. Ellucian clients will often seek out their own solutions to fit their institutional environment, regardless of integration costs and level of sophistication. This forces the company to realize that it is better to open its API and make integrations easier for institutions and integrating vendor partners. However, Ellucian is only granting API access to partners at certain levels. Integration partners, hand-picked by Ellucian, already have to go through a shadowing process for the first few implementations, and as such, Ellucian isn’t investing in a certification process for Ethos and its related APIs for a broader systems integration market until Ethos is more widely adopted across product lines.
CRM as the Data Platform: Salesforce’s HEDA
Salesforce has made it clear that it believes the CRM can fill the role of the centralized data platform for higher education institutions as a platform that supersedes existing SIS capabilities, the LMS and other data-centric services. Its vision of a CRM-centric approach to student-lifecycle management includes a robust API layer that allows third-party app developers to integrate with the Salesforce platform. Many app developers have created their own data models and objects for Salesforce that are unique to their application’s needs, though, and are not at all interoperable with other applications from the Salesforce AppExchange. Just this past month, Salesforce launched the “higher education data architecture” (HEDA) to address this problem.
HEDA is an open-source data architecture built on the Salesforce platform and made available as a free installation through the appExchange. Its goal was to standardize the objects that fully describe the student’s relationship to a university, including student groups, academic programs, and courses. Once an institution has installed the HEDA, Salesforce’s robust APIs immediately make every supported data object and record type available. Salesforce referenced three clients that are already working with systems integrators to build custom recruiting, admissions, and student success solutions on top of HEDA: University of Miami, Tulane University, and Maryville University.
In crafting the initial release of HEDA, Salesforce left out transactional processes and workflows that are unique to specific higher ed departments and business functions, such as admissions, academic advising, and learning management. Its intention was to leave data objects that are more transactional in nature under the purview of the developers of systems integrators who build products on top of Salesforce. It’s also worth noting that the current version of HEDA is not aligned with CEDS. Salesforce is more focused on speed of implementation for new clients than on ubiquitous mapping to data standards with this release. It may circle back to provide CEDS alignment in data objects and fields in a future release if its institutional users advocate for that enhancement.
Choose your Data API Approach Wisely
Before embarking on a major change to your institution’s integration approach, audit both the data sources and applications used, as well as the specific data elements that need to pass between these systems. The success of the API strategies described above depends on the specific mix of applications, their maturity, and whether your institution views integration as a core competency of your IT department. Starting with a clear understanding of the scope of available data, as well as of the litany of data APIs your existing vendors and systems provide, will enable your institution to make the best decision about which data API strategy to pursue.