What is Happening?
The API economy is not conceptually new in most of its facets. The core idea that libraries of services could be called to create applications has been both proposed and adopted through SOA and ESBs for more than a decade, and prior to that in mainframe programming with the use of Programming Libraries. There, are however, some marked differences in the surrounding technology climate that have made the API economy different from previous iterations, and in many ways much more potent, which include availability over the Internet, the true enablement of multi-vendor suites, and their ubiquity in the rise of Cloud, Mobile, Social, and Analytics.
Why is it Happening?
The API Economy does not just refer to the services that are available, but also that they are easily accessibly across networked systems, usually over the Internet and through cloud applications. The implications here are that the economies of scale that are available to those creating APIs are much greater. Because of standards being adopted by creators of APIs as well, creating and using them has become significantly easier. With the larger potential scale, the ROI on creating APIs can be realized much faster. The array of integrations available by common APIs between a variety of both consumer and enterprise applications has become a critical facet of an application’s worthiness in any workflow or business – especially where they reduce the necessity for manual data entry, retrieval, or synchronization.
Businesses see application programming interfaces (APIs) as an antidote to creating new data silos that would be highly dispersed amongst various cloud applications, and can leverage APIs along the way to create a variety of backups, copies, archival records, and integrations. Additionally, applications architected around the exposure of APIs tend to function well as their use cases evolve. For example, many Enterprise Social Networks (ESNs) enabled APIs to publish to their activity streams, such as Yammer, Broadvision, Tibbr, Huddle and others. Originally, it was used merely as a notification system, but as the applications evolved, so did the use cases and APIs. Some ESNs introduced 2-way APIs in their activity streams. As a result, this allowed user to take action from the activity stream that could return a value to the originating application, thus allowing the approval of invoices, expenses etc. without leaving the activity stream environment.
The second force that sets APIs apart from previous attempts at unified libraries of services is that capabilities around billings, subscription management, metering, and monitoring have become more robust as well as more ubiquitous. Though we are not yet in an era where individual application services (a probability function from a BI tool, for example) are widely called by external applications through APIs, we are approaching that eventuality. Many vendors, such as MetraTech and Aria, can already enable this kind of billing and several BI companies exist that meter by the amount of data ingested. As sensor technology improves, and more and more businesses start to rely on machine generated data, the ability to meter and bill for data flows (even if only for chargebacks between departments) will play an important part in the economic case for creating and using APIs.
Finally, the confluence of emergent technology trends – Cloud, Mobile, Social, Analytics, and Integration – has ushered in an era of applications that are natively built around APIs. Mobile applications count on abundant APIs to interact with the devices they run on, as well as the APIs that communicate with the application functions themselves that reside in the cloud. Data applications count on APIs to ingest and output data and results to and from other applications. Social IT has essentially merged in with other applications by extensive use of APIs to become part of many applications. And obviously integration technologies are being used to either create or simulate APIs to systems that didn’t natively expose functionality that way. For example, vendors like Informatica, Mulesoft, Boomi, and SnapLogic are enabling companies to build hybrid architectures by exposing both data and services from traditional applications, Cloud applications, or directly from APIs. This enables the creation of loosely-coupled, flexible functionality, but not through integration only. The API economy enables the systematic packaging of services that can be metered, monitored, and monetized.
The rise of the API economy is likely to present application vendors with a transformative imperative over the next two years. Though many Cloud-based applications and services already rely heavily on APIs, most have not yet realized the strategic value that APIs will enable in the creation of unique business services. Vendors’ availability through their APIs will prove a competitive advantage in the near future as concerns about both data and application integration abound.
Winners in this marketplace will be those who provide tools that control the way business processes and application services connect to each other, which can provide an additional layer of value over traditional ETL processes. Applications architected around exposing their services via APIs will also enable their business consumers to be more flexible in how systems can communicate, and what data and services are shared. APIs will be central to ensuring that a cloud strategy does not create a set of isolated applications that further complicate an organization’s ability to manage and reconcile data from disparate sources.
Finally, companies that are able to create centers of excellence around their API use and management will find that the agility garnered from the use of APIs instead of traditional integrations will enable them to react faster to competitive threats, take advantage of new tools more easily, and simplify the overall management of their cloud application portfolio.