Technology leaders who work for a public company without an Internet of Things (IoT) software development today can wave goodbye to their share price on its way down.
IoT is no longer a nascent dream; having grown 22.4 per cent to $157.9bn in 2021, the market is projected to reach $4,421bn in revenue by 2030. What’s more, the amount of IoT devices present globally is predicted to almost triple from 9.7 billion in 2020 to over 29 billion in 2030.
Global brands, such as Intel, have previously made significant changes to their business to focus on IoT, and as more devices “connect” the lines of autonomous provisioning, management and monitoring will continue to blur.
Putting the hype aside, one of the most important conversations to emerge lately relates to the tactical elements of IoT. What do organisations need to address in development to make this a successful technological shift?
Without precise execution, IoT could turn into a nightmare. Devices are getting smarter, talking to each other and cutting out the unreliable human elements, which result in higher quality and greater productivity.
>See also: 4 unexpected implications arising from the Internet of Things – Gartner
Embracing and successfully managing all of the technological complexity that comes with IoT are the most important steps toward its success.
However, IoT products and services will only be as good as the software behind them. This isn’t creating a new set of problems – software is already pervasive. Instead, the growing ubiquity of IoT just magnifies the potential impact of problematic software, and this is where the trouble begins.
Obstacles in IoT development
Firstly, a large amount of IoT activity stems from industries such as manufacturing, government (smart cities) and consumer products, with some companies in these sectors suffering from a lack of proficiency in putting together such a dynamic software capability. This is coupled with the problem that engineers, especially with knowledge in connected device development, are in high demand.
The other issue is that once IoT competence is established, organisations have to figure out how to manage the software. This results in a trifecta of problems. Even traditional embedded software developers haven’t caught up with all the practices needed to develop Internet-connected applications. How will the rest of the current software industry manage?
Second, embedded software components have to interact safely with other Internet-facing components. Although an application can operate on secure subnets, access will be restricted to users of the same subnet.
That may work for some business models, but it is not a viable solution for anyone who wants to access the global internet.
As a result, developers have to understand how these connected components will interact in order to ensure security, reliability and efficiency. This is a common problem in IT, but more recent in device software development.
Third, IoT exposes developers to problems and capabilities that are, for the most part, already well known in traditional computing but the way to counter them in a connected world is still relatively uncharted territory. For example, enterprise and web developers are very familiar with the need for robust security against local and remote attacks.
The notion of input validation as a first line of defence is well accepted in connected systems today. However, IoT development expands the scope of those concerns. Embedded, device, and mobile developers need to start considering security challenges such as input validation during development.
What about security and product quality?
One of the greatest concerns in IoT is security, and how software engineers address it will play a deeper role. As devices interact with each other, businesses need to be able to securely handle the data deluge.
There have already been many data breaches where smart devices have been the target, notably Osram, which was found to have vulnerabilities in its IoT lightbulbs, potentially gifting an attacker access to a user’s network and the devices connected to it.
Security needs to be tackled at the start of the design phase, making requirement tradeoffs as needed, rather than adding as a mere ‘bolt on’. This is highly correlated to software robustness. It may take a little bit more time to design and build robust software upfront, but secure software is more reliable and easier to maintain in the long run.
A study by CAST suggests that one-third of security problems are also robustness problems, a finding that is borne out in our field experience with customers.
Despite software developers’ best intentions, management is always looking for shortcuts.
In the IoT ecosystem, first to market is a huge competitive driver, so this could mean that security, quality and dependability are sacrificed for speed to release. Poorly written software continues to be one of the greatest safety issues today.
To meet demands, avoid pitfalls and achieve success in the growing IoT marketplace, organisations need to adopt four important practices for IoT software development.
Proper code review and repetitive testing need to be a priority. Manufacturers must communicate this message to software engineering teams and call for stricter software quality measures.
The high complexity of IoT applications leaves software susceptible to security lapses and software quality failure. One bad transaction between an application, a sensor, and a hardware device can cause complete system failure. Organisations just can’t afford that.
Continuous deployment in the connected world is business as usual. Updates occur non-stop and are often pushed multiple times a day.
The quality assurance burden on the software that interacts with IoT devices is greater than ever. If the software isn’t continuously monitored and the code evaluated, failure is almost guaranteed.
Management must take responsibility for quality assurance. Any manufacturer that doesn’t have a set of analytics to track its software risk – be it reliability, security or performance – is negligent in its responsibility to customers and other stakeholders.
Management needs to lead by example and communicate the direct link between software quality and security. It’s in their best interest, too, since security vulnerabilities caused by poor coding or system architectural decisions can be some of the most expensive to correct.
In addition to measurement and analytics, a cultural shift to include education needs to occur. Developers and management collectively need to spread the word in the community about standards.
In 2015, the Object Management Group (OMG) approved a set of global standards proposed by the Consortium for IT Software Quality (CISQ) to help companies quantify and meet specific goals for software quality. Significant strides have been made since then in creating initiatives for manufacturers and IT departments to consistently measure the quality of their software.
>See also: 4 modern challenges for the Internet of Things
Sexy consumer applications (predictive coffee makers, self-driving cars etc.) and cyber attacks (such as DDoS assaults launching from refrigerators) have dominated the IoT headlines, but the deeper business value is starting to emerge.
A McKinsey report points out mature IoT systems will take the guesswork out of product development by gathering data about how products, including capital goods, actually function – and how they are used – rather than relying on customer focus groups.
That is certainly a game changer requiring development teams to reduce risks in the software they engineer now. Understanding the importance of a secure architecture foundation and insisting that developers comply with industry standards will be the first line of defence.
Sourced from Vincent Delaroche, CEO and founder, CAST
What the PSTN switch off means for IoT — Hao Shi, solutions consultant at Arkessa, part of Wireless Logic Group, discusses what the Public Switched Telephone Network (PSTN) switch off means for IoT.
How the third generation of low-code can plug the IT delivery gap — Martin Thunman, co-founder and CEO of Crosser, explains the capability of the third generation of low-code to plug the ever present IT delivery gap.