Breaking News

Wi-Fi news from embedUR

Designing and building an IoT-enabled product means implementing embedded systems that require tight cohesion between multi-functional hardware components, standards-based network connectivity, and increasingly significant levels of integrated compute, AI, and ML, right at the edge. If the C-Suite is asking you to assess the engineering effort, it may be an opportunity to “manage up” to help leadership make a realistic decision, by reviewing the challenges you’ll face from concept through design, prototype, and production.
Once your company commits to integrating IoT features into your products, and especially when your key stakeholders are firmly aligned on a set of functional requirements, the question arises, how does the requisite embedded system come to be – that is, “do we build it or buy it”?
It’s a familiar dilemma in product engineering, whether you’re developing hardware or software, and by definition, IoT entails both. Whether your leadership leans one way or another, it all ultimately falls on you and your team.
There’s a learning curve to mastering the selection and use of both hardware and purpose-built frameworks and libraries, which is why you can also ask the “build or buy” question at more granular levels – at different phases in the project and about individual components. There is arguably no time when you should not ask this question. Yet too many engineering managers fail to do so frequently enough. Too bad for them, if they are sacrificing opportunity for ego.

No expertise – you have no choice

Getting products to market on time and on budget is a never-ending challenge, especially when new technologies and frameworks are involved. If you have neither the embedded systems expertise or the development capacity required for IoT development in-house your best option is to partner with the most experienced embedded systems developer you can find.

Some expertise – what to build vs. buy?

The discussion that follows focuses on the “close call”, when you already have some or all of the right expertise and your goal is making the right tradeoffs between outsourcing and insourcing options, for the whole project or for individual elements.
To help guide your key stakeholders along the best path to successful IoT adoption, let’s review some IoT-specific facts regarding the challenges, costs, and hidden risks in development.

How “build / buy” decision-making usually goes

Typically, before you even complete the requirements list, there’s already simmering enthusiasm for the internal build option, and not only because of the “not invented here syndrome”.
The prospect of an IoT build-out can be enticing for your team. After all, engineers gravitate towards “build” like surgeons gravitate towards “cut”. It’s what they do.
You know your team better than anyone, and even If you do have some or most of the skills and capacity you need, on paper at least, the calculus behind “build or buy” is very often more nuanced than it appears, and the level of effort to “build” can often look deceptively small. Worse, overconfidence often leads to inadequate research into what is a very nuanced challenge.
But this really is the critical evaluation – your readiness for full-throttle IoT development. it’s all too easy to under-estimate the learning curve, and to downplay the exceptional challenges inherent to IoT development.
In recent years, the reported success rate for internal IoT projects – just those that make it to market at all – has been routinely under 25%, with many study respondents echoing the theme that what “looked good on paper” turned out to be far more challenging than anticipated.
As a general rule, just tackling new technologies in-house commonly means risking 30-50% schedule slippage – know what you’re committing to directors and VPs. Those are statistics, and clearly some organizations have made first-time IoT projects successful, and maybe your company will be one of them.

Time to market or time to MVP should be your North Star.

Understanding the Level of Effort

To establish a realistic picture of the total effort, let’s look at both the extent of the technical challenges in IoT development along with those ancillary concerns, like governance, security and associated topics, that rarely interest engineers.

Design Imperatives for IoT

Despite the abundance of literature to the contrary, IoT isn’t a new “technology”, but rather a mash-up of existing ones.
Any given deployment consists of one or more embedded systems devices, and sometimes an intermediate layer of fog computing between the edge and the cloud. Like any engineering project, successful IoT projects require setting clear objectives and tightly defining requirements, while accommodating design themes like interoperability, security, scalability, and cost-functionality-reliability tradeoffs.

So what’s unique about IoT Projects?

On the device-side, the big challenge is orchestrating multiple components into a tightly packaged system of embedded software and (typically modular) hardware like a microcontroller unit (MCU), all in an environment with scarce computing resources – almost always constrained by tight physical dimensions and low power.
The nice thing is that the board-level hardware components, like the MCU, are available off-the-shelf. But selecting those components as part of holistic hardware and software architectural design is quite an art – not only to meet functional goals, but to optimize trade-offs among cost, performance, and reliability criteria. A mistake here is a big one, because every constraint or capability in the final product is locked-in by your hardware choices.

Engineering Effort

The fact that IoT systems draw so much on multiple existing technologies makes it easy to downplay the real risks that arise from integrating all the pieces.

Complexity of IoT Embedded System Development

For OEMs just entering the market, the embedded systems used in IoT pose new engineering challenges, and frequently means clearing a series of unfamiliar hurdles along the way.
Aside from the tight integration of specialty components – networking, MCU, and communication modules – “scarcity” is a big constraint. Power and computing resources are at a premium on the edge. Firmware runs “close to the metal”, so it often must be written in assembler or C, requiring developers to grasp concepts like pin-level signaling, direct management of hardware registers, and the power consumption implications of a given set of instructions – the kinds of things application programmers rarely have to contend with.
IoT systems frequently require running multiple asynchronous tasks. Depending on your hardware choices, there may or may not be a real-time operating system (RTOS) available. When there is, it usually amounts to a glorified task scheduler rather than an extensive library of system management functions. When there isn’t, your developers may find themselves managing tedious task scheduling in C or in machine code, and directly contending with low level timing issues, events, and interrupts.
Those are just a few distinctions between development of embedded systems and almost every other kind. Project leaders need to make realistic assessments of all facets of IoT development to ensure your capability to wrangle all the requirements for functionality, development costs, the ultimate unit cost and time to market, balancing those with the risk-reduction benefits of engaging an experienced IoT developer.

Some Engineering-Specific Pros and Cons

If you have rock-star embedded systems engineers, the upside of building in-house is that you know better than anyone how to integrate to your core product, what your internal standards are, and how you like to manage projects.
When your capacity and expertise is truly aligned your internal project may well be a go for launch.
Beecham Research has found that having the necessary in-house expertise for IoT is rare—87% of companies they surveyed felt that they lacked the right expertise to select and procure the right approach to device connectivity.
Either way, as IoT devices bring AI/ML to the edge, you’ll need developers and engineers with a broad range of skills to connect IoT devices, create user-friendly platforms, and align IoT services with business goals. Expertise is scarce, so it’s critical to assess whether or not you can attract and retain that talent.
Not all of the effort is in engineering. The technical part of development comes with responsibilities for governance, and some elements are often lost when initial research doesn’t go deep enough.

DevOps and Governance

Even with high confidence in your technical capabilities, everyone up and down the org chart should understand that all those novel challenges in IoT also come with a responsibility for the legal and logistical issues that support development.
Some examples:
  • Quality Assurance
    Stress and load testing that involves heavy iteration and monitoring numerous potential points of failure in both hardware and software. Effective embedded systems QA requires direct experience. This often requires development of simulators for real-world testing.
  • Risk Management
    Mitigating all aspects of risk. As a rule of thumb, successful risk management is roughly proportional to the team’s experience – your designer, developer, and DevOps all participate in identifying, assessing, and mitigating risks in software development and at run-time.
  • Data Governance
    Managing the security and integrity of the data generated and ingested by the system is a common requirement across many types of systems. But in IoT, it often demands careful trade-offs between allocating compute resources at the edge versus in the cloud.
  • Logging and Reporting
    Time-stamped logging of and run-time events and even software development activities related to compliance. In industrial applications that may also entail generating real time status of components and other telemetry.
Governance in IoT product development is crucial for a stable DevOps environment, but as you commit to the engineering strategy, verify that you’ll get the organizational support you need to guide your team through the labyrinth of legal and compliance concerns that the system and firmware complies with both existing and emerging regulation, and guidelines. That means a promise that you’ll get the resources to ensure conformity with ethical, privacy, and fairness considerations to adhere to general privacy laws like GDPR, industry-specific regulations, or internal compliance policies.
Your leadership will also need to ensure that your team isn’t burdened with getting certifications required for your IoT components to comply with industry, ISO, regulatory, and security standards – CE marking in England and the EU, FCC certification in the US, and RoHS everywhere, to name just a few.

The Team Decision

Frequently the business case for IoT adoption at the C-suite level is clear. But the separate question of “build or buy” is full of trade-offs for the technical team tasked with actually doing it – some obvious, some not. The underlying calculus clearly involves assessing both qualitative and quantitative variables, many of which are not readily apparent up front.
That’s why, in many cases the decision to buy comes down to comparative advantage: by partnering with a seasoned embedded systems developer, you can be confident that the end-product will meet your requirements, on time and on budget. It’s about mitigating the risk of missing target dates, not putting over-committed resources through endless crunch-time, only to produce a design that doesn’t scale, or worse, not even reaching MVP at all.
When it comes to architecting and engineering the whole, there’s no substitute for experience. The right partner can provide a level customization you would expect with an in-house build, accommodate scaling issues, and navigate your project around the standard pitfalls. Full service embedded systems developers can catalyze a nascent internal development practice.
For now, if you fall into the group that feels that don’t have all the required skills in-house for IoT, partnering with an experienced developer can get you to market quickly while helping you team ease into it and acquire new skills along the way.