Back to overview

Expectations of an Architect

Architect

Expectations of an Architect

Make architecture decisions

Guide instead of specify technology choices. e.g. Instead of use React for frontend development, guide the team in making the choice between Angular, React, Vue or other reactive-based frameworks.

Continually analyze the architecture

Continually analyze the architecture and current technology environment and then recommend solutions for improvements.

  • performance
  • availability
  • scalability
  • testing and release environments

Understanding the key trends helps us prepare for future and make the correct decision. We may have a tech share every year for the trend.

Ensure compliance with decisions

Verify the team is following the architecture decisions and design principles.

Diverse exposure and experience

An architect is expected to have exposure to multiple and diverse technologies, frameworks, platforms, and environments.

It doesn't mean an architect must be an expert in every framework, platform and language, but rather that an architect must at least be familiar with a variety of technologies. Focus on technical breadth rather than technical depth. It's for more valuable for an architect to be familiar with 10 different caching products and the pros, cons of each rather than to be an expert in only one of them.

Well, I think an architect should be somehow deep in one of the popular technical choices and then extend the comfort zone to embrace more wide areas. As a frontend developer who'd like to be an architect, except understanding a library like React well, one must also know others, Vue, angular, build tools, testing, and even jumping out of the frontend area and learn some backend technologies, such as microservice.

Have business domain knowledge

Have a certain level of business domain expertise! Effective architects understand not only technology but also the business domain of a problem space. In VMware's Cloud Director plugin team, we should know what Cloud Director is, etc.

Possess interpersonal skills

Possess exceptional interpersonal skills, including teamwork, facilitation, and leadership. Many good architects are ineffective due to the inability to lead teams, coach and mentor developers.

Understand and navigate politics

Understand the political climate of the enterprise and be able to navigate the politics.

Laws of architecture

Everything in software architecture is a trade-off. — First Law of Software Architecture

Nothing exists on a nice, clean spectrum for software architects. Every decision must take into account many opposing factors.

If an architect thinks they have discovered something that isn’t a trade-off, more likely they just haven’t identified the trade-off yet. — Corollary 1

We define software architecture in terms beyond structural scaffolding, incorporating principles, characteristics, and so on. Architecture is broader than just the combination of structural elements, reflected in our Second Law of Software Architecture:

Why is more important than how. — Second Law of Software Architecture

We highlight why architects make certain decisions along with trade-offs.

Architectural Thinking

First, it’s understanding the difference between architecture and design and knowing how to collaborate with development teams to make architecture work. Second, it’s about having a wide breadth of technical knowledge while still maintaining a certain level of technical depth, allowing the architect to see solutions and possibilities that others do not see. Third, it’s about understanding, analyzing, and reconciling trade-offs between various solutions and technologies. Finally, it’s about understanding the importance of business drivers and how they translate to architectural concerns.

Technical Breadth

Unlike a developer, who must have a significant amount of technical depth to perform their job, a software architect must have a significant amount of technical breadth to think like an architect and see things with an architecture point of view.

Because architects must make decisions that match capabilities to technical constraints, a broad understanding of a wide variety of solutions is valuable.

Analyzing Trade-Offs

Thinking like an architect is all about seeing trade-offs in every solution, technical or otherwise, and analyzing those trade-offs to determine what is the best solution. To quote Mark (one of your authors):

Architecture is the stuff you can’t Google.

Everything in architecture is a trade-off, which is why the famous answer to every architecture question in the universe is “it depends.” While many people get increasingly annoyed at this answer, it is unfortunately true. You cannot Google the answer to whether REST or messaging would be better, or whether microservices is the right architecture style, because it does depend. It depends on the deployment environment, business drivers, company culture, budgets, timeframes, developer skill set, and dozens of other factors. Everyone’s environment, situation, and problem is different, hence why architecture is so hard. To quote Neal (another one of your authors):

There are no right or wrong answers in architecture—only trade-offs.