Introduction

"Architecture is about the important stuff... whatever it is." -- Ralph Johnson

Architect is a position with powerfulness and respect. When you hear that someone is an architect of a company, will you feel a sense of awe? Architects are usually believed to be relevant to system design, technical strength, leadership and influence. It is precisely for this reason that many of the positions of architects in the enterprise are held by experienced and skilled senior software engineers. However, the definition of an architect in the software industry is not quite clear: cloud service providers such as 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 are nothing more than using his rich experience and excellent strength to solve technical problems, which is equivalent to what a senior software engineer can do. These are very different from the omniscient architect who designs the architecture diagram.

The concepts related to architects in this article mainly come from a book Fundamentals of Software Architecture (authored by Mark Richards, Neal Ford) that I have been reading recently. This article will briefly introduce about what a pragmatic architect should do and required skills.

Chief Engineer

First of all, an architect should be a chief engineer of the entire software project, who is responsible for the overall design, implementation and quality of the software project. Therefore, for software architects, they need to have excellent programming skills, good understanding of the software project development process, and a certain breadth and depth in various technical areas. Not only that, because the architect is the chief person in charge of the technology side, he (or she) usually needs to think it through, from a perspective of the system as a whole, about how the various modules interact, whether the division of functional services is reasonable, where the bottleneck of the whole system will be, and so on. These are all in the technical area.

When a software engineer has been engaged in many projects, he or she should have some deep understanding of software engineering and architecture, and with some system learning, he or she could ultimately become a qualified architect. Therefore, with technical consideration only, a software architect is equivalent to a senior software engineer.

Is Architecture Diagram Necessary?

You may have seen more or less some architecture diagrams: hierarchical architecture diagram, physical network topology diagram, flow diagram, interaction logic diagram, etc. But to answer the question that whether the architecture diagram is necessary, we need to understand the reason behind it. The main purpose of the architecture diagram is to help internal engineers or external technicians quickly understand the system module information contained in it. Therefore, those seemingly cool, professional and pleasing architecture diagrams, if lacking in meaningful content, would not be helpful for understanding. Instead, it is the architecture diagram which is simple, clear and easy to understand, even if looking ugly, that will be helpful for software developers. Therefore, the architecture diagram is necessary, but on condition that it reveals the system module information with simpleness, conciseness, and clearness.

Not Only Tech

As mentioned earlier, the architect, as the chief engineer of software engineering, will take technical responsibilities. But in reality, few architects can work on a project smoothly if they only focus on the technical bits. A successful architect, or an influential architect, needs at least good leadership or team management skills.

Half of the eight skill requirements for architects in Software Architecture Foundation are not directly related to technology. Let's take a look at the technical and non-technical requirements mentioned in this book.

• Technical Requirements
  • Make architecture decisions
  • Continually analyze the architecture
  • Keep current with latest trends
  • Diverse exposure and experience
• Non-Technical Requirements
  • Ensure compliance with decisions
  • Have business domain knowledge
  • Process interpersonal skills
  • Understand and navigate politics

You may be surprised at the non-technical requirements for architects, such as why architects need to consider politics? As a young junior developer, I did not understand at first, but with the continuous accumulation of project experience, I found that many architectural decisions were not only from the technical rationality of the architecture itself, but also related to corporate politics. The politics we mentioned here is not bureaucracy in the traditional sense, but more referring to the cooperation or competition between various departments. This is particularly important for large companies. I will not elaborate in detail here, but may write an article later for this topic.

Continuous Improvement

Unfortunately, many architects promoted from software engineers continue to stick with their technical skills, ignoring non-technical things. Therefore, it is emphasized in this article that the responsibilities and requirements of architects should not only be restricted to technology and architecture themselves, but also more importantly focused on non-technical skills and experience accumulation. For example, how do we balance compliance, resources and development efficiency? What business value does your software project provide and what impact it will have? How to explain professional terms to non-technical personnel (especially the boss)? When external departments refuse to cooperate, how do we navigate to ensure the project success? Such issues require non-technical skills and experience significantly, and architects who would like to pursue their career goal should take them as necessity. When you step out of your comfort zone, your are probably more like to enjoy continuous learning and growing.