Have you worked with Software Architects on your project?
If yes, did their presence matter?
Depending on your experience and role, your answer might fall into 3 broad categories:
đ What the hell are YOU even talking about? They were absolutely vital.
đ You know what! They were a BIG nuisance.
đ Iâm an ARCHITECT. And how dare YOU ask these questions?
Hello đ and welcome to a new edition of the DevEvolution newsletter.
Every Friday, I send you an email like this with actionable advice on a topic that can help you grow in your software engineering career.
The topic for today -Â Is the Software Architect Job Role Dead?
And before you grab your pitchforksđ´, let me tell you that I absolutely love the Architect role.
Hell, I happen to be a Software Architect, and some of the best engineers I had the privilege of working with have been architects.
However, off-late, I have started noticing that the Architect job role has lost a bit of relevance within the developer community.
There is an increasing amount of online discussion that the role is absolute trash and does not deserve much merit.
Why am I writing this post?
đ First, I like talking about controversial topics.
đ Second, as a developer turned architect, I want to offer some actionable items that can make the Architect role more relevant.
Hereâs the agenda:
đ°ď¸Â Whatâs wrong with the Architect role?
đ The Evolution of Software Development
đ§łÂ Thoughts on how the Architect role should evolve.
đ°ď¸Â Whatâs wrong with the Architect role?
Let me be honest here.
Not everything is right with the Architect role in a lot of places I have seen.
đ In many large organizations, the Architect's role is confined to churning out document-upon-document of best practices, creating blueprints for system design, and generally telling the development team how to write code.
Not necessarily a bad thing.
But it does not work as expected when the Architect is treated as a separate God-like entity whose job is to dish out platitudes and issue guidelines without any skin in the game.
This approach is also known as the ivory tower approach.
Itâs like the architect saying âI donât have time to write code because Iâm too busy telling other people how to write code. But if the code breaks for some reason, itâs all on you because Iâm just here to provide guidance.â
Itâs not difficult to understand how this can lead to a lot of friction within the team.
Over the years, one thing I have seen is that many software engineers donât like to be told what to do from a pedestal. Either you go collaborate with them to solve problems or you stay out.
âThings designed by people without skin in the game tend to grow in complication (before their final collapse).â - Skin in the Game by Nassim Taleb
đ Surprisingly, the reverse is also true. In many other organizations, the Architectâs role is anything, but that of an architect.
This is an equally embarrassing situation because, despite the on-paper role, the Architect is practically scrambling to finish their quota of bug fixes and feature requests. Just like every other member of the team.
There is no time for taking a more holistic look at the system and coming up with scalable solutions.
This is like the organization saying âYou are a valuable resource and we want you to feel that way. Hereâs the Architect job role where we want you to make a big difference to the future of the system. Now, go and solve those bugs because the customer is looking for them ASAP.â
đľNeedless to say, both situations make things difficult for the person playing the Architect role.
If you are an ivory tower architect, people hate you for doing nothing but nosing around their work. Moreover, your own tech skills deteriorate over time and you are left with no choice but to dial up your ivory tower role.
If you are just a paper architect, your teammates hate you because you got the shiny title without doing anything to deserve it. After all, they are also doing the same stuff as you. What gives you the badge?
The situation is like being between a rock and a hard place.
But what has caused this imbalance?
In my view, modern software development has a big role to play in creating this imbalance.
Letâs find out how.
đ The Evolution of Software Development
Over the last few years, how you develop software has changed dramatically.
đ Gone are the days of creating super-detailed architectural blueprints and the months devoted to producing the ultimate bullet-proof design that would solve all problems.
đ Also, gone are the days when one person entered a transitive state of higher cognition and came up with this magical all-encompassing design.
Software development has now become a lot more iterative and collaborative.
A lot of problems that earlier fell within the architectâs domain have become easier to solve with better tooling.
For example,
Cloud platforms provide excellent auto-scaling capabilities. Questions about computational resources that were usually answered by Architects are pretty much gone.
The friction with deployments has been significantly reduced due to the advent of tools like Kubernetes.
Profiling tools have made it trivial to run static analysis on the code, measure performance and visualize the data.
Radical changes to the overall software development processes have caused a tremendous shift in the responsibilities of modern-day Software Architects.
But the mindset has not changed.
In some organizations, the Architects are entrenched in their rigid position whereas, in other places, they have completely lost relevance.
Clearly, this situation is not tenable. Something has to change.
đ§łÂ How the Architect Role should function?
Despite the changes to software development, the Architect job role hasnât evolved much over the years.
In my view, this is the root cause behind the dis-enchantment with this particular role.
I still think the Architect job role is extremely important to the success of any software team.
However, I strongly feel that the execution of the role needs to change.
Here are a few things that can help the Architect role stay relevant and useful to the organization:
đ Get rid of Ivory Tower Architect Mentality
Stop treating architecture as a solo role. Make it collaborative.
Teams are like units with cross-functional capability tasked with the job of delivering a product.
By all means, have someone with the designation of an Architect but embed them as part of the team rather than a separate entity that pays a visit once in a while.
Architects must have skin in the game for them to be valuable to the discussion.
đ Treat Architecture as a Core Engineering Skill
Donât treat architecture as âsomeone elseâs problemâ. Make it a core part of every developerâs job.
Most times, the developers only focus on their small piece of code rather than thinking about the bigger impact. The obvious argument is why they should care because itâs not their job
It is always useful to have all developers think about scalability, maintainability, performance, and so on.
đ Coach rather than Commander
A Software Architect who has risen from the ranks is a treasure trove of knowledge.
They have seen a lot of ups and downs and generally have a more nuanced experience of things within the context of an organization or a domain area.
Making such a person act as a commander may not be the best use of this knowledge. It alienates them from the team and results in one-sided decisions.
An Architect must act as a coach/mentor to guide the team through tricky solutions.
đ The Tour of Duty Architect
What does an architect need to grow?
More knowledge and expertise. More time in the trenches.
What better way to do it than by encouraging a tour of duty concept when it comes to the architect role?
This way an architect can get exposure to a wide variety of problem domains.
Not only will it enhance their skill sets, but also help them avoid the trap of becoming obsolete in the long run.
đ Architect-Engineer Pendulum
If you are not an embedded architect in a team and donât get much chance for any real programming work, you might be in trouble.
Chances are that your technical skills are catching dust. This is an alarming situation for your career.
To mitigate the risk of skill degradation, it can be beneficial to create a system where an architect plays the role of an engineer every few years.
The practice is not so different from engineering managers spending time coding every few years to keep themselves in tune with actual hands-on work.
đšď¸ Over to you
Do you think the architect's job role should evolve?
If yes, what are your suggestions on how to go about it?
Write your thoughts about the whole thing in the comments section.
And thatâs it for now!
If you are finding this newsletter valuable, consider doing any or both of these:
đ Support the Newsletter - if you havenât done so already, consider becoming a paid subscriber.
đ Share it - Progressive Coder grows thanks to word of mouth. Share the article with your friends or colleagues to whom it might be useful!
Wishing you a great weekend ahead! âď¸
See you later.