By Robbert van Os
Posted on 2023-04-17T00:00:00.000Z

Uncovering the Key Skills Needed to Thrive as a Software Architect

Explore the skills needed for a successful software architect beyond just being able to draw building models. Learn about being a chief engineer, the importance of architecture diagrams, balancing technical & non-technical skills, and continuous improvement.

"Architect" is a powerful and respected job title in the business world. Many people associate architects with system design, technical strength, leadership, and impact. As a result, many architect positions are filled by senior software engineers with a lot of knowledge and skill. But the definition of an architect in the software industry is not quite clear. For example, cloud service companies like Amazon and Alibaba Cloud have their own teams of architects, but most of them provide after-sales service to customers under the name "architect". Some architects only solve technical problems, which is the same as what a senior software engineer can do. These are not what one would expect from an all-knowing builder who makes the architecture diagram.

"Architecture is about the important stuff… whatever it is." — Richard Johnson

Drawing from the insights gained from working on hundreds of architecture projects over the past 20+ years. It provides a practical guide to what a pragmatic architect should do and the necessary skills they must possess.

Chief Engineer

First, an architect should be the "chief engineer" of the whole software project. They are in charge of the general design, implementation, and quality of the software project. To be a software architect, one needs to be good at programming, understand how software projects are made, and have a lot of knowledge about various technical areas. The architect is also the main person responsible for the technology side, so they need to think about how the different modules work together, whether the division of functional services makes sense, where the bottleneck of the whole system will be, and so on. All of these are in the field of technology.

With experience working on many projects, a software engineer can develop a deep understanding of software engineering and architecture. With some system learning, they could eventually become a qualified architect. Thus, a software architect is the same as a top software engineer from a technical point of view.

Do You Need an Architecture Diagram?

An architecture diagram, such as a hierarchical architecture diagram, a physical network structure diagram, a flow diagram, an interaction logic diagram, etc., can be helpful. However, the main goal of an architecture diagram is to help people outside the company quickly understand the system module information it contains. A diagram that looks cool, professional, and nice but doesn't explain anything is not helpful. A software worker would benefit more from an architecture diagram that is simple, clear, and easy to understand, even if it looks bad. The architecture diagram is important if it shows the information about the system modules in a simple, clear, and concise way.


WTF Architecture Isn't Just About Tech

While the architect will have technical duties as the chief engineer of software engineering, they can't just focus on the technical aspects of a project. A successful architect needs to be able to lead or direct a team. Half of the eight skills that Software Architecture Foundation developers must have have nothing to do with technology.

Technical Requirements

  • Make choices about development
  • Continually analyze the architecture
  • Keep up with the latest technology developments
  • Diverse exposure and experience

Non-technical Requirements

  • Ensure decisions are followed
  • Knowledge of the work world
  • Interpersonal skills
  • Understanding of politics and how it works in the workplace

It may come as a surprise, but architects must also consider non-technical factors such as politics in their work. As a junior developer, they may not initially understand this, but through gaining experience working on multiple projects, it becomes clear that many architectural decisions are not solely based on technical soundness, but also on corporate politics and the dynamics between different departments.