Продолжение разговора об описании архитектуры ИТ-решений уже через полчаса.

Прямая ссылка на трансляцию: https://youtu.be/HWHxTjEE5D4

Лет этак много тому назад, возвращаясь с зимних каникул, архитекторы хвастались тем, что пощупали тот или иной инструмент, фреймворк или технологию. Сейчас развернуть что-либо и запустить пару примеров – не проблема. Доступны не только образы, но и сервисы типа https://www.katacoda.com/ В общем, традиция как-то ушла в прошлое. Вот и я в эти новогодние праздники больше читал, да и вот стрим провел (см. предыдущее сообщение). Потому буду делиться ссылками на прочитанное с некоторыми комментариями

Начну вот с этой ссылки https://unfix.work/ Все уже хором принялись ругать эту… - не мышонка, не лягушку, а Not Another Agile Scaling Framework.

А оно ведь свеженькое (первое сообщение в блоге https://unfix.work/blog от 2 января), с картинками в виде диаграмм Эйлера, как мы любим :-) (кстати, пакет картинок можно скачать за регистрацию) и историями про экипажи, возвращающиеся на базу… Базы бывают разные, экипажи тоже. И всё это великолепие кружится в инновационном вихре.

Из FAQ: The unFIX model is more a modeling tool than a framework. In fact, you can use the tool to define frameworks such as SAFe, LeSS, and Holacracy, which you can all create out of the elements of unfix

Так что ругать здесь особо нечего. Инструмент он и есть инструмент

Следующая ссылка из материалов новогоднего чтения от The Open Group https://pubs.opengroup.org/opengrouppress/the-turning-point-singlepage/index.html

Да-да, трогательная история компании ArchiSurance, иллюстрирующая использование Archimate, пополнилась настоящим романом в стиле проекта феникс или проекта единорог.

Честно говоря, внимательно я прочитал только первую главу и просмотрел приложения с картинками в archimate. Остальное прошелся по диагонали. Сюжет мне не понравился. Слишком все нарочито. Хотя начинается жизненно, с раздумий CIO о том, что же полезного удалось сделать за год после слияния компаний под улюлюканье бизнеса, внедряющего agile. В общем, полистайте, может кому понравится

Кстати, вряд ли нашел бы этот роман если бы не годовой отчет TOG https://blog.opengroup.org/2022/01/06/highlights-of-2021-peek-into-2022/ Правда отметить в нем для себя чего-то полезного я не смог :( Ну, вот хоть роман про арчишуранс полистать

Пока заметка из понедельника продолжает набирать лайки, Jurgen Appelo добавляет в блог unFix новые записи. Сегодня вот эту https://unfix.work/blog/lets-unfix-team-topologies. Я не очень люблю лонгриды, но обожаю дружелюбную критику/переосмысление популярных идей и текстов. В данном случае уже нашумевшую Team Topologies. Сомнения и альтернативы - лучшее что у нас есть

PS А предыдущее сообщение про Spotify Model я разберу как-нибудь отдельно

В этом году стал почитывать советы Дэна Хьюза по архитектурным диаграммам. Мне не нравятся! Но может я просто чего-то не понимаю https://wittij.com/5-tips-for-better-solution-architecture-diagrams/

Что архитектура решений (Solution Architecture) позаимствовала у других видов архитектур? От архитектуры предприятия – взгляд на любую деятельность, как на изменение уже существующего ландшафта приложений, процессов и данных. Ни одно изменение не начинается с чистого листа. От software architecture архитектура решений взяла сфокусированность на конкретной задаче, вместо попыток обозреть весь корпоративный ландшафт.

Я бы сказал, что архитектура решений возникает на границе. На границе систем, как набор предложений по их интеграции, на границе конкретных частных задач и общих подходов, на границе ИТ и бизнеса, границе унаследованных систем и новых потребностей, а также границе интересов самых разных групп заинтересованных лиц

Запись здесь: https://youtu.be/h-WwGQgDiBU?t=67

Очень большой текст Principles of technical documentation https://www.innoq.com/en/articles/2022/01/principles-of-technical-documentation/, возвращающий нас во времена хороших требований из легендарного IEEE-830. Тем не менее, этот текст достоин прочтения, как пример проработанного текста с одной стороны и нелишнего повторения банальностей, типа: Automation won’t improve your content - с другой

Поделюсь и я ссылкой на этот интересный текст с осмыслением текущей позиции инженерии и инженера данных

Предупреждение! Сегодня вечер активности ботов. Из разных архитектурных групп (преимущественно из "Работа для ИТ-архитекторов") боты атакуют подписчиков личными сообщениями.

Будьте осторожны! Блокируйте запросы от подозрительных аккаунтов. Сообщайте о вражеских происках. Не поддавайтесь на провокации

Полгода назад у Фаулера появился цикл статей под общей темой Patterns of Legacy Displacement Кроме основного текста https://martinfowler.com/articles/patterns-legacy-displacement/ это еще набор небольших заметок, возникающих по мере необходимости. В январе 2022 появились следующие три:
- Legacy Mimic
- Critical Aggregator
- Divert the Flow

Работа с унаследованными приложениями – одна из ключевых компетенций корпоративного ИТ-архитектора. А закономерный (как мы узнали из серии статей :) провал программы модернизации таких приложений – основной профессиональный риск.
Я далек от мысли, что авторы цикла (James Lewis и др.) уже обнаружили универсальное лекарство от legacy, но направление мне представляется вполне верным

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

Ilograph – одна из немногих компаний, которая может позволить себе писать в блоге такие вот философские рассуждения о моделировании Why Do We Create System Architecture Diagrams Anyway? Да еще ссылаться в них на работы по нейрофизиологии

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

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

Сейчас я понимаю, что вчера не следовало задавать этот вопрос :) Тем не менее, за ответы большое спасибо!

Продолжая рассматривать описания архитектур с O'Reilly Architectural Kata, обнаружил и с интересом полистал презентацию Нила Форда с kickoff вторых кат прошлого года. https://tekiegirl.github.io/Archangels/assets/docs/2021-fall-kick-off.pdf

(Описание победителей этих кат здесь: https://tekiegirl.github.io/Archangels/)

Вчера заглянул на гартнеровский вебинар (слайды здесь). Удивился, что Gartner проводит вебинары на русском, да еще такие толковые. И дело даже не в том, что компонуемость (это один из трендов 2022 года) оказалась, в первую очередь, бизнес/ИТ характеристикой организации. Компонуемость эту самую оказывается можно прокачивать благодаря улучшению перечисленных в презентации практик.

Важнее, что потребность в ней возникает из-за разрушения монополии ИТ-отдела на производство ИТ-решений. Вот это вот мега-тренд! Я касался его в вебинаре Что ждет архитектора решений? В двух словах: все мы находимся в процессе замены функциональных и технологических силосов продуктовыми. Это главная история. И это главное следствие цифровой трансформации.

Ну и слайд №20 (см. рисунок) просто великолепен

Вот мы и перешагнули еще одну скромную отметку в 7000 подписчиков. Спасибо всем, кто помогает каналу и тем кто просто его читает!

Приглашайте подписаться коллег и друзей и сами оставайтесь на связи!