Эффективная трансформация: запускаем новые цифровые продукты на старой инфраструктуре

Цифровая трансформация диктует свои правила, толкая компании на эксперименты и создание новых решений независимо от состояния инфраструктуры.

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

ERP, корпоративные порталы, CRM, MES и другие «тяжеловесные» системы годами работают без модернизации. Это происходит практически в любой компании: функциональность устраивает пользователей, а обновление — процесс трудоёмкий и рискованный.

«Железо», закупленное несколько лет назад, не тянет дополнительные нагрузки, ПО не удовлетворяет современным требованиям и не предусматривает API (механизм взаимодействия с внешними системами), — всё это признаки устаревания инфраструктуры.

В таких условиях сложно поддерживать и разрабатывать новые продукты.

За семь лет работы команда Arcsinus помогла «Ситимобилу», «Додо Пицце», «Делимобилю», Panasonic, «Сбербанку», Kaspersky и другим брендам ужиться с самыми разными типами инфраструктуры.

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

В нашем контексте инфраструктура (ИС) — совокупность информационных систем, которые включают в себя компьютеры и иное «железо», а также программное обеспечение: корпоративные порталы, системы управления предприятием, учётные и другие системы для решения b2b- или b2c-задач, адаптированные под нужды компании или разработанные с нуля.

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

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

Рассмотрим выпуск нового продукта на примере запуска мобильного приложения для клиентов или сотрудников компании. Мобильное приложение создаётся с нуля, но какие ИТ-системы компании и как будут при этом задействованы?

Вариантов конфигурации инфраструктуры для нового продукта четыре:

• Отдельная инфраструктура.
• Односторонний импорт данных.
  
• Прямая интеграция.
  
• Параллельная инфраструктура.
  

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

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

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

Тогда создаётся микросервис, который конвертирует данные между старым и новым форматом. Встречается нечасто, но такой вариант возможен.

Крупный дистрибьютор промышленных изделий хочет передать данные для мобильных приложений через старую самописную ERP-систему. Чтобы передать данные, нужно выгрузить каталог товаров на FTP и импортировать данные на сервер, который предоставляет API мобильным приложениям.

Обновляем инфраструктуру и используем адаптированные либо созданные каналы для двустороннего обмена данными с существующей. Современные ИС имеют готовые API, открытые для обмена данными.

В других случаях нужно дорабатывать или обновлять инфраструктуру и налаживать двустороннее взаимодействие.

Ритейлер запускает мобильное приложение. Компания обновляет CMS своей площадки электронной торговли и дорабатывает для неё API.

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

Такая конфигурация минимизирует нагрузку на существующую инфраструктуру (и это очень важно, поскольку новый продукт требует значительный объём вычислительных ресурсов). Новая инфраструктура становится более автономной, позволяет производить изменения и не опасаться нежелательного воздействия на существующую ИС.

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

Типовой алгоритм для построения параллельной инфраструктуры состоит из нескольких ключевых шагов:

1. Документирование и анализ структуры данных, хранящихся в существующей инфраструктуре.
2. Документирование и анализ архитектуры, а также функциональности существующей инфраструктуры.
3. Проектирование новых инфраструктуры и структуры хранения данных.
4. Проектирование протоколов и алгоритмов обмена данными между двумя инфраструктурами.
5. Разработка новой инфраструктуры в тестовом контуре.
6. Тестирование и отладка на реальных данных.
7. Ввод в эксплуатацию.

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

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

В ходе проекта выделили специализированные сервисы и компоненты системы, которые предоставляют универсальные решения для систем-потребителей внутри компании и позволяют автоматизировать бизнес-процессы.

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

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

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

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

Обратите внимание на современные технологии — проверенные и продвигаемые лидирующими ИТ-гигантами.

Примеры современных технологий:

• облачные сервисы (AWS, Azure, «Яндекс.Облако»);
• актуальные языки программирования и фреймворки;
  
• инструменты и подходы к проектированию, созданию и развертыванию программных продуктов.
  

Примеры устаревших практик:

• iOS-приложение на Objective-C — актуален Swift;
• Android-приложения на Java — актуален Kotlin, хотя Java всё же ещё силён;
  
• фреймворк без поддержки адаптива на веб-фронте (больше половины трафика — с мобильных);
  
• хостинг сервера для бэкенда в своем офисе — хостинг должен быть в облаке или у надёжного хостинг-провайдера.
  

Поэтому ещё один вариант — выбрать используемые в компании технологии. Это упростит обслуживание продукта.

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

Вы определились с вариантом конфигурации инфраструктуры под новый продукт и определили стек технологий. У вас есть высокоуровневая схема продукта, которая описывает новые и обновляемые компоненты и перечень технологий, на которых всё будет строиться.

Далее формулируем полноценные входные параметры для начала разработки, детализируем постановку задач и составляем дорожную карту.

Поэтапно процесс выглядит так:

1. Перечислить основные сценарии, которые должен выполнять продукт.
2. Приоритизировать пожелания и разбить на версии MVP, v1, v2. В противном случае грядущая разработка рискует растянуться, а первый релиз — отодвинуться на неопределённый срок.
3. Составить описание продукта, базовые требования к стеку технологий и сценарии, упорядоченные по релизам. Это поможет исполнителям оценить свои силы, сузить диапазон сроков и стоимости реализации продукта.

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

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

Снизьте риски, оцените, что в текущих условиях можно построить в принципе. Выявите все крупные компоненты новой системы, сценарии и протоколы их взаимодействия, сформируйте дорожную карту.

Не стройте сразу большие продукты: старайтесь быстро запускать микросервисы. Думайте о перспективе — какие технологии останутся актуальными в будущем.

Работа по созданию нового продукта должна минимально воздействовать на старую инфраструктуру и реальные данные: новый продукт должен жить в «песочнице», отдельно от рабочих систем.

Работоспособность всех ИС легче поддерживать, если переписывать частями. Внедрить полностью новое решение можно, только если старую систему поддерживать слишком дорого (учитывайте альтернативные издержки и потери скорости развития) или новая система сильно превосходит старую по ключевым параметрам.

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

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

#инфраструктура