#25 Besides Domain Understanding: Key Things Every Software Architect Should Know
A software architect's primary mission is to understand the domain and its challenges. Still, at some point you have to support your team choosing concepts and tools that help you to solve the puzzle.
In one of my previous posts, I described three types of architects that I face the most.
The ones who:
Focus primarily on the technical side of a solution.
Focus primarily on the business side.
Focus on both the business & technical side.
It triggered a lot of questions and really good discussions. I received similar input from several people. It was something like the following:
There are so many technologies and concepts around. It is impossible to know them all. How do you know all this stuff?
I don’t. I don’t know everything. Besides fundamentals (that I think everyone should know), I observe the market and look at other systems. I repeat this every single time something major comes out.
There are several ways to look into other systems:
Talk with your friends.
Attend meetups and conferences.
Read big players’ tech blogs, such as Spotify, Uber, or Netflix, as they often share insights, and you can learn a lot about their systems.
Note: While reading FAANG tech blogs, don’t fall into the trap of blindly using similar tech. Analyze and think twice before applying any tech to your stack. These companies play in the different league with their scale and the traffic their applications have to serve. That’s why something optimal for them might not be optimal for you. Still, they are a great source of knowledge.
Next, I will prepare a list of shame (it is what I call it; don’t feel like it is anything you should be ashamed of). I will put everything I want to look at in the next few months on it and continuously practice it.
Sometimes, adding this or that to your application makes sense when it can help (profit-loss calculation, always). Sometimes, it will be just some practical exercises to learn how something works—usually, I create some application to practice it with a real-world case. If you struggle to find ideas, you can look at John Crickett's excellent list of Coding Challenges.
Learning something does not mean knowing it from top to bottom. No, you don’t need to become an expert in each tool or concept. But it would help if you knew what everyone was talking about and could decide whether to use it or not.
In the end, the tool is just a tool. You have to select tools or concepts that fit your problem, not the other way around.
Now, it’s time to show you the list of tech things that I think every software architect should have some knowledge about (the deeper, the better). This list is prepared based on systems, environments, and problems that I have been working on since 2012:
Knowing well one of the cloud providers—Azure, AWS, GCP—helps you jump into another one quickly, as the concepts are similar
Docker
Kubernetes (you can then extend the knowledge to one of the lightweight versions like k3s)
Message brokers (e.g., RabbitMQ)
Data streaming (e.g., Kafka)
Event Sourcing
CQRS
Relational databases (e.g., Postgres), Non-relational databases (e.g., Mongo). Partitioning, sharding
Cache (e.g., Redis)
Single and multiple deployment units with special attention to modular monolith and microservices. Communication (sync & async, events, commands).
API gateways, load balancers
Building APIs
Authentication and authorization
Monitoring (e.g., using Grafana and Prometheus)
Testing, especially shift-left, performance (load & stress testing), pen-testing
Security topics: I recommend primarily examining IDOR, XSS, DoS and DDoS, and SQL injection. Also, have a look at OWASP, and NIST
Please remember that your role as an architect isn't just about knowing technologies and concepts—it is primarily about understanding how to apply them effectively to solve business problems in a given context.
Is there something you would add to the above list?