Иногда у Марка Ричардса случаются складные видео (пропустим мимо ушей разговоры про квантовую запутанность) Вот сегодня Lesson189 - Architectural Quantum Tradeoffs - вполне себе внятный рассказ про архитектурную кату Sysops Squad (она была не только в книжке про трудные компромиссы, но и в турнире O'Reilly, весной 2021, см. Разбираем описание ИТ-архитектуры) и на её примере о том, что же такое архитектурный квант.

И про отряд сисопов понятно рассказал и про разделение системы по группам нефункциональных требований упомянул и неуместное синхронное взаимодействие подсветил, хотя…

Даже удивительно, что в 2024 году кто-то всё еще отслеживает тренды в архитектуре предприятия. Оказывается, отслеживают. Сегодня речь о майском отчете State of Enterprise Architecture 2024 от Bizzdesign

Можно скачать за корпоративный e-mail или просто почитать пояснения(по ссылке выше). Пояснения Марка Ланкхорста в блоге мне понравились даже больше, чем красивый сорокастраничный буклет. Впрочем, в нем тоже есть что почитать.

Модель исследования достаточно традиционная. Взяли более 500 респондентов, по некоторой шкале оценили уровень зрелости в их компаниях функции корпоративной архитектуры. На основании этого поделили на 3 части: четверть - лидеры, столько же отстающие, а остальная половина – середнячки. А потом стали сравнивать насколько различаются эти группы по разным компетенциям. И тут вдруг начинают выявляться разные большие разрыв, например в идентификации zombie-applications или полезностью архитектуры при управлении изменениями...

В общем, см. табличку выше и читайте отчет

Поделюсь слайдами выступления на Team/Tech Lead Conf'2024. Меня уже двое попросили повторить историю о том, как рассказывать архитектурные диаграммы в ‘корпоративном’ формате. Я с удовольствием это сделаю, приглашайте.

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

Нашел для коллекции еще один кликабельный архитектурный артефакт - Enterprise Architecture Implementation Wheel

Оффтоп по пятницам: Честно говоря, я совершенно не помню, где, когда и зачем мне довелось программировать микрокалькулятор MK-61. Я не помню какие программы писал, хотя точно помню что писал. Но вот вдруг оказалось, что голова вполне себе отчетливо сохранила в памяти всю эту историю про стек из четырех регистров X, Y, Z, T, который можно вращать; про кнопки [В↑] и [С/П] и про то, как вводить, запускать и останавливать программу. Удивительно!

Прочитайте здесь: https://habr.com/ru/articles/505612/ может тоже что-то подобное вспомните. Развлекитесь здесь: https://mk-61.moy.su/emulator.html (там еще и на логарифмической линейке можно посчитать и арифмометр покрутить) и постарайтесь снова почувствовать ту наивную детскую радость, что непременно возникает при успешном прохождение дымового теста

Можно ли сравнивать Google Cloud Architecture Framework c традиционными архитектурными фреймворками, такими как TOGAF?

Я бы не спешил отвечать отрицательно. Наблюдая уже пару лет за развитием этой истории(см. журнал изменений здесь: What’s new), можно провести некоторые параллели с эволюцией более тяжеловесных подходов, проходившей лет 15 тому назад. Да, system design это совершенно не то же самое, что описание текущей и целевой архитектур, но все же. Вот даже такие видео Introduction to the System Design Pillar of the Google Cloud Architecture Framework если и не напоминает вебинары The Open Group, то тяготеет к ним по стилистике. Дежа вю усиливается если углубиться в чтение текстов. Возможно, я субъективен

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

📌 26 июля в 11:00 состоится вебинар с результатами исследования State of DevOps Russia 2024, которое я анонсировал в апреле и инфопартнером которого является наш канал

Необходима регистрация

📽 YouTube пока еще работает, но только медленно, а может уже не работает, зато быстро, а может что-то еще...

В общем, все видео и трансляции с канала Архитектура ИТ-решений я скопировал вот сюда: https://disk.yandex.ru/d/0lwmomky8wCjgw Их можно скачать оттуда в формате mp4 или посмотреть в удобном для вас качестве, не загружая на локальный компьютер

Если вы уже забыли (или не знали) о системах управления бизнес-процессами BPMS, то Bernd Ruecker - сооснователь Camunda, напоминает вам о них в своем свежем тексте Are You Done Yet? Mastering Long-Running Processes in Modern Architectures. Честно говоря, мне всегда нравился этот автор. В первую очередь, четким позиционированием и движков состояний и непосредственно камунды, как неких легковесных готовых компонент(библиотек) для построения более сложных решений. А еще умением изящно выделиться на фоне коммерческих BPMS

Правда, упомянутый выше текст смотрится немного поверхностным, а примеры надерганными и нецелостными. Тем не менее, я его рекомендую

Картинка накануне очередных летних выходных. Хорошей вам пятницы!

Почему-то мне казалось, что однажды я уже делился в канале этим слайдом и ссылкой на статью: Distributed transaction patterns for microservices compared Билгина Ибряма о распределенных транзакциях (5 паттернов двойной записи... - другое название этой статьи).

Оказалось, что не делился, хотя и обещал на одном из вебинаров это сделать. Исправляюсь!

В тот же каталог буду пока выкладывать видео других выступлений с YouTube. Вот, кстати, запись с прошедшего в конце июня в Санкт-Петербурге TechLeadConf и история о том, Как рассказывать архитектурные диаграммы (Ссылка на видео в канале конференции: https://youtu.be/Ba9IejlZ-ws)

В IcePanel собрали пару ссылок на тексты из серии Modelling vs diagramming и дополнили их новыми словами и картинками. Но, на мой взгляд, не сделали главного, а именно не собрали в одну линию эскизы, модели, представления, исходники, работающее приложение, изменения. Обошли стороной вопросы когда и зачем нужны модели или диаграммы

В этом плане, даже матрица Захмана 1987 года, прокладывающая логику от набросков на салфетке до готовой системы, смотрится более целостной.

Ссылки:
[1] Comparison - C4 modelling vs diagramming
[2] Ardoq Compared to Drawing, Modeling, and Data Visualization Tools
[3] Modelling vs diagramming software architecture

Удивительным образом на сайте Martin Fowler нашел новый для себя текст от Gregor Hohpe. Почти 5 лет назад в заметке Don't get locked up into avoiding lock-in Грегор сделал исчерпывающий обзор того, что принято называть Vendor Lock-in, выделив разные степени подобных привязок (продукт, версия, архитектура, платформа и пр., вплоть до Mental Lock-in). Ну, а заодно, в очередной раз напомнил нам о назначении архитектурных моделей и пользе рассмотрения альтернативных вариантов.

В общем, от привязок нам не избавиться, но заголовок статьи обнадеживает: не замыкайтесь в себе, избегая блокировки

С 1 сентября ArchiMate Forum из Open Group собирает идеи и запросы на изменения языка. Называется это Archimate Feedback Campaign 2024

Подробности тут https://www.opengroup.org/archimate/feedback

И, наконец, полная версия Исследования состояния DevOps 2024! от команды Экспресс 42

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

Посмотреть полную версию можно 👉 по ссылке!

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

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

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

The Solution Architect As Product Manager – новая сотня слайдов от автора учебника по архитектуре решений Alan McSweeney. Краткое резюме (см. слайд 98):
- Давно существуют и широко применяются проработанные подходы к разработке и развитию потребительских продуктов/решений/услуг (в тексте даже упомянут New Product Development (NPD) Stage Gate)
- Архитектура решений может использовать их двумя способами. Первый в том, чтоб расширить восприятие ландшафта изменения (а не ограничиваться доработкой ИТ-систем)
- Второй, для выбора действительно важных и актуальных изменений из огромного множества потенциально возможных изменений (я называю это воронкой инициатив)
- Роль архитектора решений идеально подходит для выполнения этих функций