A lot of "cloud" applications will have a need to communicate with other applications and data sources that are also living out in the cloud, or even with applications living behind a firewall that are somehow leveraging the cloud.
An ideal way for this communication to occur is via APIs, interfaces where data is passed back and forth between these applications (typically with XML using protocols like SOAP or REST) with an increased effort towards automation and getting more ROI out of these applications.
Not only will APIs enable the retrieving of information from external data sources to create a more data-driven and therefore useful application on a one-to-one basis, but exposing a public API enabling communication with a given cloud application can unleash waves of creativity to be driven by other developers and business users who have their own specific or custom use for that cloud application.
An example is all of the innovation that has emerged on top of the Twitter API, many of which are entirely re-defining what Twitter means to certain audiences, making people more productive with Twitter, and creating all kinds of additional value and staying power for the Twitter application itself, with each new application further increasing Twitter's shelf life.
However, driving adoption of a public API isn't always easy to achieve because of the inherent randomness to API development, from interfaces, authentication and usage models, data structures, response codes, and general API behavior. So even if user management, metering, and in some cases usage-based billing is already in place as part of a well-managed API, having a difficult or non-standard API can substantially slow adoption of that API, and perhaps even rendering it useless.
For example, there are hundreds of different ways to respond with a "data not found" response for a Web services API invocation, and a developer typically needs to learn what it is and a whole other set of rules for each API that they come in to contact with so they can develop on top of it. This adds a great deal of complexity, is not really scalable, and represents a major impediment to development of the back-end data highways servicing the cloud (not to mention a future mess of custom code), highways that otherwise could really help drive the usefulness of cloud applications.
What we have tried to do at StrikeIron is create a normalization layer for all of the potential differences that might occur from API to API so that a developer's workload and ongoing maintenance complexity is dramatically reduced. This is key when connecting APIs together to build exciting new applications and functionality, or connecting these APIs to existing applications that can benefit from their use (such as simple address verification call). Authentication is the same for APIs that live in the land of StrikeIron, as are interfaces, data structures, response codes and behavior, and of course all of the APIs published through StrikeIron share the same analytics formats, all regardless of what the underlying technology driving the API happens to be.
Take a look at the frictionless (or nearly frictionless) StrikeIron ecosystem below as an indicator of what the future cloud might look like, with several centralized pods like StrikeIron directing traffic and enforcing consistency and simplicity. As these API and data highway network ecosystems emerge, they will reduce a lot of the inherent complexity and randomness of cloud interfaces and enable others to easily hook into ecosystems without having to modify their own approach to the cloud, whether it's on the consumption side or publishing side of the universe.
The key is getting all of the inhibitors out of the way so that these data highways can flourish and connect applications to data and to other applications, including Web applications, social media platforms, internal applications, internal data, external data, CRM platforms, other on-demand applications, mobile devices, and any other component of value that someone might want to bring into the cloud.
What we have going on at StrikeIron I think this is a pretty good start to making it so. Fire me an email to find out how to hook into this (bob.brauer "AT" strikeiron.com) and see it in action.
Comments