In this paper, the point

  • If the Iot project is seen as an IT project, IT is doomed to failure.
  • Iot projects require the participation of three distinct groups: electrical engineers, business analysts, and cloud developers.
  • Equipment onboard is an important part of the overall solution, which affects the long-term implementation of the project.
  • Testing and continuous integration can be tricky in the Internet of Things space, and they give different working principles in solutions.
  • Put some effort into high-quality pre-production or demo environments that help us accurately mimic production scenarios.

In the transition to digital, we will eventually use more connected things. The emerging field’s focus on software and digital experiences means software will be deployed in more places. The Internet of Things focuses on how assets and data can be integrated into existing infrastructure and systems. To meet customer demand for iot solutions, service providers such as Microsoft, Amazon and IBM are investing heavily in their cloud platforms. Traditional technology players such as Schneider, Mitsubishi and Siemens are also making moves to integrate into this new ecosystem.

I have been continuously involved in several iot projects over the years. I realized that there was a big gap between what the customers wanted and what the service vendors were offering. I am not suggesting that service providers should or even can solve every problem, but rather try to highlight some areas that organizations need to focus on.

The first challenge: ownership

Iot is similar to traditional enterprise integration in many ways. However, there is a very significant difference between the two. Platform integration is ultimately meant to serve IT and is almost irrelevant to business (unless failure occurs). If you’ve been involved in some integration platform implementation projects, you know what I’m talking about. Asking companies to sponsor investments to implement EAI platforms is undoubtedly challenging. Because the platform does not generate revenue, it is difficult to show how cost savings can be achieved. I’m not saying you shouldn’t do EAI, just pointing out that the requirements and advantages of a platform are IT-related, not business-related.

With the Internet of Things, the reverse is true. Once people realize all the benefits of the business, they will be more than happy to sponsor the project. At Axians IoT, we addressed this issue by hosting a business-only IoT workshop. Workshops are driven by user stories, such as pay-per-use, predictable maintenance, equipment choreography, etc. All stories are written on separate cards, along with descriptions, values and risks. The group was given a deck of cards, and discussed each card in the deck, prioritized it, and finally selected a candidate card to try. This approach has proven to be very effective in getting everyone involved and becoming the cornerstone of the product.

IT can and should be included in workshops, but IT is not the leading role. If we look at iot projects as an IT project, we are doomed to failure. It-driven iot projects rarely succeed. Iot projects need to be business aligned and business driven. Among other things, we need to have a clear understanding of how to increase revenue or cut costs. That said, IT and OT (Operation Technology) must be involved to ensure that the solution is consistent with existing operations and maintenance processes.

Second challenge: skill set

In a “normal” IT project, the various resources (that is, developers, testers, and operators) should have a good understanding of other peers’ areas. Sometimes, for example in DevOps, the same resource may even play multiple active roles.

Iot projects, on the other hand, are made up of three distinct groups, if you will, three different types of people. These groups or characters often don’t get to know the “other side”. This is not like Java and Java a decade or so ago. Net developers, but because until now we haven’t seen any benefit in trading off each other, there’s no reason to do it.

On the one hand, our electrical engineers have a deep understanding of instrumentation, sensors, resistors, PLCS, wiring and all field equipment, and they are also experts in any mechanical, vehicle or electrical component that we want to control or interact with. They used to use systems like SCADA, focused on stability, and saw Raspberry PI as just a cute little toy. Byte arrays are the only data format they understand, and they treat Float as a normal data type, when Float isn’t! They are definitely key people and there is no need to explain why they are indispensable to the project!

Another way to look at the skill set, we also have some business analysts. They have a deep understanding of the business and a deep understanding of how data is processed and used to change revenue patterns. People in that position are often the ones driving the business case, and they should. In their mind, MS Excel is just a development platform, which it is not. They like to use Power BI. Although they may not be familiar with some areas, such as machine learning, they will soon become familiar with them. While Excel, machine learning, and Power BI may seem closely related to other types of development, they are not.

Finally, let’s look at cloud developers. As much as I’d like to explain, the character is vague. In the current scenario, cloud developers refer to traditional developers who are proficient in networking, storage, and integration. If they thought the system was stable, electrical engineers would sneer. Although this role is referred to as cloud development, I believe that as long as you focus on things like Node.js, Java, or. Advanced programming platforms, such as.NET, should include device developers. If the project considers implementing microcontrollers using embedded systems and C programming, the device developer may be more closely related to the electrical engineer.

As with any other project, planning releases and tasks for the entire project requires good leadership and management. But given that the groups had completely different ideas, we needed to do more. Each group must take the initiative to get to know the others. This is especially true for cloud developers, who have trouble communicating with other groups. Cloud developers must coordinate needs from business/data analysts to electrical engineers and vice versa.

The third challenge: onboard

The “How to configure devices” question may not appear on the Trello panel during the first Sprint. When you realize the challenges of rolling out hundreds and thousands of devices, I can guarantee you’ll hit a wall on the same panel. You can and should pre-install and configure devices to meet your needs, but each device is more or less like the others, and what distinguishes them is the information needed to automatically register them. This information can be a MAC address, an IMEI ID, a SIM card ID (ICCID), a certificate, or any combination you wish. While you can order pre-configured devices with keys or certificates, this is often very expensive.

But in some cases, we don’t need a lot of onboard devices, we just need to deploy one device at a time where WiFi is used. Iot devices can be installed in buildings by technicians, or even by the people who live in them. In this case, we could consider having the device provide a WiFi hotspot where anyone can configure the device on-site using a smartphone.

Either way, onboard is an important part of device management and should be deployed separately for multiple purposes as an important part of the overall solution. In addition to the need to manage the configuration process, we may want to consider supporting a point-in-time change of cloud service provider or support for disaster recovery across data centers.

At Axians, we use microServiceBus.com. It supports Azure, AWS and IBM’s Iot, disaster recovery across data centers, and integrates with Cisco Jasper to give us out-of-the-box onboard functionality using SIM cards. It also supports whitelisting using MAC addresses and other methods.

Fourth challenge: Planning change

It is not acceptable for an enterprise to deploy a Web application without monitoring its health or patching its operating system. Companies don’t care if every workstation and laptop has updated antivirus software and firewalls.

But for some reason, this seems irrelevant to iot solutions. People seem to think that iot devices can resist all kinds of threats and run on a magical operating system that stands the test of time. That’s not the case!

Regardless of size and shape, devices and gateways are essentially small computers with operating systems in need of tinkering, constantly updated platforms and custom code, and more dependencies than we can imagine. All of these things can be changed. If someone doesn’t admit it, we can just nod politely and leave the room for good.

However, device management is not just about remotely updating and configuring new devices. Existing IT operations may use System Center or similar tools to manage servers and workstations. The help desk and NOC may use tools such as ServiceNow or JIRA to upgrade problems, discover problems, and plan releases. Whatever facility management system we choose, it must be consistent with existing processes. Once the solution is in production, no one wants to face a messy system that no one can or wants to manage.

In addition to on-board, microServiceBus.com allows us to control devices and configure updates, and even manage code. It integrates with ServiceNow, which is our tool for managing conditions, issues, and releases.

Fifth challenge: testing

Test-driven design (TDD) and continuous integration (CI) are widely used by organizations engaged in various types of application development. However, the nature and architecture of iot solutions make these testing methods unacceptable. The goal of testing is to fail quickly, and to accommodate the needs of the Internet of Things, we need to think outside of that.

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

Skill sets and isolation

As explained in the section “Second Challenge: Skill Sets,” iot projects typically consist of three separate groups with different concerns, skill sets, and, of course, toolsets. Because the tests done are completely different, the results often do not match.

Because each group is isolated from the others, unit tests and simulation models become a part of everyone’s daily life. It can be months before a developer sees a PLC for the first time. Analysts, on the other hand, continue to use hypothetical data structures until they finally see some real data. Therefore, I need to emphasize the importance of intergroup negotiation interfaces and documentation here.

location

The distributed nature of the Internet of Things does not simplify the testing process, but access to test and demonstration environments does help. Often, it is not possible for a business to create a copy of the site setup because it often requires a lot of equipment, plumbing, and wiring, making a mess of an otherwise clean office environment.

Still, take care to create a good presentation environment. Don’t worry about investing properly, make the presentation shiny and beautiful. Assume the demo is not a future test, but something to impress your stakeholders. Give a good iot demo, this is definitely the best!

On-site installation

We all want teams with good engineers to install meters, gateways, communications and cables on equipment stations or vehicles. But as the project progresses, these engineers may not continue to set up the site. This is usually taken over by someone less skilled. They lack insight into the project and the values the organization is creating.

To accommodate this, we need to provide secure installation instructions and procedures, often in multiple languages. Installation guide must be tested!

conclusion

The Internet of Things is driving a lot of human and material engagement and bringing new opportunities. But we should make sure we are business driven. Think about what we need to do, not what we can do. Give an early estimate of your earnings and make sure you are moving towards your goals.

Build partnerships and build a great team. Encourage people to share their knowledge and experiences, regardless of their roles and responsibilities. Use Standup to build collaboration between people and work with the entire team to plan projects, both long-term and short-term.

Consider realistic challenges such as onboard and assign tasks early in the project. Take a deep look at your opportunities and make sure your hardware meets the requirements. Don’t use Raspberry Pi or Arduino for proof of concept.

Plan for changes! Make sure to choose a platform that allows us to control our devices remotely and don’t treat iot devices differently from other IT devices such as servers, phones or workstations. Ensure iot devices are always in sync with the latest firmware, operating systems and other software.

reference

microServiceBus.com

MicroServiceBus.com ® manages Iot devices on Microsoft Azure, Amazon AWS, and IBM Bluemix. The platform provides services such as deployment automation, deployment, debugging, real-time tracking, and reporting.

AXIANS IoT Nordic

AXIANS IoT Nordic is dedicated to helping small and medium sized businesses in the Internet of Things space. Through partnerships with other Vinci organizations, Axians IoT Nordic offers one of the complete and most competitive end-to-end IoT services, including IoT Device Management as a Service. AXIANS IoT Nordic is part of VINCI Energies.

VINCI Energies

VINCI Energies focuses on rapidly rolling out new technologies in connectivity, performance, energy efficiency and data to support the twin transformations of digital transformation and energy transformation. VINCI Energies is one of the largest construction companies in the world.

Author’s brief introduction

Mikael Hakansson is a solution architect and IoT expert at Axians IoT Nordic. His contributions to the Iot community earned him the Microsoft Most Valuable Professional Award. He also worked on Microsoft’s Technical Advisor Program and worked closely with the Azure product team on future releases and related products. He also devoted himself to training and speaking engagements.

Your Top Five Challenges Moving in to the IoT Space