Architecture Reviews Without The Hassle

Traditional architecture reviews can be hectic. A group of senior engineers who disagree on the best approach to take, and question the need for the Architect sitting across from them who supposedly has all the answers. Great engineers have strong opinions, which is a good thing. Diverse opinions in engineering teams can lead to great outcomes. But how do you ensure that debates don’t drag on? In this post, I will share how I run architecture reviews on my team while ensuring effective decision making.

Why do we need an Architect?

In the early stages of a business, the engineering team is very scrappy, needs to deliver fast and as a result, all engineering decisions are carried out directly by the engineers during development. This often results in accumulated technical debt, though sometimes accrued through explicitly compromise.

As the business grows, experienced engineers on the team question the need for an Architect often with the assumption that the team can operate in similar fashion as in the early days, with the team making all architecture decisions. While wrong code implementation decisions can be fixed over time via effective technical debt management (e.g. 80/20 rule), incorrect architecture decisions are considerably more expensive to fix for a fast growing business. The role of an Architect is to:

• Set short to medium term strategic architectural direction aligned with business goals, able to look ahead 6–12 months
• Devise strategies to address areas of architectural debt, and create plans to improve them
• Devise strategies to scale the systems while maintaining and improving security, compliance, reliability, performance, etc as the organisation grows

Ultimately, the Architect looks ahead to ensure good investments looking towards the future.

The goal of the architecture review

The intent of architecture review on our team is to make sure:

• Large-scale architecture is unified and heading in the same direction
• A place to hash out larger technical decisions to ensure good investments looking towards the future
• Learn from each other and connect disparate points of tech across products and platforms
• Share knowledge of good architecture practices

Structure of the architecture review

CadenceEvery 2 weeks. Ensures that we are continuously re-evaluating the architecture and the backlog of architectural decisions doesn’t grow too big.

ToolsAs a distributed team, we use Trello to project manage the backlog of architectural decisions, and facilitate discussions and note-taking. Zoom for video conferencing, and Google Docs for documenting outcomes of the meeting we can then easily share laterally to the rest of the team and upwards to senior management.

AttendeesSenior Engineers, Architect, and Tech Leads (as needed depending on agenda). Anyone else is free to join as an observer.

AgendaFor each architecture review item, we follow the following process:

• UnderstandGrok the system’s essential architecture. Understand the current architecture & implementation, its gaps, and limitations.
• Diverge / BrainstormIdentify the scenarios the system would need to undergo in the future
• ConvergeThrow the current architecture against those scenarios, then evaluate how they land. Is the current architecture able to meet the needs of those scenarios?
• DebateOpen debate and ideas about what’s best for the system. Engineers share any results from proof of concepts, tests and external research. Make sure to hear ideas from EVERY single individual.
• DecideThe architect or next best is the final decision maker. The team ‘hankos’, and if necessary, disagrees and commits.

Regular architecture reviews are critical to ensuring that the engineering team is making the best bets, aligned with business goals, and looking towards the future. The hassle introduced by the diversity of opinions can be mitigated by a lightweight review process, ensuring everyone’s opinion is heard, and explicit commitment from the team once a decision is made.