The best way to get started in IoT
Start off on the right foot. Make great decisions as you go. Here are some critical considerations.There are a lot of decisions to be made early on, so that your project turns out the way you want and the whole effort runs smoothly without “gotchas.”
Unfortunately, there are a lot of opportunities for “gotchas” in IoT and embedded systems, due to all the cost, technology, usability, security, integration, and business tradeoffs. By the way, we define embedded systems as those where intelligence is literally embedded into an otherwise non-digital device, and an IoT system where that newly digitized device now sends and receives data via the Internet.
Helping you navigate through all that, so that good decisions are made, is what we do from the very first phone call. We go far beyond what a “just write the code” type of company will do for you.
For example, during one of our first conversations, we will have something we call a “pre-mortem”—like a post mortem, but we do it before any engineering starts. “Let’s assume that it’s six months from now, and the project has failed,” we will ask. “What are the five reasons it might have failed?” The answers help us, together, pinpoint what some of the most pressing risks and tradeoffs are.
What are some of the tradeoffs and risks? Let’s look at what we’ve learned, thanks to working on hundreds of projects.
Cost
May as well start here, since it is so important. There is always a cost restriction, even if you’re building something for a massive government contract. The more common situation, though, is that you are creating a product of some sort, or a component in a larger system that is designed to create greater efficiencies for your business.
The cost tradeoff decisions often involve questions such as:
- Do we need to build this component, or can we buy something off the shelf that will cost less overall and still meet the other requirements?
- Is there some way to combine several elements into one, saving cost?
- Are there special environmental requirements that will force us to use ruggedized or otherwise specialized components?
- How much are we going to sell these for, and, given that price cap, what must the cost of the final solution be, so that we make a profit?
- Have we been given a cost limit on the solution, due to the requirements of our contract, or, if the system is to be used internally, due to what we can afford (and what we gain in efficiency) in order for this system to pay for itself?
- What are the power requirements, and are there any low-cost alternatives?
- How can we achieve a high-quality end result, without cutting development and security corners?
Your situation will be unique, but at the same time, we will be able to apply years of tradeoff experience to the discussion and can help you make wise decisions.
Technology
We could write a book about this part; there are so many technical aspects in any IoT and embedded system to consider. We’ll keep it high level here.
The cost tradeoff decisions often involve questions such as:
There is a tendency to think, “Let’s measure everything!” but the more data you gather, the more you need to either process at the edge unit, or in the “fog” (a computer closer to the edge), or up in the cloud.
If you are sending a lot of data to the cloud, that takes time and introduces latency, something you can’t afford for systems that require a near-real-time response to the data that has been collected. So “how much” data and “how fast” the processing has to happen are both important considerations.
Then we start to deal with the other aspects of technology, starting with the limitations imposed by the environment in which the device is going to operate. There are almost always size restrictions to accommodate, given that IoT and embedded system components are usually integrated into either an existing product or a new one that must be as small as possible.
Another aspect of technology to consider is the ongoing maintenance of any IoT or embedded device. If the device is operating in a remote area, for example, you want the battery to be extremely long-lasting or even solar-powered. If you are plugging the unit into the wall, you won’t have to worry about battery replacement.
If the unit does require maintenance, however, how close are experienced technicians? We have built systems that literally tested themselves, guided a less-experienced technician to make the necessary repairs, and then re-tested themselves. What if the device is going into space, or into the depths of the sea? No techs there, either. Those systems have to include built-in redundancy or self repair capability.
When we work with clients, we look at all aspects in IoT security
There are several areas that require special attention, making a comprehensive approach important: Network security—IoT devices are typically deployed onto unsecure networks, because often that is all that’s available. This places a heavier burden on the IoT device itself to provide the required security functionality.
Usability
An IoT or embedded device that is difficult to use won’t sell. Consumers will bash it in reviews, and sales will suffer. On the other hand, a device that is a pleasure to use will delight its users, and their reviews will add power and momentum to your sales. So usability is important.
We all know it when we see it, when it’s done right—or not. Menus that don’t make sense, in terms of language or hierarchy; unexpected dead ends that force us to go back and try another way; too many clicks or repetitive actions that seem unnecessary; menus with the items not logically organized . . . the list goes on.
Interestingly, substandard usability often occurs because the developers creating the software are so close to the product and its functions that they don’t even realize what they’re creating is confusing. But more importantly, users need to be involved from the start; what they want to accomplish and how they want to accomplish it needs to be designed into the earliest prototypes.
It is not that expensive to build “real user” usability into a product at the start, but it is very expensive to correct a product that users find inconvenient or incomprehensible.
Security
The real problem with security is that it only takes one breach for your company to be forever “branded,” for years, in association with that negative incident. And to dissolve the trust, overnight, that you have so carefully built up in the marketplace.
Security can be built into an IoT or embedded system from the start, into the software, firmware, and hardware. We do this automatically, using tools that allow us to quickly find vulnerabilities and correct them, in agile sprints. As with usability, it’s always easier to fix security issues during the course of development rather than at the end, after all the code has been written and the hardware has been built.
It’s especially critical with IoT and embedded systems, as it can be very expensive to have to redesign the hardware, once again addressing all the restrictions, with new parts. And those new parts need to be retested for vulnerabilities.
Integration
Your sensors need to be able to communicate with the mothership, reliably. The mothership needs to be able to accept the information and process it properly. The devices being controlled need to function properly.
All this seems obvious, but given the variety of solutions to any given IoT or embedded challenge, there are often components involved that were not necessarily designed to be used in this particular way. This requires a strong knowledge of integration options that are reliable and cost-effective.
We’ll work with you to make sure that the best options are used.
Business tradeoffs
Given that this isn’t our first rodeo, we can weigh these options with you, bringing real-world experience to the conversation. Sometimes the answer is obvious; sometimes it takes a little digging to figure out the best answer. But in all cases, we can often predict the results of a given course of action.
One business error that we help our clients avoid is the “let’s build the whole thing and send it to market” error. This often leads to disappointment, especially if “the whole thing” turns out to have a fatal flaw or some aspect of it is no longer feasible due to a component being no longer available or no longer a secure option.
Instead, we use the Agile method, where we develop in mostly self-contained sprints. We build proof-of-concept mockups for each part of the system, and make sure that mockup works as hoped. Then, we build prototypes for each part, using the real-world components that will be used in the final product. At each step in this process, we test for usability and security, and make sure that the goals and restrictions are satisfied.
We’ve done a lot of work for very large companies, where business decisions are invariably more complicated than those involving small or mid-sized companies. We are well aware of the importance of getting approval and buy-in from corporate management in these situations, and adjust our methods accordingly. We understand and can support the business decisions that result in a positive outcome for all stakeholders.
For smaller companies, we can move quickly to take full advantage of market opportunities, cost-effectively partnering our domain experts with yours.
Regardless of your company’s size or situation, we respect all of the specific experience and knowledge that you bring to the effort. Our team members always assume they will learn as much from you as you learn from us.
The result is a satisfying joint business endeavor.
And yes, the best way to get started in IoT is to find the right partner, one that will help you navigate all of the issues that can derail your project—while at the same time, producing a device and system that leads to business success.