Я выбираю архитектурное решение по тому, как из него можно выйти
Архитектурное решение обычно обсуждают как выбор «правильной» технологии. Я смотрю на него чуть иначе: насколько легко мы сможем изменить курс, если бизнес через полгода окажется не таким, как сегодня. Не каждое решение нужно делать временным. Но в каждом крупном решении полезно заранее понимать цену выхода.
Это особенно важно там, где есть неопределённость: новый продукт, новая модель продаж, интеграция с внешним сервисом, переезд из старой системы. Обратимость не отменяет ответственность. Она помогает не ставить бетонную стену там, где пока достаточно двери.
Есть решения, которые дорого изменить
Название инструмента — только вершина айсберга. По-настоящему дорогими бывают данные, контракты между системами, привычки команды, права доступа и ручные процессы вокруг продукта. Можно за неделю заменить библиотеку, но нельзя за неделю переписать историю расчётов, если она уже стала частью финансового контура.
Поэтому перед выбором я стараюсь назвать не только плюс решения, но и его точку невозврата. Когда она наступает? После подписания договора, переноса данных, запуска тарифа, обучения сотни пользователей? Если ответ расплывчатый, риск пока плохо понятен.
В статье о том, почему временное решение становится проблемой в день роста, я разбирал обратную сторону: временность без границ остаётся навсегда. Обратимость — не оправдание для костылей. Это сознательное решение оставить возможность поменять часть системы, пока факты ещё не подтвердились.
Три вопроса вместо спора о «лучшем варианте»
Когда команда выбирает архитектуру, я предлагаю на время отложить таблицу функций и спросить три простые вещи.
- Что мы узнаем после запуска? Например, какие сценарии действительно используют клиенты, нужна ли высокая нагрузка и какие данные критичны ежедневно.
- Что станет трудно поменять? Модель данных, публичный API, способ авторизации, правила расчёта или поставщика инфраструктуры.
- Какой самый маленький шаг оставит нам выбор? Отдельный адаптер, ограниченный пилот, экспорт данных, понятный контракт или временная граница.
Эти вопросы переводят разговор из «нам нравится технология» в «мы понимаем цену следующего шага». Это полезно собственнику, который не обязан разбираться в деталях стека, но отвечает за последствия вложения.
Составной пример: внешний сервис в новом продукте
Допустим, в продукте нужна доставка уведомлений. Можно прямо из разных частей системы обращаться к выбранному внешнему сервису. Это быстро. Но через несколько месяцев меняются тарифы, появляются ограничения или бизнесу нужен другой канал. Тогда вызовы приходится искать по всему коду, а поведение становится непредсказуемым.
Другой путь — выделить один понятный слой отправки. Самому продукту всё равно, какой поставщик стоит за ним: он просит отправить сообщение и получает понятный результат. Это не требует строить «архитектуру на вырост» со множеством абстракций. Достаточно не смешивать бизнес-правило «уведомить клиента» с деталью конкретного сервиса.
Что остаётся обратимым? Поставщик и способ доставки. Что остаётся осознанным и защищённым? История отправок, согласия пользователя, содержание сообщения и правила, когда его отправлять. Именно эти границы важнее модного названия подхода.
Обратимость начинается с данных
Самый неприятный вопрос при замене системы обычно звучит так: «А как мы заберём свою историю?» Если на него отвечают «разберёмся потом», это не стратегия. Это надежда.
До запуска стоит проверить хотя бы четыре вещи: можно ли выгрузить основные сущности в понятном виде, есть ли у записей стабильные идентификаторы, сохраняется ли история изменений и кто имеет право получить экспорт. Не обязательно строить сложное хранилище с первого дня. Но нельзя делать данные заложником интерфейса одного поставщика.
Этот принцип связан с тем, как я думаю о границах интеграции. Чем больше систем знают внутренние детали друг друга, тем дороже замена любой из них. Хорошая граница оставляет наружу ровно то, что нужно для работы, и не превращает каждое изменение в цепную реакцию.
Не всё должно быть обратимым
Есть решения, где полезнее выбрать и дисциплинированно идти вперёд. Единая модель прав доступа, правило учёта денег, публичное обещание клиентам — здесь бесконечная возможность выбора вреднее, чем ясная договорённость. Но и в таких случаях нужен план изменения: кто его принимает, какие данные затронет, как проверим результат.
Обратимость — не про нерешительность. Она про честное различение: где мы уже знаем достаточно, а где пока делаем ставку. Для первого нужен твёрдый выбор. Для второго — безопасный эксперимент.
Как проверить решение до масштабирования
Я люблю мысленный тест: представьте, что через полгода решение нужно заменить. Не потому что оно плохое, а потому что бизнес купил другую компанию, изменил канал продаж или получил новые требования. Что именно придётся делать?
- Можно ли выгрузить и загрузить данные без ручной перепечатки?
- Есть ли у внешних связей один владелец и понятный контракт?
- Можно ли отключить новый компонент, не останавливая весь рабочий день?
- Понятно ли, какие сценарии нужно проверить после изменения?
- Кто примет решение о переходе и кто заметит, если он пошёл не так?
Если на часть вопросов пока нет ответа, это не всегда стоп-сигнал. Иногда достаточно зафиксировать риск и ограничить масштаб первого шага. Например, начать с одного подразделения, одного типа заказов или одного тарифа. Такой пилот ценен не тем, что красиво выглядит на презентации, а тем, что даёт факты для следующего решения.
Архитектура должна помогать менять бизнес, а не спорить с ним
Архитектура — это не рисунок из прямоугольников. Это договорённость о том, что можно менять без пожара, а что требует отдельного решения. В заметке о худшем рабочем дне я предлагал смотреть на систему через момент нагрузки и сбоя. Здесь тот же взгляд с другой стороны: проверим, что произойдёт не только в худший день, но и в день перемен.
Самый полезный результат архитектурного обсуждения — не идеальный выбор на годы. Это ясность: что мы решили сейчас, почему, какие предположения проверяем и как сможем изменить решение, если жизнь покажет другое. С такой ясностью и запуск, и развитие проходят заметно спокойнее.
Где команда чаще всего путает гибкость и неопределённость
Иногда слово «гибкость» используют как оправдание отсутствия решения. Команда оставляет по три варианта хранения данных, несколько параллельных способов авторизации или не определяет, какая система главная для клиента. Снаружи это выглядит осторожностью, но в работе создаёт путаницу. Никто не понимает, на какое правило опираться сегодня.
Обратимое решение, наоборот, очень конкретно. Оно говорит: на этом этапе главным источником клиента будет одна система; мы держим экспорт и не даём другим компонентам обращаться к её внутренним таблицам; через три месяца пересмотрим предположение по фактам. В таком подходе есть выбор на будущее, но нет двойных правил в настоящем.
Полезная проверка звучит так: может ли новый сотрудник за десять минут понять, что именно принято и что пока остаётся экспериментом? Если нет, проблема не в архитектуре как таковой, а в незафиксированном решении.
Маленький контракт часто ценнее большой платформы
Когда система растёт, возникает соблазн заранее построить общий слой «на все случаи». Я предпочитаю начинать с малого и точного контракта. Например, не «универсальная интеграционная шина», а три понятных события: заказ создан, заказ подтверждён, заказ отменён. У каждого есть владелец, состав данных и правило изменения.
Такой контракт легко проверить в пилоте и легче заменить. Если новая система должна получить заказ, ей не нужно знать, как устроены внутренние статусы CRM или какие поля использует старый интерфейс. Она получает ровно то, что обещано. А изменения внутри исходной системы не становятся аварией для всех соседей.
Это же защищает от ложной экономии. Прямая связь «быстрее на старте» часто дороже после второй или третьей доработки. Я не предлагаю усложнять маленький продукт ради абстрактной красоты. Но там, где изменение вероятно и дорого, маленькая граница окупается спокойствием команды.
Как записать решение так, чтобы оно не потерялось
Для важных выборов полезна короткая карточка решения. В ней достаточно пяти пунктов: контекст, выбранный вариант, почему он подходит сейчас, какие риски принимаем и когда вернёмся к проверке. Это не техническая диссертация. Один экран текста часто спасает от повторного спора через полгода.
Например: «До конца пилота храним историю уведомлений в продукте, отправку делаем через одного поставщика за адаптером, экспортируем историю раз в неделю, пересматриваем поставщика после появления второго канала». Здесь не обещано вечное решение. Зато понятно, что проверять и что не должно быть случайно сломано следующим изменением.
Важнее всего фиксировать не только выбор, но и отвергнутые варианты. Не для того, чтобы оправдываться, а чтобы новый участник команды понял: их уже обсуждали, отказались по конкретной причине и могут вернуться к ним, когда изменятся условия.
План выхода — часть запуска, а не сценарий катастрофы
План выхода иногда воспринимают как недоверие к новому решению. На деле он похож на запасной ключ от квартиры. Наличие ключа не означает, что вы ждёте беды. Оно означает, что вы не хотите зависеть от одного случайного обстоятельства.
Для каждого изменения полезно честно определить: как откатить код, как сохранить новые данные, кого предупредить и какие рабочие операции временно остановить. Для крупного перехода к этому добавляются контрольная сверка данных, период параллельной работы и решение о том, кто подписывает результат. Чем раньше об этом подумать, тем меньше героизма потребуется в день запуска.
Обратимость даёт бизнесу не бесконечные возможности менять всё. Она даёт уверенность сделать следующий шаг без ощущения, что за ним навсегда захлопнется дверь. А для IT-стратегии это одна из самых практичных форм осторожности.
Обсудим?