Programmers and software engineers are in high demand today. In particular, those programmers who adapt to the new technological challenges and evolve their skills are more likely to grow professionally. A natural career path for experienced engineers to push forward their lifework is transitioning towards a software architect role. In a software project, the software architect is the person who has the authority to makes the technical decisions of its architecture and stay responsible for them. It doesn’t matter how big or small a software project is (or company); the software architect is a key person for the future of the project. Therefore, most architects are considered valuable assets in most organizations, which implies holding generous salaries and enjoying a position of power there. This position requires a high level of authority and responsibility. In this post, I’m going to explain what these two words actually mean and discuss the necessary skills to become a competent software architect.
The Market
The term “architect” is borrowed from traditional construction. When constructing a building, a plan is needed, as well as a team of trained construction workers with a capable foreman to lead them all. The architect is the foreman in charge of determining the construction procedures to follow. His job consist in translating the desires of the builder owner into more detailed plans and instructions that the workers can understand. This requires taking crucial decisions, such as the location to place the building, the materials and construction tools to be used, etc. If the architect is wrong, the structure of the entire building can break down, to the point of eventually causing it to fall to the ground. Thus, his decisions are really important for the project.
As occurs in construction, the software architect is someone responsible for the future of the project. He acts as the right hand of the person that holds the highest position of power within the organization, a.k.a the Project Manager (PM). In this context, the architect is the guy to be praised or blamed depending on the technical results obtained. The job of the PM is to make sure that no one doubts every technical decision the architect makes. In most projects, the architect executes both technical and managerial decisions. The software team needs someone personally responsible for the quality of the software being developed. The PM delegates the quality control to the software architect, and it is up to him finding the mechanism to delegate it further. This is what delegation is all about. Responsibility should always come with power.
As Yegor Bugayenko says in his book Code Ahead, group responsibility is the most terrible mistake a team can ever make. Therefore, in most projects, there should be only one architect on the team. This decision is crucial for the future of the project. In most situations, the architect should act as a technical dictator with the ability to analyze and embrace reality, collect all available differing opinions, and find the best possible option while leaving personal emotions aside. These particular skills make software architects a scarce kind of leaders. And as with everything else, scarcity, when combined with high demand, increases the market value exponentially.
The Value
If you are a developer, you might consider advancing your career to become a software architect.
However, it is impossible very difficult to become a software architect without years of experience grinding hard as a developer.
An architect needs to have experience developing software, but other skills give it its value.
This is because most developers are concerned only with the development phase of software, whereas architects deal with the design, implementation, testing, and releasing phases of the product.
Architects are people who plan what to do and how to do it.
Developers write code that is encapsulated into packages, configure hardware and software, install the network, and perform similar hands-on tasks.
As explained in the book Design It!: From Programmer to Software Architect, by Michael Keeling, transitioning into a software architect role is a natural step for successful developers.
When building a software product, architects need to have a proper understanding of what they are making.
What is its purpose?
The architect designs and connects the artifacts, how each module will be built, how these modules will be integrated, etc.
A pragmatic architect is particularly valuable at the beginning of the project, when the rules of the game needs to be dictated.
He should also be hands-on with the code.
For example, in a Java/Maven project, creating some initial files, configuring the pom.xml, setting up the CI environment, and adding the README.md are probably the first steps an architect will make.
Being promoted as a software architect gives not only a significant boost in the perceived salary. The promotion implies positioning the architect as the man in power, not just a highly-skilled software engineer. This role involves great responsibility and commitment. Together with the credit received from happy PMs (when the results are good), architects may take all the blame and responsibility if the project sinks. Dealing with such a responsibility demands skills that not every developer possesses. And that is exactly the reason of the architects’ value.
The Skills
To recap, software architects have two primary skill to master: responsibility and authority. The architect is responsible for turning a concept into a realizable plan for delivery. For example, identifying the gaps in the enterprise architecture, or running up an initiative on a portfolio roadmap. To do so, an architect must collect different opinions before making his own decision. Even if he doesn’t have all the merits of “the ideal architect”, his decisions should be always final. Thus, an architect must be responsible for the entire success or failure of the product, establishing the business issues to be solved, and putting all the options to solve them on the table.
In Chapter 1, the excellent book Fundamentals of Software Architecture refers to eight core skills to be expected from a software architect:
- Make architectural decision
- “An architect is expected to define the architecture decisions and design principles used to guide technology decisions within the team, the department, or across the enterprise”.
- Continually analyze the architecture
- “An architect is expected to continually analyze the architecture and current technology environment and then recommend solutions for improvement”.
- Keep current with the latest trends
- “An architect is expected to keep current with the latest technology and industry trends”.
- Ensure compliance with decisions
- “An architect is expected to ensure compliance with architecture decisions and design principles”.
- Diverse exposure and experience
- “An architect is expected to have exposure to multiple and diverse technologies, frameworks, platforms, and environments”.
- Have business domain knowledge
- “An architect is expected to have a certain level of business domain expertise”.
- Possess interpersonal skills
- “An architect is expected to possess exceptional interpersonal skills, including teamwork, facilitation, and leadership”.
- Understand and navigate politics
- “An architect is expected to understand the political climate of the enterprise and be able to navigate the politics”.
The architect should be, of course, an expert in the technical domain. But he should also listen to everybody and take their opinions into account, being an effective communicator and negotiator, just as a diplomat. The architect should communicate with the team through project artifacts, not directly. Because artifacts preserve reasoning for a much longer period than a temporal form of communication (e.g., a conversation, a meeting, etc). This requires tecnical and social abilities, knowing how to work with people: recruit, motivate, and direct their results.
Being a good coach and a teacher is a characteristic that great architects have in their skill sets, developing patience is key, especially when dealing with PMs. An architect is connected with technology because technologies change rapidly in the software engineering domain, and most of the time, using one technology stack could impact the design. The architect has abstract thinking, which means that he thinks globally a sees the product as a whole, delivering his ideas in simple words. He is also strong, which means that he has the ability to say “no” when it is difficult to do so; and disciplined, caring about software quality, processes, and rules to enforce them as much as possible. The ideal architect is loyal. He doesn’t abandon the project as most developers might do. He is also sincere, accepts his mistakes, and takes responsibility.
That being said, architects are persons, too. As such, they may take wrong decisions sometimes. To mitigate this from happening, the contract between the project and the architect must clearly explain how architect’s results are validated. In case of misunderstandings, PMs should use documents to correct and point architects in the right direction, e.g., adjusting the requirements and architecture documents written at the beginning of the project. The PM expects a weekly report of the project that includes: scope, status, issues, risks happening in the project. This keeps the project going and prevents the architect to commit an irreparable mistake.
Conclusion
The software industry has a high demand for qualified software architects. These professionals have a very high value within organizations. They have the necessary skills to deal with technology and people, which requires a rare combination of talents. That being said, the architect is not an expert capable of solving all technical problems. Thus it is essential to control the quality of the decisions the architect makes via regular reviews.
Are you ready to level up your career becoming a software architect? If not, why not?
