Системные и бизнес-аналитики довольно часто участвуют в проектах интеграции информационных систем. Сегодня рассмотрим, с чего начать предпроектное исследование, чтобы успешно разработать требования к интеграции и оформить их в виде технического задания (ТЗ) по шаблонам российских ГОСТ’ов (34.602-89 и 19.201-78) или международных стандартов спецификации. Также разберем, чем пакетный парсинг отличается от потоковой передачи событий и каковы сложности интеграции нескольких информационных систем с разными моделями данных.
Что такое интеграция информационных систем: краткий ликбез для бизнес-аналитика
Когда речь идет об интеграции информационных систем (ИС), под этим подразумевается односторонняя передача или взаимный обмен данными, которые в них хранятся. Выполнять такую передачу или обмен данными будет программное обеспечение (ПО), внешнее по отношению к связываемым информационным системам, или внутренние компоненты их самих. Как именно это будет происходить, решает ИТ-архитектор или ведущий разработчик, который отвечает за техническое решение. Чтобы корректно разработать требования к реализации такого ПО, аналитик должен понимать ключевые аспекты интеграции, которые мы и рассмотрим далее. С учетом современной тенденции российского (и не только) рынке к слиянию ролей системного и бизнес-аналитика, такой краткий ликбез по интеграции информационных систем пригодится начинающим специалистам обеих профессий. Итак, разработать требования к интеграции помогут точные ответы на следующие 5 вопросов.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
3 июня, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.
Зачем?
Поскольку любое исследование в бизнес-анализе начинается с определения потребности, неудивительно, что «Зачем?» — это первый вопрос при интеграции ИС. Зная ответ, аналитик сможет определить полезность и нужность, т.е. ценность интеграции для бизнеса: решает ли она реальную проблему и действительно ли эту проблему стоит решать. Например, сотрудники компании тратят 2 часа рабочего времени на внесение данных из одной информационной системы в другую. Зная количество этих сотрудников и их почасовую ставку, нетрудно рассчитать экономию от автоматической передачи данных между разными системами. Это и будет ценность интеграции в денежном выражении. Сопоставив потенциальную выгоду интеграции с затратами на ее реализацию, можно сделать выводы о периоде окупаемости интеграционного решения и его целесообразности. Подробнее о бизнес-проблемах, их причинах и следствиях мы говорили в прошлой статье.
Кроме того, понятные ответ на вопрос «Зачем нужна интеграция ИС» поможет определить сценарии обмена данными между ними, причем как в плане бизнес-процессов, так и с технической точки зрения. Иначе говоря, «Зачем?» является главным и первым вопросом аналитика в любом проекте, позволяя определить дальнейший путь выявления требований к решению и ключевые аспекты его реализации. В техническом задании на разработку ПО для интеграции информационных систем или спецификации требований ответ на вопрос «Зачем?» располагается во введении или разделах, которые описывают назначение и цели создания программного продукта.
Сколько?
Хотя главным вопросом для бизнеса являются деньги и то, что с ними связано, здесь речь идет не о стоимости интеграционного решения, а о том, какое количество ИС необходимо связать между собой. Если нужен обмен данными между всего 2-мя «коробочными решениями», а бизнес не планирует строить полноценную инфраструктуру данных, добавляя десятки специфических ИС для поддержки различных процессов и направлений деятельности, то границы проектируемого интеграционного ПО могут располагаться внутри 2-х связываемых систем. Когда речь идет о создании корпоративной дата-магистрали, к которой подключено много ИС, при разработке ТЗ аналитику нужно тщательно проработать требования к внешним интерфейсам, которые будут обеспечивать многосторонний обмен данными.
На основании этих требований и особенностей самих связываемых систем ИТ-архитектор принимает решение о модели интеграции. Например, это может быть общая шина предприятия (ESB, Enterprise Service Bus) с очередью сообщений, набором коннекторов к источникам и приемникам данных, а также объединяющей программной платформы. Или реализация CDC-подхода, когда с помощью триггеров отслеживаются и обрабатываются изменения в базах данных прикладных систем (Change Data Capture), сливаясь в единое корпоративное хранилище (DWH, Data WareHouse). Или же обмен данными по запросу через удаленный вызов процедур из одной системы и обращение к конечной точке другой методами RESTful-API. Подробнее о способах интеграции ИС с технической точки зрения мы поговорим в следующий раз. А пока отметим, что при разработке ТЗ или спецификации требований информация о количестве связываемых ИС и их архитектурных особенностях будет отражена в разделе «Ограничения дизайна и реализации».
Какие данные?
Этот вопрос касается структуры данных, которыми будут обмениваться связываемые системы. Каждая ИС имеет свою модель данных – чаще всего она является реляционной, где информация структурирована в связанные таблицы. В реляционной модели каждая таблица имеет заранее определенное количество столбцов для хранения данных конкретного типа: целочисленных, символьных и пр. Некоторые СУБД поддерживают не только реляционную парадигму – они называются NoSQL и хранимые в них данные могут иметь различную структуру, например, как JSON-файл со множеством ключей. Поскольку каждая ИС имеет свою уникальную модель данных, интеграция – это не просто передача записей (или значений отдельных полей) из одной таблицы в другую. Поэтому в функциональных требованиях к интеграционному решению аналитик указывает, какие данные будут передаваться, в каком виде они изначально хранятся в источнике и как будут ложиться в приемник. При этом в функциональные требования также включается преобразование значений, например, приведение к единообразной форме отображения адресов, личных данных клиентов или названий предприятий.
Например, в одной системе адрес хранится в одном поле таблицы строкового типа, а в другой – разбит на несколько отдельных полей с разными типами данных: индекс, область, город, улица, номер дома, корпус, квартира. В этом случае интеграционное решение будет выполнять синтаксический анализ (парсинг) исходных данных, чтобы выделить разные значения из единой строки и записать их в различные поля модели данных системы-приемника. Аналогичный парсинг будет выполняться и для сложных типов данных в случае интеграции нескольких систем, например, при разборе сообщений, хранящихся в очереди корпоративной ESB-шины. Описать данные, которыми будут обмениваться интегрируемые системы, а также сопоставить компоненты одной модели данных и другой поможет техника под названием «Словарь данных», которую мы недавно разбирали здесь. В дополнение к этому будет полезно показать источники и приемники данных с процессами их преобразования. Сделать это можно с помощью диаграмм потоков данных (DFD, Data Flow Diagram), которые мы разбирали в этой статье.
Методы описания бизнес-процессов (IDEF, DFD, BPMN, EPC, UML)
Код курса
MODP
Ближайшая дата курса
13 июня, 2024
Продолжительность
8 ак.часов
Стоимость обучения
18 000 руб.
Как часто или насколько быстро выполняется обмен?
Еще одним важным вопросом интеграции является частота обмена данными. Например, периодическая отправка новых или измененных записей одним пакетом из одной системы в другую или общую шину/хранилище раз в несколько часов. На практике такой пакетный режим с парсингом данных на стороне приемника используется довольно часто там, где речь не идет об обработке в реальном времени с минимальной задержкой. А если нужна оперативная реакция одной системы на события, произошедшие в другой, в дело вступают технологии потоковой обработки данных (Event Streaming Processing). Хотя эти технические особенности относятся к архитектурному проектированию и находятся в области ответственности ИТ-архитектора, а не аналитика, необходимые параметры (скорость, периодичность) приема и обработки данных должны быть указаны как нефункциональные требования в ТЗ или спецификации SRS.
Кто или что инициирует передачу данных?
Наконец, при разработке требований к интеграционному решению аналитик должен определить сценарии интеграции с точки зрения ролей в процессе обмена данными: кто из пользователей или какая из систем инициирует передачу данных. Это можно оформить в виде текстовых сценариев Use Case в разделе описания функциональных требований. Для наглядности такие сценарии можно проиллюстрировать диаграммами описания бизнес-процессов в BPMN или UML-activity, однако на практике именно для проектов интеграции такие схемы не всегда действительно нужны, в отличие от матрицы ролей и разрешений.
Основы архитектуры и интеграции информационных систем
Код курса
OAIS
Ближайшая дата курса
20 мая, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.
В следующий раз я подробнее расскажу про технические методы интеграции информационных систем: чем GraphQL отличается от REST и SOAP, с какими форматами и режимами обработки данных они работают, а также зачем эти знания системному и бизнес-аналитику. А пока в качестве проверки, насколько хорошо вы усвоили материал этой статьи, предлагаю вам самостоятельно выполнить открытый интерактивный тест на знание стандартов разработки ТЗ и спецификации требований к ПО.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
3 июня, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.
А детально познакомиться с основами архитектуры и интеграции информационных систем вам помогут курсы Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
- Основы архитектуры и интеграции информационных систем
- Разработка ТЗ на информационную систему по ГОСТ и SRS
