Limit variables like an experiment for a successful IoT strategy

IoT implementations can sometimes seem like school science projects. With so much new and unknown, there’s a lot of experimentation still being done. Like a science experiment, even the best IoT plan needs tweaking and testing to be successful.

My son’s project of building a robot provides some insight. He had dreams that it would go so fast it would beat all the others in a race. In reality, his robot went haywire and failed the minimum expectation of traversing the classroom floor. In retrospect, he learned a lot of important lessons about best practices, collaboration and testing.

My son explained, “My project didn’t exactly go as planned. I thought mine was going to be the best. But Jason and David collaborated on their robot and theirs was the winner. They were using different ball bearings, different wheels, different wiring, and their process included making several prototypes. I learned that, even after making all of their changes to my robot, all mine could do was go around in circles.”

Sound familiar? Understanding the variables and how they affect the overall architecture of a project isn’t easy. Factors you didn’t expect to influence other parts can surprise you and the results can be disastrous. That’s why it is so important to do a lot of advance planning, protect the surrounding environment, and tweak and test methodically so you can quickly and easily isolate potential problems.

If you were the science fair judge, which IoT experiment would you choose?

Photo credit: kjarrett on Visualhunt / CC BY

I’ve recently had the opportunity to work with two customers on specific IoT projects. Their approaches are very different. The first, which I characterize as big, bold and adventurous, is trying to change everything at once. It is redesigning all its applications in an attempt to come up with a comprehensive, all-in-one IoT system. I applaud its bravado, but I worry about what the company could encounter in the future with this approach, knowing that if problems arise it may struggle to isolate and address them.

The other customer has a goal of getting off its mainframe over the course of the next two years. Its operations really can’t handle any downtime, so it is approaching its move very cautiously. The company is taking its operations, function by function, and looking at changing only those pieces that will have the least impact to the business right now. It will start there, and then take what it learns from that portion and apply it to the next. I applaud its wisdom and am encouraged about the company’s future.

In my opinion, approaching large IoT projects in small chunks is a great way to test things out, customize settings and optimize the architecture for current needs. It also makes it much easier to adjust the environment in case things need to change. For instance, let’s say a new product or even a new standard comes out and illustrates that it will serve the project even more efficiently than what was originally chosen. The future is filled with innovation that businesses will want to take advantage of. If approached systematically, an IoT project can be upgraded to do so. Similarly, if there’s an issue found during the testing of one segment, issues can be addressed more easily and fixed before they propagate more widely.