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

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

Полгода назад у Фаулера появился цикл статей под общей темой 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 подписчиков. Спасибо всем, кто помогает каналу и тем кто просто его читает!

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

Добавил много ссылок, связанных с записями архитектурных решений (architecture decision record), к видео вебинара, прошедшего в сентябре 2019 года https://youtu.be/9vtf33NIJrE

Я редко стал заходить на InfoQ Когда-то это был интересный ресурс, но всё рано или поздно заканчивается. Но вот сегодня я туда заглянул и тут же обнаружил вот это: https://www.infoq.com/articles/microservices-seven-fail/ Думаю, что еще лет десять одни люди будут писать разные глупости и умности, предостерегая других людей от микросервисов. Время начинать изучать это в качестве культурного феномена

12 определений Cloud-Native приложений https://ozimmer.ch/index/2021/05/21/CloudNativeDefinitionAnalysis.html

Закон Конвея. Перевод статьи «How Do Committees Invent?»

Так как статья – не художественное произведение, да еще и написана в далеком 1968 году, ее перевод может (да, наверное, и должен) восприниматься как весьма косноязычный и местами непонятный, но так уж излагали мысли ученые в 68-м. Посчитал, что для научной статьи адаптивный перевод может привести к потере смыслов (хотя и понимаю, что на русском языке смысл может исказиться). Всячески рекомендую оригинал (ссылка в конце статьи), а переводом пользоваться только в том случае, если недостаточно знаний английского.

http://agilemindset.ru/закон-конвея-перевод-статьи-how-do-committees-invent/

Несколько цитат:

👉«никогда не бывает достаточно времени, чтобы сделать что-то правильно, но всегда есть достаточно времени, чтобы сделать это заново»

«Каждый раз, когда осуществляется делегирование и сужается чья-то область исследования, также сужается и класс вариантов решений по проектированию, которые могут быть эффективно реализованы.»

«Как только определены сферы деятельности, возникает проблема координации.  Координация между рабочими группами, хотя и снижает продуктивность отдельных сотрудников в небольшой группе, обеспечивает единственную возможность того, что отдельные рабочие группы смогут объединить свои усилия в единую систему.»

«осознание первоначальными проектировщиками того, что система будет большой, вместе с определенным давлением в организации делает непреодолимым искушение назначить для разработки дизайна слишком много людей»

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

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

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

«Даже в умеренно небольшой организации возникает необходимость ограничить общение, чтобы люди могли выполнить какую-то «работу».»

«Необходима философия управления дизайном систем, которая не основывается на предположении, что простое добавление рабочей силы повышает производительность.» – Закон Конвея именно об этом, хоть и звучит как «организация, проектирующая систему (в принятом здесь широком смысле), производит дизайн, являющийся копией коммуникационных структур этой организации»

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

Кстати, еще одна ссылка к вебинару - обзор истории ADR от Olaf Zimmermann (ZIO) https://ozimmer.ch/practices/2020/04/27/ArchitectureDecisionMaking.html

Разрешите представить Виктора Хоменко (@viktorkho), Билайн в Казахстане, Алматы, который теперь вместе со мной будет администратором наших групп по ИТ-архитектуре

Оригинальное описание Леонардом Ричардсоном его модели зрелости RESTful API объясняется вот здесь: https://www.crummy.com/writing/speaking/2008-QCon/act3.html Возможно, кому-то этих слайдов и текста будет достаточно. Идея просто отличная.

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

Richardson Maturity Model

Обнаружил, что в январе 2022 The Open Group выпустило руководство о том, как делать микросервисы по TOGAF ADM. https://publications.opengroup.org/togaf-library/g21i Вот прям по тупо по процессу, со всеми фазами: бизнес-архитектура, архитектура данных и т.д. На 50 страниц руководство.

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

В далеком 1987-м Джон Захман предложил любую модель системы причислять к одному из трех фундаментальных типов: описание данных, описание функций или описание физической структуры системы.

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

Спасибо за большое количество отзывов на такую маленькую заметку. Было бы ошибкой с моей стороны попробовать ответить на все комментарии сразу, т.к. они очень разные. Постараюсь сделать это постепенно. Начну, пожалуй, со сложности https://tttttt.me/c/1304614627/18955

Во-первых, поделюсь ссылкой на перевод старого, но всё еще актуального текста Ефима Натиса Покорение сложности ИТ Удивительно, но ссылки на этот легендарный текст в этом канале до сих пор не было.
Во-вторых, уже от себя замечу, что разные виды сложности можно и нужно различать. Есть сложность реальная, проистекающая из большой вариативности объектов, отношений и вариантов развития событий. Есть сложность невынужденная, связанная с выбором не самого подходящего варианта реализации. А еще бывает сложность мифологическая. Примером такой сложности является популярная в своё время история о том, что интеграция точка-точка проигрывает интеграции через серверную шину. Вообще, любые комбинаторные предположения должны нас насторожить. В реальности интегрировать все системы со всеми никто и не собирался. Это просто не требуется. Сейчас похожий сюжет используют в страшилках про сложность взаимодействия между микросервисами в топологии каждый с каждым. Зачем бы это понадобилось сказать сложно, но выглядит вполне пугающе

И еще одно замечание. В упомянутой статье https://www.osp.ru/os/2005/07-08/185761 Натис вводит следующее определение

Сложность (IT Complexity) — это мера нашей неспособности понимать, использовать, «ремонтировать» и наращивать свою ИТ-среду. Любое решение, помогающее воспринимать, диагностировать и обслуживать эту среду как единое целое, упрощает ее. А любые факторы, препятствующие этому, ее усложняют

Т.е., по-сути такое определение делает IT complexity субъективной мерой, т.е. зависящей от того, кто именно разбирается с данной конкретной архитектурой. Субъект может знать об определенных паттернах или не знать, понимать или не понимать замысел спроектировавшего решения архитектора и это влияет на воспринимаемую сложность. В общем, как только мы вводим в нашу модель субъекта, про комбинаторную сложность можно забыть. Слишком близка стала ИТ-архитектура к гуманитарным дисциплинам, чтоб мерять её объективными мерами длин и весов