IoT Journey – latoga labs

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:

struggled to think big enough with their long term IoT strategy *; they usually couldn’t think past the second stage of the IoT Journey.
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.

With all the customer and partner conversations I’ve had over the past few months, it’s always good to sit back and document your vision and work to clarify it over time. In that sense, here is my vision of how IoT is a Journey to a Dynamic Ecosystem:

IoT is a Journey to a Dynamic Ecosystem…What’s Your Destination?

All the IoT related discussions I’ve had starts off with one or more types of Things.

Stage 1 is always connecting that Thing to the Internet (link level initially and eventually data communication level) and then collecting data from that Thing. I’m actually a bit amazed at how many customers, in early stage projects, have no vision of what’s beyond that! They are usually focused on just the operational data that can be captured from the thing and collecting it into a big data repository of some sort. Yet so many don’t focus on the operational aspects of all these things out there…how to efficiently scale their connection to your solution, keep them all organized, and track their state within a lifecycle. Some ignore this need all together while others try to build this operational capability (taking time away from adding true value).

Stage 2 is the logical extension of Stage 1, I have all this operational data…let’s analyze and optimize! This is where a data scientist may be employed to analyze all the collected data to understand trends. If we’re talking about Industrial Internet of Things then they are looking to predict when a Thing may fail and/or optimize it’s run time state. Even for the Internet of Other Things, there is still a need to understand the state of a thing to optimize it’s usage (like turning off the Thing when outside it’s hours of usage). Being able to allow certain people or systems to send commands to a Thing over a control plane is key in order to mitigate a failure or negative consequence of a failure. And integrating with other operational data sources in real time to broaden the operational view.

Stage 3 is where most of the more advanced customer’s I’ve talked to have their visions initially set. They know they need to expose and share the data and access to their Things with others. And this is where the excitement builds for them as this is where new revenue generation models get defined…and redefined. This is also where I start to shake my head at a few “IoT Platforms” that have come along recently that claim to help solve the monetization problem of IoT.

Monetization is the secret sauce that you need to create for your IoT Solution.

Someone else can’t do this for you. The true root of the monetization challenge is being able to support dynamic ecosystem security, a method of controlling access across the entire ecosystem of people, things, and systems in a fashion where you can programmatically change the access levels. Without that that type of security model you can’t control which different groups of users have access to different aspects of a Thing and charge for the increased value that is provided.

Stage 4 is the constantly evolving stage (not calling it an end state as this journey doesn’t end) that true visionary companies and projects seem to have, one that involves sharing of their data and Thing access across multiple 3rd parties and combining it in real time with multiple 3rd party data sources. The number of different users and groups who need access to the control plane as well as the number of data sources hooked together on the data integration plane is complex and evolves with the demands of the business.

This is my view of how IoT is a Journey…where do you agree or disagree?

(and yes, there is a platform out there that allows you to build IoT Solutions to meet every stage of this journey…but that’s another post…)

The Right IoT Architecture Enables the Journey

Clarifying My Vision of the IoT Journey