In December's contribution to the IoT World community site, Ayla Networks' CEO, Dave Friedman, admits he doesn't really know what's next for the Internet of Things. In fact, nobody really does. That's why manufacturers of connected products have to build-in flexibility into their Internet of Things platforms, to easily accommodate customer's changing needs.

What does this all mean for a development team tasked with designing and supporting world-class connected products?

Here's a partial list of flexibility-increasing architectural considerations that will increase the adaptability of connected products:

  1. Design for networking agnosticism.
    What's in a thing? If it's going to be part of the Internet of Things, it probably has some sort of system architecture featuring a microcontroller unit (MCU). Most things don't have any operating system -- just a simple MCU and a few sensors. Manufacturers should be able to connect almost any MCU-based system to the Internet without being redesigned just to add networking and security. This is accomplished by removing the burden of networking stacks from the host MCU and providing a very thin bit of code that can easily be ported to the host MCU. If networking stacks are completely removed from the host MCU (e.g., if they pre-exist on the comms chips/modules), then a simple driver is all that's required to connect to the Internet. This also provides great future proofing; next year's product may use a different MCU. With this approach, that's no problem. Marketing can choose any new features it wants, and engineering can deliver it using the most appropriate component
  2. Design for data agnosticism.  
    OK, so I'm recycling terminology, but my point is similar. Just as there could be nearly any type of MCU-based architecture in a thing, there could also be just about any type of data. And you can be sure that, even across some product line, the data is going to change each year with enhancements and new iterations. Any solution that somehow requires a crystal ball for what sort of data will be leveraged (including what you name that data) will result in significant downstream redevelopment. A better solution includes integrated databases in the backend with no preset data schema. Marketing and engineering teams should be free to decide what they want devices to do and what sort of data they should collect. When they need to change the product, there should be no major engineering burden and no major customization. The manufacturers that do this best will easily out-innovate competition and get new products to market faster.
  3. Built-in feedback loops.
    This is really the home run of IoT design. Imagine easily getting products to market with any architecture or data set, as well as being able to learn on the fly as those products are used in the field. The world's premier companies -- Amazon, Apple, Google -- already do this by selling Internet services and connected products. They leverage their platforms to know which features customers like and which ones they don't. They use built-in feedback loops to design products their customers love. This will also be critical for manufacturers seeking to build IoT products. Those that can gather data, learn from their products, and adapt quickly to change them to suit their customers will be the winners. Doing this involves a complex integration of devices, databases, and business intelligence and analytics tools, but it will be crucial for responsiveness and success.
  4. Configurable cloud-based rules engine.
    The Internet of Things is truly enabled when devices can interact with other devices. Moreover, marketing is always looking for a way to make different products work better together. This is a great goal, but it's very difficult when marketing doesn't know what products are coming next, so it doesn't know how products might interact. A configurable cloud-based rules engine solves this challenge, providing the ability to modify a product's characteristics and behavior after it has been in the field, making it work with new products that are being launched. By putting the rules engine in the cloud and making it highly configurable, manufacturers can much more rapidly enable a network effect among their products.
  5. Open APIs.
    Integrations of other enterprise application or cloud platforms may not be a requirement today, but they will surely be in the future. Integrations may be unidirectional (e.g., inbound from or outbound to or bidirectional (e.g., to/from a specialized analytical engine or separate IoT cloud platforms). Either way, cloud-centric platforms provide the foundation for an open interface approach.

You can read Dave's complete blog post here: "The Internet of Things & the Great Unknown".