Cisco Aironet Developer Platform: a stealth IoT opportunity for developers

In mid-October, Cisco announced the launch of its Aironet Developer Platform (ADP), a third-party development platform based on the Aironet 3800 series access points (AP). While there was no mention of IoT in the announcement, this is a stealth IoT opportunity. While Cisco’s Kinetic and Jasper IoT platforms reside in the cloud, ADP focuses on the edge within the enterprise. The ability to manage the “internal edge” and integrate with the Kinetic platform is significant. Throw in the DevNet developer community, a large existing base of Aironet APs, and suddenly Cisco customers are doing IoT.

Cisco ADP overview

The Cisco ADP is built around the SGMII expansion port on the Aironet 3800 series APs. Cisco wants third party developers in its DevNet community to create application modules that connect to this port. To facilitate this, Cisco has created the ADP program.

Developers are provided with a Cisco hardware development kit (HDK) prototyping board (Figure One). They add their own computer boards (e.g. Raspberry Pi, etc.) and Digi XBee radio cards (as needed) to the HDK. Code development and testing is facilitated through a sandbox provided through Cisco’s DevNet program.

ADP provides IoT opportunities at the edge

The AP’s location at the edge, and its ubiquity throughout buildings, makes it an ideal platform for extending IoT applications. One big IoT opportunity, ripe for development, is edge processing (or fog). Most IoT applications are cloud based, but not everything needs or should be done in the cloud. For example, applications that require low latency, those that are mission critical or require high security, should be processed at the edge. Data issues, such as sovereignty and security, may require local processing. A partial list of potential edge applications includes:

• Redundant control for mission critical IoT applications. If the IoT devices lose connectivity with a central server, the operation of the devices is handed off to the edge management application.
• Firmware management. A central server publishes firmware updates to the edge manager, which stores the firmware, and applies the changes when the IoT devices are not in use.
• Real time, deep learning enabled, autonomous video analytics for worker safety or security. Video cameras and optical sensors capture the activity, and computer vision analytics applications scan for suspicious behavior in real time. Processing and detecting at the edge may literally mean the difference between life and death.
• Intelligent data management.  Some IoT devices generate a lot of data. Not all data needs to be treated the same – some can be stored now for forwarding later, some are forwarded or consumed now, while others are discarded immediately. This simplifies the data load on the networks, and on the cloud services which manage the inbound data.

Cisco needs to rethink its approach for monetizing the ADP applications

Cisco’s current model of turning ADP applications into revenue will yield limited success. Upon completion of software development and testing, developers must design and build the hardware modules. Short of having their own hardware engineering capabilities, they either work with Cisco’s solution partners or find their own original design manufacturers (ODM). This is akin to Apple telling its developers to build iPhone apps, and once they do, to build the iPhone that will run their apps.

Software developers are not in the hardware business. They write and support code. Operating a hardware business is outside the resources, capabilities and risk profiles of most developers. To bring a hardware product to market, they must design, test and certify the product. Then forecast how much to build. They must import, store and manage the inventory. From there they have to market, sell and distribute the product. They have to manage returns, support warranties, and deal with product end of life (EOL) issues. In an increasingly software driven world, developers have other options to make as much or more money.

Given these realities, Cisco must take a more pragmatic approach to working with developers in its ADP program. Instead of the “one application, one custom hardware” module approach, they should take a two-prong approach. Developers will self-select into one of the two approaches.

• Semi-custom hardware modules. These pre-designed, pre-built hardware modules are built around a predefined set of use case categories (e.g. edge computing, device gateway, etc.). Developers then build applications that can be loaded onto the appropriate modules. Most of the applications will fall into this category. This approach enables rapid time to revenue but requires Cisco (or its solution partners) to build the modules and resell them to the developers.
• Custom hardware modules. These are specialized applications that require specialized and custom hardware, and collaboration with Cisco for tighter access point integration. Developers will use the current process of contracting with a Cisco solution partner after application development to design and build the hardware.

ADP is promising, but barriers must be removed

Cisco’s ADP program is a potential catalyst for IoT within the enterprise. Its large base of deployed Aironet 3800 APs, global channel reach, DevNet community, and potential integration with the Kinetic platform could allow Cisco to be a significant part of the enterprise IoT ecosystem. To do so, Cisco must remove all the barriers throughout the process – from application development to hardware development.