Get started Bring yourself up to speed with our introductory content.

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.

Architecting for change

IoT is a manifestation of today’s businesses’ digital transformation, a world that is ripe with change. For the future success of IoT, now is an important time to experiment and learn. Start planning for change by building modular, scalable architectures based on standards. I recently came across an article in Forbes. It did an excellent job of describing how architecting for change is critical. In the article, “4 Reasons Why Architecting For Change Is Critical for IoT,” the author points out that “change is no longer the exception, it’s the new normal.” Adaptable infrastructures, where components can be abstracted and modular, can evolve into support for IoT projects. This is because you can test small areas and see how they affect the business before switching everything on.

There are those who will run to a new cliff and take that leap. They trust in past experience and have faith that their technique will make them successful. Then there are those who approach the cliff a bit more judiciously. They are concerned that they may not truly know the lay of the land below. IoT is a lot like coming across a new cliff. You can make some assumptions, but there is still a lot to be learned. Knowing your limitations and planning for the unexpected is wise. Making smaller adjustments while moving into the unknown can keep you from slipping too far down a precipitous path and avoid “going in circles” like my son’s science project.

All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.

Data Center
Data Management