In this paper, starting from InfoQ:www.infoq.com/cn/articles…

Being an architect is a challenging profession that requires attention to many dimensions and techniques. An architect who focuses on a single domain is not a good architect. Pat Kua (formerly a consultant at ThoughtWorks), a seasoned technologist, points out that a good architect needs to be a well-rounded architect, and discusses six characteristics that are essential to being a well-rounded architect.

  • As a technology leader
  • As a developer
  • Focusing on the system
  • Entrepreneurial mindset
  • Balance strategic and tactical thinking
  • Ability to communicate well

As a technology leader

A good software architect needs to understand that being a leader does not necessarily tell developers what to do. Instead, a good architect acts as a mentor, guiding the development team toward a common technical vision. Good architects use leadership skills such as storytelling, influence, conflict management, and trust building to turn their architectural vision into reality. A good leader is also a good architect. He/she listens carefully to each participant and adjusts their vision by interacting with feedback from the team.

As a developer

An architect is also a good developer. Often, making a good architectural choice requires balancing the desired architectural state against the current state of the software system. For example, it makes no sense to introduce a document database into a system if a problem is better suited to a relational database. An architect who does not consider the fit between the technology selection and the problem domain can easily be tempted by technology — this is the common “ivory tower architect” behavior pattern.

The best way to mitigate this is for the architect to spend more time with the developers and work on the code. Understanding how the system is built and its constraints will help the architect make the right choices in the current environment.

Focusing on the system

Experienced developers understand that code is only one piece of software. In order for code to run, they also need to understand other important quality attributes that code needs to work well in production. They need to consider deployment processes, automated testing, performance, security and supportability. Developers may implement these quality attributes in an AD hoc manner, while architects need to focus not only on understanding the code, but also on understanding and meeting the needs of different stakeholders, such as support, security and operations personnel. A good architect needs to focus on finding solutions that meet the needs of different stakeholders, rather than choosing tools or approaches that are optimized for the preferences or styles of one participant.

All technology sizing has associated costs and benefits, and a good architect needs to think about new technology sizing from both perspectives. Successful entrepreneurs are willing to take risks, but also look for ways to learn fast and fail fast. Architects can make technology choices in a similar way, gathering real-world information about short – and long-term costs and what benefits they might perceive.

A good example of this is when architects avoid committing themselves immediately to a tool they read about in a new article or heard about at a conference. Instead, they try to gather more information through architectural investigations to understand the relevance of the tool in its environment. Their choice of tool is not based on sales, but on what they need and the value the tool provides. They also look for hidden costs behind these tools, such as support for the tool (e.g., degree of documentation, community usage), constraints that the tool may impose, or additional risks that may be introduced in the long term.

Balance strategic and tactical thinking

Many teams have a handful of independent developers working together to build software, and each person tends to choose the tools and techniques with which they are most comfortable or experienced. A good architect keeps an eye on new technologies, tools, or approaches that might be useful, but doesn’t necessarily adopt them immediately. Technology adoption often requires long-term considerations. The architect will seek a good balance between agility (allowing teams to act quickly) and alignment (keeping enough consistency) at the team and organizational level. Exercises such as building your own technical radar are a useful tool for exploring technology with strategic thinking.

Good communication

Architects need to know that effective communication is a critical skill for building trust and influencing people outside the team. They know that different groups use different words, and it can be difficult to communicate with business people using technical terms and descriptions. Instead of talking about patterns, tools, and programming concepts, the architect needs to communicate with the audience using familiar vocabulary, such as risk-reward, cost, and benefit. This is better than simply using technical terms to communicate. Architects also need to recognize that communication within the team is just as important as external communication, and that the technical vision can be established and refined using diagrams and group discussions, and documented (such as architecture decision logs or wikis) to create a traceable history for the future.

conclusion

Being a technically well-rounded architect is not easy because there are so many areas to focus on, and each area has many skills that developers often don’t focus on and practice. The most important thing is not necessarily the ability of an architect, but that they have enough expertise in each different area. An architect with just one of these areas is not as valuable as an architect with good expertise in all six.

The Well Rounded Architect

Pat Kua/Mattresses

WeChat
Sina Weibo
Evernote
Pocket
Instapaper
Email
LinkedIn
Pinterest