The Right IoT Architecture Enables the Journey

Over the past year and a half, there have been two common themes running through all the IoT related discussions I’ve had with companies big and small. From global corporations crafting a product or operational IoT strategy to small device manufacturers who knew they needed an IoT strategy to compete in the market to startups creating the latest connected service offering, everyone:

1. struggled to think big enough with their long term IoT strategy *; they usually couldn’t think past the second stage of the IoT Journey.
2. lacked a general IoT solution architecture as a reference point **; they struggled to understand and compare all the vendors who latched onto the IoT buzzword or called themselves an IoT Platform…

Almost a year ago I presented my vision of the IoT Journey based upon all the customer and partner conversations I had spanning multiple IoT verticals like Automotive, Transportation, Industrial Manufacturing, Oil and Gas, Service Sector, and Smart Cities. What I quickly realized was that IoT architecture decisions were being made based on the early stages of the journey and the people building IoT solutions were going to face an expensive re-architecture in the future to fully realize the potential of IoT.

For the past few months I have used my recent down time to document the IoT Solution architecture that I saw as common across all those discussions and used that as my own IoT Solution Reference Architecture to understand the breadth and depth of the various IoT solutions and vendors in the market. After using both the Journey and the Solution Reference Architecture in all my most recent conversations (and being prodded by a few trusted colleagues), I realized I was way overdue in sharing both in more detail.

The generic high level picture most often shown for an IoT Solution looks like this:

Things connecting into the cloud and sending up their data for storage and analytics with users accessing the Solution via either a web or mobile app (or both) to view data send commands down to the thing. When in reality there is much more complexity that is needed and most IoT Solution (should) have an underlying architecture like this:

First, this is a general IoT Solution Architecture, each specific IoT Solution will be more detailed and varied due to business problem specifics, industry regulations, and technical specifics. There is a lot of details, even at an abstracted level like this, and my next few posts will be exploring those details.  I have also converted this architecture diagram into a solution functionality map which I have been using to compare different vendor offerings, I’ll be posting more on that in the future as well.

How does this compare to your IoT Solution reference architecture?  This project spun out of some IoT consulting work that I have been doing with various clients recently.  Please reach out to discuss any IoT projects you may have going on and how I may be able to help you.

 

* A friend of mine at GE Digital even mentioned that when they do their training courses around IoT for executives, they purposely don’t have them try to think about IoT for their product/offering.  It’s hard for anyone who focuses on the current state of their business to quickly jump to think out of that box.

** Even to this day I’m surprised by how many charts of the IoT Marketplace that you find that don’t differentiate between companies using IoT within their offerings versus those providing the IoT building block technologies used to build those prior offerings.