Vodafone and Netflix – Reference blueprints for Platform Business Models
As Gartner describes APIs are at the heart of the digital business model, a topic they explore through their Gartner Platforms series, focusing on specific impacted sectors like digital banking.
This great Diginomica case study of Pearson shares insights into how one pioneering media organization harnessed APIs into their digital strategy. Pitney Bowes highlights the concept in simple terms like a ‘digital supply chain’, how can you reflect the downstream world that sells your products, in API enabling terms?
APIs are about making the business ‘programmable’, like how it enabled the ‘platformication‘ of the Evernote business model. Dr Lester Thomas, Chief Systems Architecture at Vodafone, describes their central role in developing a Telco marketplace in this form, an ‘NFVaaS Ecosystem’.
Vodafone – Platform Business Model
The role of APIs in enabling Vodafone’s Platform model is described in this TMF blog.
Companies like BT, Orange and Vodafone see orchestration and APIs as key components of their strategies to become platform providers: Multiple orchestrators in multiple software platforms will communicate with each other and with other network and OSS/BSS components to deliver services – through open APIs.
They are also using the APIs to open their network to customers. “Large enterprises are demanding API access to Vodafone because they want to be in control of their services, very dynamically,” says Dr. Lester Thomas, Chief Systems Architect, Vodafone Group.
The other main industry trend that intersects here to very powerful effect is the open sourcing of AT&T’s core NFV platform ‘ECOMP’, which has since accelerated into a broader industry momentum and consolidating ecosystem, with ECOMP merging with Open-O to form a new ‘ONAP’ – Open Network Automation Platform.
Therefore the API features of ECOMP will now be features of an open source distribution for others to use the same way, such as defined in this earlier this TelecomTV interview, where AT&T’s Director of Ethernet Product Management Dan Blemings describes their motivations for the disruptive ECOMP move, and specifically the role of APIs as a central feature:
- API-driven tools for wholesale providers to on board into their systems so they can provision ethernet services in real-time, versus weeks and months.
- They are opting for open standards versus proprietary vendor solutions, essential to this supplier interoperability, such as the MEF 55 LSO Reference Architecture .
- Open sourcing ECOMP is intended to provide the industry a ‘shot of adrenaline’ that drives compability through a faster, more innovative ecosystem, particularly encouraging contributions back to the open source to spur innovation.
- This is central to their Platform Business Model.
Maturity Model – APIs and Microservices
In this Linkedin blog, Anil Madan specifically describes the role of the API in the Platform Business Model, and also suggests this API Maturity Model:
- Basic – exposes a basic API with standards, fully tested.
- Self-served – complete developer experience, available on a services portal with complete documentation and samples.
- Performant – Complies with Service Level Objectives – response-time and availability. This should be table stakes before APIs are exposed to 2-party and 3-party.
- Isolated – fully isolated, with code and data encapsulated.
- Portable –portable units built around a container technology that can be independently deployed ideally in a cloud.
The Forbes blog 2017 year of API Economy describes an API Maturity Model:
and CIO.com begins to explore a headline theme within this maturity journey: The complimentary fusion with a microservices architecture.
When Netflix began their API strategy they were still in the business of shipping DVDs. Since then of course their online global content delivery network approach has expanded exponentially, including across multiple devices as well as geographic markets.
They describe a specific philosophy blueprint for how to define such a platform:
- Embrace the Differences of the Devices
- Separate Content Gathering from Content Formatting/Delivery
- Redefine the Border Between “Client” and “Server”
- Distribute Innovation
By 2013 they describe in Deploying the API how their API had evolved to become “the Netflix API serves as an integration hub that connects our device UIs to a distributed network of data services”, and shared a series of InfoQ blogs on their ongoing API Optimization.
This blog brings us up to 2016, where Netflix describe their API as:
“The Netflix API is the “front door” to the Netflix ecosystem of microservices. As requests come from devices, the API provides the logic of composing calls to all services that are required to construct a response.
It gathers whatever information it needs from the backend services, in whatever order needed, formats and filters the data as necessary, and returns the response.”
Embrace the Differences of the Devices
The value of these philosophies is immediately evident when you consider the nature of the challenges they are seeking to address:
The key driver for this redesigned API is the fact that there are a range of differences across the 800+ device types that we support. Most APIs (including the REST API that Netflix has been using since 2008) treat these devices the same, in a generic way, to make the server-side implementations more efficient.
While effective, the problem with the OSFA approach is that its emphasis is to make it convenient for the API provider, not the API consumer.
A market explosion for Netflix has meant they’ve expanded across multiple strategic dimensions simultaneously: A shift from DVD to online platform, a massive surge in traffic through moving online, an expansion to multiple countries across the world and an enormous expansion of capacity and devices: Broadband, iPads and smartphones have all contributed to an exponential growth factor.
It’s the multiple formats of these devices that causes the challenges. Netflix wants to exploit the rich features of each but REST isn’t intended for that granularity; it achieves ubuiquity through simple operations only. Therefore to enable exploitation of these rich features for their own content strategy ambitions, they expanded their approach.
In this ProgrammableWeb guest blog Daniel Jacobson, Director of Engineering for the Netflix API, provides a much more detailed analysis explaining this rationale.
Netflix define that the OSFA approach of REST for a Digital strategy of this magnitude can prove inadequate in these terms and is thus a key insight for others planning a similar scale and mode of platform strategy.
They also share their crucial insights learned from implementing the approach, most notably the act of delegating ownership of APIs to the device teams.
As you might imagine the principle challenge that would arise from this type of approach is API complexity, with so many in use. Netflix scales to the challenge through distributing the workload across the end point development teams:
As described above, pushing some of the client code back to the servers and providing custom endpoints gives us the opportunity to distribute the API development to the UI teams. We are able to do this because the consumers of this private API are the Netflix UI and device teams. Given that the UI teams can create and modify their own adapter code (potentially without any intervention or involvement from the API team), they can be much more nimble in their development.
offering architecture benefits:
because these adapters are isolated from each other, this approach also diminishes the risk of harming other device implementations with tactical changes in their device-specific APIs.
but presenting these fundamental challenge:
Netflix describe how they address this challenge simply through always recruiting skilled engineers who can cope with these development requirements.