Think APIs – Freedom to innovate

Freedom to innovate is the most important imperative for many businesses today. Try early, learn fast, scale easily – key characteristics of a dynamic, engaging enterprise. The focus for this (second) API entry point is to chase business opportunity aggressively and to make innovation a learning process

- Everything is a prototype… until proven in practice

- Learning that something didn’t work is not failing… it is just learning

- Standing still… equals guaranteed decline

The role of APIs is to provide the calm center in the “eye of the storm of change”. This has two aspects:

- Deliver quickly what the experimenting API consumer needs (and remove it again when no longer needed)

- Protect the provider from churn (remember from an earlier blog that defining and deploying new API “views” on existing assets should be easy and cheap)

The Freedom to Innovate entry point is perhaps not as glamorous as Monetize your data, but is by far the API use case that I see the most in major Enterprises. The ability to compose new innovative capabilities, internal and/or external, without breaking the bank in terms of cost, is something that everyone is struggling with. To accelerate innovation, a blend of careful planning and opportunistic reaction is required.

- The desired outcome is to quickly learn what works and differentiates in the market, then to scale successes. Even when we believe that we know what the market needs, a “learning attitude” can deliver a healthy reality check. It is easy to get symptom and root cause mixed up when dealing with complex market dynamics.

- The audience is primarily internal developers (whether in house or sourced). There are cases where for instance external agencies are hired to be part of an innovation effort. In such cases more formal agreements are required on which APIs to provide and when, but even then it is best to keep some amount of opportunistic behavior in order to maintain learning speed. Contract negotiations are anathema to fast innovation.

- The APIs required to engage the audience are a blend of pre-defined enterprise APIs and opportunistic APIs derived from the needs of an innovative app. The reason for mixing in some amount of enterprise APIs is that exposing core data in an easily accessible fashion can kick-start not only development but also ideation. Be mindful though of keeping the pre-defined APIs small and simple – exposing the full data structure of a customer backend system probably isn’t what an innovative channel developer would consider easy to consume.

- The Ts&Cs under which API consumption happen remain important. Not in terms of “payment”, but in terms of protecting the back end systems, security wise and workload wise. After all, innovation is unpredictable 

- How to curate the data and function to implement the APIs differs between the pre-planned enterprise APIs and the opportunistic demand driven APIs. For the pre-planned APIs, careful decisions on which data segments to expose are important. Also, during implementation runtime cost is a key focus area. Pre-planned APIs will be used in varied and un-predictable ways and associated runtime cost must not be a gating factor. For the opportunistic APIs, the most important consideration is development speed and development cost. If you have to do a hack to get the API out the door today rather than next week, then do so as long as there is a viable approach to cleaning up if and when the opportunistic API becomes a success. Note that many of your opportunistic APIs may not live very long – if it turns out that something different was needed, just scratch the API and start over in the next iteration of the learning process.

- Considering which 3rd party APIs to consume is important for the Freedom to Innovate entry point. As a simple example, building social mobile apps is difficult without accessing APIs from well-known public social services like Twitter, Facebook or Linked-in. These third party APIs should be part of the API catalog that you provide to your internal developers, rather than forcing them go to some external site to find things themselves. You may even want to curate the 3rd party APIs into your own simpler version, as some of the public APIs are quite complex in their native form.

Innovation is never easy, but it can still be aided in various ways. Proper use of APIs can make the corporate backend an integral part of your innovation engine rather than being the millstone around your feet. Enterprises with a long history obviously have the advantage of having more assets to expose as APIs. But even for startup’s, taking an API driven approach to implementing innovative solutions provides more flexibility in terms of sourcing data and function. The use of APIs frees the channel developers to focus on the user experience rather than integration. The use of APIs also promotes an omni-channel experience as data and function behind the API by definition are remote, hence can be accessed from any channel or application across the enterprise.

Connect with me on @ClausTorpJensen or read my earlier blogs. You can also subscribe to the blog list here