Your Top Five Challenges Moving in to the IoT Space

When you’re on the path towards a digital transformation, you end up with more connected … things. This newfound focus on software and digital experiences means that deploying software into more places. Integrating assets and data into existing infrastructure and systems are arguably what IoT is all about. Vendors such as Microsoft, Amazon and IBM are making massive investments in their respective cloud platform to align with their customers’ demands for IoT-type solutions. Traditional technology vendors such as Schneider, Mitsubishi and Siemens are also on their toes, eager to be part of the new ecosystem.

I’ve been involved in many IoT projects over the years and have come to realize that there is a big gap between what customers need and what these vendors provide. Not saying they should or even could solve all problems, but I’ll try to emphasize some of the areas organizations need focusing on.

Challenge #1 - Ownership

In many aspects IoT is similar to traditional enterprise integration. There is however one very significant difference. At the end of the day, integration platform serves IT and has little to no interest for the business (until it fails). If you have ever been part of a project to implement an integration platform, you know what I’m talking about. Asking the business to sponsor an investment to implement an EAI platform is challenging since it doesn’t generate revenue, which makes you struggle to show how it saves costs. I’m not saying you shouldn’t do EAI, just pointing out the fact that the requirements and benefits for such platform relates to IT, -not the business.

With IoT it’s completely reversed. – The business has all the benefits, and should they come to realize this, -they will be more than happy to sponsor the project. At Axians IoT we address this through an IoT workshop which is only targeting the business. It is driven from user stories such as Pay per use, Predictable maintenance, Equipment orchestration and so forth. All stories are written on cards along with descriptions, values and risks. The group works through the deck of cards and discusses each card in the group, prioritizes them and at the end selects one to be the candidate for a pilot. This has proven to be very effective and makes everyone involved, and has become one of the cornerstones of our offerings.

IT can and should be represented in such workshops, but only as a minority. - If you think of your IoT project as an IT project you are doomed to fail. Very few, if any IoT project driven from IT has ever succeeded. IoT projects needs to be aligned and driven from the business, with a clear vision of how to increase revenue or cut costs. That being said, IT and OT must be involved to affirm the solutions aligns with existing operation and maintenance procedures.

Challenge #2 - Skillset

“Normal” IT projects, are often composed of resources (developers, testers and operation) with a good understanding of their colleague’s respective field. Sometimes the same resource might even be active in more than one role such as DevOps.

IoT projects, on the other hand, are composed of three distinctly different groups, one might even go so far as saying different kind of people. These groups or roles have often gone out of their way NOT to learn about “the other side”. Not due to disrespect as with Java and .Net developers a decade ago, but rather that there haven’t been any benefits until now, and therefore no reason to reach out.

On one side, we have Electrical Engineers with in-depth knowledge about everything onsite such as meters, sensors, resistors, PLC’s, cabling etc. They are also experts in whatever machinery, vehicle or electrical components we’re trying to control or interact with. They are used to systems like SCADA, focus on stability and look at a Raspberry PI as a cute little toy. The only data format they know of is an array of bytes and think of a Float as a normal datatype (it is not!). They are hard-core and there is no need to explain why these guys are essential to the project!

On the opposite side of the skillset we have the Business Analysts with intimate knowledge about the business and with the vision of what to do with the data and how to use it to transform the revenue model. Men and women in this position are often the ones driving the business case, - AND SO THEY SHOULD BE. They think of MS Excel as a developing platform (it so isn’t) and love Power BI. If they are not already, - they will soon become skilled in fields like Machine Learning. But although Excel, ML and Power BI might seem closely related to other type of development, it really isn’t.

Which brings us to the Cloud Developer. I could not make this role more vague if I tried, but in this context, it refers to traditional developers well versed in the web, storage, and integration space. When these people think their systems are stable, the engineers sarcastically snores and raise their eyebrows in contempt. Despite the name, I’d also include the Device developer in this group as long as we are talking about high level programing platforms such as Node.js, Java or .Net. Should the project look into implementing microcontrollers using embedded systems and C programing, the Device developer might be closer related to the engineering group.

As with any project, great leadership and management is required for planning releases and tasks throughout the projects. But with a group of such fundamentally different mindsets you need more. Each role has to reach out to learn about the others. This is especially true for the Cloud Developer as they are somewhat stuck in between the others. The Cloud Developer will have to mediate requirements from the Business/Data analysts to the engineers and vice-versa.

Challenge #3 - Onboarding

“How to provision devices” will likely not be on your Trello board for the first sprint. But I can promise you’ll be banging your head against the same board when you come to realize the challenge of rolling out hundreds or even thousands of devices. You can (and should) order devices pre-installed and configured to meet your requirements, but each device will be more or less identical to the others. Whatever sets them apart is what you need to use to automatically register the device. This might be a MAC address, an IMEI id, a SIM card id (ICCID), a certificate or preferably a combination. Although you could order devices pre-configured with keys or certificates, this tend to be very costly.

In some scenarios however, you don’t need to on-board batches of devices, but rather one at the time at site using local wi-fi. An example could be where IoT devices are installed by a technician in a building or perhaps even by resident of a house. In such cases, you might consider letting your device expose a wi-fi hot-spot enabling anyone on-site provision the device using a smartphone.

Either way, on-boarding is a vital part of Device Management, and should for many purposes be kept separate, but consider it an important part of your overall solution. If not just for the sake of managing your own provisioning process, you might also want to change your cloud provider at some point in time or support disaster recovery from one data center to another.

At Axians we use microServiceBus.com as it supports both Azure-, AWS- and IBM IoT. It supports disaster recovery from one data center to another, and integrates with Cisco Jasper which gives us an out-of-the box on-boarding using SIM cards. It also supports whitelists using MAC address along with some other options.

Challenge #4 - Plan for Change

No enterprise would think it would be acceptable to deploy a web application without monitoring its health or not patching its operating system. Nor would they be indifferent to whether or not every workstation and laptop had an updated anti-virus protection software and firewall.

Still, for some reason, this does not seem relevant to IoT solutions. People appear to think IoT devices are resilient to all threats and run on some magical operating system that will stand the test of time. – Let me assure you it’s not!

Devices and gateways, regardless of its size and shape, are essentially small computers. -Small computers with an operating system that needs patching, an ever-updated platform and custom code with more dependencies you could ever imagine. All of which are subjects to change. -If anyone tells you differently, nod politely, leave the room and don’t look back.

But Device Management is much more than remote updates and provisioning of new devices. Your existing IT-operation probably use System Center or equivalent tools to manage servers and workstations. Your service-desk and NOC likely use tools like ServiceNow or JIRA to escalate issues, identify problems and plan releases. Whatever Device Management system you choose must align with existing processes. Once the solution is in production, you don’t want to find yourself with a bastard, that no one can nor want to manage.

Apart from on-boarding, - microServiceBus.com allows you to control your devices and provision updates and even manage code. It integrates with ServiceNow which is the tool we use for managing issues, problems and releases.

Challenge #5 - Testing

Test-Driven Design (TDD) and Continuous Integration (CI) are widely used throughout organizations doing any kind application development. However, the nature and architecture of IoT solutions makes such test methodologies difficult to embrace. The goal is to fail fast, and you’ll need think a little outside the box to adapt the process to your needs.

To better explain these challenges, I’ve broken them down into three categories:

Skillset & isolation

As explained in the SKILLSET section above, IoT projects are often composed of at least three groups working in isolation from the others, with different focus, skillset and of course toolsets. Testing is done very differently hence the results can often not be aligned.

As each group is alienated from the others, unit-tests and simulated mock-ups becomes part of everyone’s everyday life. A developer can go months before seeing a PLC for the first time, while the analysts keeps working with assumed data structures until they finally see some real data. I would therefor emphasize the importance of negotiating and documenting interfaces between each group.

Location

The distributed nature of IoT does not simplify the process, but having access to a test- and demo environment is very helpful. It is often not possible to create a replica of the site setup as this would often require heavy machinery, pipes and wires that some may find disturbing in the otherwise clean office space.

Nevertheless, put your heart and soul in to creating an awesome demo environment. Spare no expenses and don’t forget to make it beautiful and shiny. If not for testing purposes but to impress your stakeholders. Nothing beats a good IoT demo!

On-site installation

Hopefully you’ve got great engineers on your team, eagerly occupied to assemble meters, gateways, communications and cabling for your pilot site or vehicle. But these engineers will probably not be the ones to continue setting up sites as your project is rolling out. This is usually done by someone less skilled and with zero insight to the project and with no understanding of the values you’re creating.

To accommodate this, you’ll need to have bullet-prof installation guidelines and procedures, often in more than one language. These guidelines have to be tested! 

Conclusion

Internet of Things drives lots of engagement and brings new opportunities. But make sure to drive from the perspective of the business. -Think in terms of what you need to do, rather than what you can do. Estimate the gains early on and make sure to stay on target.

Create partnerships and assemble a great team. Encourage people to share their knowledge and experience, regardless of role and responsibility. Enable everyone to collaborate with daily stand-ups, and plan the project, both long- and short term, together with the whole team.

Respect challenges such as on-boarding, and consider assigning the task early on in the project. Investigate your opportunities and make sure hardware aligns with your requirements. – don't use devices such as Raspberry Pi’s or Arduino’s for your proof-of-concept.

PLAN FOR CHANGE! Make sure to select a platform allowing you to remotely control your devices, and don’t treat them differently then other IT equipment such as servers, phones or workstations. Make sure they are always up-to-date with latest firmware, OS and other software.

References

microServiceBus.com

microServiceBus.com® provides IoT Device Management for Microsoft Azure, Amazon AWS and IBM Bluemix. The platform provides services such as Deployment Automation, Device Provisioning, Debugging, Live tracking and reports.

AXIANS IoT Nordic

AXIANS IoT Nordic is in the business of enabling and assisting mid- to large sized organizations in the IoT space. Through our offerings and partnership with other Vinci organizations, Axians IoT Nordic provide a complete and most competitive end-to-end IoT offer, including IoT Device Management as a service. AXIANS IoT Nordic is part of VINCI Energies.

VINCI Energies

VINCI Energies focuses on connections, performance, energy efficiency and data to fast-track the rollout of new technologies and support two major changes: the digital transformation and the energy transition. VINCI Energies is one of the biggest construction companies in the world.

About the Author

Mikael Håkansson works as a solutions architect and IoT specialist at Axians IoT Nordic. His commitment to the community has earned him the Microsoft Most Valuable Professional Award, and he is also part of the Microsoft Technical Advisor Program working closely with the Azure product teams for future releases and related products. He is also committed to training and various speaking engagements for technologies such as IoT, Web, Security and Integration.