Введение: “Фундамент залит. Теперь строим дом. По какому чертежу?”

В предыдущей статье мы говорили о фундаменте — о том, как IT Check-up (Уровень 1) обеспечивает стабильность и безопасность вашего бизнеса. Ваш “организм” здоров. Сервисы стабильны, данные под контролем, инфраструктура предсказуема. Это уже больше, чем есть у большинства компаний.

Но стабильность — это не рост. Гигиена — это право на развитие, а не сама цель.

И вот теперь возникает главный вопрос: а что именно мы строим дальше?

Здесь многие компании попадают в новую ловушку.

IT-фундамент прочен. Ошибки под контролем. Но бизнес всё равно недоволен.

IT-отдел становится “вещью в себе”: он прекрасно обслуживает то, что уже существует, но почти не влияет на скорость выхода продуктов, на гибкость, на способность обгонять рынок.

Возникает знакомая зона хронического конфликта:

• Бизнес: “Почему любая новая идея превращается в “это займет 9 месяцев”? Мы теряем окна возможностей. Мы отстаём”.
• IT: “Почему приоритеты меняются каждую неделю? Как строить архитектуру, если задачи появляются хаотично?”

Это не конфликт характеров. Это отсутствие единого чертежа развития — понятного и бизнесу, и IT.

Чертежа, на основе которого принимаются решения:

• какие технологии выбираем,
• что строим сами, а что покупаем,
• что делаем сейчас, а что потом,
• где скорость важнее, а где важнее устойчивость.

Эта статья — о Стратегическом консалтинге (Уровень 2). О том, как создать Архитектурный план роста — документ, который синхронизирует бизнес-стратегию и технологию, снимает внутренние конфликты и становится дорожной картой на 1—3 года вперёд.

Самодиагностика: Когда бизнесу нужен “Архитектор”

Фундамент может быть крепким, но если нет плана развития, здание не растёт. Ответьте честно на 4 вопроса. Если хотя бы на два из них ответ — “Да”, значит IT уже работает без общего вектора и начинает тормозить бизнес.

1. Постоянные споры “Build vs. Buy” без финального решения? Дискуссия о том, строить ли собственную систему или купить готовую, длится месяцами?
   Аргументы звучат эмоциональные: “Не доверяю облакам”, “Мы так всегда делали”, “Мне больше нравится этот стек”. А не конкретные расчёты TCO, ROI и стоимости владения на горизонте 3 лет.
2. IT не успевает за бизнесом? Маркетинг, продажи или продукт приносят идеи, которые могут приносить деньги уже завтра.
   Но слышат в ответ: “Это долго”, “Наша архитектура это не выдержит”, “Нужно переписывать половину системы”.
3. Вы чувствуете технологический тупик? Текущий стек устарел морально или концептуально.
   Хороших инженеров для него не нанять. Инновации упираются в старые решения. Каждый новый продукт — это борьба с наследием, а не проектирование будущего.

4. Каждый новый проект начинается с “войны за стек”? Совещание превращается в спор о технологиях, вместо обсуждения бизнес-задачи.

   Выбор делается по принципу: “Мне удобно”, “Мы это уже знаем”, “Это сейчас модно”. А не по принципу: “Так построим быстрее, устойчивее и дешевле на горизонте
   12—36 месяцев”.

Эти симптомы — не про людей. Это не “ленивый IT” и не “хаотичный бизнес”. Это отсутствие единого архитектурного плана, который задаёт направление.

Когда архитектура не спроектирована, компания не растёт — она просто чинит себя снова и снова.

Анатомия архитектурного плана: Из чего состоит правильная IT-стратегия

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

1. Куда идём?
2. Как туда доберёмся?
3. И на чём поедем?

Разберём их подробней.

1. Стратегическое видение — “Куда?”

Это верхнеуровневый документ, который связывает бизнес-цели компании на горизонте
3—5 лет с возможностями технологий. Он не занимается инженерными подробностями.

Он отвечает на вопросы уровня CEO:
• Какое конкурентное преимущество мы хотим усилить или создать с помощью технологий?
• Какие процессы должны быть оцифрованы первыми, почему?
• Как IT будет помогать нам запускать новые продукты и выходить на новые рынки?

Это компас. Он определяет направление и исключает хаотичность.

2. Технологическая дорожная карта — “Как?”

Это план внедрения, обычно расписанный по кварталам на 12—24 месяца.

Он делает стратегию выполнимой:
• Что внедряем по кварталам в Q1, Q2, Q3, Q4?
• Какие проекты идут первыми, а какие ждут своей очереди?
• Сколько людей, времени и бюджета требуется?
• Какие зависимости и риски нужно учитывать?

Это маршрут на карте. Он позволяет двигаться постепенно и предсказуемо.

3. Архитектурные решения — “На чём?”

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

Документ, в котором фиксируются решения, которые НЕЛЬЗЯ менять каждые три месяца:
• Монолит или микросервисы — скорость запуска или гибкость.
• Выбор облака (AWS / Azure / GCP) — инфраструктурные принципы на годы.
• Базовые платформы и системы (CRM, ERP, CDP) — что покупаем, что строим сами.
• Стек разработки — на чём реализуем свою уникальную ценность.

Это транспорт и инженерная карта маршрута: поменять “по пути” — дорого и больно.

Вместе эти три документа образуют единый Архитектурный план

Без “компаса” — команда тянет в разные стороны. Без “маршрута” — всё превращается в бесконечные “инициативы без дедлайнов”. Без “выбора транспорта” — архитектура рушится под давлением роста.

С Архитектурным планом бизнес и IT получают одну картину мира — и начинают двигаться в одном направлении.

Кто за что отвечает: матрица ролей

Чтобы стратегия не превратилась в ещё один “документ, который лежит в папке”, важно правильно распределить зоны ответственности.

Документ	Что фиксирует	Уровень ответственности	Формат работы
Стратегическое видение (“Куда?”)	Связка бизнес-целей и технологий на горизонте 3—5 лет.	CEO + CPO (бизнес) совместно с CTO.	Совместные стратегические сессии раз в квартал.
Технологическая дорожная карта (“Как?”)	Приоритеты, этапы внедрения, ресурсы, сроки.	CEO + CPO + CTO + руководители направлений.	Планирование по кварталам, регулярные ревью.
Архитектурные решения (“На чём?”)	Архитектурный стиль, стек, платформы и фундаментальные технологии.	CTO / Lead Architects.	Архитектурные комитеты, обоснование решений.

Вывод:

• Бизнес определяет направление.
• IT проектирует маршрут и транспорт.
• Документы создаются совместно, иначе они не живут.

Ключевой вопрос: Build vs Buy — архитектурное решение, а не религиозная война

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

Выбор “строить или покупать” нельзя делать:

• “Потому что команда любит этот стек”.
• “Потому что соседняя компания сделала так же”.
• “Потому что кажется быстрее”.

Единственный надежный способ — холодный анализ.

Когда однозначно ПОКУПАТЬ (Buy)?

Если процесс не является вашим конкурентным преимуществом, решение почти всегда очевидно — покупаем.

Примеры зон, где нет смысла изобретать велосипед:

• Бухгалтерия и финучет.
• HR-учет сотрудников.
• Базовая CRM для типовых продаж.

Эти процессы уже стандартизированы рынком.

Главный сигнал покупать: Скорость выхода на рынок важнее, чем контроль над технологией. Вашей команде не нужен “уникальный HR” — ей нужно нанимать людей быстрее.

В таких случаях строить своё с нуля — это сжигать время и деньги ради иллюзии контроля.

Когда стоит СТРОИТЬ (Build)?

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

Примеры:

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

Сигналы строить:

• Ни одно готовое решение не покрывает ваши потребности даже на 80%.
• Вы хотите контролировать развитие продукта, а не ждать обновлений подрядчика.
• Данные и логика процесса — это ваш ключевой актив.

Здесь покупка готового решения ограничит рост быстрее, чем отсутствие стратегии.

Как принимать решение: безжалостная математика TCO

Интуиция — обманчива. Считать нужно полную стоимость владения (TCO) на горизонте 3—5 лет, а не цену “на старте”.

• TCO покупки (Buy): Лицензии + Внедрение + Кастомизация + Интеграции + Ежегодная поддержка.
• TCO стройки (Build): Команда разработки (включая PM, QA, DevOps) + Инфраструктура + Поддержка + Развитие.

Часто:

• “Дешевое” готовое решение становится “золотым” через три года.
• “Дорогое” кастомное решение окупает себя, если оно дает ускорение роста.

Только цифры, а не вкусовщина, дают объективный ответ.

И да — почти всегда побеждает гибридный подход

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

Вывод:

Не бывает правильного ответа “в общем”. Бывает правильный ответ именно для вашего бизнеса. И он всегда рождается не из эмоций, а  из архитектурного анализа и расчетов TCO.

Результат: Что дает бизнесу наличие “Архитектурного плана”?

“Архитектурный план” — это не отчёт и не презентация. Это управляющий документ, который меняет операционную модель компании.

Когда план внедрён — меняется то, как компания принимает решения, ставит приоритеты и тратит деньги.

На практике это выражается в трёх ключевых эффектах:

1. Появляется общий язык между бизнесом и IT

Вместо вечных споров “мы хотим новые фичи” vs “нам нужен рефакторинг” возникает единая дорожная карта, видимая всем.
• Бизнес понимает, почему какие-то задачи идут первыми.
• IT понимает, какого результата ждёт бизнес.
• Споры заменяются прозрачными критериями приоритетов.

Не “кто громче кричит”, а “что ведёт к целям компании”.

2. Инвестиции в IT становятся управляемыми

Технологический бюджет перестаёт быть “чёрным ящиком” или обязательным злом. Он становится портфелем инвестиций, где каждая статья имеет обоснование.

Вы точно знаете:
• где вы платите за скорость выхода на рынок,
• а где вкладываете в собственное конкурентное преимущество.

“Модные решения” и “сделаем потому что нравится” исчезают сами собой.

Деньги начинают работать не на поддержку сложности, а на рост бизнеса.

3. Скорость и гибкость резко возрастают

Парадокс: чтобы действовать быстро — нужно заранее договориться о правилах.

Когда архитектурные принципы и стек уже зафиксированы:
• Совещаний становится меньше.
• Принятие решений происходит быстрее.
• Команда перестаёт “спорить про технологии” и начинает делать продукт.

Стратегия даёт свободу, а не ограничение.

Главный эффект

“Архитектурный план” прекращает внутренние войны, выравнивает мышление по всей компании и перенаправляет энергию из борьбы друг с другом на борьбу с конкурентами.

Именно в этот момент бизнес впервые начинает двигаться как единый организм.

Заключение: Стратегия — это не то, что вы делаете, а то, чего вы не делаете

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

Создание “Архитектурного плана” — это не про добавление новых проектов в бэклог. Это про безжалостное отсечение лишнего, чтобы выделить то, что действительно усиливает бизнес.
Это чертёж перед строительством.
Без него можно строить — но почти всегда получается дорого, долго и с ошибками.

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

Но есть ситуации, когда “доработать существующее” уже недостаточно. Когда бизнес вырос, а инфраструктура — нет. Когда нужно не просто строить новое, а переосмыслить основание.

Именно об этом — следующий уровень консалтинга.

Что дальше?

В следующей статье: Уровень 3 — Хирургическая трансформация. Как перестроить архитектуру бизнеса без его остановки.

Дзен-коан:

Ученик спросил Генерала:

— Как выиграть войну?

Генерал ответил:

— Выбери правильное поле битвы. Тогда половина сражения будет выиграна еще до его начала.

P.S.: С какой дилеммой “строить или покупать” вы сталкиваетесь сейчас? Где у вас ядро, а где — инфраструктура?