Data Exchange and APIs as part of the solution
Posted February 17th, 2008 by Steve BackmanI've been thinking a lot about data integration lately. It's always been a significant and distinctive part of our approach. It was therefore a natural to contribute to Idealware's wonderful framework for evaluating data exchange programming tools for nonprofits.
Most everyone has some expectations these days that you should be able to get your own data out of one software package and get it into another. Export and Import as a way of life. It's simple and often works. It's also tedious, manual, limited in what you can get and use, open to errors of omission or commission, which we all have made.
A data exchange framework means that the software vendor provides programming tools that let you peek beneath the surface. It means you get to see your own data as it really is in the software system. You can get what you want pretty much how and when you want it. It means you can move it from your web activism tools to your internal donor management system, from a state or other mandated data collection system to your own analytical tools, or other such things.
This realm goes beyond just automating the same old import and export. You can achieve more refinement of which data moves and how, time when you need the new data to arrive, prevent duplication, check for errors, send news of what has happened, and so on. My colleague Emily Graham, who also contributed to the Idealware project, has developed great mastery over the years in making such things happen.
In corporate computing, APIs (application programming interfaces) and SDKs (software development kits) have been around for a long time. And not just around, but expected. What is exciting and different now is that the expectation that the tools follow emerging standard norms that are part of the Web 2.0 world these days. And expectations have grown around their use in the nonprofit and small business world, and not just the top reaches of corporate software. Idealware's initiative reflects this shift, and its been fun taking part.
In assessments we do today, we look at these changes as enabling us to offer a wider range of solutions than existed a few years ago. Some factors in this shift:
- Organizations need feel less pressure to purchase software systems all in one place. You like the donor management system but don't like the general ledger? Get what you need and only build the data exchange. We look for data exchange tools that are free or low cost and as well-documented and supported as the software itself. The Idealware framework provides a great check list for evaluation.
- Organizations can feel more empowered that their data is truly their own. Many software systems, especially on the web, offer reporting tools that lag behind data collection options. Programmed data exchange can integrate off the shelf web query tools, Excel, Access or other choices to do do extended planning and analysis.
- Data exchange also moves us way beyond the “buy versus build” debate (which has been old for a while anyhow). These days, we rarely build anything from scratch. The prevalence of APIs and SDKs mean that software development is more modular. We can construct a solution for an organization that looks and functions as their unique system, but underneath, brings together a number of components.
These three changes, and the tools that make them possible, reflect global economic and social changes in which we all expect data to flow with less friction everywhere. We would like to keep control over it from the government and other snoops, and that's another story. But it's great advising on strategy today and being able to confidently give organizations way more choices over how they collect and use their own data.
Check out the Idealware report--and please consider making a donation to Idealware when you do.
- Steve Backman's blog
- Login or register to post comments


See also the vision
See also the vision expressed by the founder of Drupal, Dries Buytaert, in this article, From infinite extensibility to infinite interoperability. In summary: