“Open” APIs: a definition
There is a propensity in the technology industry, most industries for that matter, to latch onto adjectives and begin to use them excessively. In the process of descriptive repetition, the importance can be masked or diminished. With that said, the usage of the adjective, typically, is appropriate and connotes unique value…after all, the initial usage had to be compelling enough for it to gain popularity.
Let’s consider the adjective “open”.
As defined by Princeton WordNet, the usage of the word open that is most applicable to our discussion is as follows:
S: (adj) open (accessible to all) “open season”; “an open economy”
“Accessible to all…”
What is the goal of an API strategy? Accessibility. If you are a Service Provider (payments or otherwise) attempting to gain market share, ensuring accessibility of your service via APIs gives you an opportunity to partner with Software Companies & developers. If, however, your service is only available through a proprietary interface — or a dated set of specifications — the challenge of adoption is multiplied.
Open is accessible.
But there is more to “open” than just accessibility.
Consider the business of a Software Company…as they make a decision about how to bring their solutions to market, they face the challenge of all business…customer requirements dictate timeline and real, tangible cost dictates the complexity of integration that can be undertaken. As a result, a Software Company can only choose a discrete number of partners and tools to leverage.
Will your API be chosen? It depends on whether your APIs can be consumed in the fashion the Software Company expects. I will discuss this in greater detail this week when enumerating the decision making process regarding REST and SOAP implementations of web services.
Open is flexible.
Flexibility is powerful…but insufficient when considered alone.
If presented an API (or set of APIs) that they know how to use and offers some of the services required (at least notionally), the next step becomes an exercise in planning for future requirements. The comparison of volume of available services, value-added workflows available through the API, and the future capabilities presented is a very important process. The Software Company requires the ability to choose their services not only today…but in the future.
Open is choice.
This phenomenon, or perhaps requirement (as it relates to the payments industry), is elucidated by my IP Commerce colleague Peter Osberg in a post entitled Messages From The Edge: Taking Care of Customers – Payment and Provider Choice in APIs on PaymentsAPI.com.*
When a Software Company or Developer references “open” they are often speaking to the availability of choice. Choice in tenders offered and choice in providers leveraged coupled with choice in their development tools. Regrettably, the concept of “open” is foreign to many traditional participants in the payments industry – whose proprietary services and platforms effectively restrict choice.
So, what is “Open”?
Open is accessible.
Open is flexible.
Open is choice.
What’s your perspective? Agree? Disagree? Anything to add? Critiques? The comment form is below…
* PaymentsAPI.com is curated by IP Commerce and more information can be found in About Payments API.
June 28, 2010