Привет, Хабр! Меня зовут Игнатий Цукергохер, я фриланс-журналист и блогер. На Хабре в основном пишу про технику и выкладываю интервью, но решил вернуть рубрику обзоров мероприятий. И начну с такой камерной и при этом хардкорно-айтишной встречи, как True Tech Arch #8.

От корпоративной ИТ-архитектуры сегодня ждут скорости, устойчивости и понятной ценности для бизнеса, но она все еще часто существует в виде схем, презентаций и документов, которые быстро устаревают и мало помогают в ежедневной работе команд. На конференции True Tech Arch #8, последней встрече Гильдии архитекторов MWS в 2025 году, рассказывали, как выбраться из этого замкнутого круга.

В этом материале расскажу про основные темы, которые на ней поднимались: переход от Big Data к Small Data и Data Lakehouse, способы превратить архитектуру в исполняемую и измеряемую систему, а также изменение роли архитектора и коммуникаций между командами при внедрении AI-ассистентов.

Что такое True Tech Arch

True Tech Arch — это регулярные конференции, посвященные ИТ-архитектуре и ее проблемам. Каждое мероприятие состоит из практической части, докладов и традиционного нетворкинга. В этот раз за практическую часть отвечала облегченная версия Arch Kata. 

MWS представили Arch Kata c 2024 года. Это ИТ-игра, которая позволяет архитекторам, разработчикам, инженерам и другим айтишникам проверить свои силы: участники должны решить сложный бизнес-кейс, а эксперты MWS оценивают проект и дают подробный фидбэк, где хорошо, а где не очень. Цель игры — совершенствование архитектурного мышления. Разработчик думает в рамках своего модуля, а архитектор — на уровне всей системы. Более подробно MWS описали Arch Kata в отдельном материале. Естественно, в игре есть победители и те, кто еще будет ими. Ну а пока перейду к докладам.

«Data LakeHouse. Время перехода от Big Data к Small Data» от главного архитектора BigData MWS Сергея Королева

Сергей рассказал об эволюции архитектур данных в МТС и переходе к концепции Data Lakehouse. 

Для бизнеса главная ценность при работе с данными — какие инсайты можно из них извлечь. Ключевая метрика — это time to insight, то есть скорость принятия решений на основе данных.

У традиционного подхода есть серьезные проблемы: отсутствует единый интерфейс для работы с информацией, данные разбросаны по различным системам. Из-за этого приходится строить множество ETL-процессов и переливать данные из одной системы в другую. Главный недостаток такого подхода — трудоемкость работ по реализации интеграций. Это замедляет получение нужных инсайтов.

Data Lakehouse предлагает другое решение. В отличие от классического «озера данных», в Data Lakehouse четко выделены три слоя: слой compute, слой метаданных и слой хранилища. Основное преимущество Data Lakehouse заключается в интероперабельности. На одних и тех же данных в объектном хранилище можно использовать различные движки — например, Trino, Spark или StarRocks. Единый табличный формат позволяет любому движку работать с данными без дополнительных преобразований и перемещений.

В МТС внедряется собственное решение, а основной стек построен на Spark и StarRocks и собственном S3. При переходе к Data Lakehouse Spark остается ключевым движком для массивных вычислений. Важная особенность — это использование объектного хранилища S3 вместо блочного HDFS. 

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

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

Small Data

В объектном хранилище может храниться полный объем данных, но по-настоящему полезных из них не так много, а инсайты базируются на небольших выборках. Принципы Small Data:

• фокус на качестве данных, а не на их размере; 

• отказ от вычислительных кластеров там, где это возможно.

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

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

«Data-Driven Architecture: как перестать тушить пожары и начать двигать бизнес» от руководителя направления архитектуры в компании ВК-ИТ (бренд «Билайн») Дмитрия Дзюбы

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

Современные системы обработки данных очень сложны, и объяснить необходимость в таких решениях бизнесу бывает трудно. А еще они требуют больших инвестиций. В результате архитектура часто остается только на бумаге и не отражает реальное состояние систем.

Для решения этих задач в компании был выбран подход, основанный на трех принципах:

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

• Живая модель архитектуры, которая поддерживается в актуальном состоянии. 

• Автоматический контроль.

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

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

• Для телекоммуникаций: eTOM (Enhanced Telecom Operations Map) — стандарт TM Forum, описывающий бизнес-процессы.

• Для банков: BIAN (Banking Industry Architecture Network) — модель бизнес-сервисов и данных.

• Для страхования, ретейла, энергетики также есть свои фреймворки (ACORD, ARTS, IEC и другие).

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

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

Живая модель архитектуры строится на внедрении подхода Architecture As A Code. У ВКИТ для описания архитектуры берется классическая модель C4 Саймона Брауна. Система делится на контейнеры, которые выступают исполняемыми элементами. Дальше идут логические компоненты, включая API и технические возможности. К этому добавили модель развертывания. Вся информация хранится в виде графа, который позволяет анализировать влияние изменений в системах.

Благодаря такому подходу ВКИТ внедрила подход «архитектура как код». Команды описывают архитектуру в специальных репозиториях, которые публикуются через автоматические пайплайны. Для контроля используются фитнес-функции (этот термин был введен Нилом Фордом в работе об эволюционной архитектуре).

Сейчас для каждой системы проверяется больше тридцати фитнес-функций. В момент публикации можно увидеть, что спроектировано хорошо, а что требует внимания. Автоматически проводятся не только проверки качества архитектуры, но и контроль Architecture Drift (сверки архитектуры с реальной жизнь). Например, с интеграционной платформы снимается информация о том, какие сервисы опубликованы и как они работают. Эти данные сравниваются с описанием, и, если есть расхождения, архитектор может увидеть различия в характеристиках использования или обнаружить незадействованные сервисы. Сквозная видимость и предиктивный анализ на основе графовой модели архитектуры — ключевой функционал для управления сложностью. Инструмент обеспечивает понимание того, как изменение в одном элементе (например, в API микросервиса) повлияет на бизнес-возможности, процессы и другие системы. Это позволяет проактивно оценивать последствия новых релизов, снижать риски при интеграции и значительно сокращать время на планирование изменений и расследование инцидентов за счет мгновенного определения источника и области воздействия. Ключом к трансформации стала интенсивная работа по вовлечению и доказательству ценности, которая заняла около полугода стратегических сессий с руководством. Убедительным аргументом стал маппинг архитектурных проблем на бизнес-возможности, что позволило оценить их стоимость и приоритизировать изменения. Внедрение затрагивало не только архитектурные практики, но и все этапы производственного процесса, что помогло достичь комплексного эффекта. Благодаря этому внедрение охватило 30% систем, а успех подхода позволил компании рассмотреть его вывод на рынок как открытого решения. 

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

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

Система позволяет экономить время команд, устранять ошибки, связанные с человеческим фактором. Архитектор и вся продуктовая команда видят реальную пользу.

После общения с участниками конференции подтвердились идеи по дальнейшему развитию. Многие архитекторы отметили нехватку работы с версиями системы и информации по долгосрочным планам. Часто невозможно реализовать все сразу: планы могут растягиваться на месяцы или годы, их нужно фиксировать и соотносить с тем, как изменяются взаимосвязанные системы. Эти работы будут приоритизированы, особенно с учетом того, что люди из разных компаний сообщают о схожих проблемах. Некоторыми компонентами системы можно воспользоваться уже сейчас, так как они есть в открытом доступе: на GitHub и расширениях Visual Studio Code.

«Intent-Driven Architecture: как AI меняет роль архитектора и открывает путь к новым практикам» от ведущего архитектора MWS Александра Якунина

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

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

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

Для работы такой системы требуется несколько компонентов:

• Первый — это сам AI-ассистент на базе LLM. В качестве интерфейса можно использовать готовые решения, например OpenWebUI. 

• Второй компонент — это набор инструментов, которые позволяют ассистенту обращаться к разным источникам данных.

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

Процесс работы с AI-ассистентом выглядит так: архитектор формулирует запрос на естественном языке, а LLM обращается к инструментам и проверяет базу знаний. Если информации недостаточно, система идет в дополнительные источники через механизм RAG и потом формирует ответ.

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

Самым дорогим вариантом остается полное обучение модели. Более дешевый — взять готовую LLM от Microsoft, Anthropic или OpenAI и адаптировать через обучение на базе знаний. Можно использовать локальные версии моделей, но для этого также нужны мощности.

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

Один из способов оптимизации состоит в правильной организации данных. Размер контекстного окна ограничен, поэтому важно отбирать только релевантную информацию. Для этого используются алгоритмы ранжирования вроде BM25. Другим подходом может быть суммаризация контента. С этим хорошо справляется модель BERT. Но тут существует риск потери важных деталей.

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

Arch Kata

Кейс для задания подготовила команда MWS Data, и он был посвящен проектированию архитектуры Data Lakehouse для AI-агента службы поддержки облачного провайдера. При входе на конференцию можно было зарегистрировать команду и получить задание, причем команда могла состоять как из одного, так и из нескольких участников:

Организаторы рекомендовали перед началом решения обсудить вводные с экспертами MWS, присутствовавшими на конференции. Участникам рассказывали подробнее о кейсе, показывали ключевые пункты решения, отвечали на их вопросы. Ну и за победу были положены подарки. Эта часть понравилась участникам не менее (а может, и более), чем доклады. Потому что больше половины присутствующих с радостью участвовали в Arch Kata.

Нетворкинг

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

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

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

Дополнительно была высказана идея изменения формата Arch Kata в сторону практического задания по принципу хакатона, чтобы не только слушать готовые решения, но и совместно вырабатывать их на реальных системах.​

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

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