You can find a teamlead roadmap here. I created a first draft of the same thing, but for a solution architect. If you see yourself as an architect in future and you want to know what skills are required and how to learn them - you're at the right place. I would like to guide you through the roadmap here.
Roles and Responsibilities
As we figured out in the previous chapter, an architect typically plays a bunch of roles. For example, the architect should be able to adjust the development processes and practices so that they support the fulfillment of the project requirements. For example, install the quality gateways in the CI/CD pipeline or adjust the sprints, or ensure the small size of the users stories. This is the role of a scrum master.
Another responsibility is the requirements gathering. The architect plays the role of a business analyst from that perspective.
Also, the architect is doing a job of a technical writer who writes the documents, draws diagrams and manages the knowledge.
The architect is also a software developer; otherwise the person goes straight to the well known ivory tower of software architecture. The architect might implement some Proof of Concepts for the new features employing new technologies or create the tools for the teams, or implement some non-critical business features.
The architect plays a role of a consultant as well. Business frequently wants to know how different solutions compare between each other, what would be the best fit and how much those solutions cost. This is highly important as return on investment(ROI) is one of the key indicators the business uses to make decisions.
Skills set
This is an opinionated skill set which is subject to change in the future or by your feedback. Do not hesitate to leave it in the comments sections down below.
I believe the architect should have both hard and soft skills. Let's start with the latter.
Soft Skills
You may saw the architect communicates a lot with stakeholders, teams and other architects. First of all, the architect should be able to identify the stakeholders and manage them. The architect would communicate with them with project risks, updates, etc. He or she will also prove their solutions are viable to some of the stakeholders. This is the key factor of being able to speak publicly and persuade. I practice it a lot: for example, if you need to sell a solution to your CTO, you prepare a deck and pitch it. You also might want to share the expertise internally to spread the knowledge of your solution and give some public talks on the conferences for the sake of the technical brand. Architects frequently participate in both activities.
Also, an architect negotiates with peers and a customer. For example, some functionality may not be feasible up to a particular deadline, so the architects suggests other options or requests additional resources.
Also, conflicts are inevitable between the stakeholders and the architect is the person to resolve them.
Hard Skills
If an architect doesn't have a clue about the technologies he or she works with, well, I would not say this is a good architect. Usually we are speaking about T-shape engineers, where you have great understanding and hands-on experience with at least a single technology, and some experience with others. Of course, it is even better if we're having an M-shape person: deep experience with several stacks, like mobile development, frontend and java microservices. The architect can also play a role of an application architect for a particular component of the target system and mentor the developers of this component.
Aside from the technology itself an architect should know how to build the system based on the requirements. It includes knowing the tactics to fulfill particular requirements regarding availability, scalability, performance, security etc. As well as tactics design patterns of system design are highly valuable.
The system should run somewhere, so the knowledge of cloud technologies is a must nowadays. The architect should comprehend compute components, data storage capabilities, networking, monitoring, and many other stuff available in cloud providers. The list also includes tools to work with data streaming, machine learning, messaging, big data etc. I am not saying the architect should be hands on with everything, However at least the understanding of capabilities and tradeoffs is required.
The knowledge of cloud itself is not sufficient, as there are several approaches to actually run code: from bare metal and virtual machines to managed container clusters and lambdas. Understanding the tools of managing infrastructure and runtime environments are valuable for the architect too.
The high percentage of systems typically have some user-facing components such as websites and mobile apps, so at least a high level understanding is required here as well.
Going through the roadmap
The roadmap is rather broad and you may require a year or two to go through it. The roadmap contains links to the books, courses, articles, videos, and other materials to help you.
Books
First, you need to read books. Here you see I have books on cryptography, clean code, site reliability engineering, Kotlin, Kafka, risk management, NoSQL, DevOps, computer networks and others. I write the books reviews from time to time, you can find them by the appropriate hashtag.
I read both paper editions, as well as online ones. From the recent books I can mention Fundamentals of Software Architecture by Neil Ford. I like the book a lot, as it maps on my experience really well telling the proper ideas of working with requirements and managing tradeoffs. It is written in a very live manner, it rarely happens with architecture books :) Another book mentioned in the roadmap is Software Architecture in Practice. It is pretty academic, so should you experience any issues with falling asleep, the book can help with that. Jokes aside: despite being a bit boring, it guides you well through the system design tactics, which are an essential part of the roadmap.
Regarding diagrams and documenting the architecture a good choice is Documenting Software Architecture. It is a bit boring as well, however it provides proper framework on how to think about documenting software systems, what the viewpoints are, how do you approach the documentation etc.
The last book I will mention in this post is Designing Data Intensive Applications also known as a "a book with a hog" . It is an absolute must for architectures today, I am going to make a book review relatively soon.
Trainings
Books are good, but you can't become an architect only having theory in your head. You need to do something with your bare hands, and trainings can help with that. You can start with some architecture cloud exams for popular clouds platform. I am personally a former Professional Google Cloud Architect, and preparing for the exam provides a great foundation for both understanding cloud technologies and designing software systems employing them.
You can pick some of the courses of Coursera, like Preparing for Professional Google Cloud Architect Exam. I also highly recommend Acloudguru.com. The folks created a lot of courses for Amazon, now they also have materials for GCP and Azure. I went through some of them and liked it a lot. In particular they helped a lot to work with AWS, which I had several side projects with.
Also you can find some internal courses inside your company. In EPAM Systems in particular there is a Solution Architect School. In Tinkoff, I help running the School of Architecture. Chances are there are some courses inside your company as well, but if not... well, we're hiring :)
Also there are some materials on the internet like System Design Cheat Sheet, System Design Primer, a youtube channel and many more.
In order to practice you might want to solve architecture katas.
Ok, folks! That's it for now. Please leave comments with the feedback down below in the comments section, don't hesitate to submit pull requests or issues in the roadmap repository :)
Don't forget to smile alright! 🤩
Also, if you liked the article, don't forget to Subscribe to get notified once a new article is published. Sharing the article in your social networks is always welcome as well.