How do I fund my API Program?

dcouldwell
Participant III

Project centric funding of API programs does not work. The cycling of resources and associated knowledge loss each time a new team needs to get up to speed means an API Program cannot achieve and maintain the velocity demanded in todays Digital Economy.

Does the community agree? Do you have experiences of funding models for API Programs that work?

5 15 1,397
15 REPLIES 15

This isn't really a new problem for API programs. Every new technology introduction to an organization presents the same challenges with respect to building and retaining knowledge & expertise.

What matters is whether the organization sees the new technology as 'core' or not. It must be stressed that APIs present a new 'core' capability for the organization, and so must invest with dedicated resources - funding and human capital.

Not applicable

@Dom Couldwell,

Great question. Often I have found that the funding question has to do with where the organization is on the continuum from Experiment to Enterprise. In the beginning, funding seems to be more about allocating time - as there are many low cost tech options, Apigee included, for getting started - oh the SaaS revolution. The bigger issue comes at the scaling up point - moving beyond the usual IT funding and into the realm of Strategic Investment. Going digital my have to start small, but in the long run the successful orgs are the ones that embrace digital - and API are a core foundation - at a strategic level.

. @apaterson Completely agree that, at the end of the day, it is all about people. It is so hard for people to be successful when they are doing a fulltime job - with all the old processes and constraints - and then "in their spare time" completely context shift and bootstrap a whole new process and deliver value. People need to be able to focus.

There is a great chapter in the book Growing Global (Palmisano at el) that talks about how Schneider Electric went through a similar adventure with ERP, when they realized it was core they really took advantage of it. Now they see APIs and the digital economy as the next step.

So, cycling people through a program that is well established is a great way to spread digital culture and capability, provided there is a stable core. Without that core, it is extremely difficult to reach critical mass - which is a necessary condition for any platform to take off. You need to have enough wood behind the arrow.

Over here at Apigee, we are collecting stories from customers on their funding journeys - please share - if you want to share privately, feel free to contact me at nick@apigee.com

Not applicable

@Dom Couldwell, @Birute Awasthi I've found that funding strategies are directly associated to type of API program. Is it an internal/private, partner, or open program (or combination)? Is it specific to a product/platform or enterprise.

Pearson's first API program (Web Services On Demand) was partner/client centric and seen as an enabler for the product. And as it turned out, the primary reason many of our clients stayed on the product. Funding for the program was provided through the product organization and treated like a product subsystem (which requires documentation, support, marketing, etc).

We’re now in the process of rolling out an internal global API strategy and have demonstrated that an internal developer program (think API developer network) can reduce costs associate with support by 50%, and costs associated with discovery, on-boarding and education by 30%. This turns out to be a huge cost savings (based on size of Pearson) and this type of service can be leveraged to support many other inhouse technologies.

The cost-benefit of the program when presented in this light becomes self-evident and the question quickly becomes why aren’t we doing this rather than how we fund it.

I run our API Practice in Telstra, and have been working on setting up our API Program here, which has been a challenge in a large organisation.

From what I've experienced, I think there are 2 phases to ensuring a successful API Program. The first phase, early on in the transformation journey, the API Program is easiest to be incubated by a centralised team that has control over an API delivery/operate budget and the people required to deliver the APIs. Importantly this also needs a senior champion in the business who can help pave the way through other business units and get other senior stakeholders on-board.

The second phase (which we're now just starting at Telstra) is a distributed API program (some people call this a federated program, or a decentralised program), which is where project-centric funding can be used to deliver APIs as part of normal system/product delivery. It also largely helps if the company is running a formalised digital transformation/IT-simplification program where the CIO (or CxO) is on-board. Executive championing is still critical here.

APIs in their own right are difficult to get up as a business case. What we've done is ensured that Telstra is "API First", so that any projects that seek funding must have APIs implemented when releasing new systems/platforms or integrating into existing systems. This has helped break the problem and has ensured teams of developers start up among different parts of the business so that they can deliver on our IT strategy of being API First.

I hope this helps!

I run our API Practice in Telstra, and have been working on setting up our API Program here, which has been a challenge in a large organisation.

From what I've experienced, I think there are 2 phases to ensuring a successful API Program. The first phase, early on in the transformation journey, the API Program is easiest to be incubated by a centralised team that has control over an API delivery/operate budget and the people required to deliver the APIs. Importantly this also needs a senior champion in the business who can help pave the way through other business units and get other senior stakeholders on-board.

The second phase (which we're now just starting at Telstra) is a distributed API program (some people call this a federated program, or a decentralised program), which is where project-centric funding can be used to deliver APIs as part of normal system/product delivery. It also largely helps if the company is running a formalised digital transformation/IT-simplification program where the CIO (or CxO) is on-board. Executive championing is still critical here.

APIs in their own right are difficult to get up as a business case. What we've done is ensured that Telstra is "API First", so that any projects that seek funding must have APIs implemented when releasing new systems/platforms or integrating into existing systems. This has helped break the problem and has ensured teams of developers start up among different parts of the business so that they can deliver on our IT strategy of being API First.

I hope this helps!

Great answer @David.A.Freeman , Welcome to Apigee Community 🙂

Would you ever consider that this could also be a mix of the two. First the centralized API Team builds facades for individual business units and advise them on design patterns. Then turns the future care and feeding over to said business oriented IT team for future refinement?

kkleva
Participant V

I'd like to try using an internal monetization model to help fund our API program. Hopefully we've done our jobs helping app developer build amazing apps, move data and automate 'things' with our free APIs. Now that everyone is mostly happy perhaps I could charge back a few cents per hit to fund future sprints?

Michael Leppitsch wrote a great article on this. I think it is better to have an automatic allocation of capital towards the API platform in your business, rather than a cost allocation per customer or project as it might be perceived as a tax on progress for that initiative and an unwanted burden.

Would agree with @apaterson particularly in the initial stages of the program, where the value and costs of the APIs are not well established or understood. At a later point, and this is where fine grained analytics come in, you may be able to identify the APIs that are either expensive (they consume a lot of back end resources, for instance) or are driving revenue growth or are having significant impact on cost or time to market - when those are well established with data - you should start to look at the opportunity to monetize. But check with the folks you are going to charge first - make sure they appreciate the value proposition. If they don't buy the value proposition, they wither won't pay, or look for a way around. You need to have them hooked before you charge.

mchalmers
Participant I

Interesting issues associated w/APIs and their productisation. Transformation from project > program > platform/products causes disruption far beyond IT. Projects and Programs have start and end-date, defined scope, fixed objectives, budget codes etc. Products live long and morph endlessly into different value props. Project-based enterprise accounting practices can’t cope - the API team started as a discrete cost-code, now it's a P&L generating savings / revenue / income. CFU’s save time and effort (=money) from your re-useable API products - how do you get your share? Internal transfer of wooden-dollars might be the answer, but are your Enterprise Accountants as Agile as your API squads? Can 2-speed accounting mirror your 2-speed iT?

I've felt this pain myself. When transformation follows the project > program > platform journey funding definitely becomes a sore subject. Before we folded nicely under a project budget. Now we're servicing customers all over the Enterprise.

Also, if the API Team is Agile you'll likely delivering value in short sprints where the time between idea and production deployment could only a matter weeks. This kind of turn-around isn't always conducive to yearly budget cycles that depend on all work being estimated / budgeted a year in advanced.

I've floated the idea of charge back system where the API team could effectively run at a fixed cost and charge the business units for any work done under their direction post deployment. Our clients love the idea... our restaurant is serving good food so they are willing to pay. But as you said... "Enterprise Accounting" likely isn't as agile as your API squad.

So maybe the question should not only be "How do I fund my API Program?" But also "How do I keep the API Platform funded?"

Kris - I like the notion of how do I keep the API Platform funded - you may want to look at the following Forrester report

Monetizing APIs: Help Execs Think Bigger, And Drive More Revenue

Randy Heffner with Christopher Mines, Derek Nahabedian, Peter Harrison

Not applicable

This is a fascinating question. At Oregon State University our API initiative is centrally funded. We initially started by having to show different orgs and units the value behind having an API program. We were able to get off the ground by getting some internal upper management support. We chose not to monetize our API usage because we want to improve our integrations and go from bulk feeds to near-time APIs when appropriate. Using monetization would discourage the use of APIs withing our developers.

When I talk to other universities their experience is usually federated or de-centralized. They usually have students, departments and developers throughout the organization developing APIs. Depending on the style of the organization, developers aren't always given a mandate that they must use the provided API portal.

What I have seen that works for most users is showing people the benefits of the API program and helping communicate how the API program adds value to the organization. Due to funding sometimes people have to tie API manager solutions to projects. Depending on the organization having the API program be attached or tied to successful key programs can promote the program and help with funding conversations.

Great Answer @jose.cedeno , +1