Организация интеграционных работ в большом ИТ-ландшафте

Роли: Функциональный и технический архитекторы
Самый первый этап закладывает основу дальнейших работ, и он должен быть выполнен максимально качественно, чтобы избежать концептуальных ошибок. Когда мы говорим о крупном ИТ ландшафте – чаще всего это несколько десятков информационных систем и при проработке текущего состояния обменов и целевого состояния количество информационных потоков может достигать нескольких сотен. Такой объем данных удержать в голове и не ошибиться – крайне сложная задача, даже если у вас очень круто развита память. Здесь на выручку Функциональному архитектору приходит ПО класса System of Systems Integration (в нашем случае Integration management studio – IMS), которое позволяет оперировать всем ИТ ландшафтом в одном окне с детализацией до метаданных всех окружающих систем. При проектировании мы сначала должны поделить потоки данных на некоторые группы, которыми оперировать будет уже под силу.

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

• НСИ
• Транзакционные данные
• Срезы данных (цен, остатков итп)

2. По сегментам данных:
Здесь деление происходит по доменам информации и их сегментам. Например:

• НСИ
• Контрагенты
• Поставщики
• Покупатели
• Прочие
• Договоры
• Договоры закупок
• Договоры продаж
• Договоры аренды
• Договоры прочей хоз деятельности
• Номенклатура
• Готовая продукция
• Производственные полуфабрикаты
• Сырье

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

На выходе мы получаем спроектированный состав интеграционных потоков.

Роли: Функциональные аналитики
Здесь в игру вступают функциональные аналитики. Их задачей становится проработка интеграционных потоков уже с детализацией до реквизитного состава, событий наступления выгрузки и отборов, которые могут уточнять детализацию сегментов данных. Так же при этом виде работ необходимо понимать текущую модель работы ИС в ландшафте и целевую. Понять, что полнота потоков на каждом этапе изменения потоков будет обеспечена и не возникнет разрывов. Работа достаточно рутинная, но требует значительной степени внимания. Чтобы снизить риски человеческого фактора при проработке потоков + повысить скорость такого описания – нам явно потребуется ПО SoS, которое позволит оперировать метаданными всех рассматриваемых систем и помогать делать автосопоставление. Так же из этой работы последует определение правил идентификации данных при обмене между системами.

На выходе мы получаем стандартизированное ТЗ, которое уже в понятных терминах можно будет реализовывать разработчикам.

Роли: функциональные аналитики, разработчики, QA
На этом этапе стоит уделить внимание понятным техническим моментам – делать хорошо, плохо не делать. Так же спроектировать сам механизм обменов, чтобы он был стабильным. Применительно к крупным ИТ ландшафтам можно утверждать, что наиболее часто встречающийся подход – это использование корпоративных шин данных, т.к. это значительно повышает скорость разработки и снижает затраты на разработку интеграционного шва. (В наших работах мы чаще всего используем Datareon, т.к. это решение качественно и надежно позволяет решить задачи обменов).

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

На выходе мы получаем разработанные согласно ТЗ механизмы обменов, которые готовы к запуску в продуктовом контуре.