API Design Patterns (Паттерны проектирования API) (Рубрика #Architecture)

В последнее время я много изучаю материалов на тему governance. Туда входит architecture governance, API governance и другие подходы для того, чтобы двигаться в сторону engineering excellence. И так получилось, что я в выходные снял с полки эту книгу "API Design Patterns" из последней закупки на распродаже в издательстве "Питер". Книгу написал Джей Джей Гивакс, соавтор статьи "API Governance at Scale" про подходы в Google. Он же был сооснователем ресурса aip.dev и одним из главных идеологов процесса AIP (API Improvement Proposals), про который я рассказывал раньше. Интересно, что с момента издательства книги Джей Джей уже успел перейти в Meta - это видно по заглавной страничке с авторами whitepaper:)

Когда я начал читать эту книгу, то понял, что она очень хороша - автор четко и методично рассказывает про паттерны для создания ресурсно-ориентированных API. Он делится теми подходами, к которым пришли ребята в Google и делает очень доступно. В общем, пока я еще всю книгу не прочитал, но уже могу порекомендовать ее для прочтения.

P.S.
Я разбирал статью "API Governance at Scale" в первом выпуске нового подкаста "Research Insights Made Simpe" (видео в Youtube, подкаст в Ya Music). Отдельно разбор есть в моем блоге в виде статьи.

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

The Engineering Executive's Primer - Part 0 (Рубрика #Management)

Я уже давно прочел новую книгу Will Larson для IT топ-менеджеров, про которую я писал раньше. Прочел и прочел, но все как-то не доходили руки написать про нее, но сейчас я в очередной раз сижу в аэропорту и жду самолета, поэтому время есть:) Сразу скажу, что книга мне понравилась - у Вилла как обычно отлично со структурой книги, а отдельные главы достаточно емкие и наводят на размышление (интересно, что они обычно появляются как статьи в блоге lethain.com, один из немногих блогов, что я читаю)

Продолжение в следующем посте.

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

The Engineering Executive's Primer - Part I (Рубрика #Management)

Продолжая нулевой пост с обзором книги, я хотел бы сказать, что Will не поскупился на контент и сгенерировал целых 24 главы, вступление, заключение и еще пяток дополнительных материалов. Разобрать все это добро за один раз не получится, поэтому постов будет много, но начнем мы с первого:)

0) Preface
Во введении автор рассказывает про то, как он пришел к идее этой книги после предыдущих книг "Staff Engineer" и "An Elegant Puzzle. Systems of Engineering Management". Первая является классным источником информации по карьерному пути для инженеров, которые переросли уровень senior и отправились покорять новые моря. Я про нее уже рассказывал: 1 и 2. Вторая книга хороша для engineering managers, про которую я рассказывал раньше, а потом было две серии подкаста "Code of Leadership" с разбором этой книги вместе с Eugene Sergueev, senior engineering manager из Flo health: 1 и 2
1) Getting the Job
Начинает книгу автор с того, чтобы рассказать про то, а как же можно получить работу в качестве engineering executive. Для начала стоит ответить себе на вопрос, а точно стоит в это вписываться? Дальше возникают вопросы, а где это делать: внутри текущей компании или во внешней. Дальше автор обсуждает хаотичный процесс найма топов, который отличается от компании к компании, а дальше еще идет и обсуждение условий. Ну и заканчивается все тем, а как размышлять относительного того, а принимать офер или нет. В общем и целом, глава действительно неплохо описывает этот непростой процесс и дает структуру и подход для взвешенного принятия решений.
2) Your First 90 Days
Здесь автор говорит о том, что в первые 90 дней придется серьезно попотеть и начать с того, чтобы разобраться с тем как работает бизнес и откуда приходят деньги, что определяет культуру компании, как установить здоровые взаимоотношения со стейкхолдерами и своими peers, насколько хорошо функционирует инженерная команда с точки зрения delivery, насколько высоко техническое качество софта и инструментов для поддержки процессов разработки, что с моралью инженерной команды и насколько сама команда устойчива для выбранного темпа развития команды. Дальше важно ограничить количство ранних изменений, что вы делаете в первые 90 дней. Кроме этого важно выстроить доверие с коллегами и позаботиться о поддержке с их стороны. Вообще, классно разобраться как в компании осуществляется работа и как выглядят технологии (включая код и деплой, дежурства, работа с инцидентами, ...)
3) Writing Your Engineering Strategy
Эту главу я разбирал еще тогда, когда она была просто статье в блоге автора. Статья была отличной и она не стала хуже после превращения в книжную главу:)
4) How to Plan
Автор рассказывает про стандартный подход к планированию в компаниях:
- Ежегодное финансовое планирование (включая план по headcount)
- Полугодовые или квартальные планы, например в виде OKRs для команд. Эти планы таргетируют бизнес результаты или список проектов, что надо сделать
- Внутрикомандные процессы управления работой (Kanban, Scrum, etc), которые направлены на то, чтобы уложиться в квартальные/полугодовые планы
- Отдельно автор говорит о том, что могут быть еще и периодические ревью, например, каждый месяц. Эти ревью направлены на отслеживание прогресса по выполнению целей компании

Продолжение в следующих постах: 2

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

The Engineering Executive's Primer - Part II (Рубрика #Management)

Продолжая нулевой пост и первый пост с обзором книги, я хотел бы рассказать про следующие главы

5. Creating Useful Organizational Values
В этой главе автор говорит про организационные ценности и как они влияют на работу компании. Он вспоминает свою работу в Uber и конкретно культурный принцип "Let builders build (People must be empowered to build things)", который повышал diversity технологического ландшафта. Каждый из инженеров считал, что этот принцип про то, что они могут делать то, что хотят:) Подробнее про Uber в книге "Super Pumped", про которую я уже рассказывал.
Дальше автор рассказывает о том какие проблемы решают организационные ценности, должны ли они быть общими для всей организаций или у инженерной части должны быть какие-то свои ценности. Мне нравятся критерии Вилла относительно того, а как проверить насколько ценность сформулирована так, чтобы приносит пользу:

- Reversible: It can be rewritten to have a different or opposite perspective without being nonsensical.
- Applicable: It can be used to navigate complex, real scenarios, particularly when making trade-offs.
- Honest: It accurately describes real behavior.

Интересно, что я видел в своей жизни список ценностей, каждый пункт которого не проходил по одному или нескольким из указанных выше критериев.

Дальше Вилл рассказывает как раскатывать обновления культутрных ценностей через стандартный процесс раскатки изменений: "identify the opportunity, document potential options, involve stakeholders early to build buy-in, test before finalizing to avoid folks feeling trapped, and iterate until it’s useful". А потом отдельно надо встроить изменения в найм, онбординг, лестницу грейдов. Ну и дальше подсвечивать соответствие новым ценностям во время работы.
Напоследок автор приводит тот список ценностей, что кажется ему полезным

- Create capacity (rather than capture it).
- Default to vendors unless it’s our core competency.
- Follow existing patterns unless there’s a need for order-of-magnitude improvement.
- Optimize for the [whole, business unit, team].
- Approach conflict with curiosity.

6. Measuring Engineering Organizations
Эту главу автор начинает с перечисления подходов к измерениям в инженерных организациях, а дальше он рассказывает про свой подход к измеренями, про паттерны и антипаттерны. И для начала надо отметить, что он делит подходы на измерения для себя и измерения для стейкхолеров. В части "measuring for yourself" он говорит про измерения для планирования, выполнения, оптимизации, а также для вдохновения. В части измерений для стейкхолдеров автор говорит про измерения для CEO и совета директоров, для финансового департамента, для стртегически peers (продукт, дизайн, продажи), для тактических peers.
Дальше автор предлагает алгоритм для измерений
1) Некоторые вещи сложно измерить, поэтому пробуйте это измерить только если вы действительно планируете учитывать это при принятии решения. Если же это нет так, то просто померьте что-то попроще, навроде, прокси-метрики
2) Часть измерений очень проста, поэтому появляется желание сделать эти измерения для построения доверия со стейкхолдерами:) И тут часто желание измерений и усилия, приложенные для их получения, важнее чем реальный результат:)
3) Если возможно, добавляйте по одному измерению за раз, так как если пытаться внедрить слишком много изменений в измерения, то можно облажаться.
Дальше автор приводит список антипаттернов для измерений

- Focusing on measurement when the bigger issue is a lack of trust.
- Letting perfect be the enemy of good.
- Using optimization metrics to judge performance.
- Measuring individuals rather than teams.
- Worrying too much about measurements being misused.
- Deciding alone rather than in community

Интересно, что этот список хорошо пересекается с антипаттернами из книги "Тирания показателей" ("The Tyrany of Metrics"), про которые я рассказывал раньше

Продолжение в следующих постах.

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

What Is Your Definition of Software Architecture (Рубрика #Architecture)

Пока готовился к своему выступлению на ArchDays в пятницу, наткнулся на paper почти 15-летней давности от Software Engineering Institute с названием "What Is Your Definition of Software Architecture". В нем авторы сделали подборку определений архитектуры программного обеспечения с начала времен по 2010 год. Среди определений встречаются примечательные

1) Из книги "Documenting Software Architectures: Views and Beyond (2nd Edition)", Clements et al, AddisonWesley, 2010:
The set of structures needed to reason about the system, which comprises software elements, relations among them, and properties of both.
2) Из книги " Software Architecture in Practice (2nd edition)", Bass, Clements, Kazman; AddisonWesley 2003, которую я перечитывал пару раз
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.
3) Из стандарта ANSI/IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software Intensive Systems
Architecture is defined by the recommended practice as the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.
4) Из RUP (Rational Unified Process)
An architecture is the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these structural and behavioral elements into progressively larger subsystems, and the architectural style that guides this organization---these elements and their interfaces, their collaborations, and their composition

В итоге, можно выделить следующие взгляды на программную архитектуру
- Высокоуровневая структура - организация системы, структурных элементов и их интерфейсов. Фокус на взаимодействии элементов
- Абстракция и композиция - архитектура представляет собой абстракцию, что скрывает реализацию. Такие абстракции позволяют проще думать о взаимодействиях компонентов. Эта тема была отлично раскрыта John Osterhout в книге "A Philosophy of Software Design", что я рассматривалась в 21 выпуске подкаста "Code of Leadership"
- Набор структур - этот набор позволяют комплексно размышлять о программной системе, в этот набор обычно включают элементы, их взаимосвязи и свойства
- Руководящие принципы - это история про governance:) Суть в том, что архитектура - это про принципы, политики, модели, стандарты. В общем, тут фокус на стратегическом роли архитектуры. Недавно я вспоминал книгу про "Continuous API Management", где тема governance была отлично раскрыта
- Компромиссы и принятие решений - это история про принятие фундаментальных структурных решений, что стоят дорого для будущего. Фокус на поиске компромиссов между функциональными и нефункциональными требованиями
- Архитектурные стили и паттерны - это практический подход, который фокусируется на выделении повторно используемых подходов к построению архитектуры. Недавно вспоминал про книгу "API Design Patterns"
- Коммуникация со заинтересованными сторонами - здесь фокус на том, что нам надо обсуждать и согласовывать архитектурные решения со стейкхолдерами для принятия дорогих решений.

В итоге, определений много и перефразируя Джорджа Бокса, все они неправильные, но некоторые полезны:)
Главное понимать их границы применимости и использовать по назначению. У меня вроде картинка за 20 лет работы в IT сложилась:)

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

The Engineering Executive's Primer - Part III (Рубрика #Management)

Продолжая первые посты об этой крутой книге (0, 1, 2) с обзором книги, я хотел бы рассказать про следующие главы.

7) Participating in Mergers and Acquisitions
В этой главе автор говорит про участие ИТ топ-менеджеров в merge & acquisitions процессах. Для начала автор разбирает про сложные мотивы для m&a действий - условно цели команды, что ведет сделки, отличаются от целей инженерных команд. В общем, важен общий взгляд на процесс и понимание бизнес-стратегии, чтобы оценить соответствует ли поглощение целям компании и выявить потенциальные риски. Отдельно автор описывает структурированный подход к оценке поглощений с инженерной точки зрения, куда входит создание шаблонов для оценки сложности внедрения, проблем интеграции, масштабируемости, безопасности, соответствия требованиям, затрат и инженерной культуры. Важно также запланировать интеграции между объединяемыми компаниями - важен четкий план интеграции для эффективного управления переходом после поглощения. Это включает решения по интеграции технологий, реструктуризации команд и роли лидерства. А дальше надо управлять этим процессом.

😍 Developing Leadership Styles
Автор предлагает модель из трех подходов к управлению
- Leading with policy - для повторяемых решений, которы надо делать консистентно разными людьми внутри организации
- Leading from consensus - для нечастых решений с контекстом, который распределен между несколькими заинтересованными сторонами.
- Leading with conviction - для решений без четкого предложения, когда вовлеченные лица сильно расходятся во мнениях или когда решение оказывает значительное долгосрочное влияние на вашу организацию
В этой главе автор приводит примеры из своего опыта в разных компаниях (Digg, Uber, Stripe, Calm). А дальше говорит о том, что надо уметь работать над прокачкой тех стилей лидерства, что несвойственны вам. Это позволит вам стать более универсальным руководителем:)

9) Managing Your Priorities and Energy
В этой главе автор рассказывает про свою стратегию к решению задач вида "Компания - Команда - Я". Изначально автор рекомендовал принимать решения, основываясь на иерархии: сначала компания, затем команда, и в последнюю очередь — личные интересы. Этот подход использовался для обеспечения соответствия решений целям компании, а не личным или командным предпочтениям. Однако позже автор осознал, что такая жесткая структура может привести к выгоранию и потере мотивации среди сотрудников. Но дальше автор подчеркивается важность управления энергией как процесса с положительной суммой. Предполагается, что предоставление людям возможности заниматься работой, которая их вдохновляет, даже если она не соответствует непосредственным приоритетам, может повысить общую продуктивность и удовлетворенность работой.

В итоге, концепт "Company, Team, Self" изменяется на подход "Eventual Quid Pro Quo", которая балансирует приоритеты компании с личными потребностями в энергии. Этот подход поощряет приоритизацию вдохновляющей работы при необходимости для поддержания долгосрочной вовлеченности и эффективности. Автор подчеркивает необходимость гибкости в применении стратегий. Утверждается, что хотя следование правильным приоритетам важно, это не должно происходить за счет личной энергии и мотивации. Лидеры должны адаптировать свои подходы в зависимости от личных нужд и контекста их ролей.

Продолжение будет в следующем посте.

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

Архитектурные материалы для изучения от облачных провайдеров (Рубрика #Architecture)

Как-то раньше я не писал о том, что помимо книг есть большое количество архитектурных материалов у главной тройки cloud провайдеров.

1) У AWS это называется AWS Well-Architected Framework, у него 6 ключевых столпов
- Operational excellence (операционная эффективность): Фокус на управлении и мониторинге систем для обеспечения бизнес-ценности и постоянного улучшения процессов.
- Security (безопасность): Защита информации и систем с помощью надежного управления идентификацией, защиты данных и обнаружения инцидентов.
- Reliability (надежность): Обеспечение того, что рабочие нагрузки выполняются в соответствии с ожиданиями и быстро восстанавливаются после сбоев.
- Performance efficiency (эффективность): Оптимальное использование ресурсов для удовлетворения требований системы.
- Cost optimization (оптимизация затрат): Помощь в отсутствии ненужных расходов при сохранении производительности.
- Sustainability (устойчивость): Фокус на минимизации воздействия на окружающую среду за счет оптимизации энергопотребления.

2) У Microsoft это называется Azure Well-Architected Framework. Он имеет схожие цели и структуру с AWS фреймворком, в нем даже то же самое название, но столпов всего 5 (выпала часть про sustainability)
- Cost optimization (оптимизация затрат): Максимизация ценности при минимизации расходов.
- Operational excellence (операционная эффективность): Эффективное управление операциями и автоматизация процессов.
- Performance efficiency (эффективность): Обеспечение производительности и масштабируемости приложений.
- Reliability (надежность): Построение отказоустойчивых архитектур, способных восстанавливаться после сбоев.
- Security (безопасность): Защита данных и систем через надежные методы безопасности.

3) У Google это называется Cloud Architecture Framework. Он имеет немного другую структуру, но также фокусируется на ключевых принципах построения облачных решений. У него пять столпов:
- Operational excellence (операционная эффективность): Эффективное развертывание, эксплуатация, мониторинг и управление рабочими нагрузками.
- Security, privacy, and compliance (Безопасность, конфиденциальность и соответствие требованиям): Обеспечение безопасности данных, их конфиденциальности и соблюдения нормативных требований.
- Reliability (надежность): Построение отказоустойчивых систем, способных выдерживать сбои.
- Cost optimization (оптимизация затрат): Максимизация бизнес-ценности за счет оптимизации использования ресурсов.
- Performance optimization (оптимизация производительности): Настройка ресурсов для достижения оптимальной производительности.

Из этого краткого описания фреймворков видно, что у них похожие фокусы на оптимизацию затрат, безопасность, оптимизацию производительности, надежность. В общем, на вопросы, которые важны для клиентов, что планируют заезжать в облака (но важны также и при разворачивании on-prem). Эти фреймворки направлены на то, чтобы помочь организациям постоянно оценивать и улучшать свои облачные архитектуры на основе лучших практик, предоставляемых соответствующими облачными провайдерами. Хотя конкретные детали реализации могут различаться между провайдерами, основные принципы остаются схожими на всех платформах.

Кстати, часть научных статей ребят превращаются в мануалы внутри этих фреймворков. Например, раздел "Deployment archetypes" из документации Google изложен в научной статье "Deployment Archetypes for Cloud Applications", которую я разбирал больше года назад в своем блоге.

#DistributedSystems #ExternalReview #SoftwareDevelopment #SoftwareArchitecture #Architecture #SystemDesign #SystemEngineering #Cloud

Research Insights Made Simple #4 - Обсуждение "AI-Enhanced API Design"

В этом эпизоде мы обсуждаем интересный whitepaper "AI-Enhanced API Design" от ребят из Google, где рассказывалось о том, как подходы к управлению API влияют на продуктивность и usability. Исследователи показали, что общие стандарты вместе с инструментами, которые помогают им следовать, приводят к статистически значимым улучшениям в качестве дизайна API.

В разборе мне помогает крутой гость - Павел Каравашкин, мой коллега. Павел является руководителем разработки платформы T-API, а также лидером профессии системного анализа в Т-Бизнес, соведущим подкаста SA Т-Банка InSAйт. Паша любит велоспорт, Warhammer 40k и читать случайные статьи на Википедии.

Кстати, эпизод доступен и в подкасте Яндекс Музыки.

Материалы:
- AI-Enhanced API Design: A New Paradigm in Usability and Efficiency
- Мой обзор этой научной статьи
- Публичное T-API для партнеров
- Подкаст InSAйт

Мы обсудили следующие моменты
- Обзор статьи и личные впечатления Павла
- Обсуждение структуры статьи
- Проблемы и аспекты проектирования API
- Процесс разработки API в Google
- Гибкость и стандартизация в разработке API
- Методология исследований в Google
- Подходы к исследованием вокруг API в T-банке
- Проблемы и решения в персонализации
- Использование линтеров и метрик
- Анализ логов и задач разработчиков
- Исследования и метрики в Google
- Генерация контрактов
- Проблемы с архитекторами
- Методология эксперимента в Google и его результаты
- Ограничения эксперимента
- В общем про процесс разработки и помощь автоматизированных средств
- Важность этапа реализации
- Архитектура и улучшение процессов
- Измерение эффективности инструментария (отсылка к статье "Measuring developer goals" от ребят из Google)
- Роли в разработке
- Автоматизация кибербезопасности (отсылка к предыдущему подкасту)Заключение и планы на будущее

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

Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity (Радикальная прямота) (Рубрика #Management)

Прочитал на этой неделе книгу Ким Скотт про радикальную прямоту, которая рассказывает об управлении людьми посредством честного и прямого общения. Автор представляет концепцию, которая является основой для предоставления обратной связи, сочетающей личную заботу о людях с прямым вызовом и жесткими требованиями. Этот подход направлен на улучшение коммуникации, построение доверия и повышение эффективности команды. Книга состоит из двух частей и восьми глав

Часть I - Новая философия менеджмента
1. Выстраивание радикально откровенных отношений. В этой главе описывается основная идея книги - важность сочетания личной заботы о сотрудниках с прямым вызовом. Автор объясняет, как это помогает улучшать рабочие отношения и повышать производительность команды.
2. Получать, отдавать и помогать. Эта глава посвящена методам установления доверительных отношений в команде, что является основой для успешного применения радикальной откровенности. Для этого автор описывает модель, которая визуализируется как двухмерный график. На графике вертикальная ось представляет "Личную заботу", а горизонтальная ось - "Прямой вызов". Цель состоит в том, чтобы работать в квадранте, где оба элемента высоки, создавая среду открытой и конструктивной обратной связи. Это и есть квадрант радикальной откровенности, а также есть разрушительное сочувствие, оскорбительная агрессивность и манипулятивная неискренность.
3. Что мотивирует каждого члена вашей команды. Здесь автор приводит свою модель суперзвезд и надежных сотрудников: фактически есть "суперзвезды", которые находятся на крутой траектории роста, и "надежные сотрудникы", которые предпочитают стабильность и устойчивую производительность. Признание этих различий помогает эффективно управлять ростом команды.
4. Добиться успеха вместе. В этой главе автор рассказывает про свою модель работы с людьми в команде "Выслушать" - "Объяснить" - "Обсудить" - "Решить" - "Убедить" - "Выполнить" - "Усвоить" и дальше опять "Выслушать". На протяжении всей главы автор рассказывает как должен работать этот цикл в компании.

Часть 2 - Инструменты и техники
5. Взаимоотношения. Эта глава посвящена построению и поддержанию эффективных отношений в команде. Автор подчеркивает важность доверия и открытого общения между коллегами. Она предлагает стратегии для улучшения взаимодействия, чтобы создать более сплоченную и продуктивную рабочую среду.
6. Наставничество. В этой главе рассматривается роль наставничества в развитии сотрудников. Автор объясняет, как руководители могут эффективно наставлять своих подчиненных, помогая им расти и развиваться в профессиональном плане. Она делится методами, которые позволяют вдохновлять и мотивировать сотрудников через личный пример и поддержку.
7. Команда. Глава фокусируется на создании эффективных команд. Автор обсуждает, как собрать команду, которая будет работать слаженно и продуктивно, а также как управлять различиями в характерах и навыках сотрудников. Автор подчеркивает важность разнообразия и инклюзивности для достижения лучших результатов.
8. Результаты. Заключительная глава посвящена достижению результатов через применение принципов радикальной откровенности. Автор делится инструментами и техниками, которые помогают руководителям не только устанавливать высокие стандарты, но и достигать их вместе с командой. Она акцентирует внимание на том, как измерять успех и корректировать подходы для постоянного улучшения.

Интересные факты о книге
- Ким Скотт активно использует свой опыт работы руководителем в bigtech компаниях, таких как Google и Apple.
- Она подчеркивает необходимость адаптации радикальной откровенности к различным культурным контекстам, чему она научилась в процессе работы с разнообразными командами по всему миру
- Книга не только теоретическая - она включает практические инструменты, такие как сценарии для сложных разговоров и основы для эффективных встреч.

#Engineering #Management #Leadership #Processes #SystemDesign #SystemThinking #SystemEngineering

TDR — процесс технического дизайн-ревью / Павел Лакосников (Авито) (Рубрика #Architecture)

Интересный доклад Паши Лакосникова из Авито про принятие качественных технических решений в большой компании. Основные тезисы примерно следующие
1) Сам Паша давно работает в Авито и сейчас занимается выстраиванием architecture governance
2) По мере роста компании все сложнее принимать качественные решение из-за роста чимсла команд и усложнения иерархии
3) Компании часто вводят роли техлидов и архитекторов для решения этих проблем
4) Это приводит к тому, что инженеров отстраняют от принятия решения и они теряют мотивацию и ответственность за принятые без них решения
5) Дальше появляется архитектурные комитеты и архревью, где рассматриваются архитектурные артефакты и принимаются решения
6) Если все решения прогонять через архкомитет, то он становится бутылочным горлышком и замедляет работу, а также стоит много-много денег
7) Следующий шаг - это дизайн ревью решений в асинхронном формате
😍 Для этого нужны шаблоны документов для описания технических решений + автоматическая валидация их заполнения. В документе должны быть: автор, команда, юнит, дата создания, уровень влияния (низкий, средний, высокий), сроки ревью.
9) Дальше появляется реестр таких документов и возможность поиска и анализа решений
10) Инициативы делятся на разные уровни, которые требуют ревью разной строгости и формата
11) Уровни влияния помогают разным стейкхолдерам отслеживать только нужные им инициативы, например, техдиры могут отслеживать самые крупные изменения
12) У технических инициатив есть связь с продуктовыми, что позволяет лучше понять для чего мы делаем изменения и насколько они оправданы
13) У инициатив есть жизненный цикл: прототип, эксперимент, масштабирование. Каждый этап имеет свою детальность проработки. А также можно фиксировать зависимости между командами и компонентами для предотвращения ошибок.
14) Так как в инициативах указываются затронутые компоненты, то их владельцы получают уведомления и могут прийти поревьювить инициативу, в которой они упоминаются
15) Наличие реестра обеспечивает историчность принятия решений + позволяет настроить валидацию принятия решений, чем отдельные роли: авторы, контрибьюторы, FIY и owners
16) Реестр можно связать с техническим радаром, который должен быть входной точкой в жизненный цикл технологий.
17) Все это обеспечивает прозрачность появления и развития технологий, а также их depracation и миграции с EOL (end of life)
18) По всей этой машиенрии можно собирать метрики: количество decision records, время их прохожджения, доля успешно доведенных до конца и так далее
19) Внедренный процесс помогает решить проблему с архитектурными комитетами, а также повысить вовлеченность инженеров

P.S.
Про то, как это устроено у нас было в постах
- Серия подкаста "Code of Leadership" - Interview with Anton Kosterin about Architecture Governance
- Мое выступление на ArchDays 2024 - "Архитектура в Т-Банке: вчера, сегодня, завтра"
- Серия подкаста Research Insights Made Simple про "API Governance at Scale", где мы с Даниилом Кулешовым разбирали whitepaper о том, как это устроено в Google, а также говорили про governance у нас в компании

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