Build or Buy? An Executive’s Guide to IoT Platforms

While some amount of custom development is inevitable when building out an IoT environment, companies should be wary of the drawbacks of building a platform from scratch.

But despite the plethora of options available on the market, a significant number of companies are developing their own IoT platforms.

Informa recently surveyed people whose companies have deployed IoT projects at production scale. While 30% of respondents said they purchased a single off-the-shelf platform, 24% said they developed one in-house.

“What’s interesting is that what I’ve heard from speaking to vendors is that build-your-own is their number one competitor,” said Jessica Groopman, industry analyst and founding partner, Kaleido Insights. “The nature of IoT is such that, in a word, it’s heterogeneous,” Groopman said. She explained that the IoT projects make use of a plethora of sensors, all with different power, connectivity and security requirements.

While most IoT platforms were created to support such diversity, many companies “end up building their own or deploying a hybrid solution,” Groopman said.

Nomenclature further complicates matters, according to Dilip Sarangan, global research director for IoT, Frost & Sullivan. “Calling something a platform is misleading because it makes everyone think that this will manage every device and every system I put on there. Not always,” he explained. While Sarangan said that 450 to 500 vendors claim to offer an IoT platform, “only 30-40 offer true platform capabilities.” He continued: “A platform is not a one-dimensional software solution.” Conversely, it is a layered technology with support for a variety of capabilities and technology providers. Ultimately, an IoT platform is “seamlessly integrated so that data moves between operators and solution providers,” Sarangan said.

“Ultimately, the value is in the interoperability and different data sets and feeds talking to each other,” Groopman said. “That’s the core enabler for the whole downstream data value proposition: how do we connect data so we have greater visibility than we have today?”

Steve Hilton, an analyst and the president of MachNation, which runs an IoT performance test lab, frequently hears about IoT implementers interested in forging their own platform path. “One of the things we’ve found is that some place along the decision-making process, someone always says, ‘We’ll just build our own platform.’ People always think it will always be cheaper to build their own,” he said. However, that’s not necessarily the case.

To build an IoT platform, companies need development resources. “This can be a problem. You need to keep developers around to add capabilities to the platform but have enough work to keep them employed,” Sarangan said. “The cost is significant but there’s also the issue of availability of resources. There’s only a finite universe of developers out there.”

There’s also the challenge of flavor-of-the-month coding languages. “Whatever coding language you use today might become outdated, and you’ll need to completely overhaul the IoT platform or migrate to something else. Organizations aren’t necessarily thinking about these things when they develop in-house,” Sarangan said.

The good news is, even companies with diverse requirements don’t have to build an IoT platform from scratch. “If you’re a large enterprise and your solution is unique, and you want to have custom stuff and you want it built just the way you want it, it’s better to go with the building-block approach, so you put it together yourself and get exactly what you want,” Hilton said.

That building-block approach is how Hilton describes the microservices provided by hyperscale cloud vendors like Amazon Web Services, Google and Microsoft. “You can take all the microservices and stitch them together, and you would be developing an IoT platform,” he said.

Similarly, Sarangan explained that some vendors, like AT&T and IBM, may not have a complete IoT platform that they built themselves, but provide a range of interoperable capabilities through an extensive partner ecosystem. “They have all the capabilities, and while not all of them are developed in-house, they are plug-and-play. The partner ecosystem has the capabilities and solutions available, and they integrate together and create an overarching platform,” he said.

Regardless of the IoT platform companies choose, some development is inevitable. “You can use a productized platform that already has those microservices stitched together, but you still have to develop an app on top of the platform that will allow you to visualize your data.” Hilton said.

Companies should also keep in mind they don’t have to do the development themselves. “At the end of the day, especially with large corporations, there will always be some element of custom configuration. That doesn’t mean they can’t work with platform providers and their professional services arm to do that. Both constituencies are trying to fill in this gap, but the result is that many companies have this hodgepodge of solutions,” Groopman said.

There are scenarios when multiple technologies are necessary — if not advantageous — such as when companies require specialization for targeted use cases. As an example, Groopman said companies may decide to deploy GDPR software on top of an existing configuration. “When you have a complex problem like compliance, that’s a good way to not only target that issue but also have a company that helps substantiate that and that you can point to as experts in that particular area. That’s important from a liability standpoint,” she said.

Companies should be wary, however, about deploying multiple stand-alone platforms. This can become an issue when separate operating divisions or business units pursue an IoT initiative in a silo. This can create numerous management and interoperability headaches, as Hilton pointed out.

“It’s not a good idea for the overall architecture. These platforms are all built independently. The databases are all different. The way you store data in one platform will be different from another. If you want to merge data and do analysis, you’ll have to decide how you’ll combine that stuff,” he said.

For organizations that find themselves with multiple platforms, Hilton advised, “If you have to do it that way, I would prefer to use technology to create a common API layer over both platforms. Then the developer doesn’t have to develop in each platform but can develop to a common layer that talks to each of those platforms.”

Finally, Sarangan offered this advice: “You’ll always have these layers of technologies. At the end of the day, it’s about making sure that everything is open enough or has the APIs to integrate with something else.”