The Pivotal Role of Business APIs in IoT Platforms: Part II

In part one of this article, we introduced the concept of business APIs and showed how they can transform your product into a platform in much the same way technical APIs do for software products. We view business and technical APIs as two parts of a single whole. By approaching them with common principles, your IoT solution can go from being a platform in theory to a platform that scales in practice.

Open product architectures are compelling because they enable simple and compelling user experiences. The Internet-connected garage door opener we mentioned in part one provides 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 product becomes 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

The Three Rs of IoT Business APIs

	Business APIs	Fragile & Niche	Resilient & Scalable
Role	What role do we play in the IoT platform? What workflows to us? What permissions do we have to take action?	Complex, negotiated case by case, driven by negotiating power (zero-sum)	Simple, standardized by category, driven by customer needs (positive sum)
Rights	What access do we have to the platform? What rights do we have to the data? What rights do others have to the data?	Complex, negotiated case by case, emphasis on walls	Simple, standardized by category, emphasis on bridges
Revenues	What rents are we able to charge? What payments are we expected to make?	Dictated by 'landlord,'rigid, hidden	Dictated by market, malleable, transparent

Source: Peer Insight Ventures

For example, an insurance company was creating a usage-based insurance offering for truck fleets. The solution required sensors to detect driving behaviors and provide feedback to drivers and dispatchers. The insurer attracted a telematics software partner to the platform by defining the opportunity for the partner as follows:

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 principles for 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.

This article was co-written by Tim Ogilvie, Founding Partner of Peer Insight Ventures, and Mark Pontarelli, Director of Corporate Strategy for a Fortune 100 high-technology company.