5 Tips for Becoming a Successful Embedded Software Architect

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!

Tip #3: Collaborate and Communicate, But Don’t Design by Committee

Collaboration and communication are critical pillars in any development project. You need to be able to work as a team and effectively communicate with your teammates. Unfortunately, I often see teams starting on a software architecture, which means putting the whole team in a room to hash out the architecture. I’ve seen time and time again that doesn’t work. An embedded software architect doesn’t and shouldn’t design by a committee. When teams design by committee, simple decisions turn into a democratic debate that freezes the team and brings progress to a standstill.

Software architects should instead reject design by committee. The architect oversees the creation of the architecture and should pull in a few people at a time as needed. I’ve found groups of 2 – 3 people often work best. That makes the group small enough for everyone to participate effectively but not so large that people get quiet or into big debates that waste everyone’s time. As decisions are made, it’s okay to have team meetings that present the architecture and ask for feedback. That keeps everyone involved while simultaneously ensuring that rapid progress is made.

Tip #4: Think Long-Term and Maintain Flexibility

When you make decisions early in the development cycle, those decisions can have long-lasting impacts. In fact, sometimes they last a decade or more! It’s critical that an embedded software architect thinks about the long-term implications for the company and maintains flexibility in the design. A good architect will consider issues such as maintainability, scalability, portability, etc. Long-term thinking ensures that the team can successfully deliver and maintain their product with reasonable resources.

When you think about the long-term, building flexibility into your design is essential. Over a product's life, it’s typical for new customers and requirements to surface. Sometimes, these features can wreak havoc on the architecture. However, you'll become a great software architect if you think ahead and keep your architecture flexible by planning for change.

Tip #5: Stay Updated and Involved in the Community

Software techniques and technologies change at a rapid pace. The industry is constantly evolving, and things that worked just a few years ago may no longer work for your current project. It’s critical that an embedded software architect stays current and learns about new architectures, tools, and techniques they can leverage to improve their designs. If you aren’t learning and moving forward, you’ll quickly find that you’re being passed and left behind!

An embedded software architect should ensure they get involved in a software community where they can learn from peers, ask questions, and mentor others. They should be reading books and articles and attending classes periodically. I’ve found it excellent how quickly you can lose something without using it! It’s key that embedded software architect continues to learn and advance their craft to ensure they can successfully deliver an architecture that meets their stakeholders' needs.

Conclusions for Becoming a Successful Embedded Software Architect

Going from a developer to an embedded software architect is a journey. Their perspectives are different. Developers think short-term, while architects think long-term and look at the big picture. Becoming an embedded software architect isn’t about learning material but changing your mindset. Anyone can learn about software architectures. Changing your mindset to design robust, flexible, and scalable architectures consistently is a different thing. If you follow the tips in this post and adopt this mindset, you’ll be on your way to becoming a successful embedded software architect.