How to be an Architect?

The one question which I asked a lot while being a developer half of my career. And is a common question I receive working as full time Solutions Architect. I rarely got 2 similar answers to the question. But it is somewhat agreed understanding that Architects in a technical team are very senior people who should know everything. This is not a complete truth and nor a lie. What architects are supposed to do (I believe) still varies from organisation to organisation.

Types and Kinds of Architects

In my career I worked in 3 countries and many organisations. And the very definition of “Architect” is not same everywhere. Sometimes architects are extremely technical, they can code features and infra, create diagrams and present very complex solutions to non-technical stakeholders, manage budgets, have SLAs and KPIs, experiment and maintain the technical roadmap, understand security, cloud, business domain, integrations, architecture, development methodology, team dynamics and much more. These kind of architects are Angels to know and work with. A software engineer might grind under them but true growth is exceptional.

Another kind; enterprise and sometimes solution architects are quite theoretical. They know certain tech lingo and create high level diagrams and can discuss integrations. But their core competency is system understanding and business domain. They naturally grow from Business Analysts stream rather than Software Engineering. In large organisations, such architects are the glue for communication and standardisation. Both of which are always a challenge in enterprises. These architects seldom code and are “technical” of different type. Perspective is key here; someone from deep software development background might not comprehend their importance. But there’re a lot and good reasons why the role exists.

Technical or non-technical is a separate debate on it’s own. And which specific skills to have depends. In this article I’ll share the ideas which applies to all kinds of architects and some other overlapping roles.

First Principles & Decision Making

The core skill for this role I believe is critical thinking and decision making. For any problem statement different roles in software engineering domain will have different solutions based on their perspectives. An Architect is the one which should understand all such perspectives and take decision based on first principles.

The decision making is a short expression but require a number of capabilities to do it right. It’s a balancing act between below mentioned (sometimes conflicting) ideas:

technology best practices and business value
biases and preferences
planning, designing and delivery
short term vs long term architecture
tech debts vs perfect code base and practices
many more…

To be good in decision making, one should have a number of non-technical soft skills. These soft skills help architects sell their story to the wider audience. In many scenarios, everyone agreeing to the story (architecture / solutioning) is much better than partial support towards the end goal.

Soft Skills

In SOFTware Engineering I believe soft skills makes the most sense (for architects specially, sometimes more than technical knowledge). Humans create software for humans. So without soft skills, technical knowledge alone seldom works. The failure rate of software products is full of skills. Article by Forbes discusses 14 points, none of them is about tech!

Business vs tech

Every engineer at some point in her career thinks that optimised, documented, test-covered, and formatted code is the best code. That’s how the source code should be. The truth is, only code which matters is the one that creates some business value. The more senior people you see in tech, the more business they understand & support. Without business, tech in it self is worth nothing (or puny).

Every architect should understand this idea and practice it equally well. It doesn’t mean technology is not important or it’s impact is not valued. Balancing the both is the key!

Biases & preferences

Software world is always changing, so much so that no two products are built the same way. Given this, everyone has some kind of preferences and biases. These biases are due to our past experiences. We like to repeat what we have already done. It reduces the learning time and potential risks.

Bias is not only gender or the ones common in AI/ML space. There are LOT of Biases in software engineering. [1] and (https://github.com/charlax/engineering-management#biases) 2 discusses these and you’ll be amazed how much of these are common around us. It’s just that we don’t know they exists until we know. An architect should know these and identify, point & rectify them when required.

Writing

If you’re the perfect shooter or can lift 1000kg but never told anyone then you’re just wasting the talent. It’s the same if you never contribute anything back. Anyone who has to stay relevant has to read! I don’t believe there’s any exception to this rule. Same like medical profession where doctors have to read medical journals to keep them updated with latest advancements. Software professionals have to read about new architectures, programming paradigms, development methodologies, etc.

Defining & Naming

This is a hidden talent which I observed some of the great architects have. They name practices and architectures when they develop or *discover something. They productionise the tool which creates an entity in the universe which others can refer to and further build upon. Naming software have an impact on it’s stakeholders. If something has a name then it comes to life with health, behaviour, lifecycle, and other such attributes.

Some other aspects like versioning, maintaining lifecycle of APIs, nomenclature of artifacts, etc. are traits of this same competence.

*We discover best practices and patterns from iterative refinements

Architects to Follow

Given a list of skills an architect must have, there must be some role models to follow. Whatever I know today majority of the credit goes to these architects, leaders and great writers who shared their thoughts and experiences. Sharing the list for the readers:

Martin Fowler. He’s so great that few times I shared his idea and people were sceptical. When I mentioned that Mr. Fowler suggests this, everyone instantly agreed with it. His video on YouTube are amazing and his website is absolutely amazing for anyone to learn software architecture (and beyond)
Mark Richards. I attended two trainings from him and he knows the solutions of problems which we didn’t knew we’ll face in future given our tech stack and team dynamics. His YouTube channel is full of remarkable discussions.
Gregor Hohpe is someone I feel touch the philosophical aspects of Architecture and Engineering. His articles under AWS blogs are worth reading over and over again.
Some other greats I love to read are Sam Newman and Neal Ford

Cloud Architect

Cloud Architects are new beings and they demand special mention here. The special part about this role is the breadth of knowledge and skills required. We read that cloud democratise IT; it means cloud architects has to be well versed in

Infrastructure (networking, compute, storage, etc.)
Application architecture (architecture patterns like microservices, event driven systems, queues, design patterns, etc.)
Enterprise architecture (large scale integrations, costing, maintenance, tech debts, etc.)
Security, automation, management, etc., etc.

Any “good” cloud architect can’t be good in one area and be ignorant in other. They have to be a full package for the organisation. In terms of real-life example, AWS architects have a proper T shaped skillset. Yes there are specialised SAs, but even they understand basics of other domains like every specialised medical doctor have to go through MBBS.

So you might be an architect planning to explore cloud. Or in your early career thinking someday you’ll be an architect. Be open to this idea that Architects come in all shapes and sizes. And that depends on the opportunities they get in the career & projects they work on. The variable which one can control is what they love to do, and there’s a high chance that some kind of Software Architect exists which does that! Keep designing, keep learning, everyone is an architect; depending on the scale.