This file type includes high-resolution graphics and schematics when applicable.
Vincent Perrier, CMO, MicroEJ
As the Internet of Things (IoT) evolves, it’s likely that it will experience mutations similar to what was once achieved by more mature IT markets. The IoT implies a new client computing domain, aside the historical personal computer and the more recent mobile computing domain (smartphones and tablets).
By “client computing,” we mean computers that connect to internet servers. PCs (desktops, laptops, notebooks, etc.) have evolved to become clients of servers in the internet as we know them today, with advanced wired and wireless connectivity and powerful operating systems (OSs) and browsers. Cell phones have also mutated into smartphones and tablets, offering new experiences to users with the notion of “apps.”
It’s interesting to highlight three important aspects of this mutation:
• The OS (and not the hardware) has become the true computing platform and consumer reference for its capacity to run compatible apps—I have a “Windows PC” or an “Android smartphone.”
• The access to the Internet has become critical to the point of becoming an extension of the client OS itself, whether through a web browser or an application store app attached to the OS.
• Each client has come up with a personalized way of interacting with the internet and had mutual influences on each other – smartphones started with mobile websites and PC-like browsers, and then came apps and online stores, which were eventually generalized back on PCs.
PCs and mobile clients had their “ancestors”—software platforms upon which current OSs have been built. If we apply this to IoT client computing, it’s likely that the IoT will be built on its own roots in embedded computing.
Also, the way consumer IoT devices connect and interact with the internet is only partially defined at this time, and it’s likely that it will derive from the PC and mobile domains, with its own adaptations of browsers, apps, and stores. Eventually, IoT may invent a new way of “doing” the internet that may make its way back into mobile and PCs.
IoT Requires New Application Platforms
Let’s look at the first element that constitutes an internet client computing domain: the OS.
The PC and mobile Internet have converged on two platforms, each with one proprietary and one open-source operating system:
• Microsoft Windows and open-source Linux for the PC
• Apple iOS and Google Android for the mobile
This convergence can be simply explained by the need to provide an open software platform that hosts and runs several third-party applications upon which an entire ecosystem can be built. The ubiquity of those platforms ensures that deploying apps (and the web services they enable) can be achieved on a large scale and be economically profitable. Thus, the ecosystem can turn into a true industry involving semiconductor vendors, original equipment manufacturers (OEMs), OS vendors, app developers, service providers, end users, etc.
To become a true industry with similar deployment and profitability levels, the IoT has to converge around OSs offering open software application platforms and enabling third-party app developers.
Let’s look now at the second element that constitutes an Internet client computing domain: the internet client app.
The internet client app refers to the way the client accesses web content and services. This is an internet web browser on a PC and a store app on a mobile client.
Here again, the IoT has to offer a way to easily access dedicated web services to connected devices, whether they are used by a human (interactive devices with some human-machine interfaces) or not (machine-to-machine interfaces). This is the area where we can expect innovative technologies and new user experiences.
A Make vs. Buy Decision
As explored in a blog of ours, the technical and economic characteristics of the IoT make it impossible for existing PC or mobile solutions to be replicated and used as-is on diverse embedded computers with strong cost, power, and resource constraints.
This blog also explains that legacy technologies of the embedded world, real-time operating systems (RTOSs) in particular, are also too limited to ensure the advent of an IoT industry with large app developer communities and open application platforms.
Many companies have looked at the problem and came to the same conclusion. Device manufacturers face the traditional dilemma of a converging market that’s not yet stabilized or hasn’t seen the emergence of a dominant player: “Should I make or buy my IoT device platform?”
The make option can be achieved from two starting points: from scratch (developing everything) or from selected embedded legacy components. Re-developing everything from scratch would be the equivalent of creating something like Google Android (although it was built upon Linux and the Java technology). This may be affordable by companies the size of Google, but may not guarantee any profitability for an OEM whose business isn’t correlated to the number of internet connections in the world.
One could start from some existing embedded legacy software components (drivers, RTOS, C compilers, C libraries, and stacks) and build its own device platform on top of it. Though possible, it may require an investment of probably 100 person-years with highly skilled engineers. Again, profitability could be achieved if the OEM’s intent is to extend the reach of its embedded platform to the entire IoT domain. It seems difficult to justify a good return on investment (ROI) for the product families of a single OEM.
The buy option implies that an existing vendor offers a solution that corresponds to what the OEM is looking for, and that using its solution results in significant ROI compared to the make option. The vendor’s offer makes all the difference in the world, so the question may not be “make or buy,” but “make, buy from X, buy from Y, or buy from Z.” As such, analysis should be conducted on a case-by-case basis with a vendor that offers a reasonable solution.
That said, it’s generally simpler to project ROI for the buy option as the uncertainties of an existing solution are far fewer than a yet-to-exist one. So even following a make vs. buy analysis, one should consider that the buy option is much less likely to inflate beyond an early projection.
Conclusion
In the end, the make vs. buy decision comes down to the goals, resources, risk tolerance, and potential market of a given OEM. If one wishes to become the Android or Linux of IoT, where the product may occupy most or all IoT devices, there’s merit to choosing make. However, one must have deep pockets and little fear of failure when going that route.
Though restricted to our own products, the make vs. buy analysis we run with customers has put buy out in front for every single customer we’ve talked to who hasn’t already invested in their own platform (and it’s typically the best choice for those that have, given future competition from a dominant vendor). Because a vendor platform’s profitability doesn’t depend on a single line of products, said vendors can charge much less than the development costs of producing a platform from scratch or even with legacy components (which, as we saw, saves less money than one would hope).
And there’s more to the decision than cost. Time-to-market drops when large portions of your project have already been developed, tested, and validated elsewhere. Existing platforms include features that may otherwise not have been within the budget, adding value to final products. Moreover, unforeseen bottlenecks vanish when working with an integration team that has overcome a given problem beforehand. If your vendor is transparent and reputable, it’s simply not worth the pain to reinvent the wheel.
