The Pivotal Role of Business APIs in IoT Platforms
An IoT platform needs to attract a healthy ecosystem of partners in order to scale. Firms use technical APIs to specify how the technology components will work together. Forward-thinking firms apply the same logic to create ‘Business APIs’ that are simple, transparent, and dynamic.
Open product architectures are compelling because they enable simple and compelling user experiences. The Internet-connected garage door opener we mentioned in part oneprovides utility but is more attractive in open partnership with smart home and security platforms. It even has the potential to become a platform itself.
The Adaptive Resilience of Open Architectures
In addition to improved usability, open architectures are more adaptive and resilient. Technical APIs build resilience through exercise by an increasing number and variety of connecting partners. The business side of the API builds resilience in a similar fashion through continually-evolving business collaborations.
As connected cameras become cheaper, the garage door opener platform might, for example, expand to accommodate package delivery to the garage. Your smart car might eventually open the garage door to self-park. The goal of openness isn’t to predict the future but to be in a position to participate in it.
In these open architectures, technical APIs provide the genetic code by which a productbecomes a platform. Similarly, transparent and simple Business APIs make a platform economically scalable—by mediating how contributors exchange business value. A simple way to frame the business APIs is to view them as Three Rs:
- Role
- Rights
- Revenues
ROLE
- In-vehicle experience owner. At a minimum:
- Capture real-time driving behavior through in-cab sensors
- Provide real-time feedback to drivers and dispatchers
RIGHTS
- Exclusive sensor-feedback provider for one year
- One of no more than three providers long-term
- Share all data produced by your sensors with the insurer
- Have full access to de-identified data for the platform as a whole
REVENUES
- Charge a one-time set-up fee for each vehicle
- Charge a monthly per-mile usage fee for each vehicle
- Revenue share of future vehicle apps and services
For the fleet telematics platform, the three Rs above established a principle of limited openness (e.g., “one of no more than three providers”) and full data-sharing, within boundaries (i.e., “de-identified”). It also anticipated potential revenue sharing for future apps and services.
Cloud-based physical security provider Brivo Systems is another good example. Their access control solution started by linking 1990s-era card readers and door strikes to an IP-based network. As cameras came down in price, Brivo’s open technical APIs made it easy to add cameras. Along with adding the video functionality, the business APIs set by Brivo include a per-month, per-camera subscription fee. This foresight has enabled a significant portion of Brivo’s revenue model.
“You can always choose to waive a fee later, but it’s difficult to start charging for something once people have had it free. By having open business APIs, we have customers we would have never anticipated. We’re a B2B SaaS solution, but today Amazon is driving growth on our platform because of our APIs.”
— Steve Van Till, CEO of Brivo
Four Principles for Creating Effective Business APIs
From these examples and other successful IoT platforms, we recommend four principlesfor defining effective business APIs.
1. Know Your Role in Value Creation
Are you the Convener, the firm that serves as the fulcrum and is very difficult to replace? Are you a Contributor, a firm that provides a key element, one that could be sourced, eventually, from a handful of other firms? Typically, the Convener will initiate the APIs, but that doesn’t mean a Contributor can’t assert better ones or even initiate the platform collaboration in the first place.
2. Seek Variety
Once you know your role, you need to figure out what’s missing. What contributions will be needed from other firms to make a complete IoT offering? Seek world-class components; don’t allow existing partners to contribute anything they aren’t great at. And don’t limit your appetite to firms like yours. There is a bias for Big firms to work with other Big firms, but that’s too limiting (and often too slow). Business APIs should support Big-Big, Big-Little, and Little-Little engagements
3. Focus on the Upside
Ignore your instinct to build walls and protect your turf. Instead, focus on creating win-win relationships that expose the IoT offering to network effects. If more firms are motivated to invest in your shared IoT platform and make money, it’s more able to scale
4. Win Customers in the Short-Term
Don’t worry about giving away the farm with the first iteration. Keep business APIs short-term, ideally six months at first. The most important thing is to create a successful first instance of the IoT platform and win customers. By organizing around standard, transparent APIs that spell out the Role-Rights-Revenues, each participant understands what the others need to be sustainable. It’s easier to adapt the APIs once you have a user base and a sense of the upside potential for all parties.
In the dynamic world of IoT, speed is essential. Armed with the Three Rs and these design principles, new IoT platforms can define a set of business APIs that are 88 percent right—just like the technical solution they support. That way, instead of fighting over deal terms in the conference room, you can focus on fighting for traction in the market.
If you are working on a new IoT offering—congratulations! So are lots of firms, of course, and those unseen competitors tend to dominate our thoughts. For example, it’s natural to think, “I need to really nail down the entire technical platform and business model before I let anyone see what we’re up to.” Resist that temptation. Instead, open up your development process, using a simple mechanism we call