Архитектура как код - Роман Пионтик - ArchDays 2022 (Рубрика #Architecture)

Интересное выступление про Dochub от автора инструмента на ArchDays 2022. Актуальная информация по инсструменту расположена здесь, но тут я расскажу про основные тезисы доклада:
- Основная идея была в создании инструмена для покрытия всех этапов развития компании, от стартапа до зрелой организации.
- Этот инструмент должен быть адекватным конкретному домену, встраиваться в процессы производства и анализировать архитектуру.
- Инструмент должен был поддерживать расширяемую метамодель, позволяющую анализировать данные архитектуры.
- Инструмент должен поддерживать командное развитие архитектуры и контроль глобальных стандартов.
- То, что получилось позволило сделать "живые" документы и шаблоны, которые валидируются и актуализируются
- Внутри есть комбинация инструментов вида
-- PlantUML и Mermaid - для диаграмм как код
-- Markdown - для разметки и документации
-- Swagger и AsyncAPI - для документации контрактов API
-- YAML/JSON манифесты для описания архитектурных объектов
-- SmartAnts - язык для запросов по этим описаниям
Все это позволяет накрутить поверх проверки этой архитектурной документации, которые позволяют контролировать важные для архитекторов вещи при помощи запросов на языке SmartAnts.

В общем и целом, по моим ощущениям от этого доклада получается примерно такая схема:
- Предлагается некоторая система для документирования архитектуры на базе Dochub
- В этой системе работают специальные люди, у которых шилдик "архитектора"
- Они пишут не код приложений, а код, который документирует архитектуру
- Они же пишут валидаторы этого описания архитектуры
- А SDE (software development engineers) пишут свой код в продакшен системах
- Дальше встает вопрос а кто поддерживает актуальность production code vs architecture code и в рамках какого процесса? Например, если это обязательный этап для любой фичи и его надо пройти еще до ее релиза, то тогда lead time взмывает в небеса, если это делает благословленный небом архитектор, а если это делают SDE, то неясно какое преимущество он получает от этих действий. Если это делается постфактум, то мы опять получаем лаг между реальным кодом и архитектурным описанием как бы оно не было получено: нарисовано картинками или сгенерировано из описания картинки кодом (с тем же успехом можно промптом попросить chatGPT генерировать картинки).

P.S.
В этом подходе меня смущает, что все самое интересное заметено под ковер. Условно, хотелось бы уметь связывать архитектурное описание и реальность, причем идти от второго, а не рисовать первое хоть кодом, хоть руками. В итоге, описанный процесс с Dochub мне кажется сложным, дорогим и неудобным для всех в команде разработки, кроме архитектора, который находится во вне и придумывает правила и проверки, а также рисует диаграммы кодом.

P.P.S.
Интересно сравнить рассказ Романа из Сбера про Dochub и то, что в том же 2022 ходу рассказал Кирилл Ветчинкина из Сбер Маркета про их архрепу и процесс написания ADR (я рассказывал об этом вчера). Подход Кирилла показался мне более приземленным, практичным и полезным.

P.P.S
В следующем посте напишу куда я бы хотел копать эту тему с архитектурой, чтобы сделать сделать работу над архитектурой неинвазивной и полезной для самих разработчиков.

#Architecture #Software #SoftwareArchitecture #Management #Processes

Материалы к докладу "Architecture at T-Bank: how we design our solutions" (Рубрика #Architecture)

Сегодня я выступаю на нашем фестивале Т-Двор в Питере с рассказом про проектирование и архитектуру. Сегодняшний день фестиваля посвящен науке и технологиям, поэтому я решил взять такую тему и подать ее по максимуму просто, чтобы любой посетитель фестиваля понял. В итоге, у меня в докладе получилось много отсылок, которые заинтересовавшиеся смогут изучить в свободное время сами, а не просто верить мне на слово:) И вот эти отсылки
- Мое древнее выступление на ArchDays 2020 про подходы T-Bank (ex Tinkoff) к архитектуре
- Книга "Learning Domain Driven Design"("Изучаем DDD") Влада Хононова и особенно первая часть книги про стратегические паттерны DDD, где идет речь про бизнес домены и поддомены, а также их типы (core, generic, supporting). Про книгу я уже много рассказывал раньше
- Cynefin framework - интересная концепция про сложность с точки зрения предсказуемости наших действий, подходит для размышлений как в контексте менеджмента, так и архитектуры
- Книга "Balancing Coupling in Software Design" Влада Хононова или хотя бы его выступление "Сложность и модулярность две стороны одной медали" на ArchDays 2023, про которое я рассказывал раньше. Влад хорошо рассказывает про архитектуру как управление сложностью и показывает простой инструмент для ответа на вопрос "а хороша ли наша архитектура" и пора ли ее улучшать:)
А дальше идут отсылки к тому, а как менять это в большой организации
- Закон конвея и обратный маневр Конвея и почему нам часто для улучшения архитектуры системы под задачи бизнеса надо поменять оргструктуру. Кстати, я раньше рассказывал про интересный доклад "How Technical Problems Cause Organizational Friction" от Adam Tornhill на тему того, как из кода можно вытащить данные о том, что есть проблемы со взаимодействием команд и принять меры:) Ну и в эту же тему есть мой рассказ про изменения в мобильном банке, где менялась команда, процессы, архитектура, ...
- Переход на платформенные решения - мне видится это основным способом двигать архитектуру IT систем в сторону унификации и начинать экономить на масштабе, так как платформенные решения можно централизованно развивать под нужные сценарии. Рекомендую на эту тему почитать статью моего коллеги Димы Гаевского, который ее сделал по мотивам своего выступления на Highload++ Spb 2022 (я уже рассказывал про этот доклад раньше)
- Архитектура как код - это интересная концепция, которая у многих на слуху. Текущие подходы больше напоминают архитектурную документацию как код, которую сложно и дорого поддерживать, но которая дает ощущение контроля за архитектурой. На эту тему можно посмотреть
-- Выступления Кирилла Ветчинкина из Сбер Маркета, про которое я уже рассказывал
-- Выступление Романа Пионтика из Сбера, про которое я уже рассказывал
Мне кажется, что можно сделать работу над архитектурой еще лучше, но про это я отдельно напишу большой пост позже.
- Тестирование архитектуры - когда архитектура становится чем-то более приземленным, чем картинки, то появяляется желание ее протестировать. На эту тему можно почитать следующие книги
-- "Building Evolutionary Architecture", в которой был концепт fitness function, но не было интересных примеров (я про нее рассказывал)
-- "Software architecture metrics", где были примеры с архитектурными метриками (я про нее рассказывал)
-- "Continuous Architecture in Practice", где была похожая история с тестами архитектуры (я про нее рассказывал)

#Architecture #Software #SoftwareArchitecture #Management #Processes

System Design. Как построить распределенную систему и пройти собеседование - Владимир Маслов - JPoint (Рубрика #Architecture)

Интересный доклад про System Design Interview от Владимира Маслова. Он сделал прикольный обзор этого типа интервью и рассказал с мемасиками про следущие темы
- Зачем работодатели проводят этот тип интервью и что хотят проверить
- Какие варианты бывают (популярный сервис с нуля, новая фича в известный сервис, архитектура вашего проекта)
- Как важно общаться с интервьюером и уточнять у него, а что именно требуется спроектировать
- Кому обычно дают system design interview
- Как выглядит структура собеседования (по Alex Xu): Functional requiremens -> Non-functional requirements -> High-level design -> Detailed design -> Bottlenecks & tradeoffs
- Какие сигналы хочет увидеть интервьюер (умение понятно выражать мысли, аргументировать свои идеи, опыт проектирования, понимания ограничений спроектированного решения, ...)
- Как прорабатывать каждый из компонентов собеседования в глубину: требования, высокоуровневый дизайн, погружение в отдельные компоненты, масштабирование, надежность, ...
- Как подготовиться к интервью - здесь автор доклада дает много add-hoc способов где что по быстрому подботать, но также приводит и книги, которые стоит изучить
- Как набить опыт и повысить шансы найма через мок интервью
- Как навыки проектирования могут пригодится в реальной жизни инженера, а не только при прохождении интервью

В общем, мне было по фану смотреть это видео - оно сделано забавно и содержит много полезно контента.

P.S.
Когда-то я тоже рассказывал про этот тип интервью и подготовку к нему на ArchDays. Вот запись, расшифровка и рекомендуемые материалы.

#SystemDesign #SoftwareArchitecture #Software #Conference #Architecture #DistributedSystems #SystemDesign #SystemDesignInterview

Как остаться человеком в команде - Илья Якямсев - Trampoline Meetup (Рубрика #Humor )

Последние дни я слишком много говорил про архитектуру и проектирование, поэтому сегодня расскажу про забавный доклад от Ильи Якямсева, которому удается быть одновременно и стендап-комиком и agile коучем. И хоть Илья не пишет код, но в вопросах менедджмента и общения с людьми он собаку съел, поэтому его выступления на ИТ-конференциях смотрятся свежо и интересно. В этом докладе Илья рассказывает про правила коммуникации в IT-командах. За 40 минут получилось раскрыть тезисно
- Почему лучший сотрудник – Лунтик
- Какая основная ошибка новичков
- Почему ваш план больше вашего рабочего места
- Почему так важна иерархия и криги «я / команда / компания / клиент / рынок»
- Почему любое действие – это разговор
- Почему правила должны быть записаны
- Зачем разделять умение говорить и умение говорить по делу
- Как использовать иерархию как инструмент
- Почему, если ты не можешь объяснить, то ты не знаешь
- Что такое T-shape
- Что такое "5 почему" и чем они полезны
- Что делать в любой непонятной ситуации …

P.S.
У Ильи был и друго крутой доклад "Как перестать управлять и начать работать", про который я уже рассказывал раньше

#Humor #Management #Leadership #Software

Раз архитектура — «as Code», почему бы её не покрыть тестами?! - Руслан Сафин - ArchDays 2023 (Рубрика #Architecture )

Интересный и практичный доклад от Руслана Сафина на тему тестирования архитектуры. Основная логика доклада примерно такая
- Описываем архитектуру через plantuml в нотации C4 Model
- Все это сохраняем в репозитории в виде исходного кода (в той же репе, где хранятся конфигурации deployments для k8s)
- Дальше тестируем в пайплайнах соответствие нарисованного в plantuml и того, что лежит в настройках deployments (например, автор показывает как проверяется, что список сервисов в plantuml соответствует тому, что описано в деплойментах для k8s). Это позволяет поддерживать актуальность описанного в plantuml тому, что деплоится в реальности
- А вообще можно проверять тип и параметры связей, параметры деплойментов, соответствие конвенциям. Поэтому описываем базовые принципы нашей архитектуры и начинаем проверять их автоматически.

Руслан приводит следующие примеры принципов, которые они реализовали у себя
1) Использование ACL (anti-corruption layer) паттерна - сервисы, что реализуют ACL помечаем как adapter в plantuml, а дальше проверяем, что связи со внешними системами идут только через такие сервисы
2) Пассивные репозитории - репозитории предоставляют доступы только поверх БД, к ним могут быть входящие связи от сервисов, у них исходящие связи с базой, но вот исходящим связей к другим сервисам быть не может
3) Внешние вызовы должны идти через API Gateway - проверка по url в конфиге k8s и архитектурной диаграмме
4) Операции записи идут только через оркестратор бизнес-процессов (Kamunda)

Дальше можно накручиваать проверки и других принципов, которые вы приняли для себя (и зафиксировали в ADR). Ну и если находятся новые архитектурные проблемы, то можно написать еще новый тест и поправить потом проблему.

В конце доклада Руслан поделился тем, какие реально проблемы были решены
- Была актуализирована архитектура, а также приведена к конвенциям
- Были удалены устаревшие топики, куда только пушили сообщения, но не вычитывали
- Нашлись дубли внешних систем, которые были заведены в разных командах
- Получилось посчитать техдолг по количеству тестов и сервисов

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

P.S.
Странно, что в самом начале доклада Руслан говорит о том, что об идеи о тестировании архитектуры никто не додумался.
Этой теме очень много лет и про нее можно почитать книги, про которые я вспоминал раньше
-- "Building Evolutionary Architecture" (первое издание 2017 года), в которой был концепт fitness function, но не было интересных примеров (я про нее рассказывал)
-- "Software architecture metrics" (2022 год), где были примеры с архитектурными метриками (я про нее рассказывал)
-- "Continuous Architecture in Practice" (2021 год), где была похожая история с тестами архитектуры (я про нее рассказывал)

Ну или почитать whitepaper пятилетней давности "Architecture Anti-Patterns: Automatically Detectable Violations of Design Principles", о котором я рассказывал в прошлом году.

#Architecture #Software #SoftwareArchitecture #Management #Processes

AI для разработки - базовый навык для 2024 - Владислава Куклева - Agile Days 2024 (Рубрика #AI)

Интересный доклад Владислава Куклева, CEO агенства Agentcy, про AI тулинг. Понятно по названию его компании, что финальным аккордом является история про мультиагнетные системы, но до это Владислаав успевает пробежаться по вопросам
- Архитектуры языковых моделей (рассказ про LLM на уровне сложности для обывателей)
- Проблемы LLM (галлюцинации и угадывание), но OpenAI дотюнила модели обучая на размеченных диалогах с пользователем + появился промпт инжиниринг, про который рассказывает автор. Правда, он не упоминает, что по новейшим исследованиям промты для LLM сами LLM пишут лучше, чем люди:)
- Создание при помощи LLMs дизайна, слайдов, диаграмм (mermaid.js)
- Помощники для написания кода: GitHub Copilot, Cursor, Phind
- Цепочки запросов и AI-агенты - как это устроено и почему сейчас это очень перспективное направление
- Мультиагентские системы и как отдельные агенты могут объединятся в команду - подробнее в whitepaper "ChatDev: Communicative Agents for Software Development"

#AI #ML #Software #Processes #Management

Темные данные (Dark Data. Why What We Don’t Know Is Even More Important Than What We Do) - Part II - (Рубрика #Management)

Продолжая рассказ про темные данные, которые я начал в прошлом посте, в этом я хотел рассказать про классы темных данных, которые выделяет Дэвид Хэнд, член Британской академии, президент Королевского статистического общества.

1) Данные, о которых мы знаем, что они отсутствуют - это "известные неизвестные", которые возникают, когда мы знаем, что в данных есть проблемы, скрывающие значения, которые могли быть записаны
2) Данные, о которых мы не знаем, что они отсутствуют - это "неизвестные неизвестные". Тут мы даже не знаем, что нам не хватает каких-то данных. В книге рассказывает про катастрофу Challenger, где принимающим решения не хватало информации о поведении уплотнительных колец при холодной погоде, но они об этом и не знали
3) Выборочные факты - к таким проблемам приводит плохой набор критериев для включения в выборку или ошибочное применение разумных критериев. Также сюда можно отнести p-hacking, который состоит в проведении большого количества статистических тестов, но рассказе только о тех, что были успешны
4) Самоотбор - этот вариант является подтипом предыдущего типа темных данных, а именно выборочных фактов. Он проявляется, когда людям дают самим решать что включать в результаты опроса, а что нет. У отсутствующих данных могут быть системные отличия от тех, что все-таки были внесены.
5) Неизвестный определяющий фактор - тут старая как мир история про то, что корреляция не является причинно-следственной связью. Тут же автор вспоминает про парадокс Симпсона
6) Данные, которые могли бы существовать (контрфактуальные данные) - это данные, которые мы смогли бы увидеть, если бы предприняли какие-то другие действия или наблюдали бы за происходящим при других условиях.
7) Данные, меняющиеся со временем - одни данные могут перестать регистрироваться за пределами периода наблюдений, другие - потому что изменилась природа. В итоге, время может скрывать данные разными путями.
😍 Неверно определяемые данные - определение данных может меняться со временем, чтобы лучше соответствовать своему предмету и назначению. Это может вызывать проблемы в интерпретации временных рядов, так как сам характер данных меняется.
9) Обобщение данных - здесь идет речь о том, когда мы вместо данных сохраняем какие-то их параметры: среднее, медиану, средне-квадратичное отклонение и так далее. Так мы теряем часть информации из данных
10) Ошибки измерения и неопределенность - этот тип данных про погрешность измерений, а также при конвертации данных из разных форматов.
11) Искажение обратной связи и уловки - этот тип данных возникает, когда собранные значения начинают влиять на исходный процесс. Есть примеры с раздуванием оценок и пузырями на рынке акций. Плюс можно вспомнить квантовую физику, где само измерение влияет на состояние системы:)
12) Информационная ассиметрия - этот тип данных возникает, когда у разных участников взаимодействия существуют свои наборы данных. Акерлоф, Спенс и Стиглиц в 2001 году получили Нобелевскую премию по экономике за работы по исследованию рынков с ассиметрией информации (они исследовали рынок подержанных автомобилей "лимонов")
13) Намеренно затемненные данные - здесь речь про предумышленный отбор определенных фактов для скрытия информации и манипуляции фактами для обмана или мошенничества
14) Фальшивые и синтетические данные - такие данные создаются искусственно, например, для мошенничества. Интересно, что сделать качественные синтетические данные сложно, но реально при помощи симуляции процессов.
15) Экстраполяция за пределы ваших данных - данные обычно используются для построения моделей. Эти модели нормально работают в границах тех данных, что мы видели. А вот выходя за границы мы получаем эту проблему с экстраполяцией. Тут опять приводится пример с шаттлом Challenger.

В общем, знать про эти типы темных данных полезно, а еще полезнее почитать книгу и услышать интересные истории факапов с данными из первых рук.

#Management #Data #Math #Statistics

Проводим архитектурное ревью продуктовой фичи - Максима Педченко - Яндекс Go Product Engineering Meetup (Рубрика #Architecture)

Хороший доклад от Максима Педченко из Yandex, в котором он рассказал зачем проводить архитектурное ревью и даже показал на +/- реальном примере как оно выглядит. Забавно, что пример был из домена реферальных программ, а проще говоря как сделать фичу с промокодами, которыми пассажир сможет делиться со своими друзьями. Эта фича обычно направлена на активацию механики сарафанного радио, когда ты customer acquisition cost несешь не на рекламу, а раздаешь его тому, кто рекомендует сервис и тому, кто пользуется рекомендацией и становится новым клиентом. В управлении маркетинговых технологий, что входит в мой юнит есть сервисы на эту тему и они называются BAF (Bring a Friend) и они приносят значимую часть новых клиентов.
Но если возвращаться к самому докладу, то в нем неплохо описана проблематика + приведен алгоритм архревью продуктовой фичи
- Появление идеи проекта
- Проверка гипотезы
- Задача на полноценную разработку (с стандартными НФТ по надежности, безопасности, и так далее)
- Создание RFC/ADR с описанием изменений и дальше ревью по стандартному флоу вопросов. В самом докладе станадартный список был в конце выступления и звучал примерно так
-- Какую продуктовую проблему решает проект
-- Какое место занимает решение в системе
-- Какие фолбеки предусмотрены внутри и снаружи
-- Какая ожидается нагрузка
-- С какими компонентами взаимодействует фича
А в примерах ревью разбирались реальные фичи, поэтому вопросы были в их контексте и они были такими
-- Сколько пользователей (ожидаемая нагрузка)
-- Как масштабироваться (scalability)
-- Можно ли сделать оптимальнее (performance)
-- Что с отказами и 500x (отказоустойчивость)
-- Могут ли быть гонки (что делать для обеспечения консистентности данных при паралелльных/асинхронных запросах)
-- Как сделать удобнее для пользователя (некоторые оптимальные решения с точки зрения прямо ломают UX в corner cases, а значит надо сделать чуть сложнее, но удобнее для пользователя)
-- Идемпотентность вызовов (включая идемпотентность во времени) - если так проектировать, то проще обеспечить надежность системы, так как условные ретраи будут безопасными
- Под конец автор замечает, что ревью не должно длиться бесконечно и когда-то мы должны остановиться и сказать good enough, а потом пойти реализовывать спроектированное решение. Иначе мы можем бесконечно крутиться в цикле paralysis of analysis. Условно говоря, лучшее - это враг хорошего:)
- Для условных экспериментальных фичей такое сложное ревью можно не делать, так как это может быть слишком дорого для эксперимента. Причем дороговизна с одной стороны за счет траты времени инженеров, а с другой стороны за счет замедления lead time изменений. Но если мы делаем уже что-то на долгосрок, то там архревью принесет много пользы на долгом горизонте.
- Для того, чтобы архревью работало надо описать его цели и правила, а также зафиксировать SLA по его проведению (например, сроки в которое оно должно быть пройдено и получен ответ)

#SoftwareArchitecture #Architecture #SystemDesign #Software #SoftwareDevelopment #DistributedSystems