TDR – Technical Design Review Process / Pavel Lakosnikov (Avito) (Category Architecture)

Interesting. report Pasha Lakosnikova from Avito about making high-quality technical solutions in a large company. The main points are approximately the following:

1. Pasha himself has been working in Avito for a long time and is now building architecture governance.
2. As the company grows, it becomes more difficult to make quality decisions due to the growth of chimsl teams and the complexity of the hierarchy.
3. Companies often introduce the roles of techlides and architects to solve these problems.
4. This leads to the fact that engineers are suspended from decision-making and they lose motivation and responsibility for decisions made without them.
5. Then there are architectural committees and archreview, where architectural artifacts are considered and decisions are made.
6. If you run all the decisions through the arch committee, it becomes a bottleneck and slows down the work, and also costs a lot of money.
7. The next step is to design a review of solutions in asynchronous format. This requires document templates to describe technical solutions + automatic validation of their filling. The document should include: author, team, unit, date of creation, level of influence (low, medium, high), review deadline.
8. Then there is a register of such documents and the ability to search and analyze solutions.
9. Initiatives are divided into different levels that require revisions of different rigor and format.
10. Levels of influence help different stakeholders track only the initiatives they need, for example, techdirs can track the biggest changes.
11. Technical initiatives have a connection with product initiatives, which allows us to better understand why we are making changes and how justified they are.
12. Initiatives have a life cycle: prototype, experiment, scaling. Each stage has its own detailed study. It is also possible to record dependencies between commands and components to prevent errors.
13. Since the initiatives identify the affected components, their owners are notified and may come to review the initiative in which they are mentioned.
14. The presence of a registry ensures the historicity of decision-making + allows you to customize the validation of decision-making than individual roles: authors, contributors, FIY and owners.
15. The registry can be linked to the technical radar, which should be the entry point into the technology life cycle.
16. All this ensures the transparency of the emergence and development of technologies, as well as their depracation and migration from EOL. (end of life)
17. Throughout this maschenria, you can collect metrics: the number of decision records, the time of their passage, the share of successfully completed and so on.
18. The implemented process helps to solve the problem with architectural committees, as well as increase the involvement of engineers.

P.S. About how it was arranged in the posts.

• Code of Leadership podcast series - Interview with Anton Kosterin about Architecture Governance
• My performance on ArchDays. 2024 - "Architecture in T-Bank: yesterday, today, tomorrow" Research Insights Made Simple series "API Governance at Scale"where Daniil Kuleshov and I discussed the whitepaper about how it works at Google, and also talked about governance in our company."

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance