Internet, Nonprofit 2.0, Strategy, Web Services

Getting your vendor to support Open Standards

There’s been a bit of a discussion on open standards web services APIs for nonprofits over at Deborah Finn’s Information Systems Forum. If you’re a nonprofit tech worker and you haven’t signed up to it. Do it now. You won’t be sorry.

Apparently, I’ve taken part in an old discussion about how nonprofits can extract data they’ve entered into hosted ASPs (or I guess any vendor that ends up storing your data in an inaccessible format or location). I decided to post (dated April 9, 2006) the following:

I have started to go through my list of prospective and existing vendors to advocate for open standards for data exchange. Generally, I’m advocating for a “pull” model for data on a real-time basis out of the ASP’s silo. It’s not a particularly sexy way to do data interchange but is a fairly safe and innocuous way to begin the dialogue….

I’m hoping that all the other tech workers who have final authority to recommend a tech purchase on this list will post their efforts to advocate for open standards and to encourage them to show up at NTEN NTC. I’m not a total fanboy of NTEN NTC but it could be a good way to demonstrate to these vendors the purchasing power of our sector and to give a better platform for speaking out about open standards issues….

So that’s the dream, no? An open standard web services API removes the need to have clunky .csv files dumped from your application (cough) Raiser’s Edge (cough) and empowers the nonprofit because the data can be re-exported back into another system without the need for vendor intervention. You don’t have to buy a copy of Crystal Reports or Access to process your data just because the vendor says it’s in a particular format. In short, your data is yours again and you’re no longer at the vendor’s mercy should you decide to move to another vendor. After all, it IS your data, your org created that data in the first place and at the very least, should be able to access the data that was entered in by your staff. That’s the immediate short-term benefit.

Long term, we’re talking about that meme again, Nonprofit 2.0. The ability to recombine data with another application will create new opportunities for nonprofits. Re-empowerment of the nonprofit worker and resulting transformation into a knowledge worker, data re-presented as knowledge – these are all themes for Nonprofit 2.0. The benefits are much more tangible to IT directors who have to work with data all the time but not so tangible to nonprofit management. Making this need visceral is going to have to be the job of every nonprofit IT director out there.

So here’s an action plan:

1. Before you buy hosted ASP services, DEMAND an open services API. This may mean customizing their app and helping them build a web service. Take a look at Google’s or Yahoo’s APIs and see how they can fit your app. For the most part, ask for a REST request that returns a single XML document. Try not to get too complicated in the first pass. Just a simple read-only XML of your most basic client data may actually suffice. Be a pragmatist and remember that the code to write Web services is usually shorter in length and easier to write than writing the presentation layer that originally encapsulated the data. Remember that the Web service you help build may be one that other IT directors might want to use so don’t try to build request APIs that are specific to your nonprofit org only.

2. If you already have hosted ASPs, ask for an open services API to be part of the next release. If they start to balk at it, you’ll probably have to wait until the market is sufficiently savvy enough for competitors to pop up in their space with web services. No worries, if enough IT directors do step 1, step 2 will be easy for everyone else.

3. Come back to this blog or to the Information Systems Forum and tell everyone else what you did. I’ll start making a list of ASPs that service the nonprofit sector that support open APIs. I’m already working with a new vendor — and they’re interested in doing the same. As soon as I write a spec ( which I’ll duly post here on the blog), you’ll get a sense of the actual work involved in laying the technical groundwork of Nonprofit 2.0.

How relevant was this post to you?
Why did you post this???I do not think this was necessary.Not bad. I will save for later.I really needed to read this!This bit of knowledge will make me look good. (No Ratings Yet)
Loading ... Loading ...


  • On 04.21.06 michaelatmo said:

    I’d go one step further. Picking up on your reference to Raiser’s Edge – I’d say that all apps – not just hosted ones, should provide an API. Just because the data resides on your server does not mean you have acceptable access to it. We had a user of our product ask us to move some data from our web app into Raiser’s Edge and we found the API is sold separately and it’s not inexpensive!

    And remember – access is not just the ability to extract the data, but to insert transactions. Unless you really understand the relational structure of the system, this can be very difficult without an API.

    As I said to Alan when he mentioned this on ISF recently, a real dream would be for the nptech community – vendors, users, consultants – to define a minimal API for each functional area: what do you need to expose for membership management, for events management, etc. This would let users build custom pages over their vendors products, and really leverage their investment.


  • On 04.22.06 abenamer said:

    I think long-term you’re entirely right Michael and that’s where I want to go too. The only problem is how to build enough industry momentum on our end. I don’t like to aim too high when I talk to my vendors simply because there’s a lot more code and cost associated with data insertions because they have to make it secure. A badly-coded API can lead to easy SQL injection exploits.

    At this point, I think if we try to put too much on the vendor, we’ll just end up with a lot of pushback. After all, our “power” over the vendors is fairly indirect once we’ve purchased the app. That’s why I prefer a rolling start where we just ask for read-only methods in an API. In fact, that’s basically what many commercial vendors are giving out for now. This is not to say we can’t argue for updates and inserts later but let’s just get the low-hanging fruit while we can.

  • On 06.06.06 paulmorriss said:

    I get at Raiser’s Edge via ODBC into the backend SQL database. If an API were defined, someone could at least do the read-only bit by writing a bit of code at the backend to do the SQL.

speak up

Add your comment below, or trackback from your own site.

Subscribe to these comments.

Be nice. Keep it clean. Stay on topic. No spam.

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

*Required Fields