10 IoT Development Best Practices For Success
IoT development is more than embedded programming and more than enterprise application building. Here are 10 things you should know about building applications that require a bit of everything.
![](https://eu-images.contentstack.com/v3/assets/blt69509c9116440be8/blt94c5666be1ecc9b1/64cb405b38b460f5dc2c81ad/Image_1.png?width=700&auto=webp&quality=80&disable=upscale)
The Internet of Things means different things to different companies. One of the things it means to most organizations, though, is that a pile of new development is in order. For some of those companies, even those that have been developing in-house software for years, it also means learning a new way of building software.
Here's the issue: For many years, enterprise software development and embedded control development have been two entirely separate disciplines. The tools are different, the platforms are very different, and it's rare to find a professional who's competent in both. The IoT changes all of that.
IoT development spans traditional enterprise programming and embedded systems programming in ways that we've only rarely seen before. The remote devices and sensors have to be programmed to both do their jobs and pass data back to the enterprise core for analysis and subsequent action. The core itself must support applications that can accept and process vast quantities of data in predictable, real-time fashion. Then there are the layers in between.
[See 14 Ways IoT Will Change Big Data and Business Forever.]
The bottom line is that successful IoT development has to incorporate the best practices and processes of both embedded control and enterprise software development. And the person managing the development has to do something truly difficult -- bring two distinct and quite different cultures together on a single team.
Succeeding at this bifurcated development effort requires figuring out which techniques are best used where and getting a handle on a handful of key points. Some of the points will shift with the seasons as new platforms come into the field or new vulnerabilities are found. Others are evergreen, defining good development practices regardless of the specific project. In any case there are a number of things you should know about developing successful IoT projects for the enterprise.
Here are 10 of those key points. It's not like these are huge secrets, but it can be easy to lose sight of them in the heat of project deadlines. The real question, though, is whether you've come up with key IoT points through your development work. Is it all about choosing the right tools or picking the right pizza for those late-night coding marathons? Is there some magical quality you look for when selecting members of the team for an IoT project?
Let me know what you think. The IoT is changing the way the enterprise looks at development projects and there are plenty of key factors to know and adopt. Your peers are waiting to hear yours.
Does your company offer the most rewarding place to work in IT? Do you know of an organization that stands out from the pack when it comes to how IT workers are treated? Make your voice heard. Submit your entry now for InformationWeek's People's Choice Award. Full details and a submission form can be found here.
For an infrastructure made up of tiny little pieces, the IoT can certainly generate huge volumes of data. It's easy to say that the data has to go somewhere, but one of your early decisions is whether that's true. The decision is critical because knowing what you're going to do with your IoT data will determine whether those bits ever leave the edge -- and how long they get to stick around if they make the trip to your enterprise core.
Your decisions on the data will have a major impact on the communications you use, how many tiers the application requires, and just what sort of I/O engine you're going to need on the backend. We'll leave the storage component to another discussion. So, before you go too far in your development, figure out the data piece -- and think carefully about just how much data you want to deal with once you've left the edge of the application.
In recent years, the big platform news has been around embedded control systems designed to make prototyping and low-volume solution-building easier and less expensive. The new prototyping platforms have unleashed a huge wave of creativity (and, in some ways, the IoT revolution itself), but prototype platforms don't necessarily transfer directly into finished, deployable products -- unless they do.
Why the contradiction? It has a lot to do with just how many devices you're going to deploy and what the customer looks like. If your IoT plans include a network to monitor and control your own systems -- a network that stretches to include a device count in the scores or hundreds -- then an Arduino or a Raspberry Pi platform could work. If, on the other hand, you're going to deploy an IoT system to thousands upon thousands of customers, then you'll need to choose a compact, rugged platform that can easily be gang-programmed (or have the software flashed during manufacturing) and inserted into the device.
The fact is, the platform matters. Small embedded systems are not infinitely interchangeable. Enterprise software developers aren't accustomed to choosing the hardware platform on which their software will run, but for embedded control developers it's part of the game. You'll need to pull the two sides together to think about the long-term implications of whichever platform you choose. Whether you ultimately go with one of the popular prototyping boards, or with a custom design in conjunction with a chip development house, your choice of platform will have a huge impact on both the immediate success of your device and the ability to revise the design in the future.
OK, first the bad news. Not long ago, we got wind of a vulnerability lurking in the heart of one of the Internet's core technologies, DNS. It's called glibc, and it allows someone to execute code without your permission through a simple technique called stack overflow. Now for the worse news. It's been present in the basic code stack for DNS for a long time.
I've talked about the masses of data that the IoT can generate and what a problem that data can be when it comes time for analysis and control decisions, but it's possible you have the basis of a solution sitting in your data center. SAP, Oracle, and other enterprise ERP vendors are rushing to build the best case for being the best hub for an enterprise IoT deployment.
There are some very real advantages that can be obtained by putting a big analytics engine at the service of the IoT. The analysis is fast, data-handling services are numerous, and communication protocols well-defined. Why wouldn't every organization just turn to ERP for IoT?
The biggest obstacles to ERP engines for IoT are related. The software is complex and expensive. If the analysis requirements are simple, there are almost certainly less-expensive ways to make them happen. If, on the other hand, your organization is looking to feed robust analysis through the sensors of the IoT, then the ERP engine you already have might be the perfect solution.
One of the problems in talking about the IoT is that the term means different things to different organizations. Connected programmable residential thermostats? IoT. Fitness trackers? IoT. Networked industrial process control? IoT. You begin to see the problem. The problem does nothing but grow when you hear some people talk as though the IoT is a monolithic, homogeneous whole.
The fact is that the things that make up the IoT matter. The platforms, communications, precision required, and safety margins are different for the different values of "IoT." Think carefully about the nature of the system that you're building and the devices that sit on the perimeter, and don't allow yourself to be convinced that "one size fits all" when it comes to the things you're introducing to the Internet.
A couple of pages back I was talking about the possibility of using enterprise ERP as the analytics core of your IoT universe. Now comes the flip side. Don't make your IoT software (or the hardware that supports it) any bigger than it has to be.
One of the side effects of Linux servers that can fit into breath-mint containers is that system designers tend to stuff far more computing power than necessary into a device "because it's there." Then, because the hardware platform is quite capable, the software team starts looking for functionality to add, and before you know it there's a top-heavy application stack teetering atop a fairly simple problem. The "KISS" principle was never more appropriate than in the IoT. Look for reasons to take things out, edit feature lists ruthlessly, and follow the writers' advice to "kill your darlings." The final product will be better for it.
Enterprise software development has gone full-bore into agile discipline. Managers and programmers now speak as easily of scrums and stories as of procedures and compile cycles. Embedded design, on the other hand, has long been a world of "write once and forget it" discipline, in which the common assumption is that the hardware and software will never be touched again after they've been deployed. In the IoT, it's time for embedded design to get agile.
One of the reasons that embedded controllers weren't designed to be updated is that most existed in isolation, never connected to other systems or a wider network. The IoT has changed that, and IoT architects should take advantage of the connection for continuous improvement. Now, this makes security ever more important, but the advantages of agile development and product life cycles are too great to ignore. It's time to teach your embedded team all about agile.
If you're going to be secure, you're going to be lightweight, and you're going to be agile, then you'd better figure out how to be thoroughly tested before your IoT product hits the field. The stakes are simply too high to allow any company to put poorly tested devices out into the world.
It's not that embedded system developers never tested in the past, it's just that there's an element of testing that many aren't accustomed to. That's the element of human testing. When all embedded systems were just taking environmental input and converting it to specified actions or output, no humans were involved. Now, though, the IoT is in the hands of humans all the time.
Take the time to test every system with a variety of unintended use-cases, and under no circumstance neglect security testing. Your users and your legal team will thank you for taking the time to test.
Never before have embedded system designers had so many options for the language used to develop their applications. When the operating systems for embedded devices include Linux and Windows 10, there are simply very few limits on which languages can reasonably be used for embedded development. Look at the possibility of having the on-device apps and the backend applications developed in the same language by teams that talk to one another on a constant basis. You might very well find that code-sharing takes care of problems on both ends, and that data translation issues are minimized, because each team can see and understand the process used by the other.
So, 10 things you should know about IoT development. Now here's my question to you: What is the 11th thing people should know about IoT development? I'd love to get your take -- and your thoughts on my 10 -- in the comments. I'll look forward to seeing you there.
Never before have embedded system designers had so many options for the language used to develop their applications. When the operating systems for embedded devices include Linux and Windows 10, there are simply very few limits on which languages can reasonably be used for embedded development. Look at the possibility of having the on-device apps and the backend applications developed in the same language by teams that talk to one another on a constant basis. You might very well find that code-sharing takes care of problems on both ends, and that data translation issues are minimized, because each team can see and understand the process used by the other.
So, 10 things you should know about IoT development. Now here's my question to you: What is the 11th thing people should know about IoT development? I'd love to get your take -- and your thoughts on my 10 -- in the comments. I'll look forward to seeing you there.
-
About the Author(s)
You May Also Like