Illuminate Education Shines Light on Growing Need for Better Data Sharing

“We are an all data system,” says Mark Walls, Chief Product Officer at Illuminate Education. “We’ll build out whatever data set you want.”

That’s a bold offer, but one that the Irvine, Calif.-based company says it can deliver to its customers, which include more than 1,500 districts serving roughly 5.5 million students. Illuminate’s three core products aim to help educators manage their students’ learning experience through tools that capture and visualize different types of data, from attendance and assessment to behavior, demographics and special needs.

To provide this service, Illuminate needs to receive student data from other tools such as student information systems (SIS) and assessment providers.

For Illuminate, the ability to openly share data between schools and tools isn’t just a nice-to-have. It’s a core product feature. “We’ve been talking about interoperability since the beginning in 2009. It’s a key tenet of what we do,” Walls explained.

As Edtech Industry Grows, So Do Data Conversations

“The conversation around interoperability has shifted over the past decade,” Walls notes. Back in 2009, data interoperability wasn’t a high priority—simply because there weren’t many data management products in the market. “There were fewer players in the field,” he says.

At the time, Illuminate only had to figure out how to import data from a few tools.

Yet as the edtech industry has grown, so too has the number of digital tools. And as schools adopt more technologies, their data systems have become more complex. Educators today want data to be able to travel seamlessly between the specialized tools in their increasingly complex learning environments.

Illuminate was founded to serve this demand, says Walls. “Data sharing is what we do, so there aren’t really product development trade offs.”

Data Pipeline Decisions

Requests related to data integration usually come from the school. For example, a district that uses PowerSchool’s student information system, and Illuminate to deliver assessments, will want the two systems to be connected so that the assessment data automatically shows up in PowerSchool. Teachers shouldn’t have to do manual data entry work to make this happen.

“No one uses the word ‘Interoperability,’” Walls says, “but that’s what they [educators] are asking for.”

For Walls’ team, there were several approaches to improving how data is shared between edtech tools. They could:

adopt an open data sharing initiative like the Schools Interoperability Framework (SIF);
manually set up custom processes for importing and exporting files to each tool a customer uses;
build an application program interface (API) that customers can use to access Illuminate’s data

Adopting a common open data standard like SIF was the most appealing option to Walls. In theory, if every edtech company invested the time and resources to do this alignment, data could flow between products seamlessly and require little additional investment from developers. It would be a win-win situation.

Yet the issue with SIF was less about getting companies onboard, and more about its adoption in schools and districts. According to Walls, SIF proved too complicated for administrators and educators to use. For instance, in order for data to transfer between SIF-aligned systems, a district needed a specific server, specific software, and manual coordination of all the products to determine which information needed to flow in which direction and at what time.

A highly trained staff was required to pull off the technical feat. “Districts had to have IT staff with the appropriate skill level to do all of these things,” says Walls. “What we were seeing was that districts were asking their teachers and administrative clerks to fill these roles.” Since schools and districts didn’t have the right personnel and resources to use SIF effectively, he believed the initiative wasn’t worth investing in.

The second option would be a costly compromise. Theoretically, the company could work with each customer to set up custom processes to pass data files between Illuminate and the other tools used by a school. However, since each tool reported data differently, the amount of time it would take to provide this custom service for each customer’s unique suite of products would quickly become too costly for the team to sustain.

In 2011, the company decided on the third option: building its own API that would allow other vendors to get data from Illuminate whenever they wanted it. (Think of an API as a mall directory that people use to figure out what data points are available and how to find them.)

Through Illuminate’s API, schools and other product vendors could, using a few lines of code, collect the data they want. This would save the company from having to spend time transferring data between systems themselves.

Illuminate released its API, yet Walls realized this wasn’t a perfect solution. Even though many schools will ask vendors to talk to one another to make their data compatible, sometimes those conversations stall because both vendors have their own APIs, which don’t play nicely with each other.

Walls recognizes that this is a problematic situation, and that Illuminate’s API is only a partial solution to interoperability. But it was a step in the right direction. “We understand that this API didn’t adequately address the idea of interoperability for some customers,” he acknowledges.

One Standard to Rule Them All?

According to Walls and many other industry experts, the answer to the interoperability problem rests upon having a single industry standard API, built according to open standards such as SIF 3.0 or Ed-Fi. In fact, he recalls that right around 2011 Illuminate was having conversations with Ed-Fi Alliance saying, “We need a standard API in education.”

The first step, according to Walls, is for educators to mobilize behind the issue of interoperability so that it gets attention and gains traction. Then, likely with the support of a foundation, a small working group should be created. Ideally it would include four or five vendors with significant experience dealing with data interoperability, and a handful of administrators from across the country who are well-versed in data issues.

The group should determine the three or four most common use cases for data sharing in the field and begin building, or working with an existing standardized API around only those needs. After these few use cases are built out, companies should test them and iterate to determine how they can be improved for users. “We don’t need to solve all of the problems,” Walls says. “Let us sit at a table with the right people and solve one small problem really well.”