Wednesday, February 13, 2013

inBloom, Ed-Fi, and Killing SIF

Data interoperability has been a problem in schools since the first district mainframe started chugging out report cards and first teacher started typing their quiz grades into Visicalc. For more than a decade, the "right" way to solve this problem was SIF, the Schools Interoperability Framework, which started out as an experiment by Microsoft into how one might manage integration using the then-new XML standard. As you might expect, they guessed wrong about what the best -- or at least most common and widely understood -- practices in this regard would end up being.

During my "open standards are inherently good" phase, I spent a lot of time on SIF, including writing an (incomplete and unfinished) open source SIF "zone integration server" in Python and generally promoting SIF to the global open source in education community (to no avail, probably justifiably). Finally I just washed my hands of the whole logjam, realizing it was going to take someone opening a very large wallet to fund a viable competitor to shove aside SIF to make any progress in this decidedly un-sexy area.

While I've been pointedly not paying attention, this has finally come to pass. First step, CES, the Common Educational Data standard, which is hosted by the federal Dept. of Ed, laid out a newly revised data model.

Next, Ed-Fi, funded by the Dell Foundation, added... I'm not sure what. Some interim layer between CES data and what follows...

The Big Kahuna is now known as inBloom (née Shared Learning Collaborative). inBloom encompasses several aspects, including, at least as I currently understand it:

  1. A well documented open source implementation of the preceding standards and a REST web services API based upon them. The lack of a free reference implementation was one of the things that crippled SIF. SIF couldn't do this because it became controlled by companies who were in the business of providing proprietary SIF solutions. inBloom will be controlled by content providers, who aren't going to let this potential gravy train be screwed up by a few chiseling little educational IT companies trying to squeeze pennies out of district tech budgets.
  2. The source code for a big repository for pretty much all the data relevant to teaching and learning in K-12 schools, along with various open source clients.
  3. The singular big repository for as much of the data relevant to student learning in the entire country as they can "ingest" as they like to put it.

Of these, it is #3 that people are justifiably freaking out about, particularly over the kind and amount of data which commercial vendors may be given access to.

Overall, this parallels the centralization on the internet which we've seen over the past 15 years. Nobody wants to run their own mail server or even try to keep a WordPress up to date, with good reason, nor do we have static IP addresses at home or even IPv6, so we just let Google (Amazon, etc.) handle it. This is pretty much the same idea, although I suppose your school district will still have its own student information system too. Or will it? That's a good question.

From SchoolTool's point of view, this is certainly worth keeping an eye on. When Steve Alexander sketched out his initial design for SchoolTool almost a decade ago, REST web service API's were very cutting edge, which is one of the things that attracted me to the project. Unfortunately, you get no benefit whatsoever for adopting an interoperability technique 10 years ahead of all the other applications you'd like to talk to, so REST web services support eventually dropped away in SchoolTool. At this point, I pretty regularly get questions about whether we have a web API to which I respond "Not really, is there one in particular that you'd like us to support?" which essentially is never answered. It seems like a waste of money to make one up ourselves (again) because I know as soon as we do it everyone will say "Oh, we can't use this, you should have implemented 'X'!" Perhaps inBloom will give us a useful standard to apply either as a client or even to mimic their server API. If this takes off, Virginia CTE at least will want CanDo to act as an inBloom client.

A few other random impressions:

  • This doesn't literally kill SIF, your SIF system will be able to talk to inBloom if you've already got that. SIF's not really going to grow after this point though.
  • There doesn't seem to be any major "gotchas" in the open source-ness of the project (like used to plague ed tech) although the server code is not yet available, the issue will be the legitimate difficulty of getting your own inBloom server running. There's a lot more to that kind of system than just the code, and even if they do a LOT of work to try to make it feasible, it will still probably be impractical to run yourself. On the other hand, it will be possible to do outside security audits, which should give people some solace.
  • This is the context that I've seen Common Core in -- it is actually a bigger project to align both technical and academic standards to create an efficient marketplace. The worst thing about the whole process is that we're implicitly simplifying our concept of "education" to make it fit this model. If you believe that the problem with American education is that we aren't delivering the correct market-tested and research-approved chunks of curriculum to individual students at the right time, this is awesome. I just don't think that's the problem.
  • When you read through something like this, you see why I've been so critical about all the discussion of the various curriculuar mandates in the Common Core appendices and commentary. This system is not going to care about how much fiction or non-fiction you've read this year, or if it is constructing an appropriately sequenced knowledge-based curriculum. It is going to serve up exactly what it thinks a student needs to raise his or her scores on the enumerated standards. There is no place in the data model for, "Also, too, suggestions from David Coleman and E.D. Hirsch."
  • Thanks to Dan Willingham for all the articles, but the data model does include an attribute for a student's learning styles, expressed as percentages weighted between three categories. This was not added by hippies.
  • I'm imagining a lot of advertising embedded in this process for teachers: our system recommends Pearson's ReadBlast 3000 for students with Timmy's profile! Talk to your curriculum coordinator today!

Finally, if history is a guide, this project will collapse under its own weight, so don't get too enthusiastic or paranoid.

1 comment:

nvrijn said...

Great blog post and your last sentence was amazingly spot on about the InBloom implosion. Twas data privacy issues killed the beast (or at least wounded it).

However you need to re-touch base with SIF though - a LOT has changed. The SIF 3.0 spec is in member review, and should go public before the end of the month (August) and it looks like a game changer. For openers the new infrastructure is:

1. Independent of the data model (runs unchanged in the AU, US, and UK).

2. REST based (no more roll your own transport)

3. Middleware optional: A client does not know whether it is communicating with a service directly or with a broker.

The data model is 100% CEDS compatible ... basically in the US SIF 3.0 is CEDS on a secure wire.

Oh ... and check out the SIF REST Developers Sandbox - a hands on tutorial on the new specification, a test harness for SIF v3.0 clients .. and available for developers "out of the chute".

http://rest3api.sifassociation.org/jsp/index.jsp