Don’t Lose Touch as a Software Architect Going Into 2022
Architects that forget their roots end up becoming glorified project managers. In this article, I reflect on some important tips learned in the last few years.
Join the DZone community and get the full member experience.Join For Free
We’ve seen many job titles surrounding Software Architecture. Solution Architects, System Architects, Cloud Architects, Application Architects, 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.
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 a 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 engineers 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
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 whether 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, but it also helps foster better relationships with developers. Instead of leading by authority, you’re now leading by example.
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.
Published at DZone with permission of Ryan Susana. See the original article here.
Opinions expressed by DZone contributors are their own.