How Much Functionality Should be Embedded in the Product and How Much in the Cloud?
The article, How Smart, Connected Products Are Transforming Competition, published in the November 2014 issue of Harvard Business Review (HBR), identifies the ten strategic choices manufacturers must make to capitalize on IoT opportunities.
Co-Author and PTC CEO Jim Heppelmann explains the second strategic choice, how much functionality should be embedded in the product and how much in the cloud, and provides a recommendation to get started.
So keep in mind that connectivity serves a dual purpose. It gives us the ability to move information back and forth, but it also gives us a new domain in which to create capabilities. So, for example, as an engineer, given a requirement from the customer I really have four different ways or four different engineering domains in which I can create capabilities.
1. I could use a mechanical approach, and add mechanical features and characteristics.
2. I could use an electrical or electronic approach, and add circuit boards, and those capabilities.
3. I could use software, and put the software in the product as embedded software.
4. Or I could use software in the cloud, and put the software in the data center.
And across these four domains, a product can work pretty seamlessly. So you're going to find yourself asking the question for this feature or this capability, which of those four domains should I use? And we think that there are some pretty important variables that you ought to think about when evaluating which software should be embedded vs. in the cloud.
First of all, what's the requirement for availability or response time? For example, an anti-lock breaking algorithm inside an automobile probably should be running in the automobile just in case the availability or the response time of the network is a problem.
You might also think of the nature of the interface, the human machine interface to the capability. It's pretty easy to think that rather than struggle to deploy mechanical human machine interfaces, I could easily move the user control of this device up into the cloud, and then deploy it in the rich environment of a smart phone.
I'd also give some thought to the nature of the problem we're trying to solve or the solution that we're trying to create. If you're running big data analytics looking for patterns and data coming from many different products, almost by definition you're going to have to put that capability up in the cloud.
And then finally, I think you have to think about the type of connectivity that your thing is going to have to the internet. This is important because some of those connectivity means are essentially free, and others vary with the volume of data being moved back and forth. And I think you want to be careful not to create a big expense around data transmission, moving data up to the cloud if it was practical actually to process that data in algorithms in the product.
So here's the recommendation we would have which is to realize that you have these four domains in which to deliver new capabilities. But then step back and realize that there is an inevitable progression in value and innovation from hardware to software that's going on. And secondarily realize that within software innovation, there's an inevitable progression from software that's embedded in the product up to software that's running in the cloud. So we encourage you to spend some time think about what is the right balance of mechanical, electronic, embedded, and cloud software that's going to produce the most value in your product and in your business.