Книжный куб

Калининград (Кёнигсбе́рг) Вчера вечером я прилетел в Калининград. Это мое первое посещение этого города, поэтому сразу после заселения в Crystal House я решил прогуляться. Рядом с отелем есть красивый парк с прудом и дорожками для прогулок и велосипедов - очень приятное место. Чуть севернее парка расположен Верхний пруд с красивыми видами и катамаранами для тех, кто хочет увидеть виды с середины пруда:) На берегу нашлось кафе-гриль "Огонек", где готовят отличное мясо и рыбу. Собственно, это кафе и стало точкой назначения, где удалось подкрепиться и двинуться обратно. Я здесь буду еще несколько дней и посещу ключевые достопримечательности, но уже могу сказать, что город мне пока нравится:) #Travel

MBA - Модуль "Стратегирование и самоактуализация/визионерство" - Part 3 - (Рубрика #Management) Продолжу рассказ про модуль "стратегии и лидерства", который начал в первых двух постах: 1 и 2. Во второй день обучения мы рассмотрели много интересных моментов и я даже купил себе несколько книг, что проскакивали в обсуждении. Вот основные темы, что мы обсудили - Концепция многоуровнего управления с такими уровнями: геополитический, суверенный/социальный, корпоративный, личный. Влиять можно на тот уровень, на котором ты оперируешь, а к уровням выше можно просто подготовиться (если уметь работать с информацией и рисками) - The Global Risk Report 2024 - интересный 100+ страничный документ от World Economic Forum, который собран с привлечением тысяч крутых специалистов и который рассматривает риски на горизонте этого года, 2-х лет и 10 лет. Документ использует подход PESTLE анализа, в котором рассматриваются разные факторы: political, economic, social, technological, legal, environments. Потом я отдельно сделаю пост про этот интересный документ - Geopolitical fragmentation and trade - интересная научная статья 2023 года на тему разделения мира с учетом текущих геополитических течений. В статье есть интересные предсказания - "Следующие 100 лет: Прогноз событий XXI века" - интересная книга 2009 года политолога Джорджа Фридмана, который создал компанию Stratfor (Strategic Forecasting). Эту книгу мне уже привезли в бумаге и я даже начал ее читать. Она определенно интересно изложена и показывает модель размышлений о геополитических причинах происходящих событий. Сами предсказания частично исполнились, а частично остались версиями для альтеративных вселенных (подробнее в многомировой интерпретации или интерпретации Эверетта) - Проблематика разрыва между поколениями в США (и не только) - бумеры до сих пор определяют потребление в США, а более молодые поколения находятся в положении, что не могут позволить себе того, что было доступно их дедушкам бесплатно (образование, медицина, ...) 🙂 - Волны Кондратьева - гипотеза о цикличности экономических индикаторов, которая говорит о том, что в развитии экономики есть фазы долгосрочных колебаний порядка 50 лет. Так как четких правил, определяющих параметры этих волн нет, то эта гипотеза не соответствует критерию фальсифицируемости Карла Поппера, так что она не тянет на научную, а скорее на религиозную:) - ESG повестка - с нами надолго:) Можно на эту тему посмотреть ролик от Apple про Mother Nature - Население Земли стареет и поэтому на повестке "серебрянная экономика" - можно почитать на эту тему материалы от ООН с неймингом "life expectancy index" Вторая половина дня была посвящена личному стратегированию и анализу светлого образа руководителя в рамках концепции Глобального Юга и Глобального Севера. Определенно, это было интересно, но результаты этих размышлений о своем направлении развития каждый оставил при себе:) В итоге, модуль про стратегию был действительно интересным. Интересно, что я проходил предыдущую версию этого тренинга 2 года назад, весной 2022 года, но тогда стратегические вещи заходили сложно, а теперь они воспринимались как надо:) #Management #Leadership #Processes #Strategy

Why Everybody Hates Agile • Jesper Boeg • GOTO 2023 (Рубрика #Management) Интересный доклад от Jesper Boeg, Agile/Lean Coach, который рассказывает почему все не любят Agile и agile коучей:) Слайды этой забавной презентации доступны здесь, а основные мысли, что я вынес для себя изложены ниже - Agile has been reduced to a set of practices - вместо agile принципов теперь принято оперировать набором практик, которые и должны принести успех. Например, это циклы discovery и delivery, спринты и burndown charts, double diamonds от продактов, agile release trains, system и solution архитектуры и так далее. Дальше приверженцы разных практик воют друг с другом в религиозных войнах, упуская значимость контекста, который и придавал смысл тем практикам, которые к нему подходят - Agile has become a monster - догматичный подход к правильному Agile (Scrum, Less, SAFe, Kanban, Scrum&Scale, Nexus, ...) извратил концепцию и мы получили монстра, но нет подтверждений того, что один из подходов всегда лучше всех остальных - Excuses are abundant - но люди пытаются объяснить выбор канонического подхода на всю организацию по разному (если что эти объяснения - это хрень на постном масле): -- Если процессы разные, то людям будет сложно при переходе между командами -- Это "проверенный" метод -- Если делать все "по книге", то мы точно будем вынуждены решать реальные проблемы -- Если мы не будем делать все одинаково, то мы не сможем делиться найденными идеями -- Нам надо четко зафиксировать роли и ответственность на всех уровнях - We should not be surprised - мы не должны удивляться тому, что так происходит. Мир вокруг сложен, а мозг ленив и старается по минимуму задействовать вторую систему (подробнее рекомендую прочитать в книге Канемана "Thniking, Fast and Slow", про которую я вспоминал раньше) - Agile gone wrong: Theory vs reality - тут автор приводит подборку тезисов, которые на практике отличаются от того, что говорит agile теория -- Sprint commitment will ensure effectiveness - цель спринта иногда недостижима -- ONLY Working quality software to scale counts - иногда надо сделать некачественное г**но, но быстро получить деньжат -- Product Discovery on everything - здесь автор вспоминает Cynefin фреймворк и говорит, что для obvious и complicated не особо нужно discovery -- Scrum Master as a full time role - но не всегда это так:) -- и еще куча примеров:) - Summary & advice - заканчивает автор на высокой ноте, вспомнив про основные принципы, которые важнее набора практик, которых он старается придерживаться

1. A purpose for each team 2. An outside-in organizational structure 3. Teams are empowered, self-organizing and relatively stable 4. Small batches 5. Early and continuous market, customer and end-user validation 6. End-to-end pull system 7. Operational and technical excellence 8. Modern leadership

Но также упомянул, что - Структура бизнеса важна - Стартовый набор практик важен, но его стоит использовать с умом и сразу объяснять почему та или иная практика полезна в текущем контексте - И если приходится заниматься change management, то не стоит менять все сразу:) #Management #Processes #Leadership #Agile #Philosophy

Спектакль "Мойдодыр" в театре "Домик Фанни Белл" (Рубрика #Culture) Были сегодня с женой и младшим сыном на представлении по мотивам Мойдодыра Чуковского в этом небольшом театре, что расположен в саду Баумана. Этот театр дает камерные представления для маленьких зрителей, которые сидят на подушках прямо у сцены, а родители сидят на стульчиках сзади. Артисты, которых обычно не больше трех, выступают прямо перед детишками и активно взаимодействуют с ними: задают вопросы куда побежал немытый трубочист или даже помогают его умывать при помощи только что выданных губок. Параллельно самой истории детей учат правильно гигиене, а точнее как правильно умываться, а также рассказывают как делать разминку как крокодил, что неряху чуть не проглотил. В общем, если изначально я не мог понять как растянуть этот стих на целых полчаса, то побывав на представлении я все понял:) Рекомендую этот театр для тех, у кого есть маленькие дети. P.S. Я уже рассказывал про этот театр "Домик Фанни Белл", когда говорил про спектакль "Щелкунчик", на котором мы были с детишками перед Новым Годом. #Theater #ForKids #ForParents #Culture

Вовка в Тридевятом царстве. Сказки (Рубрика #Kids) Недавно с женой купили младшему сыну забавную книгу сказок из нашего детства. Сказки в книге адаптированы под формат комиксов и туда входят три сказки разных трех авторов, а иллюстрации сделал художник А. Савченко - «Вовка в Тридевятом царстве» В. Коростылёва - мультик 1965 года, в котором советский школьник попадает в сказочную страну лентяем, который не желает работать. Путешествую по сказке на его пути попадаются Двое из ларца, одинаковых с лица, которые за него все делают (даже едят), правда, делают это не очень хорошо. Именно это его заставляет взять работу в свои руки и начать работать руками по книге "Сделай сам". В общем, это хорошая мотивирующая сказка. - «Петя и Красная Шапочка» В. Сутеева - мультик 1958 года, в котром советский школьник попадает в сказку про Красную шапочку. В этой альтернативной версии сказки Петя как пионер пытается спасти бабушку и внучку и предупреждает их о грозящей беде. Прячет бабушку, подменяет красную шапочку и сам бьется с волком до прихода охотников. В общем, волк оказывается повержен, а все мирные жители цели, а Петя всех спас:) - «Коза-дереза» А. Тимофеевского - мультик по мотивам народной сказке про козу-манипуляторшу:) Купил дед козу на базаре, привел домой, а она дальше начала настраивать деда и бабку против других зверей: петуха и зайца, устраивая подставы. Но потом все вскрылось и дерезу вывели на чистую воду. В общем, сказки сами по себе крутые, а книжка их упаковывает в тот формат, который удобно читать детям перед сном - по-крайней мере, наш самый маленький часто выбирает почитать перед сном "Вовку". Так что я могу рекомендовать эту книгу родителям:) #ForKids #ForParents #Tales

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