Чаще всего сложности возникают в том, что количество потоков достаточно большое (300+). Надо спроектировать обмены, чтобы не осталось «белых пятен», согласовать спецификации, выдержать единство принципов сопоставления данных, продумать порядок переключения систем и затем передать на поддержку. Поэтому далее мы поделимся нашим опытом как делать подобные проекты прозрачно, надежно и комфортно всем участникам. Рассмотрим жизненный цикл подобных работ.
Проектирование
Роли: Функциональный и технический архитекторы
Самый первый этап закладывает основу дальнейших работ, и он должен быть выполнен максимально качественно, чтобы избежать концептуальных ошибок. Когда мы говорим о крупном ИТ ландшафте – чаще всего это несколько десятков информационных систем и при проработке текущего состояния обменов и целевого состояния количество информационных потоков может достигать нескольких сотен. Такой объем данных удержать в голове и не ошибиться – крайне сложная задача, даже если у вас очень круто развита память. Здесь на выручку Функциональному архитектору приходит ПО класса System of Systems Integration (в нашем случае Integration management studio – IMS), которое позволяет оперировать всем ИТ ландшафтом в одном окне с детализацией до метаданных всех окружающих систем. При проектировании мы сначала должны поделить потоки данных на некоторые группы, которыми оперировать будет уже под силу. Для того, чтобы это сделать удобно, мы предлагаем следующую классификацию:
1. По видам потоков:
- НСИ
-Транзакционные данные
-Срезы данных (цен, остатков итп)
2. По сегментам данных:
Здесь деление происходит по доменам информации и их сегментам. Например:
· НСИ
o Контрагенты
- Поставщики
- Покупатели
- Прочие
o Договоры
- Договоры закупок
- Договоры продаж
- Договоры аренды
- Договоры прочей хоз деятельности
o Номенклатура
- Готовая продукция
- Производственные полуфабрикаты
- Сырье
Далее мы можем брать конкретный вид потоков и сегмент и заниматься его проработкой: кто будет первичным источником данных? Кто будет потребителем? Где интеграция будет по модели звезды, а где каскадом? Такая проработка позволит целостно взглянуть на каждый контур и не пропустить концептуальные детали.
На выходе мы получаем спроектированный состав интеграционных потоков.
Формирование требований
Роли: Функциональные аналитики
Здесь в игру вступают функциональные аналитики. Их задачей становится проработка интеграционных потоков уже с детализацией до реквизитного состава, событий наступления выгрузки и отборов, которые могут уточнять детализацию сегментов данных. Так же при этом виде работ необходимо понимать текущую модель работы ИС в ландшафте и целевую. Понять, что полнота потоков на каждом этапе изменения потоков будет обеспечена и не возникнет разрывов. Работа достаточно рутинная, но требует значительной степени внимания. Чтобы снизить риски человеческого фактора при проработке потоков + повысить скорость такого описания – нам явно потребуется ПО SoS, которое позволит оперировать метаданными всех рассматриваемых систем и помогать делать автосопоставление. Так же из этой работы последует определение правил идентификации данных при обмене между системами.
На выходе мы получаем стандартизированное ТЗ, которое уже в понятных терминах можно будет реализовывать разработчикам.
Разработка
Роли: функциональные аналитики, разработчики, QA
На этом этапе стоит уделить внимание понятным техническим моментам – делать хорошо, плохо не делать. Так же спроектировать сам механизм обменов, чтобы он был стабильным. Применительно к крупным ИТ ландшафтам можно утверждать, что наиболее часто встречающийся подход – это использование корпоративных шин данных, т.к. это значительно повышает скорость разработки и снижает затраты на разработку интеграционного шва. (В наших работах мы чаще всего используем Datareon, т.к. это решение качественно и надежно позволяет решить задачи обменов)
На этом же этапе необходимо понять, какие обмены необходимо покрыть автотестами, как их организовать и какие подходы в организации тестового контура использовать.
Так же надо отметить, что если постановка задач выполнена в стандартизированном виде для всей команды, то становится достаточно легко балансировать загрузку как внутри одной команды, так и передавать блоки работ между разными командами.
На выходе мы получаем разработанные согласно ТЗ механизмы обменов, которые готовы к запуску в продуктовом контуре.
Поддержка
Роли: специалисты службы поддержки
Поддержка обменов начинается не после вывода в продуктив, а немного ранее. На мой взгляд это временная точка, когда проектная команда согласовывает план переключения интеграционных потоков в привязке к датам и временной последовательности событий. Здесь возникает точка перепроверки результатов из пункта 1 – что выполнив переключение интеграционных потоков мы не оставим без данных каждую систему, которая попадает в наш периметр, а также перепроверим результаты проектирования из пункта 1.
Так же необходимо понять, к каким потокам будут предъявляться наибольшие требования к производительности и критичности по скорости трансляции рассматриваемых данных в другие системы. Для этих потоков необходимо реализовать инструменты сверки данных между системами, которые позволят, анализируя выборку данных за какой-то период либо показать отличия, либо убедиться в корректности обменов. Еще один из интересных артефактов вывода в продуктив интеграционных потоков – формирование инструментов мониторинга, которые позволят проактивно мониторить обмен наиболее критичными данными и оповещать ответственных об ошибках.
Ах да, куда же без корректной, живой документации? Если работа организована согласно вышеописанной методике – то мы автоматически при взаимодействии разработчиков с аналитиками в рамках 2 и 3 этапов получаем уже готовую документацию, которую не стыдно отдать группе поддержки.
Обеспечение Службы Безопасности информацией о потоках данных
Роли: специалисты службы безопасности, функциональный архитектор.
Чаще всего служба безопасности довольно плотно взаимодействует с ИТ подразделением, чтобы иметь максимально полную и прозрачную картину по ИТ ландшафту. Наибольший интерес представляют 2 вопроса:
- вопрос использования портов применительно к серверам приложений, тк это потенциальное окно во внешний мир,
- вопрос организации разделения доступа к данным разного уровня доступа. Например, что одна организация не видит НСИ другой организации. Так же в рамках этого пункта активно рассматривается вопрос данных, которые относятся к 152ФЗ.
Чтобы удовлетворить запросы службы безопасности оперативно, полно и без лишних издержек – на помощь нам приходит IMS (Integration management studio), которое нас сопровождало с самого первого этапа (проектирования).
На выходе мы получаем готовое описание системы, которое будет давать понятные ответы на вопросы по интеграционным потокам, в том числе про 152ФЗ.
Заключение
По итогу хочется сделать вывод, что использование специализированного ПО, включенного в процесс разработки, делает интеграционные работы более прозрачными, управляемыми, легко маршрутизируемыми и позволяет всем участникам данного вида работ быть в едином информационном пространстве. Снижаются риски человеческого фактора и издержки на обмен информацией между командами.
Автор: Валерий Немцов, менеджер продукта интеграции компании "Константа"
Материал подготовлен и предоставлен компанией «Константа»
marketing@standart1c.ru
8 (831) 28-28-227
