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
APIs tend to be developed by a single organization, sometimes in collaboration with partners, to achieve a specific goal such as opening sales and partner distribution channels, increasing the visibility of products or services, giving users access to data or visibility into processes, or providing users with higher levels of control, configuration, or collaboration. While it might be ideal from the perspective of a customer or partner relying upon an API that the API be standards-based, standards conformance is at best a secondary consideration from the perspective of the API developer. The API developer's immediate concern is to deliver a design that will achieve a specific business goal and to finish the API on-time and on-budget.
This is what leaders of standards development organizations (SDOs) and standards evangelists need to keep in mind. Factors such as suitability to the immediate business goal and ease of implementation/use are always going to drive API design before considerations of standards conformance. I'm not writing off standards (not all, not yet), but it is increasingly clear that many if not most standards organizations need to change the way they operate to keep up. One source of the problem is that standards organizations may be the last great bastion for waterfall design methodologies. Analysis and requirements enter at one end of the process and a specification emerges many months or even years later, possibly followed by something like a real-world test of the specification in terms of a reference implementation. Agile, test-driven development in some form or other is rapidly becoming the norm everywhere except within standards organizations.
The other key challenge is one of constituency. I mentioned in an earlier post that there are at least a few sources of market metrics as to the type of APIs, as well as the particular APIs, that are gaining adoption. Available data shows growing use of RESTful APIs and general preference for simplicity. If you were compare the design characteristics of the APIs with strongest market adoption with the design characteristics of standards currently being developed by SDOs and Consortia, you'd find a gap. Standards organizations are behind in the shift to RESTful approaches. But even if you were to compare the SOAP-based APIs with market traction to SOAP/XML-based message standards offered by SDO's you'd find great differences in complexity. You need look no farther than counting XML name spaces. These proliferate in offerings by standards groups whereas the SOAP-based APIs with adoption in the marketplace usually keep message payloads to a single name space.
There are likely many factors contributing to the gap between what SDOs are delivering and what the market demands. Obviously, most standards organizations answer primarily to internal constituencies with a narrower set of interests than those within the broader marketplace. This has some logic to it. The group most invested in the standard would tend to favor stability versus change. On the other hand, it is hard to see how SDOs with an internal orientation can remain relevant, much less be poised to make an impact on cloud computing APIs.
So what is an SDO to do? Simply stated, the challenge for SDOs is to "get agile" and to "open up." Constraints will bring change and innovation. Perhaps some SDOs can adapt their methodologies to better ensure their offerings are aligned with market demand. Perhaps there is a role for new types of organizations or initiatives to work along side traditional SDOs. These are questions I'll continue to explore in posts to this blog.
