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

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

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

В том, что касается структуры я непременно соглашусь с форматом 10-минутного описания проблемы в начале каты и 5-минутной презентацией решения в конце. Но традиционно поспорю с архитектурными характеристиками и архитектурными стилями затесавшимися в середине. Ну, сколько можно популяризировать "звездную" табличку стилей-характеристик (я вот уже её постил однажды: https://www.tg-me.com/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 (слайды внутри)