Книжный куб

Новый офис на Белорусской После переезда нашей компании в новый офис у меня теперь новый вид из окна - теперь я вижу крупную железнодорожную станцию:) Этот вид отлично подошел бы Шелдону Куперу из "Теории Большого взрыва", который любил железнодорожный транспорт. Я конечно не Шелдон, но мне тоже иногда нравится постоять в кабинете и подумать, глядя на подъезжающие и отъезжающие поезда. Иногда после этого приходят интересные мысли, которые можно превратить в очередную схему на электронной доске или какой-то осмысленный текст в wiki/jira/почте/tg:)

MBA - Модуль "Стратегирование и самоактуализация/визионерство" - Part 2 - (Рубрика #Management) Продолжая первый пост на тему модуля про стратегию, расскажу что мы еще успели обсудить вчера - После портерианства и ресурсников мы вспомнили Нортона и Каплана и их систему сбаалансированных показателей (balanced scorecard). Эта концепция появилась в 90-х годах и позволила показывать бизнес с четырех сторонах: финансы, сотрудники, клиенты, организация/процессы - Дальше мы продолжили говорить про нарративы, которые позволяют двигать вперед компании. В плане изучения нарративов можно почитать книгу Владимира Проппа "Морфология волшебной сказки", в которой он рассказывает о том, что все волшебные сказки по сути состоят из ограниченного набора паттернов, которые выстраиваются в определенном порядке. Это позволяет сказке доносить свой метафорический смысл до слушателей. Так и нарративы, которые мы создаем позволяют нам направлять стратегию как свою, так и людей в компании:) Кстати, про книгу Проппа я уже рассказывал и рекомендовал ее почитать - После этого мы вспомнили про отношение к успеху в обществе и что оно определяется религией, а христианство (католичество и православие) не очень про успех, а больше про превозмогания и страдание. Но вот протестанство и старообрядчество в этом плане как раз отличаются от мейнстрима в сторону того, что там быть успешным это ок:) - Дальше мы перешли к занятию с прямым стратегированием насчет своих планов на 5 и 10 лет. Суть была в том, чтобы выбрать 2 основных вызова, дальше выбрать 2 крайние альтернативы в этиъ вызовах, а потом построить матрицу 2x2 и нанести на нее расширяющиеся квадраты: меньший для текущего момента, побольше для будущего через 5 лет и самый большой для будущего через 10 лет. А дальше попробовать выбрать то, а где ты хочешь оказаться через 10 лет, потом понять а где ты будешь через 5 лет. А дальше проанализировать как должно выглядеть развитие событий для попадания в цель:) - Интересно, что для того, чтобы так строить стратегию надо понимать, что восприятие успеха зависит от двух факторов: рационального и эмоционального. Про первый помнят многие, когда ставят себе амбициозные цели, а вот про эмоциональную часть забывают. В итоге, можно достичь всех атрибутов успеха, но оказаться глубоко несчастным человеком. То упражнение, что мы делали позволяло пойти не просто от рацион, но и попробовать подключить эмоциональное восприятие. - Прикольно было обсудить как настраиваться на встречи через трио -- Что у меня сейчас с телом, как себя чувствую (базальные ядра)? -- Что у меня сейчас с эмоциями (лимбическая система)? -- Какое у меня намерение сейчас (кортекс)? - Интересно было посмотреть на стратегию со стороны работы терапии и коучинга, а также прошлого и будущего -- Прошлое - с ним работают терапевты -- Будущее - с ним работают коучи -- Настоящее - а тут поляна для религии, когда настоящий момент стараются сделать более полным и растянуть в молитву или медитацию - Финальная часть вчерашнего дня была посвящена самоакутализации и вопросам вида -- Кто я? -- Откуда я? -- Куда мне? -- Зачем все? - И тут пригодился Эфроимсон и его импрессинг, который говорит про информационное воздействие, ранние и сверхранние впечатления детства, которые определяют мотивы и направление деятельности личности на всю жизнь, формируют интересы, шкалу ценностей, и при позитивном влиянии средовых факторов приводят к значительным достижениям в той или иной области. Круто, если удается вспомнить а что это были за воздействия - это позволяет понять почему нас так тянет к определенным видам деятельности. - Ну и в конце мы сели писать эссе про то, как бы мы отмечали свой 70-летний юбилей: где, с кем, в какой обстановке, и так далее. Очень интересное упражнение для того, чтобы подумать над своим будущим. В общем, вчерашний день был очень интересным, а про сегодняшнее продолжение я напишу уже в следующий раз. #Management #Leadership #Processes #Strategy

MBA - Модуль "Стратегирование и самоактуализация/визионерство" - Part 1 - (Рубрика #Management) Вчерашний день целиком я провел на обучении в Сколково, где Андрей Шишаков рассказывал в присущем ему стиле про подходы к созданию стратегии. Интересно, что я уже проходил этот модуль от Андрея в середине 2022 года, когда вопрос определения стратегии стоял довольно остро. В общем про ту программу я уже рассказывал раньше и тогда модуль Андрея был одним из самых интересных. В этом году у нас уже третий запуск корпоративного MBA и предыдущим выпускникам можно было записаться выборочно на посещение интересным модулей и я выбрал заново сходить к Андрею и сравнить, а что поменялось за последние 2 года. Как и тогда теория и практика на модули заставляет рефлексировать относительно стратегии компании и своей личной стратегии. Теперь немного тезисов о том, что мы вчера обсуждали - Начали мы с изучения трех абстрарктных картин, из которых надо было выбрать ту, что нравится и дальше описать возникающую эмоцию и дать название картины - Дальше мы перешли к обсуждению концепции базового доверия к миру Эрика Эриксона и поняли, что есть 2 диаметральных позиции "мир опасен" и "мир безопасен". - Каждый человек находится где-то на этой шкале и это определяется генотипом (генами) и фенотипом (опытом, полученным в ходе развития). Важно понимать свое отношение к миру - Следующей большой темой стали "нарративы" и как они влияют на людей. Ну и начали мы с рассмотрения гештальтов и разбора концепции Фредерика Перлза. Кстати, я вчера сразу заказал основную книгу Фреда "Внутри и снаружи помойного ведра" - Для этого мы вспомнили про устройство мозга: базальные ядра, лимбическая система, кортекс. На пальцах это примерно как мозг ящерицы, коровы и человека. - Собственно, незакрытые гештальты появляются, когда мы не прожили ситуацию до конца, например, подавили эмоции и на уровне кортекса решили, что все ок - В итоге, гештальт по Фреду выглядит так 1) потребность, 2) пред-контакт, 3) контакт, 4) пост-контакт - Дальше мы ушли обсуждать ценностное предложение, которое обычно мы создаем как организация. Здесь важно подумать про всех ключевых стейкхолдеров: акционеры, клиенты, сотрудники, общество. Если про кого-то забыть, то наша компания потенциально уязвима для конкурентов. Похожее ценностное предложение можно составить и на личном уровне, где надо ответить на вопросы про пользу для: ваших руководителей, сотрудников под вами, горизонтальных peers и дальше для семьи:) А мне особенно понравилась отсылка к взаимоотношениям в семье и вопросу жене вида "Дорогая, а какой у тебя со мной клиентский путь":) - Дальше мы ушли в обсуждение создания стратегии сверху-вниз (портерианство) и снизу-вверх (ресурсники). - Портерианство - это подход к стратегии от Майкла Портера, где он строит матрицу 2x2 и расссматривает размер рынка (узкий/широкий) и тип конкурентного преимущества (преимущество в затратах/преимущество в продукте). На выходе у нас получается 4 квадратика и три варианта стратегии: -- дифференциация (лидерство в продукте) - это создание уникального продукта в своей отрасли -- лидерство в издержках (ценовое лидерство) - это получение самого низкого уровня расходов (минимизация затрат на производство) -- специализация (лидерство в нише) - это концентрация всех усилий фирмы на ограниченной группе покупателей - Портерианство подходит для тех, у кого мир безопасен. Они могут планировать свою стратегию сверху-вниз и верить в то, что все пойдет по плану:) В больших корпорациях часто именно так подходят к формированию стратегии - Ресурсный подход к построению стратегии придумал Джей Барни. Суть в том, что тут мы идем снизу от ресурсов и компетенций, к конкурентного преимуществу, привлекательной отрасли, а дальше построению стратегии и внедрению. Интересно, что этот подход привлекателен для людей, у которых мир опасен, так как таким образом они избегают конкуренции алого океана и могут найти свою стратегию голубого океана. Продолжение в следующем посте. #Management #Leadership #Processes #Strategy

Бизнес-линии, сервис-линии и платформы @ T-Bank - Part I - (Рубрика #Management) Достаточно давно я не писал про менеджмент и решил исправиться, написав про структуру Т-Банк:) Наша компания устроена федеративно: разные подразаделения работают достаточно независимо для достижения общих целей компании. Большая часть подразделений относится к одному из трех типов: бизнес-линии, сервис-линии, платформы, которые сильно отличаются друг от друга. А для руководителя важно понимать в каком типе подразделения он работает. 1) Бизнес-линии - характерной особенностью такого подразделения является продукт, который предоставляется внешним клиентам (продукт может быть разных типов: b2c, b2b, b2g, b2b2c, ...). У продукта обычно есть план развития и продуктовые метрики, а также PnL (profit and losses). Такое подразделение похоже на мини-компанию внутри большой компании. Примерами бизнес-линий могут быть: банк физлиц и отдельные продукты внутри (дебетовые, кредитные, ...), банк для юрлиц и отдельные продукты внутри (РКО, бухгалтерия, ...), инвестиции, страховая и так далее. В нашей схеме у таких бизнес-линий есть собственные бизнесовые руководители (CPO) и их ребята в виде продактов и бизнес-аналитиков, а также собственные технические руководители (CTO) и вся структура IT команд под ними. В идеальном случае бизнес и IT выровнены по целям и используют какой-то фреймворк для каскадирования целепологания по всем уровням. 2) Сервис-линии - такие подразделения оказывают некоторый сервис, который необходим бизнес-линиям для эффективной работы. Такой сервис часто проще строить централизованно и получать эфффект экономии на масштабе. Также очень важно, что в сервис-линиях часто концентрируется некоторый важный ресурс, который надо уметь использовать совместно и не допускать эффекта трагедии общих ресурсов (tragedy of the commons). Поэтому снаружи сервис-линия для бизнес-линий выглядит как некоторый интерфейс, куда они приходят за сервисом, который предоставляется с определенным уровнем качества. Внутри же сервис-линия часто состоит из какого-то набора специалистов, которые в рамках операционной деятельности оказывают сервис. Деятельность этих сециалистов автоматизируется командой разработки этой сервис-линии и на выходе получается большое количество инструментария, который позволяет оказывать сервис эффективнее. Для сервис линии важно уметь считать косты, которые аллоцируются на бизнес-линии, которым оказывается этот сервис. А вот profit часть здесь считается сложнее, но обычно есть матмодельки, которые показывают как его можно оценить:) Например, для онлайн-привлечения затратами являются траты на ФОТ сотрудников, рекламу, а прибыль считают из моделей NPV продукта, куда привлекают пользователей или LTV привлеченного клиента (этот подход посложнее NPV). 3) Платформы - такие подразделения создают продукты для внутренних пользователей. Характерной особенностью таких продуктов является возможность использования их в формате self-service. Самым ярким представителем таких платформ является IDP (internal developer platform), которая направлена на инженеров внутри компании, которые создают цифровые продукты. На тему IDP можно почитать whitepaper от CNCF и мой разбор в трех частях: 1, 2 и 3. Платформа бывает представлена в виде коллекции возможностей, что определены и представлены в соотоветствии с потребностями пользователей платформы. Здесь важно, что все эти возможности интегрированы вместе и предоставляют возможность выполнять типичные сценарии пользователей платформы. Помимо IDP бывают и более высокоуровневые платформы, которые предоставляют возможность использовать платформу в формате as a Service или развернуть для себя какую-то часть сервисов платформы, если коммунальная версия почему-то не подходит. Интересно, что большая часть моей деятельности в Т-Банке связана с автоматизацией сервис-линий, а иногда и переход от сервис-линии к платформе. Дальше я поделюсь своими примерами из практики и покажу как тип подразделения диктует некоторую стратегию развития и цели для команд:) #Management #Leadership #Software #Processes

Выезд на биостанцию Чашниково (Рубрика #Kids) Был в эти выходные с семьей на биостанции в Подмосковье на экскурсии, что организовывали ребята из канала "Путь открытий". Собственно Настя, моя жена, нашла эту экскурсию и заинтересовала всех наших детей колонией голых землекопов, которые водятся на этой биостанции, бывшей закрытой лаборатории биофака МГУ:) Мы приехали туда за полчаса до начала экскурсии и успели погулять по территории, а потом нас встретил заведующий, физиолог животных Рустам Бердиев и начал свой рассказ - Про медведицу Машу, которая с 2007 года живет при биостанции, так как в те времена на биостанции реабилитировали диких животных (но это уже в прошлом) - Про выращивание личинок, жуков, саранчи на продажу как корм другим животным - Про лабораторных мышей и крыс, которых там выращивает на эксперименты для биофака МГУ - Про колонию голых землекопов, которая и является звездой программы и расположена на втором этаже и обычно находится в темноте, так как землекопы похожи на кротов в своей любви к пребыванию под землей В общем, хороший получился выезд ... и острые впечатления от вида таких насекомых и животных, которые пугают Настю:))) #ForKids #ForParents

Архитектура приложения и ошибки проектирования - Рустам Ахметов - Joker 2022 (Рубрика #Architecure) Интересный доклад от Рустама Ахметова на тему архитектуры того, как можно организовывать свой код приложений. Автор подошел к снаряду основательно и сделал обзор всех распространенных вариантов архитектуры, делая отсылки к оригинальным статьям, где про них в первый раз вспоминали. Собственно автор сначала говорит о том, что хорошая архитектура и структура кода помогает нам бороться со сложностью. А это значит, что новички на проекте, открыв IDE, легко смогуть понять как он устроен и как наносить пользу без долгого изучения, а как же тут принято раскладывать код по папкам:) Основные мысли доклада следующие - Horizontal Design - это привычная всем слоенная архитектура. Так писали код уже давно и там было обычно деление на presentation tier, app tier, database tier. Этот подход был доминирующим долгое время, он доминирует и сейчас, но постепенно он вобрал в себя плюсы из других подходов. Кстати, иногда tiers было больше трех:) Например, в 2003 году появилась книга "Domain-Driven Design" Рика Эванса и начал появляться еще отдельный doaimn layer - Vertical design - этот подход появился еще в девяностые годы и нужен был для масштабирования команды, чтобы отдельные подкоманды могли автономно работать. В итоге, внутри монолитного приложения появлялись отдельные изолированные модули внутри приложения (модули делились по доменам или функциям). Это был прообраз микросервисов. Кстати, сейчас популярна становится vertical slice architecture, про которую я уже как-то рассказывал при разборе выступления "Designing for change with Vertical Slice Architecture - Chris Sainty" с NDC. Этот подход хорош для небольших приложений - Hexagonal - в 2005 году эту архитектуру предложил Alistair Cockburn. Суть была в том, чтобы внешние абстракции хорошо уметь в отдельных модулях. Здесь новинка в том, чтобы изолировать бизнес-логику от внешних интеграциях. Но как это организовать на уровне кода Алистер не показал. - Onion - луковичная архитектура была описана в 2008 году Jeffrey Palermo, который взял примерно ту же идею, что и hexagonal architecture, но показал как это сделать на уровне приложения и сделать не круговой, а разложить по слоям: отдельные папки для взаимодействий, отдельная папка для бизнес-логики, отдельная папка для объектной модели данных - Clean Architecture - предложил в 2012 Uncle Bob (Robert Martin), который попытался объединить hexagonal и onion и отделить бизнес-логику от внешних зависимостей, куда вошли и фреймворки. В общем, идея стала популярной, но догматизм Uncle Bob мешает воспринимать его серьезно. Дальше автор рассмотрел современную hexagonal architecture from Netflix, которая с точки зрения автора похожа скорее на современную слоенную архитектуру:) В жизни автор предлагает этот шестиугольник от Netflix превратить в слои примерно так: input -> adapter -> app core (service layer) -> adapter -> output. Дальше автор показывает демки того, как все виды архитектур выглядят в коде и какие они имеют преимущества и недостатки. Все выглядит достаточно наглядно, поэтому рекомендую демку к просмотру. #Architecture #SoftwareArchitecture #SystemDesign #Engineering

Генерация архитектурных схем и метаданных - Кирилл Ветчинкин - E-community 2023 (Рубрика #Architecture) Интересный доклад от Кирилла, в котором он продолжает тему про архитектурный репозиторий, которую он поднял на ArchDays 2022. В этом продолжении идет речь о том, как сделать архитектурные диаграммы актуальными и основные мысли доклада следующие - Кирилл начинает с постановки проблемы неактуальных схем и выделяет 4 момента: -- По неактуальной схеме невозможно принимать решения -- К неактуальной схеме низкое доверие у всех участников процесса разработки -- Сложно анализировать состояние системы тем, кому это нужно делать (аудиторы, участники процесса разработки) -- Такие схемы не помогают и во время operations - техподдержка и SRE не могут их эффективно использовать - Для решения проблемы заводим архитектурный репозиторий, где с помощью C4 Model и подходов из DDD описываем свои сервисы (компоненты, из которых состоит наша система). Причем список компонентов должен вестись централизованно, чтобы мы могли их однозначно идентифицировать и переиспользовать внутри наших схем - Для того, чтобы архитектурный репозиторий актуализировался автоматически нам требуется завязаться на наши конфигурационные данные о наших сервисах: -- Описание самого сервиса - в Sber Market это app.toml (конфигурация в формате TOML). Кстати, данные из этого файла используются для пополнения каталога сервисов, что используется для описания в архрепо -- Конфигурацию и зависимости сервиса - этот файл values.yaml используется для деплоя сервисов в production, поэтому он содержит актуальные параметры или сервис просто не будет работать как задумывалось в проде. Ну а для архитектуры можно использовать файлы из разных сервисов можно построить граф зависимостей для сервисов. -- Описание базы данных - в Sber Market это structure.sql, который содержит схему базы данных и может использоваться для составления ER-диаграмм. В итоге, построение архитектурных диаграмм выглядит примерно так: - Чтение файлов app.toml, values.yaml, structure.sql - Преобразование данных из файлов к объектной модели - Построение графа взаимосвязей для разных сервисов - Рендеринг схем для всех сервисов - внутри сервиса есть ER-диаграммы, а также container диаграммы, на которые подтягиваются как сервисы в которые мы стучимся, так и те, что ходят к нам (они подтягиваются из values.yaml потребителей) - Сохранение схемы - Отображение схемы В общем и целом, именно такой подход мне кажется правильным движением в сторону архитектуры как код: - Использование стандартного тулинга для документации архитектуры - Сама информация о сервисах и их взаимосвязах не заполняется руками, а тянется из системы, что является источником истины и определяет как наши сервисы задеплоены в реальности - Поверх накручиваются тесты для контроля архитектурной целостности, что гоняются в пайплайнах (fitness functions из книги "Building evolutionary architecture") P.S. На тему управления архитектурой уже было недавно несколько постов, которые тоже интересно почитать - Архитектура как код - Роман Пионтик - ArchDays 2022 - Архитектурный репозиторий на базе GitLab и C4 Model для большой компании - Кирилл Ветчинкин - ArchDays 2022 - Материалы к моему докладу "Architecture at T-Bank: how we design our solutions" - Раз архитектура — «as Code», почему бы её не покрыть тестами?! - Проводим архитектурное ревью продуктовой фичи - Опыт использования подхода «Архитектура как код» в ГК Самолет - Роман Пионтик, Валентин Козлов - ArchDays 2023 #SoftwareArchitecture #Architecture #SystemDesign #Software #SoftwareDevelopment #DistributedSystems

dbt — ядро современной платформы данных - Евгений Ермаков - SmartData 2023 (Рубрика #Architecture) Интересный доклад Евгения Ермакова про построение дата платформы в toloka.ai, которая, получив независимость от Yandex, вынуждена была переезжать на новые технологии. В итоге, выбор пал на databricks, dbt, airflow и tableau. Автор рассказывает о том, почему был сделан такой выбор и как в итоге это все работает. Основные моменты следующие: - Сама toloka - это система для краудсорсинга, куда заказчики приходят с задачками навроде разметить данные, а с другой стороны на платформе зарегестрированы люди, которые их выполняют - Архитектура базируются на трех китах: -- Data lakehouse -- Процессы в соответствии с подходом data mesh -- Современный технологический стек - До переезда на новые технологии ребята использовали много своего, часть из которого уже есть в opensource: YTsaurus, datalens - После переезда выбрали новые технологии и dbt стал ядром системы, закрывая функциональность: data quality, data catalog/ data observability, batch processing (вместе со spark), orchestration (вместе с airflow) - Изначально dbt (data building tool) нужен был в качестве удобного инструмента для transformation шага в ETL/ELT - Интересно, что в концепции компании dbt есть мнение и относительно ролей, где помимо стандартных data engineers и data analysts появляется еще analytics engineer. В итоге, data engineers - это те, кто делают так, чтобы data платформа работала эффективно, data analysts ищут инсайты в данных и помогают их эффективно использовать, а вот analytics engineers - это ребята, что-то среднее между другими двумя + хорошо укладывается в концепцию data mesh, где нет централизованной дата-команды, а есть дата-команды по доменам - Основой dbt-проекта является dbt model. Модель состоит из файла с описанием логики (.sql или .py файл) и файла с описанием конфигурации. В .sql файле есть запрос на формирование объекта, другие модели используются через ref() или source() + используется jinja шаблонизация. В .py файле возвращаем dataframe с рассчитанными данными, есть доступ ко всем возможностям pyspark + другие модели тоже используются через ref() или source() - Материализацию запроса dbt берет на себя и есть разные стратегии, из которых самая интересная incremental - Настройки хранятся в dbt_project.yaml и profiles.yaml - dbt поддерживает большое количество баз данных, например, postgres, mysql, clickhouse, ... - dbt - это консольная утилита, например, при запуске dbt build происходит сборка всех зависимостей между моделями, а также компиляция python/sql запросов и запись в manifest.json - Команда dbt run запускает скомпилированные запросы, где запуск можно настроить по разному, но интересно запускать по графу - Кстати, dbt умеет генерировать документацию командой dbt docs generate и дальше можно посмотреть на lineage данных - Также мы можем писать тесты в том же месте, где мы описываем модели, а дальше запускать их при помощи dbt tests. Например, можем проверять unique или not null на поле, а также если хотим relations между моделями - У dbt есть еще много возможностей, но про них стоит почитать самостоятельно:) - Дальше автор рассказывает как сделать data mesh на уровне dbt + airflow. Автор рассматривает варианты вида: -- Монолитный - один dbt проект на всю компанию -- Микросервисный - отдельные dbt проекты на каждый домен -- Layered - отдельные dbt проекты по уровням -- Смешанный - анархия, где проекты создаются кто как хочет Выбрали монолитный подход и получили аля монорепо под data mesh, в котором живут все. Обусловлено это было тем, что при микросервисном подходе ломались все связки между моделями (до 1.6 не могли называть модели одинаково в разных проектах + была проблема с импортом друг друга, так как это приводило к циклическим зависимостям). Из интересного еще сделали конвертор графа исполнения dbt в airflow формат, чтобы запускать DAG из airflow. В итоге, ребята реализовали свой подход к data mesh при помощи open source инструмнетов и вся схема выглядит достаточно стройно. #Data #Datamesh #DWH #Processes #Management

Опыт использования подхода «Архитектура как код» в ГК Самолет - Роман Пионтик, Валентин Козлов - ArchDays 2023 (Рубрика #Architecture) Интересный доклад про описание архитектуры от Романа и Валентина на последнем ArchDays. Суть доклада в том, чтобы показать как это документирование устроено в строительной компании "Самолет", где и так многое завязано на информационном моделировании BIM (Building Information Model) для отображения архитектуры зданий, который построили и строит компания "Самолет". Компания решила пойти дальше и стать поистине девелоперской компанией и, в итоге, получилась гетерогенная архитектура предприятия, связанная с автономностью команд, отсутствием единого понимания стратегической цели. Потом в компании появились архитекторы, которые занялись решением этих проблем с помощью документации архитектуры и кажется, что у них это получилось достаточно неплохо. Если говорить про сам рассказ из доклада, то - Сначала был попытка использовать plantuml для построения диаграмм - Потом была попытка использовать structurizr для того же - Потом все пришло к использованию Dochub, про который говорится, что это уже не просто картинки и документация, а целый "цифровой двойник" - Дальше идет рассказ о том, что умеет Dochub: расширяемая метамодель, визуализации (plantuml), подключаемые плагины - Потом заходит речь про внедрение инструмента и описание первых двух уровней из C4 Model (system и container уровней) - В общем, в "Самолете" инструмент прижился и его используют для управления архитектурой и дальше есть планы от этого инструмента двигаться в сторону кода и инфры - условно выдавать доступы или ресурсы только если все качественно задокументированно в Dochub. Кстати, это хорошая мотивация для команд поддерживать эту документацию в актуальном состоянии, особенно если это получится автоматизировать:) Вторая половина доклада посвящена рассказу о планах расширения инструмента и про архитектора 2.0, о котором есть отдельная философская статья на Хабр, основная мысль которой в том, что - Архитектор 2.0 - это архитектура человека и машиночитаемые данные, в отличие от архитектора 1.0, который использует визуальные схемы и диаграммы. - Архитектор 2.0 - это использование языка производства, а не придумывание собственного языка - Архитектор 2.0 должен уметь влиять на развитие своего инструмента и уметь дорабатывать его для удовлетворения потребностей бизнеса и разработчиков. - Архитектор 2.0 также должен уметь создавать новые фреймворки для накопления и развития архитектурных практик. И этому архитектору 2.0 поможет фреймворк SEAF (Sber Enterprise Architecture Framework), который Роман кратко презентует в последние 10 минут этого выступления. Про него я расскажу в отдельном посте, который будет по мотивам другого выступления Романа, где он почти час рассказывает только про SEAF. P.S. На тему управления архитектурой уже было недавно несколько постов, которые тоже интересно почитать - Архитектура как код - Роман Пионтик - ArchDays 2022 - Архитектурный репозиторий на базе GitLab и C4 Model для большой компании - Кирилл Ветчинкин - ArchDays 2022 - Материалы к моему докладу "Architecture at T-Bank: how we design our solutions" - Раз архитектура — «as Code», почему бы её не покрыть тестами?! - Проводим архитектурное ревью продуктовой фичи #Architecture #Software #SoftwareArchitecture #Management #Processes

Аналитик-исследователь в области статистики и A/B-тестирования в Т-Банк Последнее время я достаточно много рассказываю про работу с данными, проведением экспериментов и построение a/b платформы. И это все не просто так - мы создаем a/b платформу на всю компании, а также у нас есть лаборатория прикладной статистики, которой руководит Роман Филев (@simbaizdolgopi). Сейчас Рома ищет в свою лабораторию аналитиков для того, чтобы разрабатывать и внедрять SOTA методы проверки гипотез, пионерить лучшие практики и катить их через единую платформу принятия решений (А/Б-платформа, платформа продуктовой аналитики и тд). А еще эти ребята часто десантируются в продуктовые команды для помощи в сложных ситуациях в этой области. В обязанности аналитиков будут входить - Исследование и применение современных математических и статистических методов в А/В-тестировании - Коммуникация с бизнес-подразделениями для точной формализации бизнес-задач - Разработка и совершенствование методов А/В-тестирования - Распространение лучших практик A/B-тестирования через участие в образовательных проектах и выступления на профильных конференциях Для успешного выполнения обязанностей нужны следующие теоретические знания - Теория вероятностей и статистика: - Прочное владение базовыми курсами - Вдумчивое понимание проверки статистических гипотез, включая ошибки I и II рода и интерпретацию p-value - Опыт работы с основными статистическими критериями, в том числе Z/T/U-тестами и критериями Колмогорова-Смирнова, Андерсона-Дарлинга - Знание предельных теорем, включая Закон больших чисел (ЗБЧ), Центральную предельную теорему (ЦПТ) и теорему Донскера-Прохорова - A/B-тестирование: - Глубокое понимание статистической механики A/B-тестирования, с умением связывать тесты с проверкой гипотез - Навыки определения размеров выборки, работы с множественной проверкой гипотез и ratio-метриками - Осведомленность о современных подходах ускорения A/B-тестирования, таких как снижение дисперсии и последовательная проверка гипотез - Теория метрик: - Понимание различных видов метрик и принципов их выбора - Знакомство с подходами к созданию иерархии метрик Минимально с точки зрения практики нужно - Иметь уровень middle аналитика в SQL и Python - иметь опыт работы с click, gp, superset, а также с инструментами визуализации и системами управления проектами (Jira/Confluence) Если вам понравилась вакансия, то пишите в личку Роме (@simbaizdolgopi) и уточняйте детали. P.S. Кстати, я уже рассказывал про книги на тему статистики, которые были бы полезны такому инженеру - Как лгать при помощи статистики (How to Lie with Statistics) - на пальцах объясняется как врут с помощью статистики, а отсюда становится ясна мотивация создания системы подведения итогов экспериментов - Understanding Statistics and Experimental Design. How to Not Lie With Statistics (Статистика и планирование эксперимента для непосвященных) - в этой книге рассказывается про дизайн экспериментов и математику, что стоит за ними - Доверительное a/b тестирование (Trustworthy Online Controlled Experiments) - а эта книга позволяет еще и понять как сделать платформу для проведения экспериментов на уровне всей компании - Темные данные (Dark Data. Why What We Don’t Know Is Even More Important Than What We Do) - книга про то, как можно облажаться с данными и что с этим можно сделать #Vacancy #Statistics #Data #Analytics

Проводим архитектурное ревью продуктовой фичи - Максима Педченко - Яндекс Go Product Engineering Meetup Хороший доклад от Максима Педченко из 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

Темные данные (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

Спектакль "Nirvana" - Театр Модерн (Рубрика #Culture) Был вчера со старшим сыном на этом представлении про культового музыканта Курта Кобейна. Спектакль начинается с рассказа про школьные годы музыканта, где уже видно как ему тесно в родном Абердине и как он решает его покинуть (в постановке его сопровождает Драг, олицетворяющий расширяющие сознания вещества). Дальше Курт встречается с Кортни Лав, сочиняет музыку и записывает альбомы, а также вовсю употребляет вещества. Дальше уровень сюррелизма начинает нарастать и мы видим странные декорации, а Курта продолжают мучать его демоны и только наркотики помогают ему продолжать творить. У Курта и Кортни появляется дочь Фрэнсис Бин Кобейн, которая является отрадой Курта. Но наркотики не отпускают Курта и он заканчивает свой земной путь выстрелом в голову. P.S. Спектакль длится всего 2 часа и за это время мы знакомимся с жизнью творца и видим как из бунтаря он превращается в тень самого себя. И все это происходит под культовую музыку Nirvana (Smells Like Teen Spirit, Come As You Are, Heart-Shaped Box и других) #Theater #SelfDevelopment #Culture

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

Раз архитектура — «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

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

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

Закончил выступать и пошел в бар, где очень примечательная коктельная карта, а через часик уже в аэропорт и обратно в Москву. В общем, поездка в Питер удалась:)

Материалы к докладу "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

Архитектура как код - Роман Пионтик - 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