preface
When you click on a recruitment APP and screen for Internet technology, there are often a few high-paying positions with the word “architect” on the list. When you click on the job details, you’ll be dissuade by its high requirements. They often require more than five years of working experience, requiring applicants to have more than three years of system design experience, proficient in various architectural patterns and system frameworks, but they do not meet any of the requirements.
Software architect is one of the most desirable but frustrating positions in the world. Just like architectural designers always have the dream to become the chief designer, aerospace workers always have the ambition to become the chief engineer, I believe that every software engineer has the idea of becoming a software architect. As defined in Wikipedia, the responsibility of a software architect is to determine major technical choices, design the main framework of the system, and implement it according to requirements during software system development. However, the skills required by an architect go far beyond technology selection and system design. This article introduces the definition of software architecture and some of the skills required to become a software architect to give you a better understanding of the role of software architect.
Most of the ideas in this article come from the book Fundamentals of Software Architecture, which is recommended for more details.
Definition of software architecture
For Software Architecture, we usually think of it as the blueprint of a Software system, but it is often difficult to give an exact definition. Wikipedia defines software architecture as an abstract description of the overall structure and components of software, used to guide the design of various aspects of a large software system. However, this definition is also one-sided, software architecture is not only the overall structure and components of the system, these alone are not enough to guide the design of a good software system.
Mark Richards and Neal Ford describe software architecture in four dimensions, They are Structure, Architecture Characteristics, Architecture Decisions and Design Principles.
Structure
A Structure describes the architectural style used by a software system, For example, layered architecture, event-driven architecture, Microkernel architecture, and Microservices are the most common Architecture, etc. When you ask an architect what architecture a software system uses, and he tells you, “The system uses a microservices architecture,” he is simply clarifying the architectural style of the system. To understand the software architecture of the entire system, an in-depth understanding of architecture Characteristics, Architecture Decisions, and design principles is required.
Architecture characteristics
Architecture characteristics are also commonly referred to as non-functional requirements, such as Availability, Scalability, and Reliability. Architecture Characteristics are often overlooked by software novices, but they are very important for software systems. If functional requirements determine the lower limit of a software system, then non-functional requirements determine its upper limit.
Architecture decisions
Architecture Decisions describes the rules that must be followed when developing software systems, such as the example in the figure. For a hierarchical Architecture style system, development engineers need to follow the following rules: only the business layer has direct access to the service layer, and the presentation layer does not. Architecture Decisions is more of a constraint, the violation of which may not affect the functionality of the system, but is a source of architectural corruption.
Design principles
Design Principles are system Design principles that guide the development team to choose a technical solution that best fits the characteristics of the system. Design Principles give a direction, not a concrete implementation. For example, the system design principle shown in the figure is that asynchronous communication between microservices should be used as much as possible to improve system performance. Design principles do not restrict development teams to implementing asynchronous communication through REST or RPC.
Skills needed to become an architect
Just as software architecture is more than just the overall structure and components of a system, it is not enough to be a software architect only to be able to select technology. A qualified software architect should possess the following skills:
Making architectural decisions
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.
This is the most basic skill an architect needs to have, and it needs to give the development team the principles of system design and the constraints of system development. The role of the architect here is more of a facilitator than a designer of specific technical solutions. For example, if the development team is choosing a front-end framework, the architect’s advice is to choose a Reactive style front-end framework (guiding the team to choose between Reactive. Js, Angular, Vue. Js, or another Reactive style front-end framework). Instead of directly recommending the React. Js framework. The former is an architectural decision, while the latter is a technical decision.
Continuous analysis of the system architecture
An architect is expected to continually analyze the architecture and current technology environment and then recommend solutions for improvement.
Just as the life cycle of a software system does not end at the end of development, software architecture is not a one-size-fits-all deal. This requires the architect to continuously analyze the system architecture and propose improvements so that the system can remain well architecting in the face of both business and technical changes.
Stay sensitive to technology and industry trends
An architect is expected to keep current with the latest technology and industry trends
As an architect, you must always be sensitive to technology and industry trends. Under the trend of agile development, the characteristics of software change frequently, but the infrastructure of software often changes very little. It can be disastrous for a software system if architects fail to grasp current technology and industry trends and design software architectures that are unable to cope with business and technical changes in the coming years.
Make sure the team is developing according to established rules
An architect is expected to ensure compliance with architecture decisions and design principles.
The architect not only needs to lay down design principles and development constraints, but also needs to ensure that the team can consistently develop software according to these rules. This requires the architect to conduct Code Review of the core Code submitted by the developers, otherwise the architecture of the system can easily be corrupted.
Expand the breadth of your knowledge
An architect is expected to have exposure to multiple and diverse technologies, frameworks, platforms, and environments.
It is not necessary for an architect to be proficient in every framework, platform, and language, but at least to understand as many of them as possible in order to better support architectural decisions. This requires the architect to be constantly learning new things and constantly stepping out of his or her comfort zone. The best scenario is to be proficient in two or three languages and frameworks, as well as familiar with a variety of commonly used languages and frameworks in the industry. This combination of depth and breadth of knowledge leads to better software architecture.
Have some domain knowledge
An architect is expected to have a certain level of business domain expertise.
All the technology serves the existing business, and the software technology without the business is worthless. An architect does not need to be a domain expert in all aspects of a system, but at least has some business experience. Software is designed to solve problems, and architects who do not understand the business are trying to solve problems before they have read them. For example, a business requiring low latency can be designed by an architect who does not understand the business, resulting in a high-throughput architecture.
Interpersonal skills
An architect is expected to possess exceptional interpersonal skills, including teamwork, facilitation, and leadership.
This is probably the most difficult requirement for most development engineers and architects. They are good at and happy to solve technical problems, but they are quite resistant to problems related to people. But this is something that a qualified architect must overcome, because an architect not only needs to set the technical rules, but also needs to lead the team to develop according to the rules, which inevitably involves leadership and interpersonal skills.
When a development engineer decides to adopt the singleton pattern during a requirements development, the rest of the team may not pay much attention. However, when an architect decides to design a system with a microservice architecture, it may be challenged by a variety of people on the team. For example, the release manager may feel that the microservice architecture is too complex and will not affect the pace of delivery. Developers may find a layered architecture easier to implement. In this case, the architect is required to have good interpersonal skills to persuade various people, so that the project can proceed better.
conclusion
Software architecture is a very abstract thing, and most of its definitions are very broad descriptions. Fundamentals of Software Architecture describes Software Architecture from four dimensions, giving a clearer view of Software Architecture. On this basis, the book also proposes several skills that a qualified software architect needs to possess. In summary, it is hard to design a good software architecture, and even harder to become a good software architect.
In addition, the book proposes two principles of software architecture, which make sense but are somewhat abstract. Don’t try to understand it. Feel it.
1. Everything in software architecture is a trade-off.
2, Why is more important than how?
