Несмотря на простуду провел вчера вебинар Как архитектура решений снижает сроки и стоимость реализации изменений Спасибо участникам вебинара, выдержавшим мой хрипящий голос в течении 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

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