Don’t lose touch as a ‘Software Architect’ in 2022

4 min readDec 15, 2021

We’ve seen many job titles surrounding Software Architecture. Solution Architects, System Architects, Cloud Architects, Application Architect, Information Architects, Enterprise Architects, etc…

Formalized title or not, you should have people in your organization who:

Make and mandate long-lasting architectural decisions and guidelines
Continuously analyze and upgrade software architecture, paying back technical debt
Mentor developers
Have oversight as to what’s important for businesses, navigating politics along the way
Broadens, deepens and renews their own knowledge, as the industry grows at a rapid rate

These are what I call the Software Architects, but you can call them whatever you want to. I’ve been hyperfocused on becoming a great Software Architect in 2021. In this article, I will go over some tips I’ve learned. Bring on 2022!

You’re a developer first, make sure of that

Have you ever seen a judge who wasn’t a lawyer before? Architects are good and experienced developers at heart. They’re accustomed to the problems that many other developers face day-to-day.

An architect must not lose touch with what developers deem as important. You must speak the language of developers. Maintainability is the largest driver of IT costs. You must design with developers in mind.

Architects that forget their roots lose the respect of their developers. They effectively become glorified project managers, and no one needs an extra manager.

To avoid becoming a spineless, armchair architect, you should allocate some of your time to:

Try new or different technologies with developers
Consume content surrounding software development. This can be in the form of courses, YouTube videos, conferences, webinars, etc.
Hobby development projects

Humble yourself

On the other end, you might think you’re the brightest developer who has ever laid hands on a keyboard. And you have the skills to show it. Great job, you’ve won gold at the Ego Olympics! Now what?

There are few subtle differences between developers and architects. One of the most essential skills that architects must possess is Communication, capital C. You might have an elegant or clever solution to a problem, can you communicate that to stakeholders and developers pleasantly and effectively? Does your team despise you, envy you, or admire you? That new engineer on your team, are they keeping up with the pace? You should constantly be asking yourself these questions.

Some tips that I can give are:

Allow room for inclusion in major architectural decisions. Try to foster developer consensus around your technical decisions.
Allow developers to be autonomous and make their own decisions and mistakes. Make a balance between risk and learning opportunities.
There will come a day when a developer surpasses you in some aspect. Embrace it. Help them on the way up!
Speak enthusiastically about your job. And theirs.
Take more responsibility, give more credit

If you design it, you should be able to build it

Writing the right amount of documentation is a good skill to have. Too little specification, and no one but you understand the system. Too much specification, and the system becomes costly to change. Finding the sweet spot depends on the project and the team. However, as an architect, you should know that.

It’s very easy to get carried away with fancy-shmancy diagramming tools and techniques. At the end of the day, it doesn’t matter unless you have something to show for it. I prefer to go with lean documentation practices, such as those advocated in the C4 model. Companies full of vibrant, capable engineers also seem to agree.

One key principle that you should have is: if you design it, you must be able to create it. Or at least the important bits of it. It’s a foolish game to design a system you can’t implement yourself. It’s your job as an architect to understand the implications of the technical decisions and guidelines you make. Although theoretical knowledge will get you far, nothing beats someone who’s capable of practically getting the job done. If you don’t know if you’re capable of doing the job: Step 1. Make a prototype…

Get your hands dirty

Research has shown that architects should be hands-on and write code. Many experts also agree. When working on a software project, I suggest that architects get involved. This can mean:

For greenfield projects, bootstrap the teams with a Walking Skeleton
Write Architectural Unit Tests or other fitness functions for your projects
Take part in peer reviews
Refactor code for better design
Write some new functionality

Not only does this strengthen your own skills, it also helps foster better relationships with developers. Instead of leading by authority, you’re now leading by example.

Conclusion

In this article, I went over some Software Architect advice that I’ve picked up on in the last year. The main points were: refining your technical skills and being a humble and helpful leader. Hopefully, you found this useful. Hopefully, I can do this annually.

Connect with me ❤

I’m usually down for a spar session. Maybe even a new code homie?

Connect with me on LinkedIn: https://linkedin.com/in/ryan-susana/
Check out my code on GitHub: https://github.com/RyanSusana
Follow me on Twitter: https://twitter.com/RyanSusana
Send me a message via my website: https://ryansusana.com