В нашем чате Работа для ИТ-архитекторов новое обсуждение ролей и зон ответственности: архитекторы, тимлиды, техлиды и пр. Кто нужен, кто не нужен, зачем, когда, где… - прям матрица Захмана. Кстати, именно классификации типов ролей в индустрии, на мой взгляд, и не хватает. Разного рода SFIA они плоские, если так можно сказать. В них нет принципиальных различий между разными ролями.

На мой взгляд, полезней была бы многомерная модель. В ней по одной оси откладывается тип организации. Например: enterprise, outsourcing, product-based company. И в одних из них архитекторов много и разных, а в других практически нет. Ну или энтерпрайзов совсем нет, а системный архитектор - один на продукт или на технологию, как это было принято в системных интеграторах.

Другое измерение – унифицированность видов деятельности и навыков. Это можно отобразить в виде концентрических окружностей. В центре более стандартизированные роли: dev-ops-qa. Потом круг с тимлидами и аналитиками. Потом роли, которые перечни своих работ и задействованных ресурсов формируют самостоятельно и в каждой работе заново (помните в TOGAF ADM этапы B-D начинаются с выбора эталонных моделей, точек зрения и инструментов. Более общий термин для подобных вещей job crafting – подстраивание, подгонка работы под себя. Скоро об этом собираюсь рассказать поподробнее. А заодно и про модели мотивации-выгорания, JD-R и пр.). В общем, в этом измерении нужно что-то похоже на tech radar

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

Завершающаяся неделя была отмечена коллективными фобиями относительно операций, включающих как изменения состояния объктов в базе данных, так и публикацию событий.

В четверг Уэйд Уолдрон в своем видео на канале Confluent напомнил нам про Transactional Outbox Pattern. А следом Дерек Комартин вспомнил про свой прошлогодний ролик Alternative to the Outbox Pattern в сообщении Listen to yourself pattern: Is it an alternative to the Outbox Pattern?

Как спокойно было в нулевые, в мире монолитных приложений и транзакций, реализованных внутри СУБД. Хороших всем выходных!

Чем-то меня зацепил этот автореферат книжки Software Architecture and Decision-Making Может кто-то уже успел полистать и готов поделиться рекомендацией читать – не_читать?

Результаты опроса о том, что не всегда просто сделать при изложении архитектуры решения:
- Объяснять сложные вещи
- Уложиться в отведенное время
- Запоминать новые идеи
- Сдержать волнение

Однажды автор C4 model Саймон Браун подготовил A software architecture diagram review checklist.

Мне нравится С4 модель, вернувшая чересчур абстрактные подходы UML в домен информационных технологий. Мне нравятся чек-листы – простой способ направить ту или иную деятельность в нужное русло и проверить степень готовности результата этой деятельности. Но я думаю, что существует некоторая опасность, заключающая в формальном отношении к чек-листам. Это обстоятельство может все испортить.

Возьмем, например, пункт: «каждая диаграмма должна иметь заголовок» - кто бы с этим спорил. Большинство архитектурных диаграмм имеет заголовок. Значительная часть заголовков выглядит примерно так: «С4 Container Diagram». Ценность такого заголовка колеблется в районе нуля, плюс-минус. Место на диаграмме и внимание при её разборе занимает, а пользы не приносит. В кратком анонсе Браун пишет, что заголовок диаграммы должен описывать её тип и границы и в качестве примера приводит "System Context diagram for My Software System". Думаю, это не вполне подходит.

Я бы сказал, что заголовок должен привязывать диаграмму к месту, времени и автору. Т.е. мало указать диаграмму чего мы рисуем: системы, проекта или изменения. Во-первых, потому что имена вещей могут пересекаться. А во-вторых, практически всегда, абстрактные идентичности (системы, проекты и тем более изменения) имеют очень неявные границы. Под термином веб-сайт продукта может скрываться все что угодно. Далее, со временем вещи (и их границы) меняются. Да и само понятие время штука довольно сложная (вспомните грамматику любого иностранного для вас языка). Есть нечто свершившееся, нечто запланированное и что-то происходящее прямо сейчас. А есть еще наши планы, которые были сформулированы в отношении будущего и должны были реализоваться вчера, но мы не знаем случилось ли это или нет. Для описания подобных времен нужная специальная бюрократическая грамматика. Ну, да ладно. И завершающий момент: архитектурные представления (особенно представления будущего) вещь крайне субъективная. Потому без указания автора диаграмма утрачивает значимую часть своей убедительности. Иногда эта часть заголовка заменяется подписью руководителя. Впрочем, оптимальный вариант – заголовок в виде гиперссылки, ведущий на страницу описания изменения со всеми перечисленными выше реквизитами. Если это невозможно, то можно добавить пару срок с датой, автором и назначением диаграммы рядом с заголовком или в любом месте картинке.

(Много слов получилось. В следующий раз сокращу или сделаю пост в блоге)

На сайте EventStoreDB нашел транскрипт легендарного выступления Грега Янга, случившегося 10 лет назад. В виде текста оно воспринимается немного иначе. Чем-то похоже на известный 50-страничный CQRS Documents

Знаете что меня удивляет? Несмотря на обилие инфы вокруг этой темы, в ней, почему-то, всегда остается возможность добавить еще что-то новое. В том-же блоге Event Store ряд актуальных заметок, но и не только. В общем - залезаем все глубже в кроличью нору

В материалах TheOpenGroup опубликованы не только файл с описанием и archimate-моделью учебного кейса ArchiSurance Case Study, но и сформированная при помощи Archi web-версия модели для этого кейса(правда немного кривая, как и сам Model Exchange File примера)

Начинать смотреть вот с этой вкладки: https://pubs.opengroup.org/architecture/case-study-models/archisurance-html/?view=id-45418

Не знаю, выложили недавно или же я раньше просто не обращал внимание, но непременно воспользуюсь в своем курсе про модели корпоративной архитектуры

Записи прошлогодней конференции Flow появились в открытом доступе: https://youtu.be/Qt26BQXSsvA?si=HX07IvGIOZks206S&t=218

📅 15 марта 10:30 MSK Бесплатный вебинар: Реальная альтернатива микросервисам

Монолит не альтернатива микросервисам! Будь он хоть двадцать раз модульным. Монолит всегда останется единым процессом, который не разделить по серверам... или нет?

Подробности и регистрация: https://mxsmirnov.timepad.ru/event/2803564/

У Фаулера появилось описание наверное самой востребованной техники Перехват событий в рекомендациях Patterns of Legacy Displacement

Причем рассмотрены разные случаи. Если есть такая возможность, то события извлекаются из очереди. Нет такой возможности, то перехватываем HTTP поставив reverse proxy или доработав приложение или воткнув посередине API-gateway. В крайнем случае - триггеры БД (хотя по мне, так это уже перебор, не надо так). Ну и простенький пример перехвата событий с change-data-capture процессом

Ссылка на запись: https://youtu.be/rIr6xIB_x3I

+ слайды

На днях у /thoughtworks проскочила очередная статья про техрадар How to create your enterprise technology radar с набором не очень очевидных мыслей о том, что техрадар не только картинка для руководства, но и ещё формат обсуждения технологий в организации и даже инструмент упрощения технологического стека.
И это действительно важное преимущество радара перед аналогами.

Мне всегда хотелось использовать что-то подобное для оценки инициатив (запросов на изменения). Чтоб сразу видеть истории, которые еще пару лет назад были отправлены в Hold (где им и место если не навсегда, то надолго). Понимать что уже в Adopt, и значит у кого-то в работе, а потому теперь не требует пристального внимания. Ну и сосредоточится на распределении тем между Assess и Trial

Техрадар дает карту возможностей. Но схожий инструмент для оценки потребностей был бы не менее полезен

Читаете ли вы заметки Kai Waehner о потоковой обработке данных? Я, признаться, почитываю. И хотя они порою даже длиннее, чем волны и хайпы(те же волны, но в другой проекции) Gartner-Forrester-а, читать их как-то поинтересней. В общем, свежее гадание: The Past, Present and Future of Stream Processing. На мой взгляд, слишком облачное для наших широт. (прочие истории этого автора здесь: https://kai-waehner.medium.com/)

🏛Архитектура решения (Solution Architecture), в некотором смысле, является наиболее простой архитектурой. Простой, если её, например, сравнивать с архитектурой предприятия или системной архитектурой. При разработке архитектуры решений мы достаточно хорошо понимаем целевое состояние, в которое должны прийти. Мы примерно представляем, когда это случится, каким в этот момент времени должен быть набор функций решения, как будут выглядеть данные, какой набор технологий мы задействуем. Более того, мы неплохо понимает текущий набор технологий, приложений и данных из которого мы будем это целевое состояние создавать.

Сравним для примера этот уровень определенности с тем, с чем мы работает при разработке архитектуры системы. Пусть нам предстоит спроектировать систему, про которую мы знаем, что через пару месяцев должен полететь MVP, через полгода заказчику хочется покрыть некоторый базовый функционал, а через год от текущего момента времени выйти на окупаемость. Какую архитектуру нам рисовать? Ту, что сложится через год, полгода или в ближайшие пару месяцев? Они будут очень разные. Первая пара месяцев, быть может, предсказуема с точки зрения технологий. За этот срок вряд ли что-то изменится. Но на начальный момент времени предметная область (domain) окутаны густым туманом. Может быть что-то можно сказать про компонентный состав, т.е. мы выберем тот самый то ли стиль, то ли паттерн из книжек Форда и Ричардса. Через пару месяцев мы слегка начнем понимать домен. Через полгода может быть уже разуверимся в предсказанный заказчиком профиль нагрузки и начнем менять тот самый архитектурный стиль. К горизонту год что-то будет меняться в технологиях под нашей системой. В ходе всей истории мы регулярно будем узнавать много нового о реальных навыках команды разработчиков, а быть может и выбранном техстеке.

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

Разве может InfoQ избежать соблазна прокатиться на очередной волне хайпа? Свой мартовский выпуск The Software Architects' Newsletter они посвятили, цитата:
This month, we focus on "Evolution of architectures: Monolith, microservices, and moduliths"

Исследование состояния DevOps в России 2024

Компания Экспресс 42 попросила меня выступить в качестве информационного партнера ежегодного масштабного исследования состояния DevOps 2024!

Если тема DevOps вам не безразлична – пройдите опрос и внесите свой вклад в развитие индустрии. Спасибо!

Alan McSweeney в своей книжке Introduction to Solution Architecture приводит целую палитру типов запросов к архитектору решений. И даже классифицирует их по уровню уникальности запроса, требуемой глубине проработки решения и ожидаемой продолжительности работы над запросом. Позволю себе пересказать описания этих типов так:

1. У меня есть отличная идея и я хочу поскорее увидеть варианты её реализации с ориентировочными сроками, стоимостью и требуемыми ресурсами.
Rapid Solution Design: Специфика высокая, сроки сжатые, уровень проработки небольшой

2. Мне нужен детально проработанный проект на основании требований или описания проблемы, которые не обязательно четко определены.
Традиционный Solution Design Process: Специфика низкая, глубина проработки высокая, сроки обычные

3. У меня особые требования к решению и мне нужна четкая спецификация для его разработки.
Detailed Design: Высокая уникальность, сроки ближе к среднему, детальная проработка решения

4. Я хочу увидеть варианты решения проблемы с высоты птичьего полета.
Early Engagement: Частый запрос, средняя продолжительность, уровень проработки неглубокий или средний

5. Мне нужна консультация для определения новых бизнес структур для решений, связанных с некоторой проблемой или возможностью.
Business Engagement: Конкретика запроса очень низкая, уровень проработки и длительность выше среднего

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

Однажды (шесть лет назад) я делился ссылкой на From Text to Models: A Comprehensive Guide to Textual Modeling and Diagrams as Code Tools За это время каталог уже не раз обновился, так что подниму вверх

Отчет InfoQ Software Architecture and Design Trends Report с каждым разом становится всё лаконичней.

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

Похоже, чтоб разобраться придется слушать подкаст