Интеграция систем и модулей — это, пожалуй, одна из самых сложных задач в ИТ; соответственно, любые задачи, где есть передача данных из одних систем в другие - самые сложные для системного аналитика.
Делюсь с вами алгоритмом, по которому я обычно думаю, когда сталкиваюсь с интеграциями:
1. Анализ бизнес-потребности. Зачем нам интеграция? Какие бизнес-процессы или юскейсы она будет поддерживать?
2. Какие системы участвуют в интеграции? В каких системах есть данные, и в каких системах они в результате интеграции должны оказаться?
3. Детализированные функциональные требования: какая система в какой ситуации должна показать или использовать данные из другой системы; сделать запрос; передать данные по своей инициативе. Тут мы предварительно можем прикинуть, ну или хотя бы обсудить: кто является инициатором обмена? Синхронный или асинхронный обмен? Какой стиль интеграции мы можем использовать? (Передача файлов, общую БД, синхронные вызовы/веб-хуки/сокеты, асинхронный обмен через промежуточную среду/очередь). Какой паттерн управления обменом используем: оркестрацию или хореографию?
4. Регламент обмена данными в виде таблицы: | система источник | система приёмник | расписание или событие, по которому стартует передача | что именно передается: один объект, набор объектов, по какому признаку отфильтрованы? Какие поля объектов: все; явно перечисленные; только изменившиеся?.. Нужна ли агрегация или расчеты? | — это стараемся писать точки зрения бизнеса.
5. Количественные показатели интеграции: ожидаемая интенсивность (частота передач), ожидаемый объем (одной порции данных), это разовая передача или потоковая, перспективы роста интенсивности и объемов, число систем-клиентов - тут мы пытаемся понять, есть у нас где-то хайлоад, или всё так просто. Если какой-то показатель вылезает за миллионы или тысячи/сек., то дальше уже всё проектируем гораздо аккуратнее. Результат можно зафиксировать в виде НФТ или показателей качества, добавив требования к доступности, настраиваемости и безопасности.
6. Детальная спецификация данных. Тут нужно выявить — в каких системах в каком виде данные лежат, кто является мастер-источником для каких данных, что именно нужно передавать, какие использовать идентификаторы(!), откуда берем и как синхронизируем справочники.
7. Преобразования и мэппинги. Поняв структуры данных, описываем их преобразования и как они друг на друга маппируются. (Часто всё проектирование интеграций только к этому пункту сводится, а остальные аспекты игнорируются и реализуются как придётся, без анализа).
8. Способы взаимодействия: синхронное/асинхронное, прямое/через промежуточную очередь, оркестрация/хореография, что вообще интегрируемые системы могут, а то может там только файловый обмен возможен. Как обеспечиваем требования безопасности, нужно ли шифрование/хэширование/маскирование/обезличивание, как устроена аутентификация и проверка полномочий.
9. Детальный сценарий обмена (диаграмма последовательности + текстовый сценарий).
10. Общие требования к обработке ошибок, журналированию, мониторингу. Где-то тут, когда начинаем думать про ошибки, возникают вопросы про гарантию доставки, идемпотентность и хранение переданных ранее данных. По обработке ошибок по сути у нас два решения: а) система, обнаружившая ошибку (кстати, кто может обнаружить ошибку?), пытается её исправить; б) система оповещает людей, которые уже сами пытаются решить проблему. Эти решения не взаимоисключающие. Кроме того, нужно зафиксировать ошибку в журнале (в каком? что именно записать? и т.п.).
11. Выбираем уже окончательно стиль интеграции и конкретную технологию или решение.
12. Проходим пункты 7-10 ещё раз, фиксируя конкретные и детальные решения, связанные с выбранной технологией. Дальше уже проект интеграции дробится на требования к каждой отдельной системе, участвующей в интеграции.
Делюсь с вами алгоритмом, по которому я обычно думаю, когда сталкиваюсь с интеграциями:
1. Анализ бизнес-потребности. Зачем нам интеграция? Какие бизнес-процессы или юскейсы она будет поддерживать?
2. Какие системы участвуют в интеграции? В каких системах есть данные, и в каких системах они в результате интеграции должны оказаться?
3. Детализированные функциональные требования: какая система в какой ситуации должна показать или использовать данные из другой системы; сделать запрос; передать данные по своей инициативе. Тут мы предварительно можем прикинуть, ну или хотя бы обсудить: кто является инициатором обмена? Синхронный или асинхронный обмен? Какой стиль интеграции мы можем использовать? (Передача файлов, общую БД, синхронные вызовы/веб-хуки/сокеты, асинхронный обмен через промежуточную среду/очередь). Какой паттерн управления обменом используем: оркестрацию или хореографию?
4. Регламент обмена данными в виде таблицы: | система источник | система приёмник | расписание или событие, по которому стартует передача | что именно передается: один объект, набор объектов, по какому признаку отфильтрованы? Какие поля объектов: все; явно перечисленные; только изменившиеся?.. Нужна ли агрегация или расчеты? | — это стараемся писать точки зрения бизнеса.
5. Количественные показатели интеграции: ожидаемая интенсивность (частота передач), ожидаемый объем (одной порции данных), это разовая передача или потоковая, перспективы роста интенсивности и объемов, число систем-клиентов - тут мы пытаемся понять, есть у нас где-то хайлоад, или всё так просто. Если какой-то показатель вылезает за миллионы или тысячи/сек., то дальше уже всё проектируем гораздо аккуратнее. Результат можно зафиксировать в виде НФТ или показателей качества, добавив требования к доступности, настраиваемости и безопасности.
6. Детальная спецификация данных. Тут нужно выявить — в каких системах в каком виде данные лежат, кто является мастер-источником для каких данных, что именно нужно передавать, какие использовать идентификаторы(!), откуда берем и как синхронизируем справочники.
7. Преобразования и мэппинги. Поняв структуры данных, описываем их преобразования и как они друг на друга маппируются. (Часто всё проектирование интеграций только к этому пункту сводится, а остальные аспекты игнорируются и реализуются как придётся, без анализа).
8. Способы взаимодействия: синхронное/асинхронное, прямое/через промежуточную очередь, оркестрация/хореография, что вообще интегрируемые системы могут, а то может там только файловый обмен возможен. Как обеспечиваем требования безопасности, нужно ли шифрование/хэширование/маскирование/обезличивание, как устроена аутентификация и проверка полномочий.
9. Детальный сценарий обмена (диаграмма последовательности + текстовый сценарий).
10. Общие требования к обработке ошибок, журналированию, мониторингу. Где-то тут, когда начинаем думать про ошибки, возникают вопросы про гарантию доставки, идемпотентность и хранение переданных ранее данных. По обработке ошибок по сути у нас два решения: а) система, обнаружившая ошибку (кстати, кто может обнаружить ошибку?), пытается её исправить; б) система оповещает людей, которые уже сами пытаются решить проблему. Эти решения не взаимоисключающие. Кроме того, нужно зафиксировать ошибку в журнале (в каком? что именно записать? и т.п.).
11. Выбираем уже окончательно стиль интеграции и конкретную технологию или решение.
12. Проходим пункты 7-10 ещё раз, фиксируя конкретные и детальные решения, связанные с выбранной технологией. Дальше уже проект интеграции дробится на требования к каждой отдельной системе, участвующей в интеграции.