Узнал я новое слово на букву "С". На днях Билгин Ибрям написал довольно большой текст на InfoQ What Are Cloud-Bound Applications? о том, что же привязывает наши приложения к конкретным инфраструктурам, платформам и сервисам

В Scaled Agile Framework есть ряд идей, на которые я часто ссылаюсь в своих курсах, вебинарах и выступлениях. Например, выделение трех основных архитектурных ролей (enterprise, solution и system architect) или воронка Portfolio Kanban, позволяющая определять приоритеты задач на основании рассмотрения альтернативных вариантов реализации(см. рисунок).

Это совершенно не значит, что я за SAFe или же против него. Чтоб избежать предвзятого отношения я позволю себе поделиться ссылкой на сайт The SAFe Delusion оставив каждому подписчику труд выработать то или иное собственное отношение к SAFe или возможность не делать этого вовсе

Simon Brown добавил несколько примеров альтернативных визуализаций в https://c4model.com/#AlternativeVisualisations

Выше я ссылался на его выступление Diagrams as Code 2.0 с идеей, что модель не только первична по отношению к диаграммам, но и может быть выражена разными нотациями моделирования

Текущие результаты опроса (Google Tree Map Chart)

Ежегодно O'Reilly анализирует поисковые запросы по своим книжкам и курсам и пишет об этом большой и бестолковый отчет Technology Trends for 2023. В этом году он появился 1 марта, но у меня все не доходили руки с ним разобраться.

Честно говоря, чтения отчета несколько меня разочаровало. Я бы предпочел набор сырых данных (меньше букв, больше цифр). По крайней мере, тренды по архитектурным словам (см. график) я понять не сумел. Согласно отчету растет всё:

- Архитектура ПО выросла в 2022 по сравнению с 2021 годом на 26%.

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

Я остановил опрос с такими текущими результатами:

В нашем чате более 500 архитекторов решений (Solution Architect), более 330 системных и 150 бизнес-аналитиков. Более 300 разработчиков. А еще 250 архитекторов ПО и примерно столько же человек, которые позиционируют себя в качестве Enterprise Architect. Меньше системных инженеров и QA

Я пропустил тот момент, когда ассоциация всех ИТ-архитекторов IASA вместо руководства по архитектуре ITABOK стало развивать The Business Technology Architecture Body of Knowledge (Btabok) Кто-нибудь разбирался с этим?

Вышла стенограмма InfoQ Software Architecture & Design Trends 2023

Честно говоря, я не подписан на Криса Ричардсона и потому заметку About dark energy and dark matter: forces that shape an architecture, появившуюся в его блоге в прошлые выходные, увидел сейчас впервые (хотя метафору эту он использует уже давно).

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

Рlatforms are a very popular concept these days and rightly so in fact many of you might be designing or building platforms right now but as architects we should also look behind what makes platforms so special...
- The Magic of Platforms by Gregor Hohpe

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

Читайте на сайте Luca Galante с пересказом и отдельными слайдами https://platformengineering.org/talks-library/the-magic-of-platforms или просто смотрите на YouTube https://youtu.be/WaL3ZbLgMuI

#platformengineering

Когда автору архитектурных диаграмм поручили спроектировать электроплиту

Как говорится, PR-щику на заметку: Если вы сомневаетесь, что основной материал, в данном случае Software Architecture and Design InfoQ Trends Report - April 2023 удался, то сначала опубликуйте его обсуждение. Иначе, никто не станет читать ни отчет ни историю его подготовки

Первоисточники и истоки появления platform engineering вообще не про конкретные решения. Они про управление когнитивной нагрузкой и гибкость в следовании за изменениями в процессах.

Мы сейчас наблюдаем рождение очередного карго-культа, как с ESB (паттерн подменили вендорскими решениями), управление процессом (подменили jira) и так далее.

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

Бэкстейж, как и сама модель работы спотифай, развивались годами, пройдя определенный путь, который и привел их к текущей точке. Если брать их платформу, то нужно менять и оргструктуру и все окружающие процессы и культуру и инструменты и в ряде случаев технологии.

Запись вебинара #PlatformEngineering

Обещал выложить слайды

Ну, и еще немного про платформы. Почитать на выходных документ от CNCF: https://tag-app-delivery.cncf.io/whitepapers/platforms/

Давайте поделюсь еще одним отчетом по #PlatformEngineering
State of DevOps Report: Platform Engineering Edition https://www.puppet.com/resources/state-of-platform-engineering

Каждая версия технологического радара приносит какие-то новые термины или переосмысляет прежние. Вышедшая на днях 28-ая версия не исключение. И в длинных списках платформ, инструментов и языков программирования может легко затеряться раздел про системы управления знаниями. Так что обратите внимание на то, что Thoughtworks включил в кольцо assess раздела инструментов Obsidian и Logseq

На AWS re:Invent 2022 знаменитый Gregor Hohpe в своем выступлении Are you integrating or building
distributed applications? порадовал нас вот таким вот слайдом про RPC

[1] Ссылка на выступление https://youtu.be/Zrj7RD7G24Q?t=3141
[2] Слайды в PDF

Можно было бы сделать отдельный курс по Solution Architecture по материалам от Alan McSweeney. Но пока этого не случилось, в дополнение к слайду о составе ИТ-решения, я поделюсь его слайдом об отображении компонент решения и зависимостей между ними