Is the architect a big bluff? Ali Technology Daniel tells you the truth!

is the architect a big bluff? Ali Technology Daniel tells you the truth.

Source: Aliyun

Author: Lin Hao went (nickname Bi Xuan), Alibaba technical support researcher, has been a Taobao platform architecture Division architect. The personal research direction mainly is the Java modular, the dynamic system construction, as well as the high-performance large-scale distributed Java system construction, leads Ali data Center off-site many live project construction.

Architect, this title, like the title of the director, has been thoroughly rotten. But in the lifecycle of a software product, the architect is a real, extremely important role. It is important for the architect to write code for the core part of the entire system. This part is not necessarily the most technical challenge, but it plays a key role in controlling the quality and even the success of the whole system. The architect must be born from among the people who write the core code. Bi Xuan's article is mainly about what the architect he understands should have.

Business understanding and abstraction capabilities

The architect's first responsibility is to understand the business and transform it into an implementation that can be developed and understood, so business understanding is an essential skill for architects. Generally speaking, a senior business architect will have a very deep knowledge and accumulation of the business. An excellent business architect should be able to approximate the future trends of the business in order to allow for a certain amount of space in the scalability of the system. So it will be natural to have some business architects doing the role of simply switching to PD type.

Abstract ability is a model that translates into a system implementation through the understanding of the business, which is clearly an important capability. Abstract many times also undertook to break down the responsibility of many teams, clear division of labor.

NB's code capabilities

Many architects are now considered to be big-fudge, there are a bunch of architects who don't work (even people who are almost ignorant of the technology), and when they say no, and add to the uncertainty, it's easy to be considered a big bluff.

I always thought that the architect had a very important responsibility to write code for the core part of the entire system. This part is not necessarily the most technical challenge, but it plays a key role in controlling the quality and even the success of the whole system.

So the architect must be born from the person who wrote the core code. In a large system across multiple domains, architects are not likely to be good at anything, and it is impossible to write the core code of each section, and the architect must know how to determine if the partial implementation of the non-Self knowledge domain is OK to ensure that the parts are grouped together to conform to the architectural design expectations. Often this code that ensures that parts are organized together work should be fenced by the architect himself.

The most critical quality: comprehensive

Overall is an architect to show the most critical quality, fully reflected in the following three points:

First, in the face of business issues, the architect's mind will emerge from a variety of technical solutions:

This is actually very important. Otherwise, it may appear that there is a simple mature scheme, but because do not know and do other complex immature scheme, so a broad technical vision is the architect of the necessary.

In addition, the architect can not be all good at, at the point that they are not good at, need to know to find which professional person is reliable, this is also very important.

Second, in the design of the system whether to take into account a sufficient number of aspects:

For example, many system design is easy to omit the details of the online link, resulting in the on-line found missing what consideration, temporary solution or can only be redone.

Remember one year I did a design did not take into account the on-line phase of a detail, leading to the online time to find because the network segment of the problem is completely work, and there is no temporary solution, had to restart.

System Design not only guide the development of students how to write code, but also to guide all other relevant technical students work.

And for example, when I was doing a service framework design in 2008, clusters and clusters are accessed through hardware load balancing devices, which are connected in a single long connection, and this design leads to the need to release the invoked service during the run, and it is easy for the pressure to be concentrated on the previously restarted machine, This is also a typical design problem that the entire link does not consider clearly.

Again for example 2013 I'm doing a broader system makeover design, as a part of the software is not known enough to judge errors, resulting in the transformation in the course of the process to find some need to change the key software design is too rough, the last on-line progress almost one months delayed, And the designs that were later made are urgent, and the stakes are very high.

Looking back at the software I have designed, I found that the mistakes made at this point can be said for several days, it seems that I should tidy up another document "I made in the system design of XXX Error", some in fact rely on a good system design template may be able to avoid. A good system design template can help the architect think more comprehensively.

Third, in the design of the system whether to take into account the future of some development.

As much as possible not to appear in the future a little change will lead to the present in vain or to spend a lot of effort to transform the phenomenon.

When I think about the service framework, I later found out that when I did the design, I did not take into account the problem of the future service call Trace, resulting in a great effort (not technical, but implementation) to make up for it later.

The overall need for the architect to have a wide range of technical domain knowledge and enough experience to accumulate, from a comprehensive point of view the architect's work is not to draw a few boxes, even a few lines so simple.

The challenge to the architect's "overall" point, the more difficult it becomes, the greater the scope of the system (the design of a system, and the design challenges of a large system composed of 100 systems), whether it is the breadth of knowledge, the coverage of the points considered, or the future trend, Even more complex situations can have structural adjustments that correspond to organizational restructuring, which also takes into account, for example, the large architectural transformation of service, which means the establishment of a dedicated professional Field Service team.

Global

Global view usually refers to the system design, whether to consider the impact on the upstream and downstream systems.

After all, the design of the system is not an isolated system, if not good enough to the overall view, it is likely to lead to their own system to complete the line, the other upstream and downstream systems (especially some of the upstream and downstream is who, how to do not know the case) there are problems. This is also true of many cases.

Weigh

Trade-offs are also an extremely important competency for architects. Or it can be considered as a decision-making ability, the decision of technical solutions is an architect's most important responsibility.

The above "comprehensive" is the architect in the process of thinking "put", and the trade-off is the process of "collect". The end of the process means that the technical solution is determined and the rhythm is determined.

Trade-offs can be particularly pronounced on two points:

I. Principles of technical programme decision-making:

Usually a problem can be solved by a variety of technical solutions. How to make decisions is crucial, and decisions are often related to the whole. Generally speaking, the principle of decision making is price-performance and sustainable development.

Cost-performance is simply the implementation cost of the scheme, which includes a lot of aspects. For example, some scenarios may be a hardware solution that looks like money, but the final conversion cost is the most cost-effective, many system design in the decision-making price ratio is too casual, such as a different common scenario is to build a new system to replace the old system, At this time, the cost of the old system may not be considered at all, even if the old system is changed.

Sustainable development is simply the choice of the technology program in the company is sustainable. For example, the simple case is that the company's main developers are PHP, but to engage in a different language, and only very few people understand.

Of course, this still depends on cost-effective, if one other language brings more benefits than the language/talent system replacement costs. Another example is the introduction of an open source product, whether or not a professional team to maintain this is a key factor to consider.

Second, priority and rhythm control:

I often ask students who do system design a question: For this business scenario, in the system design of the most need to grasp a point is what.

This is a key issue, which means taking into account a lot of local problems, but usually the business requirements are implemented with strong time requirements, so it's important to consider the priority of the different points at this time,

It also includes technical solutions to make trade-offs when making decisions, it is possible to choose a not so good technical plan, but by leaving some room for transformation, for the future reconstruction to pave the way, that is very good, especially technical students are sometimes more prone to fall into the solution of technical problems of the scene to go, But the problem may not be the most important one at this stage.

Priority and tempo control is what I think is the best embodiment of one of the most NB architects, priority means to grasp the focus, to ensure that the design of the architecture under the guidance of the business implementation will not be a big problem, rhythm control means a comprehensive, know as the business development at what point in time to do what, to pave the way for the future.

Copyright Disclaimer: Content Source Network, the copyright is owned by the original. Unless it is not confirmed, we will indicate the author and the source, if there is infringement please inform us, we will immediately delete and apologize. Thank you.

-end-