by Santiago Arango, Software Architect at Growth Acceleration Partners.
“An architect in software engineering is like a conductor in an orchestra, harmonizing various components to create a masterpiece of functionality and performance.”
—Philippe Kruchten
Intro
Hello dear reader, thanks for being here and taking some time to read this article. I am sharing from my experience what defines a good software architect, not only from a technical perspective, but also as a referent, who leads what others want to follow.
Trust me, there are a bunch of different perspectives to see and work as a software architect, so I will be doing it as I work, not only making technical decisions, but also leading an excellent team of developers and QAs. So, you would see a point-of-view that also involves being a tech lead.
My name is Santiago Arango, I have worked in the software industry for 12 years. I worked as a software developer at all levels from junior to staff. I have been a lead for almost 6 years, and in the last two years, I had the chance to work as a software architect and technical lead.
The Responsibilities of a Software Architect
There are many responsibilities a software architect needs to take ownership of. I will share some of the basics you need to adapt to your day-to-day
Analyze and Decide
Yes, as obvious as it sounds, being a software architect requires you to have a huge capacity to analyze. You will be presented with many challenges on a daily basis that range from making technical decisions that impact a whole system to coding strategies to looking into the near and far future. Every decision you make will eventually have an impact on the product you work on; you have to be mindful of that.
You must also learn to follow your instincts, but make sure those are tight and honed by the experience you have. Don’t let emotions drive those decisions, but never remove the passion and the fire you have for what you do. You have to find a balance between being too emotional and lacking emotions.
Design and Plan
You must have the capability to design and plan solutions. You have to be ready for chaos, and you need to be aware that sometimes even those plans that look so perfectly designed and planned might fail.
But that doesn’t mean you have to sit down and wait for things to burn if they do. Make sure your plans and decisions always have a contingency plan that allows you to correct and evolve a system or team when things don’t go as planned.
You might design a great solution, but it would be too much for what it really needs to be solved. Or it might end up being too simple for a problem that could be very complex. Even if your plan looks a perfect fit for the problem, be aware that business, systems, teams, technologies and markets change. So, design thinking in a product could grow exponentially, but don’t turn a simple solution into something so taxing and expensive that might end up being too expensive to hold.
Mentor and Code
You need to mentor others, including your teammates and especially software engineers who might use you as a technical reference to define their future paths. So make sure you are a good example to them. And yes, you need to code. You need to certify yourself and invest extra hours to study and be up to date with the trends. And you need to be 5 steps further along than your team.
Don’t stop coding. A lot of software architects stop coding just because they dive too much into design. Knowing how to code would allow you to work closely with your team, but more importantly, it gives you an insight into the tech stack you work on. You will feel the positive impact of knowing how to code a component when you are designing a system, and you will know if using something is as easy as pie, or potentially harder than a diamond. When you don’t code, you have no clue about that, so you might add things to your solution things that don’t adapt to your team
Closely aligned with that is your role as a mentor. You must provide your team with insight on how to do things properly on the code. You need to be a fountain of answers to them, but more importantly, you need to be a figure that if you don’t know the answer, you will eventually come to your team to work on it.
Don’t be afraid to not know something, but when you notice something is skipping your fingers and it is part of your day-to-day, that’s a call to work on it.
Document
I will keep this one short; it is as it sounds. Document everything you do, from the final proposal to those drafts. Any documentation might eventually be useful, so keep it close to you, and fall in love with creating documents, so they become a referral to you, your team and the product you work with.
Software Architect Skills Set
Communication Skills
Yes, you also need a lot of soft skills. You are not just a box of technical knowledge that designs and makes decisions.You need to have the skills to talk to other people, to understand them and even more importantly, to LISTEN!
Don’t take your role as a super being, because you are not; you make mistakes, you don’t know everything, and those staff and senior developers might know a thing or two that you don’t. So don’t be afraid to reach out to people and listen to them. This also applies to working with your peers, and working with other software architects to check how you are doing.
I already mentioned this earlier, but never stop learning. You must be someone who puts a lot of effort into what you do. Read books — a lot of books. Also, read other software architect’s solutions, check the internet, and learn the most modern design frameworks and code. Learn new technologies, watch videos and take certifications. All of these things will prove your game.
Critical and Creative Thinking
You must have a mindset to experiment and provide solutions. You need to enforce creative thinking and challenge yourself. If you put yourself in a position where you think you know everything, you will pretty soon find that you do not. So, challenge yourself, challenge your own proposal, and be very critical of the solutions you propose.
Use all the information at your disposal. If you want to develop critical thinking, all the information you have prior to a solution would be the key to a successful solution. Never ignore the data. Do a vast amount of research before moving to the solution; see if similar problems have been already solved and how was the rate of success.
Improve your creativity.Don’t be afraid to experiment and fail. Let your creativity go and explore. I strongly believe creativity is also key to keeping a healthy mind, so invest time in whatever makes you happy. Go to the gym, read other non-technical books, play video games and spend time with those you love. You would be surprised how a good routine is key to an efficient capability of making decisions. An unhealthy body with poor emotions would never develop a brain with vast creativity.
Technical Skills
You need a strong game on technical skills, beyond coding. With your current position comes a requirement to know about architectural design and styles. You will need to know how to exploit any type of resources your client has, from cloud to on-premises or both.
It is important to mention you don’t need to be a boss in all cloud providers, but to be successful, I would recommend being very good in at least one of them: Azure, AWS, GCP, etc. Choose whatever brings you the most value based on your profile, career, project and programming experience.
Read about software architecture styles for both designing scalable solutions and also programming patterns. So, to summarize, to design you should learn base concepts about microservices-oriented architecture, event-driven architecture, microkernel patterns and others. And when coding, it would be nice to know stuff like domain-driven architecture, test-driven design, CQRS and event-sourcing. But more importantly, knowing how to connect both and the success of applying the design of a system strongly depends on how it is coded and what approach follows up the main design the best.
Get familiar with DevOps too; you don’t need to be an expert on deploying resources, but for sure knowing strategies to escalate systems properly — and how to operate them in whatever infrastructure you choose — would gain you a major insight on how to design a solution. This is similar to the coding piece.If you know what resources are available, how they operate them, how much they cost, and the hard and easy parts of managing them, you will have a bigger picture to know what you need to choose for your solution.
Work closely with the DevOps teams and also with DevOps architects. That way, when you propose a solution, you can go into the detail of what is needed to achieve what you are planning to propose. Maybe if you need a hard drive, you might need to allocate VMs to deploy those managed Kafka clusters you would like to include; or you might need to set up a Kubernetes cluster for the first time… they might know if you don’t.
Conclusion
If I manage to sell the idea of what I believe to you, by now you need to understand that a good software architect needs to be an expert on a lot of technical and human things, and needs to have insights into other ones. Plus you need to be a great listener, and someone who asks a lot of questions too. Be someone who doesn’t fear to challenge what exists today, but is also very cautious and ready to accept and adapt to failure.
Then again, this is my personal view. I know some might not agree with being so specialized in different things. And some others might not agree with being a leader, and would instead advocate to just be a designer and let the developers adapt the solution. But then again, this is my point of view. It worked for me from my time as a technical lead and software architect, and I hope you might get some value from this reading.
Thanks, dear reader!
