5 Tips for Becoming a Successful Embedded Software Architect
Becoming an embedded software architect isn’t about learning material but changing your mindset.
September 26, 2023
The role of an embedded software developer is quite a bit different from that of an embedded software architect. Developers often jump into the code with the pressure to knock out as much code and features in the shortest time possible. The developer focus is short-term. Architects aren’t in a hurry; they are thinking about the long-term success of the software product. Developers often transition to architect, but the path can be choppy without care. This post will explore five tips for a successful embedded software architect.
Tip #1: Think from the Top Down
Embedded software developers often think from the hardware up. I can’t tell you how often I’ve sat with a team to discuss a high-level feature only to have developers dive from the 30,000-foot view to ground level. A discussion about a user pressing a button turns into a conversation about which processor and GPIO line will be used. While these details are necessary to implement the final product, they won’t help you successfully create your architecture.
An embedded software architect needs to think from the top down. A software architecture often starts at the highest view and then works down to lower levels. In fact, good architecture never gets to the ground level! Instead, the architecture paints the overall picture and vision for the software. The details, like which GPIO pin, are abstracted from the architecture. Doing this gives the developer, the implementer, the flexibility to make low-level decisions that the overarching architecture doesn’t care about. A good software architect thinks from the top down and gives the developer flexibility to make the ground-level decisions that make the architecture successful.
Tip #2: Delay Decisions as Long as Possible
I know this sounds like something you used to do in college. Professors always told us not to procrastinate. As an embedded software architect, delaying decisions as long as possible is to your benefit! We all know that information and details change rapidly when we start architecting a system. The sooner you decide and commit to it, the more likely you’ll have to take that decision back. That means developers may have gone to the races only to learn that all their hard work was for nothing.
The art of software architecture design is to make decisions only when you are forced to. What framework are you going to use? Do you have to make that decision today? Is there anything you can do to delay it, like adding an abstraction layer? Developers tend to make quick decisions and jump in, which wastes development time and budget. Architects only make the decisions they must make right now. Everything else is pushed off into the future. Doing this makes you more likely to design an architecture that is flexible, scalable, and less dependent on low-level details. Finally, procrastination wins the day!