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\u2019s Kinetic and Jasper IoT platforms reside in the cloud, ADP focuses on the edge within the enterprise. The ability to manage the \u201cinternal edge\u201d 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.\nCisco ADP overview\nThe 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.\nDevelopers 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)\u00a0to the HDK. Code development and testing is facilitated through a sandbox provided through Cisco\u2019s DevNet program.\nADP provides IoT opportunities at the edge\nThe AP\u2019s 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:\n\nRedundant 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.\nFirmware 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.\nReal 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.\nIntelligent data management. \u00a0Some IoT devices generate a lot of data. Not all data needs to be treated the same \u2013 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.\n\nCisco needs to rethink its approach for monetizing the ADP applications\nCisco\u2019s 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\u2019s 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.\nSoftware 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.\nGiven these realities, Cisco must take a more pragmatic approach to working with developers in its ADP program. Instead of the \u201cone application, one custom hardware\u201d module approach, they should take a two-prong approach. Developers will self-select into one of the two approaches.\n\nSemi-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.\nCustom 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.\n\nADP is promising, but barriers must be removed\nCisco\u2019s 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 \u2013 from application development to hardware development.