IoT Platform Build Versus Buy Decision Guide
Key considerations and TCO calculator
Enterprises embarking on a digital transformation are making a series of new and difficult decisions. One of these decisions that has particularly lasting implications is selecting which technology building blocks to develop in-house and which to buy from a vendor. Most would agree that the most significant building blocks are the microservices that make up IoT middleware, colloquially called an IoT platform.
MachNation’s recent research, presented here, suggests that the decision to buy rather than build is supported by quantitative and qualitative decision drivers for most enterprises. MachNation also provides an interactive total cost of ownership (TCO) calculator so enterprises can model their own build versus buy scenarios.
Enterprises and public sector organizations recognize the critical importance of an IoT platform to efficiently, securely, and economically support their IoT applications. IoT platforms provide some of the fundamental microservices to help these businesses grow and innovate.
Often an IoT data and device management platform is sometimes referred to as an IoT application enablement platform (AEP). An AEP is IoT middleware allowing a customer to ingest and process data from IoT devices and deliver the data northbound to IoT and third-party enterprise applications. It also allows customers to manage IoT devices at scale. Without this middleware, customers would have to build complex systems to manage IoT data, devices, and applications.
Enterprises and public sector organizations have choices when adopting new technology. Often, they will choose to buy technology – hardware, software, or services – from technology vendors. Other times, they will choose to build their own technology components.
In fact, this is the same question facing many organizations today when they consider an IoT platform. Is it better for an enterprise to design, build, test, and manage its own IoT data and device management platform or is it better to buy this technology from a vendor?
To help businesses make this decision, MacNation's research:
- Describes the key microservice categories of IoT data and device management platforms.
- Defines the key quantitative and qualitative factors when choosing to build or buy a data and device management platform.
- Presents 3 typical use cases (including cost comparisons) of businesses that are making the build or buy decision.
- Provides a link to an online TCO calculator that helps businesses quantify their build versus buy decision.
Dive into IoT platform capabilities
An IoT data and device management platform is comprised of a series of 6 microservice categories. Such platforms are fairly complex and can take months or years to build. If an enterprise wants to deploy an IoT solution it will need to ensure the middleware exposes these services to connected assets and applications.
Access control is the system of identity verification and permission management for all platform-connected elements including APIs; administrator or operator interfaces; devices; stored and in-transit data; and any other platform service. Access control helps ensure security of a platform and IoT solution. And, according to MachNation research, security concerns are the top reason why enterprises do not adopt IoT solutions.
Data management is defined as the capabilities within an IoT platform to ingest, store, manage, and forward data received from platform-connected assets. Data management helps users effectively move data from connected assets to middleware for processing and storage while making it available to applications.
Device management refers to the ability of a platform to provide device lifecycle management functionality including device onboarding; deployment of software and firmware updates; and configuration of devices. Device management helps users deal with the challenges of managing heterogeneous device deployments at scale.
Event processing refers to the ability of an IoT platform to execute actions or provide notifications based on administrator or operator configured rules or triggers. Event processing allows users to automate actions that will take place under certain device or application scenarios. Without this capability, enterprises would have to resort to manual inspection of data to execute actions across a set of devices or applications.
External integration is the capability of an IoT platform to interface and share data with external applications, services, or systems. IoT platforms are often connected to many enterprise applications, so having a predefined way to execute the most common integrations saves development time and money.
Monitoring is the capability of an IoT platform to trigger events, evaluate device status, and follow ingested data streams. Platform capabilities for monitoring should include both aggregated and drill-down views, and typically include operator- or administrator-facing dashboards and other graphical interfaces. Monitoring capabilities allow enterprises to evaluate and take actions on IoT platform activities.
These 6 microservices categories form the basis of data and device management platforms. And whether a business chooses to build its own platform or buy from a vendor, it will need these microservice categories.
Let’s now look at the factors that a business must consider when choosing to build or buy an IoT platform.
There are quantitative and qualitative factors that an enterprise must consider when deciding whether to build its own IoT platform or buy platform services from a vendor. Quantitative factors help enterprises estimate the total costs of building versus buying. And the qualitative factors help enterprises identify – and minimize - some of the decision-making risks.
We’ve summarized the quantitative and qualitative factors on Figure 3. While these factors are specific to the build and buy scenarios, here are some short definitions of each factor.
Figure 3: Quantitative and qualitative factors influencing the IoT platform build versus buy decision
There are numerous quantitative factors associated with technology and labor costs that impact the build versus buy decision. In the build decision, overall costs are associated with technology and labor needed to design, develop, and operate an IoT platform. In general, an enterprise will build an IoT platform that suits its particular IoT use cases, deployment size, and complexity. If an enterprise is seeking to deploy one IoT application to support a relatively small number of simple IoT devices, it will build a fairly simple IoT platform, possibly from open source components. Conversely, an enterprise deploying multiple IoT applications supporting a tremendous number of heterogeneous IoT devices will build a fairly extensive, complex IoT platform. MachNation’s TCO calculator takes into consideration these build parameters.
In the buy decision, overall costs are generally embedded in the SaaS-based pricing offered by the platform vendor, although there are sometimes relatively small, up-front, design-related labor costs.
Hardware – Hardware refers to any IT hardware that an enterprise would need to purchase to run an IoT platform, assuming the enterprise chooses an on-premises (non-cloud-based) deployment.
Infrastructure – Infrastructure refers to cloud-based compute that an enterprise would need to purchase to run an IoT platform in a third-party provider’s cloud.
SaaS – SaaS refers to the fees charged by IoT platform providers to their customers for use of the platform. These SaaS fees are typically related to the number of devices connected to the platform, the number of API calls consumed, or the number of applications deployed.
Labor – Labor refers to the human resources required to build and run an IoT platform. MachNation allocates labor into two categories: design and development labor for the initial and ongoing conceptualization and creation of an IoT solution, and operations/support labor for the ongoing maintenance of an IoT platform.
There are also numerous qualitative factors that have a material impact on a company’s IoT platform build or buy decision. The business must consider the time-to-market of an IoT solution; level of customizations required; in-house competencies; compliance and security; and expectations for ongoing support
Time-to-market – Time-to-market refers to the amount of time it takes for an enterprise to launch an IoT solution. The time-to-market is impacted by the time required to build an IoT platform or deploy IoT platform services from a vendor. This impact on launch time might put an enterprise at a disadvantage if a competitor is able to launch its IoT solutions more quickly.
Levels of customization required – Many I oT solutions require some bespoke technology. Customizations have impact on time-to-market and tend to increase risks due to the custom functionality developed and ongoing support required.
In-house, company competencies – Each company adopting an IoT solution has to determine its ability and willingness to design, develop, test, deploy, and maintain an IoT platform. Technology is not the core competency of most companies, so decisions to build an IoT platform and develop a comprehensive yet achievable product roadmap can be daunting.
Compliance and security – The ability to meet regulatory compliance and security requirements can impact the decision to use an in-house or a vendor-provided IoT platform.
Ongoing support – Each company adopting an IoT solution has to determine its willingness to provide on-going support for the IoT solution, and whether that support would be provided by an internal team, a services company, or a vendor.
How do these quantitative and qualitative factors influence enterprises’ decisions to build or buy?
Companies that lean toward building their own IoT platform tend to have very large IoT deployments, possess fairly extensive internal engineering resources, and seek to turn an IoT platform into a core competency and a differentiator. These build-leaning enterprises are more likely to offer their platform as a service to their customers rather than exclusively provide a set of productized offerings. Additionally, if the required IoT platform has a high degree of specialization, it is possible that a vendor-built platform simply will not offer the technology to satisfy bespoke requirements. This combination of factors tends to influence enterprises to consider building their own IoT platforms.
Companies that lean toward using an IoT platform from a vendor include companies with a desire to shorten time-to-market and to avoid allocating significant resources to make an IoT platform a core competency. These enterprises are more likely to use the platform to offer new services to customers. In such scenarios, the platform itself is not seen as a competitive differentiator, but rather an enabling technology that allows the enterprise to offer something new or better. Additionally, companies that tend to buy an IoT platform from a vendor are those that are comfortable using cloud services, wish to scale-up over time, believe that it will be difficult to create a best-in-class platform, and are comfortable leveraging external resources for on-going platform support.
MachNation build versus buy verdict
According to MachNation’s analysis, the majority of enterprises are best served by buying IoT platform services from a best-in-class IoT platform vendor. In fact, the most common IoT applications and use cases including telematics, remote asset management, factory automation, smart metering, and smart cities are best supported by vendor-provided platforms. It is only in rare and exceptional circumstances that an enterprise would benefit from building its own IoT platform.
Let’s look at use cases for three typical companies facing an IoT platform build versus buy decision.
Every IoT deployment is unique. And each enterprise’s decision to build an IoT platform or buy services from a vendor is unique. MachNation has used its interactive, online TCO calculator to quantify the build versus buy decisions.
A German mittelstand building specialized industrial machines wants to deploy a preventative maintenance solution to its customers to provide a higher level of service.
Connected machinery. In order to achieve this digital transformation, the firm is deploying IoT gateways that will be placed next to each machine. The gateway will be responsible for data ingestion, normalization, and analysis. Meanwhile, the cloud components will offer visualization and alerting to ensure predicted failures are addressed before they impact the business. The solution will also provide device management of the gateways. Over the next five years, the firm will be retrofitting 580 devices at client sites and delivering about 80 new deployments. In this case, the firm is small and specialized and lacks technical resources to design, develop, and operate a platform to power the new solution. Also the firm’s size and number of deployments is too small to benefit from any potential economies of scale of building its own IoT platform. The total 5-year total cost to build this IoT platform would be approximately USD1.6 million, while the cost to buy this solution from a third-party vendor would be approximately USD43,000, a 97% cost savings over 5 years.
In this particular case, both quantitative and qualitative factors suggest that the best approach is to go with an off-the-shelf IoT platform.
An Australian utility company wants to connect gas meters and delivery infrastructure to enable centralized monitoring and reduce operating costs of truck rolls.
This Australian utility company is responsible for providing gas to approximately 3 million households. Currently it spends a sizable portion of its operating budget dispatching trucks and employees to collect meter readings and check infrastructure to ensure safety and compliance. The company is looking to take advantage of low-power wide-area networks (LPWAN), smart meters, and sensors to bring new efficiency to the business by eliminating routine truck rolls. The plan involves a major upgrade to the infrastructure to allow data to flow into an IoT platform and be exposed to operations crews using web-based dashboards and iPad applications. The utility plans to retrofit existing meters with an NB-IoT connectivity module to send gas usage data to backend storage. Leveraging the same connectivity technology, the utility will also add environmental sensors to substations and gas delivery systems to make safety data available to operations and incident response teams.
Companies in industries such as oil and gas tend to start small in IoT, but the numbers of connected devices can be in the millions when it is time to ramp-up deployment.
Over the next five years, the gas utility expects to have 3.2 million smart meters deployed in 2000 gateways to monitor the grid. In this case, the middleware requirements of the platform are fairly standard and likely to be satisfied by many available platforms in the market today. While the total device count is high, each device is expected to send very small amounts of data to the cloud weekly. The utility lacks interest to make an IoT platform their core competency and is looking to build domain-specific applications that will drive down operational costs and improve safety. For this utility, the total 5-year cost to build an IoT platform would be approximately USD16.4 million, while the cost to buy a suitable platform from a third-party vendor would be approximately USD9.1 million, a 44% cost savings over 5 years.
For these reasons, the Australian gas utility is most likely to benefit from working with an IoT platform vendor rather than building an in-house platform.
A North American Tier 1 carrier seeks to build a horizontal IoT platform to offer as a service to medium and large enterprises for development, deployment, and operation of bespoke enterprise IoT solutions.
As part of its initiative to sell valuable services to enterprises, this carrier is looking for ways to offer technology that is higher than connectivity in the technology stack and also sell domain-specific solutions to its customers for connected cars, smart cities, and smart factories. With the launch of LPWAN, this carrier is expecting exponential growth – with millions of connections added each year. In this case, the carrier already has invested in operating data centers and compute infrastructure. It is also expecting to offer the platform as a service to its customers, and thus needs to create a competitively differentiated platform that will be one of its long-term core competencies. The operator is also expecting to offer platform and solution services at carrier scale, providing middleware for large enterprises’ core business functions.
Based strictly on quantitative measurements, a carrier might choose to build its own platform when the number of LPWAN devices on an IoT data and device management platform reaches approximately 3 million. However, other qualitative factors including time-to-market, requirements of fairly extensive ongoing support, and enterprise requirements for customizations are encouraging some carriers to select a vendor’s platform.
Enterprises embarking on a digital transformation are making a series of new and difficult decisions. One of these decisions that has particularly lasting implications is selecting which technology building blocks to develop in-house and which to buy from a vendor. MachNation research suggests that for most enterprises, quantitative and qualitative decision drivers point readily to the buy decision.
For further analysis, we encourage enterprises to visit MachNation’s interactive web-based TCO calculator for modeling their own IoT platform build versus buy scenarios.