Блог Сергея Баранова об ИТ-стратегии, архитектуре и организационном развитии

Я вот чего не понимаю, про ИИ же кучу всего можно интересного рассказать. Вот на вскидку только с инфраструктурным уклоном - Архитектура оркестрации агентов от LandGraph до Temporal. Или вот более теоретическая-академическая архитектура self improval system.…

Я вот чего не понимаю, про ИИ же кучу всего можно интересного рассказать. Вот на вскидку только с инфраструктурным уклоном - Архитектура оркестрации агентов от LandGraph до Temporal. Или вот более теоретическая-академическая архитектура self improval system. Ну на худой конец архитектура пайплайнов для предотвращения утечек данных и балансировки запросов к разным провайдерам для урезания костов - если хочется больше девопсятины и кибербеза. Чо все упарываются в беклоги, рефакторинги и спеки?... 🙁

В архитектурных этюдах новый кейс о наболевшем: https://t.me/archicases/9786/9787

Про фейл с моделью Чего сегодня рассказали, делюсь с разрешения 🙂 В общем, небольшой региональный банк, выдает кредиты, они в конце прошлого/начале этого года решили попробовать пропилотировать использование LLM модели для оценки заемшиков. В целом как пилот и затевалось, но мало ли, думали что может что-то из этого выйдет. Взяли подрядчика, подрядчик решил пойти по пути файнтьюна как я понял, не понял зачем, но ок. Дообучили на исторических данных, на всем корпусе данных что было, на приемке на синтентических данных показало 90-95% точности. В целом круто, конечно. В прод выводить не стали, страшно, но каждую заявку стали отдельно отправлять в модельку и потом сравнивать модель и какое решение система/аналитик приняли. В общем, точность у них упала до 60-70%, начали разбираться почему, разобраться - отдельный челлендж, непонятно же почему такие решения, а модель попробуй допроси. И на самом деле они там до сих пор не уверены в своих выводах, но основной вывод был такой, что дообучали на всех заявках, а заявки поступали и решения принимались в разные периоды времени - были и кризисы и рост и разный кредитный портфель по объему и риску, то есть куча факторов, которые влияли на скоринг не только с учетом риск-профиля заявителя, но и кредитных аппетитов и рисков банка (к слову вот этот контекст восстановить полностью так и не удалось, получается нужно вычислить «дифференциал» в каждой точке принятия решений по кредиту, ну или на каком-то отрезке, в течение которого условия были стабильными, до изменений, а кто эти изменения фиксирует, попробуй выясни, что там поменялось). А поделиться я захотел, потому что сам все время указывают на потребность в качественных данных и качественном представлении этих данных для того, чтобы модели могли нормально работать, но вот этот кейс завел меня в тупик. Получается, что мало самих данных, нужны и условия в которых эти данные были сформированы, а как это получить - большой вопрос. У меня только два варианта как можно решить такую проблемы: • Сегментация данных по периодам стабильности (как написал в тексте выше), однако надо их как-то определить и определить точки перехода • Версионирование самих политик, без них как сегментировать не совсем понятно, в целом стоит видимо фиксировать под контролем версий все изменения в рамках принятых решений, чтобы собрать полный актуальный контекст в точке времени и в прошлом • Дополнять внешним контекстом (макроконтекстом) по отношению к компании, который имел влияние на принятие решения В Event Storming есть такая связка, что данные – это следствие решений, а не описание реальности само по себе. Получается, что модель, обученная только на данных, теряет причины, которые эти следствия сформировали, а это и есть та база, которая нужна модели, чтобы мы могли ее подпустить к принятию решений. Кстати, пока писал, подумал, что конкретно в решениям по кредитам это может быть решено (может кто-то так и делает), если вместе с заявкой, данными и решением сразу же сохранять в условном json весь тот контекст (условия), которыми руководствовались при принятии решения, хотя опять же, далеко не все доступно, макроситуация недоступна например. Ну и проблема не нова, в безопасности уже много лет система просто блокирует переводы, доступы, а почему - даже сам банк порой не знает и иногда не может узнать, но то безопасноть, совсем другое дело - операционные бизнес-процессы.

29 августа поделюсь наблюдениями про типовое и не типовое в архитектуре. Основная идея в том, что мы много чего себе можем понапридумывать, вообразив, что некая задача суперважная, суперсложная и вот нужно ее прям кропотливо спроектировать и никто такого раньше не делал, мы уникальные. А оказывается, что в индустрии для таких задач есть типовые решения и нетипового там по факту с гулькин нос. Или решаем мы суперсложную архитектурную задачу, а если разложить систему на косточки, оказывается, что ничего сложного там и нет и снова задача вполне себе типовая. Будет легкий и непринужденный доклад с примерами и мыслями для медитации над своими системами после :) https://meetup.tbank.ru/conference/jvm-day/

Вышел Qwen 3.8 https://qwen.ai/blog?id=qwen3.8 2.4T parameters (95B active), with open weights releasing next week

Как-то так вышло, что я здесь ни разу не упомянул про ATRAF, хотя уже почти год, как применяю. Это фреймворк оценки архитектуры, у которого под капотом три метода. Читать тут: https://arxiv.org/abs/2505.00688 Сейчас со временем напряженно, но могу сделать вебинар, где рассказать и показать, если это кому-то нужно. Кто-то вообще использует формальные методы оценки архитектуры?

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

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

Research Insights Made Simple #25: почему AI-copilot архитектора всё ещё не получился (Рубрика #Architecture) AI уже умеет предложить архитектурный паттерн, сформировать ADR и нарисовать убедительную диаграмму. Но умеет ли он удерживать историю решений, ограничения…

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

Окончательно оформилась мысль о важности инженера в разработке и обещаниям ИИ. Итак, инженеры в текущей парадигме никуда не денутся. Пока, по крайней мере. За год не делись и не денутся. Сейчас пришло похмелье от LLM и стало понятно, что хоть мы и научились писать код быстро, это, видимо, никогда не было ключевым ограничением. Я выше как-то писал, что у меня было несколько проектов по возвращению «микросервисов» в нормальный модульный монолит там, где распределенная система не нужна, потому что когда на сцену выходит ее величество экономика и компании начинают считать деньги, избыточная, не нужная в заданном контексте сложность, оказывается неподъемно дорогой. Скоро ждем того же с вайбкодом и тут куда больше аргументов. 1. Развивать и поддерживать важнее, чем просто сделать. Наведенные неконтролируемые ошибки то тут, то там - это половина беды. Без модульности, без использования паттернов проектирования каждое следующее изменение становится дороже. В пределе каждое изменение может начать стоить как самолет, просто потому что продукт станет сложным и потребуется больше итераций и чтобы внести изменение и чтобы стабилизировать. 2. NFR развиваются во времени. Сегодня требуется 100 rps, через год 10000 rps и соблюдение десятка новых требований регулятора. И мультитенант. Я не представляю, как не инженер даже сформулирует такую задачу, а если понимает, то как и куда внесет изменения, если не понимает логику того, как сформировалось текущее решение. А логика формирования решения - это не промты, это понимание причинно-следственных связей и компромиссов при принятии решений. Дело в том, что иногда нужно пересобрать решение, а не дополнить его, для того и существует, например, рефакторинг - мы не можем в будущее заглянуть, поэтому каждое решение может вносить по-немногу эрозию в архитектуру и она просто может стать непригодной под новые условия. 3. Экономика, - пока непонятно как держать под контролем. Зависимость от LLM - это мощный вендорлок. Успешный продукт, много пользователей, обязательства. И вот стоимость токенов разом становится x10. Понятно, что этим риском можно управлять, но все же, ситуация не гипотетическая, - дорабатывать становится экономически не целесообразно, обязательства перед клиентами остаются, компетенция для развития на ручнике не сформировалась, - как минимум нужна страховка либо в виде людей, либо локальных моделей, все это увеличивает затраты 4. Самое мое любимое - как будто код мы теперь и правда можем писать быстрее, но не сильно заметно, чтобы это породило много добавленной стоимости/ценности, может и не там было ключевое ограничение. Инженерия - она ведь про решение прикладных задач эффективным способом, а не про написание кода. Пока разработчик писал код, он понимал задачу лучше, мысли упорядочивались, обретали структуру и понимание проблемы. Часто во время разработки. Теперь нужно это вынести вперед, до написания кода. А это мощный сдвиг для всей индустрии - это своего рода легитимизация всей той парадигмы, которую должен был agile привнести - решеное бизнес-задач с помощью ИТ, не написание кода, а решение бизнес-задач. То есть полное понимание того, что и зачем мы делаем, как мы это делаем еще до того, как приступить к написанию кода. А это всегда было очень сложно, потому и появились и TDD и непрерывная интеграция (как процесс). Качество дизайна подтверждается рабочим решением и нам еще предстоит перестроить свое понимание этого тезиса, а пока уверен, что сильные инженеры будут цениться все сильнее, иначе мы получим сотни тысяч решений, которые не работают или перестанут работать как только станут хоть сколько-нибудь популярными. Наблюдаем, участвуем, формируем вместе будущее отрасли 🤝

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://t.me/blog_sb. Рекомендую подписаться, если вам интересна архитектура не как набор диаграмм, а как работа с системами, организациями и решениями. На самом стриму мы обсудим: - Где AI уже полезен и почему лучше всего выглядят узкие задачи с измеримым контуром проверки; - Почему диаграмма, ADR или список паттернов ещё не складываются в архитектурное решение; - Что benchmark’и 2026 года говорят о способности моделей связывать требования, компоненты и trade-offs; - Какой фундамент нужен настоящему copilot архитектора: живая связь требований, решений, кода и телеметрии — и ответственность человека за итоговый выбор. Сегодняшний AI в основном работает со статическим снимком, тогда как архитектура живёт в истории системы. Поэтому поговорим не только о моделях, но и о traceability, архитектурной базе знаний, метриках и роли архитектора. Для меня главный вопрос выпуска практический: если по изменению требования нельзя восстановить затронутые ADR, код и runtime-сигналы, сможет ли AI сделать что-то большее, чем красивый снимок? #Architecture #AI #AI4SDLC #Engineering #Research #Software

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

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

Как должны выглядить ИТ-стратегия? Ложится ли она на 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 публичны и доступны всей компании и явно запретил привязывать цели к деньгам (бонусам, премиям). То есть это больше культурная история.

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

Я помню, как в 90-е в Казахстане, в городе Аксу (ранее - Ермак) сжигали на заводе старые деньги. Вот примернно так же было последний год с ИИ. Уже столько раз рассказал этот кейс, что оставлю здесь, чтобы делиться ссылкой. На прошлых выходных сначала, по обычному плану от опуса, сгенерил проект и внесение одного изменения кодексом обошлось в 6.5 млн токенов. Затем сделал по уму - построил модель предметки, задал архитектурные принципы, сформулировал границы в терминах карты контекстов, распределил требования на 17 модулей, сказал, что должен быть модульный монолит. На все - часа 4. Затем взял SPDD и провел требования до уровня Structured Prompt. Еще раз собрал проект кодексом. Затем попросил то же изменение применить, что и в первом варианте - 70к токенов. Умножаем на средний размер бэклога и переводим токены в деньги. Получается, что суровая инженерия стала только важнее, иначе это карго культ и те самые печи, в которых люди сжигают деньги. А почему вообще так получилось? Без описания предметной области, границ, декомпозиции и прочего модель вынуждена сама додумывать что ей делать. Помимо этого она строит среднее решение, не использует паттерны (изоляция сложности), не использует уникальные для этой области границы. Она же не берет за референс что-то конкретное, она обучена на огромном корпусе данных. Получаем рабочее решение, которое развивать и поддерживать возможно, но дорого. Просто люди это делали долго и поэтому было дорого, а нейронка делает быстро, но стоит так же дорого. Просто единицей тарификации стало не время, а объем.

Не могу не поделиться :) Лет 10 назад я выступал на небольшой конференции в EPAM, выступление было что-то вроде «Нужен ли архитектор в agile?» и я тогда словил достаточно хейта за модель доменной, социальной и технологической сложности. Ну словил и словил, все равно эмпирически она все эти годы меня не подводила, в январе статью написал на Хабре, ну потому что работает же: https://habr.com/ru/articles/985914/ И каким же было мое удивление спустя 10 лет увидеть это, чуть в иной формулировке, в стандарте O-AA (Open Agile Architecture Standard) Version 2.0 от OpenGroup. Так что кто у меня учился еще тогда на Agile Architecture, – вы лет на 10 опередили Opengroup :)