Привет, Хабр! Меня зовут Роман Стрекаловский, я корпоративный архитектор в «Столото». Мой первый рабочий день начался с экскурсии в лотерейный центр — место, где воплощаются мечты миллионов. Блестящие шары, гул вращающихся барабанов, атмосфера напряжённого ожидания — всё это производило сильное впечатление. Я сразу почувствовал: здесь живёт энергия, которая двигает бизнес.
Но когда я заглянул «под капот» — в ИТ‑ландшафт компании, — меня ждало ещё более интересное открытие. Передо мной оказалась сложная, многолетняя экосистема: более 500 систем, выросших вместе с бизнесом, монолиты, сплетённые самописными интеграциями, и процессы, в которых ключевую роль играл опыт инженеров. Запуск нового решения мог занимать до года, а создание новой игры — требовать ручного внесения данных в десяток разных систем.
Это был классический техдолг, порожденный быстрым развитием. И перед командной архитекторов стояла увлекательная задача: не просто модернизировать, а переосмыслить архитектуру, сохранив всё, что работает, и построив основу для будущего — быстрого, гибкого и масштабируемого. Впереди нас ждали не только технические, но и глубокие организационные, а иногда и человеческие трансформации.
И я хочу поделиться этой историей с вами.
Но сначала — немного контекста. «Столото» — крупнейший распространитель государственных лотерей в РФ. Организаторами этих лотерей выступают Министерство финансов РФ и Министерство спорта РФ. На базе собственной платформы ежедневно проводится почти 600 лотерейных розыгрышей, а участникам выплачивается в среднем более 500 тысяч выигрышей в сутки. Лотерейный IT‑ландшафт очень похож на IT‑ландшафт любого крупного финансового института
Именно эта масштабная и ответственная инфраструктура и стала отправной точкой нашей архитектурной трансформации.
Но что такое Enterprise‑архитектура и почему её так часто не любят?
Простым языком, если обычный архитектор или разработчик смотрит на отдельный дом — выбирает кирпичи, планирует комнаты, — то Enterprise‑архитектор (EA) смотрит на весь город сразу. Его задача — спланировать, где проложить дороги, где построить электростанцию, а где оставить место для парка, чтобы город мог расти и развиваться без пробок и Чернобылей.
Казалось бы, полезно? Но именно это и вызывает отторжение:
Она «медленная» и «абстрактная». Пока EA рисует схемы и пишет стратегии, бизнес кричит «нам нужно вчера!», а разработчики хотят кодить, а не заполнять каталоги. Её ценность — в предотвращении катастроф и экономии миллионов через год — неочевидна в режиме «тушим пожар сегодня».
Она ограничивает. EA говорит «давайте использовать вот этот стандартный кирпич, а не тот, который вы нашли на AliExpress». Для команды это выглядит как диктат и убийство креатива. Хотя на самом деле — это попытка избежать будущего кошмара поддержки 100 500 видов уникальных кирпичей.
Она требует дисциплины. Легко работать как угорелый, создавая костыли на героизме. Гораздо сложнее тратить время на проектирование, согласование и документирование. EA пытается внести порядок, а порядок — это всегда поначалу скучно и сложно.
В «Столото» нам предстояло не просто построить новые системы. Нам нужно было сначала убедить всех, что нам нужен генеральный план всего «города», и что его создание — не бюрократия, а инвестиция в будущее, которое не рухнет в следующий крупный тираж.
Теперь план: как всё упорядочить? Мы избрали стратегию долгосрочных инвестиций в фундамент, а не в сиюминутные победы. Мы осознали, что точечные решения лишь усугубляют хаос. Вместо этого мы сделали ставку на трех китов:
Политика и стандарты — новый «Свод правил». Мы прекратили споры о технологиях на уровне мнений. Вместо этого мы начали создавать общекорпоративные политики и стандарты. Это не было диктатом «сверху». Это были правила игры, принятые вместе с ключевыми техническими лидерами:
Стандарты кодирования: чтобы код разных команд выглядел и работал предсказуемо.
Стандарты интеграций: чтобы системы общались единообразно, а не через «костыли».
Политика управления данными: чтобы данные стали активом, а не проблемой. Эти документы стали нашей «технической конституцией», к которой мы могли апеллировать.
Инвестиции в стратегию, а не только в проекты. Мы договорились с бизнесом, что выделяем ресурсы не только на фичи, но и на архитектурную проработку. Это была сложная дискуссия, но мы научились говорить на языке бизнеса:
Типичный запрос от IT: «Нам нужно 3 месяца на проектирование».
Правильный запрос на языке бизнеса: «Если мы потратим 3 месяца на проектирование, мы снизим риск срыва запуска на 70% и сэкономим 40% бюджета на поддержку в будущем». Мы стали инвестировать в снижение будущих издержек и рисков, а не только в немедленную прибыль.
Фокус на цели цифровой трансформации. Все наши действия мы стали проверять на соответствие главным целям:
Гибкость: можем ли мы быстрее выводить новые продукты?
Масштабируемость: выдержит ли система пиковые нагрузки?
Скорость изменений: можем ли мы деплоить чаще и без инцидентов?
Однако, чтобы эти цели перестали быть лозунгами, мы перевели их в конкретные измеримые характеристики и — что критически важно — закрепили за ними четкое распределение ресурсов:
40% усилий — Доступность и устойчивость систем (прямая реализация масштабируемости).
30% усилий — Бизнес‑фичи (инструмент для достижения гибкости).
20% усилий — Спецзадачи и практики команд (фундамент для скорости изменений).
10% усилий — Технический долг (обслуживание всего пер��численного выше).
Теперь любое решение — от выбора технологии до организационного изменения — должно было не просто «работать на трансформацию», а вносить конкретный вклад в одну из этих измеримых характеристик с понятным весом в общем балансе ресурсов.
Этот триединый подход — политики, стратегические инвестиции, фокус на трансформации — и стал нашим планом по наведению порядка. Мы перестали тушить пожары и начали проектировать систему противопожарной безопасности для всего ИТ‑ландшафта.
Но обо все по порядку.
Часть 1: Диагноз: Федеративное устройство и управленческий хаос
Анализ показал, что проблема была не только в технологиях, но и в организации работы:
Федеративное устройство ИТ: отдельные команды и центры разработки работали изолированно, порождая сырые и несогласованные решения.
Отсутствие процессов и стандартов: не было единых правил игры — каждая команда выбирала стек и подходы под себя.
Сложность развития: ландшафт был настолько запутанным, что каждое изменение напоминало уход за старым, разросшимся садом — высокие риски и непредсказуемые последствия.
Проблемы на старте:
Организационное сопротивление: Команды, годами работавшие автономно, восприняли попытки стандартизации как посягательство на их независимость и недоверие к их экспертизе. Лозунгом было «Мы и так знаем, как лучше для нашего продукта».
Консервативность мышления: Многие сотрудники, работавшие с момента основания компании, были глубокими экспертами в своих узких областях, но с подозрением относились к новым «абстрактным» методологиям вроде TOGAF. Их главный аргумент: «Раньше мы без этого прекрасно обходились и бизнес рос».
Нехватка ресурсов: Бизнес‑заказчики ждали новые фичи, а не «какие‑то там архитектурные красоты». Выделить время разработчиков на описание систем, а не на создание новой функциональности было крайне сложно.
Наша цель заключалась не просто в том, чтобы «переписать всё на микросервисах», а в проведении полной трансформации управления ИТ-активами. За основу мы взяли методологию TOGAF и лучшие мировые практики, чтобы построить процессы и стандарты, отвечающие ключевым бизнес-целям. TOGAF предоставил нам универсальный язык и четкую структуру для работы с архитектурой. А общепризнанные референтные модели архитектурных доменов – такие как «Розница», «Финансы», «HR» и другие – стали практическим инструментом: готовыми шаблонами, которые мы адаптировали под свои процессы. Это позволило избежать разработки архитектуры «с нуля» и сразу ориентироваться на проверенные, отраслевые решения.
Часть 2: Стратегия: «Сначала учёт, потом развитие». Битва за данные
Мы отказались от революционного подхода. Вместо этого мы начали с фундамента — наведения порядка в данных об ИТ‑активах. Наш принцип: «Нельзя автоматизировать хаос».
Шаг 1. Учёт информационных систем и интеграций
Мы начали с описи всего, что есть. Для этого мы ответили на ключевые вопросы по каждой системе.
Базовые вопросы для учёта:
Кто владеет системой? — Бизнес‑владелец обосновывает бизнес‑ценность, формирует бизнес‑требования.
Кто отвечает за работоспособность систему? — Технический владелец отвечает за соответствие системы бизнес требованиям, её разработку, развитие и эксплуатацию.
Зачем она бизнесу? — Какую бизнес‑функцию или процесс она поддерживает.
Зачем она ИТ? — Её роль в общем ландшафте (например, является ли системой записи или обслуживает интеграции).
Как она вводится и выводится из эксплуатации? — Понимание сложности интеграции и вывода из эксплуатации.
Вопросы для анализа состояния:
Какие технологии использует? — ПО, фреймворки, базы данных.
С кем интегрируется? — Карта интеграционных взаимодействий (логика, транспорт, сценарии).
Какие данные обрабатывает? — Критичность данных, требования к безопасности и согласованности.
С какими проблемами столкнулись?
«Можно же спросить у разработчиков»: Самая частая отмашка. Люди не понимали, зачем тратить время на формализацию того, что «и так в головах». Приходилось раз за разом объяснять, что скорость принятия решений в масштабах 500+ систем невозможна без единого источника правды.
Проблема владения: Выяснение настоящего бизнес‑ или ИТ‑владельца системы часто превращалось в детектив. Никто не хотел брать на себя ответственность за legacy, особенно если его создатели уже ушли из компании.
Нехватка инструментов: Первые месяцы учёт вели вручную в таблицах, что было муторно и вызывало справедливое недовольство команд.
Этот процесс позволил нам превратить хаотичное нагромождение систем в стандартизированную и читаемую архитектуру, относительно которой можно было проводить анализ, оценивать риски и принимать обоснованные решения. Делать это коллегиально, учитывая мнение всего IT.
Шаг 2. Учёт технологий
Следующим уровнем стал технологический радар. Как мы его создавали и чем руководствовались:
Принцип четырёх квадрантов
Мы разделили все технологии по классической модели:
Adopt (Внедрять) — проверенные технологии, ставшие новым стандартом.
Trial (Пробовать) — перспективные новинки для пилотных проектов.
Assess (Оценивать) — новые технологии для изучения.
Hold (Ограничивать) — устаревшие или проблемные решения.
Процесс формирования — коллегиальный
Радар создавался не архитекторами в вакууме, а Техническим советом с участием ключевых тимлидов и инженеров. Каждое решение проходило защиту с кейсами и метриками.
Особенности нашего подхода:
Привязка к жизненному циклу: для каждой техн��логии определяли её текущую степень адаптации по фреймфорку от ThoughtWorks: HOLD, ASSESS, TRIAL, ADOPT.
Интеграция с каталогом ИС — автоматическое добавление технологии на радар при внесении в реестр.
Регулярные пересмотры: стандарт определения технологии: класс, область применения, степень детализации и так далее
С какими проблемами столкнулись?
«Пусть разработчики разбираются»: Идея стандартизации технологий вызывала бурю протеста. Аргументы были разные: от «это убьёт креативность» до «эта новая библиотека нам не подходит, а ваша разрешённая — устарела».
Юридические и иные риски: обнаружили критические системы на старых версиях ПО, обновление которых было сложным и рискованным, особенно учитывая реалии санкций.
По итогу все управление технологиями стало частью управления IT ландшафтом, а внедрение новых технологий — осознанным, открытым и управляемым.
Шаг 3. Данные как продукт (Data as a Product)
Мы осознали, что данные — это актив. Это прозрение пришло после анализа нескольких болезненных кейсов:
Что заставило нас изменить подход:
«Стоимость некачественных данных» — когда маркетинг тратил недели на согласование отчётов из‑за разночтений в определении «активного игрока» в разных системах.
«Упущенная выгода» — невозможность быстро собрать единую картину по клиенту для персонализации предложений.
Требования регуляторов — нам важно предоставлять отчеты в государственные органы с максимально подробной детализацией и соответствием требованиям.
Как мы превратили данные в актив:
Внедрили политику управления данными
Использовали федеративный принцип управления, разделелили данные на домены,
Создали ролевую модель, включающую такие роли как: Data Owners (владельцы данных на стороне бизнеса) и Data Stewards (кураторы качества).
Разработали стандарты именования, классификации и качества данных.
Внедрили глоссарий бизнес‑терминов с чёткими определениями.
Ведётся внедрение каталога данных
Реализовали поиск по всем источникам: «где найти данные по продажам за сегодня?»
Добавили систему оценки качества данных и их актуальности.
Внедрили механизм обратной связи для улучшения метаданных.
3. Разрабатывается процесс перехода от наборов данных к дата‑продуктам
Вместо доступа к таблицам начали предоставлять данные, как продукт используя архитектуру Data Mesh, которая дает понимание и доверие к данным, с счет следующих принципов описания:
Кто владелец и какая ценность дата продукта,
Кто основной потребитель и сценарии использование дата продукта,
Какая архитектура данных и их критерии качества.
С какими проблемами столкнулись?
Культурный барьер: Бизнес‑пользователи не привыкли воспринимать данные как продукт. Они ждали волшебную кнопку «сделайте мне отчёт», не понимая, что для этого нужно сначала навести порядок в источниках.
«Это не моя работа»: Назначение ответственных за качество данных (Data Owners) на стороне бизнеса было одной из самых сложных организационных задач.
Внедрение практики управления данными — крайне важна для нашей компании: строгая отчетность, маркетинговые отчеты. Данная тема заслуживает будет описана в отдельной статье, а возможно и цикле статей.
Часть 3. Автоматизация и борьба с техдолгом
Только после того, как процессы были описаны и отлажены вручную, мы начали их автоматизировать.
С какими проблемами столкнулись?
Ошибка № 0: Попытка автоматизировать плохой процесс только умножает проблемы. Мы наступили на эти грабли несколько раз, пытаясь автоматизировать то, что сначала нужно было перепроектировать.
Девальвация термина «Техдолг»: для многих это было просто модное слово. Нам пришлось разработать систему оценки влияния техдолга на бизнес — переводить его в понятные менеджменту метрики: «поддержка этой системы стоит X рублей в месяц», «риск простоя во время розыгрыша — Y миллионов».
Приоритизация: битва за ресурсы между проектами, которые приносят новую выручку, и проектами, которые «всего лишь» снижают риски и будущие издержки. Без понятного языка денег и рисков мы бы её проиграли.
В итоге была разработана и принята методика управления техническим долгом, которая состояла из следующих классических этапов: выявление, оценка, исправление, профилактика. Команды довольно позитивно восприняли методику и были удивлены, что техническим долгом можно управлять и есть мировые практики и концепции работы с долгом.
Часть 4. Взгляд в будущее: AI в архитектуре
Ну и куда же без современных и уже частично доказавших свою эффективность технологий. Мы уже начали эксперименты с применением искусственного интеллекта. В планах следующие направления:
AI‑ассистент для работы с Confluence и внутренними документами
Умный поиск и классификация: вместо ручного пролистывания сотен страниц — семантический поиск по архитектурным решениям и шаблонам, а также нормативным документам компании, которые читают только тогда, когда возникают проблемы.
Автогенерация документации: ИИ анализирует код и автоматически создаёт черновики технической документации, экономя до 40% времени архитекторов.
AI для анализа архитектурных решений
Проверка на соответствие стандартам: ИИ проверяет предлагаемые решения против наших референтных моделей и архитектурных принципов.
Прогнозирование рисков: система анализирует аналогичные кейсы в истории и предсказывает потенциальные узкие места.
Автогенерация диаграмм: по техническому описанию создает схемы взаимодействия компонентов.
С какими проблемами сталкиваемся?
Скептицизм и завышенные ожидания: часть команды ждёт, что ИИ «заменит архитекторов», другая — не верит, что он может дать что‑то полезное. Важно держаться середины: ИИ как инструмент предварительного анализа, поиска, описания информации и контекста, а не замена экспертизы.
Качество данных: модели ИИ работают на данных. Если наш каталог и реестры неточны, то и выводы ИИ будут бесполезны. Это лучшая мотивация поддерживать наши данные в чистоте.
Заключение: Преодоление
Путь от хаоса к зрелости занял несколько лет. Главный наш результат — не идеальная архитектура, а управляемый и предсказуемый ИТ‑ландшафт.
Но главный вывод даже не технологический. Самые сложные вызовы оказались человеческими и организационными. Нам приходилось:
Ломать стереотипы и доказывать ценность архитектурного подхода снова и снова.
Находить общий язык между ветеранами компании, хранящими уникальную экспертизу, и новыми сотрудниками, приносящими свежие практики.
Постоянно продавать ценность изменений бизнесу на их языке — языке денег, рисков и скорости.
Этот путь показал, что основа успешной архитектуры — не в выборе между монолитом и микросервисами, а в системном подходе к управлению и готовности работать с людьми. Технический долг — это лишь симптом. Его корень почти всегда кроется в процессах и организационной культуре. И его оплата начинается с трудных разговоров, а не с написания кода.
