Выделение самостоятельного контура из legacy-платформы
Проект находится на этапе Discovery. Промежуточный результат — не целевая архитектура, а управляемый процесс её получения: определение границ продукта и данных, построение карты coupling, закрытие открытых требований, ведение реестра рисков и подготовка к проверяемому Architecture Readiness gate.
Обзор
Компания A продолжает развивать существующую legacy-платформу, а для Компании B нужно выделить самостоятельный продуктовый контур со своими пользовательскими интерфейсами, backend, инфраструктурой и БД. Я веду анализ и декомпозицию этой задачи, отделяю требования от предварительных архитектурных гипотез и готовлю команду к осознанному проектированию.
Проблема
Исходный запрос уже содержал правдоподобную техническую схему: перенести продуктовые сервисы, оставить часть платформенных зависимостей в A, связать контуры через API и синхронизировать нужные данные. При разборе выяснилось, что до выбора реализации не определены границы продукта B, ownership данных, пользовательская identity, состав сервисов, режим сосуществования A/B, требования ИБ, Legal, NFR и эксплуатации.
Ограничения
- Компания A не выключается: часть кабинетов и функций продолжает жить в существующем контуре, поэтому нужно проектировать coexistence, а не линейную миграцию с одним cutover.
- Legacy-платформа сочетает frontend-монолит, около полутора десятков продуктовых сервисов, несколько платформенных сервисов, legacy-монолит и крупную общую БД.
- Простого списка сервисов недостаточно: прямые обращения к данным, синхронные цепочки, общие библиотеки, инфраструктура, доступы и ручные операции могут удерживать скрытый coupling.
- Регистрация, аутентификация, OTP, SSO, межсистемное связывание пользователей, API-контракты и механизм синхронизации данных ещё не выбраны.
- Нельзя публиковать реальные названия компаний и систем, внутренние URL, документы, задачи, сотрудников, точные SLA, финансовые показатели или закрытые схемы.
- Документация должна поддерживать решения небольшой рабочей группы, а не создавать десятки страниц и отдельную бюрократическую систему.
Подход
Я вернул задачу от преждевременного выбора технологий к Discovery: разделил факты, требования, ограничения, гипотезы, решения и риски; сформировал направления анализа и Stage Gates; организовал AS-IS и coupling-разбор; собрал открытые вопросы и owners; сократил документацию до нескольких живых рабочих контекстов; определил состав входных данных и критерии Architecture Readiness.
Ключевые решения
Не фиксировать целевую архитектуру до минимально достаточного Discovery
Первоначальная схема помогла обнаружить неизвестные, но опиралась на неподтверждённые предположения о пользователях, границах сервисов, данных, интеграциях и эксплуатационных характеристиках. Дорогие архитектурные решения должны приниматься после проверки этих входных данных.
- Сразу проектировать перенос существующих сервисов
- Выполнить lift-and-shift текущей архитектуры в новый контур
Рассматривать B как самостоятельный продуктовый контур
Компания A продолжает существовать, поэтому B нельзя считать только новым frontend над A или временной replacement-системой. Нужны собственные границы продукта, пользователей, данных и ответственности, а также явно спроектированное сосуществование.
- Сделать B новым frontend над backend Компании A
- Считать проект временной миграцией до полного выключения A
Задать независимость данных B через ownership, а не через копию legacy schema
БД B должна строиться от доменной модели и ответственности нового контура, без прямых связей с БД A. Это фиксирует границу данных, но не предрешает механизм межсистемного обмена, который ещё нужно выбрать по требованиям.
- Использовать общую БД A и B
- Сделать копию нужных legacy-таблиц основным контрактом между системами
Собрать несколько живых рабочих контекстов вместо десятков документов
Небольшой рабочей группе важнее быстро видеть статус, блокирующие вопросы, владельцев и решения, чем поддерживать отдельную страницу для каждого артефакта. Принцип — один удобный рабочий контекст на страницу.
- Создать отдельную страницу для каждого типа требования
- Завести отдельный документ для каждого небольшого ADR
- Собрать весь проект в один большой документ
Стек
- Confluence
- RACIVS
- ADR / Decision Log
- Architecture Readiness Gate
- Legacy-монолит
- Микросервисы
- Реляционные БД
- Cloud infrastructure (целевой контур)
Результат и импакт
На текущем этапе задача перестала рассматриваться как простой lift-and-shift. Предварительные решения отделены от требований, ключевые неизвестные и классы coupling стали явными, Discovery получил направления, owners и Stage Gates, а риски начали фиксироваться до проектирования. Это создаёт рабочую основу для совместного review с Product, BA/SA, Backend, Frontend, DevOps, ИБ, Legal и Architecture без заявления о готовой системе или утверждённой архитектуре.
Выводы
- Архитектурная гипотеза полезна как инструмент поиска неизвестных, но не должна незаметно превращаться в решение.
- Перед разделением системы важнее исследовать ownership и coupling, чем посчитать микросервисы.
- Отдельный frontend или cloud-кластер сами по себе не делают продукт самостоятельным.
- Пользовательская identity, продуктовый пользователь и бизнес-роль — разные сущности, даже если legacy-система хранит их вместе.
- Architecture Readiness полезнее календарного обещания начать проектирование, если входные требования ещё не готовы.
- Документация должна снижать когнитивную нагрузку команды, а не становиться ещё одной сложной системой.
- Для долгого coexistence нужно фиксировать не только будущую архитектуру, но и временные зависимости и условия их удаления.
Статус кейса
Это первая публичная итерация живого кейса. Проект только начался и находится в Discovery: целевая архитектура не согласована, сервисы не перенесены, новый контур не реализован и не запущен.
Текущая ценность работы — в другом. Исходная техническая схема стала проверяемой программой получения требований: что должно принадлежать Компании B, какие зависимости остаются с Компанией A, кому принадлежат данные, какие риски блокируют проектирование и по каким критериям можно переходить к архитектурному review.
От «переезда сервисов» к разделению системы
На старте задача выглядела как выделение части существующей платформы. У Компании A есть frontend-монолит с несколькими личными кабинетами, продуктовые и платформенные сервисы, legacy-монолит, крупная общая БД и общие инфраструктурные зависимости. Для Компании B нужны отдельный домен, собственные пользовательские интерфейсы, backend, инфраструктура и БД.
При этом Компания A не исчезает. Часть её кабинетов и функций продолжит работать, возможно в сокращённом виде. Поэтому модель проекта — не A → B → A выключили, а два контура с осознанным периодом сосуществования.
%%{init: {"flowchart": {"useMaxWidth": false}}}%%
flowchart TB
A["A: legacy работает"] ~~~ B["B: цель —<br/>самостоятельный контур"]
A --> Discovery["Discovery:<br/>границы · ownership<br/>coupling · отказы"]
B --> DiscoveryЭта схема показывает контекст, а не целевую архитектуру. Направления вызовов, контракты, способы обмена и временные зависимости ещё нужно определить.
Первоначальная гипотеза
Первая техническая гипотеза была естественной:
- перенести продуктовые микросервисы в новый cloud-кластер B;
- оставить часть платформенных сервисов в инфраструктуре A и вызывать их через API или API Gateway;
- реплицировать необходимые данные из общей БД;
- отделить frontend нужных личных кабинетов от монолита.
Я не считаю эту схему ошибкой. Она дала команде конкретный предмет для обсуждения и быстро показала, каких входных данных не хватает. Ошибка началась бы позже — если бы рабочая гипотеза незаметно стала утверждённой архитектурой.
Что заставило остановить проектирование
При разборе одна техническая схема распалась на несколько групп неизвестных.
| Направление | Что нужно выяснить до архитектуры |
|---|---|
| Product / Business | Зачем выделяется B, какие процессы принадлежат ей, что входит в первый релиз, что остаётся в A, что откладывается или не переносится. |
| Users / Identity | Когда возникает пользователь B, как живут его собственный ID и запись, когда допустима связь с A, какие согласия и роли нужны. |
| Data | Source of truth, owner и writer каждой сущности, история, migration/replication, consistency, latency, lifecycle, retention, consent и audit. |
| Integrations | Какие сервисы переносить, использовать через контракт или переписывать; где допустим sync, где нужна локальная projection или async; как B работает при недоступности A. |
| Security / Legal | Trust boundaries, business authorization, privileged access, service accounts, ПДн, audit, logging, secrets, OTP и требования регулируемой организации. |
| NFR / Operations | SLI/SLO, availability, latency, capacity, RTO/RPO, monitoring, tracing, alerting, support, incident ownership и межсистемные SLA/OLA. |
Отдельный блок вопросов относится к UX: какие наработки A действительно переиспользовать, где пользователь видит границу A/B, какие нужны loading/error/empty states и потребуется ли общая design system.
Discovery вместо преждевременной архитектуры
Первым шагом я разделил типы информации, которые до этого легко смешивались:
- факт — подтверждённое текущее состояние;
- требование — необходимый результат;
- ограничение — условие, которое нельзя нарушить;
- гипотеза — предположение, которое нужно проверить;
- решение — согласованный способ реализации;
- риск — неопределённость с возможным негативным последствием.
Это простое разделение защищает проект от подмены: фраза «поставим API Gateway» остаётся гипотезой, пока неизвестно, какие сценарии, границы доверия, характеристики отказа и эксплуатационные требования она должна закрыть.
Моя работа на этом этапе — не выбрать технологию за команду. Я вёл декомпозицию, формировал вопросы к бизнесу, участвовал в review первых Vision & Scope материалов, искал противоречия, отделял архитектурные варианты от требований, ставил задачи по AS-IS и coupling analysis, собирал риски и открытые вопросы и готовил общий контекст для Product, BA/SA, Backend, Frontend, DevOps, ИБ, Legal и Architecture.
Как я декомпозировал работу
Большая задача разделена на шесть целей:
- завершить Discovery и получить готовность к архитектурному проектированию;
- спроектировать и согласовать архитектуру;
- подготовить инфраструктуру;
- реализовать и протестировать систему;
- запустить и стабилизировать;
- передать систему в сопровождение и закрыть проект запуска.
Сейчас активна только первая цель. Такая декомпозиция не обещает сроки следующих этапов, но не позволяет обсуждать инфраструктуру и миграцию так, будто продуктовые и эксплуатационные границы уже определены.
Ищем coupling, а не считаем сервисы
Решение «перенести сервис» мало что значит, пока непонятно, какие зависимости должны уехать вместе с ним. Поэтому AS-IS анализ охватывает не только список компонентов, но девять типов связанности: Data, Runtime, Temporal, Release, Schema, Infrastructure, Security, Operational и Organizational coupling.
| Слой | Что проверяем |
|---|---|
| Data / Schema | Прямые обращения к чужим таблицам, общие транзакции, shared database, неявные владельцы и несколько систем, записывающих одну сущность. |
| Runtime / Temporal | Синхронные цепочки, таймауты, cron и background jobs, ETL/BI, порядок операций и поведение при недоступности A. |
| Release / Infrastructure | Общие библиотеки и схемы, CI/CD, cache, filesystem или object storage, сетевые правила и зависимости релизов. |
| Security | Shared service accounts, secrets, callback, allow-list, privileged access, технические и бизнес-права. |
| Operational / Organizational | Логи, мониторинг, ручные операции поддержки, incident ownership и команды, без которых компонент формально перенесён, но не автономен. |
Такой разбор нужен, чтобы будущая классификация «перенести / оставить / переписать / вывести» опиралась на реальную связанность, а не на название репозитория или сервиса.
Независимость B начинается с ownership данных
Одна из важных границ текущего этапа: пользователь B — самостоятельный пользователь B со своим идентификатором и записью. Если есть нужное согласие и подтверждённый бизнес-сценарий, позже может инициироваться создание или связывание пользователя в A. Но registration, authentication, OTP, SSO и способ межсистемного связывания пока не считаются выбранной архитектурой.
То же относится к данным. Для каждой сущности нужно назвать source of truth, owner и writer, правила истории, миграции, consistency, задержки, retention, consent и audit. БД B должна строиться от доменной модели B и не опираться на прямые связи с БД A.
Это решение задаёт границу, но не выбирает механизм обмена. Репликация, API, события, локальные projections и другие варианты остаются гипотезами до подтверждения требований.
Документация как инструмент управления
В начале появилась модель с десятками отдельных Confluence-артефактов. Для небольшой рабочей группы она создавала риск: документация могла стать самостоятельным проектом и затруднить поиск актуального решения.
Я сократил структуру до принципа «один удобный рабочий контекст — одна страница».
| Живая страница | Для чего она нужна |
|---|---|
| Управление проектом | Статус, цели, Stage Gates, RACIVS, stakeholders, risks, open questions, Decision Log, sign-off и ближайшие действия. |
| Vision & Product Scope | Business context, цели, пользователи, роли, lifecycle, capabilities, critical journeys, UX и Scope / Out of Scope / Later / TBD. |
| AS-IS A и зависимости | Frontend, backend, монолит, сервисы, БД, интеграции, jobs, storage, инфраструктура, support, coupling и предварительная классификация компонентов. |
| Технические и эксплуатационные требования | Regulatory, InfoSec, access, data, integrations, NFR, metrics, infrastructure, DevOps, coexistence и transition. |
| Architecture Readiness | Короткий dashboard готовности, owners, blocking questions и итоговый READY или NOT READY. |
После Discovery появится отдельный рабочий контекст «Целевая архитектура и ADR». Небольшие ADR будут собраны там с оглавлением и якорями, а не размножены по отдельным страницам без необходимости.
Architecture Readiness как gate
Архитектурное проектирование начинается не потому, что пришла дата рисовать C4. Для входа нужны как минимум Vision & Scope, roles/lifecycle, capabilities, AS-IS, Data Ownership, integrations/coupling, Regulatory, Security, NFR, Infrastructure, Coexistence/Transition и список критичных рисков. Итог gate — READY FOR ARCHITECTURE REVIEW или NOT READY.
%%{init: {"flowchart": {"useMaxWidth": false}}}%%
flowchart TB
Inputs["Входные данные"] --> Gate{"Достаточно?"}
Gate -->|"да"| Ready["READY"]
Gate -->|"нет"| NotReady["NOT READY"]NOT READY — не наказание и не бюрократический отказ. Это видимый список входных данных, без которых архитектурное решение будет строиться на предположениях.
Как риски вошли в Discovery
Risk management начался до проектирования. В текущем risk register есть классы рисков, связанные с преждевременной фиксацией API Gateway, CDC или схемы БД; скрытыми зависимостями от legacy DB; несколькими источниками записи одной сущности; сильным runtime/temporal coupling; неучтёнными batch/ETL/BI процессами; Legal и Compliance; административным доступом; отсутствием baseline нагрузки; rollback после появления новых данных в B; и временными интеграциями без условий удаления.
Отдельно зафиксирован организационный риск чрезмерной документации. Это не шутка про процессы: если рабочая группа тратит больше времени на навигацию и синхронизацию страниц, чем на закрытие неизвестных, документационная модель перестаёт помогать управлению проектом.
Что уже изменилось
На текущей итерации можно честно зафиксировать только качественный процессный результат:
- задача больше не рассматривается как простой lift-and-shift;
- предварительные решения отделены от требований и открытых гипотез;
- ключевые неизвестные стали видимы до дорогостоящего проектирования;
- Discovery получил направления, owners, Stage Gates, risks и Decision Log;
- определён состав входных данных для Architecture Readiness;
- документация сведена к небольшому числу рабочих контекстов;
- появился общий материал для предметного review с техническими и продуктовыми участниками.
Эти изменения не доказывают экономию, надёжность или готовность продукта. Их ценность — сделать следующий этап проверяемым и не скрывать неопределённость за конкретными названиями технологий.
Что ещё предстоит решить
До следующей существенной версии кейса остаются открытыми:
- модель регистрации, authentication, OTP, SSO и linking пользователей A/B;
- границы сервисов и состав первого релиза;
- межсистемные контракты и поведение B при недоступности A;
- ownership, migration и synchronization данных;
- sync/async границы, состояния, повторы и ручные операции;
- NFR, SLI/SLO, RTO/RPO и межсистемные SLA/OLA;
- инфраструктурная модель и эксплуатационная ответственность;
- coexistence, transition, rollback и условия удаления временных зависимостей;
- целевая архитектура и набор утверждённых ADR.
Что я сознательно не публикую
В кейсе нет реальных названий компаний, доменов, систем, документов, поставщиков, сотрудников, задач, внутренних URL, production endpoints, ID, точных SLA, финансовых показателей, скриншотов и закрытых схем.
Даже безопасные архитектурные количества приведены только диапазонами и там, где они объясняют связанность legacy-системы. Диаграммы нарисованы заново как модель задачи и не воспроизводят внутреннюю архитектуру.
Чему меня уже научил этот этап
Архитектурная гипотеза полезна, когда помогает задавать вопросы. Опасной она становится в момент, когда команда перестаёт видеть в ней предположение и начинает обсуждать только детали реализации.
Самостоятельность контура определяется не отдельным доменом и кластером, а ownership пользователей, данных, контрактов, эксплуатации и решений при отказах. А документация помогает только тогда, когда сокращает путь от вопроса к владельцу и решению.
Продолжение
Этот кейс будет обновляться вместе с проектом. Следующая существенная версия появится после прохождения Architecture Readiness и согласования целевой архитектуры; последующие — после реализации, запуска, стабилизации и передачи в сопровождение, если результаты и артефакты можно будет безопасно подтвердить и опубликовать.