What OEMs should know about SaaS and the IoT

By Michael Lamp   |   March 1, 2023   |   Provided By Avnet Silica

OEMs developing a SaaS model need to treat the software as a product

Software as a service (SaaS) has almost become synonymous with the IoT for good reason.

Connectivity provides a constant connection between a manufacturer and a customer. A SaaS model enables that connection to generate value beyond the initial hardware sale.

Today, hardware could include “hardware as a product” or “hardware as a service,” and it is perhaps easier to differentiate between what a product is and what a service is in the context of hardware.

• Hardware as a product normally has a fixed fee and would describe anything physical that is purchased.
• Hardware as a service has an ongoing fee and could describe replaceable infrastructure, such as a server.

Buying hardware as a product means that product will never change. Leasing hardware as a service means the server may be upgraded or replaced, but the access to the server will always be available (depending on the service-level agreement, of course).

Applying this definition to software:

• Software as a product might describe an application that is bought, downloaded and installed on a device, as a one-off transaction.
• Software as a service carries with it an ongoing fee in exchange for that service.

It is important to emphasize that the ongoing fee is for the service, not the software. The software enables the business model, but what the OEM is selling should really be considered, in a wider context, a product rather than a software application.

This is the important and subtle difference that many OEMs may not appreciate when first exploring a SaaS opportunity. Any SaaS must be, for the purposes of commerce, thought of as a product line, and not just as a piece of software that generates an ongoing revenue stream.

Getting SaaS straight

Any product needs a business model. Building a model for physical, hardware-based products would draw on the experience of the OEM, their market knowledge and existing customer base. A selling price would be calculated based on the cost of development, the cost of production, the cost of supplying it to the market and the cost of support. Other costs, such as marketing, may come from a separate budget but must also be factored in.

All these costs apply to a SaaS model, but the calculation must also consider the ongoing revenue and how that can be sustained. If no product improvements are made over the lifetime of the SaaS, then the OEM may need to expect the amount a customer pays for it to go down over time. To sustain or even increase the revenue, the product offering must improve over time.

Treating SaaS as a product line means it must also have a product support team. Creating a new SaaS offering means having the resources to support that product for its entire lifecycle. Scaling a SaaS model doesn’t scale the same way a software product (like an app) will scale. The nature of SaaS means that support will likely include ongoing product development and improvement, but not with the intention of selling more services to the same customers. The ongoing development is needed to retain those customers.

This may sound daunting, but it is imperative that the customer understands the value proposition of SaaS. There are many examples of subscription services presented as SaaS that cause customers to withdraw. These are perhaps best described as feature upgrades rather than SaaS, as they enable new features on an existing product for an additional fee.

The confusion is understandable because subscription-based models presented as SaaS are becoming commonplace. Part of that confusion could be because they are enabled by the same technology. When these technologies are combined with software features, terminology can be misused.

The technology behind SaaS

The ability to monitor, change and update a device remotely is one of the enabling technologies of the IoT and it is just as important for software-based revenue models. The implementation of over-the-air (OTA) updates is not limited to SaaS or subscription models, but it is a key feature. Before the internet delivered ubiquitous connectivity, these kinds of updates were implemented with a physical connection – such as a CD-ROM, a PC and cable, or a flash drive – and were performed by engineers (or sometimes customers) in the field.

The advent of the IoT and connectivity made the process simpler for the OEM. They can now deploy updates across a wired or wireless connection. The process is often associated with bug fixing, but the emergence of SaaS has made OTA a key feature for new IoT products.

Security is not inherent with OTA. All IoT products need adequate security in place. It is too easy to implement OTA without the right security measures. When OTA is used, the need for security is even more important. This has rapidly changed the way hardware products are developed. In the recent past, the process may have been to design the product, add OTA capability and then think about how to make it secure.

Today, the design process needs to start with security, then how to implement secure OTA features, before moving to developing the hardware and its features. This is a fundamental shift that the IoT imposes and is not limited to developing a SaaS offering. But for any OEM working on a SaaS offering, securing OTA capability must be a first consideration.

Part of the reason behind ensuring OTA is secure is because it is fundamental to a SaaS offering. As described earlier, a SaaS offering has a product lifecycle, it should be subject to continuous development and improvement. These are things that can only be managed at scale through OTA and that requires an adequate level of security.

Secure device management, which includes issuing and revoking certificates for product features, is a key feature of a SaaS value proposition for both the OEM and the customer. A customer may only use some of the functionality of a product, in which case they do not want or need to pay for the features they don’t want or need. These features can be switched off using certificates issued by the OEM.

This resembles a subscription-based model, but the key difference is that the OEM continues to develop the SaaS offering even when a customer is not using it. The cost of continuous product improvement should underpin the business model. The hardware and the software combined enable the execution of that model.

Multi-tiered SaaS ecosystems

Another key differentiator for SaaS versus subscription is that the end customer is normally the target for a subscription, but a SaaS model is a better choice in a multi-tiered supply chain. An OEM may offer a SaaS solution to a customer who then builds their own solution over that. The SaaS model here is to support the intermediary, while the end customer may not be aware that there is a SaaS tier in the product they use.

If that were a subscription model, the expectation would be to add a margin and pass the cost of the subscription to the next tier, all the way to the end customer. This is a difficult and complex value chain to put in place and maintain.

For the intermediary, the value comes from having SaaS in their overall solution and billing their end customer for the value they deliver.

Data ownership in a SaaS model

The ownership of data generated in this ecosystem needs to be considered. There are examples where an entire supply chain has been halted because the ownership of data is contested. Data is an important part of a SaaS model, but data brokering is not a sustainable business model.

A better solution is to use a trusted third party to act as a data moderator. All data can be aggregated and shared with partners based on their need. Ownership would extend to using the data for the purpose of the SaaS. Sharing the data with partners would be allowed based on this understanding. Avnet’s IoTConnect® solution acceleration software suite was designed with this in mind. It provides data stewardship between partners in an ecosystem for SaaS models. Administrators can provide data based on a business need, while restricting access to data that is not necessary or may be sensitive.

Conclusion

OEMs looking to offer a SaaS solution need to consider the business model at the start. Communicating the value to the customer is essential. The messaging can often be confusing to a customer, who may see it as a subscription-based proposition.

For the OEM, security and OTA are the cost of entry for a SaaS product offering. They should also approach it like any other product development, putting in place all the resources needed to support the product throughout its lifecycle.

At its core, SaaS differs from a conventional product in one important way. The revenue generated by a physical product is likely to be the selling price, with no further revenue expected (not including a service contract). This may be financed, but the fee is fixed at the point of sale.

A SaaS product offering differs in that the customer will not pay a single, large fee up front. They are encouraged to continue to pay for the value of the SaaS, which means the SaaS needs to continue to deliver value. For a SaaS product, every day is the first day of service.

Avnet is experienced in helping customers develop SaaS solutions. Its IoTConnect solution acceleration software suite has been engineered to support a SaaS model, with the security, device management and scalability that demands. See the Avnet IoT offering or contact your Avnet representative today to learn more.

See how Avnet Silica helps OEMs and product developers accelerate their IoT success.

Follow Avnet Silica on LinkedIn

About Author

Michael Lamp

Michael Lamp is Director of Americas IoT Business Development at Avnet. Working alongside Avnet’s I...

View Bio