Hi all -
I can appreciate that the CEO of a standards organization thinks that standards are the solution every bit as much as the CEO of a vendor thinks that their product is the solution. :) As with many things, the truth and reality here lie in the middle. Standards work well in certain cases just like APIs work well in other scenarios. We've had the greatest successes when blending the two approaches. Standards just don't do all of the things that we'd like to do in the ways we'd like to do them. APIs in contrast, don't establish enough common ground when perhaps there should be, but as a trade-off they can open up more possibilities on a shorter timeframe.
I'd also like to advocate for integration middleware, be it in-house or commercial. Again, here we've had success by blending both approaches (our own solution in combination with Apidapter - http://www.apidapter.com/product/, Lingk was not yet a company when we started down this path). It has saved us heaps of headaches, allowed us to address undesired glitches introduced by upgrades, set us up with the flexibility to transparently swap systems out for others, and enabled us to do much more much faster. Unfortunately the reality for us is that we have to transform even standards-based requests to make up for the inconsistencies in implementation among products, including those listed as certified by standards organizations. We also, in tandem, work with each of our vendors to improve their standards-compliant integrations over time, but they can't always do so on our timeline. Our culture is to get things done, and we regularly choose not to wait - either on the vendors or on various standards organizations to make improvements where we want them. We then work improvements as they are made into regular maintenance so that interim solutions do not become permanent.
The topic of APIs should remain on all of our minds because of the possibilities that they make possible in the same ways that standards make other things possible. As one example, SURFnet in the Netherlands is pursuing an open standard _for_ a university API. Doing so could open up the possibility of vendors writing to a common university API implemented by each institution instead of each university having to write to each vendor's API individually. BYU is pursuing some very interesting work related to institution-wide APIs that should be more broadly considered, and Michael Feldstein has also penned a blog post about the possibilities APIs open up from an individual's perspective. Here are some links to learn more:
Enterprise Solutions Architect / Academic Technologies
University of Maryland University College
Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.