Over the last few years, as we have built and supported IOT solutions in the market, we discovered that cost to prototype a solution was higher compared to “traditional” new technologies. There are implications to nurturing technologies where the cost to validate is high – think, will you try out a new club if it had a $200 cover charge. Right ?! Similarly, having a high cost to prototype an IOT solutions leads to many companies to postpone their IOT initiatives.
A typically IOT stack has multiple moving components – devices, device protocol, gateway, device management, cloud service, analytics, etc. If a company is in its advanced stages of having an IOT maturity model, deliberating on each choice may seem like a worthy endeavor. But when we are testing new ROI models with IOT, getting started cheaply and efficiently is the requirement of the day.
Besides the technology and vendor fragmentation that exists in the IOT marketplace – device connection, analytics, device management, solution and app development - that is solved by Oracle’s IOT Cloud Service, there are additional reasons for the expensive “cover charge”.
I will cover two key reasons in this blog post.
In a typical deployment, research staff members in an enterprise use hobbyist kits and devices to build and sell a vision about how IOT can be used in an enterprise. However, when it comes to developing real-world prototypes, these “kits” do not suffice. No CIO will fund a project to monitor its multi-million dollar cold supply chain based on sensors that cannot be deployed in the field.
What typically follows in a lengthy and an expensive task of finding the right sensors for the job. Many times, such sensors do not exist, so we have to design custom sensors for the job. Imagine that you want to go from San Francisco to Cupertino, and we have to design a custom car, since each car was designed to travel on a specific highway. While this is a highly inaccurate analogy, that is how CIOs funding the IOT projects end up feeling. “Are we the first people monitoring temperature for moving cargo”, they ask? “No, but you are moving meat, which has different cargo monitoring requirements”, reply the device vendors.
True, sensors deployed in the field will require custom work to be performed around ruggedness etc. However, the IOT implementation teams are left with two choices – either, prototype using a cheap kit and re-implement for production (which invalidated the goals of prototyping), or prototype with expensive custom-developed devices.
What is required is the ability to prototype with commercial off-the-shelf devices and have the confidence that the prototype code can be “lifted and shifted” to production-grade devices without significant redesign.
In other words, what is required is developers use the same technology stack to implement prototypes in an agile manner, and then deploy their code into production environments running on the same stack, reducing costs to deploy and risks of missing product requirements.
Many enterprise IOT use cases revolve around monitoring environmental conditions for monitoring cargo, facilities, fleet, worker etc. Most of these use cases involve tracking traditional environmental parameters such as temperature, accelerometer, light, humidity etc. So, the vendors providing device solutions for environmental monitoring should ideally provide one device and one set of APIs to monitors all these variables, right?
Well, it is not that easy, at least today with most vendors. Let’s take the example of monitoring temperature. There may be one vendor with its own stack to monitor temperature from 100-500 degree F and another vendor with its own stack and APIs to monitor between -20 to 50 degree F. This makes sense from the point of view of physics (and the hardware used). I would not use my personal thermometer (to check if I have a fever) to measure if my steak is cooked. However, from developing enterprise applications, the need to support different technology stacks and APIs to populate a Java object (based on the range of values for a field) sounds completely counter intuitive, and breaking the principles of abstraction!
There are two ways the device industry is trying to solve the problem. First, by implementing standardization (e.g., all temperature devices will expose the same API). Hmm. The other and more practical approach is vendors supporting multiple devices that span measuring a wide range of temperatures, but supporting the same API to make it easy for the software developer – nice!
At Oracle, we partner to make developing IoT solutions simpler and better.
One of the most important criteria we use to select our partners is by determining if the partner solution is built from the vantage of an enterprise software developer. For example, does the solution expose APIs in a modern language? Would it force a system integrator to learn about embedded systems, registers, and control systems, or has the vendor taken the steps to simplify the integration with enterprise apps. Does it support seamless integration with device management solutions such as the one from WindRiver or Dell?
Similarly, we promote vendors that have a broad range of devices supported by the same stack in their portfolio. Remember the example of monitoring perishable cargo? With our partners, an application developer can develop solutions that monitor temperature of perishables or molten zinc on the same stack and API.
Even better, with Oracle IOT technology partners, I can use same APIs and stack to monitor related variables such as temperature, humidity, light and motion.
The device world is evolving to support well-known design principles such as having consistent contracts between different classes such as an app and a device. We are doing our share to support partners engaged in modernizing their stack experience.
For more information about our partner ecosystem, please visit https://cloud.oracle.com/en_US/iot-asset-monitoring-cloud/partners