I often hear the term “ROI” used in reference to an API program. Often, it is the discussed in the context of getting either direct revenue from an API or growing reach from an API, which in some places, translates into a lower cost of customer acquisition. While both direct revenue and reach are admirable goals, ROI from an API program is not limited to the number and quality of external developers.

For instance, most organizations will derive far more immediate payback from an API initiative if it enables internal developers, enterprise mobility initiatives, tighter partner integrations or even IT rationalization through hybrid cloud. Each of these endeavours will pay dividends in terms of productivity, agility, distribution and lowered IT costs. Each deserves its own dedicated discussion. However, underpinning all of these API business drivers  – external developers included – there is one often-overlooked consideration for cost and return in any API program: how do you introduce and innovate new APIs cost effectively?

Obviously, there are many ways to stand up an API. Many packaged software applications have some kind of API already, even if some are XML- or SOAP- centric. But in many instances, nothing exists except the desire to expose a piece of functionality or quantity of data as an API. Programmers can obviously build “programmable  interfaces” onto almost anything. It just takes time and people. However, the results will be brittle and the journey expensive.

A faster, less costly and more flexible route is to use an adaptation layer that can talk to various application or data backends and dynamically render one or more as an API. Using a backend adaptation layer can, with the right product, also solve the related problem of iterating on an API, both in terms of versioning but also composition. Add to that the promise of facilitating new business functionality by orchestrating API interactions with external mobile, social and cloud services and you get a pretty compelling ROI story.

Not surprisingly, Layer 7 provides such an adaptation layer. Our API Gateways provide more than just security and management; they simplify backend connectivity, new API formation (i.e. composition) and novel orchestrations with all kinds of cloud, social and mobile services. Like many of our API compatriots, we provide tools that help enterprises build and foster developer ecosystems. But we also realized early on that much of the cost and potential of an API program will rest on how quickly and cost-effectively new services can be launched and evolved. Something worth considering the next time you evaluate the ROI of an API program.

Yesterday, we introduced the concept of a Data Lens for aggregating and sharing data. Today, I want to talk about why this concept matters to organizations concerned with the Internet of Things (IoT).

Simply put: “things” generate petabytes of data. Putting sensors on everything, as both Cisco and GE propose, creates a data nightmare. Hadoop has made analyzing big volumes of data much easier but what happens when you want to share a small sliver of that information with a customer or partner? After all, the purpose of “Big Data” collection is not altruism – it’s about monetization. In many situations, this will only be possible if data can be shared easily.

A Data Lens gives IoT data owners – such as manufactures or telco carriers – an easy and secure way to share a focused and billable data set with their customers and partners. Anything outside of the scope of a Data Lens cannot be accessed, whereas anything inside the lens is  “in focus”. The data in focus can be raw or aggregated. There can be any number of Data Lenses on a data set. They can be used internally or shared securely with external partners and customers. Data access through individual Data Lenses can be governed by service level agreements and – through metering – monetized.

For manufacturers and network operators looking at ways to share focused data slices from their Big Data, a Data Lens solves a big problem. By leveraging the Layer 7 API Gateway’s unique ability to focus on small data sets inside larger ones and to present these data sets as secure APIs, customized to specific customers or partners, it’s possible for IoT operators to drive new revenue from their Big Data.

As we see it here at Layer 7, there are two big problems with Big Data:

1. There’s just so much of it that it’s easy to lose sight of the byte-sized trees in the petabyte-sized forest

2. It’s locked away in every recess of the enterprise – from applications to relational databases, to non-relational databases, to in-memory caches, public clouds, Hadoop clusters etc.

Data growth and diversity have made data access harder. But data access is the foundation of mobile app development, anything to do with the Internet of Things (IoT) and all kinds of Big Data analytics. Given this need for data in the face of access complexity, it didn’t come as a total surprise to see some of the most innovative Layer 7 customers start using our API Gateway technology as a novel data access, aggregation and presentation solution. As our resident IoT expert Holger Reinhardt pointed out to me: they are using our products to build highly-customized “lenses” across their distributed data backends. To me, this characterization is perfect because what these customers are looking for is perspective on their data. A lens gives perspective with focus.

Now, a Layer 7 API Gateway is more than just a data integration solution. Our technology has several unique features that make it ideal for collecting, composing and presenting data. First, we can talk to all kinds of data sources natively. That wasn’t easy to achieve and it’s something we developed over many years. Second, we can represent the source data as a RESTful API. Even better, we can dynamically generate a virtual API view for a specific user, app, partner etc. The API then becomes the entry point for accessing the aggregated data. Third, we can add fine-grained access and protection policies that ensure only authorized consumers get visibility to specific slices of data, while also protecting the data sources from attack and misuse. When combined, these capabilities give organizations a way to focus on just the information that is relevant to a particular mobile, IoT or Big Data analytics project and then share selectively with an app, cloud service, developer or partner.

A data lens is born!

If you want to learn more about our Data Lens solution, have a read of this new solution brief. Also, feel free to reach out to us with any questions.

A decade ago, during the first wave of Internet innovation, countless business plans began with the breathless promise of becoming the UN of this or that information exchange. ECommerce and communications would be transformed through the mediation of a neutral “man in the middle”. Here’s what happened: the communitarian exchanges failed; businesses that went direct to consumers succeeded; the hope for communal mediation was left to overreaching consortia grasping after fading relevance.

Why did  the “disintermediated” direct-to-buyer model win? Simple: it was simplicity. The problem with multilateral exchanges is complexity. They require members to buy in completely and never hedge with alternative paths to consumers; they require the exchanges to always be subservient to the members; and they require 100% participation and 100% consensus. That’s why they keep failing despite the best efforts of organizations like GSMA, the UN, OASIS and others. They require a rigid web of multilateral agreements, subjugation of individual corporate needs to ephemeral collective goals and universality. Just because the broker is a for-profit entity like Apigee doesn’t change anything so long as success or failure depends on universal cooperation and comity. To repeat an oft-used metaphor: putting lipstick on failed efforts like WAC and OneAPI won’t make them any more attractive. They will never have the agility and directness of an over-the-top direct-to-buyer/consumer/developer service. That’s why giant operators keep getting beat by three-person Y Combinator start-ups.

Does this mean aggregation is dead? Of course not! Aggregation models can work but only if the “broker” has the independence and freedom to go off and negotiate unilateral agreements as needed. The aggregator must have the freedom to be run like a self-interested business where the wishes and hopes of the underlying providers don’t factor in. As evidence look at the growing disparity between Netflix and Hulu. The latter emerged as a deliberately-crippled response to the growing power of Netflix. However, the need to accommodate multilateral interests has made it irrelevant. ISIS is fairing no better in the payments arena.

For operators, there is a similar lesson. Be the broker or sell to the broker. Each model has clear economics and places success or failure in the hands of the operator. If an operator wants to offer non-geo-specific services to buyers, it should partner with over-the-top providers or get the capacity from other operators one-to-one. If an operator would rather wholesale its services, be promiscuous and enable every broker/aggregator to consume its services, fine. Then let them be your buyers. The beauty of both models is that they are non-exclusive and don’t require consensus, universality or other impracticalities.

I give Apigee credit, the API Exchange is an improvement over the failed WAC. However the problem was never just technology. Some business models just don’t work in practice.

For API publishers, acquiring developers is a pretty fundamental matter. “More developers, more money and reach” goes the thinking. But are all developers of equal value? And is borrowing a developer as good as true developer ownership?

My rather unsurprising answer to both questions is: “No”. Clearly, some developers will be more valuable than others and borrowing will never be a substitute for ownership. Here’s why:
•    The only developers that matter are those that are engaged and active

Registration numbers don’t matter. “Key Wielding” this or that is marketing fluff. Looky-loo’s don’t build apps that drive revenue or reach. They may take your time, they may toy with your APIs but they won’t deliver business value. And if they are borrowed, “drive-by” developers, guess what – they never will!

As a vendor that helps organizations publish APIs, my advice is to always own your developer. Don’t get caught up in the promises of vendors lending access to hordes of faceless developers. The only developers that matter are the ones engaged directly with you because those are the ones that care about your API and those are the ones that you can develop and nurture.

This does not mean that making it easy for high-value developers to access your APIs should not be a goal. Giving engaged GitHub developers the ability to use their credentials to access your APIs is smart. There are millions of current, high-quality developers waiting for the right project.

So, pick a vendor like Layer 7 that enables onboarding and Single Sign-On from GitHub and other deep pools of active, engaged developers. And be careful not to get caught up in the developer equivalent of a feel-good payday loan. You will pay a high price in the long run.