I'm Brett Slatkin and this is where I write about programming and related topics. Check out my favorite posts if you're new to this site. You can also contact me here or view my projects.

16 November 2012


Good article about Harper, OFA, and Narwhal. I had a chance to volunteer with these folks this summer and it was a blast.

Some highlights:

Narwhal unified what Obama for America knew about voters, canvassers, event-goers, and phone-bankers, and it did it in real time.


When Obama campaign chief Jim Messina signed off on hiring Reed, he told him, "Welcome to the team. Don't fuck it up." As Election Day ended and the dust settled, it was clear: Reed had not fucked it up.


Perhaps most importantly, Narwhal really got on track, thanks no doubt to Davidsen's efforts as well as Josh Thayer's, the lead engineer who arrived in April. What Narwhal fixed was a problem that's long plagued campaigns. You have all this data coming in from all these places -- the voter file, various field offices, the analytics people, the website, mobile stuff. In 2008, and all previous races, the numbers changed once a day. It wasn't real-time. And the people looking to hit their numbers in various ways out in the field offices -- number of volunteers and dollars raised and voters persuaded -- were used to seeing that update happen like that.

But from an infrastructure level, how much better would it be if you could sync that data in real time across the entire campaign? That's what Narwhal was supposed to do. Davidsen, in true product-manager form, broke down precisely how it all worked. First, she said, Narwhal wasn't really one thing, but several. Narwhal was just an initially helpful brand for the bundle of software.

In reality, it had three components. "One is vendor integration: BSD, NGP, VAN [the latter two companies merged in 2010]. Just getting all of that data into the system and getting it in real time as soon as it goes in one system to another," she said. "The second part is an API portion. You don't want a million consumers getting data via SQL." The API allowed people to access parts of the data without letting them get at the SQL database on the backend. It provided a safe way for Dashboard, the Call Tool (which helped people make calls), and the Twitter Blaster to pull data. And the last part was the presentation of the data that was in the system. While the dream had been for all applications to run through Narwhal in real time, it turned out that couldn't work. So, they split things into real-time applications like the Call Tool or things on the web. And then they provided a separate way for the Analytics people, who had very specific needs, to get the data in a different form. Then, whatever they came up with was fed back into Narwhal.
© 2009-2016 Brett Slatkin