Я тут новый (?) термин придумал – цепочка поставки зрелости 🙂

А конкретно сейчас в ней как-будто бы разрыв.

В середине ноября в одном обсуждении я вкинул такую мысль: «Мои наблюдения показывают, что использование AI в структурированном PDLC увеличивает потребность в Senior/Architect, но Junior-позиции непонятно как пристроить, потому что как раз Junior-задачи AI закрывает полностью, при этом без Senior-экспертизы AI PDLC разваливается (у всех, в мире), если требуется развитие. А проблема тут в том, что где брать Senior’ов и архов, если входная точка не актуальна. Это интересный вызов.»

Мы как-будто убрали из уравнения экономическую целесообразность Junior-роли, но не убрали необходимость взращивать экспертизу. А раз потребность есть, то должно быть какое-то объяснение. И кажется оно у меня появилось, но пока только на половину. Junior позиция должна измениться в восприятии и стать инвестиции в возможность компании воспроизводить будущие Senior Capabilities.

При этом сюда хорошо встраивается старый-добрый цикл наработки архитектурного опыта: решил->сделал->получил последствия->разобрал->улучшил.

Меня все не отпускает мысль сделать что-то вроде школы, где на проектах, возможно в рамках конкретной компании, быстро (ну как быстро – год минимум) поднять уровень Junior. Тут меняется целевая модель, например, знать код уже не так критично, а может и вообще не нужно будет.

Думаю попробовать в качестве эксперимента, если есть желающие попробовать хотя бы сделать первый шаг, напишите мне в личку @sergey486, встретимся, обсудим, на повестке будет три вопроса:
1. Какие задачи AI уже закрыл?
2. В каких задачах Senior/Arch-роли стали «бутылочным горлышком»?
3. Какие компетенции нужны будущим Senior-специалистам?

Как вы понимаете, вопросы взаимосвязаны. Встреча ни к чему не обязывает, в крайнем случае просто с пользой пообщаемся.

Просьба писать тем, у кого есть содержательный ответ на первый вопрос, если AI у вас никакие задачи не закрывает, то смысла не будет, без прикладного опыта строить карту развития будущих Senior – это просто помечтать 🙂

1/3

Попалась статья про переход компаний к облачным стратегиям с акцентом на технологический суверенитет и снижение геополитических рисков:
https://siliconangle.com/2026/04/24/geopolitical-pressures-ai-initiatives-drive-enterprise-adoption-sovereign-first-cloud-strategy/

Статья, на мой взгляд, важна тем, что фиксирует заметное изменение настроений среди enterprise-клиентов. В статье данные опроса 3700 тех. руководителей из 21 страны и 83% из них отметили, что важность технологического суверенитета них серьезно возросла (на фоне геополитического давления). А 65% уже изменили свои облачные стратегии.

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

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

Так к чему я все это?

Примерно с начала года тоже думаю о том, что часть облачных сервисов, особенно в сегменте SaaS, может начать замещаться локальными или внутренними решениями. Не все сервисы, конечно. Нельзя смешивать условную CRM, багтрекинг, wiki или helpdesk с инфраструктурой для AI, глобальным CDN или эластичным вычислениями. Разные классы систем с разной экономикой.

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

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

Однако, выше - подводка, написать я решил, потому что увидел четкие очертания рисков самой SaaS/Cloud-модели и в свете вышесказанного далеко не нулевую вероятность реализации этих рисков.

2/3

Первый риск про Паретто-распределение, что-то вроде 80% приносят 20% компаний и когда они уходят становится неприятно. Вдвойне же неприятно, когда они всем довольны и счастливы, им твой сервис приносит радость и счастье, но - теперь они так умеют сами.

Конечно, это не универсальное правило для всех облачных сервисов, но риск существует, особенно у нишевых SaaS-провайдеров и B2B-платформ, ориентированных на крупный бизнес.

Таким образом, возвращаясь к тексту выше, если несколько крупнейших клиентов уходят в in-house, приватные облака, self-hosted или к локальным поставщикам, экономика конкретного SaaS-сервиса может резко ухудшиться. Вообще не обязательно, что сразу банкротство, возможны варианты:
• повышение цен
• сокращение бесплатных тарифов
• урезание функций (особенно с высоким расходом того, за что платишь IaaS, вроде вычислений, хранения, передачи)
• продажа бизнеса
• сокращение инфраструктурных расходов
• изменение продуктовой стратегии

Тем не менее это важный риск и для архитекторов и для ИТ-стратегии, да и в целом для многих. Ныне массовый и устойчивый сервис может изменить условия, закрыть ваш тариф, ухудшить поддержку или вообще прекратить работу. И мы это уже видели с AI-сервисами, причем и с самыми крупными в этом году 🙂

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

Сервисам на заметку - если каждый клиент уникален и не получает никакой выгоды от того, что на вашей платформе есть и другие клиенты, то уйти будет легко и просто (чем дальше - тем проще).

Второй риск исходит из экономики суверенитета. Пользоваться сервисов нельзя по закону, но и альтернатив нет. Компании и государства во всем мире все чаще обращают внимание на то, где хранятся данные, кто имеет к ним юридический доступ, в какой юрисдикции находится провайдер и может ли сервис быть ограничен из-за санкций, политического давления или решений самого поставщика. Можно адаптироваться через развертывание в локальных регионах, партнерства с нац. операторами, отдельные юр. структуры, это не моя область, но с точки зрения IT это означает фрагментацию облачной стратегии. Напомню - кто-то точно сделает свое и будет использовать in-house решения.

Почему второй риск вообще риск и причем тут альтернативы?
Обобщим: если есть зависимость части SaaS от крупных клиентов и рост требований к суверенности, то это бьет по самой сути облачной модели - она держится на масштабе:
• общая инфрастуктура
• общие сервисы
• мультитенантность
• централизованная разработка
• единая поддержка
• единый обновления
• и так далее

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

• Был один глобальный SaaS на 1000 клиентов
• Затем часть клиентов потребовала локальной юрисдикции
• В результате появилось 9 локальных сервисов по 100 клиентов
• Еще 100 клиентов ушли в in-house/self-hosted

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

3/3

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

Исходя из всего вышесказанного, считаю, что в корпоративные риск-модели теперь нужно закладывать не только классический риск вендорлока, но и несколько дополнительных сценариев:
• провайдер может быть заблокирован из-за санкций или политических решений (это уже наша обычная жизнь)
• доступ к сервису может быть ограничен из-за требований юрисдикции (и это наша обычная жизнь)
• провайдер может изменить условия обслуживания (а это обычная жизнь почти всех AI-сервисов, они ищут свою модель монетизации)
• сервис может закрыть нужный тариф или регион (вот недавно доступ к моделям закрывали)
• локальный провайдер может оказаться менее зрелым технологически (и им невозможно пользоваться)
• решение после миграции инхаус может оказаться дороже в сопровождении, чем ожидалось

Если развивать мысль дальше, то проблемы крупных SaaS-провайдеров теоретически могут повлиять и на инфраструктурных провайдеров, потому что многие SaaS работают поверх IaaS/PaaS глобальных облаков, однако здесь важно не преувеличивать. Для крупных провайдеров один или даже несколько SaaS-клиентов обычно не являются критическим источником выручки. Их бизнес диверсифицирован по отраслям, регионам и типам нагрузок. Поэтому массовое банкротство SaaS не обязательно ведет к серьезным проблемам у глобальных IaaS.

А вот для меньших инфраструктурных провайдеров или локальных облаков с высокой концентрацией клиентов такой риск может быть гораздо существеннее.

Обратная зависимость тоже важна, – если IaaS/PaaS-провайдер сталкивается с ограничениями, сбоями, регуляторными проблемами или финансовой нестабильностью, это может ударить по SaaS-сервисам, которые на нем построены. Именно поэтому важно смотреть не только на конкретный SaaS, но и на всю цепочку зависимостей: где он хостится, кто управляет инфраструктурой, где находятся данные и насколько быстро можно мигрировать.

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

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

Я сейчас сформулировал очень сложный вопрос в нейронку, многоступенчатый… и как интересно, – ответ на моей локальной Qwen3.6-35B-A3B-MTP-GGUF:UD-Q8_K_XL практически идентичен ответу Sonnet 5.0 в платном аккаунте Perplexity. При этом локальная модель отработала быстрее на пару порядков.

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

Я помню, как в 90-е в Казахстане, в городе Аксу (ранее - Ермак) сжигали на заводе старые деньги. Вот примернно так же было последний год с ИИ.

Уже столько раз рассказал этот кейс, что оставлю здесь, чтобы делиться ссылкой.

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

Затем сделал по уму - построил модель предметки, задал архитектурные принципы, сформулировал границы в терминах карты контекстов, распределил требования на 17 модулей, сказал, что должен быть модульный монолит. На все - часа 4.

Затем взял SPDD и провел требования до уровня Structured Prompt.

Еще раз собрал проект кодексом.

Затем попросил то же изменение применить, что и в первом варианте - 70к токенов.

Умножаем на средний размер бэклога и переводим токены в деньги.

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

А почему вообще так получилось?

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

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

Как EA занимаются своей работой без формальной подготовки по орг.дизайну?

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

Стоит начать с того, что если посмотреть на область работы EA, то оргдизайн выглядит в ее составе весьма органично, он, буквально, структурно должен входить в работу EA и если обратить внимание на то, что пишут EA и CIO/CTO на мировых площадках, то как основную задачу EA сейчас видят «перепроектировать операционные модели для федеративных, гибких организаций». Проблема в том, что даже TOGAF не содержит описаний теории оргдизайна.

В итоге, отвечая на вопрос и пообщавшись с EA, выяснил, что, в РФ пока еще единицы допускают к орг.дизайну, а в мире 14 человек из разных компаний мне ответили, что это входит в их задачи, но почти никто не учился специально, в основном набирались опыта из общения, через моделирование (об этом позже), через выявление паттернов в поведении (два человека так ответили).

Моя гипотеза исходя из общения в том, что при этом социальные и культурные аспекты вообще не учитываются, модели бездушны, а основные две модели, которые помогают строить орг дизайн - Capability Map и Value Stream Map. На западе многие всё, что знают об оргдизайне - это книга Team Topologies (правда, Team Topologies только про команды разработки, так что про организацию в целом это не дает представления). Про Минцберга никто и не слышал. Никто вообще =)

Business Capabilities - мощный инструмент, безусловно, но признанных методов выведения из них орг структуры пока нет. Даже в комбинации с Value Stream Map этого пока еще недостаточно для формирования целевой организационной структуры.

Если посмотреть на ситуацию с позиции описания предметной области, то явно есть пробелы:
• В EA не определен понятийный аппарат оргдзиайна, вроде модели Гэлбрэйта или Минцберга, социотехнических систем, моделей принятия решений, соответственно начинается - одни говорят о командах и потоках, другие о ролях и структурах и в рамках организации понятия не интегрируются в общую систему
• Отсутствует методологический аппарат вывода оргструктры из инструментария EA - Capability Map и иных артефактов
• EA фреймворки, предоставляющие базовый, широкий уровень образования направлен на IT и стратегию, но не на оргдизайн

Как мне кажется, в такой ситуации, если EA без формальной подготовки в оргдизайне берется за оргдизайн, то чаще:
• Структура следует за системами (не за стратегией)
• Соц и культурные аспекты не учитываются
• EA-команды становятся непонятными для бизнеса, отчасти потому, что не говорят на языке орг изменений

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

Как должны выглядить ИТ-стратегия? Ложится ли она на OKR-методологию?

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

ИТ-стратегия – это структурированный документ и управленческий процесс, связывающий технологические инвестиции с бизнес-целями организации. Обеспечивает выравнивание ИТ-инициатив с бизнес-целями, включая стратегическое планирование, оценку технологий, управление рисками и управление производительностью (в орг смысле).
OKR - это методология постановки целей, механизм исполнения стратегии.

Исходя из определений, OKR служит инструментом операционализации стратегии. То есть стратегия задает направление, а OKR переводит направление в, зачастую квартальные, ориентиры. Совместить возможно, но тогда потребуется два уровне OKR - стратегический на уровне компании (North Star OKR) и тактический на уровне команд, однако все равно архитектурные принципы, управление техдолгом, инфраструктурные инвестиции и прочее подобное плохо ложится на OKR.

Если на очень высоком уровне взять ИТ-стратегию, то она состоит как минимум из:
• Видения и миссии, то есть куда движется ИТ-функция и какова ее роль в бизнесе (совешенно не праздные вопросы)
• Текущее состояние
• Целевое состояние
• Дорожная карта, а по сути - портфель проектов и инициатив с приоритетами
• Принципы управления (Governance)
• ИТ-риски
• Метрики и KPI (в хорошем смысле)
• Методы управления изменениями, то есть как изменения принимаются компанией и интегрируются в нее

Очевидно, что стратегия – первична и в OKR нет почти ничего из ИТ-стратегии. OKR в таком случае - это то, как стратегия каскадируется.

Однако, практика показывает, что у OKR есть минусы, которые сложно обойти:
1. Горизонты разные. Стратегия может быть построена на 3-5 лет, максимум известный мне горизонт OKR - 1 год (хотя ограничений нет)
2. В ИТ-стратегию могут быть заложены организация платформ, управление зависимостями, архитектурный рефакторинг, - это все сложно выразить через Key Results в OKR формате
3. OKR про прорывные, инновационные цели, в базовых книгах так и заложено - ставить амбициозную цель, достижение на 70% - успех. В ИТ многие задачи - операционные, как через OKR определить соответствие требованиям регулятора, выполнение SLA.. Здесь KPI подходят лучше. Да, к OKR прикрутили «commited OKR» c обязательным выполнением 100%, но имхо это костыль, теряется сам смысл OKR).

Исходя из этого процесс такой:
ИТ-стратегия -> Сбалансированная система показателей (стратегическая перспектива) -> Годовые OKR компании -> Квартальные OKR команд -> Agile-исполнение (чтобы не замедляться)

Резонный вопрос - что тогда на руководящих встречах обсуждает ИТ, если все смотрят на OKR? Два контура смотрят: стратегический, то есть что ИТ меняет ради бизнес-результата (OKR) и операционный/риск-контур через KPI - безопасность, надежность, вот все эти показатели.

KPI в таком ключе - условия допустимости стратегии. Если сервисы нестабильны, требования регулятора не соблюдены и так далее, то растут риски, а иногда и достигнутые OKR теряют смысл.

Тут важно понимать, что Гроув, автор OKR, в своей книге так и написал, что OKR - это он взял MBO Друкера, добавил Key Results (чтобы стало понятно как достигнать цели), ограничил цели пятью (то есть буквально - не более 5 Objectives - это строгое правило), ввел обязательное правило, что Objectives публичны и доступны всей компании и явно запретил привязывать цели к деньгам (бонусам, премиям). То есть это больше культурная история.

Ну что, видимо, пришла пора агента, который зайдет в Ютуб и в поисковой выдаче отфильтрует все тысячи сгенерированных по определенной теме видео. Причем я в целом не против сгенерированного, но у сгенерированного есть две важные особенности:
1. Если где-то в сгенерированном видео есть неточность/проблема, то попробуй еще перегенери - нейронка же генерит видео на основе исходного материала и это не детерминированный процесс (запросил A -> получил A), поправить готовое видео на N секунде - это прям отдельный челлендж. Поэтому никто не заморачивается. Ну вот есть пара-тройка-сотня неточностей, ну и ладно.
2. А часто это просто пайплайн. Берется материал, прогоняется по пайплайну и заливается. Никто не просматривает и не проверяет.

В чем ценность записи человека? Человек тоже может ошибаться, но ответственный человек выверяет что он доносит заранее и человеку проще поправить, перезаписать, записать уточнение, человек в том, что он доносит, обычно развивается, это процесс, человек развивает мысль со временем, подкрепляет примерами, а в примерах есть детали. Это, конечно, иделизированная картина, но по крайней мере стоимость внесения изменений при явных косяках в итогов видео ниже. Хотя кто знает… теперь многие стали экспертами во всем, а по сути - proxy между LLM и экраном.

Коллеги, какими средствами коммуникации пользуетесь, подскажите?

Не мало компаний перешло внутри на стэк ВК и Яндекс. Они не работают с тремя буквами. В макс никто не готов идти для обсуждения того, что составляет коммерческую тайну, - и сами не готовы и безопасность не разрешает. Получается, что телегу некоторые (многие) не могут зайти в течение дня. Внутрь пускать не все готовы.

В итоге коммуникация максимально перешла в почту, уронив эффективность (оперативность) коммуникации на несколько порядков.

Хочется решить эту проблему, но пока непонятно как, кроме как поднять собственный jabber.

Интересует именно рабочая коммуникация компаний с другими компаниями.

Research Insights Made Simple #25: почему AI-copilot архитектора всё ещё не получился (Рубрика #Architecture)

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

29 июля в 17:30 по Москве мы вместе с Сергеем Барановым разберём whitepaper "Artificial Intelligence Support for Software Architecture Practice" - систематический обзор 51 исследования об AI в работе software-архитектора, про который я уже писал раньше.

Сергей - практикующий архитектор, партнер Скрамтрека и основатель конференции ArchDays, в программный комитет которой я вхожу с первой конференции и до текущего момента. В общем, с Сергеем мы давно знакомы и я знаю, что беседа получится интересной. Также он пишет о технологиях, социотехнической архитектуре и организационном развитии в своём канале https://xn--r1a.website/blog_sb. Рекомендую подписаться, если вам интересна архитектура не как набор диаграмм, а как работа с системами, организациями и решениями.

На самом стриму мы обсудим:
- Где AI уже полезен и почему лучше всего выглядят узкие задачи с измеримым контуром проверки;
- Почему диаграмма, ADR или список паттернов ещё не складываются в архитектурное решение;
- Что benchmark’и 2026 года говорят о способности моделей связывать требования, компоненты и trade-offs;
- Какой фундамент нужен настоящему copilot архитектора: живая связь требований, решений, кода и телеметрии — и ответственность человека за итоговый выбор.

Сегодняшний AI в основном работает со статическим снимком, тогда как архитектура живёт в истории системы. Поэтому поговорим не только о моделях, но и о traceability, архитектурной базе знаний, метриках и роли архитектора.

Для меня главный вопрос выпуска практический: если по изменению требования нельзя восстановить затронутые ADR, код и runtime-сигналы, сможет ли AI сделать что-то большее, чем красивый снимок?

#Architecture #AI #AI4SDLC #Engineering #Research #Software

Окончательно оформилась мысль о важности инженера в разработке и обещаниям ИИ.

Итак, инженеры в текущей парадигме никуда не денутся. Пока, по крайней мере. За год не делись и не денутся. Сейчас пришло похмелье от LLM и стало понятно, что хоть мы и научились писать код быстро, это, видимо, никогда не было ключевым ограничением.

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

Скоро ждем того же с вайбкодом и тут куда больше аргументов.

1. Развивать и поддерживать важнее, чем просто сделать. Наведенные неконтролируемые ошибки то тут, то там - это половина беды. Без модульности, без использования паттернов проектирования каждое следующее изменение становится дороже. В пределе каждое изменение может начать стоить как самолет, просто потому что продукт станет сложным и потребуется больше итераций и чтобы внести изменение и чтобы стабилизировать.

2. NFR развиваются во времени. Сегодня требуется 100 rps, через год 10000 rps и соблюдение десятка новых требований регулятора. И мультитенант. Я не представляю, как не инженер даже сформулирует такую задачу, а если понимает, то как и куда внесет изменения, если не понимает логику того, как сформировалось текущее решение. А логика формирования решения - это не промты, это понимание причинно-следственных связей и компромиссов при принятии решений. Дело в том, что иногда нужно пересобрать решение, а не дополнить его, для того и существует, например, рефакторинг - мы не можем в будущее заглянуть, поэтому каждое решение может вносить по-немногу эрозию в архитектуру и она просто может стать непригодной под новые условия.

3. Экономика, - пока непонятно как держать под контролем. Зависимость от LLM - это мощный вендорлок. Успешный продукт, много пользователей, обязательства. И вот стоимость токенов разом становится x10. Понятно, что этим риском можно управлять, но все же, ситуация не гипотетическая, - дорабатывать становится экономически не целесообразно, обязательства перед клиентами остаются, компетенция для развития на ручнике не сформировалась, - как минимум нужна страховка либо в виде людей, либо локальных моделей, все это увеличивает затраты

4. Самое мое любимое - как будто код мы теперь и правда можем писать быстрее, но не сильно заметно, чтобы это породило много добавленной стоимости/ценности, может и не там было ключевое ограничение. Инженерия - она ведь про решение прикладных задач эффективным способом, а не про написание кода. Пока разработчик писал код, он понимал задачу лучше, мысли упорядочивались, обретали структуру и понимание проблемы. Часто во время разработки. Теперь нужно это вынести вперед, до написания кода. А это мощный сдвиг для всей индустрии - это своего рода легитимизация всей той парадигмы, которую должен был agile привнести - решеное бизнес-задач с помощью ИТ, не написание кода, а решение бизнес-задач. То есть полное понимание того, что и зачем мы делаем, как мы это делаем еще до того, как приступить к написанию кода. А это всегда было очень сложно, потому и появились и TDD и непрерывная интеграция (как процесс).


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

Наблюдаем, участвуем, формируем вместе будущее отрасли 🤝

Об ограниченных контекстах на базе корп курса по Event Storming + DDD + MSA.

Получилось полезное видео.

Прошла наша с Сашей Поломодовым встреча с разбором метаанализа по ИИ в архитектуре, а я хочу на фоне этого осветить кратко другую тему - почему архитектура плохо поддается научной проверке?

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

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

Усложняется все тем, что каждый продукт уникален в совокупности факторов, влияющих на его развитие.

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

Фредерик Брукс в свое время сфрмулировал такое качестве, как архитектурная целостность.

Это такой, слобо уловимый атрибут качества за счет своей абстрактности, практическое применение которого слабо уловимо, если не перейти в практическую плоскость.

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

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

Не могу не поделиться, настолько сильное недоумение у меня вызвало то, что сегодня произошло.

Дочь осваивает более сложные сценарии взаимодействия с техникой, в общем, клавиатуру осваивает.

И открыли мы для себя яндекс игры. К играм претензий нет. Но елки-палки, детские игры, для детей 3-5 лет, за 10 минут штук 50 рекламных вставок на весь экран и справа вот эти как на скрине. Дочь, конечно промахивается и периодически кликает. Я не знаю, кто там кому за что платит, но для меня это выглядит НААСТООЛЬКО странно…

Я, кстати, про примерно 50 рекламных вставок за 10 минут как бы даже преуменьшил.

Дочери предлагали купить квартиру, сходить в ресторан, улететь во все города страны, чего-там только не было. Правда, она еще читать не умеет даже и игры мы выбирали детские… не понимаю что такая реклама может дать, кроме повышения статистики показов и кликов (а вот тут как раз еще как может дать, прям оооочень дать :))))

Я если что не ворчу, искренне не понял логику.

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

Это фреймворк оценки архитектуры, у которого под капотом три метода.

Читать тут: https://arxiv.org/abs/2505.00688

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

Вышел Qwen 3.8
https://qwen.ai/blog?id=qwen3.8

2.4T parameters (95B active), with open weights releasing next week