It’s been a while I posted an excerpt from Quora. This one really resonated with me and I felt I should share. It was written as a response by Gary Wisnieski.

First, it’s important to differentiate software architecture from simply best practices. A good software engineer may be excellent at coding, excellent and detailed in their approach, and have a great deal of insight into the problem, but still, may not be a good architect.

At a minimum, a good architect should have the following skills:

• An architect is excellent at problem decomposition. Problem decomposition is the skill necessary to see a problem at virtually any level and break it down into the steps and pieces necessary to implement it. A good software architect can take a statement like “Our Air Traffic Control systems are inadequate and we need a better design” and knows the questions to ask to begin to decompose the problem into achievable components, to decompose those component goals into achievable sub-projects, and decompose those sub-projects into achievable programming tasks. A good architect can do these things at any level or scale from envisioning a billion line software project to understanding the best way to implement an algorithm to cope with unreliable links. The scale is irrelevant because the process is always the same.

• An architect understands interfaces. Interfaces, whether in the form of protocols, function libraries, class interfaces, or schemas are the primary tool needed to manage the complexity of projects when there are independent contractors and implementers. By knowing the process of defining crisp, unambiguous interfaces that are logically complete, an architect can empower many people to build pieces of systems that connect easily to achieve a larger goal.

• An architect understands that complexity is the enemy, and has a mastery of the programming tools and paradigms necessary to reduce complexity in all components, to reduce the complexity of interfaces, and assure minimal or no redundancy of implementation of function. They can quickly recognize algorithms and implementations which are too specific or too generic, and guide those developing to create components which perform just the right function. Often, the tools of managing complexity are things such as data hiding, object-oriented programming, self-validating systems, and comprehensive testing plans for standard interfaces. But, a good architect is not dogmatic about tools and technologies because they have a comprehensive academic understanding of the underpinnings and reasons why data hiding works, and why certain languages support good design principles and others do not.

• An architect is a good communicator, a good and prolific writer, and documentor, and is good at speaking the language of programming as well as the common language of those who are stakeholders in the system’s design. Along with good communication, a good architect can give concrete reasons for programming practices rather than opinions, and offers insight to their team rather than argument. They strongly favor and seek out the user’s opinion of suitability to that of their own or the programmers involved in the project.

• A good architect is a good leader and is excellent at gaining the respect of all the technical people they work with. Usually, this means that they have a high level of skill, have worked in multiple languages, and have been an architect before, or have demonstrated their ability to create systems designs which have remained flexible in the face of change.

Many definitions include an array of buzzwords, emphasizing methodologies like data-driven design, agile programming, specific languages, platforms, and toolkits. These things are current labels for various techniques whose basis needs to be well understood, not accepted because they are currently in vogue. So, in many ways, the chief skills of an architect are experience, intelligence, willingness to work hard and take a hands-on role, good intuition, and the ability to break down problems using logic so that as industry buzzwords come and go, their designs remain useful and relevant.

My definition above intentionally does not include project management, scheduling, and management skills. The architect’s role is to create good systems, not to solve team problems or budgets. In fact, it is best if those with budgets and team issues are simply stakeholders who help define one of the constraints the architect must deal with, just as if it were part of their design problem.