Architect in my eyes: What should a good architect have? __ Architect

Time back to 78 ago, at that time "architect" is a very "tall" title. But in today's Internet circle, any developer who has worked for three or five years can call it an architect.

Just a few more recruiting sites, you can see: Front-End architects, back-end architects, Android Architects, iOS architects, PHP Architects, operational Architects, DB Architects, search architects, middleware architects, large data architects ... A wide variety of miscellaneous.

From these job requirements can be seen, "architect" The word is actually a very "virtual" word, different technical fields, different industries, the required skill points, the ability to focus on the model is very different, not a simple "architect" can be summed up.

And this article will also talk about my personal understanding of the position of "architect": Although the competency models required in different areas are not the same, the individual believes that as an "architect" there is something in common that needs to be mastered.

Interested friends can focus on the public number "architecture of the road and surgery" to obtain the latest articles.
or scan the following two-dimensional code:
pattern

The word "pattern" sounds rather empty, but I would like to cite a popular example: you travel to a strange city, I think the first thing you need is a map. This map defines the city's "boundaries" and defines all the parts of the city, and through this map you will have a "global understanding" of the city.

And this "global vision" is not to say that architects need to change to do other jobs, other industries, the same reason. Product manager, need to have a "global vision" of the product, do operations, market, need to operate, the market corresponding to the global vision, to do technology, need technology-related global vision.

With so much to say, it may be more "virtual", and I'll give you an example of what it means to be a "global vision", for example, you are now in charge of developing a new system, and you may need to understand the following issues that are relevant to the "big picture":

What is the positioning of this system? What core values it can create.

What is the background of doing this system? Why didn't you do it before? is because the business has developed to a certain scale. or the development of resources are now redundant, nothing to do.

Where the system is located throughout the organizational structure. What is the status of other systems associated with this system?

How the Product Manager views the system. Technology boss how to see.

The demand for this system is in a more definite and clearer state. There is still a lot of gray space. Many of the core points, we have not thought clearly.

The system used in the technical system is relatively old. is still up to date.

Similar systems in the industry, how others do.

。。。

Key points: Above casually cited this example, there is no standard answer, I would like to express is that a "big picture", a "pattern" of people, before doing a thing, to do things have a "global grasp", where the risk. Where is the challenge? Be prepared in advance.

Finally, one more word: "pattern" is layered, national Prime minister in the "country" this level of thinking, the CEO in the industry, "Company" this level of thinking, line of business leaders in his responsible for the "business" level of thinking, technology boss may be mainly in the "technical level" thinking, product boss in the "product level", to the bottom , writing code, thinking at the level of "code".

Different levels of people, the scope of focus is not the same size. But if you can extend your "range" to the outside, it will be good for you to do your own "job".

And this, in my opinion, is "pattern". Historical conception-technical blood

If the "pattern" is from the perspective of space to look at the problem, then "history" is from the point of view of time.

Any kind of technology, is not who is full of nothing to imagine out of thin air, it must be to solve a specific problem. This particular problem must have its historical background: it is because the previous technology, in solving this particular problem, the solution is not good enough, or have other side effects, so invented the new technology.

So, looking at a technology, a methodology, needs to put it in the "history", to see where it is in history, where.

By extension, more than just technology, any other knowledge, it does not need a "historical view." To speak a more professional philosophical term, this is called "Historical materialism" bar. Abstract Ability

Like the "pattern", "abstract ability" is a very "empty" word. As an architect, this "retreat thinking" is needed.

Abstraction is also a "hierarchy" structure, from the bottom to the top, at different stages of work, you need to think at different levels of abstraction.

Many people who write code are more accustomed to the "bottom-up" way of thinking. When you talk to him about demand, the first thing he thinks about is how this needs to be achieved, not whether the demand itself is justified. What is the correlation between this requirement and other requirements?

This premature consideration of "implementation details" of the way of thinking, will let you "trees, trees", eventually submerged in the vast variety of details, the level of confusion, not grasp the focus.

Also take the example above, if you're going to make a new system, from "abstract" to "detail", you might want to consider:

The rationality of each demand.

What is the domain model of the system?

This system should be rebuilt on the old one. Or should be a stove.

This system can be divided into installments and implemented in stages.

The system will be split into subsystems.

How many modules each subsystem splits up again.

Table design of the system. API interface design. The design of the job. Message transfer between systems.

。。。

From top to bottom, is a process of gradual refinement, and into the next 1 levels, the 1 level may be returned to modify. the ability to think deeply

The ability to think deeply, here refers to the depth of "technology". On the "breadth", the above "pattern" of this layer has been included.

"Depth" is not to say that you have to be deep in all areas. The energy of a person's life is limited, you cannot be deep in all technical fields, but you need 1 deep areas.

This depth does not mean that your current job requires the technical field, but rather the "way to think deeply" that will allow you to think about other problems with this "habit".

This thing is important because technology has been changing, and when you face a new technology, if you have the ability to think deeply and habits, then your understanding of the new technology is often very thorough.

At the same time, "depth" will give you a more sober understanding of "technical risk", when you do a project, this potential "pit", you may find in advance, rather than wait to do that, find the problem, forced to think. the landing of the architecture

Any architecture must be able to fall to the ground and be implemented. Can not fall to the ground, can only stay in the structure of the PPT above, it can only be fooled people. This kind of structure, not only has no guiding effect to the reality, but also has the reaction, is misleading to the actual development.

And an architect, should track from the architectural design to the framework to the complete process, "theory" to "actual" there must be clearance, tracking this process, real-time correction, only may really do "theory" and "actual" unity. Business Architecture vs. Technology architecture

Business architecture and technology architecture are typically 2 different areas of focus, the business architecture emphasizes a deep understanding of "domain", which is often closely related to "domain experts", which may emphasize the "scalability" of the system, the "reusability", and the flexible response to demand;

Technical architecture, need to have sufficient control of the underlying technology, here may emphasize the system's "high-performance", "High Concurrency", "high reliability" and so on.

Business architecture and technology architecture are not independent of each other, generally are "business-driven Technology", 2 in mutual promotion, at the same time to the depth and breadth of development. Organizational structure and leadership

More complex systems, are "people" developed. And after more people, "people" related to the problem will naturally occur: inadequate communication, organizational confusion, unclear responsibilities ...

As an architect, it is generally difficult to "get out of the way" and say I just "technology", regardless of "person". Because your work, is a "team" completed, not a "thousands of miles to go solo" hero.

So familiar with the entire organizational structure, asphalt responsibility, the various chaotic processes, coordination, and should also be taken into account. Summary

Speaking of now, you will find that I may not be talking about a "pure architect". Indeed, these are the things that I think as a "technical person" that should be constantly practiced, rather than the light "architect" needs.