Non-Profit Tech Blog

“Honey, can you take out the laundry please?”

Actually, my wife never says that. I’m lucky to live in a neighborhood where the local laundromat will pick up your laundry and then deliver it the next day, clean-smelling and freshly folded. In fact, visitors who stay at my apartment are often amazed at how efficient the service is. I believe this laundry service is fairly analogous to what an open API does. The proprietor, Steve, and I use English as an agreed-upon language for setting the terms of the transaction. He even offers some documentation in the form of a receipt and a number corresponding to the weight of the laundry. This week it was twelve pounds. I gave him all my laundry and returned with all the laundry I gave him. Very few items have been lost in the last few years. And it’s pretty darn cheap because it’s run as a family business. What more could you want? And uh, excuse the stick figures but I got the idea over at Andy Kessler’s blog.

And really, that’s why we in the non-profit sector really like the idea of open APIs. Efficient, open and cheap transactions should represent the core ideas that are encapsulated within an open API. However, before I start enumerating the trademarks of a truly open API let’s just make sure everyone knows what an API is. API stands for “application programming interface”. In its general, Wikipedia definition, an API does not imply something like a .csv file dump from an application. Where exactly is the programming interface there? There’s a data interchange taking place in a .csv file dump but it is NOT an example of an API, let alone an open one. What an API implies is there’s some interface that you can write code to much like a menu being made available to a diner. Again, to continue the analogy, it’s the menu, not the dinner that needs to be served to the diner. That’s the difference between a .csv file and a method call like “ReadAll(date_start, date_end)”.

I would also say that the term “open API” does not instantly imply a Web interface. In fact, many nonprofit IT directors can live WITHOUT a Web interface being designed by a vendor application. After all, getting some business apps to talk to each other won’t necessarily result in some cool geocoded mashup. On a business operations level, an open API is merely a way to take data from one business process and insert it into another one. And frankly, this is how IT Directors and the rest of a nonprofit management staff should see it. And again, this is why so many nonprofit workers get frustrated by the LACK of an open API. It should be simple to take data from one process and move it over to another one or is it? After all, if I can have my laundry why can’t Judi Sohn from C3: Colorectal Cancer Coalition mix and match member and donor information in salesforce.com and GetActive?

Imagine if say, Steve decided that he would only wash my clothes in hot water and that he would then drop off my clothes in 3 lb. packets every 3 hours on Tuesdays. I’d be stuck with very tight “tidy whiteys” and would be a bit of a laughingstock in my floods not to mention the fact that I’d probably have to take all of Tuesday off to retrieve all my laundry. Worse, what if Steve charged me thousands of dollars so that he could wash the clothes the way I wanted them washed and to leave my Tuesdays free for other things? That’s the situation we’re in right now in the nonprofit sector when we work with multiple data vendors (not to mention Blackbaud). So let’s stick to the business transaction that I’ve outlined in the beginning of this article and see if we can draw up a strategy for defining an open API.

To be continued… in part 2 of this post.