IT Hurtz

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

IT Hurtz pinned a photo

30 января (пт) в 19:00 мск проведём вебинар на тему «Не хочу ничего решать — хочу архитектуру!», где ведущий проведёт краткий экскурс в понятие «архитектурное решение»

Последнее время все говорят о каких-то архитектурных решениях. Ну как «все»… Я говорю :) . Но непонятная задача проектирования архитектуры становится, казалось бы, еще более непонятной.

На вебинаре попробую собрать в кучу всю основную информацию об архитектурных решениях (design decisions) — что это, как появилось, почему важно и почему недостаточно просто «нарисовать архитектуру», когда об этом просит руководитель проекта или заказчик (а если вы РП или заказчик — разберемся, что именно просить).

▫️На вебинаре обсудим:
1. Кратко историю возникновения понятия «архитектурное решение» в рамках дисциплины
2. Где мы сейчас в контексте работы с архитектурными решениями
3. Ключевые характеристики архитектурных решений, и почему они должны быть ключевой частью процесса архитектурного проектирования

▫️Кому будет полезен вебинар:
Аналитикам Middle- или другим специалистам, которые принимают участие в проектировании или хотят этим заняться

▫️Ведущий вебинара — Максим Шаломович
— ИТ-архитектор
— Работал в ИТ в разных ролях с 2007 года на позициях проектировщика, аналитика и технического писателя, когда еще не знал, что это все разные люди, и просто назывался «инженер-программист»
— Последние годы работает в ролях технического архитектора и архитектора решений в крупных корпоративных и государственных проектных инициативах
— Автор воркшопа «Структуризация и рационализация архитектурных решений»

🎥 Мы выложим видеозапись в течение недели после проведения вебинара в @se_webinars

👥 На вебинаре спикер в режиме реального времени ответит на все вопросы слушателей

Регистрация обязательна

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

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

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

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

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

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

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

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

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

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

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

Авторы рассматривают три опции участия архитектора в процессе проектирования, прокаченном ИИ - 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 - хрен пойми. Ну и примечательно, что во всех случаях человек несет итоговую ответственность даже за «полностью самостоятельный ИИ» (что ну в целом тоже логично).

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

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

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

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

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

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

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

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

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

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

Бариста в моей "домашней" кофейне спросила, чем я занимаюсь. Потому что "вы то что-то кодите, то на кого-то ругаетесь, то на каких-то совещаниях".

Я подумал, что это идеальное описание моей работы, конечно😂

З.Ы. ещё она сказала, что думает, что мне меньше 30, но это к делу не относится🤗

🎄🎄🎄
Так, ну шо, поздравляю всех с наступающим/ наступившим Новым годом и Рождеством/ Ханукой/ праздником Солнца или «епта, наконец-то выходные!»

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

И помните:

Лучше всех в колхозе работала лошадь, но председателем так и не стала

Готовлю для коллег презентацию о будущем архитектурной деятельности😂

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

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

И тем не менее задача описания архитектуры решения на картинке (-ах) всё-таки есть. И решая ее, нельзя не задаться вопросом "зачем?". Душный Академически-правильный ответ "чтобы изобразить на нужных представлениях интересы (concerns) заинтересованных сторон" или "чтобы донести до заинтересованных сторон информацию в визуальной форме" я знаю, но это никому не интересно. Нужна конкретика, кому оно может быть надо? Вот список опций практического применения описания архитектуры/ дизайна решения (Solution Design/ High-level Design/ Solution Architecture и прочие похожие названия) из моей практики и практики коллег (кроме очевидного "шоб было вообще понятно, что мы такое делаем?"):
🔹 описание инфраструктуры для выделения мощностей. Первый в моей жизни документ под названием "Описание архитектуры" потребителями на стороне заказчика назывался не иначе как "Заявка на выделение мощностей в ЦОДе".
🔹 определение структуры работ для последующего планирования (Work Breakdown Structure, WBS). Особенно плотно вошло в практику архитекторов на границе Solution и Enterprise, так как буквально отвечает на вопрос "что мы будем создавать в рамках решения, что менять, что использовать, а что удалять". Все мои варианты описания за последние годы включают статус элемента/ компонента в рамках решения.
🔹 описание информационных потоков. Особенно интересно сетевикам и безопасникам. Хотя в "тру-архитектурных" сообществах принято жаловаться, что архитекторы часто занимаются рисованием картинок для ИБшников вместо того, чтобы ТВОРИТЬ, однако попробуйте в современном мире на фоне атак на крупные ресурсы и компании, вызывающие потери бизнеса, не ответить на вопрос "зачем вам надо открыть HTTP порт на вход из открытого контура в закрытый?" - и посмотрим, как далеко ваше "творчество" ляжет в стол.

Вышеописанные применения интересны тем, что для их реализации надо рисовать HLD определенной степени глубины, содержащий довольно конкретные абстракции и сущности. Философскими картинками тут не обойдешься. Это, как мне кажется, и хороший критерий качества и полезности таких артефактов, и хороший стимул к росту для тех, кто занимается таким "рисованием".