А вот тут собраны ссылки на другие радары: https://github.com/lotharschulz/awesome-techradar

Я не пишу про AI, а вот Кент Бек пишет: Social AI Adoption: Lessons from Hybrid Corn Причем, в отличии от книг, которые у него получаются в последнее время очень лаконичными, статьи выходят вполне себе развернутыми

Да и пишет он не столько про AI и не про то, как CEO Shopify пытается перезагрузить поведение сотрудников, а скорее о том, что процесс принятия технологий - явление социальное. Не технологическое, даже не экономическое, а именно социальное. Пусть и на примере гибридной кукурузы (про кукурузу и логистическую S-кривую здесь).
Почитайте кому интересно

Да вы что?! :-) Зеленое ПО и ячеистая архитектура в трендах InfoQ Software Architecture and Design Trends Report - 2025

Кстати, я бы пообсуждал пару вопросов вокруг этого отчета. Но, наверное, должен еще выйти подкаст. Нельзя же ведь просто так написать на картинке слова и по части из фраз бросить пару абзацев текста. Подождем!

Update: Подкаст тоже появился https://www.infoq.com/podcasts/infoq-architecture-trends-2025/

Несмотря на простуду провел вчера вебинар Как архитектура решений снижает сроки и стоимость реализации изменений Спасибо участникам вебинара, выдержавшим мой хрипящий голос в течении 1,5 часов

В конце 2016 года я написал в своем блоге текст про Тень цифрового будущего (или ИТ стратегия в переходный период) в котором посетовал, что проникновение в повседневную жизнь анонсированных инновации, почему-то, задерживается. В 2025 году уже очень многие отмечают, что разговоры о том, что вот-вот, уже очень скоро, буквально на днях произойдет нечто… В общем, такие разговоры совсем небезобидны.

Наверняка вы сталкивались с ситуацией, когда в ответ на те или иные текущие проблемы корпоративных информационных систем инициируется проект по внедрению какой-нибудь новой большой и хорошей системы вместо старой плохой. Опытные пользователи понимают, процесс этот может занять пару лет или больше, а результат его вряд ли будет отвечать ожиданиям хотя бы на треть. Но сделать они ничего не могут и вынуждены терпеть отвратительную работу системы еще несколько месяцев, чтоб затем убедиться, что в новом приложение все работает еще хуже, чем раньше. Айтишники, в принципе, все это тоже понимают, но обычно молчат. Нельзя же сказать, что наш CIO, анонсировавший в качестве проекта №1 внедрение нового CRM, например, или еще какую-нибудь дичь, мягко говоря, немного лукавит.

Подобные ситуации возникают и в других областях:

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

(С чего бы они будут лучше? Или вам сейчас нравится общаться с чат-ботами техподдержки и автоответчиками?)

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

Наверное, я не очень давно читаю блог CONFLUENT и потому не видел в нем стенограмм выступлений Мартина Клеппмана (автора книжки с кабанчиком). А их там несколько штук. Вот, например:
➡️ Выворачиваем базу данных наизнанку

Databases are global, shared, mutable state. That’s the way it has been since the 1960s, and no amount of NoSQL has changed that. However, most self-respecting developers have got rid of mutable global variables in their code long ago. So why do we tolerate databases as they are?

Копия транскрипта и ссылка на видео есть и на сайте Клеппмана. Да и весь его блог весьма познавателен

Я часто говорил, что известный текст Architectural Blueprints—The “4+1” View Model of Software Architecture, написанный Philippe Kruchten в 1995 году, никогда не переводился на русский язык.

Это не так. Недавно нашел в сети вот такой перевод Модель представлений программной архитектуры 4 + 1 в двух частях (продолжение здесь)

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

Кстати, очень подробное изложение подхода на русском здесь: Use-case 3.0: краткое руководство

Пропустил историю о том, как Нил Форд и Марк Ричардс занялись [пере]осмыслением темы Architecture as code. В феврале они провели подкаст в котором упомянули, что пишут новую книгу с тем же названием, а в конце июня собираются провести двухдневный курс Architecture as Code

В подкасте речь шла о разработке некоторого легковесного Architecture Description Language и комментариям почему это не model-driven architecture и как такой ADL поможет в разработке полезных фитнес-функций. Темы курса вроде бы несколько шире, но думаю речь пойдет примерно о том же. Возможно, термин architecture mesh из подкаста тоже всплывет.

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

Когда речь заходит о записях архитектурных решений (architecture decision records, ADR) часто возникает вопрос: где посмотреть реальный пример? Вот чтоб в проекте более-менее долго фиксировались решения, уточнялись, пересматривались и т.п.
... и тут все обычно начинают мяться, вспоминают про NDA

Из открытых проектов я бы предложил посмотреть как это ведется в NATS, см. NATS Architecture And Design Если у кого-то есть еще примеры, то непременно поделитесь, плз.

Все знают, что я люблю делиться стостраничными презентациями Алана Максуиней – автора первой толстой книжки о Solution Architecture. В июне он порадовал нас новым слайдсетом Application Of The Function- Behaviour-Structure (FBS) Design Framework To IT Architecture Designs на мой взгляд, и на этот раз есть на что посмотреть и над чем подумать

Поделюсь недавней заметкой Дика Доуделла Rethinking Technical Debt, основная идея которой в том, что техдолг является скорее системной проблемой, а не просто изъяном, возникающем при неправильной доработке кода. И решаем мы эту проблему неверными способами

Forget the metaphor for a second. Technical debt isn’t just a design compromise or a lack of refactoring time. It’s a structural imbalance that arises when systems evolve without coherent patterns.

Причины дисбаланса по мнению автора:
- чрезмерное увлечение «лучшими практиками». Agile церемонии, TDD, микросервисы, CQRS, dependency injection etc. не заменяют архитектуру. Нельзя исправить ошибки декомпозиции: правильное определение границ между компонентами и взаимодействий, улучшая то, что находится внутри компонент
- иерархические вызовы вместо разработки bindable (связываемые, подключаемые) компонент
- … и отсутствие "модерации сообщений" (отдельный текст Дика The Magic of Message Moderation)
- шараханье от единственного монолита к хаосу случайных микросервисов вместо развертывания, называемого автором service nodes. Я бы назвал это осмысленным развертыванием
...

Ну а заканчивает автор замечанием, что это не фантазия или мечта, а реализуемая его командой реальность и что The architecture resists debt by design

Подытожу: идея переосмыслить источники технического долга мне точно нравится

Предварительные итоги опроса (1204 голоса) с исправленной ошибкой :)

#архитектура

Выложили видосы по архитектуре с прошлых конференций

• Роман Цирульников - Основы архитектуры систем

• Максим Смирнов - Как показать ценность проектирования ИТ-решений

• Кирилл Ветчинкин - Как DDD и Event Storming помогает декомпозиции на сервисы

• Никита Ерилин - Где тонко, там порвётся: считаем нагрузку и подстилаем соломку

25 комментариев к предыдущим постам сообщали об использовании Archimate или удивлялись его отсутствию в опросе. Я думаю, что Archimate это вообще отдельная и разноплановая тема и её не надо смешивать c диаграммами. К тому же, TheOpenGroup как-то очень своеобразно развивает этот стандарт. С одной стороны, регулярно добавляет в него новые уровни и аспекты (хотя и Archimate версии 1.0 уже был перегружен идеями, и к 3-м версиям он вовсе не стал проще). С другой стороны, давая советы по усеченному использованию языка, например, для отрисовки представлений TOGAF.

В общем, может нам zoom пора провести на тему Archimate 2025? Давайте сделаем блицы: 5 минут на выступление + 5 на вопросы и комментарии. Я помодерирую. Кто готов выступить и уложиться в регламент – записывайтесь в комментарии к этому сообщению

Дата/время: 7 августа 19:00 MSK

Кстати, в конце июля появилось
... описание того, что должно стать следующей версией спецификации, а именно: ArchiMate® NEXT Specification, Snapshot 1 По ссылке список ожидаемых изменений и сам snapshot

С составом спикеров разговора об Archimate мы определились. Это:
- Artem Varkulevich
- ‎⁨Roman Tsirulnikov⁩
- ‎⁨Kirill Keker⁩
- ‎⁨Mikhail Zaborov⁩
- Alexander Chertilin, и я
- Maxim Smirnov⁩
а вот на темы разговора еще можно повлиять.

В комментариях к этому сообщению вы можете обозначить интересующие вас темы и задать вопросы спикерам

и, конечно, присоединяйтесь к зуму
📆 7 августа в 19:00 MSK
(ссылка будет в этом канале накануне)

📆 Уже завтра 7 августа в 19:00 MSK
поговорим об Archimate

Присоединяйтесь по ссылке:
https://us02web.zoom.us/j/87387272422?pwd=g8J2EBF7rt10bjbMCgftkZd9GhQDD9.1
Идентификатор конференции: 873 8727 2422
Код доступа: 329698

Запись тут
https://vkvideo.ru/video-228508670_456239021
https://youtu.be/Z2CzE9j5cu0

Чуть позже поделюсь материалами