Apigee is announcing the launch of its Enterprise Monetization Services today, a complete end-to-end solution for companies seeking to monetize their APIs and other digital assets. In this phone interview with Anita Paul, Director of API Products, and Bryan Kirschner, Director of the Apigee Institute, I had a chance to dive deeper into what makes this product a leap ahead of its competitors. The product will be available sometime in August.
Designed to fit into Apigee's Enterprise API platform, the monetization services makes it easy for companies with APIs to manage how they make money from them, and to manage that from a wide variety of angles. Here's where the product fits into their portfolio of offerings.
Programmableweb Welcome to both of you. Give us an overview of the product's main goals.
Anita Paul The function of the Enterprise Monetization Services is to maximize monitization, and just as importantly to manage the developer/partner workflow, the relationship the owners of APIs (the digital assets), have with the developers who are using those APIs.
PW Most readers know Apigee as the company with a platform for people to build enterprise apps, data and APIs on. How does that build on your existing products? What is the most important thing about Enterprise Monetization Services?
AP I’ve been working in the field with legacy systems on monetizing and billing and so on for 10 – 15 years. But now that the world is changing into using APIs, this presents problems for legacy business models. When you have an API that you are trying to monetize, to sell to developers or create a revenue stream with in some way, you want to be able to make changes to your business model, and make them fast. In the old system you had to notify a developer to make the changes in your business model. Then you had a laborious task of notifying developers, your customers, of the change. And that's just a small fraction of a cumbersome process. Here’s what’s different with our new Enterprise Monetization Services;
- It's all self-service. Look at it from the owner of the digital assets point of view, the owner of the API, for example. As a business you can change the plans you offer--pricing and much more. Critically, you can look at performance, to see which business models you are testing are working. So you have an understanding of your business models, what works and what doesn't, that informs your choices about how you choose to monetize your digital assets.
- Now let's look at it from the other end. What does the developer see, your client who is using the API in their app or however they are using it? Just as it is for the asset owner, it's self-service for developers. Meaning you can pick amongst plans and so on and implement them with a mouse click in real time. It's quite possible, for example, that as the developer's business changes--a change in volume to take the simplest example--it might want a different plan from the API owner. Making choices is easy.
Bryan Krischner This is part of doing a platform in the digital world. It's not just about gateway management. But as business assets increasingly become digital, everything will be digital in some sense. The divide between digital and nondigital assets is to some extent disappearing; everything seems to have a digital side to it. The problem is that, to manage those assets, traditionally you had to bring IT people in to make changes in the business model, and so on. With Enterprise Monetization Services, now you just manage the asset and the models.
PW You have customers including Dell, AT&T, Motley fool, and eBay. What does this mean for firms like them?
AP Clients spend a lot of money to manage and integrate different monetization strategies, and to do that differently for their different customers. The Enterprise Monetization Services integrates into the back end so that the client has new tools that fit in with existing core processes.
Here's a big advantage. Big customers have this concern: how does it fit with our large system? The answer is, easily, since it is all API-based and you can manage it—without a boatload of technical people.
BK Right, so there are cost savings for the big guys. But beyond that, a lot of folks who were not at the pointy edge of the spear in terms of API use are now comfortable with APIs. Now, they are now asking, how can we have an ecosystem that manages our digital assets? And how do we know what the best structure for monetization is? That’s an empirical question. To find the answer to what monetization plans work best with each type of developer or client, you need to experiment. In the old days you would grab people from the market research and legal departments and start doing surveys and so forth. Today, with our services solution you can skip all that and instead start setting terms, expose them to developers and learn from the results to see which plans are most effective for which customers--right on the spot.
PW So just to clarify, businesses have to experiment. And that's because you can’t get the business model right the first time?
BK Exactly. Folks get stuck to be able to do a classic NPV proposal: what's the net present value of some digital asset? What is this API worth? The answer is very clear: who the heck knows? So you have a dilemma: You have to act, but you also have to experiment.
PW You say the enterprise monetization services are aimed at addressing pain points. You've covered some in terms of legacy systems. Tell me more about those.
AP A big one is notification: I want to notify my developers I am changing a plan. How do I do that? Our system makes it both simple and extremely flexible. Here's another one: monitoring. How do you know when you want to change a plan? By monitoring performance of various offerings, you can find the answer to that question. These pain points go on and on; even finance functions are changing, becoming easier to manage.
PW Tell me more about what types of business models the monetization services support. I see you support freemium models; what are other new transactional opportunities?
AP Let's look at two. One is where the developer pays to use your asset, an API, say, and the other where you pay developer. The traditional model is a bundle of transactions. Now you can charge within the API: you can create plans for storage. You can do discounts for higher plans. And you can create bundles for API calls.
The second model is to share revenue with developers. They get a portion of the revenue that comes in. For example, telecos share revenue, based on what content has been sold, with developers and partners. This is different from the traditional invoice model based on API calls and charges based on usage. This is a revenue model where I give the developer a share of the revenue.
PW You say it's the only fully integrated end-to-end solution from purchase to payment. What are your competitor's offerings typically missing?
AP With legacy systems they have stability but can't engage in experimenting and aren't self-managed. With newer competitors, they don’t offer end to end. How do you get the plan across, how to buy it, how to bill, how to pay for it, how to monitor it? We cover all those things.
The developers get their developer portal, where they can manage their company profile, choose or change a purchase plan, monitor revenue reports, billings and more. A big advantage is that you have no manual processes. No more calling up developers to get them to pay you--the billing and payment via credit card is all automatic.
BK In addition, all the terms and conditions you set are based on your developer identity. You can have different terms and conditions for different developers: like you can incentivize volume for the big guys. You can offer free for smaller partners. You can have thee (or more) different offers for big, medium and small users. Your terms can be developer specific. And you can set it up so that only certain categories of developers get to see certain offerings.
Here's what we mean by self service: it doesn’t require technical intervention. That means your commercial team of sales, finances, and whoever the nontechnical mangers are can manage the system without calling in their IT experts.
You can also try experiments without having your IT team set them up--it's all user friendly so you can set them up yourself.
AP Another great feature is you can set triggers. Let's say I want to know when a given API uses more than 5,000 calls a week. Or I want to know when a developer is doing well. You can set these triggers based on a plan, a developer user, a time span like daily, weekly, monthly, etc. So, for example, you can set a trigger for any developer if he or she hits that 5,000 call mark. Or it could be based on value: tell me when someone has hit more than $5,000, for example. You can set a range of options for what happens at the point something is triggered. You can notify developers, but you don't have to--it can trigger some internal event like a notification to you, as an alternative.
PW Bryan, tell us more about the Apigee Institute and how it worked to develop this product.
BK The Institute is our research arm that grew out of our interactions with customers. We have a unique perspective that is immersed in both the tech and business sides. Take a question like: How do you move forward with ditigal transformation? We want to share what we learn. We also got exposed to a lot of questions with no good answers. No hard data. The Institute was created to share and add to knowledge. As part of our research agenda we did a global survey of executives, and we have built a membership organization where we hear what the big questions are. Then we focus on researching the answers.
The Institute has an outbound role with its members but also an inbound role. We see patterns and share those in the process of product development. Let's take one example related to the product being announced today, the Enterprise Monetization Services. Let's return to that situation where you can't calculate the NPV because things are highly uncertain. Under very uncertain conditions, there's a tendency to do nothing because you can’t know. But if you avoid risk for a year, you may sidestep some pain but your competitors will have jumped ahead.
To develop real options for ROI, you should forecast several different scenarios and think through how to use the data. You have to be able to experiment to create that data. And that's very hard if not impossible with a legacy system.
PW So you guys are facilitating data collection from experiments.
BK Exactly. We think there is an opportunity to explore empirical questions, but you have to be able to experiment—and experiment cheaply.
PW Thank you both, Anita and Bryan.
A demo video is available, with more to come.