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.
