Are we Doomed to be Integration Engineers?

Jacob Beningo
Jacob has 15+ years of experience in microcontroller based real-time embedded systems. An avid writer, trainer, speaker, consultant and entrepreneur, he transforms the complex into simple, understandable concepts that accelerate technological innovation. Jacob has more than 200 published articles on embedded software development techniques and holds three degrees including a Masters of Engineering from the University of Michigan. Visit Jacob at

Are we Doomed to be Integration Engineers?

The big push for embedded systems to is to become inter-connected with local intelligence complemented by cloud-based AI and management… and exposed to the user through a gorgeous modern Human Machine Interface (HMI). These features are dramatically increasing system complexity. Increased complexity isn’t necessarily a bad thing if it allows companies to rapidly innovate and differentiate their products while reaching new markets that might not have otherwise have been available. One major problem with increased complexity in this case, is that development teams are not being provided more time or money to deal with it! Instead, best case, development timelines and budgets are staying the same but, in many cases, they are decreasing. Developers are left in between a rock and hard place and are turning to third party software stacks and hardware to help manage the complexity and give them a leg up on the timelines and budgets. This leads us to an important question, “Are we all doomed to become integration engineers?”.


When someone mentions an embedded systems and software engineer, I immediately picture an electrical engineer who is not only a master over the hardware but also understands the bits and bytes of the software that is driving that hardware. The fact is, as we move to more complex systems, those embedded systems and software engineers are becoming a rare and nearly extinct breed. There just isn’t the time or budget available to understand everything that’s happening in the system! Are embedded software engineers becoming nothing more than integration engineers taking software stacks and hardware from various third-party sources, meshing them together and then going to market? 

On the surface, it very much looks like we are doomed to become integration engineers. Control over the low-level bits and bytes will quickly become a distant memory as embedded software engineers move away from the hardware. The reliance on third-party stacks will dramatically increase as the entire system becomes nothing more than interconnected black boxes. To some degree, this all makes sense, since there is a lot of common code in an embedded system and we don’t really want to waste precious development cycles reinventing the wheel.


When we dig deeper, the truth is that while we may very well become integration engineers, if we leave behind our embedded roots, we will never be successful. The fact is, the modern embedded software engineer needs to leverage and integrate third party software but also must be fully capable of optimizing and customizing the solution. While we can’t afford to build everything from scratch like we did in the “good old days”, we can still customize and scale our integrated software solution to provide a fully differentiated product that is built upon the same building blocks as our competitors. After all, many embedded systems share a common base, components that are needed in every system. Recreating that functionality is a waste of not only time but also budget.

The key to avoid becoming only an integration engineer is to develop a product on a platform that is already fully integrated and provides developers with the ability to easily scale and differentiate their product. Such a platform would allow developers to still dive deep into the low-level software and customize it to their own applications needs. If you stop for a moment and think about this, it makes a lot of sense. You wouldn’t catch a chef spending most of his time trying to build an oven. Instead, a chef buys the oven which is nothing more than the tool that he uses to differentiate the product for his customers. 


Stop thinking that all the software in the system is software.  Start thinking that all the base firmware – OS, stacks, infrastructure – should be supplied as a tool.  If you start thinking of these as expected tools from the vendors, then it changes your idea of embedded engineering.  Using the “tools” and building an “application” take on a different level.  Don’t think of this as replacing your IP or software, think of this as leveraging a much bigger tool.  You’re the chef, use the oven, stop building the oven every time you want to cook. 


Are you wasting precious development time reinventing the wheel or building your own oven? If so, take a closer look at the SCM318 which can provide you with that baseline hardware and integrated software platform that you can use to start immediately differentiating your own products.

3 Pillars of Embedded Innovation

Three pillars of innovation – communications, control, and human machine interface (HMI) – drove a consumer device revolution.
How are these affecting the embedded systems you design?

The Top 3 Problems Holding Back Embedded Systems Engineering

Most embedded system developers don’t realize it, but they have three mindset problems that are preventing them from getting to market faster and decreasing their engineering costs: customization,
starting out too low-level, and believing that all software should be free.

How to Scope Your First HMI Project

HMI developer often under estimates the total extent of what is necessary to successfully pull off the project. In this post, we will examine what is necessary to scope your first HMI project and make it a success.

The Siren’s Call of the Pseudo Platform

An LCD and touch screen are certainly important, outward facing factors of a Human Machine Interface (HM). But behind the scenes, there is much more to a display module than meets the eye — it’s is a highly integrated real-time embedded system tuned to efficiently interact and communicate with its environment.

7 Free Resources for Embedded UI Design

Designing an embedded HMI’s User Interface (UI) and User Experience (UX) can be a daunting task. We’ve compiled seven free resources to equip you and your creative team (if you’re lucky enough to have one), with an arsenal to leverage when drafting your UI design.

The Anatomy of a Display Module: Software

there is a lot of software that is used to get a Human Machine Interface (HMI) display module up and running. To compete in today’s fast-paced and competitive market, can you leverage an existing display module to accelerate your development cycle and beat the competition to market?

The Anatomy of a Display Module: Hardware

An LCD and touch screen are certainly important, outward facing factors of a Human Machine Interface (HM). But behind the scenes, there is much more to a display module than meets the eye — it’s is a highly integrated real-time embedded system tuned to efficiently interact and communicate with its environment.