Abstract: This article mainly introduces the definition of software architecture, as well as some of the skills required to become a software architect, so that you have a deeper understanding of the position of software architect.
This article is shared from Huawei Cloud Community " Want to become an architect? Let's see if these conditions are met or not! ", original author: Yuan Runzi.
Preface
When you click on a recruitment app and select Internet technology as the screening criteria, there are often a few high-paying positions with the words architect When you are attracted by its high salary and click to view the job details, you will be persuaded by its high demands. They often require more than 5 years of working experience, and the person who needs to have more than 3 years of system design experience, proficient in various architecture models and system frameworks, but they do not meet any of the conditions.
Software architect is such a desirable, yet sighing position. Just as architects always dream of becoming chief designers, aerospace workers always have the ambition to become chief engineers. I believe every software engineer has the idea of becoming a software architect. Quoting the definition in Wikipedia, the software architect is to determine the main technical choices and design the main frame structure of the system according to the requirements in the software system research and development, and to build and implement . However, the skills required by architects go far beyond technology selection and system design. This article mainly introduces the definition of software architecture, as well as some of the skills required to become a software architect, so that you have a deeper understanding of the position of software architect.
Most of the opinions in this article come from the book "Fundamentals of Software Architecture". For more details, I recommend reading the original book.
Definition of software architecture
For Software Architecture, we usually regard it as a blueprint of a software system, but it is often difficult to give a precise definition. The definition of software architecture in Wikipedia is , an abstract description of the overall software structure and components, used to guide the design of various aspects of large-scale software systems . However, this definition is also one-sided. The software architecture is not just the overall structure and components of the system. These alone are not enough to guide the design of a good software system.
In the book, Mark Richards and Neal Ford describe the software architecture from four dimensions, namely Structure, Architecture characteristics, Architecture decisions and Design principles.
Structure
Structure describes the architectural style used by the software system, such as the most common layered architecture, event-driven architecture, microkernel architecture, and microservices architecture )and many more. When you ask the architect what architecture a software system uses, if he tells you, "The system uses a microservice architecture," then he only clarifies the architectural style of the system. If you want to understand the software architecture of the entire system, you must have an in-depth understanding of architecture characteristics, architecture decisions, and design principles.
Architecture characteristics
Architecture characteristics are the non-functional requirements we often say, 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 describe the rules that must be followed when developing a software system , 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 can directly access the service layer and the presentation layer No direct access to the service layer. Architecture decisions are more of a constraint. Violation of this constraint may not affect the function of the system, but it is the source of corruption of the system architecture.
Design principles
Design principles refer to the principles of system design , which are used to guide the development team to choose technical solutions that are more in line with the characteristics of the system. Design principles will only give a direction, not a specific implementation plan. For example, the system design principle given in the example in the figure is: asynchronous communication between microservices should be used as much as possible to improve the performance of the system. As for the implementation of asynchronous communication by the development team through REST or RPC, the design principles are not limited.
Skills required to become an architect
Just like the software architecture is not just the overall structure and components of the system, to become a software architect, only technology selection is far from enough. A qualified software architect should have the following skills:
Make 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 that an architect needs to possess. It is necessary to give the development team the principles of system design and the constraints of system development. The role of the architect here is more a guide than a maker of specific technical solutions. For example, the development team should select the front-end framework. As an architect, the advice that should be given is to choose a reactive-style front-end framework (guide the team to choose between React.js, Angular, Vue.js or other reactive-style front-end frameworks Choose) instead of directly suggesting to choose the React.js framework. The former is an architectural decision, while the latter is a technical decision.
Continuously analyze 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 the development phase, software architecture is not a one-shot deal. This requires the architect to continue to analyze the system architecture and put forward suggestions for improvement, so that the system can still maintain a good architecture in the face of dual changes in business and technology.
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 will frequently change, but the software infrastructure is often rarely changed. If the architect cannot grasp the current technology and industry development trends, resulting in the software architecture designed to be unable to cope with the business and technical changes in the next few years, this will be catastrophic for a software system.
Ensure that the team develops in accordance with established rules
An architect is expected to ensure compliance with architecture decisions and design principles.
Architects not only need to formulate design principles and development constraints, but also need to ensure that the team can always follow these rules for software development. This requires the architect to code review the core code submitted by the developer, otherwise the system architecture is easily corrupted.
Expand the breadth of knowledge
An architect is expected to have exposure to multiple and diverse technologies, frameworks, platforms, and environments.
For an architect, he does not need to be proficient in every framework, platform and language, but at least he must understand them as much as possible, so as to better support architectural decisions. This requires architects to continuously learn new knowledge and constantly jump out of their comfort zone. The best situation is to be proficient in 2 to 3 languages and frameworks, and familiar with various commonly used languages and frameworks in the industry. This combination of depth and breadth of knowledge can design a better software architecture.
Possess certain domain knowledge
An architect is expected to have a certain level of business domain expertise.
's technologies serve the existing business, and the software technology that has been stripped of the business is worthless . Architects do not need to be as proficient in the various businesses of the system as domain experts, but at least they must have a certain amount of business accumulation. Software is used to solve problems. Architects who do not understand the business do the software architecture design, which is equivalent to starting to solve the problem before reading the problem, and the result is often counterproductive. For example, if a business that requires low latency is handed over to an architect who does not understand the business for system design, a high-throughput architecture may be obtained.
Interpersonal skills
An architect is expected to possess exceptional interpersonal skills, including teamwork, facilitation, and leadership.
For most development engineers and architects, this may be the most difficult requirement. They are very good at and willing to solve technical problems, but they are quite resistant to people-related problems. But this is a point that a qualified architect must overcome, because the architect not only needs to formulate technical rules, but more importantly, the leadership team develops in accordance with the established rules, which inevitably involves leadership and interpersonal communication. ability.
When a development engineer decides to use the singleton mode in a requirement development, other people in the team may not pay much attention. But when an architect decides to use a microservice architecture to design a system, he may be challenged by all kinds of people in the team. For example, the version manager may feel that the microservice architecture is too complicated and will it affect the pace of delivery; the developer may feel that Layered architecture is better to achieve. In this case, the architect is required to have good interpersonal skills and persuade all types of personnel, so that the project can proceed better.
to sum up
Software architecture is a very abstract thing, and most of its current definitions are broad descriptions. "Fundamentals of Software Architecture" describes the software architecture from four dimensions, giving a clearer view of the software architecture. On this basis, the book also proposes several skills that a qualified software architect needs to possess. In general, is that it is difficult to design a good software architecture, and it is even more difficult to become a good software architect.
In addition, the book also proposes two principles of software architecture, which make sense, but they are a bit abstract. But it's okay, don't try to understand it, just feel it.
1、Everything in software architecture is a trade-off.
2、Why is more important than how.
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。