Architects Must Be Hands On written by John Davie

按：选自《97 things every software architect should know》

合格的架构师应该是名技术上的全能手，且工程经验丰富，还善于与人沟通，能够指导他人。

 

A good architect should lead by example. He (or she) should be able to fulfill any of the positions within his team, from wiring the network and configuring the build process to writing the unit tests and running benchmarks. Without a good understanding of the full range of technology, an architect is little more than a project manager. It is perfectly acceptable for team members to have more in-depth knowledge in their specific areas but it’s difficult to imagine how team members can have confidence in their architect if the architect doesn’t understand the technology. As has been said elsewhere, the architect is the interface between the business and the technology team, and thus must understand every aspect of the technology to be able to represent the team to the business without having to constantly refer others.
　　Similarly the architect must understand the business in order to drive the team toward its goal of serving the business.
　　An architect is like an airline pilot: he might not look busy all of the time, but he uses decades of experience to constantly monitor the situation, taking immediate action if he sees or hears something out of the ordinary. The project manager (co-pilot) performs the day-to-day management, leaving the architect free from the hassles of mundane tasks and people management. Ultimately the architect should be responsible for the quality of the projects and their delivery to the business. This is difficult to achieve without authority, which is critical to the success of any project.
　　People learn best by watching others; it’s how we learn as children. A good architect should be able to spot a problem, call the team together, and without picking out a victim, explain what the problem is or might be and provide an elegant workaround or solution. It is perfectly respectable for an architect to ask for help from the team. The team should feel it is part of the solution, but the architect should chair the discussion and identify the right solution(s).
　　Architects should be brought into the team at the earliest part of the project; they should not sit in an ivory tower dictating the way forward, but should be on the ground working with the team. Questions about direction or technology choices should not be spun off into separate investigations or new projects, but be made pragmatically through hands-on investigation or using advice from architect peers—all good architects are well connected.
　　Good architects should be experts in at least one tool of their trade, e.g., an IDE; remember they are hands on. It stands to reason that a software architect should know the IDE, a database architect should know the ER tool, and an information architect should know an XML modelling tool. A technical or enterprise architect, however, should be at least effective with all levels of tooling, from being able to monitor network traffic with Wireshark to modelling a complex financial message in XMLSpy—no level is too low or too high.
　　An architect usually comes with a good resume and impressive past. He can usually impress the business and technologists, but unless he can demonstrate his ability to be hands on, it’s difficult to gain the respect of the team, difficult for the team to learn, and almost impossible for team members to deliver what they were originally employed to do.