Some Opinions on technical architects

Many people talk about architects. There are actually two types of Architects: Business Architecture and technical architecture. My experience and lessons are limited to technical architecture. Therefore, this article focuses on technical architects.

One year before graduation, seven years after graduation, about eight years of experience and lessons in the technical field, participated in a number of large and small projects, some of which were well-known experiences, and some failed lessons. I have been a technical leader in the past, gradually filling in various aspects of knowledge in different fields, and began to design architecture in the past year. Here are some of my views.

Technical architects should be responsible

For example, for a large project (hundreds of developers and dozens of basic engines) that has been used in the past, this large project has a basic module with poor design and severe performance problems, the structure is chaotic and the responsibilities are unclear. Many people have discovered this problem in the early days, which is well known. But it has not been changed. It is said that the cost of the change is too high, and the other part should be changed. However, the later the change is made, the more cost will be paid. This basic component subsequently caused many serious problems, including performance problems (high memory usage), development efficiency problems (chaotic structure, and troublesome use), and so on. Many years later, when I asked about this component, related colleagues said that the component is too bad to be changed. I often think about it and think about why and how to solve it. Responsibility is the most important issue. At that time, the technical architect was not responsible for solving the problem and asked him to drag it down.

Speaking of the quality of technical architects, of course, profound technical skills are required, but this is a basic quality, not a key quality. I thinkThe key quality of technical architects is the sense of responsibility.. As an architect, it is your painstaking effort to design this architecture. You must "love" it, lay a solid foundation for its long-term development, and even sacrifice some short-term benefits.

We are all growing and often encounter opportunities to do things beyond our capabilities. When architects design the first architecture or even the nth architecture, they may be beyond their own capabilities, and then gradually improve their capabilities in actual work. The early design may be not good enough and has already been applied in implementation. However, your ability has been improved and you need to correct the problems, correction requires cost. As an architect, you must be responsible, dare to take responsibility, be responsible for faults, and change him.

No one dared to take responsibility for the stubborn nature of many projects! As an architect, you must be responsible for everything!

Technical architects must be persistent

On one occasion, I made a technical architecture solution and wanted to execute it. Everyone (including some managers) was opposed, but I finally insisted on it, it eventually achieved very good results and became one of the most critical technologies in this technical architecture.

As a technical architect, you may have the best technical skills in your team and think more than others.If you believe that your technical decisions are correct, then you will stick to it, regardless of politics, regardless of the gods!

What should I do if I encounter a problem that I am not good?

As an architect, there are always many problems and areas of expertise. At this time, ask other colleagues for their decisions and work out solutions together, or simply give the decision to a colleague who is good at this aspect. Do not be knowledgeable or competent.

What should I do if I do something wrong?

There will always be something wrong. What should I do? Do not look at your face, make excuses, accept criticism, and make quick improvements.Face-to-face! No one else will deny all your mistakes. Based on experience, people who do things wrong and then make improvements are generally more reusable. The reason is that the error has occurred, and the leaders know the difficulty of the problem. If you solve it, it means that you have solved a difficult problem.

In-depth understanding of the actual situation

Ivar jacbson recently talked about technical architects and said that code execution is more important than macro architecture. There is a common truth between Ancient and Modern Chinese and foreign countries, that is, Details determine success or failure. It is also said that "the devil is always in detail ". Some architecture problems are always reflected in implementation details or usage details.As a technical architect, you 'd better read the actual usage of architecture developers, open the project, read the code, run the program, and observe the execution.In a recent technical architecture, many of the important technical solutions are the improvement solutions summarized after observing the code of the developers.

Technical architects have many technical details, such as layered details, database naming rules, code specifications, spring configuration file management, ibatis configuration file management, log output specifications, and regular findbugs checks, the Eclipse plug-in fixes some technical solutions, regularly maintains the wiki knowledge base, performs code review, organizes project dependencies, and manages daily product output. The details of each specific project are different. If the details are not well handled, the "devil" will emerge ".