5 pitfalls of embedded software architecture

Software architecture is a critical design element that guides developers in successfully building an embedded application. Here are five pitfalls that can hinder the development of a good software architecture.

Software architecture is the fundamental organization of a system embodied in its components, their relationships with each other and with the environment, and the principles guiding its design and evolution. [1]. Every embedded system should have a software architecture that guides developers on what they build. Unfortunately, it is not uncommon to encounter several pitfalls that hinder successful software architecture. In this article, we’ll explore five pitfalls of embedded software architecture and how you can avoid them.

Pitfall #1 – Believing in scalable architectures

There’s a notion I’ve seen floating around in development teams that you don’t need to consider your software architecture before you start coding. Instead, it is believed that a system software architecture will miraculously evolve from nothing to a scalable, reusable, and high-quality architecture on its own. Unfortunately, the belief seems to stem from a misinterpretation of ideas from the Agile movement. So, let’s set the record straight.

Software architecture is a roadmap, a blueprint, that tells coders how their code fits into the larger puzzle. A software architecture identifies the main components, their inputs, outputs and interactions with each other. A characteristic of a well-designed software architecture is that it is scalable to meet changing customer needs. However, in my experience, I’ve found that the most successful teams spend time upfront working on their software architecture.

Spending time up front to understand the elements of software architecture always works well for teams working within Agile methodologies. The architecture does not need to be developed in cascade, but can be designed and refined over multiple iterations as details and lessons are learned. A software architecture developed this way is generally more flexible and will be much more successful than a team hoping the architecture will appear. Unfortunately, the only architecture that will appear for these teams is a big ball of mud. (Or, if you’re hungry, a big ball of spaghetti.)

Pitfall #2 – Not Tracking Data

A great principle for designing software architecture is to follow data. My first principle of modern embedded software is that data drives design. Data is the real asset that every embedded system is designed to manage. Data enters a system in various forms to create entries. These data inputs are then processed, stored and/or used to produce system outputs.

When designing embedded software, you don’t have to worry about which temperature sensor is used, which push button is designed into the system, or even which microcontroller is used. Instead, designers and developers need to identify and track data assets in their system. So, for example, the architecture should identify the temperature data asset instead of worrying about the temperature sensor vendor. Similarly, in software architecture, we don’t care about hardware, just that there is an interface that will serve as temperature data.

If you track the data, the software architecture needed to perform the desired system behaviors on that data will naturally fall into place. Interestingly, this will create a hardware-independent and more easily tested software architecture. Avoid this pitfall by identifying and tracking data through the software system.

Pitfall #3 – Not considering response times

Embedded systems often have real-time response requirements associated with them. For example, if a user presses an emergency stop button, the system must shut down within ten milliseconds. From time to time, I’ve seen software architects get too enthusiastic about creating a sleek, all-encompassing software architecture or attempt to adopt a more modern architecture that destroys real-time performance.

While aiming to create a scalable and flexible architecture, software architects must also consider the implementation impacts of their architectural decisions. At the architect stage, he may not be able to fully quantify response times. However, high-risk areas can be identified and tested as soon as possible.

I often see developers struggling when creating a task-based architecture. If the architect is less experienced with task-based design patterns, it’s not uncommon to have much more response latency than expected. Many timing issues arise from interactions between interrupts and cron tasks. The problem can sometimes be solved by changing the architecture of the problematic task from time-based to event-based.

Pitfall #4 – No implementation/architecture feedback loop

When a team is setting up their software architecture, I often see teams acting as if the architecture is gospel and cannot be changed. It is not uncommon for the developers writing the code to make architectural changes and never send those changes back to the architects. The catch is that there has to be a feedback loop between the implementation and the architecture.

Architects build their architecture based on what they perceive to be the optimal solution for the application. Unfortunately, architects often don’t have all the information they need to fully construct the architecture. Therefore, it is up to the coders during implementation to update the architects on their findings, issues, etc. to determine the best direction for the overall software architecture. If the coders themselves make the changes without feedback from the architects, they can move the system in a direction that is not optimal for the architecture. The result is that code and architecture slowly accumulate technical debt that hampers success.

Pitfall #5 – Choosing the wrong architecture

Several types of software architectures can be applied to embedded applications. For example, there are unstructured monoliths, layered monoliths, event-driven, state-driven, and microservices architectures. If an architect chooses the wrong architecture for their system, they may discover that they have application scaling issues, response time issues, or many other potential issues.

Several reasons why a developer might select the wrong architecture for the job. First, they may just be interested in trying out a new architecture that they’ve never used before. While broadening one’s horizons can be a good thing, designers should ensure that the type of architecture they decide to use solves the problems encountered and does not introduce complexity or other potential problems. For example, microservices architectures have become very popular, but they can suffer from complexity and response time issues if care is not taken.

When architecting an embedded system, look carefully at the data and the domains in which that data operates to help identify the architectural pattern that will work best for the application. In some applications, you may find that mixing architectural types is necessary to solve the problem.


Software architecture is a critical design element that guides developers in successfully building an embedded application. Developers can take advantage of a wide range of software architectures and design patterns to solve common design problems. Before exploring these architectures and design patterns, we first looked at five software architecture pitfalls that can get in the way of good architecture.

What additional pitfalls have you seen teams fall into when developing their embedded software architectures?


[1] https://en.wikipedia.org/wiki/IEEE_1471. IEEE 1471 has been superseded by IEEE 42010. (I just like the IEEE 1471 definition).

Jacob Beningo is an embedded software consultant specializing in real-time systems based on microcontrollers. He actively promotes software best practices through numerous articles, blogs, and webinars on topics such as software architecture design, integrated DevOps, and implementation techniques. Jacob has 20 years of experience in the field and holds three degrees, including a Masters in Engineering from the University of Michigan.

Related Content:

For more embedded, subscribe to Embedded’s weekly newsletter.