As mobile becomes key for business success, it seems that everywhere you turn in today’s digital businesses—from the C-suite to the developers—APIs are being talked about. 2013 was a monumental year for APIs with increasing amounts of enterprises in every industry—from health to retail—realizing the transformative power of APIs on business. As we head into 2014, 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
A common refrain among developers is: “We already have SOA, why do we need an API layer?” This is like asking, “I already have bank account, why do I need a credit card?”
At the back end, 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 achieve with your bank account. And of course, PayPal and Bitcoin are now doing to credit cards what credit cards did to bank accounts.
The difference? 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 the same way as the Web proliferated in the beginning
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.
• 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 copy/paste 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 website: “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 reap the advantages of the API revolution. Today’s businesses must re-examine their digital transformation strategies with the same strategic perspectives with which businesses looked at the rise of the Web in the 1990s. Today this means looking into platforms that support tight integration of data, analytics and insights with the world of APIs.
#!4. Data-centric architectures will start to take shape in enterprises
It’s been said before, but 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 is 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 is 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.
Enterprise apps built using API-centric data architecture are becoming more prevalent. More and more of the data surfaced, insights generated, and the actions taken as a result are becoming API-centric.
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 100x larger. Many of these devices do not speak APIs, just like many of the enterprise back ends don’t. But connecting these devices to enterprise back ends is the thing to do.
Consider the success of connecting smart meters to utility grid controllers, or healthcare 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.
Anant Jhingran (Ph.D. from Berkeley) leads Apigee’s data technology as vice president of products, having joined from IBM where he was vice president and CTO for IBM’s Information Management division. He had a wide impact on IBM’s business in warehousing, search, e-commerce and analytics on structured and unstructured data, and he worked on IBM’s Watson computer.