Software architecture is a critical design element that guides developers to successfully build an embedded application. Here are five pitfalls that can get in the way of developing a good software architecture.
Software architecture is the fundamental organization of a system embodied in its components, their relationship to each other and the environment, and the principles that guide its design and evolution . Every embedded system should have a software architecture that guides developers through what they build. Unfortunately, it is not uncommon to encounter several pitfalls that stand in the way of a successful software architecture. In this post, we’ll explore five embedded software architecture pitfalls and how to avoid them.
Pitfall #1 – Believing in evolutionary architectures
There’s an idea I’ve seen floating around in development teams that there’s no need to consider your software architecture before you start coding. Instead, there is the belief that a system software architecture will miraculously evolve from nothing to a scalable, reusable, high-performance architecture on its own. Unfortunately, the belief seems to stem from a misinterpretation of ideas that emerged 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 bigger puzzle. A software architecture identifies key components, their inputs, outputs, and interactions with each other. A hallmark of well-designed software architecture is that it is evolvable to meet changing customer needs. However, in my experience, I’ve noticed that the most successful teams spend some time working through their software architecture.
Spending some time figuring out the pieces of software architecture still suits teams working with Agile methodologies. The architecture does not need to be developed in a waterfall fashion, but can be designed and honed in several iterations as details and lessons are learned. A software architecture developed in this way is generally more flexible and will be much more successful than a team hoping for architecture to simply appear. Unfortunately, the only architecture that will show up for those teams is a big ball of mud. (Or, if you’re hungry, a big ball of spaghetti.)
Pitfall #2 – Not tracking the data
An excellent principle for designing a software architecture is to follow the data. My first modern principle of embedded software is that data dictates the design. Data is the real asset that any embedded system should manage. Data comes in various forms into a system to create input. That data input is then processed, stored and/or used to produce output from the system.
When designing embedded software, you should not care which temperature sensor is used, which push button is designed in the system or even which microcontroller is used. Instead, designers and developers must identify and track the data assets in their system. For example, the architecture should identify the temperature data assets instead of worrying about the supplier of the temperature sensor. Likewise, in software architecture, we don’t care about the hardware, just that there is an interface that will serve as temperature data.
If you follow the data, the software architecture needed to perform the desired system behavior on that data will fall into place on its own. Oddly enough, it will create a hardware independent and easier to test software architecture. Avoid this trap by identifying and tracking the data through the software system.
Pitfall #3 – Not taking response times into account
Integrated systems often have real-time response requirements. For example, if a user presses an emergency stop button, the system will stop within ten milliseconds. Occasionally, I’ve seen software architects get overly excited about creating an elegant, all-encompassing software architecture or trying to use a more modern architecture that destroys real-time performance.
In addition to pursuing scalable and flexible architecture, software architects must also consider the implementation impact of their architectural decisions. At the architect stage, it 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 to create a task-based architecture. If the architect has less experience with task-based design patterns, it is not uncommon for there to be much more latency than expected. Many timing issues arise from interactions between interrupts and periodic tasks. The problem can sometimes be solved by changing the architecture of the problem task from time-based to event-driven.
Pitfall #4 – No implementation / architecture feedback loop
When a team builds its software architecture, I often see teams pretend that the architecture is gospel and cannot be changed. It is not uncommon for the developers who write the code to make architectural changes and never return those changes to the architects. The pitfall is that there has to be a feedback loop between the implementation and the architecture.
The architects build their architecture based on what they see as the optimal solution for the application. Unfortunately, the architects often do not have all the information they need to build the architecture completely. Therefore, during implementation, it is up to the coders to keep the architects informed about their findings, problems, etc. to determine the best direction for the overall software architecture. If the coders make the changes themselves without feedback from the architects, they can move the system in a direction that is not optimal for the architecture. As a result, the code and architecture slowly build up technical debts that stand in the way of success.
Pitfall #5 – Choosing the wrong architecture
Different types of software architectures can be applied to embedded applications. For example, there are unstructured monoliths, layered monoliths, event-driven, state-driven, and microservice architectures. If an architect chooses the wrong architecture for their system, they may find they have application scaling issues, response times issues, or many other potential issues.
Several reasons why a developer may choose the wrong architecture for the task. First, they might just be interested in trying out some new architecture that they’ve never used before. While broadening your horizons can be good, designers need to make sure that the architectural type they decide to use solves the problems and doesn’t introduce complexity or other potential problems. For example, microservice architectures have become quite popular, but they can suffer from complexity and response time issues if one is not careful.
When designing an embedded system, look carefully at the data and the domains in which that data works to help identify the architecture model that works best for the application. In some applications, you will find that mixing architectural types is required to solve the problem.
Software architecture is a critical design element that guides developers to successfully build an embedded application. Developers can use a wide variety of software architectures and design patterns to solve common design problems. Before examining those architectures and design patterns, we first examined five pitfalls in software architecture that can get in the way of good architecture.
What additional pitfalls have you seen teams fall into when developing their embedded software architectures?
 https://en.wikipedia.org/wiki/IEEE_1471. IEEE 1471 has been replaced by IEEE 42010. (I just like the IEEE 1471 definition).
|Jacob Beningo is an embedded software consultant specializing in real-time, microcontroller-based systems. He actively promotes software best practices through numerous articles, blogs and webinars on topics from software architecture design, embedded DevOps and implementation techniques. Jacob has 20 years of experience in the field and holds three degrees, including a Masters of Engineering from the University of Michigan.|
For more Embedded, subscribe to Embedded’s weekly email newsletter.