Software Architect Responsibilities

Responsibilities of the architect The
architect needs to participate in the whole process of project development, including requirements analysis, architecture design, system implementation, integration, testing and deployment, and is responsible for guiding and coordinating technical activities and technical descriptions throughout the project.
The architect has 4 main responsibilities:
1. Confirm the requirements
    During the project development process, the architect is involved after the requirements specification is completed, and the requirements specification must be approved by the architect. Architects need to communicate repeatedly with analysts to ensure that they fully and accurately understand user requirements.
2. System decomposition
    According to user requirements, the architect decomposes the whole system into smaller subsystems and components, thereby forming different logical layers or services. Subsequently, the architect will determine the interface of each layer and the relationship between the layers. The architect not only needs to decompose the entire system by "vertical" layering, but also divide the same logical layer into blocks and perform "horizontal" decomposition.
    The skills of software architects are basically reflected in this, which is a relatively complex job.
3. Technology selection
    The architect finally formed the overall architecture of the software through a series of decomposition of the system. The choice of technology mainly depends on the software architecture.
Does Web Server run on Windows or Linux? Database using MSSql, Oracle or Mysql? Need to use a lightweight framework such as MVC or Spring? Is the front end a rich client or a thin client? Similar work needs to be proposed and evaluated at this stage.
The architect's selection of products and technologies is only limited to evaluation, and there is no decision-making power. The final decision-making power belongs to the project manager. The technical solution proposed by the architect provides important reference information for the project manager. The project manager will weigh the actual situation such as project budget, human resources, and time schedule, and finally confirm it.
4. Develop technical specifications
    The architect is the technical authority in the project development process. He needs to coordinate all developers, keep in constant communication with developers, and always ensure that developers implement various functions according to its architectural intent.
    The most important form of communication between architects and developers is technical specifications, which can be in various forms such as UML views, Word documents, and Visio files. Through the technical specifications provided by architects, it is guaranteed that developers can observe and understand the subsystems or modules they undertake from different perspectives.
Architects need to maintain communication not only with developers, but also with project managers, requirements analysts, and even end users. Therefore, for architects, there are not only technical requirements, but also interpersonal communication requirements.
3.3 Misunderstandings
of architects 1. The architect is the project manager The
    architect is not the project manager. Project managers focus on budget control, time schedule control, personnel management, external contact and coordination, etc., and have management functions. In general small projects, project managers and architects are common.
2. The architect is responsible for requirements analysis
    . The architect is not a requirements analyst. The job of a requirements analyst is to collect and analyze requirements, and to keep in touch with end users, product managers. The architect only reviews and confirms the final requirements, and proposes unclear and incomplete parts of the requirements. He will keep in touch with the requirements analyst at all times. Architects are technical experts, not business experts.

3. Architects never write code
    This is an open question. At present, there are two views:
View 1: Architects do not write code, writing code is purely manual work, while architects are overkill in writing code. The architects hand over the various views of UML to the developers. If there is any unclear place, they can communicate with the architects at any time.
Viewpoint 2: Architects are originally from programmers, but they are at a higher level than programmers. The only thing more than programmers is experience and knowledge, so architects are also unavoidable to write code.
    I personally think that these two statements are related to the origin and environment of the architect.
    Architect is first and foremost a technical role, so it must come from the group of technical personnel, such as system architects, mostly from operation and maintenance personnel, who may not write much code themselves, or can not write very beautiful code. Software architects are mostly from programmers, with the pedigree and feelings of programmers, so in the process of project development, they may write some core codes. Our ideal is that architects don't have to write code, but the reality is sometimes too ideal. Whether an architect writes code or not may depend on the reality of the company's size, culture, and quality of developers. In addition, architects are not so clearly separated from programmers. There are also high, high and low levels according to their abilities. Writing or not writing code is not the fundamental criterion for distinguishing between the two.
3.4 Basic Qualities of Architects
Zhou Xingchi has a film "The King of Comedy", in which Yin Tianqiu carries the book "Actor's Self-cultivation" all day long. A good actor not only needs talent, but also needs certain theoretical guidance. After all, there are few people who are self-sufficient. The same is true for the growth process of architects. From ordinary programmers to senior programmers, to architects, it is a process of accumulation of experience and sublimation of ideas. Experience accumulation is one aspect, quality training is another aspect, and the two complement each other, so I think it is necessary to list the qualities that architects need to have as the direction for programmers to work hard.
1. Communication skills
    In order to improve efficiency, architects must win the approval of team members, project managers, customers or users, which requires architects to have strong communication skills. Communication ability is the most universal quality requirement of human beings. It seems that technical personnel are easy to ignore. If you want to become an architect, you cannot ignore it. Don't hold such a concept: pregnancy is like pregnancy, and it will always be discovered after a long time. Or the buddy who sells Dali Pills on the flyover is right: just talk and don't practice fake hands, just practice and don't talk stupid. Look at the minds around you, which one is not a master among them, we must not despise it, thinking that this is flattery, speculation, and everything must see the positive side, "communication" is indeed a kind of ability. I consider myself to be a little introverted, because I am a child from the countryside, I can't speak Mandarin well, and I used to have a little bit of inferiority complex. less loss. Now, I deeply understand the importance of communication, I will take the initiative to communicate with colleagues and bosses from time to time, and I feel that my work is much smoother.
    I think this one is the most important, so it ranks first. I even think the following items can be ignored, the only one you have to keep in mind and remind yourself often.
2. Leadership
      Architect can drive the technical progress of the entire team, can make key decisions under pressure, and implement them to the end. How can architects ensure this execution? This requires architects to have leadership skills.
    Architect leadership skills are not the same as project managers. The project manager is mainly responsible for solving administrative management. This ability has little to do with technology. He has human rights and financial rights. With the tiger skin of "leadership", the method of "carrot and stick" can basically guarantee execution. force. Architects may use more informal leadership in the project, which is what we often call influence, which includes personal charm, technical ability, knowledge transfer and so on.
3. Abstract thinking and analytical skills
    The architect must have the ability of abstract thinking and analysis, which is the basic quality of your system analysis and system decomposition. Only with this ability can the architect see the whole of the system clearly and control the overall situation, which is also the basis for the formation of the architect's overall view. How do you have this ability? One is from experience and the other is from learning. Architects need to have experience not only in the problem domain, but also in the software engineering domain. That is to say, the architect must be able to accurately understand the requirements, and then use the ideas of software engineering to transform and decompose the requirements into a level that can be implemented in a computer language. The accumulation of experience takes a time process, and no one can help you in this process, you need to experience it. However, if you cultivate consciously and continuously absorb the experience of predecessors, you can still shorten this cycle. That's one of my motivations for writing this series.
4. Technical depth and breadth
   The architect is best to be proficient in 1-2 technologies. With this technical ability, he can have a deeper understanding of the working principle of the relevant architecture, and can also narrow the distance with developers and form influence in the team. .
   The breadth of technical knowledge of the architect is also very important. It is necessary to understand as many technologies as possible. The so-called well-informed, only in this way can it be possible to integrate various technologies and choose a solution that is more suitable for the project. Some people say that the requirements for the architect's technical breadth are higher than the technical depth requirements, which is very reasonable.
All in all, one sentence: the architect is the technical authority on the project team.

The two basic concepts of process-oriented and object-oriented, not only architects need to be very clear, but also programmers and designers. This is also the most basic common sense of system analysis, design and coding. Many of the programmers I have come into contact with only stay at a level of "paradoxical", which is not acceptable. If you want to move forward, you have to lay a solid foundation, so I think it is necessary to return to the furnace and make up lessons.