Who is a Software Architect?
First of all, let’s try to define what is a Software Architect. It’s an important part because it has so much different definitions and role descriptions over the industry that it’s not that easy to navigate.
If to check on Wikipedia, you will read as follow:
A software architect is a software development expert who makes high-level design choices and tries to enforce technical standards, including software coding standards, tools, and platforms.
I love the “tries” part.
And this is genuinely precise, as well as hardly help in reaching that career ambition. Because it feels like this is exactly what I was doing on almost any engineering position I had! It’s rather debatable how much of an expert I was on those, but I did high-level estimations and designs for tasks that I had before me on my level of responsibility. And this is a vital part — on my level of responsibility.
Architect Classes
For instance, one of the theoretical standards, if any can be named as such, can be a classic separation into application architect, solution architect, and enterprise architect. And they all technically comply with the definition above, but what is different is the level of responsibility. And specifically, the application architect is responsible for the application, single software product — he is hands-on with code, actively cooperates with developers and managers. From my experience, there is almost always an application architect even if he has no label like that in his/her LinkedIn profile. Solution architects get a higher level vision and are responsible for a solution, a system of multiple applications or projects, interacts with multiple teams. He/she usually relies on application architects, or directly developers, but also hand-on with code, even though the level of detail is less. And finally, the enterprise architect handles the system of systems — you will deal with technologies in the industry. And still, I think the actual work will depend on the architect’s personality, company needs, and state.
You can consider those as steps on a ladder, and in some way they are: higher on the ladder > more responsibility > higher rates. But also they are significantly different in scope and type of work. So if you thrive in one position, you might not in the other. And I think it’s best to find a position you will be happy in the first place.
Architect Hats
Software architects are industry experts, negotiators, and first of all team players. But let’s go one by one, in short, I promise.
Industry Experts
When product owners talk to you — they expect you to understand them. But when engineers talk to you — they expect you to understand them. Actually, everybody expects you to understand them — you are an architect for god`s sake! And this is not easy to understand people with different backgrounds and professional priorities. So, you need to keep yourself hands-on with current technology trends, learn your business industry nature and talk to people around you all the time. In the end, you are the part of that glue, that makes a company of diverse professionals create the right thing in the right way.
Negotiator
When people with different backgrounds and professional priorities come together to create something, they will all pull the cart in different directions being 100% sure they are right. And they are in their own sense. And very often in a company, the loudest get the most value, even if it’s far from optimal for the product overall. The priorities thing is the responsibility of the product owner, of course, but it’s often hard to see real weights on the chart to make a weighted decision. One of the popular issues in companies over different industries is when short-term revenue-generating solutions significantly prevail over long-term technically important tasks. That leads to technical stagnation and the long-term unsustainability of the product. The architect’s role is to bring a balance between revenue generation and technical sustainability to ensure that the product will last.
Team Player
There is a lot on the architect’s plate and at some point, it becomes apparent that he/she can’t do all of this alone. The architect needs to be close with different departments and teams, getting to know their strong and weak sides, their pain points, and needs to negotiate that balance and grow his/her expertise. In the end, it’s all about the company and its people, not about the architect. When personal ambitions grow bigger than the sense of common good the architect turns to the “Dark Side” and brings more value to his resume, than to the company he works in and this is a bit different story.
Architect Traits
To wear the hats mentioned above it’s obvious that the architect needs to be: technically competent, which comes with experience and watching the technology trends; have good soft skills to communicate with different teams, kinds of professionals and negotiate the priorities. But I would like to talk about less obvious things that I believe are important for the architect.
Strong Background
Of course, there are multiple cases of different successes with different backgrounds. But I believe it might be a survivor’s errors. And to be a good architect you need to have a strong background in fundamental knowledge, such as mathematics, analysis, algorithms, and design thinking. For myself, I got it in University, where I studied applied mathematics and got plenty of fundamental knowledge that builds your structural thinking and problem-solving skills. It might look like I am not using this in my daily job, cause I am not building splines, complicated equations, and math models. But when working on all of those in my early days it built me neuron connections that define how I think today. And I saw exactly this when training junior developers with no background in sciences — they understand how it works, but it’s much harder for them to manipulate complicated structures than junior developers with a background in sciences. Don’t get me wrong, they still manage to learn, but eventually getting this background later and giving away more energy and time.
Sense of Common Good
Even if you are the best industry expert in the world, if your motives are wrong — you won’t get it right. When I say sense of common good, I mean a few things.
First of all, an architect needs to agree that it’s not about him. For example when choosing a technology for a project. If you want to put that technology in your resume — it’s a wrong motive. If you just have more experience with this technology — it’s a wrong motive. It’s about the common good — you need to choose what fits best by analyzing multiple perspectives.
Secondly, an architect needs to agree that he is not here to please anyone. Nor the engineering team to constantly do the fun stuff over boring, nor the product team to constantly drive short-term revenue-generating projects that will bury the solution in technical debt. It’s about the common good — you need to keep the balance so that everyone gets what they need, without hurting each other interests and help everyone to understand the reasoning.
And my last point regarding the common good is that architect needs to fill in the gap. What I mean, is that by having a high-level overview and understanding of the way things are in the company, you can identify weak parts in the company. Perhaps, you love doing X, but if you see that there is a specialist who can cover X, but no one covers Y, maybe you can delegate X and work more on Y, at least before you grow someone to cover this further.
How to become an Architect?
Growing into an architect in my case looked like this. I have a strong academical background and working in engineering positions I always tried to dig into the essence of the problems to fix them, while taking more responsibilities in the scope of projects I worked on. Then I got an opportunity to become a technical lead of multiple engineering teams, where I got a significant boost in soft skills and multi-department communications. I faced all the time engineers who struggled with the technical issues in the company that they believed were constant. And I was looking to processes and different means of changing the way things are, what people saw wrong or inefficient so that things started to change for the better. At some point, I got an opportunity to become an architect and I took it.
That’s it.
Before this happens I did not have a conscious career ambition to become an architect — I didn’t look for courses and literature about architects. Just at some point, I realized that I am doing an architect’s job because no one did. And I was filling the gap, that luckily suited me well.
So my advice would be to work on your background, training your system and design thinking. If you are a developer right now — try better understand the tasks before you, not only how to do them, but why it’s decided to be done. Is there a better way to get to do it? And then discuss it with the stakeholders. cause talking about things with other people help you widening you expertise. Being an architect is being a bridge between the business and technology, so, in some way, becoming an architect is about why and how rather than how and with what.
And show that you care. And keep an eye on opportunities around you.
Closure
There are a lot of articles about how to become architects, what books to read and certifications to pass. They are all probably true, but also they might not be perfect for you, because I believe every architect’s path is unique. So there is no clear specific step-by-step guide you can follow. At least the one I would believe in. And about books… I said I did not read books about it before I become an architect, but now I bought a few I can mention:
Just Enough Software Architecture: A Risk-Driven Approach by George H. Fairbanks
But also I read a lot of books like those, that are not about architecture:
The Undoing Project: A Friendship That Changed Our Minds by Michael Lewis
Drive: The Surprising Truth About What Motivates Us by Daniel H. Pink
Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity by Kim Scott
And others. So, learn and try to do your best is my advice. And keep an eye on the opportunities that spawn around you.
