Last week, I attended the IEEE Learning Standards Technology Committee (LSTC) meeting in Alexandria, VA. There are at least a couple topics discussed at the meeting I'd like to cover. I'm starting in reverse order in this post since I'm covering a topic discussed on the last day of the three-day meeting.

On that third day, Chris Guin of BBN joined us to review the "SCORM RTE Web Services Interface." This was developed as part of an "Integrated Prototype Architecture" funded by Joint ADL Co-Lab beginning in 2006. A paper describing this work was submitted in 2008 in response to LETSI's call for papers on requirements for a successor to the current-day SCORM standards. As the paper describes, the web services interface follows "as closely as possible" the SCORM ECMAScript Interface for Content to Runtime Services Communication (IEEE 1484.11.2-2003).

A key difference between the two versions of the same interface is that while the ECMAScript API facilitates communications to an LMS from a Sharable Content Object (SCO) delivered within web client, the SOAP-based Web Services interface allows any application to act as an SCO. Thus, the web services version opens up the opportunity to use SCORM for integrations where content is delivered within a specialized simulation or game application rather than just a browser.

While the pace of business change is never slow, many observers note that the current economic downturn, far from slowing the pace of innovation, is certain to increase the pace of change within many sectors. The growing attention given to "cloud computing" is one example of economic constraints driving such change.

In recent a post, I promised I'd address the relationship between standards and APIs. A broad assertion that I believe holds up fairly well, is that standards are not APIs, but that ideally good standards figure into what makes a good API. As I write this post, I notice that IBM's Bob Sutor has put up a post on his blog describing issues with the proliferation of APIs that fall short on measures of "compatibility," "interoperability," or "interchangeability." Bob writes:

With cloud computing becoming more and more important, people are correctly asking questions about standards. My sense is that virtually none of the cloud environments are interchangeable and that interoperability among them is sketchy, at best. Unless one provider ends up being overwhelmingly dominant, interoperability will need to be improved.

Many would agree that standards potentially have a very important role to play in leveraging capabilities from the cloud. However, many also would agree that there are significant obstacles to realizing anything like standards-based cloud computing.

The Challenge for Standards Development Organizations

Everyday there is more written and presented about what makes a good API.

In recent years, much discussion related to APIs has focused on architectural approach (e.g., SOAP-based web services vs. RESTful ones) or even how a specific approach (like REST) is best applied. Beyond all the blog-blather about APIs (this post included among the blather), there also is an increasing number of market metrics as to the type of APIs, as well as the particular APIs, that are gaining the most adoption.

Some of the metrics come from the API publishers themselves. For example, a key data point frequently cited with regard to Amazon web services (offered in both SOAP and RESTful configurations) is that 20 percent of the usage is SOAP, while 80 percent is REST. There also are a few independent sources of information about API usage. SOA analyst and born-again cloud-computing evangelist David Lithicum highlighted in one of his recent podcasts the website Programmableweb.com, which provides a directory of, and community feedback on, more than 1,000 APIs.

What Makes a Good API?

I won't try to recreate the aforementioned blog blather about what makes a good API, but if you want to be spoon-fed a good, high-level introduction on this topic there really are few better sources than the webcast embedded below (also available here) by Joshua Bloch, a senior software engineer and architect at Google. This is a high-level review of technical design principles. I have a follow-up regarding one of Bloch's early statements in the webcast about API's as "business assets," which I'll get to below the embed.

If you've worked in standards development for any time, you've likely seen skirmishes as well as major battles. Some prove to be worthy fights, while some have proven to be an absolute waste of everyone's time. Few produce absolute, bright-line resolution, but many do influence the directions of all parties - often for the better. Some are civil, while some involve behavior that we probably wouldn't want our children to emulate. However, this post isn't a rant about manners.

I'd be curious about what others who have worked in the area of business language and messaging standards would consider the most unruly standards battle of the past decade? "WS-*" web services versus ebXML? OAGIS vs. UBL? UN/CEFACT CCTS vs. ASC X12 CICA? While "REST" isn't so much a standard or specification, some of the "WS-*" web services vs REST debates have approached the same decibal levels. Even the "un-standards body," Microformats community, has had a bitter debate or two within its ranks.

While avoiding acrimony is desirable, the level of rancor within a discussion isn't by itself an indicator of progress or a lack of it. You can certainly find examples of individuals and organizations who were opposite sides of some of the aforementioned battles who have found enough common ground to be working actively and constructively on standards projects today. Really, this is the very essences of standards making -- going from the divergent to the common -- so those who have managed to reconcile differences to work with former competitors truly are the unsung heroes within their standards-making communities.