Scribd
Upload
3 views

Architecture_Review_Process

Uploaded by

doyer.guyllaume
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
3 views

Architecture_Review_Process

Uploaded by

doyer.guyllaume
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

Architecture Review Process

The architecture review enables a team to seek feedback from the entire team on a
specific architectural design (new feature, major refactor, major optimisation or
important fix) in order to de-risk the solution and make sure it satisfies to the
architectural vision and quality expectations of the company. If done properly it
should not add much work or delays in the overall design and build process while
providing a very powerful source of validation of the design to a specific team.

The topic under review may not be an entire feature or group of features under
development. It can be a thorny technical issue, a major refactor or any major
change that is potentially bringing risks to the rest of the stack and our production
systems.

Architecture Review Ceremony


One meeting is enough. It is recommended to invite all the engineers and potentially
PMs and designers in PDT. Most people are optional except all platform engineers or
architects, squad architects and most engineering leads and managers along with all
engineers participating to the implementation under review. It is recommended that
the PM(s)/designer(s) involved in the project join also.

Two weekly slots are defined in all engineers, PMs and designers calendars as
placeholders for potential architecture reviews. This scheduling page enables any
team to reserve a slot. Let's try to schedule an architecture review as early as
possible and at least two days before the due date. When registering an architecture
review in the corresponding schedule, the team will name a moderator whose role
will be to structure the meeting in real time and take notes on the actionnable items
that result from the exchanges of opinions during the meeting itself.
At least two days before the review, one of the team leaders sends a reminder to the
whole PDT organisation of the pending architecture review. She/he also attaches an
architecture review document modeled after the architecture review template below.
This should be a distributed document type Google Doc. All participants must read
the document and ask their questions in it (if not they come prepared and can ask
additional questions on the fly during the ceremony).

During the meeting, the moderator doesn't repeat the document. Everyone is
supposed to be familiar with it. Instead the team will go over the questions

Architecture Review Process 1


progressively and leave time for the participants to ask more questions. Questions
can be assertions and comments.

Some of the points made will lead to final action items: modifications, improvements,
inconsistencies, unhandled risks and more. Even though this meeting originates
from the technical track, functional and design issues can also be identified through
that process!

Roles and Responsibilities


Any developer can spawn an architecture review. The best is to consult team
leads and our chief architect to make sure it is appropriate or if the issue at hand
can be resolved differently (an architecture review is still an investment in time
and efforts for many in the team).

Team managers and/or leads are responsible for spawning an architecture


review for important developments within their team in order to avoid introducing
major risks and issues in the stack.

A PM in charge of a specific feature group has vested interest in making sure the
appropriate architecture review happens (de-risking, productivity, production
quality and maintainability). She/he should check with her/his engineering
counterparts opportunistically.

The chief architect or any other architect of the organisation can escalate the
deemed highly risky nature of a specific feature or design and demand a change
of direction. She/he should sync up with executive sponsors to evaluate next
steps. Other architects can do the same after consulting the chief architect.

Architecture Review Template


These sections are not mandatory except maybe 1., 2. and 3. Choose the ones you
want to fill in if they bring information useful to the purpose of the corresponding
review!

Introduction
Quick description of the goal for that review

Resources and References

Architecture Review Process 2


JIRA epics, stories and tickets related to the review. Same with other design
resources that the team wants to share.

Feature(s) Description
Description of what functions will be reviewed. It can be a purely technical problem.

Data Model(s)
Potential data models to solve the issue under review.

Entities
Potential class, object, component and other entity related models to describe the
design under review.

Flows
Potential event, sequence, state diagrams and flows to describe the system under
review.

Volumetrics
Potential bandwidth, volume of data flows, memory and other data/performance
metrics of importance in the system under review.

Infrastructure and Services


New type of architecture or (cloud based) services that will be used to support the
system under review.

Experimentation
A/B tests, Segmentation and other experimentation techniques and sets.

Deployment plan
Deployment strategies including mitigation and rollback strategies.

Can you envision performance risks? Describe


Present what you believe brings potential performance risks and describe them.

Can you envision infrastructure risks? Describe


Present what you believe brings potential infrastructure related risks and describe
them.

Architecture Review Process 3


Can you envision exploitation risks? Describe
Present what you believe brings potential exploitation risks and describe them.

Can you envision security risks? Describe


Present what you believe brings potential security risks and describe them.

Can you envision maintainability risks? Describe


Present what you believe brings potential maintainability risks and describe them.

Can you envision deployment or release risks? Describe


Present what you believe brings potential deployment risks and describe them.

Can you envision any other risks (tech debt, functional, other)?
Describe
Present what you believe brings additional risks and describe them.

Action Items
To be complemented during and after the review.

Outputs and Decisions


Action items decided during the review: modifications to the specifications,
modifications to the design, additional tasks or infrastructure work, involvement
of operational or business people in certain tasks or cases.

These action items are transformed into JIRA tickets and/or work streams by the
organisers. It is potentially necessary to ping executive management (at least at
PDT) to organise some of these corresponding work streams or changes (re-
prioritisation of the roadmap for example).

Potentially the chief architect, CTO or other sponsors can require to freeze
current developments to reconsider the whole feature and its design.

Architecture Review Process 4

You might also like