🗿В прогрессе нет ничего неизбежного. Многие плохие идеи, которые были давно и надолго спрятаны, имеют тенденцию возвращаться

Это про монолит, если что. Длинный и довольно красочный текст, с большим количеством ссылок (я знаю, такие многим нравятся), возвращающий нас к неутихающему спору про монолит и микросервисы. Давно не было слышно сторону, голосующую за распределенные системы. Этот текст прерывает молчание. Честно говоря, мне понравилось. За 18 минут свободного блуждания мыслей автора я не встретил тезиса, с которым был бы готов поспорить. Наслаждайтесь! https://mikaelvesavuori.medium.com/on-complexity-and-monoliths-424ea76abaf5

Generated with DALL·E. Prompt: “a complex monolith in a server room, with the faces of IT consultants...

Mark Richards решил записать видео, в котором перечислил названия фаз TOGAF ADM. TOGAF 10 за 10 минут, так сказать.
Не очень понимаю зачем, ну да ладно https://youtu.be/AihWJ3_klRQ

Альберто Брандолини пробует пересмотреть метафору технического долга (не в первый раз, кстати; когда-то раньше он говорил о долге перед мафией). Заменить техдолг он предлагает целостным дизайном. Получается, на мой взгляд, не очень убедительно, но задуматься заставляет https://medium.com/@ziobrando/from-technical-debt-to-design-integrity-48e7056b6776

Как вам разноцветные цитаты в новой версии telegram? (это был просто вежливый вопрос, отчасти, как я надеюсь, замещающий утреннее приветствие)

А мы возвращаемся к жанру обсуждения околоархитектурных текстов. На этот раз я предлагаю вам вышедший на неделе текст Pierre Pureur и Kurt Bittner Has Your Architectural Decision Record Lost Its Purpose? и обещаю сделать его критический разбор через пару дней. (Я и правда довольно скептично настроен к тому, что пишут обычно эти авторы)

Возможно, я немного предвзято отношусь к авторам этого текста(за исключением, разве что, Thomas Betts). Если кто-то находит их рассуждения полезными и ценными, то просто игнорируйте мои придирки.

Но у меня сложилось впечатление, что Пьер и Курт часто делают примерно так. Сначала они пишут текст с рядом предложений и гипотез. Как, например, в вышедшей полтора года назад статье Software Architecture: It Might Not Be What You Think It Is. Потом они ссылаются на свою же статью, как на некий свершившийся факт, набор принятых, устоявшихся, само собой разумеющихся практик. (Что не всегда так). Так в старой статье предлагается отказаться от взгляда на архитектуру, как на структуру решения и полностью заменить описание архитектуры набором архитектурных решений. А потом, как бы сверху закрытой темы, нам советуют не путать архитектурные решения с другими решениями, важными, но не архитектурными. И архитектуры, в её традиционном виде, уже как бы давно не существует. А вот сейчас, на взгляд авторов, важно не замутить воду настоящих архитектурных решений решениями важными, но не архитектурными

Так и хочется крикнуть, словно вдогонку уносящему авторов поезду:
- Эй, ребята, Мы не с вами! Вы одни, сами с собой уноситесь на этом поезде в страну плюшевых единорогов.
Это у вас там пасутся стада Minimum Viable Architectures (MVA), эволюционирующие вместе со своими продуктами. Это у вас запрещены архитектурные описания в виде документов, а архитектурой занимаются абсолютно все потому, что профессиональные архитекторы давно уволены и т.д.

У нас же сохранились архитекторы и архитектурные описания. И ADRs дополняют их, а не отменяют. И смена языка, на котором пишется приложения, в 99,9% случаев является архитектурно-значимым решениями. И замена одной реляционной базы данных на другую – тоже архитектурное решение. (В тексте это примеры трудно заменяемых, но не архитектурных решений). Думаю, ключевая ошибка авторов в том, что они сводят всю пользу архитектуры исключительно к гарантиям атрибутов качества. Что абсолютно не верно!

В принципе, текст то довольно насыщенный, а порой и интересный. Но разбирать его надо критически, цепляясь буквально за каждую фразу. Вот, например, на мой взгляд нельзя просто так взять и написать:
Architecture, then, establishes limits on the kinds of problems a system can solve, and even, sometimes, on the ability of developers to see different kinds of solutions by establishing a kind of hammer-nail blindness to alternatives.
Ну, т.е. написать можно, но тут же должна набежать толпа архитекторов решений и объяснить авторам, что архитекторы для того и существуют, чтоб помочь увидеть альтернативные решения тем, у кого взгляд почему-то замылился. А еще напомнить, что выбор конкретной реализации всегда лишает нас преимуществ отвергнутых альтернатив. Так что ограничиваем мы не область проблем, а пространство решений. Не потенциально возможных решений, а решений, воплощенных на практике.

В общем, кто еще из нас muddies the waters, такие как я читатели, или же авторы текста – вопрос открытый!

А вот вам старая (8.1.1) зато кликабельная версия и TOGAF ADM. Выбирать можно кружочки на картинке с тогафовской ромашкой слева или закладки справа.

Наслаждайтесь http://www.togaf.com/admref/admreference.html

Эшли Дэвис собрал в один текст все правильные мысли какие мог и про возрастание сложности, и про убывание отдачи от инвестиций и объединил их очевидным заголовком о том, что противопоставление монолита и микросервисов является ложным. https://www.infoq.com/articles/monolith-versus-microservices/

Кто-то должен был написать и опубликовать такой текст (лет пять назад) и вот он появился

Главной темой канала, как это следует из названия, является Архитектура ИТ-решений, т.е. Solution Architecture. Материалов по этой архитектурной практике не так уж и много. Из толстых книжек вспомнить стоит пожалуй только одну Introduction to Solution Architecture. Остальные, хоть и содержат в названии слово solution, написаны о чем-то другом. Часто это справедливо и для статей или сообщений в блогах

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

Вчерашнее обсуждение архитектуры решений (Solution Architecture) ожидаемо привело к обсуждению архитектуры предприятия (Enterprise Architecture, EA).

Напомню, что я посетовал на скудность материалов по архитектуре решений и как тут не вспомнить про их изобилие про архитектуру корпоративную. Может и не надо никаких специальных материалов по архитектуре решений и достаточно взять, например, TOGAF EA Practitioner's Guide где в разделах Walk Through Architecture to Support Project или Walk Through Architecture to Support Portfolio даны рекомендации по адаптации процесса разработки архитектуры для проекта и портфеля соответственно. Как думаете?

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

Нет в этом ничего удивительного. В архитектуре предприятия такому развитию событий способствует много вещей и, в частности, концепция архитектурного ландшафта (EA Landscape). Если мы заглянем в раздел 3.2.1 Introduction to the EA Landscape руководства TOGAF ADM Practitioners’ Guide, то узнаем про эту концепцию следующее:
- не существует единого описания архитектуры предприятия
- в любой момент времени типичное предприятия использует для решения своих задач различные по широте, детальности, времени достижения и актуальности описания (см. рисунок)
- каждый проект развивает ландшафт ограниченно, в необходимом для достижения целей проекта объеме
- ну, а EA Landscape представляет собой полный набор всех архитектурных описаний

Сконструирована эта концепция таким образом неслучайно. EA изначально была нацелена на то, чтоб не только стать инструментом идентификации и организации изменений на предприятии, но и объединить собой все прочие архитектуры

Archimate форум из The Open Group продолжает придумывать всякие разные инициативы. Месяц назад я про мультик рассказывал. Теперь вот они зовут в свое сообщество поделиться и пообсуждать паттерны: https://blog.opengroup.org/2023/11/21/the-archimate-patterns-library-what-is-it-and-how-to-contribute/

Ну как не поделиться такой веселой заметкой про Circuit-Breaker Pattern https://lab.scub.net/architecture-patterns-the-circuit-breaker-8f79280771f1

Похоже, тут новый манифест архитекторов появился. Последим за реакцией https://www.thefrugalarchitect.com/

Два видео в тему. Вчерашний кейноут собственно от Dr. Werner Vogels на AWS re:Invent 2023 на пару часов:
https://youtu.be/UTRBVPvzt9w и от Владимира Иванова на час покороче: https://youtu.be/yRkayvvzX7Q

После добавления новой фичи похожие каналы telegram обнаружил 74 канала, похожих на этот(посмотреть можно в свойствах). Не знаю, что с этим делать, но сами каналы, при случае, посмотрю

Excalidraw пытается рисовать диаграммы, описанные на русском языке начинающим промптером

Если вы любите большие пространные рассуждения про CAP теорему и согласованность данных в распределенных информационных системах, то длинный текст Марка Бёрджесса Deconstructing the `CAP theorem' for CM and DevOps безусловно для вас.

Со списком литературы и в двух частях:
Part 1: The Special Theory of Relativity for distributed systems
Part 2: The greatest distributed system of them all

Еще в октябре вышла новая книжка автора экстремального программирования Кента Бека Tidy First?: A Personal Exercise in Empirical Software Design
Книжка маленькая – 125 страниц. Практически, это набор из 33 небольших заметок, разбитых на три группы: tidyings, managing, theory. Но писал её Бек 3,5 года. А в прошлогоднем выступлении на QCon plus он рассказал, что это первая книга в серии из трех. Еще не вышедшие книжки расскажут о взаимодействии внутри разработчиков и разработчиков с заказчиками