The Silo Challenge With The Internet Of Things (IoT)

An endless stream of new smart and connected things hit the market every day and a big challenge becomes more and more obvious: silos are forming where things should in fact be connected.

Take a smart home: Nest of Lyric thermostat. Smart CO2 and smoke detectors (maybe from Nest too), smart locks from lockitron, smart fridge from Samsung, smart lights from SmartThings, a scale from Withings, smart TV, and on and on.. not including your fitbit, your smart watch, your phones and tablets, your Sonos. They all talk to some server on the Internet. They are all part of the Internet of Things (or at least the premises of it) but talk about connectivity: They can’t even talk to each other!

What if you smart window shades could close when the thermostat says it’s too hot in the house? what if the fridge could tell you a little reminder to not snack when your scale is a bit high (arrg.. I shouldn’t have taken that extra cheese)? What if all locks or even doors could open when a high level of CO2 is detected to ventilate? What if your Sonos could sound an alarm when a fire is detected?

From a user experience, you shouldn’t have to open 15 differents apps to access your information, you should be able to have a view of your home, a view of your health, composed of every elements and piece of data from all the devices you have or interact with.

Silos are the doom of IoT. If they don’t come down, the dream will not be fulfilled.

This is exactly what the AllSeen alliance is trying to solve and I believe it is one of the most interesting challenge in IoT today. We could break it down into a few pieces:

- Device discovery standards: Enable devices to be discovered, broadcast their capabilities and interact with other in standard ways. Obviously taking into account all the security and privacy concerns that go along with those scenarios. In this world, a device could say I have an On/Off status, I have a temperature, I have an alarm with 10 levels of importance, and other parameters. It wouldn’t matter what the device is, those could apply to hundreds of different devices.

- Protocol translation: I don’t believe we will have 1 protocol to rule them all. You will have devices speaking MQTT, some XMPP, some CoAP, some DDS, some proprietary protocols. Inside those the data format may even be different. Translating those protocol to something standard either through JSON, XML or RESTFul APIs is going to be key.

- Thing beyond the devices: Not only devices will need to talk to each other but applications as well. Getting the weather, talking to my bank, looking at my Strava bike rides, getting my medical information from my doctor. The source of data is not only devices but everything you interact with.

big-data

I feel that the data silo challenge is fascinating but has the most fantastic outcome you can imagine: Personalization to the individual level. When systems will be able to make sense of all that data, when system will start to correlate the data using machine learning models in order to find patterns or find similar people, when you can start to predict. That’s when IoT will have a true meaning in our lives.

Open Source will be critical to the Internet of Things (IoT)

Opensource.svg

I am personally a fan of Open Source. The second company I was running with some good friends back in France in 2006 (www.iniflux.com) was all about it. We were playing with email servers, firewalls, file servers and everything you could think of on Open Source. We even created an appliance that was doing ISP redundancy for less than $1000 that would compete with $15K load balancers that were on the market thanks to Open Source software. Heck, most of the Internet today is run on Open Source. Apache has roughly 50% of all web servers out there, Mysql is all over the place and has 65,000 downloads a day!! Even open standards like HTTP are core to what the Internet is.

Netcraft (link here) published a study showing that Apache and Nginx make for roughly 60% of web servers out there.

But now, with the Internet of Things, it is going to need it more than ever. And here is why:

- The volumes we are talking about are unprecedented and every company out there will have a need to connect some things to other things. With that amount of companies, comes the same amount of specific use cases and needs which can lead to a more optimized customization to fulfill them.

- The diversity of standards (if any) and protocols would require a single vendor to put way too many resources to maintain them all. This is a community’s work. Lots of people need to contribute in order to be able to evolve standards, improve them, adapt them for everyone’s benefit. Cisco is saying 50 Billions devices by 2020, some say more like 20 Billions, but anyway.. it’s huge!

- Respect for privacy, security, control, scale and customization are the major benefits of Open Source and are making this a primary choice for companies. with so many connected device, being 100% sure that things are done securely, and can be fixed quickly when an issue arise is essential.

- Perennity is important.. If you are an industrial company with equipments that have a turnover of 15 or 20 years, you cannot afford to depend on a specific vendor to be there for that long. I work with many startups and they exit after a few years and most often disappear. With Open Source in hand, companies can be certain that they are in control of their destiny and will have something they can count on for years to come.

Of course Open Source has its downside in terms of skill set required and some bundles HW/SW optimization that may not exists, and this is why I am also a big fan of companies like Cloudera who propose support, training, and supporting tools to reduce complexity of management and maintenance of the underlying Open Source stack. Even large companies like HP are leveraging Open Source under their Helion umbrella (HP Helio). I find those models particularly interesting in fact as they combine the best of both worlds.

Here are some resources to look into:

The Eclipse Paho project: http://www.eclipse.org/paho/

A bit on MQTT: http://mqtt.org/

Some message brokers: http://mosquitto.org/  and http://activemq.apache.org/

What is Internet of Things (IoT) really?

Obviously the most over hyped word of the moment: IoT. The Gartner Hype Cycle 2014 shows it pretty clearly

 

gartner_2014-2

but the more I am dealing with IoT the more I realize that this word is really a garbage bag for about everything closely related to some object that can connect to something else, somehow.. It’s so vague that everything kind of falls into this category these days.. Old 15 or 20 year old companies are now IoT companies without having changed a bit what they were actually doing. I can understand it. If there is a wave, one should try to ride it.

But let’s look at it a little closer and try to give it an accurate definition. IoT: Internet of Things. That is standing as a reflection of an Internet of People I assume. So the internet today is mostly people connecting to servers or other people via a large network of interconnected networks that is accessible to all. It relies on a set of standards (the most famous being TCP/IP, HTTP, etc) to enable open communications between people and servers.

If we translate that to “Things”, we should define the Internet of Things as a large network of interconnected networks where Things communicate with other Things. There should really be no people involved. So why is Wearables in the Internet of Things? why is a connected Oil rigs in the Internet of Things? Why is your connected car in the Internet of Things? I am really starting to think that they are not. They are just a new wave of connected and potentially smart devices but still connect to a person at some point.

Your FitBit will connect to you phone, which will send data to a server so you can review, track, compete with other people. That’s not an internet of thing, that’s a thing connected to the internet.

In an internet of things, things are the actors. A device connects to another device of server which sends something back automatically, and the device may take action based on that response. If the interaction starts to become more complex, to the point where an entire life cycle can happen between devices, then we are in the internet of things.

What could that look like. Imagine your self-driving car..

Self-driving car

It detects some high level of vibration in one of the wheel. It connects to a server that can identify the cause and likelihood of failure thanks to all the other cars that had the same issue, and roughly in the same condition of use (some predictive models would apply). The verdict is clear: that wheel will have an issue in the next 2 to 4 weeks. The server let’s your car know. The car checks your schedule and maps it to potential repair slots in a garage near your work. It books an appointment during your work hours. That day, it takes you to work, then leave to go the appointment (on it’s own!! it’s a self-driving car!). It gets the repair, and comes back to pick you up at the end of your day. Potentially the repair was made by a robot in the garage. No humans involved, maybe except for the validation of payments ;-)

There we are talking about an internet of things. The car could talk to the garage, thanks to standard protocols, it could analyze issue based on other data point from other things, it could read your agenda and self drive thanks to sensors and plenty of other information given by other Things it didn’t know about that were connected and intelligently inform the car’s decisions.

I think we will truly achieve the Internet of Things, when things can autonomously interact between each other to the benefit of people. In the meantime, it’s a lot hypes, but don’t get me wrong, it has tons of value and that’s why I’m so passionate about it.

Internet of Things Landscape Beyond Things

As I am looking at the different facets of the Internet of Things, I realize that there are a million ways to slice and dice it’s different components. It is clearly a complex ecosystem and the amount of buzz generated around IoT is a clear demonstration of that fact. Similarly to my previous post around the IoT protocols stack I wanted to attempt to draft a view of the landscape but this time beyond the things and communication layers. I wanted to have a focus around the application side of things where I believe most of the value lays. So let’s show that. Here is my view of the IoT landscape and I’ll talk about the different bricks right after:

Image

 

Following a strong message pitched by Salesforce.com around the fact that behind every device is a customer, this is where I started: The connected customers on the left.

It all starts with connected devices, and you will find in there chip manufacturing, and connection protocols like Bluetooth, wifi, etc.. Not the focus of this blog but definitely important. The following bucket to look at is to the right of the connected devices: The communication buckets where you will find a lot of the protocols I described in my previous post. But there is where the interesting part begins.

DATA END POINTS. I have create a bucket for this as it many players actually only play there. The features found in this bucket are around pub/sub architectures and protocols for high volume communications for millions of devices, but also intelligence. I believe that intelligence at the Data end point level is extremely important as it will avoid the overload of totally useless information coming from the devices. The end point should be capable of creating a first level of triage of the information coming in: What’s expected? what’s normal? what is NOT normal? The end point should be able to generate alerts in near real-time to the customer support bucket (below) or to applications through the development platform (above). The better at assessing data in real time, the less dumb data will be added to the data store (to the right). Another important element of the data end point, is authentication and security that can be handle there. The end point should be able to know (authenticate) the devices and customers behind the devices as well as make sure that communication are secured (encrypted) and no one can send data or commands in a malicious way.

BIG DATA STORE. This is where the raw data will go in. I do believe that if the data end point has done its job right, not everything needs to be stored. Maybe only aggregate data is store like “the device has been on for 24hours” instead of thousands of “I’m alive” data points. That said, there is a balance between pure raw data and not enough data. The value of a big data store is to be able to query and work through that data via learning algorithms, and pattern detection algorithms. Those algorithms love to have tons of data as they become better and better with it. There again, the intelligence is key to determine predictive outcomes. This is the holy grail of the industrial internet by the way: predicting when things are going to fail in order to reduce unplanned maintenance. You will notice that the diagram connects the big data store to applications (above) and customer support (below) as this data is key to provide insights to agents in call centers (of in the field) as well as provide input, bi-directionally, to applications. Maintenance history, upgrades, etc, should feed back from specialized application into the big data store as well.

ASSET MANAGEMENT. There is data generated by the devices, but there is data about the devices. A device needs to come online for the first time and declare itself through a provisioning system before it can send data. The devices have owners, serial numbers, a history of their creation, maybe even all the way to the CAD designs and specifications. It is made of parts that can be assembled, upgraded, etc. It has a cost, to sell of to built. It can be optimized in a way or another. All that information about customers’ assets will be kept in that system. An advanced asset management and asset optimization system is a critical piece of the landscape where a lot of value can be generated.

DEVELOPMENT PLATFORM. On top of the data and assets, can sit a development platform. From simple cloud based OS to full fledge application development platform, you will find a entire ecosystem just in that bucket. Anything that allows others to create applications linked to the data or to connect to the device (via the data end points bus). Those platform have to provide all the brick of security, authentication, licensing and provisioning management, workflows and business processed, etc.

CUSTOM APPLICATIONS. Either through an ecosystem of ISV or by customers themselves, applications can be developed on top of the platform to consume data and manipulate / control devices. Applications can be virtualized for certain industries (smart home, smart cities, industrial internet, healthcare, etc..) each having their own market to go after. I think there is still a lot of work and opportunities in that bucket where most certain 70% of the value chain will reside at some point. Note that those applications will connect back to the customer via the web, through any type of device (mobile, tablet, desktop) including the device itself.

CUSTOMER SERVICE AND SUPPORT. Going back to the bottom part of the diagram, you may know that I am a big fan of the service use case of the IoT. I believe it is one of the big opportunities that this trend provides: to offers outstanding customer service thanks to the data generated by connected devices. From intelligent routing of alerts coming from the data end points in real time, or from the data store asynchronously, to knowledge management, entitlements, RMA, and then multi-channel communication with the customer, a good customer service operation will empower agents by tying device data and related intelligence to the customers themselves.

FIELD SERVICE. Interestingly the field service use case is very big in customer support. It’s not because machines are connected that there is never a need to physically go see them. Repairs, maintenance, refill, physical upgrades, all those still have to be performed by a field technician. I think what has changed is that now that devices are connected, the field service technician can be much more efficient than before. Accessing the entire history of the devices, its usage and failure patterns, knowing everything about the parts needed and planning for preventive maintenance are all very cost effective tasks that will drive significant returns to companies using connected devices. I even think that it will drive more field service needs than before, but it will be done is a more efficient way. Instead of incurring a huge cost of a failure, a company can have a much smaller cost of more efficient technicians.

SALES AND MARKETING PROCESSES. Even if support is definitely a big use case for IoT, the extension into sales and marketing is undeniable. A cartridge is low in your printer: that’s a lead. You don’t drive your car very much: that’s a lead. You go in certain places very often: that’s a lead. Opportunities are all over the place for up-sell, cross-sell, proactive marketing, in-context marketing, etc. I think this will come a bit later as the infrastructure need to be in place for it to be realized fully but it will come and it will be big.

ANALYTICS & INSIGHTS. I could not have a diagram without this piece. Understanding the data through smart visualization is critical to efficient decision making. Seeing trends and patterns and being able to generate reports and dashboards conveniently for every level of the organization are constant asked from any company I talk to. Bringing together, Device data, support data and sales data into single dashboard has tremendous power that many company will take advantage of.

I hope that this view of the IoT landscape brings some clarity to some of you. I would love to get feedback about it to make it better. Why I built this initially was to understand where we wanted to play as a company and I think it has been helpful to segment the market and the players we have been talking to.

Enjoy and share.

 

 

The Internet of Things Protocol stack – from sensors to business value

There is no doubt that we are entering a new era.. An era that will change the world more than the Internet did 15/20 years ago. This era is the Internet of Things, or IoT. John Chambers, the CEO of Cisco is going on a crusade to tell the world about and is driving many conversation with his potential $19T in economical impact from efficiency gains to pure economical growth. I have personally never seen a number that big, and it’s starting today.

Granted connecting objects is not something new, we have had connected machine for more than 15 years. Axeda, one of the leading solution providers in connected machine, has been in business since 2001! What has changed is that now: 1- it’s becoming cheap to connect machines to the internet. Very cheap. Hardware is affordable and even open source: Raspberry Pi announced it’s 2M unit sales in November 2013! Knowing that they compete with Arduino, Mbed and others, I am astounded by the cheer volume of supposedly “hardware enthusiasts”. This not a hobbyist game anymore, it’s everywhere. I personally played around with an Mbed and a Spark Core using Cloud based backend from Xively. It’s so easy, it amazed me and got my imagination going on a few projects.

But where is the catch? I’ll be honest: Standardization. The IoT landscape is a mess! Too many protocols, too many wannabe standards, too many revolutions. It will calm down and consolidate but for now it’s creating more mess with every new device that comes out on the market.

I’ve decided to give a try at describing that mess through a protocol stack that I’m hoping to be useful for others. My goal was not to be exhaustive in anyway, I don’t even think it’s possible. But I hope that I captured the most common protocols that people encounter on in a day in the life of an guy in IoT.

IoT protocols stack

 

[Note: This diagram has been updated based on comments and feedback received since Jan 29]

What I found important in this stack was to add a Business value layer, because what’s the point of connecting devices if in the end there is no business value.

Some will find similarities with the ISO stack (Link layer, Transport, Session, etc..) and there are some, but I wasn’t particularly trying to map to it. It just happens that the ISO stack is foundational to the Internet and as a consequence in the DNA of everything Internet.

Protocols you will find in there:

Connectivity layer: What kind of physical connectors you can find. RJ45 (the physical connector, usually for Ethernet), PLC, RS-232, RS-485, ModBus, USB (as a connector type, not the communication protocol), SPI, ODB2 (in Cars), and Wireless (no connector!). You will sometimes find gateways that will convert any of those physical connectors into wireless.

Link Protocol: How do those device actually send the data. Ethernet 802.3, Wifi 802.11a/b/g/n, BlueTooth, BLE, Dash 7, ZigBee, RFid, GSM, 6LoWPAN, 802.14.5e. The last two are really focused on the IoT use case. I have put ZigBee here only but I am well aware that ZigBee covers a large portion of the entire stack. To avoid too many redundancy, I had to make a decision on where it would fit best.

Transport: IPv4 and IPv6. I also added 6LoWPAN and RPL despite the fact that they are both based on Ipv6. The IPv6 has been a long time coming and was supposed to be adopted by everyone 10 years ago, but now with the projection of having 50 Billions devices connected in 2020 (according to Gartner), we have to go to IPv6! What was interesting is that I haven’t found much of anything beside the IP protocol out there which proves the dominance it has acquired through the rise of the Internet.

Session / Communication: This section is an interesting bunch with a lot of new protocols that have been build for super high volumes and large networks of things. The most famous right now is MQTT, a subscribe and publish protocol that is used by Facebook for its mobile app. You will also find CoAP (kind of a REST Based protocol but much more efficient than its HTTP counterpart), DDS, XMPP and AMQP that are all well suited for IoT and will map different use cases. One will still find older protocols like FTP, Telnet and SSH, but even though they are working very well, they are resource intensive, power intensive, and do not fit well with the low power, unreliable bandwidth of the IoT realm.

Data Aggregation / Processing: This is where it gets really interesting. When device send data, lots of data, you need an end point to do something with it. Be it processing it in real time (with Storm), but at minimum getting the data and sending it somewhere else at very large scale, which Kafka is a great example of. Other solution exists like RapidMQ, Scribe, Plume, Luxun, Fluentd (although more on the translation to JSON side)

Data Storage / Retrieval: The realm of Big Data backend and NoSQL solutions. Hadoop, HBase, MongoDB and Cassandra dominate the field. There are others, like the google AppEngine,  but I may add them later on if they start appearing more in IoT use cases.

Business Model: This is a new addition fro, the initial post. This layer is trying to capture the fact that business value and business processes always rely on an underlying business model. Open or Closed, Integrated or platform, direct sales or indirect, cloud based or on-premise (or private cloud), on-demand pricing, etc.

Business Value: I’ve split it in three. One part if around Device Management, the provisioning, registration, firmware management, remote access, but also the product and asset structure as well as Security (tremendously important, especially as we just went through the first massive Connected Devices attack just a couple of weeks ago. The second section is to highlight the birth or transformation of Service for smart devices, Marketing for owners of smart devices and the impact on manufacturing those smart devices.  Finally, the analytics piece shows how much technology could be applied to the data gathered, With machine learning algorithms, data mining, and all the insights and visualization that can be derived from it.

With such a representation of the most common protocols, the need for consolidation really becomes obvious, the IoT cannot keep going with so many protocols if the dream of having any devices talk to other devices in a fully connected world wants to come true. In any case, it’s fascinating.

Building your App in the Cloud or not is a business decision better made early…

Having worked at Salesforce.com for several years now, I have been immersed in the world of Cloud and I have witnessed first hand how an enterprise class application could scale in such an environment. It has been fascinating all along and that experience has been truly put to use as I have been dealing with ISV (Independent Software Vendors) partners in the last few months for Salesforce.

As I talk to CEOs and CTOs of those ISV who want to work with us, the question of the architectural choice they have made comes every single time: Is your offering Cloud based or on-premise? Is it truly Multi-tenant or more of a shared hosted solution? What I came to realize through those conversations is that the choice those companies made early on is definitely something that is very impactful to their business and that once it is made, it is extremely hard to change. That difficulty can have huge consequences on your ability to scale, your ability to innovate, your ability to lead and even your ability to exit!

As a consequence, I would like to write a piece of advice, or at least a bit of guidance to all  of you, early entrepreneurs, who are thinking about building software: Should you go Cloud or not, and if so what type of Cloud offering should you pursue? What I hope from this post is that you will realize that this decision should not be taken lightly and should definitely not be an afterthought, but above all, it should be made early.

Cloud, Multi-tenant, On-premise.. What is all this??

Let’s quickly recap what Cloud, multi-tenant or on-premise mean (I’ll stay very high level here):

  • A Cloud application does not live on your customers infrastructure(usually). The customer connects to your application via a basic Web Browser. Most of the time those solutions are sold on a subscription basis.
  • An On-Premise solution usually lives on the customers infrastructure. The customer owns servers and potentially spaces in data centers to run the software. Usually those solutions are sold through a one time license and some yearly maintenance fee that gives access to upgrades and patches.

Cloud based solution can have (roughly) two flavors: Hosted or Multi-tenant.

  • A Hosted solution usually means that despite the fact that the customer accesses your solution through the Web and has a subscription service they pay, the application lives in its own container called “instance”. Each customer has its own instance with its own engine and Database. There is literally a virtual separation between each customers instance.
  • A multi-tenant solution usually means that the Database as well as the application is unique and access for each customer is controlled through some meta-data layer. Everything is shared and security is ensured at the query level rather than at the virtual infrastructure level.

So what are the implications of each of those solutions for an early startup?

Let’s assume you start with an on-premise solution

Let’s say you start on-premise (just like many of the enterprise solution providers out there started many years ago). Here is how your business will go:

  1. Your sales representative will be compensated on the licenses they sell. Usually those up-front licensing costs are high: the customer “Buys” the software. That’s usually pretty attractive when you start because:
  2. You get more upfront cash which can fuel your growth
  3. You don’t have to have a security conversation with your customers which will ask where the data resides and how secure it is, etc.. so sells are a bit easier.
  4. You will have happy sales guys because they will get high bonuses

So it all starts pretty well, but then as your business grows, this is what happens:

Your customers are not upgrading which means you have to maintain several versions of your software which drives your support and development costs up. You have to release patches for several versions and you have to train your support crew on several versions.. this could quickly become a nightmare. So to reduce this cost you revert to a fewer releases which drives down your ability to innovate fast, react to new market trends and lead ahead of the competition as you cannot afford to manage too many versions and at the same time and you cannot force your customers to upgrade.

You realize that the new hardware that a customer has added to their machine is causing issue so you have to handle hardware specific patches, or your virtual machine provider has released a patch that is also causing problems with your application but that only happened for a subset of your customers..

Your sales guys constantly have find new customers because your revenue is dependent mostly on this one-time licensing fee that you charge and if they don’t get new deals they don’t get the nice bonuses they use to have.

Some prospects are worried about the seasonality of their business and how quickly they can scale up and down and also deploy mobile apps.. Well with your on-premise solutions Mobile access is not that simple as your customers need to open their Firewalls to give access to the servers that host your App. And by the way, they also need to integrate with other solutions, and some of them are Cloud based, so do you offer some kind of standardized platform where partners can create those hooks?

As a business owner you look at this, you look at your costs, you look at the market trend and the growth of the Cloud and you decide that it’s time for you to start providing a Cloud based solution..

This is where things really start breaking.

From on-premise to cloud: the equivalent of a pivot, but harder!

Your sales force has been trained to pitch the value of on-premise versus cloud and all your customers have bought into this vision. Now you have to go tell them that Cloud is better! If you don’t, you will have to manage yet another version of your offering and increase your costs even more.

Of course, you don’t want to re-code everything as multi-tenant, it would take you months if not years as the architecture are fundamentally different. Your developers would be frustrated and your customers may not have the patience. You may even loose the precious lead you had on your competition in terms of product features. Multi-tenant is a no-go, so you decided to go hosted.

Going hosted is easy enough, you basically take the on-premise App you have, hopefully you had a web browser front-end instead of a desktop application (if not you are really in trouble), and you put it in your own infrastructure.. You change your licensing model to be subscription based and you are good to go: You have a nice Cloud bases solution.

Well it’s not that easy..

First, you still had to spend an ungodly amount of cash to build or rent your datacenter in the meantime though. You will have to swallow that as the revenue of a Cloud based offering are also much more progressive, no big one-time fee here.

Second, your sales guys won’t like this and will always sell the on-premise version if they can. They will come in a deal leading with Cloud, start pitching and revert to the on-premise every time. Maybe you mitigate this with two different sales units, one for Cloud solutions and one for on-premise, but you will rapidly enter a turf war internally. I have seen this over and over. That means your cloud solutions will have a very hard time picking up.

The maintenance of the hosted solution is also going to be the same nightmare as it was for the on-premise.. When you upgrade you have to go through each instance individually and upgrade them one by one. The problem is that your customers will always tell you that it’s not a good time and it takes weeks if not months to upgrade everyone. By that time you may already have a new version available.

Going hosted you haven’t solved anything.. you made it worth. You have sales that don’t want to sell your stuff, you have support and maintenance nightmares and you lost your innovative power.

Let’s continue the story. You are resourceful and with your strong leadership you have been able to change the culture of your company and everyone is behind you now.. your hosted solution has taken off and you have an opportunity to exit with one of the leading firm in the Cloud.

Looking at an exit? Tough luck…

The company (fictional) that is looking at your business was attracted by you because of your Cloud offering. Their IT is looking at your architecture and realized that you host many instances of your solution.. There is nothing multi-tenant and basically the integration story will be almost impossible as everything will have to be re-written to be compatible with multi-tenant. Your support organization will be cut drastically as well as you have way to many and all your customer base will have to be migrated as heavy costs which means there is a good chance of attrition. How do you think the acquiring company will feel about your business? not so sexy anymore. Of course it can happen, but what multiple will you get?

So what about multi-tenant then?

Very quickly, multi-tenant means you ARE Cloud. You develop 1 version, you maintain 1 version, you upgrade everyone at once, you are nimble and innovative and you will crush your competition. Your sales will be trained on 1 message, compensated on 1 model, and customers will grow with you, making you a very good target for a beautiful exit.

One element often forgotten about hosted versus multi-tenant is that a hosted solution will never be able to grow your customer base in the SMB market if that is what you plan on doing (either as a start or if you want to go down market later). Spinning up a new instance and maintaining that instance for a customer with 2 seats will definitely not be worth the time. A Multi-tenant architecture on the other hand, doesn’t care if you are 1 or 10,000, the cost of deploying and maintaining each customer comes down to a cost per seat (roughly). Small business are subject to the same level of quality and care as the big customers and your overall level of service is much higher.

Summary: choose wisely and choose early… (my advice: choose multi-tenant!)

I took a very simplistic approach to the story, but hopefully you now have a better understanding of what it could mean to start with the wrong architecture. Going on-premise may be simple, or even hosted to start with, but the consequences on the growth of your company, the costs, the innovation and flexibility you will have to adapt to a rapidly changing market and the ability to exit may be really impacted and depending on your business strategy and goals could even be detrimental.

I truly believe in the Cloud but I also truly believe in multi-tenant. There are many different ways to architect your solution with some hybrid solutions but always keep in mind the maintenance costs they will generate assuming customers will not upgrade if they can avoid it.. Some customers are very sensitive to cloud solutions like in the banking industry but salesforce has proven that with the right security, the right message and with enough benefits, even the banks will follow you.

How difficult is it to build hardware for a startup?

My gosh… I’ve always been a software guy but since I’m young I like to build things. It start with lego, even “Mecano” (ok I’m not that young anymore and I have played with Mecanos as a kid..) and last year I though it would be really fun to try to build some kind of hardware and see how that works. I was inspired by the Makers movement and all the Arduino’s projects and thought to myself: I can do this!  So I did..

Here was the plan:

  1. Find a good idea (I had one already)
  2. Build a prototype
  3. Put it on Kickstarter and raise some funds
  4. Sell it and potentially expand the product line

That sounded about right.. My initial goal was to learn about hardware making and prototyping.. All those Kickstarter projects were pretty fascinating and the advent of 3D printing allows you to go pretty far. Hoping to help (or warn) other entrepreneurs about going that route, here is what happened:

The context:

I watch TV and I have kids.. I can never watch a good action or sci-fi movie without the risk of waking up the kids or annoying my neighbors so I wanted a device to wirelessly transmit sound from my TV to my hears. There are plenty of them out there already but without going into the details, they SUCK! The only ones that work very well are the Sennheiser, which will charge you an arm for them and force you into a single type of headset.. I have my headsets, some nice Bose QC15 that work perfectly and I wanted to use those instead.

The Idea:

Have a very small device on which I could plug my own headset to listen to sound of my TV wirelessly.

The constraints:

Wirelessly transmitting sound is not easy when combined with TV: It cannot suffer any delays (latency) between the image and the sound otherwise it would look like a horrible foreign language dubbing! And it cannot use too much bandwidth because there are a lot of interference with existing wifi networks already. Wifi is out, Bluetooth is out, regular RF is out and the only really good solution I found was the KLEER chip (also used by the heigh end Sennheiser system)

The easy part:

Get a name: Soundora.com was available..

Get a quick website up and running www.soundora.com

Get a Logo (I have some really talented friends there)

soundora_high_transparent

Get a twitter account, an email and a facebook page

Barely any costs there.

Building the first prototype:

I found who built the KLEER chip, and luckily they were in the Silicon Valley so it was easy to contact them. They send me all the specs of the chips some reference designs, and all the surrounding hardware.. That’s where the nightmare started.. My electrical engineering skills are about 15 years old and those chips cannot be soldered by hand.. Half of the surrounding component I had no clue what they were, some had different options I didn’t understand either..

So after a bit of research I reached out to companies that built prototypes for you. They know their stuff! Great conversation but the initial investment was at minimum around $10K to have a single prototype, and probably around $50K to get a first low volume batch.. No go.

The fun part is that I initially did some designs without hardware constraints, and had a good idea of what it would look like, but as soon as you had: Battery, Connectors, and all the other stuff around the device, you realize the magic there is behind building something as small as an iPod Shuffle is! Man, Apple is good.. So all my initial designs went to the toilet. I had to start from the inside and work my way out.

So what I did is buy a couple of low end Sennheiser headset (which use the same KLEER chip as the high end) and tore them appart to get the circuit inside small box I bought at Frys.. What I didn’t expect is that buying components such as a 3.5mm jack plug, flat batteries, etc.. would take so much time. I also didn’t realize that they were never exactly the right format, the right length, etc.. Amazon doesn’t have a lot of it so delivery would always take 5 to 7 days to realize it wasn’t what I needed.. In the end I did get all my part and a bit of soldering later I had a working device:

First prototype of Soundora

When I say working, it’s partly true.. The button in the front for power and Volume were iphone buttons that are way to thin to work with.. I could really change the volume or turn on and off the device.. I had to design my own box (which was fun).

Here you go a few days later I had my 3D model:

3D model or Soundora receiver

I used Shapeways.com which had the cheapest 3D printing service I found and got me the box. Very existing but another few weeks to get it..

1 IMG_8225  3D Printed receiver open

At this stage I realized that 3D printed is not really there yet.. Anything under 0.8mm space will be filled.. That means that my button did NOT work (again!!). I was starting to get frustrated with this, buttons are really tough to design, it’s just amazing!

Anyway, I got the circuit in and kicked it up

2 IMG_8228 2 IMG_8233

huh… That orange light wasn’t supposed to show up that much.. I even had build a little deflection inside the box to let the light come out through a small hole.. Interesting surprise.

Anyway, it worked! I had to have another batch of buttons from Shapeways to solve my issued and it now looks pretty cool.

I also found another battery pack that is flatter and should work as well so I was in good shape. I’ll have to do another box (thinner) though.

But here is the main issue: Ripping out a Sennheiser device for my personal use is fine but I can’t really do that commercially so I still needed to find a way to get my own circuit built.

Getting my own:

By total chance, I stumbled upon a small business that is building systems around KLEER for different customers.. They built the Dr Dre wireless headset.. so I contacted them. Very cool guys and they had small circuits (smaller than sennheiser) that I could use to get an even better device. Very exciting.

But then we talked about production batches.. The Kleer chips are bought by batches of 2000, pretty expensive per unit cost.. Building the box (transmitter and receiver) would probably cost about $4K to $5K to get the mold and get it ready for a batch. That doesn’t even count for prototyping the real thing..

Basically I need to raise at least $100 to $150K to get the project going, and it would mean a sales price in the $150 to $200 a system (1 transmitter + 1 receiver). You can add more receivers (up to 4 total) but it cost about as much as the transmitter.. So the economics barely work for small batches of a few hundred devices. They would for larger batches though.

I am currently kind of stuck there, I don’t want to do a Kickstarter project with a prototype that doesn’t look like a finished product (maybe I’m wrong in thinking that by the way), and I am honestly having a hard time with anything touching the electronic of the device.. I’m a software guy. Also I want to keep it lean as much as possible but I realize that the lean startup model of software doesn’t apply that well in the hardware world.

Other things to consider:

Even if I get to a point where I do have a working prototype there are other things to think about when building a hardware startup:

  • This one is a wireless device and requires certifications about the lack of danger of the transmitted wave. There are a bunch of certs you need to get for the device that will add costs to the project.
  • Designs should be turned from the current Patent pending status to a real patent in some way even though it’s using only existing technologies.
  • Packaging is another good one: Getting a nice box that is cheap but looks good and conveys the experience you want to provide to the users
  • Power plug adapters for distribution in Europe and North america, including different voltage and frequency
  • Documentation in several language
  • Distribution network: initially direct as done through kickstarter, but eventually through stores like Best Buys and others. This will hit the margins.
  • Shipping costs between China (or wherever the device is manufactured) and the destination
  • Maintenance and defects management: Some devices won’t work, some users will be unhappy, and you have to determine who is responsible, what’s your return policy, what costs can be projected around those issues, including shipping..
  • Potential competition from Sennheiser or others.. Roku came out with a similar device and even though it is limited to one listener and to sources from the ROKU box, it still is a fairly tough competition.
  • Unsold devices: If you create batches of devices, what if you don’t sell them all?
  • Delays in production and shipping..
  • etc..

Conclusion

I didn’t give up. I still would like to get to a point where I have a very nice looking prototype, but when I compare this to any of the software project I have done, I realize that it is a totally different world.. Fun in a way as you can touch and feel something, and as you are effectively building something, but the initial cost and technical skills required are really larger.

I have learned so much along the way and I now look at all those Kickstarter project in owe of the complexity I lived through. Some of those guys are really good.

I hope you you entrepreneurs out there will find value in this experience and maybe make you think a bit more before going into hardware. I also welcome any help from someone with electrical engineering, manufacturing, hardware engineering to get this through a first finish line ;-)

Cheers, and keep making stuff!