What makes a technical architect?

An architect is a person who understands an array of concerns related to a project and creates/oversees the overall development strategy of the project. The person has to foresee any possible setbacks, create contingency plans for the same, knows where corners can be safely cut often to ensure the project is delivered on time and as per requirement as well as within budget.

A technical architect is no different, is a person that understands the technical stack of the project in thorough detail, creates the overall execution strategy which includes choosing the stack, different components as per the requirement and team feasibility. He/she is also often involved in creating the foundation of the project and also oversees the overall execution of the project.

The role of the architect is quintessential to any project and a good architectural base plays the most crucial role in delivering the product on time and keeping it on track. In a technical company, this role is best played by the CTO of the company but can be played by a technical lead or a technical manager as well.

Well, I emphasise the technical part of the equation as it is a basic pre-requisite of the project and in-detail knowledge of different components helps the architect make a reasonably sound approach. Though I have found being technically sound is just one aspect of the role and other aspects are equally indispensable. In this article, I will be mainly focusing on the role and its main responsibilities.

What does the role of a technical architect consist of?

The role of a technical architect is often underplayed and abused in software projects but is an essential asset of the project. The architect is supposed to play a significant role in the following key areas:

1- Business Understanding/Project & Resource Planning

2- The Bigger Picture

3- Initial Code Bootstrapping

4- Art of making Trade-off

5- Leadership

1- In most cases, Success of a project boils down to how well do the people working on the project understand the requirements. A good architect can go long way in bridging the gap between the developers and the stakeholders while providing significant value to the project itself.

The Architect is supposed to understand business requirements & features promised by the sales team and convert everything into an achievable road path which can be achieved in a time-bound manner by the technical resources available. Quite often the requirements are misunderstood or taken by the word, whereas better solutions can found for the problem. The idea is to focus on the problem rather than the solution.

For example: choosing a new language/stack where the team would be required to pause and start from scratch is probably a poor decision unless the problem really requires it. I have seen multiple cases of leads accepting all the requirements from sales/upper management and agree to an insane timeline, which in essence sets the team for failure/burn-out.

Converting business requirements into a project timeline is a fairly complex process, but as said by the jogging baboon, it sure gets easier once a person does it multiple times. The topic is huge and I hope to cover it in a separate blog post.

2- The bigger picture might be what separates a freelancer/programmer from the architect as requirements keep on coming and systems keep on developing an infinite amount of technical debt and inter-component dependencies. Newer team members often fall for the fallacy that rewrites are the solution to all their problems, technically they might even be correct, but the answer almost always lies somewhere in between. Such situations often lead to developers asking for a complete rewrite, which actually doesn’t really add any business value.

A good architect would accept the flaws of the system, would take the team into confidence and create a longer sustainable plan keeping in project timelines/requirements in check while addressing the issues which are quite often sorted by their business value.

3- Getting the project off the ground is a lot of work and involves a lot of decision making. Although team consensus is important, it becomes a tad difficult to achieve in larger teams. The lead taking the team into conscience should make an informed decision on the level the autonomy team can function and deliver on the project. Decisions, when felt like being shovelled down the throat of the team, can bring the morale down or even break the team.

4- Trade-offs are an indispensable part of technical projects and it is another tricky area where are no rights and wrong. All decisions made here almost always lies in the grey zone, which can turn both right and wrong from different perspectives. Decisions made here should be evaluated entirely on the basis of their execution, as the results achieved here are often an amalgam of various factors. An Architect is responsible for overall technical quality whereas the developers often take lower implementation decisions. You can getHow long your mistakes take to get rid of.

5- Authority and leadership: The theme that is common in the above 4 points is the ability to make your team and the stakeholders to buy in your decision. An architect is expected to share and apply his broader experience gained from years in the field and make decisions that have a lasting effect.

Having a good and diverse background with sound and well explained technical decisions helps the architect to establish his authority in the team as well amongst the stakeholders. Winning the trust of your team can only be achieved by making your team buy in your decisions which a test of the leadership skills of the architect. Using your authority to ram decisions through your team only does irreparable damage to the morale and motivation of the team.

Who is a good architect?

Taken from a blog of a Chinese company, there are three tiers of architects.

The first tier architect sees only the product. The second tier architect sees the product as well as the overall solution whereas the third tier Architect sees the business value of the product and consider it to be of prime importance.

My time at Aftership Ltd. and Nanonets Inc has made me appreciate the importance of business value which should be the driving factor of the project, which often appears as a counter-intuitive idea to my technical peers.

Well, a good architect prioritises business needs and converts them into sustainable and attainable development goals.

I remember a conversation with Teddy Chan, CEO Aftership, where he emphasised on creating and delivering business value for the customers instead of focusing on creating technology. Here I am not saying, creating new technology is bad and incorrect, but actual problem-solving products should be built around users with the focus on delivering the actual value and a good architect uses the existing technology, unless the new technology is crucial for the product.

This mantra syncs with the famous, do not reinvent the cycle unless the path requires it.

A small introduction of me is now warranted, I am a self-taught programmer/architect/startup enthusiast who has worked on an array of products in a lot of different verticals and have come to understand the nuances of different stages of technical projects like planning, execution, delivering targets using various methodology. I have also mentored a whole lot of students and developers as the Lead of a local Google Developer Group, as a CTO of my previously failed startups and it has helped me gain valuable hands-on experience on managing teams.

I hope you liked the write-up! If so, you can follow me on Twitter.