97 notes that the software architect should know (5)

63.
The architect is a developer first
Keep up with the development of their respective fields. Gain the respect and trust of developers, so that developers can voluntarily take over the task.
From time to deal with some complex tasks, the purpose: a) Make yourself a treasure B) helps developers prove that they are not just a blow
The main goal is to create feasible and maintainable solutions. The self-designed system should be programmed and implemented by itself.

64.
Making decisions based on ROI
Every decision we make to the project-whether it is technology, process, or people-related, can be seen as a form of investment. If the product market time is crucial to investors, fast release will bring higher Roi. At this time, the "perfect architecture" is not as bad as the architecture, but the version can be completed quickly.
Consider architecture decision-making as an investment and take the relevant Rate of Return into account.

65.
All software systems are legacy systems
The system is more advanced. It is a legacy system for those who interact with it. Therefore, this label should not be excluded.

66.
At least two optional solutions are required.
If only one solution is considered for a problem, it will be troublesome. If the solution is provided without comparison with other solutions, you have to think twice.

67.
Understanding the impact of changes
The abstraction provided by the architect in the solution should provide a solid foundation for a higher level and be pragmatic enough to cope with future changes. Understand changes, including people, systems, and systems. It is necessary to clearly understand the types and impacts of changes in the solution.

68.
You must understand the hardware.
Architects are responsible for connecting both business needs and software solutions, as well as hardware and software. Some hardware knowledge is equally important as software architecture, such as hardware Disaster Tolerance capabilities and capacity planning. In the absence of hardware planning capabilities, it is best to work closely with infrastructure architects.

69.
Now take shortcuts and pay interest in the future
When encountering architecture problems or design defects, as an architect, you must always start when the cost is low. The longer you put it on hold, the higher the interest you pay for it.

70.
Do not pursue "perfection". Just do "good enough ".
"Good enough" means that the remaining imperfections will not have any profound impact on the functions, maintainability, or performance of the system.

71.
Be careful "Good idea""
The evil of "good" ideas: they are good and cannot be easily discovered. For example, if a framework has an upgraded version, we should also use the new version. A technology is very powerful. We can use it ......

72.
Content is king
Many systems emphasize requirements, design, development, and security without any end, and never pay attention to the real key point of the system-data. Data is especially important for content-based systems. In the design process of the new system, you must focus on the evaluation content library. For example, the system focuses on what content, whether the content can be updated in a timely manner, and the main sources of the content.
The success of the system depends on its content.

73.
Architects should avoid cynicism on the business side.
If you feel too good about yourself, you will often forget to listen and refuse to listen to and analyze others' suggestions. Over-confidence will make your business dash. Business is the reason for the existence of the architect profession. Serving the business is the foundation of our survival. Listening to and understanding the business of employers is the most critical skill we must master.
Instead of making comments, we need to make constructive comments on the shortcomings.

74. Stretch key dimensions and discover deficiencies in Design
Some key dimensions are stretched to discover system design limitations. (That is, imagine that some dimensions are extended and stretched in advance)
For example, you need to know whether the basic design can meet the increasing demand and narrow down the limits. Can the peak throughput be processed normally.

75. architects should rely on their own programming capabilities
When designing a project architecture, you need to be aware of the workload required to implement each design element: If you have previously developed a design element, it would be much easier to estimate the workload required.
Do not use a pattern that you have not personally implemented in the design, do not use a framework that you have not used to write code, and so on. If the architecture depends on a variety of design elements that you have never used in person, there are many negative effects, such as the inability to estimate the time required to implement the design, the inability to easily avoid traps in those design elements, and the inability of developers to ask you when encountering problems.
(Architects keep up with their careers and pay more attention to them. They must use some frameworks and models on their own. They must have experience when using these things)

76. Proper Name
If you don't know what a thing should be called, you certainly don't know what it is.
If you cannot give a proper name, you cannot continue programming. If you find that you need to name it rationally multiple times, it is best to stop until you find out what you want to do.
Make sure you have a good name !!!!!!!!

77. Only stable problems can produce high-quality solutions
The best architect is not to solve the problem, but to work around the problem. Architects should be able to circle the various software problems and draw the boundaries to ensure a stable and complete understanding of the problems.
If the problem is stable, it will never bother you again after the problem is solved.

78. Tiandao rewards
Although being creative is an important feature of a successful architect, a successful architect also needs to be diligent. In many cases, project failure is not caused by insufficient capacity, but by lack of diligence and lack of urgency.

79. Responsible for decision-making
The root cause of many failed projects is that they make improper decisions or fail to make the right architectural decisions.
Methods for making effective decisions:
A) have a full understanding of the decision-making process (the decision was recorded in writing and communicated with the Decision-Making executor)
B) reviews the architecture decisions on a regular basis to check the actual results and expected results of the decisions.
C) To implement architecture decisions, architects should not only participate in the design phase, but should continue to follow up later.
D) Some decisions can be handed over to the problem domain experts.

80. Abandon smart, simple
Cleverness will induce us to use tricks and tricks in software development. Clever design is rigid and difficult to change. Details will involve too much in the whole world. In a simple solution, each component only does one thing, which consumes less time and is easy to create, making maintenance easier in the future.