IT: The Gatekeeper of your IoT Deployment

In the early days of an IoT project most of the team is focused on figuring out what data they want to collect and overcoming the constant stream of technical challenges. What is often not well understood is that after all the other problems are solved, the fate of the project is contingent on the approval of one of the most important yet overlooked stakeholder: IT.  However, the role of this stakeholder often depends on the nature of the project. In the case of OEMs and ODMs that make connected products, the IT group has little influence and can be a roadblock at times. Another case are those companies that implement an IoT solution and have IoT devices on the corporate network where IT group wields a lot of power. They have the power to say “no” and must be brought to the table early. Then there are those companies, typically in manufacturing, where IT has taken the lead on an IoT project and is not only the gatekeeper but also holds the purse strings.

No matter which category your company falls into, your IT group should have a very important seat at the table but your strategy will change depending on its role in the project. One may think that a viable strategy is to go around IT and avoid the issue all together. This can be done using VLANs to isolate the IoT devices on the corporate network or by using cellular (4G/5G) gateways to bypass the corporate network all together. This is viable approach during the proof of concept phase of a project where the interest is to prove technical feasibility. However, this creates data silos and can be a barrier to unlocking the power of IoT. For example in health care IT, IoT medical equipment needs to talk to other clinical systems (medical record systems, imaging systems, etc.). Isolating the IoT devices as a means to get around the headache of dealing with the IT department can seriously harm your big data strategy because you need to connect to disparate enterprise IT and clinical systems. You can’t do that if you create a silo. This means that you simply can’t go around IT and expect your healthcare device designs to go anywhere.

Before you engage the IT group you have to understand where they are coming from. The default “no” response if often due to your IoT project posing additional network threats and attack vectors, additional load, and increased complexity without adding more budget or tools to combat these issues. Once you understand that your request represents more work for them, you have made the first step in the right direction. The next steps to address objections and encourage engagement need to include the following:

1   A champion from a revenue generating group – when someone like a product manager or a leader from the service organization understands and represents the positive business impact and ROI, it can help the IT folks understand the benefits of aligning with your interests.

2   Security – You will need to be able to talk about security and how your IoT devices will be protected while on the network. White papers, security architecture, and penetration testing are all tools available to help you

3   Trust – the IT side will need to understand exactly what your products do. You will need to demonstrate that there is high availability and the training necessary for them to be able to properly operate and manage the solution.

The last element that is critical to success is your ability to speak their language. You must be fluent in IT. I was recently at a customer meeting discussing the importance of remote update capabilities. We were able to see eye-to-eye on the expectations of the user experience once I started talking in context of technologies that he could relate to like Active Directory and Windows Update Service. People in the IT department are already familiar with concepts of asset management when those assets are computers running Windows. As long as the IoT asset management platform products are built using a similar paradigm, the IT side of the house will be immediately familiar with the new tools.

In conclusion, embrace the fact that IT must have a seat at the table, and invite them early. Pull in the stakeholders from the product / business unit, arm yourself with a security story, and learn how to speak IT’s language to address their concerns. Once this has been done then the real work can begin.