Architecture is a capability, it is not a title. In other words, we need to have architectural capabilities, but not necessarily to be architects. Just like Deng Gong, he is called the chief designer of reform and opening up, but he is not a designer.
In this case, do we still need an architect? Do you still need an architecture department?
The answer I gave is: No, because everyone should be an architect .
Why architects don't work
Before coming to Alibaba, I was working in the payments department of eBay. At that time, there was an architect named Scott. All designs and solutions needed his approve to pass. As a result, he became the bottleneck of the entire team. Many things were blocked. His place.
The engineer is very uncomfortable. Just introducing him to the business and system design requires a lot of time to discuss (due to the time difference, a discussion often takes a week to reach a conclusion). It is also not easy for him. To understand the structure and business details of each system is exhausted.
Not to mention the inefficiency, what benefits did such tossing finally bring? To be honest, when I look back now, apart from a few variable naming I think Scott made more sense, there is really nothing more valuable.
I think the main problem here is that because Scott is not in the executive team, he does not understand the details, so it is difficult to give valuable input. We think that "he does not understand" many things, that is, his plan cannot convince us. Naturally, it is very difficult to cooperate.
Many people like to use the analogy between building architecture and software architecture. They think that since architecture needs architects, software should also need architects. Too simple, too naive!
In fact, apart from the need for drawings and artistic elements, the two have little in common.
First, architecture is different from software. The standard and certainty of architecture is much higher than that of software, and the flexibility of software has no boundaries. Any function can be implemented in countless ways and there is no fixed formula. Therefore, the binding force of software architecture diagrams is much lower than that of architectural drawings. If the building is not designed according to the design, you cannot achieve its function. The software design document and code can be two parallel universes.
Architecture is static, software is dynamic. The quality of a building is to be stable and beautiful; the software should be flexible and efficient. Therefore, the two are completely different.
Second, construction workers are different from programmers. The job of a programmer is definitely not just "moving bricks". Software design is a challenging creative work. It needs to weigh various subtleties, and only by going deep into it, hands-on coding, can the problem be found. Therefore, floating on the development team and gesticulating PPT architects are bound to be difficult to succeed.
Why does the architecture department not work
If the architect is a lightweight solution, then there is another "weapon of mass destruction" that is the establishment of a dedicated architecture organization.
A few years ago, B2B had such an organization. I remember that at the "Architecture Diagram" KO meeting that year, the person in charge at that time asked us to draw an architecture diagram. I asked him what is the meaning of this architecture group? If I just draw an architecture diagram and use it as a ppt for my boss, I don’t want to draw this diagram. I also sternly said a famous saying-KO does not have to be Kick Off, it can also be Kick Out. More than that, and then I "submitted" to the CTO of B2B at that time, and then... With the transfer of the CTO and the resignation of the head of the structure, there is no more...
In fact, the "architecture map" is a good retreat. Although it is useless, it does not constitute a killer. What really kills is that the structure organization is unwilling to do nothing, holing its mind to "do things."
It can be said that in the business technology department, the "want to do" behavior of the architecture team is very dangerous. The bigger the thing, the more lethality.
how you said that? Let us first take a look at what the structure organization can do in the business technology department.
-
Business architecture? I am in the marketing domain, in the order domain, in the commodity domain, and in the supply chain domain... Your architecture team told me that you have a better understanding of business domains, business processes, and business details than PD, operations, and engineers? I am afraid it is difficult. A qualified PD should be able to do a good job in the abstraction of the business domain and the abstraction of the business process. As for the details, it seems that no one knows better than first-line development. Architecture team, die!
-
Application architecture? After the requirements were relatively clear, I, a TL who still had some influence in the application architecture field, would often argue with the team when discussing boundary division and design solutions. Are you an "outsider" in the architecture group wanting to come to your fingertips? Haha, how do you underestimate the self-esteem of programmers? Architecture team, die!
-
Technology Architecture? Well, then our architecture team will return to the technology itself, and we can always do something purely technical. Sorry, as long as there is some valuable technical middleware, a middleware team is already working on it. Remember, the Hilton container of the ICBU architecture group and the AE architecture group (middleware team) "do their own way" use SpringBoot? This kind of duplication of wheels is completely unnecessary. Before the cloud native mature, PandoraBoot is the best solution. The architecture team, with the entire BU together-pawn!
Here I would like to mention Alipay’s middleware team (architecture department?). I don’t know the history. Maybe TecFin does have its own particularities. However, from the perspective of the entire group, I think a unified technology center should be a better approach.
For an enterprise, perhaps at a special stage, it does need physical organization to ensure the implementation of the structure.
But in most cases, especially when the technical system is relatively complete. For example, in Ali, the business technology department, it is best not to set up a special structure organization in the BU. Believe me, in my career, I have seen many technical structure organization cases set up by the business technology department, and they basically fail. And ended.
Everyone is an architect
The architect can't do it, nor can the architecture department. Who will do the architecture? Look at the one on the left of your seat, look at the one on the right of your seat, and then look at your supervisor... Don't look, they do it, you do it yourself, everyone is an architect.
First of all, let's take a look at what architectural capabilities are. I think the broad architectural capabilities should be a set of methodology for analyzing and solving problems. It requires you to have insight into the essential elements of the problem, clarify the relationship between the elements, and the ability to formulate corresponding strategies.
From this perspective, I believe that architectural capabilities are core competitiveness. Every engineer should have certain architectural capabilities, and everyone should be an architect. How to understand?
-
As a technical front-line employee, maybe your working hours are not long, the architecture ability is relatively weak, there is no shortcut, learning and learning, growth and growth, architecture as a capability can be learned, not so advanced.
-
As the leader of the technical team, you must have certain architectural capabilities, whether it is business architecture or application architecture. TL should have the ability to discover the essential elements in the problem and clarify the relationships between the elements. If you are already a TL, but the architectural ability is still relatively lack, you need to make up as soon as possible. It doesn't matter if it is insufficient, what matters is the cessation of learning and growth. As Huai Su said, many people with insufficient stamina mainly stopped learning and growing prematurely. Your ability should oscillate around your level. This oscillating range will not deviate too much. Sooner or later, it will return to a relative Reasonable interval.
-
As a CTO (have never eaten pork, but watched a pig run), the CTO has no choice but to be a very, very good architect. You must not only be familiar with business architecture, but also be proficient in technical architecture. More importantly, because of the butt problem (Conway's law), you have to design the organizational structure to adapt the production relationship to the development of productivity . Only in this way can technology support business development stably and efficiently.
I heard that Tencent does not have a CTO, so each BU has its own technology stack and middleware.
If the picture above is true for Tencent's structure, I think it would be better for them to have a CTO. Because it is obvious that for general technical solutions, such as big data processing, technical middleware. There is no need to reinvent the wheel, and reuse is obviously a more scientific approach.
At this point, as shown in the figure below, I think Ali is undoubtedly ahead of Tencent. Among them, the data center and technology center, I think Ali is the best and the most NB. As for why there is a small dark cloud next to the business center, this is because the abstract reuse of business is much more difficult than the abstract reuse of technology. The difference in business problems faced by different businesses is huge. The technical problems faced by different businesses are much more stable than business problems. I think this is also the reason why technical middle stations have been successful, and business middle stations are still exploring.
How to practice
Finally, share how I became an "architect" in the team.
On the one hand, I will spare no effort to cultivate the architectural capabilities of team members. I will continue to discuss with them whether the system boundaries are reasonable, whether the model abstraction is reasonable, whether the process abstraction is reasonable, and whether the module design is reasonable. And asked them to explain clearly what the thinking and philosophy behind the design are, and then use my own methodology and thinking to collide with them. If we repeat this process, my team and I will grow.
On the other hand, I will hands-on coding and participate in the coding of core business logic, which is very important. It is necessary to dig into the code details to do the architecture, because many problems will only be exposed during the coding process. In addition, unnecessary discussions are inefficient. The way to verify whether the architecture is reasonable is to combine business scenarios and write code to verify. Whether the design is reasonable and elegant, you can get good feedback during the coding process. More than once, in the process of writing code, I refactored the original design, or even completely overturned it.
All in all, architecture as a capability and the core growth goal of our engineers is worthy of our tireless pursuit. As an architect, in most cases, it is a "haha".