Интеграция ИТ-систем начинается не с API

В корпоративном ИТ-ландшафте десятки решений обмениваются данными и участвуют в одних бизнес-процессах. Но клиент в CRM уже обновлен, в ERP по-прежнему числится старый контрагент, а в СЭД документ живет с другим статусом. После обновлений и доработок таких расхождений становится больше, а выяснить, где именно возникла проблема и кто должен ее устранять, удается не сразу.

На виртуальном круглом столе, организованном журналом IT Manager и экспертным сообществом «ИТ-Диалог», ИТ-директора и представители ИТ-компаний обсуждали слабые места корпоративной интеграции — API, мастер-данные, обновления, архитектурный долг и ответственность за общий процесс. Модерировал дискуссию Антон Кузнецов, начальник отдела развития пассажирских сервисов Петербургского метрополитена.

Когда API недостаточно

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

Андрей Власенко (УК «Старт») приводит пример с электронными транспортными накладными. Регуляторное требование появляется тогда, когда у компании уже работают системы транспортной логистики, ERP, ЭДО и другие решения. Нужные для ЭТРН сведения находятся в разных местах, и их требуется собрать в единый процесс, не останавливая действующие системы. «Если бы мы в начале всех интеграций видели весь ландшафт систем и конечную цель, проблем бы не было. Проблема в том, что требования появляются не в начале работы, а в моменте, и их нужно реализовывать, учитывая функциональные и технические требования всего ландшафта», — объясняет Андрей.

Разнородность систем остается одной из причин, по которым такие проекты трудно укладываются и в сроки, и в бюджет. У поставщиков разные архитектурные подходы и свои способы интеграции, а общего стандарта, который снимал бы основную часть вопросов, нет. Одновременно растут требования к самим связям между системами. Недостаточно просто передать данные из точки А в точку Б: нужны повторная доставка, контроль ошибок, трассировка, производительность, отказоустойчивость, а у крупных заказчиков уже встречаются требования к катастрофоустойчивости.

«Я, пожалуй, знаю единицы проектов, где затраты по интеграции удавалось удержать в требуемом бюджете. Всегда возникает что-то, всегда бэклог команд расписан на годы вперед, интеграционные команды всегда в дефиците», — говорит Дмитрий Гаврин («Диасофт»).

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

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

Для интегратора обещания поставщика «у нас есть API» явно недостаточно. Полина Дуйкова («Софтлайн Решения», входит в ГК «Софтлайн) рассказывает о недавнем проекте крупной промышленной компании, где системе документооборота требовалось взаимодействовать более чем с 250 системами. Продукты для таких проектов проходят внутреннюю архитектурную проверку, тестируются в «песочницах» и на сквозных сценариях. Отдельно проверяется, действительно ли заявленный коннектор годится для конкретного корпоративного ландшафта. Иногда готовый коннектор вообще оказывается не лучшим способом интеграции. Тогда в зависимости от задачи используются API, обмен через базы данных или RPA.

Есть и другой подход — не наращивать количество связей без необходимости. В «Теплообменнике» сознательно держат минимально достаточное количество систем. Часть интеграций там написана собственными силами и работает много лет, а некоторые — с середины 2000-х. Архитектура строится вокруг данных, а не вокруг конкретных продуктов. «Самое главное — это не системы. Самое главное — данные, которые такие системы создают. Поэтому главный принцип, который нам позволяет справляться с трудностями интеграции, — данные отделяются от систем и имеют определенный статус», — говорит Александр Стручков («Теплообменник»).

Корпоративная шина, MDM и открытый API сами по себе не определят, какой справочник главный и кто имеет право менять запись. У Олега Смирнова (Fplus) на этот счет есть практичная формулировка: «Мы все рассматриваем интеграцию как технический проект, а на самом деле она, как и проект MDM, в большей степени организационная. Основная сложность в том, что всегда нужно договориться».

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

Проверка до контракта

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

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

Обязательную внутреннюю архитектурную проверку проходят продукты, которые предполагается использовать в крупных проектах «Софтлайн Решений». Есть «песочницы» с ERP и другими корпоративными системами, где можно посмотреть работу интеграций не по презентации, а на конкретных сценариях. Для заказчика такой пилот тоже может быть отдельным платным этапом. Небольшие расходы до приобретения иногда оказываются дешевле, чем неудачно выбранный продукт с высокой стоимостью дальнейшей эксплуатации.

При этом проверять нужно не только сам API. В одном проекте обмен может идти через интерфейсы приложений, в другом — через базу данных, где-то остается RPA. Для закрытых контуров требования становятся более строгими. Сергей Ершов («Электроавтоматика») привел пример полностью изолированной сети, куда данные приходится переносить физически. Найти готовое решение для асинхронного обмена между открытым и закрытым контурами оказалось значительно сложнее, чем найти продукт с хорошо описанным API.

Есть и другая крайность — пытаться перенести в прикладную систему весь набор требований к интеграции. В одном из проектов «Диасофт» заказчик добавлял к простому обмену все новые условия: повторную отправку при недоступности соседней системы, контроль доставки, трассировку и другие механизмы. И таких требований набралось около сотни, что привело к заметному увеличению сроков проекта.

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

Кто отвечает за общий процесс

Иногда сбой возникает именно между двумя системами. У первого поставщика все работает. У второго — тоже. А бизнес-процесс в это время стоит. И рассчитывать, что кто-то из вендоров сам возьмет на себя чужой участок, не приходится. По опыту Олега Смирнова (Fplus), поставщики стараются ограничить ответственность даже в пределах собственного продукта. Значит, еще до запуска нужно решить, кто отвечает за интеграцию целиком и кто разбирается с проблемой, если она возникает между системами.

Для предприятий с закрытым контуром цена такой неопределенности особенно высока. В «Электроавтоматике» подрядчик не может подключиться удаленно, специалист должен приехать на площадку, а его визит — пройти согласование. Иногда ждать приходится неделю. «Получается, что нам экономически выгоднее просто взять человека в штат и пилить все это своими руками. Потому что любой приезд, особенно если специалист достаточно редкий, упирается в то, что нам нужно сегодня человека согласовать через неделю. И весь этот промежуток у нас всё это будет стоять», — говорит Сергей Ершов.

В «Теплообменнике» сильная собственная ИТ-команда стала насущной потребностью. «У нас все, что касается ИТ — это ответственность ИТ-директора», — поясняет Александр Стручков. Но и после внедрения вендор не должен исчезать из общей картины. Если партнер рассчитывает на долгие отношения с заказчиком, от него ждут участия в тех проблемах, которые неизбежно появятся позже.

Но даже такая жесткая формула не делает ИТ владельцем всех данных компании. «Если руководство получило неверную отчетность, значит, данные не проверили до сдачи. За корректность цифр отвечает финансовый департамент, который их сдает. А задача ИТ вместе с ним — закрыть этот процесс контрольными точками, чтобы подобные ошибки в принципе не могли попасть в отчетность», — приводит пример Олег Смирнов.

Чем больше систем, тем длиннее список тех, кто может сказать: «Это не у нас». У одного подрядчика — документооборот, у другого — ERP, у третьего — инфраструктура. В одном из проектов «Софтлайн Решений» вместе с заказчиком работали еще более четырех партнеров. «Все зоны ответственности определяются. Тот контур, который находится вне, например, документооборота, с которым нам нужно интегрироваться, — это зона ответственности наших партнеров. Если другие партнеры отвечают за поддержку ERP-системы, то на них перекладывается такая ответственность и они тоже становятся частью большого проекта», — комментирует Полина Дуйкова («Софтлайн Решения»).

В «Диасофт» для таких случаев отдельно выделяют интеграционное тестирование и назначают ответственных с обеих сторон. Проверка «сообщение ушло — сообщение пришло» здесь ничего не гарантирует. Важно, что получилось после этого у бизнеса.

Обновление одной системы касается всех

«Интеграция — это не какая-то одна разовая история, это скорее отдельный объект эксплуатации, который необходимо тестировать, сопровождать, изменять, потому что интеграция имеет свой жизненный цикл», — считает модератор круглого стола Антон Кузнецов. Одна система получает новую версию, в другой меняется структура данных, третью дорабатывают под новое требование. Обновилась вроде бы одна, а работа появляется у всех соседей.

У Олега Смирнова здесь простой принцип: смена системы не должна ломать весь обмен данными. Данные продолжают ходить по прежней схеме, а изменение правил интеграции — отдельная задача, а не повод переделывать всё заново.

Со стороны вендора один из способов снизить риск — не ломать старые интерфейсы при выпуске новой версии. «Если мы делаем новую версию прикладного продукта и вносим изменения в API, то предыдущие версии тоже должны корректно работать. Исключения мы не делаем», — говорит Дмитрий Гаврин («Диасофт»).

Обратная совместимость, впрочем, решает не все. Сергей Ершов («Электроавтоматика») опасается другой крайности: если бесконечно тянуть за продуктом весь legacy, развитие начинает зависеть от старых способов обмена. Для компании важнее, чтобы не менялся смысл передаваемых объектов, а новые версии протокола можно было поддерживать без переделки всей связки.

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

У «Теплообменника» своя защита от сюрпризов — обновляться без лишней спешки. Новую версию ставят только тогда, когда для этого есть причина, часто совмещая обновление с развитием системы. Исключение — продукты, которые приходится регулярно менять из-за законодательства. Перед переходом проверяют, что изменилось и как это повлияет на соседние системы.

Единый справочник

MDM, НСИ, корпоративная шина — все это помогает работать с данными, но не отвечает на главный вопрос. Какие из этих данных считать правильными? Для «Теплообменника» ответ однозначный: сначала нужно определить, где они возникают, кто имеет право их менять, кто использует и кто отвечает за результат. Уже потом эти правила можно закреплять ролями, доступами и бизнес-процессами, уверен Александр Стручков.

Подобный опыт у Олега Смирнова уже был — в Асконе подразделение нормативно-справочной информации подчинили ИТ. Он объясняет это тем, что одна вертикаль позволяет быстрее формировать правила и жестче контролировать их исполнение: когда НСИ и ИТ разведены по разным подразделениям, любое изменение упирается в согласования, а соблазн переписать справочник под удобство закупок, бухгалтерии или другого отдела растет. Документ здесь — не формальность, а следствие того, что правило должно работать одинаково для всех. Хочешь его изменить — меняй утвержденный документ, а не запись в системе по договоренности. Лишняя гибкость в этом месте не помогает, а вредит.

Такой подход годится не всем, но он хорошо показывает суть проблемы. Единый справочник не становится единым в момент покупки MDM. Если бухгалтерия, закупки и производство по-прежнему считают правильными разные записи, система лишь получает возможность аккуратно хранить все версии разногласий.

Временное решение не должно становиться постоянным

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

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

Облако могло бы снять часть таких ограничений, но подходит далеко не всем. Алексей Петрухин напоминает, что для компаний, связанных с ОПК, такой вариант часто закрыт требованиями регуляторов. Проект приходится подстраивать под сроки поставки собственного оборудования, даже если бизнесу мощности нужны раньше.

У других критерий проще: ИТ-решение имеет смысл до тех пор, пока помогает предприятию выполнять основную работу. «Интеграция, да и вообще любые эти решения для промышленного предприятия — это не цель, а способ достижения цели. И вот как только подобные решения начинают тормозить достижение цели или мешать, в такой момент надо задумываться об их модернизации, смене, развитии», — говорит Александр Стручков.

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

Чтобы не искать автора через три года

Чем больше система зависит от конкретного подрядчика, тем дороже может оказаться ее дальнейшая жизнь. В крупной производственной компании Алексея Петрухина поэтому стараются не использовать частные разработки, которые привязывают заказчика к одному исполнителю. «ТЗ и договор составляются таким образом, чтобы мы минимально зависели от поддержки вендора или интегратора и имели максимально документированную систему», — говорит Алексей Петрухин.

Одного описания API для этого мало. В техническом задании нужны проектные решения по интеграции, программа и методика испытаний, условия гарантии. После запуска появляются требования к технической поддержке: SLA, время реакции на сбой, порядок работы с изменениями. Полина Дуйкова («Софтлайн Решения») советует еще до выбора подрядчика посмотреть, как вообще выглядит его документация. Несколько страниц из справки вендора могут оказаться слабым подспорьем для команды, которой через два года придется восстанавливать устройство интеграции.

У Андрея Власенко (УК «Старт») требования делятся на два основных блока — функциональные и технические. Причем до начала работ подробно зафиксировать оба удается не всегда. В одном из проектов часть функциональных требований пришлось дописывать уже по ходу процесса, когда техническая реализация дала лучшее понимание будущего результата.

Заметно вырос и объем требований, которые вообще не относятся к функциям продукта. По наблюдениям Дмитрия Гаврина («Диасофт»), десять-пятнадцать лет назад заказчика в основном интересовало, что умеет система. Теперь у крупных компаний значительная часть требований относится к информационной безопасности, надежности, квалификации подрядчика, отказо- и катастрофоустойчивости. Проверяют уже и то, что произойдет при недоступности целого ЦОДа.

У Андрея Власенко нашлась история о том, чем заканчивается недокументированная интеграция: «У меня в одной компании была недокументированная интеграция: она была воплощена в человека, переносившего данные из одной системы в другую. А потом человек уволился, и все стали искать, почему данные перестали ходить». Позже выяснилось, что у бывшего сотрудника была собственная «подпольная кличка» с говорящим названием «Шина данных».

Интеграция должна окупаться

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

«Случается, две системы дешевле интегрировать, посадив условную машинистку, которая будет просто перебивать данные туда и сюда. Просто дешевле. И надежнее: никакие версии протоколов не нужны», — говорит Сергей Ершов («Электроавтоматика»). Решение выглядит архаично, зато не ломается после обновления API и устраивает службу ИБ.

Для ИТ это не самый красивый вариант, но бизнесу красота архитектуры сама по себе ничего не дает. Александр Стручков («Теплообменник») предлагает оценивать такие решения по тому, помогают ли они предприятию выпускать продукцию быстрее и качественнее. Если интеграция начинает тормозить работу, ее нужно менять. Пока она выполняет задачу и стоимость устраивает компанию, ее техническое несовершенство еще не повод затевать перестройку.

Здесь же возникает вопрос о роли ИТ в экономике компании. Для Сергея Ершова это уже не просто статья расходов: «Я стараюсь продвигать мысль, что ИТ — это часть системы, которая зарабатывает деньги. Можно не вкладываться в ИТ, можно сократить или заменить людей, но тогда и сама система в какой-то момент перестанет зарабатывать».

На промышленном предприятии эта логика постоянно сталкивается с конкуренцией за бюджет. Алексей Петрухин замечает, что при выборе между новым производственным оборудованием, которое даст понятный эффект на ближайшем горизонте, и вложениями в ИТ руководство скорее отдаст деньги производству. Экономия на ИТ, однако, никуда не исчезает. Она просто переносится вперед. «Не вкладываясь в ИТ своевременно, в развитие, интеграции, компания на самом деле накапливает некий долг, который она все равно заплатит, но только позже цена будет несколько выше», — добавляет эксперт.

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

***

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

Круглый стол начинался с вопроса, почему хорошие ИТ-системы плохо работают вместе. За время обсуждения стало понятно, что дело далеко не всегда в самих системах. Чаще проблемы появляются между ними — в данных, договоренностях, ответственности и в том, что никто заранее не подумал, как эта связка будет жить после запуска.

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