Невозможно представить современную информационную систему (далее – ИС), которая бы стояла особняком, и не была бы интегрирована с другими. Особенно, если мы говорим о корпоративных или государственных данных. Вопросу интеграций посвящены целые книги, такие как «Шаблоны интеграции корпоративных приложений» Грегора Хопа. Некоторые издания пытаются рассматривать не только технические, но и организационные вопросы интеграции (например, «Предметно-ориентированное проектирование (DDD)» Эрика Эванса). Между тем, современный уровень технологий и высокий уровень компетентности разработчиков очень сильно снижает технические риски, выставляя на первый план организационные. В этой статье мы рассмотрим интеграции информационных систем именно с точки зрения организационных рисков.
Взгляд на ИС сквозь призму команд
Как правило, при проектировании новой системы, или во время изучения ТЗ, на интеграции смотрят под следующими углами:
Интеграция одной подсистемы с другой;
Интеграция с другими ИС внутреннего ИТ-ландшафта заказчика (т.е. смежными ИС);
Интеграция с внешними ИС по отношению к Заказчику, т.е. за пределами его ИТ-ландшафта.
Не менее важно также рассмотреть каждую конкретную интеграцию с точки зрения команд. Под командой мы имеем ввиду группу, которая представляет определенные интересы организации или ее структуры. Например, проектная команда со стороны заказчика это одна команда, а инфобез заказчика – может быть совсем другой командой. Каждая команда имеет свои цели и интересы. Команда может как как помочь, так и существенно затруднить интеграцию.
Когда все участвующие команды стремятся к одной цели, то и интеграция с внешними системами делается просто. Конфликт же создает препятствия. Самоочевидная вещь.
Неприятно, когда дорабатывать ИС для поддержки интеграции должен ваш конкурент. Если он ведёт себя достойно, то всё будет в порядке. Но бывают и случаи, когда на словах перед заказчиком конкурент демонстрирует лояльность, а на деле саботирует любые нужные для интеграции действия.
Есть еще очень опасный и неочевидный вариант. Отсутствие команды разработки, которая может реализовать нужную вам поддержку интеграции в ИС. Самое банальное – ИС старая и связь с разработчиком утеряна. А сама ИС функционирует как «черный ящик». В этом случае все зависит от заказчика и его готовности пустить ваших специалистов на изучение этого «черного ящика».
Схема взаимодействия с поставщиком интеграции
В книге Эванса приводятся варианты схем взаимодействия команд при интеграции контекстов, часть из которых можно рассматривать и для интеграции систем.
Конформист. Команда, которой нужна интеграция, (команда Потребитель) полностью адаптируется к реализации. Команда разработчик реализации (команда Разработчик) живет полностью независимо.
Заказчик/Поставщик. Команда Потребитель ставит задачу на разработку интеграции и команда Разработчика реализует требования.
Открытый протокол. Публичное API, которое доступно всем, опубликовано в открытых источниках и, как правило, имеет хорошую документацию.
На предварительных этапах многие приходят к выбору либо схемы Заказчик/Поставщик, либо Публичного API. Всем понятно, что схема Конформист не позволит взять исполнителю контракта хоть какую-то ответственность на себя. Но, не смотря на заявления заказчика, по итогу любая схема может превратиться в Конформиста.
Наша задача определить детали схемы взаимодействия как можно раньше чтобы выявить элементы скрытой схемы Конформиста. При предполагаемой схеме Поставщик/Заказчик на этапе предконтрактных работ должно насторожить следующее:
Заказчик не знакомит команду Потребитель с командой Разработчик.
Команда Разработчик не готова детально обсуждать схему взаимодействия и другие технические аспекты во время выполнения работ.
Есть информация, что отношения между Заказчиком ИС и командой Разработчик натянутые (интеграция с вами может стать предметом чужих торгов).
Вы не ощущаете у Заказчика сил продавливать необходимость реализации интеграции в команде Разработчик.
При предлагаемой схеме Публичного API могут насторожить такие факты:
API еще не готово, но «обязательно будет готово к окончанию вашего контракта». Это очень существенный риск, даже если API должно быть готово за полгода до окончания контракта.
API готово, но вы будете первыми, кто к нему подключится.
Заказчик ИС не готов предоставить описание интеграционного взаимодействия. Важно, что в это описание должна входить не только документация на API, но и регламенты подключения. Регламент должен содержать организационную часть (кому и что писать) и техническую часть (какие протоколы и оборудования сетевого уровня надо использовать).
Текущие возможности API не закрывают потребности ваших интеграций.
Как защитить проект на этапе контрактации
При контрактации самая распространенная схема — это Поставщик/Заказчик.
В теории вы, как возможный исполнитель контракта, должен составить ТЗ для необходимых вам изменений, и передать его на согласование Заказчику. А он уже передаст его команде Разработчик, которая выполнит Ваше ТЗ «в кратчайшие сроки и с наилучшим качеством». Только в жизни все может получиться по-другому.
Заказчик, как правило, укажет на Исполнителя и скажет, что нужно договариваться с ним напрямую за счет бюджета проекта. А это уже совсем другая история. Появляется огромная проблема непредсказуемости по всем направлениям – начиная от готовности взяться за подряд и заканчивая его сроками и бюджетом. Подрядчик внешняя организация, и формально рычагов давления на неё нет.
Для минимизации рисков обязательно нужно четко прописывать зону ответственности Заказчика в контракте (используйте пункт «Вклад Заказчика» в ТЗ). При этом прописывайте вклад как можно конкретнее. Заказчик должен:
Предоставить всю необходимую документацию для реализации интеграции.
Предоставить тестовые данные (про тестовые данные у нас есть отдельная статья.
Обеспечить сетевую связность.
Заключить договор субподряда с командой Разработчиком интеграции (это сложный пункт).
Очень важно стремиться к тому, чтобы ответственность за организационные вопросы максимально лежала на плечах заказчика ИС, и чтобы эти договоренности были зафиксированы.
Кстати, иногда это бывает не так просто. У нас был случай при разработке инфраструктурной ИС X. По замыслу, порядка 30 региональных информационных систем должны были подключиться к ИС X. При этом заказчик настаивал на ответственности разработчика X за подключение этих ИС, и очень настойчиво хотел вписать это требования в условия закрытия контракта.
Крайне желательно до подписания контракта проработать ТЗ и договоры со всеми субподрячиками, которые будут участвовать в проекте. Проведение такой работы существенно снижает риски. Когда вы подписываете контракт, имея на руках ТЗ и макеты договоров, все участники имеют больше ясности насчет предстоящих задач, сроков и бюджета. Вы заранее выстраиваете отношения с внешними командами.
Также следует иметь в виду следующее (особенно это характерно при работе с гос. Заказчиками): часть работ вам придется делать в любом случае, даже если это не входит в контракт. По интеграциям это часто бывают различные проекты соглашений, которые дают юридическую основу для обмена данными между ИС, принадлежащим разным ведомствам.
Еще один важный момент. Если есть возможность, то всячески избегайте требований к сдаче проекта, связанных с конкретной реализацией интеграций, если это не типовые подключения к СМЭВ или хорошо известные вам системы из IT-ландшафта заказчика. Обязательно требуйте пункта, который говорит о том, что в случае недоступности внешней интеграции, система может быть сдана на эмуляторе интеграции внешней системы (проще говоря – на моках). Разумные заказчики включают это допущение.
Минимизация рисков на этапе разработки
Независимо от того, как хорошо мы подстраховались в зоне ответственности заказчика, ещё остается вопрос времени. Время выполнения работ надо всегда держать на особом контроле.
Если не получилось составить ТЗ до контракта, или не удалось получить подробную документацию, то стартовать работы нужно сразу после заключения контракта.
Одновременно с этим следует запрашивать:
Тестовые данные (почему важно как можно скорее получить тестовые данные, мы подробно писали в статье «Информационная Система с данными и без»).
Доступы и сетевые связности.
Подготовку документов для юридического обоснования интеграции.
Если у вас неплохие отношения между командами, то доступ к тестовым стендам вполне могут дать без соглашения об интеграции.
Но не стоит оттягивать старт упомянутых активностей, какими бы ни были отношения с заказчиком и командами.
Зачастую могут всплыть неожиданные требования (часто – со стороны безопасников). Например, может потребоваться конкретный поставщик оборудования для обеспечения сетевой связности, как следствие для завершения контракта Заказчик будет вынужден купить себе новое оборудование.
У крупных заказчиков часто есть свои внутренние интриги, разборки и клановые войны. Очень важно, чтобы ваша компания не участвовала в них, и оставалась нейтральной и благожелательной ко всем. Ваша главная цель – сделать качественную ИС и ввести ее промышленную эксплуатацию. А интриги оставьте другим.
Что делать, когда интеграция пошла не по плану
Есть печальная новость: если интеграции зашли в тупик, то хороших вариантов действия уже нет.
Особенно, если вы разрабатываете в рамках госконтракта, и не предусмотрели пункт о сдаче на эмуляторах.
Есть пара возможных действий, с которыми можно пробовать продвигаться вперед:
Начинаем писать официальные заказные письма Заказчику с требованиями предоставить доступ, документацию и т.п. Здесь сильно помогает пункт контракта «Вклад Заказчика», на который и будем ссылаться. Эти письма помогут доказать, что не вы виноваты в проблеме сдачи контракта в полном объеме.
В соответствии с ФЗ-44 и Гражданским кодексом вы можете приостановить работы по контракту до получения нужной информации. Для этого сценария вам следует предварительно изучить вопрос.
Надо понимать, чтобы оба этих пункта это уже, по сути, конфликтная ситуация с Заказчиком, что само по себе крайне плохо. Ждать условия завершения контракта можно долго, а вы ведь рассчитывали на определенные сроки выполнения. У вас команда разработки простаивает.
Переключить разработчиков на неопределенный срок, а потом снова собирать и включать обратно в проект – это очень не просто. А уж про разрыв денежных потоков от такого ожидания и говорить не приходится, ведь команда не виновата, что другие не успели (или не захотели), а все должны зарплату получить в срок.
Резюме
Итак, что нужно сделать при проектировании и разработке интеграции:
Определить список интеграций.
Понять, какие команды будут участвовать в каждой интеграции. Выяснить, как они связаны с Заказчиком, насколько он может оказывать на них влияние. В идеале познакомиться с ним до заключения контракта.
Узнать технические аспекты интеграции. Определить схему работы (Заказчик/Поставщик или Публичное API), получить документацию. В случае публичного API обязательно узнать, сколько интеграций по нему уже было сделано и насколько предоставляемые возможности удовлетворяют вашим требованиям.
Отдельно обращайте внимание на обеспечение сетевой связности и требования информационной безопасности.
В договоре или контракте чётко обозначайте «Вклад Заказчика». При наличии даже малейших рисков настаивайте на включении в контракт пункта о возможности сдачи проекта на эмуляторах внешних систем.
Интеграции должны стать ключевой точкой контроля и мониторинга на этапе разработки. Работы по этому треку надо запускать сразу после заключения контракта.
Успех любой интеграции так или иначе зависит от взаимоотношений между людьми и командами. Тщательно формируйте команду из таких людей, которые хотят и могут выстраивать крепкие рабочие отношения со всеми, кто участвует в проекте. Это, наверное, ключевой фактор успешной реализации любой интеграции.
Сергей Кузнецов
Леонид Выговский
