The rate of change in the API economy is accelerating as more and more organizations understand the power provided by apps and APIs and the agility provided by big data analysis. Here are five changes that will shape the API economy in the coming year.
1. The difference between APIs and SOA becomes crystal clear
I’m continually asked: “We already have SOA, why do we need an API layer?” This is like saying, “I already have bank account, why do I need a credit card?” At the backend, your credit card is linked to your bank account. But you can use your credit card far more flexibly in new and innovative ways that you just cannot with your bank account. And of course, PayPal and Bitcoins are now doing to credit cards what credit cards did to bank accounts.
SOA is for enterprise apps. They have a half-life of decades. APIs are for modern apps and, in many cases, mobile ones. They have a half-life of months. APIs need to be a separate layer—case closed.
2. Application-specific APIs proliferate through Ctrl-C/Ctrl-V—the same way as the web proliferated in the beginning
Dan Jacobson, Netflix’s director of API engineering, said it pretty well here. There are going to be two sides of the API layers—services looking up, and apps looking down. Typically, the latter might be 10x the former. Construction of the app-side APIs will happen by starting with 1:1 mapping of the service-side APIs, but then, over time, two changes will occur:
Efficiency and optimization for delivering the right performance to apps will require some lightweight orchestration or coordination of the server-side APIs. For example, mobile apps might make a call to one app-side API, but that API in turn might coordinate or orchestrate multiple server-side APIs, for efficiency’s sake. Such orchestration logic will sit in the API layer such as Apigee’s API Services.
The app-side API hits the 10x mark only when every developer isn’t forced to write from scratch. Many a story has been written on how the web initially proliferated because people liberally did Ctrl-C/Ctrl-V of their favorite websites (links and all) to get started. Within an enterprise—and quite possibly across an enterprise—similar things are bound to happen. Without that, the proliferation just cannot happen, despite the fact that businesses will demand that this proliferation happens. This implies that just like a website is a collection of HTML pages, an app-centric API should be completely packageable and copyable.
3. Everyone realizes that an API is just a channel; data is the real competitive advantage
Lou Gerstner, IBM’s CEO back when the web was becoming popular, famously asked a team that showed him the IBM web site: “where’s the buy button?” He knew that going from static content to transactional content was the big leap of the web. Amazon quickly took the lead here, by moving from transactional content to smart content (with recommendations, for example). Most API usage today is somewhere between static and transactional but by the end of 2014, it will become smart. Without continuously analyzing, optimizing, and acting on API traffic and contextual traffic, businesses won’t see the advantages of the API revolution.
Our customers are already making the journey here. At Apigee, we’ve built out deeply embedded analytics and our Insights platform to bring the power of big data to the API world. A platform that does not support such tight integration of data, analytics, and insights with the world of APIs will not serve the needs of the business that is looking at its digital transformation strategy with the same strategic perspective as it looked at the web in the 1990s.
4. Data-centric architectures will start to take shape in enterprises
I have said it before, and let me repeat it: ETL is dead.
Of course, it is dead in the way that mainframes are dead. IBM continues to show growth in mainframes. However, the growth is much, much smaller than new web-centric and cloud-centric hardware. Similarly, people will continue to buy ETL technologies. However, they’ll do so to maintain the world of legacy enterprise apps, which feed legacy enterprise warehouses, which feed legacy business intelligence apps.
The world of APIs is transforming the world of data integration and ETL in fundamental ways:
More and more data are being fronted by APIs, forcing any data integration layer to become API centric. ETL has typically been database- and enterprise app-centric (SAP connectors are an example).
Data fronted by APIs is meant to be easily consumable (a basic tenet of APIs says that they are consumption-centric). This makes the job of integrating that much easier, as it doesn’t require expensive cleansing and standardization. This is typically achieved by some lightweight integration being done at the data source itself.
Common patterns of ETL (lookups, joins, and normalization, for example) are easily supported in modern API-centric architectures, so many or all of the things done in the ETL layer are easily and better done in an API layer.
At Apigee, we are building all our enterprise apps using an API-centric data architecture. A classic example of this is our own Customer360 app, which gives us visibility into hundreds of our customers. The data that we surface, the insights that we generate, and the actions that we take are all API-centric. Jira, Marketo, salesforce.com, Google Analytics, and Apigee API services are all sources of data, and are all fronted by APIs, using GETs. Lightweight mapping between, for example, a customerID in salesforce.com and orgID in Apigee API services are the basic building blocks that allow us to build these apps. The beauty is that we can take actions on insights we generate back into these apps through POSTs.
5. M2M API-centric architectures get their first major instantiations
I don’t know about you, but I love my Nest. For all the mobile devices out there, the number of other devices connected to the internet will be one hundred times larger. Many of these devices do not speak APIs, just like many of the enterprise backends don’t. But connecting these devices to enterprise backends is the thing to do. Consider the success of connecting smart meters to utility grid controllers, or health care devices to patient management.
The solution is as obvious as stated in the paragraph above. Two API gateways connected back-to-back. One API gateway speaks proprietary protocol to the devices. One API gateway speaks proprietary protocol to back-end services. This is the way APIs will revolutionize M2M, even if both ends do not speak APIs!
We are already seeing examples of this across the Internet of Things: Nest, Belkin Wemo, Etherios (by Digi), Insteon, Axeda, and many other industry-specific solutions create M2M silos the same way silos of applications for TV, mobile, tablet, or desktop were created in the past. Connecting two API gateways back-to-back not only creates a universal rendezvous point for the integration of devices to applications, but also enables cross-M2M solutions and cross-experiences.