Architect Responsibilities

1. Architect division According to the different fields that architects focus on, Microsoft divides architects into: Enterprise Architect EA (Enterprise Architect), Infrastructure Architect IA (Infrastructure Architect), Specific Technology Architecture TSA (Technology-Specific Architect) and Solution Solution Architect SA (Solution Architect).

EA's responsibility is to decide the technical route and technical development direction of the entire company. For example, Bill Gates.

IA's job is to refine and optimize the basic, public, and reusable frameworks and components that have been accumulated and precipitated in technology, which are one of the most valuable assets inherited from a technology-based company.

TSA, they are mainly engaged in the planning and design of special technologies such as security architecture and storage architecture.

SA's work focuses on the planning and design of solutions. The word "solution" has become a serious flood in China, and the big fools like to talk about it the most. The so-called solution is to continuously combine products, technologies or theories to create options that meet user needs. Pre-sales engineers usually take it to customers to play.

In practical work, we often see another relatively simple classification method, which divides architects into software architects and system architects. Software architects are basically TSA+IA, which is also the easiest path for programmers to break through and most likely to embark on, such as JAVA architects, DotNet architects, LAPM architects, and so on. The system architect is actually SA+TSA, which is more focused on the comprehensive use of existing products and technologies to achieve the needs expected by customers. A system architect requires knowledge of both software and hardware, so its knowledge system is relatively complex. If the architects are divided into software architects and system architects, it involves the company's system engineering (System Engineering) and development engineering (Development Engineering) two departments. The main responsibility of the system engineering department is to define and decompose the technical requirements at the system level and subsystem level according to the market requirement document (compiled by the marketing department), and form the decomposition result into a certain document. Document types include requirements documents, interface control documents, system architecture documents, information model documents, etc. An engineer in the systems engineering department is called a system architect (System Architect) or simply a system engineer (System Engineer). The development engineering department develops the final software product according to the output document of the system engineering department. Software development architect (Development Architect) is the earliest person involved in product development in the development engineering department.

Second, the main responsibilities of the software architect　　

1. Confirming 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. Technical 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. Formulate 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.

　　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.

In practical work, software architects need to do the following:

1. Participate in the review (Review) of all documents of the system engineering department. The design scheme of the systems engineering department must be understood and approved by all network element (Network Element, which is a term in the telecommunications industry, which refers to a sub-product in a system) level software architects can ensure its developability. Guaranteed by having the software architect review the systems engineering output documentation. Software architects can involve relevant development engineers in the review process to ensure the quality of the review. This situation occurs because software architects are less aware of specific implementation details than engineers.

2. As the interface person between the system engineering department and the development engineering department. When systems engineering needs help from development engineering to understand software implementation details, systems engineering gets help through a software architect. Conversely, the software architect is the bridge when the development engineering department needs the help of the systems engineering department.

3. Leading the evaluation of network element-level R&D workload. When a company plans to develop a new function or feature, its workload needs to be assessed first. The software architect needs to organize the assessment of the workload at the network element level, and is responsible for entering the assessment results into the corresponding management tools. It is worth mentioning that the evaluation work takes place before the specific development work of the systems engineering department and the development engineering department.

4. Realize the refinement of technical requirements at the network element level and participate in the management of requirements. The software architect needs to make further refinement according to the technical requirements of the system engineering department, so that the software development engineer can carry out the development work. The refined requirements need to be associated with the requirements of the system engineering department, and the associated work is also done by the software architect.

5. Prepare software architecture documentation. The software architecture document describes which software modules are included in the implementation of the network element, and defines the roles of each module and the message interaction between modules (including message names and message formats). The software architecture document and the requirements at the element level (derived from item 2 above) are inputs to the work of the software development engineer.

6. Help software development engineers answer questions, including software business logic and coding. If the software development engineer has doubts about the business logic described by the requirements, he will ask the software architect for help. If the software architect can't solve it, the software architect needs to get help from the systems engineering department. Software architects need to be exposed to software code, and when necessary, need to personally implement software design and coding work.

7. Review outline design and detailed design. After the development engineer completes the outline design, a design review meeting needs to be held. The software architect is an important role in the review meeting. Similarly, software architects need to be invited to participate in code review meetings after the development engineers complete the detailed design.

8. Review test cases. The test cases used by the development engineer to verify the software implementation are subject to review by the software architect.

9. Participate in or initiate improvement of the development process. The software architect is the representative of the development engineering department for the wide-scale process improvement work initiated by the systems engineering department. The software architect is the initiator and organizer of the process improvement work within the development engineering department.

10. Lead the tackling of difficult software problems. Because most of the software architects have rich experience, they naturally need to play an important role in solving software problems.

11. Responsible for the technology transfer of the project in different R&D centers. When a project needs to be moved from one R&D center to another, the software architect is the primary technical owner and leader. From the responsibilities listed above, the software architect plays a very important role in the software implementation phase.

3. Differences between software architects and system architects

1) System engineers focus on business logic, not code implementation. Therefore, system engineers need to have a very comprehensive and in-depth understanding of industry specifications.

2) Software architects do not need to understand industry specifications as high as system engineers, but need to understand a lot of code implementation details. Although software architects are not too demanding of industry norms, they must be able to quickly find various documents prepared by the systems engineering department.

3) Another difference has been mentioned before, the system engineer comes from the system engineering department, while the software architect comes from the development engineering department.

Fourth, the misunderstanding of software 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 write code that is overkill. 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.

Five, the quality of software architects

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 **** and financial power, and then puts on a "leader" tiger skin, using the method of "carrot and stick", basically Execution is guaranteed. 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 analysis ability 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.