IoT model canvas by thethings.iO

IoT model canvas by thethings.iO

After working on hundreds of IoT projects at thethings.iO, always there are common strategies and steps.  We truly believe on a lean approach for IoT, in order to reduce the time to market. That means, that we needed a document or a visual element to describe the IoT project value proposition, the hardware, the payloads, protocols and actors of the project, among others.

This is the reason why at thethings.iO we built our own framework to initialise the work with our customers. On this post we would like to share with you our methodology when we start working on an Internet of Things project, the IoT model canvas.

We get inspired by the Business Model Canvas, which was originally designed by Alexander Osterwalder, back in 2008. The Business Model Canvas is almost a standar-de-facto when anyone creates a product. This is the reason why we created a model canvas for Internet of Things projects, to facilitate the way to design the vision of a connected product at thethings.iO.

IoT model canvas

The IoT model canvas, as the Business Model Canvas has 9 elements. Together, all the elements have to create the vision of the IoT product with coherence, in order, to potencially start making the first working prototypes.

This is the description of the 9 elements of the canvas:

• Actors: who are the actors of the project? what do they need to do with the devices and the data? what restrictions should they have?
  • Example: do you have technicians moving around the country to install or repair your devices? Do you want to offer them a dashboard? Does your marketing director want to access to a dashboard with some specific KPIs? I’m sure that most of the answers are YES! List all the actors of your workflow here.

• Data: what is the data that you want to work with? It’s not even important what are the data sensors that you collect on your hardware (that’s on the left side of the canvas), it’s more about what is the complete set of data that you need to make sense on your use case. List this set of data.
  • Example: do you need data from the weather forecast everywhere where you install your devices? maybe you don’t have a specific sense on the hardware but you can generate it with mathematical operations through the data that you have from other sensors? Make sure that you have a clear vision of the data you want to play with.

• Hardware: what is the hardware and technology that you are going to use? what are the sensors? is there any actuator? what is the technology you are going to use to connect this hardware to the Internet? Is there any other satellite hardware? Does the hardware accept bidirectional communication? And firmware upgrade?

• Apps/Dashboards: what type of applications would consume the Data generated by the Hardware?What type of devices (mobile phones, desktop, TV screens, …) will showcase the Data collected? Remember, for us an App is an interface that shows a subset of data or subset of devices.
  • Example: imagine that you have technicians around the city that move with an Android phone. Is there any Android App available for them? Is there any Operational insights dashboard for the Operations Director? Maybe there is an App for the final customer?

• Protocols: what are the communication protocols available from your hardware? Are you using CoAP with IPv6? or you only have available TCP with TLS? It’s important to understand the protocols accepted in order to think about the interaction between the Apps/Dashboards and the Hardware, and of course the Data.

• Cloud Code: are you going to need any business logic algorithms on the top of the data? Do you need to trigger alarms (e.g. SMS sent) when data gets into specific threshold? Do you need a daily report with the data generated by a machine? Do you need to apply predictive maintenance or machine learning algorithms for your devices? This is the space to define all the requirements of what you need in terms of algorithms on the top of the data.

• Payloads: what are the messages that your Hardware can send? Does your Hardware support JSON, 12 hexadecimal bytes, 512 bytes in 0 and 1, … As defined previously, we know the Hardware, the communication Protocols and the Data. Now it’s time to understand the type of payloads you can send from the Hardware and the restrictions we will have to convert them into Data.

• Value Proposition: Probably the most important area. What is the core value proposition of your product? List in bullet points the WHY.

• 3rd party integrations: Most of the time connected Products are more interesting when they are connected with 3rd party services, such as your ERP, SMS system, among other. List here all the 3rd party integrations that are needed in order to build your Value Proposition with of your Hardware, Data and Apps.

This is how we work at thethings.iO when a customer wants to work with us and they miss some parts of their system. We try to help companies to accelerate the time to market not only with our technology but with our know-how and contacts.

Feel free to contact us in order to start working with you and make sense of the Internet of Things applied in your industry.