Getting to a Ubiquitous IoT Framework

KNOWLEDGE TO POWER THE BUSINESS OF IOT

NEW: IoT PLATFORM RFx TEMPLATE  - CLICK HERE

The Internet of Things has finally arrived - the hype is at maximum levels, and now it’s time to find the reality.  IoTScorecard.com is here to help. Our charter is to break down the technical concepts, challenges, and capabilities associated with creating your own IoT solutions into simple ideas for you to understand and ultimately make wise technical choices.

 

And yes, there is a real scorecard. We’ll be publishing the first draft in February 2016. This scorecard will serve as an open source template you and your organization can use to craft your own IoT framework, or use as the basis for competitive analysis and RFI/RFP efforts.

 

Our first step? We’re going to define the four core elements that make up the IoT framework. Each element of IoT requires distinct selections in middleware, developer skills, and architecture preferences, so these elements are at the highest level.  They include:

 

[1] Things

 

This is the cool stuff that consumers and customers plug into the wall and show their friends.  It might be a sensor or a light switch, or it might be a smart phone. These things might have powerful CPUs, but more likely these things might be extremely lightweight, with minimal computation other than sending a few bits over proprietary protocols.  These things innovate rapidly.  These are going to be things that you select based on best of breed function and capability for your use case.

 

Challenges of Things

 

Hardware selection: Finding the right vendor to produce at the scale and price you need that will work with all the other vendors for software, cloud and gateway

 

Authoring language:  What’s the right language to build in? Do you start with something a little heavier but widely used like Java or Node?  Or do you go hard-core out of the gate and work directly against C?

 

Dependent libraries: Rebuilding what others have already made is painful, being able to reuse libraries is key if you can find them.

 

Which protocols: Zigbee, Bluetooth, RFID, NFC, Thread, MQTT-SN, DDS, proprietary hardware manufacturer - there are so many options and so many reasons to pick different protocols.  Selecting the right one often depends on your needs like discovery, security, payload size restrictions, speed and time to invest.

 

[2] Gateways

 

One of the constraints of the things is that they are low powered and talk over things like BLe and Zigbee, these protocols today aren’t ready to be shuffled onto the internet.  That’s where the gateway comes into play.  This is the place where Bluetooth information is converted into IP/TCP based payload that can the get to the Internet. It’s the “I” in IoT, and it goes without saying the gateway space is competitive as well.  Eclipse provides open source software for gateway implementation; vendors like Dell, Intel, and Cisco are all aggressively doing cool things here for specific use cases and verticals.  Again, it's another space where you will choose multiple best of breed solutions to solve this challenge.

 

Challenges of Gateways

 

What amount of control will be put on the gateway - Its critical to your security model, your transaction speeds, and the scalability to carefully choose the level of function that runs at the gateway

 

Hardware selection: The IoT community offers high-end gateways that support many protocols out of the box to maker communities, where engineers are putting together solutions in their garages.  Do you build on something where the maker community can jump on board and invent with you or do go with a tried and true vendor who will take your pain away for a price?

 

Security: This is an area where the security model is incredibly important.  Do this well and your connected devices will be protected from outside intruders. Implement this poorly and you introduce vulnerabilities that can attack both your device ecosystem and your cloud / server infrastructure.

 

Ease of use: Gateways need to roll out and deploy in mass quantities for IoT to become a reality.  Whatever you build at this layer has to be ready to drop into the existing home / factory / retail environment and be ready to rock

 

[3] Servers

 

Once the data is ready to leave an IP enabled device the magic happens and IoT platforms can do there work.  These IoT platforms – if they do there jobs well should provide you a place secure your devices, it should provide you a place to implement all the application layer logic of previous generations, it should expose your data structures, and finally it should leap you forward onto an IoT protocol that can do publish and subscribe rather than old fashioned request response.

 

This pub sub model is critical if you want devices to immediately react to the light switch getting flipped, rather than waiting for the device to have to check whether it is turned on or off.  This definition of an IoT platform is more than just a rules engines, in place of a real application layer than shunts data into their big data offerings. This is the definition of supporting full application logic, a world where devices have a true application layer and can accomplish real things.

 

Challenges of the Server

 

Analytics: So much noise has been made about Big Data we often forget why we are even doing it.  Establishing what data behaviors you want to capture and ultimately when and how you want to understand them drives a huge amount of the server architecture.  To achieve simple storing and data review represents a different strategy than needing to process huge amounts of the data real time and issuing actionable tasks immediately

 

Security: in the cloud or in the enterprise there are a few critical elements of security that cant be ignored.  Trust, Encryption, Authentication, and Authorization.  Each element must be achieved without room for error to ensure that the valid end devices and users are talking to the right servers, with the right credentials for the right access and privileges in a manner that cannot be overheard or captured by someone else.  Simply opening endpoints fails to achieve that goal without significant platform or homegrown coding efforts

 

Scalability: A server based IoT solution has to scale to levels that we can't really predict.  The implementation of the server level has to be ready to scale horizontally where predefined limits are only due to infrastructure not architecture.  Additionally this scalability has to be achieved throughout all parts of the server side solution.  From managing message broker open connections, to http execution, to database pools

 

Performance: Server infrastructure today is full of functional proof of concepts.  The POCs may be in production for many enterprises but the represent a behavior that will create huge vulnerabilities in an IoT ecosystem.  Selecting technologies that fail to deliver rapid logic execution and transmission of messages will fail miserably at activities targeted to both user experiences where thresholds are ~250ms, blue dots on maps for position mapping in real time at high speeds, and ultimately safety requirements for protecting workers and machines from collision.

 

[4] The Enterprise

 

The enterprise is the reality of the world today. There are real systems including the newer ones like SalesForce and Sharepoint, but also systems that are much older and must interact with this new IoT world. It’s the job of the IoT platform to make it possible and simple to connect to those existing systems.  he IoT platform needs to be considerate of the constraints for performance and protocols those legacy systems are bound to  This means SOAP, SOCKETS, JARs, CORBA, and more - the real world enterprise stuff running in organizations around the world.

 

Challenges in the enterprise

 

Cloud integration: Very few vendors have really achieved integrating the cloud into their existing IT stack.  This doesn’t mean that they simply have a cloud service but rather use the cloud in collaboration with their existing IT systems of record that are most likely on-premise.  Setting up this real integration not just co-existence will push Enterprises for years to come

 

Modernization / Integration / Rewrite: To really move some systems forward they will require investment that those systems have not seen in 10 to 15 years.  Those systems may no longer have SMEs available or be running on unsupporting infrastructure. Business must decide how to integration those channels of business into their IoT

 

Scalability: Legacy systems of record were not designed to handle the scalability challenges that IoT will be throwing at them (It's going to be worse than mobile ever was). The need to make strategic decisions on how and when systems receive external IoT requests will be critical to keeping normal business operations, while also opening themselves to new possibilities.