What is an architect
There used to be this joke:
A: I’ve been hired by a medium-sized software company, and the whole company welcomed me at work today.
B: I envy ing. Who’s here?
A: The CEO, COO, CTO, All of the programmers, the accountant, the driver are All here.
B: Wow, they take you so seriously, talent, so many people to greet you!
A: No, just one!
B: Oh, #%￥$%…
At many startups, it’s not uncommon for one person to hold more than one job. At least, I am experiencing, one half of all the development process, the test I have done, is absolutely a dragon, but often will stumble on steel wire, unicycle-riding, once, result, sent from my hand CD motherboard, contain virus zombie, that was forced to take back onto the market has 20000 CDS, from then on, My heart just started to get so strong, and now the whole backstage service is down, and I just smile. As a matter of fact, there is nothing wrong with one person playing both architect and programmer, or even multiple roles. I will talk about this topic later. This phenomenon is not a Chinese characteristic, and it is completely in line with foreign countries. I once had a similar conversation with an Engineer in The United States on MSN and found that their approach is no different from ours. In the IT industry, the gap between us and the world is only one day, and we are sure to see the new thing they just made the next day.
The term architect is not a figurehead, but an international standard (ISO/IEC 42010). An architect is one of many roles in software development activities, and it may be an individual, a team, or a team. Microsoft has a classification reference for architects. For reference, they divide architects into four categories: Enterprise Architect (EA), Infrastructure Architect (IA), Technology-specific Architect (TSA), and solution Architect SA (Solution Architect). Microsoft’s classification is based on the area of focus of the architect.
EA’s responsibility is to determine the technology path and direction of development for the entire company. Gates gave himself the Title of chief software Architect, netease Ding Lei also like to call himself that, in fact, EA role; The job of IA is to refine and optimize the basic, common, reusable frameworks and components accumulated and precipitated in technology. These are one of the most valuable assets inherited from a technology company. TSA, specialized technology architects who plan and design specific technologies such as security architecture and storage architecture; SA specializes in the planning and design of solutions, a word that has become so prevalent in China that it is a favorite word of the hustlers. A solution is a continuous combination of products, technologies, or theories to create choices that meet user needs. Pre-sales engineers generally take it to the customer to play.
Big companies tend to have different types of architects, while small companies tend to be less particular. Architects are mostly IA+TSA+SA, so big companies have specialists and small companies have all the talents.
In practice, we often see a simpler way of categorizing architects into software architects and systems architects. Software architect is basically TSA+IA, and this is the path that programmers are most likely to follow, such as JAVA architect, DotNet architect, LAPM architect, etc. The rest of my talk is about software architect. The system architect is essentially SA+TSA, focusing more on integrating existing products and technologies to meet customer expectations. The system architect needs to be knowledgeable about both software and hardware, so its body of knowledge is relatively extensive. On the subject of system architects, we can discuss that later.
Responsibilities of the architect
The architect is involved in the entire project development process, including requirements analysis, architectural design, system implementation, integration, testing, and deployment phases, and is responsible for directing and coordinating technical activities and specifications throughout the project.
An architect has four main responsibilities:
1. Identify requirements
During project development, the architect steps in after the requirements specification is completed, which must be approved by the architect. Architects need to communicate with analysts repeatedly to ensure that they have a complete and accurate understanding of user requirements.
2. System decomposition
Depending on user requirements, the architect breaks down the system into smaller subsystems and components to form different logical layers or services. The architect then determines the interfaces of the layers and how they relate to each other. The architect not only layers the entire system into “vertical” decomposition, but also blocks the same logical layer into “horizontal” decomposition.
Software architect skills are basically reflected in this, this is a relatively complex work.
3. Technology selection
The architect forms the overall architecture of the software through a series of decomposition of the system. The choice of technology depends largely on the software architecture.
Does the Web Server run on Windows or Linux? Does the database use MSSql, Oracle or Mysql? Do you need to use a lightweight framework like MVC or Spring? Is the front end rich client or thin client? Similar work needs to be proposed and evaluated at this stage.
The architect’s decision on product and technology selection is limited to evaluation and has no right to make. The final decision belongs to the project manager. The technical solution proposed by the architect provides important reference information for the project manager, who will weigh the actual situation of the project budget, human resources, schedule, and finally confirm it.
4. Develop technical specifications
The architect is the technical authority in the project development process. He needs to coordinate with all the developers, communicate with them all the time, and always make sure that the functionality is implemented according to its architectural intent.
The most important form of communication between architects and developers is the technical specification, which can take the form of UML views, Word documents, Visio files, and more. Technical specifications provided by the architect ensure that developers can see and understand the subsystems or modules they are responsible for from different perspectives.
The architect needs to communicate not only with the developer, but also with the project manager, requirements analyst, and even with the end user. So, for architects, there are not only technical requirements, but also interpersonal requirements.
Three mistakes of architects
The architect is the project manager
Architects are not project managers. Project manager focuses on budget control, schedule control, personnel management, external contact and coordination, etc., with management functions. Project manager and architect are common in small projects.
2. The architect is responsible for requirements analysis
Architects are not requirements analysts. The job of the requirements analyst is to collect and analyze requirements and liaise with end users and product managers. The architect only reviews and validates final requirements, presenting unclear and incomplete requirements, and is in constant contact with the requirements analyst. Architects are technical experts, not business experts.
Architects never write code
This is a matter of debate. There are two schools of thought:
Point 1: Architects don’t write code. Writing code is a manual job. Architects are overqualified to write code. The architect hands the various views of UML to the developer, and is always available to communicate with the architect if there is any ambiguity.
Point 2: Architects are from programmers, but at a higher level than programmers, the only thing more than programmers is experience and knowledge, so architects are not immune to writing code.
I personally feel that both statements have to do with the architect’s background and environment.
The architect is a technical role first, so it must come from the group of technical personnel, such as the system architect, mostly from the operation and maintenance personnel, may not write much code, or can not write very beautiful code. Software architects are often programmers with programmer pedigree and feelings, so they may write some core code during the project development process. The ideal is that architects don’t have to write code, but sometimes that’s too ideal. Whether an architect writes code or not may depend on the reality of the company’s size, culture, quality of developers, and so on. In addition, architects are not so clearly separated from programmers, and there are high, medium and low levels of ability, and whether or not they write code is not the fundamental criterion to distinguish them.
Basic qualities of an architect
Zhou Xingchi has a film “king of comedy”, the Yin Day Chou in the play chuai all day this “actor’s self-cultivation”, a good actor not only needs talent, but also needs certain theoretical guidance, after all, the person without a teacher is a few. Architects grow in the same way. From ordinary programmer to senior programmer, and then to architect, it is a process of experience accumulation and ideological sublimation. Experience accumulation is one aspect, quality cultivation is another aspect, the two complement each other, so I think it is necessary to list the qualities that architects should have, as the direction of programmers’ efforts.
Ability to communicate
To be effective, the architect must win the approval of team members, project managers, clients, or users, which requires strong communication skills. The ability to communicate is one of the most common human qualities that technical people tend to overlook, but architects can’t. Do not hold such a concept: pregnant with just like pregnancy, a long time will always be found. The elder brothers who sell vigorously pill on overpass say right: light say not practice false handle type, light practice don’t say silly handle type. Look around you and see who isn’t the best at this. Don’t look down upon it as flattery or opportunistic. Look on the positive side of everything. I think I am a slightly introverted person, because I am a rural child, mandarin can not speak well, before more or less with a sense of inferiority, fantasy is gold will always shine, so in the career suffered a lot of losses. Now, I deeply understand the importance of communication, I will take the initiative to communicate with colleagues and bosses from time to time, feel that the work is much smoother.
I think this one is the most important, so it’s on the top of the list. I would go so far as to say that I can ignore all of the following, but this is the only one I should keep in mind and remind myself of frequently.
Ability to lead
Architects drive the technical progress of the team, make critical decisions under pressure, and follow through. How can the architect ensure this execution? This requires leadership from the architect.
The leadership of an architect is acquired differently from that of a project manager. The project manager is mainly responsible for solving administrative management, which has little to do with technology. He has human rights and financial power, and then puts on a tiger’s skin of “leadership” and adopts the way of “carrot and stick”, which can basically ensure execution. Architects are more likely to use informal leadership, also known as influence, which includes charisma, technical competence, knowledge transfer, and so on.
Abstract thinking and analytical ability
The architect must be able to think abstractly and analytically, which are essential qualities for your systems analysis and system decomposition. Only with this ability can the architect see the whole system and control the overall situation, which is also the foundation of the architect’s big picture view. How do you acquire this ability? One comes from experience and the other comes from learning. Architects should have experience not only in the problem domain, but also in the software engineering domain. That is, the architect must be able to understand the requirements accurately and then translate and decompose them to a level that can be implemented in a computer language using software engineering ideas. The accumulation of experience is a time process, this process can not help you, you need to go through. However, you can shorten this cycle if you consciously cultivate and constantly learn from previous experience. This is one of the original motivations for writing this series.
Technical depth and breadth
The architect should be well versed in one or two techniques that allow for a deeper understanding of how the architecture works, a closer relationship with developers, and influence on the team.
The breadth of the architect’s technical knowledge is also important. The architect needs to understand as many technologies as possible and be well-informed so that it is possible to combine them and choose a solution that is more suitable for the project. Some people say, with good reason, that an architect needs more technical breadth than technical depth.
In short, the architect is the technical authority on the project team.