Back to top
Blog

Data Integration Lessons from inBloom

News of inBloom's shuttering evokes mixed emotions here at Ellevation. On the one hand, we are saddened to see the inBloom platform, which offered a sound solution to the critical and complex challenges of educational data integration and educator authentication, will be closing its doors. However, this is balanced by legitimate and understandable concerns around student data privacy from parents, educators and districts.

In this post, we'll avoid a "Monday Morning Quarterback" hindsight analysis of the media- and PR-related debate around inBloom. Instead, we'll describe the problems inBloom purported to solve, how it actually proposed to solve them, and what lessons about data privacy we should derive from the inBloom failure:

  • In Part 1, "End the (CSV) Insanity", we will describe why today's state of affairs limits choice and quality solutions for educators;
  • In Part 2, "Scheme vs. Schema", we will clear up confusion between the definition and usage of the inBloom data model;
  • and in Part 3, "Great (Data) Expectations", we will offer some thoughts about what school district leadership should require of their ed-tech partners in the areas of student data integration, data security and privacy.

End the (CSV) Insanity

Every school district has a central "source of truth" for its student data, known as a Student Information System (SIS). Over time, as the needs of school systems have increased in complexity, SIS vendors have been unable to provide a single, comprehensive solution. As a result, companies like Ellevation have responded to the needs of educators by offering specialized, "best of breed" platforms that bring additional capabilities to bear for specific needs -- a wonderfully heterogeneous "app store" that meets needs as diverse as cafeteria scheduling  and IEP management.

This rapidly evolving ecosystem should be welcomed and supported, just as it has in other consumer and business markets. Just like you can select different apps for restaurant reviews, digital photography and social media, school administrators and educators should be able to purchase different apps for Learning Management, grades, and reading assessment.  But here's the "sticky wicket" -- no one wants to have re-enter student information into multiple apps. Nor should they have to. Chances are the data already exists in the SIS.

Mobile apps, such as a movie review app, don't need much more than an email address and a password. Conversely, education data is much more complex and dynamic. Quickly consider the potential data associated with a student -- their schedule,  attendance, homework, teachers, contact information, etc. -- and then remember that it can change many times over the course of a school year, if not daily. Here at Ellevation, where we work exclusively with ELL students, high mobility across schools, districts, states and countries make for some of the most dynamic data models in K-12 education.

So, in order for best-of-breed educational apps to reflect relevant, current student information – a critical precondition for a good user experience – SIS data must flow seamlessly from a central SIS repository to the application (e.g., a bus scheduling app). Enter a reliable but inefficient mode of exchange: the CSV file.

Unfortunately, the CSV sledgehammer still leaves plenty of unanswered questions that require manual intervention:

  • The format: Do column headers need to be included? If so, do they need to exactly match a unique (i.e. non-reusable) file specification? Is it your "Student First Name" the same as my "Student_First_Name"?
  • The data itself: Which students' data should be included -- enrolled or just the records that have changed? In addition to demographic data such as grade, DOB and school, what other data needs to be included? My SIS stores student race as an integer -- gah!
  • The transport: How often should I upload the file? Should I use FTP/SFTP/FTPS/Dropbox? Do I need to encrypt or zip the file? Can this be automated?

(Lather, rinse and repeat.)

If it's not clear by this point, we can summarize thusly: data integration is hard. At Ellevation, we have people and software tools dedicated to solving the many challenges of CSV files. And while we're proud of how we've managed to overcome many of these obstacles for the betterment of our partner districts, we were not alone in hoping that inBloom could show "a better way."

Why shouldn't we be hopeful? Virtually every other industry has established data interchange standards. Even in the education sector, efforts like CEDS and Ed-Fi show promise, and the growing prevalence of API-enabled applications holds promise for greater interoperability. Unfortunately, there has been limited adoption of these standards, for at least three reasons:

  • Technology change: Previous standards efforts failed to predict that education data exchange would need to occur between companies and clouds, instead of over a local network.
  • Proprietary concerns: Vendors naturally want to hold their data close ("we want school X to use our gradebook, not another gradebook") instead of providing extension points for third parties to access.
  • Unclear ROI: As a technology company, committing the resources to API-enable your product can be a significant investment -- and a chicken-egg question of how to leverage such an investment if there isn't API consumer demand (or if the demand will grow if the API is available first).

In the last few years, with increasing demand and lower-cost technology capabilities, there have been a few baby step improvements in the right direction. Third-party services such as Clever and Learnsprout provide a useful subset of student records via a common REST API (based on Ed-Fi). SIS platforms such as Powerschool now offer a REST API and SSO capabilities. However, these and other solutions provide only a narrow slice of the student record, and typically in a read-only capacity. There continues to be a need for secure, selective access to a more comprehensive data set. That is what inBloom tried to do, and their failure will be a set-back for districts that need high quality software applications to support their work.