🛰 Максим Смирнов, ИТ-архитектор, автор и преподаватель учебных курсов, выступит на третьей конференции Systems Design Online с докладом на тему «Некоторые заблуждения об архитектуре предприятия»

Подробнее о докладе
Архитектура предприятия существует уже более 30 лет. За это время менялись решаемые этой дисциплиной задачи, развивались методы, модифицировались подходы и практики. Тем не менее многие до сих пор знакомы только с устаревшей версией архитектуры предприятия и не знают о тех серьезных изменениях, что произошли в ней недавно. Цель выступления Максима — актуализировать взгляд на архитектуру предприятия, разобрать типичные заблуждения и мифы о целях и методах этой дисциплины.

Подробнее о конференции здесь

Канал конференции @systems_design_online

#конференция@systems_education

🤖 Я обещаю не злоупотреблять публикацией текстов и прочих материалов, полностью или частично изготовленных при помощи ИИ.

Но этот эксперимент с DeepSeek мне показался интересным (да и выходные нынче). В общем, делюсь ссылкой на сообщение в блоге со сравнением вариантов воплощения одного слайда

📎 Какие бывают архитекторы

Может кому пригодится: https://generativeprogrammer.com/p/architecture-diagramming-tools-and

Записи выступлений ArchDays’24 появились и в VK Видео: https://vkvideo.ru/@archdaysconference/all
(ссылка для мобильного браузера)

С ноября прошлого года Eetu Niemi ведет довольно интенсивную рассылку Enterprise Architecture Transformation Большинство подобных рассылок “ломается” через пару-тройку выпусков, но в этом случае вышла уже пара десятков текстов об архитектуре предприятия, а рассылка остается на достаточно неплохом уровне

Разработчики SaaS инструмента для управления архитектурой предприятия Ardoq ответственно подошли к реализации записей архитектурных решений - ADR (см. Architecture Records Metamodel, Architecture Records: Purpose, Scope and Rationale). И хотя термин метамодель они используют немного по-своему, сам поход вполне адекватен.

В частности, Architecture Record у них представляет собой обобщение пяти разных вещей, включая традиционный ADR, паттерн, архитектурный стандарт, оценка соответствия, запрос на исключение. Архитектурные записи связаны с компонентами из традиционных архитектурных представлений (приложения, требования, персоны и пр.). Не знаю, насколько просто будет по таким связям строить отчеты (все ADRs связанные с некоторым компонентом и т.п.), но, на мой взгляд, примерно так решения и должны быть связаны с моделями

Вышла новая версия техрадара от ThoughtWorks Technology Radar и небольшой комментарий к нему Macro trends in the tech industry | April 2025. Раздел Beyond the AI spotlight дается авторам все сложнее. Тем не менее пару интересных вещей в текущей версии найти можно

В целом, инструмент отличный. А вот в части содержания я был бы рад ссылкам на альтернативные варианты. Кстати, ведь многие компании ведут свои версии техрадаров. Почему не публикуют?

Небанальная модель зрелости практик архитектуры предприятия от Святослава Котусева How Do Enterprise Architecture Practices Mature? (кому удобней в виде pdf-файла). Четыре этапа:
- от полного отсутствия архитектуры(0)
- через архитектуру решений(1) и
- архитектуру ИТ(2)
- к настоящей архитектуре предприятия(3)

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

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

А вот тут собраны ссылки на другие радары: 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

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