Разве может 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-кода на картинке

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

Марк Ричардс выложил видео Running an Architecture Kata Session (очередной выпуск серии Software Architecture Monday). В нём он на второй минуте упомянул всеми нами любимого персонажа – джуниор архитектора, порекомендовал делать команды с нечетным числом участников и насоветовал ряд других более-менее очевидных вещей по структуре и таймингу проведения каты.

В том, что касается структуры я непременно соглашусь с форматом 10-минутного описания проблемы в начале каты и 5-минутной презентацией решения в конце. Но традиционно поспорю с архитектурными характеристиками и архитектурными стилями затесавшимися в середине. Ну, сколько можно популяризировать "звездную" табличку стилей-характеристик (я вот уже её постил однажды: https://tttttt.me/it_arch/1426)

Подкаст InfoQ Architecture and Design Trends in 2024 оказался содержательнее отчета. Не менее 20 минут уважаемые эксперты поговорили о трендах современных распределенных архитектуры. С их мнением можно соглашаться или не соглашаться (или вообще игнорировать), но хотя бы термины они прояснили

Сell-based architecture сразу утратила часть своего обаяния когда стало понятно, что речь идет о Bulkhead pattern. Причем этот термин представляется мне намного более понятным по сравнению с ячеистой архитектурой.

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

Рико Фриче порадовал текстом Domain-Driven Design: The Power of CQRS and Event Sourcing, в котором вместо традиционного уже пояснения что представляет собой CQRS/ES акцентируется на более глубоких аспектах. Прям целая россыпь идей, включая:

- замечание об однонаправленном поток данных(single direction flow) в отвечающих CQRS паттерну архитектурах. Я бы даже сказал, что речь идет о направлении потока изменения данных. Вот он един(но может разбиваться на рукава), упорядочен, с четко заданным направлением от одних элементов к другим. Чего обычно нельзя сказать просто о взаимодействиях;

- замечание, что объединение моделей чтения и записи данных приводит к более сильной связности (high coupling). Избавляясь от представлений для чтения, можно сделать модель записи более ориентированной на поведение. А независимость моделей чтения от записи открывает нам возможность построения набора независимых проекций данных

В общем, CQRS/ES не только про масштабирование

На сайте The Open Group появился небольшой обзор истории Archimate приуроченный к 15-летию выхода первой версии под эгидой TOG https://blog.opengroup.org/2024/04/18/celebrating-15-years-of-the-archimate-modeling-language-a-milestone-in-enterprise-architecture/

Нашел чек-лист для проверки опровержения CAP теоремы. Если вы считаете, что сумели придумать решение, сочетающее в себе доступность, согласованность и устойчивость к разделению (consistency-availability-partition tolerance), то загляните сюда https://ferd.ca/beating-the-cap-theorem-checklist.html

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

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

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

Часто в таких случаях раздражение выплескивается на архитектора. Он же ведь эти диаграммы рисовал, а ведь мог бы вместо того пойти код писать. Только архитектор во всём это не виноват, ведь правда?

В марте этого года я провел вебинар с разговором об альтернативах микросервисам. И конечно не обошлось без упоминания модульного монолита, ставшего столь популярным в прошлом году.

Месяцем позже Derek Comartin высказался на эту же тему в своем тексте/видео Google Service Weaver is a Bad idea Естественно сделав это несравнимо более полно и профессионально, чем я

С некоторых пор отмечаю в себе нездоровый интерес к кратким описаниям TOGAF. И вот еще одно: A Practical Guide to TOGAF Implementation от Visual Paradigm.

Описание представлено в двенадцати лаконичных разделах и сопровождается историей о том, что в какой версии появилось. Ну разве оно не замечательно? Думаю, чуть подсократить и на страницу бы поместилось

А вот здесь уже опубликовали видео моего недавнего выступления:
⏯ Job crafting в работе ИТ-архитектора

Готовился я тут к выступлению о том, как рассказывать архитектурные решения и набрел на короткую заметку Джорджа Фэрбенкса из 2011 года про архитектурные хайку Haiku tutorial (слайды внутри)

Продолжаю рассказывать про архитектурные репозитории - один из главных инструментов архитектора предприятия. В исходном сообщении я поделился ссылкой на HTML-представление учебного примера архитектуры предприятия ArchiSurance Case Study. Опубликовано оно среди материалов для архитекторов на сайте The Open Group, а непосредственно модель была изначально сделана в Archi.

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

SHOW TABLES 

ну а элементы модели получить SELECT-ами по соответствующим таблицам.

Подробней обо всем этом в первомайском тексте Xiaoqi Zhao: https://yasenstar.github.io/EA/architool/Query-Archi-HTML-Report.html