Примерно так выглядит работа в новогодние праздники))

Перефразируя классиков, за каждым архитектурным решением стоит кот, который понимает контекст лучше, чем заинтересованные стороны

Официальный рабочий год стартовал.

По инерции с прошлого года еще много текучки, но и много «стратегических» планов на активности, в том числе - обучающие. В конце января планируется вебинар по архитектурным решениям, в феврале - очередная итерация воркшопа на ту же тему, обновленного)) буду шарить инфу по возможности💪

За «выходные» осилил одну статейку на проф темы - про место архитектора в эпоху ИИ (естессно, ну о чем еще-то?)

Авторы рассматривают три опции участия архитектора в процессе проектирования, прокаченном ИИ - Architect in the Loop (AITL), Architect on the Loop (AOTL) и Architect out of the Loop (AOOTL) - как обычно, непереводимые англоязычные обороты для буллщит баззвордов.

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

AOTL - «надзорная» модель, где архитектор делегирует задачи по принятию арх решений ИИ, а сам определяет для него границы и «governance». Тут архитектор по-прежнему всё ещё часть процесса проектирования, изучает область проблемы с помощью ИИ и строит для него границы.

Тогда как в AOOTL роль архитектора уже меняется полностью. ИИ делает всю «стандартную» арх работу по изучению области проблемы, формированию опций, дизайну и принятию решений, которую потребляют другие члены команды. Архитектор определяет правила для ИИ, гарантирует безопасность его деятельности и несет ответственность за последствия его (ИИ) действия.

Идея тут, видимо, в том, что первая модель - самоочевидная и наиболее вероятная, с минимальным выхлопом, а последняя - самая эффективная, но небезопасная. Средняя - серединка на половинку. Я, честно говоря, в практической плоскости вторую модель понимаю слегка, а третью не понимаю совсем. То есть на уровне концепций и абстракций это всё звучит красиво, но какие практические последствия being out of the Loop - хрен пойми. Ну и примечательно, что во всех случаях человек несет итоговую ответственность даже за «полностью самостоятельный ИИ» (что ну в целом тоже логично).

Имхо, проблема этой всей концепции в том, что даже для «мясного» архитектора скоуп задач во многих процессах сформулирован максимально расплывчато, выхлопы звучат местами неубедительно, а затраты - чисто психологически - часто перевешивают (см. скрин с моей «итоговой» презентации для коллег на эту тему). А если даже человеческий скоуп этой деятельности часто нечеткий и ставится под сомнение, то строить какой-то «луп» для выполнения этого всего с помощью ИИ, да еще и делать для человека роль какого-то «супервайзера» - звучит как очень хреновая сделка) В этом смысле первая модель тоже выигрывает, так как «мясной» архитектор в этой модели продолжает делать хоть что-то, за что ему понятно, за что платить, а как он там ИИ использует для прокачки своей деятельности - бюджетодержателям пофиг. Работает эффективнее? - молодец!

Автор канала "Человек и машина" Карен Товмасян фактически прекратил вести канал и попрощался с читателями. В своем финальном посте он поделился причинами, и я считаю их довольно показательными.

Канал представлял собой авторский блог на ИТ-шные темы - в основном вокруг облаков, облачной архитектуры и AWS. С 2017-го года Товмасян работал в Нидерландах Cloud Practioner-ом, облачным архитектором на границе с девопс-специалистом (весьма распространенная в облачных инфраструктурах, да и не только функция архитектора), затем стал работать в EPAM, а затем - в Uber. В блоге он рассказывал о собственном опыте, выкатывал приличные экспертные тексты (в том числе - довольно много интересной информации про IAM в AWS или историю развития DynamoDB).

Ключевой причиной прекращения развития канала автор называет сильную занятость в работе и отсутствие возможности вести об этом блог (хотя непосредственно в статье причина описана более ёмко, буквально как «Я за%@ался»). При этом писать что угодно, лишь бы была активность, он считает некорретным по отношению к своим читателям, а писать полноценный экспертный контент, как раньше, не может - между блогом и работой выбирает работу.

Ключевая мысль из текста, кмк, звучит вот так:

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

То есть это буквально про дихотомию «работать или рассказывать о работе». Да, в нашей отрасли есть немного примеров, когда автор, занятый в практической деятельности, параллельно находит возможность вести какое-то около-экспертный контент (как правило, без претензий). Мой канал (не понтуюсь) - как раз такого плана, но посмотрите на частоту выхода постов)))

Но в основном люди, занимающиеся регулярной около-экспертной публикацией в ИТ, рано или поздно приходят к тому, что публикация и становится их работой (ну или основным инструментом привлечения к работе, который занимает 80% времени). Это не плохо и не хорошо, но скорее всего этим во многом и объясняется некоторый ммм.. скептицизм аудитории к «экспертизе» таких спикеров («а Фаулер вообще кто по жизни мне тут про паттерны рассказывать? Интеграцию со СМЭВ делал? На php в 90е кодил? Вот то-то и оно..»). Товмасян, на моей памяти - первый пример спикера, который свернул на этом пути в другую сторону и выбрал работу.

Готовится новый вебинар.
По традиции на финальном слайде - мои котики 🤷
Анонс в начале недели💪

Готов анонс. Если интересно - приходите💪

Поговорим про мою любимую корову - архитектурные решения (design decisions то есть)

В рамках нескольких рабочих задач вспомнил о существовании довольно интересного видео об эволюционном подходе к архитектуре в Agile. Это запись вебинара от Luxsoft, который прошел больше семи лет назад - по меркам современного ИТ - во времена динозавров. Когда-то, когда я активно искал для себя и коллег ответ на вопрос "как нам в этом вашем agile что-то проектировать, когда мне все разработчики рассказывают про то, что они мол в своих командах и сами себе архитекторы", я на него наткнулся, и мне очень зашло.

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

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

Кстати, для предстоящего сегодня вебинара по арх решениям (робко напоминаю, если интересно - приходите) тоже будет полезно.

З.Ы. Ну и суровый русский акцент модератора вебинара вызывает приятные воспоминания...

З.З.Ы. Если ВДРУГ у большого количества будут траблы с доступом в отрицательно ускоренный ютуб, ставьте 🥲. Если наберется много - выгружу видео и даже могу сделать русскоязычную версию с помощью нейронки.

Начинаем через 3 минуты))

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

Речь про материалы от Andrew Harmel-Law, автора книги Facilitating Software Architecture. Книгу, каюсь, целиком не читал, и не осуждаю, базировался на следующих материалах:
🔹Статьи на сайте его книги, в частности вот статья про критерии архитектурной значимости решения и вот статья про сам Architecture Advice Process
🔹Статья про масштабирование архитектурных практик (как раз буквально про распределенный дизайн) на сайте Фаулера
🔹Запись подкаста с автором книги на InfoQ. Если не очень хорошо воспринимаете английский на слух, на сайте есть хорошая расшифровка (но имейте ввиду, сайт без кое-каких технических решений работает почему-то медленно)

В целом в этом процессе не прям рокет сайнс. Ключевые мысли оттуда (в первую очередь - из подкаста) могу написать отдельным постом, если будет интересно.

Спасибо всем, кто был на вебинаре, прошу прощения, если было немного долго🥲

Хороших выходных!

Пока организаторы готовят запись вебинара, ловите презентацию.

Всем привет и TGIF!

Как-то незаметно почти пролетел февраль, в середине которого я наконец-то осилил какое-то подобие отпуска. Готов ворваться с новыми силами (нет).

В прошедшие выходные проводил еще один поток воркшопа по структуризации архрешений (называю его коротко "Воркшоп по ADR"). По сравнению с прошлым, пилотным потоком структуру и содержимое воркшопа удалось прилично обновить, и - да простят меня посетители пилота - получилось вроде более эффективно и полезно. Ну и ученики, конечно, мне пока попадаются исключительно мотивированные, заинтересованные и задающие правильные вопросы. Жаль, что преподаватель им попался, который простых ответов почти не дает😂

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

Итак, одна из самых больших, можно сказать, ключевых сложностей процесса принятия архитектурно-значимых решений (design decisions, уточняю, чтобы избежать путанницы с solution) - определение проблемы/ задачи и границ решения. Многие проблемы с превращением "легковесных ADR" в гигантские развесистые трактаты об архитектуре, аналитическим параличом всех "принимающих решения" и вялотекущим процессом, который в итоге никак не вплетается в производство, рождаются из неправильных границ самой сути решения, то есть из неправильного ответа на вопрос "а что именно нам надо в итоге решить?"

Давайте на примере:

Вот есть условная задача "сделать так, чтобы база данных могла обрабатывать бОльшее количество запросов без возможности вертикально масштабировать БД".

Поставь эту задачу группе технически подкованных людей - и они через 15 минут прибегут к тебе с вариантами решений: "шардировать БД, нет, перевести всё на микросервисы, нет, заменить РСУБД на NoSQL, нет, выкинуть БД и перенести всё в облако...". Затем на каждый такой вариант они начнут сами себе задавать вопросы, погружаясь в пучину разветвленного дерева решений - если заменить всё на микросервисы, то какие это будут микросервисы? Может тогда часть БД всё-таки заменить на NoSQL? А если нет, то может это можно шардировать? Но по какому ключу? А что если мы наймем еще 30 новых разработчиков? Обязательно кто-то задаст вопрос "а сколько у нас вообще CPU и RPS?", и скажет, что без этого решить ничего абсолютно невозможно.

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

Скажем, в нашем примере первое решение - выбор стратегии или подхода - или как хотите назовите - по решению задачи "сделать так, чтобы база могла обрабатывать больше запросов без вертикального масштабирования". Все остальные детали - ключ шардирования или количество микросервисов - будут уже потом, сперва надо решить главное (на сейчас).

Или, например, задача "импортозамещения БД", которая часто воспринимается как задача "замена импортной БД на другую", на самом деле чаще звучит как "избавиться от импортной БД" со всем остальным контекстом.

От умения ограничить задачу (problem в структуре любого ADR) и границы (scope/ context) зависит, удастся ли выстроить процесс принятия архитектурно-значимых решений. Это же позволит многие "важные" решения (которые на самом деле - составляющие части других, более поздних решений) отложить на потом, писал об этом тут.

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

Ну и напоследок - вот запись моего вебинара, где я раглагольствую про архитектурно-значимые решение - откуда это взялось, как развивалось в контексте нашей дисциплины, где мы сейчас, и почему это вообще кому-то должно быть интересно. Попробовал тут в этом вебинаре собрать почти всё, что считаю важным по теме. Можно смотреть на отрицательно ускоренном YouTube на х1.5 точно.

Хороших выходных💪💪