Привет! Меня зовут Семен, я solution-архитектор в Газпромбанке. За девять лет в разработке я насмотрелся на одну проблему, которая встречается практически везде.

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

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

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

Ландшафт — это не только про серверы и Kubernetes

Когда мы говорим «ландшафт компании», обычно имеем в виду IT-инфраструктуру: серверы, кубер, докер и т. д. — все то, что мы так сильно любим. Но я всегда выступал против увеличения расстояния между IT и бизнесом — наоборот, пытался его сократить.

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

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

Разорванный ландшафт — когда бизнес-архитектура и IT-ландшафт существуют как независимые сущности. Но воспринимать их атомарно нельзя — это должно быть однонаправленное движение.

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

Как понять, что у вас ландшафт разорван

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

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

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

«Почему так долго? Мы думали, это на три дня»

Первая и главная проблема — бизнес не понимает мощностей IT. Эстимации сложности у бизнеса и разработки кардинально разные. Бизнес думает, что на задачу нужно три дня, коммитится, согласовывает бюджеты, а IT отвечает: «Ребята, извините, мы так быстро не можем».

Когда возникает условная идея «привлечь 2,5 миллиона клиентов в следующем году», IT должно быть к этому готово. Нужно понимание: сколько команд потребуется, выдержат ли системы, можем ли мы масштабироваться на такое количество пользователей одновременно.

Когда вместо микросервисов получается монолит

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

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

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

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

Война доменов

Еще один маркер: два отдела управляют одним процессом. Например (описываю не наши процессы, пример просто из головы): появляется группа недовольных клиентов — отдел претензий решает поднять им кешбэк на месяц. Но в системе уже есть VIP-клиенты с постоянным повышенным кешбэком.

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

Правильный подход — создать отдельный сегмент «недовольные клиенты» со своей логикой обработки. Иначе каждый домен будет тянуть метафорическое одеяло на себя, превращая задачу в снежный ком, который чем дальше, тем больше будет обрастать проблемами.

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

Почему проблема обострилась именно сейчас

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

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

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

Когда ландшафт разорван и бизнес живет по-своему, легко может возникнуть ситуация: «Мы тут запартнерились, можем завтра все это выпустить?». Нет, не можем. В итоге компания теряет конкурентное преимущество и не способна быстро вывести комплексный продукт на рынок.

Как починить разорванный ландшафт

Шаг 1: остановитесь и проведите аудит

На том проекте с критическим дедлайном я так и сделал — предложил взять тайм-аут на несколько дней и посмотреть, кому что нужно и интересно.

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

Главное на этом этапе — выявить все точки взаимодействия между бизнесом и IT, понять, где возникают разрывы в понимании. Нужно точное «определение продукта», чтобы заказчик осознавал, чем он управляет и как это все дальше развивать. Благодаря этому определению всем будут понятно, кто за что отвечает, где точки роста и узкие места, этапы развития: какой бизнес-процесс требуется здесь и сейчас, а какой можно отложить на потом.

Шаг 2: разделите домены и назначьте владельцев

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

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

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

Как не допус��ить разрыва: профилактика

Убедите бизнес мыслить архитектурно

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

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

Это конкретный запрос из другого домена, согласованный с руководством. Создание новых сегментов происходит в домене «лояльность» — владелец не нарушит архитектуру, не сломает сегментирование.

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

Наладьте правильную коммуникацию

Архитекторы должны участвовать в бизнес-встречах, понимать потребности заказчика и интегрировать их в IT-ландшафт. Нужны структуры сотрудничества:

• Enterprise-архитекторы и C-level-менеджеры,

• Solution-архитекторы и бизнес,

• Solution и системные архитекторы,

• Enterprise- и solution-архитекторы.

Это обеспечивает контроль IT-ландшафта через вовлечение бизнеса.

TOGAF и другие фреймворки — инструмент, а не панацея

Зачем нужны архитектурные фреймворки

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

Один из самых известных — TOGAF (The Open Group Architecture Framework). Это набор методов и инструментов для создания корпоративной архитектуры. По сути, TOGAF предлагает общую терминологию и структуру описания: как должны выглядеть бизнес-процессы, как они связаны с IT-системами, кто за что отвечает, как планировать развитие на несколько лет вперед.

Вместо ситуации, когда «бизнес» говорит: «Нам нужна штука для клиентов», а IT отвечает: «Мы сделаем микросервис», появляется общий язык. Бизнес описывает процесс по определенным правилам, IT понимает, какие системы нужны, архитекторы видят, как это вписывается в общую картину.

TOGAF — инструмент для объединения команд: бизнеса, топ-менеджеров и архитекторов. Он помогает прийти к единому видению корпоративной архитектуры.

Адаптируйте, не внедряйте

Выбирая фреймворк, нужно понимать готовность бизнеса к изменениям. Если они привыкли работать с простыми требованиями в Word и это пока их устраивает, зачем навязывать что-то сложное? Но когда бизнес-процессы усложняются, все начинают понимать, что имеющихся подходов недостаточно. Появляются противоречия, недопонимания, процессы путаются — тогда и возникает запрос на более структурированную работу.

Я всегда ориентируюсь на то, что каждая компания — комбинация действительно необходимого здесь и сейчас. Бизнес может жить с требованиями в Word? Отлично. Нужна UML-диаграмма для разработчиков? Рисуем.

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

Вот что предлагает TOGAF

Полный цикл Architecture Development Method (ADM) — основа TOGAF. В центре — управление требованиями, вокруг — восемь фаз, от предварительной до управления изменениями архитектуры. Пытаться воплотить его целиком «как есть» не стоит. Лучше начать с двух-трех фаз, которые закрывают текущие болевые точки, а остальные добавлять по мере необходимости.

Начинаем с одного «лепестка» — например, миграции на Kubernetes или с ClearCase на Git. Добавляем IT-инфраструктуру, приложения… А когда бизнес говорит: «Не понимаем, почему стало сложно» — включаем бизнес-архитектуру.

От разорванности к единой стратегии

Устранение разрыва между бизнесом и IT — не техническая, а стратегическая задача. Опыт показывает, что когда все участники понимают свои зоны ответственности и свое влияние на трансформацию ландшафта, недопонимание исчезает.

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