#017 - Modernizing Embedded Systems: Step #2 - Modernize Your Software Architecture

Summary

In this episode of the Embedded Frontier Podcast, Jacob Beningo dives into modernizing embedded software architecture—the second step in his seven-step framework for building faster, smarter firmware. He explores why most legacy architectures turn into “giant balls of mud,” how tightly coupling software to hardware holds teams back, and the four architectural dimensions you must consider: characteristics, principles, decisions, and structure.

Jacob also shares controversial yet practical perspectives, including his philosophy that “there is no hardware, only data,” and why data—not hardware—should dictate design. From architectural decision records (ADRs) to adopting a top-down approach with the 4C model, this episode provides actionable insights for designing scalable, maintainable, and future-ready embedded systems.

Takeaways

• Avoid spaghetti code: Emergent architectures rarely scale; intentional design upfront is critical.
• Define architecture characteristics: Select 3–7 key qualities (e.g., modularity, scalability, robustness) to guide decisions.
• Establish design principles: Adopt philosophies like “data dictates design” and “there is no hardware, only data.”
• Capture architectural decisions: Use ADRs to record trade-offs and prevent wasted rework.
• Think top-down: Use the 4C model (Context → Containers → Components → Classes) instead of bottom-up hardware-first design.
• Abstract hardware: Decouple hardware details from application logic for scalability and reusability.
• Prepare for change: Modern IoT and ML-driven systems demand flexible, forward-looking architectures.

Keywords

embedded systems, software architecture, modularity, scalability, ADR, design principles, data dictates design, hardware abstraction, IoT, DevOps, test-driven development, modern firmware, top-down design, containers, 4C model

Transcript

Jacob Beningo (00:08.216)
Welcome to the embedded frontier podcast, where we explore modern embedded systems, development techniques so that you and your team can develop faster, smarter firmware. I'm your host, Beningo, founder of Beningo embedded group, the embedded software Academy and co-founder of the embedded online conference. Before the summer break, we were talking about a seven step framework to help you modernize the way that you design and build embedded systems. That framework.

involved first overhauling your build system. Secondly, how you modernize and architect your embedded software. Okay. Modernizing your architecture. Third, how you implement DevOps practices. Fourth, adopting test-driven development. Fifth, incorporating simulation into your workflows. Six, leveraging AI and machine learning technologies. And finally, establishing a metric scoreboard.

Now, today, what we're going to do is dive deep into how you can modernize your embedded software architecture. OK? And this isn't just for folks who are working on high-end Linux machines. This is also how firmware developers, people who are working on microcontrollers and resource-constrained devices can start to rethink the way that they architect their systems. OK? And I'm going to warn you, there'll be some controversial ideas here, and I'm going to force you to think in ways that you don't normally think, perhaps, but...

The end result is that you're going to find if you follow some of these tips and tricks that I talk about in a session. It will help you develop software faster. It will help you work smarter and help you to increase the robustness and the quality of your embedded systems. I know this is a fact because I use these exact practices when I develop embedded systems and I've successfully delivered over 200 projects so far in the 20 years that I have been developing embedded systems. OK, so first of all, if we are talking about

modern architecture. We need to try to figure out what exactly is a software architecture. All right. Well, I'll tell you what the most common software architecture is first. It's a giant ball of mud. Okay. It's basically this tightly coupled spaghetti looking piece of software that makes it so that modules are tightly coupled. You can't pull any piece of code out of the software architecture without having to bring in, know, bring the whole thing with you. Okay. What you end up finding is that if you want to switch hardware,

Jacob Beningo (02:29.517)
from one microcontroller to another, you're not going to be able to do it. Why? Because you tightly coupled your application code to the low level hardware. All right. If you discover that I want to try to leverage a modern technology like simulation to test my application code, you discover you're not able to do that because you've tightly coupled to your hardware. OK. And so what I find a lot of times is that the way people are architecting their software, it's actually holding them back. OK.

which isn't something that you want to happen. All right. I've seen a lot of teams say, Hey, we don't need to develop a software architecture. Our software architecture is actually emergent. As we write our code, we're just going to end up with this beautiful scalable architecture that's robust and that everybody understands and just works. Right. Well, you know, newsflash, most teams today are writing embedded systems that require hundreds of thousands of lines of code. And you're not going to have an emergent architecture.

that's scalable, reusable, flexible and high quality without spending time upfront developing that architecture. All right. An embedded software architecture, I always look at it as a roadmap. OK, it is the guy it's what's guiding you for what it is that you're building, how the different components in your system interact with each other, how it interacts with the environment and even the philosophies and the design principles of how that software system will evolve over time.

Many of us approach software architecture like we're going to do it once and be done with it. But the fact of the matter is requirements change if you even have them to start with. And that's going to end up resulting in a software system that is in constant flux. And so our software architecture should be written in such a way that allows us to pivot and make changes as customer needs change or as we learn more about the system and what it is that we're actually building for our customers. All right. Now, a software architecture, when I mention this in general,

you probably stop and you immediately start to think about the structure of the code. All right. You think about threads and classes and how those classes interact with each other and other things related to that. Maybe you start thinking about state machines. Maybe you think about, you know, if you're working in very resource-contained systems with no RTOS, maybe you're thinking about foreground and background loops and how interrupt service routines are going to interact with code that's running in the main piece of your software. Now, when you stop about and stop and think about that,

Jacob Beningo (04:54.071)
The structure of your architecture is extremely important, but at the same time, that is just a single piece of the architecture. A modern embedded system today actually has four different architectural pieces that you need to think through in order to have a successful architecture. That first piece is going to be architectural characteristics. All right. Now, what on earth are these? OK, these are characteristics that your software has to exhibit. OK.

So, for example, as a real-time embedded software developer, oftentimes I'm aiming to have a system that has good performance. It might have scalability, might have performability, it might have secure ability. It might be, we want modularity. You can think about different characteristics of software. Oftentimes, in some of the literature, in some of the software architecture books, I've seen this referred to as Illidies. But there are actually over 70 different

or characteristics that your software might need to exhibit. All right. And all of those different characteristics, they're trade-offs. They're competing against each other. And so often what I will do is when I'm working with teams to help them develop their software architectures, I'll recommend that we pick anywhere from three to seven key characteristics that our system architecture needs to exhibit. All right. Now, a lot of times, like I said, in today's world, oftentimes modularity is really important. Scalability is important. Robustness.

secure ability of the system and performance. Those right off the bat are five that often I see show up over and over and over again. OK, but there can be many different characteristics that you follow. Ultimately, these are the intrinsic qualities of your software system that when you develop your architecture, you need to make sure these characteristics come out of your software architecture. OK, and you don't have to spend a lot of time thinking about, you know, this. can figure this out in 15 to 30 minutes. You know, this isn't spend weeks and weeks and weeks in

and deep philosophical thought to identify what these are. Just identify what the key things are. OK. And then mark them down, put them somewhere so that everybody knows, hey, these are the qualities that we're looking for, the characteristics that we want to come out of our software. All right. So that's the first important step when we're developing a software architecture is to make sure that we know what our characteristics of our architecture are going to be. Secondly, we need to define what our design principles are. All right. Yes, this feels like a.

Jacob Beningo (07:19.348)
you know, a course in philosophy at this point, right? What are the design principles that are important for us when we're developing our system, right? Well, we just want to make things work, right? We're under deadline, we're under pressure. Let's just get this thing done and knock it out. But the problem is, is when you have a team that has, you know, small, there are small teams out there with maybe just a couple of developers, very easy to work in a small team of like three developers. But when you have teams of 20, 40, a hundred or more developers all working together to develop a system.

you have to identify what are the key principles that we're trying to follow. All right. Now, every team is going to have different principles that are important to them. One of the first principles that I consider to be a firmware, a modern embedded software design principle is that we let data dictate our design. Over the years, I have discovered if I break a system down into the data that is that the system produces and consumes.

And I follow that data from inputs all the way through outputs. It very much dictates how I should break that system up into threads, how I should break that system up into components, how it should be broken up into classes and so on and so forth. OK, so looking at the data of your system, I have found that this really helps you architect an amazing system that's very flexible, that you very easily can apply different design patterns to. right. And so data really is at the heart of every embedded system. All right.

An embedded system is nothing more than a data processing system. It takes input data, it processes it, maybe it stores it, it might transform it, and then it outputs that data into the real world. All right? And so thinking about the different philosophies and thinking, like I said, for my example of a first principle is that data dictates your design. Now, I have a second principle that I consider to modern that really gets firmware engineers fired up. Okay? And many of you may not like this idea.

But the idea is that there is no hardware, only data. All right. Now you're going to say, no, no, no, the hardware is absolutely critical and important for what we do as embedded developers. And you're absolutely right. I'm not saying that we completely ignore the hardware and that we never look at it and pretend like it doesn't exist. But from a software architecture standpoint, that hardware is a data machine. That piece of hardware, that microcontroller, that serial interface I'm working with.

Jacob Beningo (09:38.58)
It's producing a stream of byte data. has registers that are in the form of maybe, you know, 32 bit data that I am manipulating to get the hardware to behave the way that I want to. And so ultimately from a software perspective, yes, there's hardware there and there are performance issues and there are all kinds of things that go in that we have to take into consideration with the hardware as far as constraints go. But when we're architecting our software, we don't care about those things. We follow the data. All right.

We abstract that hardware. If I have a serial port, I abstract that in my software architecture so that I don't care whether it's a USART, an I squared seed bus, ethernet, CAN bus. The core application code that we're developing shouldn't care what the hardware is underneath. Okay. Now, yes, we care about that because we do have to interact with hardware at some point. But the idea there is that if you're developing a software architecture that needs to have characteristics like modularity, flexibility, scalability,

If you're developing a platform that needs to be used for the next 10 years and might have multiple products that you launch off of it or have to support a dozen or more customers, you cannot tie yourself down to the hardware when you design your software architecture. right. Software embedded software development for many teams. And I'm not going to say all teams because there's a lot of very resource constrained devices where we still design things like they were 20 years ago. But a lot of modern IOT based systems today, they are extreme. You know, just have so much horsepower.

and need so much flexibility that we can't have the hardware tightly coupled to our software. All right. So that's the idea here behind that principle of there is no hardware, only data. Let that data go back to the first principle. Let the data dictate your design. OK. And so that's the idea. I'm not saying we ignore that the hardware exists. There's very important constraints there for us that we have to follow. But when you're architecting your software system, you can't tightly couple down into the hardware.

Like I see so many bad software teams do today. I've seen multiple examples where, know, like during COVID when people had their application code tightly coupled to their hardware and they couldn't get microcontrollers. What happened? They had to go back and completely rewrite all of their software because they didn't follow good modern design principles. They tried to say, I'm an embedded developer. I'm special. I can directly access hardware from my application code. All right. Now there might be cases where, yeah, there's things that are high speed like motor controllers.

Jacob Beningo (12:06.336)
where we need direct access to that hardware for certain features. And that's great. In those cases, we design that piece of our system to directly interact with the hardware. But we need to isolate it and abstract it from the high level application code that uses it. OK? And I know it sounds crazy, and you might say, well, that's impossible, Jacob. I've done a lot of motor control applications in my career. I'm telling you, it's totally possible. And I've done it dozens of times, probably. OK? And maybe dozens is over.

emphasizing, but I've at least done it a half a dozen times. Okay. Um, so it's definitely possible. Now the third thing that you need to keep in track, keep track of. Okay. So we've already said we have to have the characteristics of our system. need to know what design principles we're going to follow. And then, you know, again, I identify somewhere between three and five or three and seven that are very important to you. I actually write these down and keep them, you know, you can't see over to the right here of me, but I actually have my design principles written down. So when I come into, to work, to actually write code.

You know, on days when I'm not doing podcasts and blogs and content development, when I'm actually developing event systems, I sit down and I review those really quick before I sit down and write my code or before I architect a system. That's how important and critical those are. I want them always right there in front of my face. Okay. But the third and important area that I see teams just ignore all the time is architectural decisions. Architectural decisions that they're making, they often live in people's minds. They're not writing them down.

And so what happens? Well, you develop a system. You have a beautiful architecture that you put in place. You know why you made the decisions that you made. There were certain trade-offs you had to make. Software architecture is all about trade-offs, right? As I mentioned, you're trading off different characteristics of the system to match the ones that you need most out of your system. And then suddenly you start getting more teammates or you hire new people and they come in and they look at the code and what do they say? They go, look at this flaming pile of junk.

Why on earth would you develop this thing like this? This is a, you don't know what you're doing. Let's go back and redo all of this from scratch. Right. And what happens? You waste time, money, resources on something that might actually be okay. As it turns out, I've seen this happen multiple times where if you're not recording why you're making decisions about your architecture, what trade-offs you're making and why you decided what you did. I see that happen all the time where teams will come in and they'll just completely blow up what was already there in existence.

Jacob Beningo (14:32.219)
not understanding why those trade-offs were made. And then ultimately ending up in the exact same position that they were before on top of wasting a whole bunch of time and money. Okay. And so what we do when we develop a software architecture is that we actually keep track of our architectural decisions. We store these in something called ADRs, architectural decision records. Now within an architectural decision record, we are going to keep track of, you know, essentially the problem that we're facing, the issue.

We're going to lightly evaluate what some of the options are. And then we are going to select or kind of specify what choice we make and why we made that choice. OK. Now, this doesn't have to be super complicated. Oftentimes I do this with a simple markdown file. If you look up architectural decision records, there's lots of great examples on the Internet of how people actually record these. The idea is that they're lightweight markdown files that allow you very quickly to keep track of the decisions you're making and that

then other people can go and review and you can prevent that whole chain of, no, not invented here. You don't know what you're talking about. Let's go back and rewrite and rework all of this because of, you know, I'm a better programmer than you. Right. The whole not invented here syndrome, which I see happens so much. OK. And in order to save ourselves a lot of time, money and headaches. I see it where we take these architectural decision records, give it to one those engineers who comes on board and says, no, you guys don't know what you're talking about. And afterwards, what do they do? They read those records and they go.

yeah, yeah, yeah. I understand why you're doing it this way. I'm on board now. I understand what's going on. Right. And then instead of going back and redoing a whole bunch of stuff, you're moving forward as a team together. All right. So these architectural decision records are absolutely critical to keep track of in order to ensure that your architecture doesn't just survive, you know, a teammate or team rollover, right. Or expansion. It also is so that you yourself can understand, you know, six months or three months from now, why you made a decision, right? Why did you choose FreeR Tossover ThreadX?

or Zephyr over whatever, right? The reason is documented in an architectural decision record, right? And you might say, well, you know, from an architectural standpoint, the RTOS you choose shouldn't matter. And I agree with you 100%. Well, there could be a trade off where you decide not to obstruct the RTOS or that maybe there's an RTOS that has a whole ecosystem and you adopt their architecture for your system and you have to build your system around the way that they do things. OK. And so embedded development.

Jacob Beningo (16:58.844)
The great thing about it is that there's so many different ways we can design these systems, so many different tools. How do we keep track of what the right way for our particular solution is? We keep track of these architectural decision records. And, you know, a simple five minute ADR today can easily prevent five weeks of confusion or even five months of unnecessary development further on down the road. All right. So make sure that you keep track of your architectural decisions as you go. Now, the last piece.

of kind of a modern software architecture is the piece that comes to mind for all of us when we first think of software architecture, is actually figuring out how we organize our software, what the actual structure of the software is. Today, there's so many different ways that we can do this as embedded software developers. We can go with, you know, different design patterns. We can go with just simple bare metal. I'll be honest, bare metal is the easiest. I were doing like, you know, I don't know, a smart toothbrush or an electronic toothbrush or something, right? Why not bare metal? All you need to do is push a button.

let that thing go into some type of a for loop and we're good to go, right? Or maybe some light scheduling for some button presses or something like that. There's a lot of systems that are honestly, they don't require a lot of architectural forethought. Okay. So, you know, your architecture can be pretty simple and very bare metal, but a lot of systems that I encounter today, and perhaps it's just my own personal bias of the teams that I happen to work with. You know, I work in the IOT space.

I work in robust systems development. So I'll be working on automotive controllers. I'll be working on turbine engines in the defense industry, propulsion systems that go into space. I'll be working on medical devices. Sometimes they're safety critical, sometimes they're not. I'll work on consumer electronic devices, work on industrial control type applications, a lot of like GNSS types of applications, asset trackers, all that kind of stuff. And depending on...

exactly what the end goal is there is really going to depend on how you architect your system, what type of trade offs you make and what ultimately you have to do in order to be successful with that architecture. so sometimes a bare metal system is it's perfectly good enough. But for a lot of those types of systems I just mentioned, using a real time operating system or maybe even using embedded Linux can make things a lot easier. And a lot of IoT devices today, they have to worry about connectivity stacks like Wi-Fi, LoRa.

Jacob Beningo (19:26.386)
Bluetooth. You might have USB on board, CAN buses. You might even have AI, neural networks that they're running, machine learning, all kinds of different things can go on to these systems. And the more complex these systems are, the more of these modern architectural practices you need to adopt. If you're building something really simple, then yeah, data dictates to the design may not be a good design principle for you. Or there is no hardware only data, might not make sense for you, all right, if it's a real simple application.

But so many devices today that I see are adopting machine learning on board. They're using IoT. They're connecting to things. They're very complex sensor fusion applications. And we have all these pieces coming together. You can't rely on the types of architectures we designed 10, 15 years ago and expect them to help you successfully solve your problems. OK, this is where you need these modern design principles. This is where you need architectural decision records. We need to identify the characteristics of your architecture.

and where we even need to maybe modernize the architectures that we work with. There are times where I sat down with a customer and said, hey, let's architect your project. And we went through and I architected a nice thread model for him. It worked really well in a standalone system. And then four years later, they come back to me and say, hey, this is now going to be a distributed system. Let's redo the architecture. And my answer is, well, actually the way I architected it the first time,

made it so we can easily break this integrated system up in a distributed components with very little adjustment to the architecture. OK. And so part of selecting design patterns, selecting the different organized the way you're going to organize your embedded system and its architecture, that can dictate how easy it is for you to make changes in the future. All right. And if you do it right, those changes are very flexible. There's not a lot of extra stuff you're going to do. All right. But if you don't.

think ahead and you just kind of let the architecture emerge, become emergent, then you're going to discover you're going to be spending a lot of time just going back and redoing things that you did before. You're going to be fighting a lot of bugs, fighting fires. And honestly, at least for me, that's not fun. I always love to be on the forefront pushing where these systems can go, pushing the types of techniques that we're using to develop these systems so that we can go faster and we can work smarter. All right. Hence why you always hear me say faster, smarter, firmware.

Jacob Beningo (21:49.584)
Smarter doesn't necessarily mean AI and machine learning, although it certainly could. For me, faster, smarter firmware means that we want to go faster. We want to work smarter and we're working with firmware. These are embed systems. This is the fun stuff, right? So that is some thoughts and ideas there on what a modern embedded software might look like, how you might go about implementing.

Now, if we think a little bit further about how you can modernize your architecture, I'm going give you another controversial way to think about how you can architect your system. OK, we've talked about, you know, there is no data or there, you know, let data dictate your design. There is no hardware, only data. Another technique that you can use in addition to using these four steps is to go through and design your architecture from the top down. All right. I know that's that's that's that's a that'll flip your mind backwards. All right.

Because how do we usually go about developing embed systems? We start from the bottom up. I've sat in rooms where we're developing software architecture and we say, there's a push button here. And the first thing that embedded software engineers want to do is say, we have a push button. what's the debounce rate? What GPIO pin is it connected to? And they go straight to the low level hardware details. Okay, now don't get me wrong. My mind wants to do the exact same thing.

You know, I've been a firmware engineer for 20 years. All right. I wrote assembly level code on PIC 16F84s, you know, 20 years ago. mean, that's a little level. But today's systems, in order to have a good scalable, reusable architecture, if you're developing a platform based system where you want to be able to reuse your code, guess what? You can't think from the bottom up. You have to think from the top down. Instead, you think about that switch and you think about the components.

And you think about the data that's associated with it. And you think about the other things that it interacts with. And you push those low level details of what GPIO pin is it, or is it even on GPIO? Maybe it's a spy device. Maybe it's I squared C. Maybe it's some ethernet signal. Who knows, right? You try to push those, that information down to the bottom of your software architecture. Okay. So we work from the top down. We identify the major components, how things come in and out of our system. We identify, know, oftentimes I'll say we use the 4C model, right?

Jacob Beningo (24:11.25)
We will go through and we'll develop the context diagram, which says, hey, these are the users. This is our system. Here's how they interact with it. Once you understand the context of who's using the system, then we can actually dive down to the next level and say, well, what's the containers? How am I going to break this thing up into different containers? And you might say, Jacob, I'm working with firmware. I'm not working with containers. There's no such thing as a container in firmware. And I'll tell you, you're actually mistaken.

There are containers. What do you think a thread is or a task in in our toss? It's a container. You take multiple components and organize things that work together and you contain them within a task or a thread. Sure. It's not the container that you think of when you're thinking of Docker or podman, right? But it's still a way to containerize your software. All right. And, you know, I'll even say I've seen examples of containers.

that run on embedded systems. Just last week, I've got some STM32U585 boards over here that I've been doing some work with for like Trust Zone and some other experiments. My RTOS courses and stuff like that, I'll use that board. But anyways, I'm digressing. Back to containers, I was actually running a container from a company called Atom, A-T-Y-M, and I was able to write code and then push a container down to my system.

And it was super cool. They use like WebAssembly and actually allow you to create different applications and containerize it and deploy it down to your embedded system. OK. And so thinking that containers don't exist on a resource constrained microcontroller is it's mistaken. OK. This technology, it's here. We could actually use containers if we want to. If you're working on a system that uses Linux or, you know, some very high end RTOS's, you'll find that there is

emulation technology, there is the ability to create containers and have containers interact with each other. so, yes, at microcontrollers, it's not as common, but the technology is there. And we do have to think about these types of things in our embedded software development. There's more than one domain for embedded systems, right? We got bare metal type of domains. We have RTOS based domains, maybe even state machine driven domains. If we think of like active objects type of architectures, and then we can go up in the service based architectures. We can go into container based, can, you know,

Jacob Beningo (26:35.924)
Et cetera, et cetera. OK, there's a lot of different ways we can architect these systems. OK, but ultimately coming full circle back around what I was talking about, you figure out your context, how people interact with your system. You figure out how your what your major containers are in your system. Then you look at each of those containers. Maybe it's a thread and you break that up into components. Maybe you have a push button component now. And yes, you start to think about that. All right. And then eventually you design the class that cares about the fact that you're interacting with GPIO.

And there's some configuration module that interacts with that GPIO. All right. Even when I'm working at a low level of firmware, I try to write my code so that it doesn't necessarily care about the hardware. Okay. Yes, it does have to know those details, but even when I do write the code, I abstract to some degree, or I create configuration tables and I create, you know, things that iterate over, over the data tables that then just go into memory and just write to the memory. Okay.

My code pretty much looks at it and just says, Hey, I'm taking this data and I'm stuffing it in this memory location. It doesn't care that that memory location is a serial port or USB or ethernet or whatever it is. Okay. And so, you know, yes, we care about the hardware, but you can think about writing software in different way. And when you start to do that and you start thinking from the top down and you start to think about letting data dictate your design. And then you start to say, well, I shouldn't, you know, there is no hardware only data AKA.

don't tightly couple my application to my hardware, you find that it will actually open up a whole bunch of modern techniques that you can use to develop faster, smarter firmware. All right. That will include allowing you to adopt DevOps, implement CI CD platform, CI CD pipelines that work really well, that can analyze your software, that can run unit testing because you don't, you're not hardware dependent. Okay. It will allow you from that perspective. I can do unit tests. can do test driven development.

which means I have tests before I write production code, which means the quality of my code should go up, which also means I'll have test coverage, which will give me that, you know, feeling that, you know, yes, I can kind of confidently accept that my system maybe works the way that I expect it to under certain conditions. OK, we all know code coverage is kind of a vanity metric, right? If I get 100 % coverage, it doesn't mean I have no bugs. It just means I'm touching all the, you know, all the branches and all the lines of code.

Jacob Beningo (28:58.381)
but that doesn't mean it's actually working the way it should. You can fake that metric, which is why I call it a vanity metric. But it's one we all love. I I love it myself. And I have to keep reminding myself, hey, don't trust that metric. Don't trust it. OK. But we'll talk about more about that when we get to creating a metrics benchmark, OK, our dashboard. All right. So those are some ideas, some thoughts about how you can go about developing your embedded software architecture, about how you can modernize

your embedded software architecture. OK, these are just a few ideas. There's lots of other things that we can do to improve the way that we develop our software architectures. OK. But ultimately, we're trying to adopt more modern techniques that will help us to move faster and smarter in our development cycle and increase the robustness of our products. OK, now, if you want to learn more about how to how do you develop a modern software architecture like this. OK, there's lots of places where I've been talking about this.

One of them, I actually have an embedded software architecture masterclass I put together. Pretty inexpensive. You can go to your boss. It's like 200 bucks. You can go and take that if you wanted to. But even on my blog at Beningo.com, I have lots of articles I've been writing, kind of talking about software architecture that go into some details that will help fill in the gaps for you. If you're an individual developer and can't afford to take a low cost course, then check out my blog. There's a lot of details there. You can also learn a little bit more about this by going...

going on my LinkedIn profile. So if you go to LinkedIn, look me up, you'll find that I've been talking about this, you know, data dictates design. There is no hardware only data type of idea and showing examples there as well. And then of course, you can sign up for the embedded bytes newsletter where I go into a lot of detail on these types of topics. Now, I'm not trying to push you into these types of things. What I'm trying to do is say if Arc software architecture is a sticking point for you, there are ways that are very low cost for you to get the training that you need to develop an embedded software architecture successfully.

And ultimately, if you find that you are stuck, email me at jacobepenningo.com and I'll see what I can do to help you and or your team to develop your modern embedded software architecture that will scale and meet the needs, not just of you, but also your customers. All right. So that's our second step. Modernize your software architecture. We can think about developing our software architecture in many different ways, as we saw. And from here, what we are going to be doing next time is we are actually going to be

Jacob Beningo (31:26.541)
Digging in a little bit of detail, we'll talk with Brendan Slade from NXP about software architecture, about Zephyr, about some of the things that they're doing. And then after that one, we're keeping with the pattern of I talk to you about some ideas. We talk to someone in industry about it. And then we'll come back after that next podcast, which will be available here in a couple of weeks. We will talk about DevOps next. OK, that will be a fun one. We'll talk about.

what DevOps really looks like for embed software developers, things you need to be thinking about, what you should be putting in your pipeline, and what you can do in order to modernize the way that you integrate and deploy your software. So with that in mind, thank you very much. And I look forward talking with you again in the future. In the meantime, happy coding.

Jacob Beningo (32:18.691)
you