Architecture Reviews Without The Hassle

Brice Nkengsa
The Andela Way
Published in
4 min readFeb 26, 2018

--

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 overtime 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
  • 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

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

Tools
As 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.

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

Agenda
For each architecture review item, we follow the following process:

  • Understand
    Grok the system’s essential architecture. Understand the current architecture & implementation, its gaps and limitations.
  • Diverge / Brainstorm
    Identify the scenarios the system would need to undergo in the future
  • Converge
    Throw the current architecture against those scenarios, then evaluate how they land. Is the current architecture able to meet the needs of those scenarios?
  • Debate
    Open 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.
  • Decide
    The architect or next best is final decision maker. The team ‘hankos’, and if necessary, disagrees and commits.

Regular architecture reviews are critical to ensure that the engineering team is making 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.

If you have any experience with running effective architecture reviews please share in the comments section below.

--

--

Brice Nkengsa
The Andela Way

Co-Founder @Andela. Software Engineer, Entrepreneur & Investor.