Чаще всего сложности связаны с тем, что количество потоков достаточно большое (300+). Надо спроектировать обмены, чтобы не осталось белых пятен, согласовать спецификации, выдержать единство принципов сопоставления данных, продумать порядок переключения систем и затем передать на поддержку. Ниже мы поделимся своим опытом, как реализовывать такие проекты, чтобы они были прозрачны, надежны и комфортны всем участникам. Рассмотрим жизненный цикл подобных работ.
1. Проектирование
Роли: функциональный и технический архитекторы
Самый первый этап закладывает основу дальнейших работ, и он должен быть выполнен максимально качественно, чтобы избежать концептуальных ошибок. Когда мы говорим о крупном ИТ-ландшафте, чаще всего это несколько десятков информационных систем и при проработке текущего состояния обменов и целевого состояния количество информационных потоков может достигать нескольких сотен. Такой объем данных удержать в голове и не ошибиться – крайне сложная задача, даже если у вас очень круто развита память. Здесь на выручку функциональному архитектору приходит ПО класса System of Systems Integration (в нашем случае Integration management studio – IMS), которое позволяет оперировать всем ИТ-ландшафтом в одном окне с детализацией до метаданных всех окружающих систем. При проектировании мы сначала должны поделить потоки данных на группы, которыми оперировать будет уже под силу. Для того чтобы это сделать удобно, мы предлагаем следующую классификацию:
1. По видам потоков:
- НСИ.
- Транзакционные данные.
- Срезы данных (цен, остатков и т. п.)
2. По сегментам данных. Здесь деление происходит по доменам информации и их сегментам. Например, НСИ:
- Контрагенты: поставщики, покупатели, прочие.
- Договоры: договоры закупок, договоры продаж, договоры аренды, договоры прочей хоздеятельности.
- Номенклатура: готовая продукция, производственные полуфабрикаты, сырье.
Далее мы можем брать конкретный вид потоков и сегмент и заниматься его проработкой: кто будет первичным источником данных, кто будет потребителем, где интеграция будет по модели звезды, а где каскадом. Такая проработка позволит целостно взглянуть на каждый контур и не пропустить концептуальные детали.
На выходе мы получаем спроектированный состав интеграционных потоков.
2. Формирование требований
Роли: функциональные аналитики
Здесь в игру вступают функциональные аналитики. Их задачей становится проработка интеграционных потоков уже с детализацией до реквизитного состава, событий наступления выгрузки и отборов, которые могут уточнять детализацию сегментов данных. Также при этом виде работ необходимо понимать текущую модель работы ИС в ландшафте и целевую. Уяснить, что полнота потоков на каждом этапе изменения потоков будет обеспечена и не возникнет разрывов. Работа достаточно рутинная, но требует значительной степени внимания. Чтобы снизить риски человеческого фактора при проработке потоков повысить скорость такого описания, нам явно потребуется ПО SoS, которое позволит оперировать метаданными всех рассматриваемых систем и помогать делать сопоставление в автоматическом режиме. Также из этой работы последует определение правил идентификации данных при обмене между системами.
На выходе мы получаем стандартизированное ТЗ, которое уже в понятных терминах можно будет реализовывать разработчикам.
3. Разработка
Роли: функциональные аналитики, разработчики, QA
На этом этапе стоит уделить внимание понятным техническим моментам – делать хорошо, плохо не делать. А также спроектировать сам механизм обменов, чтобы он был стабильным. Применительно к крупным ИТ-ландшафтам можно утверждать, что наиболее часто встречающийся подход – использование корпоративных шин данных, так как это значительно повышает скорость разработки и снижает затраты на разработку интеграционного шва. (В наших работах мы чаще всего используем Datareon, так как это решение качественно и надежно позволяет решить задачи обменов.)
На этом же этапе необходимо понять, какие обмены необходимо покрыть автотестами, как их организовать и какие подходы в организации тестового контура использовать.
Кроме того, надо отметить, что если постановка задач выполнена в стандартизированном виде для всей команды, то становится достаточно легко балансировать загрузку как внутри одной команды, так и передавать блоки работ между разными командами.
На выходе мы получаем разработанные...