Изображение предоставлено агентством Kotelov с сайта https://kotelov.com/
Интеграция систем действительно может стать одной из самых сложных и неопределенных фаз в процессе разработки программного обеспечения. От того, насколько качественно будет организована эта часть проекта, сильно зависит его успех, сроки и бюджет. В статье от CEO KOTELOV Валерия Котелова, подробно разобраны ключевые моменты, которые стоит учитывать на этапе планирования и внедрения интеграций.
Статья полезна для продактов, руководителей направлений, аналитиков.
Зачем заказчику знать об интеграциях
Допустим подписан серьезный контракт на разработку корпоративного софта. Заказчик ждет в течение трех месяцев получения MVP. Создано подробное ТЗ на 75 страниц. Несмотря на это, подрядчик не уложился в сроки. Почему? Потому, что потребовалось провести необходимые интеграции.
Статья рассказывает как предвидеть риски, связанные с интеграцией и сохранить бюджет.
Посчитайте число интеграций
Количество систем: Одним из первых шагов является выяснение, сколько систем будет интегрировано. Чем их больше, тем сложнее будет процесс.
Почему важно: Это важно, потому что большое количество систем может потребовать создания Центрального интеграционного хаба, который будет агрегировать и обрабатывать данные, облегчая обмен информации между системами.
Как узнать: продакту нужно сформулировать конечную бизнес-цель с разделением на задачи, если заказчик не понимает реальное количество интеграций.
Например, перед компанией S7 Airlines стояла цель по переводу бумажных накладных в электронный вид, взяв сведения из 1С.
Этапы перевода:
- Получить и связать данные из 1С с рейсами;
- Создать интерфейс для обработки накладных;
- Отправить обработанные данные обратно в 1С;
- Выдать результаты другим системам.
В итоге необходимо было провести 4 интеграции — две с 1С, одна с приложением и одна с другими системами. Изначально казалось, что требуется всего 1 интеграция.
Сбор сведений о системах для интеграции
Предоставьте разработчикам документацию по этим системам. Обеспечьте подписание NDA для защиты конфиденциальной информации. Эта информация необходима для эффективной работы.
Изображение предоставлено агентством Kotelov с сайта https://kotelov.com/
Почему это ключевой аспект:
Многие системы на старте обеспечиваются специализированными интерфейсами для API-общения, облегчающими процесс внедрения и интеграции с другими сервисами. Тем не менее, существуют ситуации, когда необходимые API отсутствуют изначально. В такой картине разработчики сталкиваются с неподготовленностью внешних ресурсов к сотрудничеству, что влечёт за собой значительные отсрочки — до месяца и дольше, – вызывая недовольство всех участников проекта.
Как решить эту проблему:
Продакт-менеджер должен провести комплексную оценку каждой системы в рамках интеграции с целью установления наличия готовых API для передачи и обработки информации.
Какие действия необходимы:
API должны быть разработаны или внедрены владельцами систем, их IT-командами либо приобретены как готовые решения. Важно заранее подтвердить готовность интерфейсов до старта работы над новым продуктом. Это позволит избежать не только временных потерь и дополнительных расходов, но и предотвратит риск увольнения разработчиков из-за вынужденного простоя без оплаты их труда в ожидании решения проблем с API.
Изображение предоставлено агентством Kotelov с сайта https://kotelov.com/
Как это сделать:
Владелец продукта должен найти команду или владельца системы, с которой планируется интеграция. Например, для S7 мы интегрировались с 20 различными системами, и иногда было сложно найти ответственных за них.
Даже если вы нашли владельца системы, нужно дополнительно идентифицировать разработчиков, так как лицо, принимающее решения о функциональности, не всегда будет его реализовывать.
Задайте правильные вопросы:
- Опишите бизнес-потребность без использования технических терминов для достижения понимания.
- Определите, на каком этапе процесса нам нужны сведения.
- Выявите, какие именно требуются данные.
- Определите, что направляется в ответ, если интеграция двусторонняя.
От качества выяснения этих вопросов зависит точность интеграции. Иногда системы уже имеют готовые решения для таких запросов, что может ускорить процесс разработки и решить часть проблем.
Предоставление документации на сервисы
Это необходимо, так как в веб-сервисах часто может не хватать информации для разработки вашего будущего проекта.
Как подойти к этому:
Рассматривайте вопрос с точки зрения бизнес-процесса:
– Как формируются и обновляются данные?
– В какие моменты они могут изменяться или исчезать?
– Какие есть исключения и особенности?
Чем глубже вы изучите логику данных, тем легче будет формулировать требования для разработчиков и описывать тестовые сценарии. Это поможет избежать возвратов задач на доработку после проведения тестирования.
Если информации нет:
Если наблюдаются проблемы с текущим источником данных, стоит найти альтернативные решения. Если смежные системы не имеют документации, иногда приходится вместе с разработчиками создавать ее самостоятельно.
Изображение предоставлено агентством Kotelov с сайта https://kotelov.com/
Тестирование — это ключевой момент. Необходимо выяснить, есть ли у команды тестовое окружение, готовы ли они выделить специалистов для проверки или предоставить доступ к тестовой базе для самостоятельной интеграции.
На одном из предыдущих проектов в S7 проходил рефакторинг интеграции. Перед релизом команда проверила всё на своей стороне, и смежные группы подтвердили, что всё в порядке. Однако после запуска в продакшн некоторым пользователям случайно начислили тысячи миль, что привело к убыткам для компании. Изменения были быстро откатаны, но урок в том, что важность продуманного и согласованного процесса тестирования нельзя недооценивать. Лучше проходить его вместе со смежными командами.
Тестовая среда с обезличенными данными: Это необходимо для обеспечения конфиденциальности пользовательских данных. Например, для онлайн-магазина игрушек тестовая среда может не быть критичной, но для ПО, обрабатывающего информацию о пассажирах или финансовых данных, безопасность становится приоритетом. Утечка базы данных ВИЧ-инфицированных может вызвать серьезные последствия для пострадавших. Защита данных — это интерес подрядчика.
Что делать: При получении доступа к данным важно заранее определить, как мы будем их хранить и использовать. После разработки API необходимо обеспечить наличие документации с четкими требованиями и инструкциями по работе с данными.
Продакт-менеджеру следует проверить два момента:
- Разработчикам не должны присылаться лишние данные.
- Все необходимые данные должны быть в наличии. Иногда подрядчику предоставляют API, но в нём содержится только половина нужной информации. Заказчик может быть уверен в полноте документации, тогда как разработчики остаются без необходимого набора данных для работы.
Сопутствующая документация: Даже если вы предоставили документацию на REST API или WebSocket-сервисы, добавьте материалы, объясняющие терминологию компании или особенности бизнеса.
Изображение предоставлено агентством Kotelov с сайта https://kotelov.com/
Пример: В авиаперевозках используется термин “deadhead” (англ. «мертвая голова»), который не имеет отношения к трупам, а обозначает живого человека, не являющегося пассажиром или членом экипажа. Без сопроводительной документации разработчику пришлось бы затратить много времени на выяснение правил обращения с этим deadhead.
Другой пример: в РЖД внутренняя коммуникация происходит с использованием сокращений, и без соответствующей документации разобраться в этом невозможно. Ни опытный бизнес-аналитик, ни чат GPT не смогут помочь в такой ситуации. Все подобные моменты необходимо прояснить для разработчиков, иначе процесс может затянуться.
Наладьте общение безопасников с подрядчиком:
Убедитесь, что команда разработчиков вашего нового продукта взаимодействует со службой безопасности.
Почему это важно:
Низкая скорость разработки зачастую вызвана требованиями службы безопасности. Подрядчик должен быть знаком с этими требованиями и учитывать их на этапе разработки, чтобы избежать задержек.
Изображение предоставлено агентством Kotelov с сайта https://kotelov.com/
Пример: Разработчики могут создать огромную систему с использованием шаблона MVC, но в какой-то момент выяснится, что каждый метод контроллера должен логировать действия пользователя. Если они использовали фреймворк, это не так страшно, но при использовании самописных решений могут возникнуть серьезные проблемы с поддержкой и масштабируемостью.
Синхронные VS асинхронные языки программирования
Если вы продакт-менеджер, системный аналитик или руководитель направления, необходимо понимать, какие потребуются интеграции, и на основе сведений выбирать верный язык программирования.
В ряде случаев это решение передают разработчикам даже в компаниях с крупным архитектурным комитетом. При этом надо помнить, что языки программирования можно разделить на асинхронные и синхронные. При использовании синхронных операции идут последовательно: сначала пользователь идентифицируется, потом определяют его уровни доступа и заканчивают операцию.
Асинхронные языки работают по другому: когда пользователь взаимодействует с системой, асинхронный язык одновременно идентифицирует его, определяет уровни доступа и предоставляет необходимые данные. Это позволяет ускорить обработку запроса как минимум в 3 раза по сравнению с синхронными языками.
При работе с большой компанией, такой как S7 или аукцион для «Газпромбанк Лизинг» одновременно поступает 50 или более запросов. При этом синхронный язык работает медленнее, а асинхронный покажет большую производительность.
При выборе асинхронного языка, лучше подойдут такие языки, как Java, Go, TypeScript и .NET. Если интеграция происходит с 1С, где нет необходимости получения сведений в реальном времени, то будут достаточны синхронные языки PHP и Python.
REST API-сервисы vs WebSocket
При разработке real-time-систем, таких как финансовые продукты, биржевые решения или онлайн-чаты, нужно учитывать требования к взаимодействию заранее. Если заказчику нужен чат и получение биржевых котировок, REST API-сервисы не подойдут. При нагрузке в 10 тысяч пользователей продукту может не хватить серверов для обработки всех запросов, и это важно учитывать.
При создании онлайн-аукциона для Газпромбанка мы использовали WebSocket. Изначально это могло показаться избыточным, поскольку у аукциона есть список автомобилей и возможности для ставок. Однако важно, чтобы пользователи в режиме реального времени получали информацию о том, что их ставки перебили. В этом случае WebSocket является оптимальным решением, а не REST API.
Самое главное об интеграции
Для успешной реализации интеграций между системами, особенно на уровне таких больших организаций, как авиакомпании, необходимо учитывать множество аспектов. Давайте подробнее рассмотрим перечисленные вами шаги и добавим некоторые важные нюансы.
- Определение количества интеграций
Начинается все с того, что вам нужно четко представить, сколько систем будет взаимодействовать друг с другом. Определение этого количества позволяет:
– Понять масштаб проекта.
– Распределить ресурсы и задать ожидания по времени выполнения.
- Наличие API
Следующим логическим шагом является проверка, имеются ли у этих систем API (интерфейсы программирования приложений) или возможность их предоставить. Этот момент критически важен, так как:
– Наличие API значительно упрощает интеграцию.
– Если API нет, то необходимо работать над его разработкой, что потребует дополнительных временных и финансовых ресурсов.
Совет: Если у системы еще нет API, рекомендуется не просто запрашивать его разработку, но и предложить конкретные кейсы использования. Это поможет владельцам систем понять, как именно их API может помочь в бизнесе.
- Запрос документации
Документация на системы — важный аспект, который поможет вам:
– Разобраться в том, как работают текущие системы.
– Избежать недоразумений на этапе интеграции.
– Понять, какие данные могут быть полезны или нужны для вашего проекта.
Также, стоит запрашивать сопутствующую документацию, которая поможет понять специфические процессы и термины, используемые в бизнесе. Пример: договоритесь о встречах с ключевыми пользователями, которые смогут объяснить бизнес-логику за системами.
- Обезличенные данные
Старый добрый принцип: “Тестируй в безопасной среде!” Позаботьтесь об обезличенных данных для тестирования интеграций. Это поможет вам:
– Избежать утечки данных.
– Соответствовать нормативным требованиям, особенно если данные содержат личную информацию.
Обязательно соедините подрядчика с службой безопасности. Их требования могут варьироваться — от шифрования данных до ограничений по доступу.
- Синхронные и асинхронные языки программирования
Хорошо бы иметь базовые знания о различиях между синхронными и асинхронными подходами в программировании. Это поможет вам:
– Понять, как лучше организовать взаимодействие между системами.
– Внедрить подходы для обработки данных, минимизируя задержку и обеспечивая высокую производительность.
- Решение проблемных ситуаций
Важно быть готовым к возможным проблемам, связанным с интеграцией:
– Ошибка в данных: Определите механизмы для верификации данных.
– Изменение требований: Будьте гибкими в своем проекте, учитывая, что бизнес может требовать изменений в процессе интеграции.
– Задержки: Поставьте четкие сроки для выполнения задач и организуйте регулярные статусы для всех вовлеченных сторон.
Интеграции могут стать сложным процессом, но с четким планом и качественной документацией можно значительно уменьшить риски. Напоминайте всем участникам команды о важности коммуникации и сотрудничества, чтобы каждый понимал свои задачи и был в курсе всей информации о проекте.
Неправильное понимание требований, недостаточная подготовка или слишком поздняя реакция на возникающие проблемы могут привести к серьезным задержкам и переплатам. Зная ключевые моменты и подготовившись к возможным трудностям заранее, вы сможете значительно снизить риски и оставить финансовую «дыру» позади. Успешная интеграция — это не только техническое решение, но и комплексный подход к планированию, взаимодействию и управлению проектом.