Архитектура ИТ-решений

Отвлекусь от аналитики популярной на более фундаментальный контент. Gerben Wierda, автор книжки Mastering ArchiMate, отметился в своем блоге новым текстом с длинным названием Don’t forget all the things that a core team performs to a tee, but that you never see, в котором в очередной раз, и довольно внятно, изложил свою основную концепцию, описывающую цифровизацию, современные ИТ и связанные со всем этим проблемы.

📓Напомню её основные идеи:
Мы живем в хрупком мире на вершине айсберга из запутанных логических систем, появившихся в предыдущие несколько десятилетий. Хрупкость вызвана нашими скромным способностями к пониманию устройства этих самых (я бы сказал дискретно-событийных) систем и еще более ограниченными возможностями их корректного(неразрушающего) изменения. Что неплохо люди научились, так это наращивать такие системы (ООП, agile/devops, project to product shift Хербе считает проявлением общего подхода борьбы со сложностью: сначала стандартизация, а когда это перестает работать, то фрагментация). Но расширение систем усложняет их еще больше, делает крайне инерционными, практически непригодными к изменениям. Процесс развития систем автор описывает как получение продуктивность в обмен на гибкость. А потерю гибкости считает неизбежным свойством large logical landscapes. И просто крылатая фраза автора, повторяемая из текста в текст:

technical decoupling is possible, logical is not

В общем, все эти(а еще и другие) наблюдения в крайне компактном по объему тексте. Enjoy!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+ слайды

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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