Создание экосистем на практике

К написанию статьи подтолкнула постоянно возникающая необходимость "навести мосты" между различными ведомственными информационными системами (ВИС). Бизнес- или административными процессами такое взаимодействие организаций/подразделений определено, а вот для информационных систем оно зачастую не реализовано.

Одним из примеров, когда требуется взаимодействие, является решение задач в сфере градостроительства с использованием ГИСОГД - государственной информационной системы обеспечения градостроительной деятельности. В соответствии с действующими нормативными документами ведение ГИСОГД региона осуществляют уполномоченные органы - ОМСУ (районы/городские и муниципальные округа) и Оператор (ОИВ или ГБУ на региональном уровне). Потребители получают информацию из ГИСОГД через публичный портал, развернутый в Интернет, и муниципальную услугу «Предоставление сведений из ИСОГД» (платную, пока, по крайней мере).

На практике количество участников – потребителей и поставщиков информации – существенно шире. К таким участникам следует отнести различные региональные органы исполнительной власти в сфере земельно-имущественного комплекса, инженерной и промышленной инфраструктуры, природных ресурсов, охраны природы и окружающей среды, объектов культурного наследия.

У каждого такого участника уже есть или планируется создать собственные информационные системы и/или сервисы. Для таких систем можно выделить схожие задачи: паспортизация объектов с учетом расположения (пространственная привязка) собственных объектов и объектов смежников (в других сферах); оказание государственных/муниципальных услуг; анализ сведений; формирование регламентированной отчетности; раскрытие информации.

Такие информационные системы участников в нашем представлении и формируют региональную экосистему, при построении которой необходимо обеспечить такие свойства как распределенность, адаптивность, масштабируемость, устойчивость.

Делимся, с чем довелось иметь дело в проектах

1. ВИС участников (ведомств) организуются на одной платформе

Мы работаем с собственной платформой «ГеоПрайм». При создании ВИС как правило используются модули «ГеоПрайм»: «Реестры пространственных данных», «Обращения», «Разработка документов», «Аналитические отчеты», «Каталог георесурсов», «Администрирование», «Безопасность».

Оператор выполняет настройку карточек реестров. Пользователи при работе с реестрами могут вносить сведения об объектах и их пространственном расположении. Для ведения пространственных данных используется ввод координат, рисование геометрии объектов на карте, загрузка геометрии и координат из внешних файлов. В карточках информация располагается в закладках и секциях, состав которых настраивает администратор; для отображения данных могут быть заданы правила, определяющие показывать или наоборот скрывать из карточки поля, проверять введенные значения на соответствие заданным правилам; может быть настроена подсветка записей различными цветами.

В «Обращениях» настраивается описание предмета обращения, бизнес-процесс обработки заявок на услуги,   подключаются печатные формы. К обращениям может подключаться возможность отправки межведомственных запросов. Активация таких запросов может выполняться как вручную, так и автоматически.

В «Разработке документов» конфигурируется бизнес-процесс подготовки документов, структура документов, печатные формы.

По данным объектов системы настраиваются аналитические отчеты, которые представляют информацию в форме таблиц, диаграмм, картосхем.

И, конечно, конфигурируются роли, учетные записи, настройка личного кабинета с разделами, подразделами.

Сформированные посредством реестров, обращений и документов объекты с пространственной привязкой актуализируют слои, доступ к которым может быть организован на геопортале.

Плюсы такой организации - без создания дополнительных сервисов пользователи различных ВИС имеют доступ к данным смежников.

Минусы - увеличивается количество организационных вопросов, которые потребуется решить, чтобы добиться синхронизации развития и сопровождения систем, если у таких ВИС разный оператор.

Пример организации ВИС на одной платформе

В Республике Саха (Якутия) на базе региональной геоинформационной системы территориального планирования (РГИС ТП) были организованы личные кабинеты для специалистов Министерства природы, в которых решались задачи паспортизации объектов негативного воздействия и объектов окружающей среды. Далее эта личные кабинеты развились в региональную государственную систему природопользования со своими собственными модулями (региональный экомониторинг, гос.надзор, аналитика), а блок задач паспортизации был вынесен в отдельный экземпляр системы (РГИС ППиООС).

Выделение системы природопользования в отдельный экземпляр произошло на тот момент с целью обеспечить управление доступом и настройками двум разным операторам - Министерству строительства (РГИС ТП) и Министерству природы (РГИС ППиООС). Это же разнесение систем далее позволило асинхронно выполнять развитие систем, поскольку общего оператора не было, а финансирование велось из отдельного бюджета каждого оператора.

Если бы в регионе был определен единый оператор, обеспечивающий синхронизацию задач развития и управления ресурсами, на наш взгляд, в регионе вполне успешно можно было бы работать нескольким ведомствам в одной системе. Это бы точно сократило затраты на сопровождение и развитие базовых возможностей систем.

2. Интеграция ВИС через РСМЭВ/СМЭВ

Такой подход применяется, когда ВИСы уже есть и для межведомственных запросов между системами-участниками применяется РСМЭВ или СМЭВ: в составе ГеоПрайм разворачиваются сервисы интеграции и обработки данных, а также адаптер СМЭВ.

ВИС, организуемая на платформе ГеоПрайм, настраивается также как и в п.1, но дополнительно разворачиваются сервисы, обеспечивающие взаимодействие с внешними ВИС посредством СМЭВ/РСМЭВ.

Сервис интеграции является универсальным. Он обеспечивает передачу сообщения, полученного в составе пакета в адаптер, в сервис обработки; а также получение сообщений для внешних ВИС, упаковку и передачу в адаптер СМЭВ для последующей отправки в СМЭВ/РСМЭВ.

В сервисе обработки определяются преобразования для конкретного вида сведений, которые задают правила переноса данных входящего сообщения в объекты ВИС (например, в Обращения) и наоборот - получение данных из ВИС и преобразование их для передачи в сервис интеграции. Дополнительно сервис обработки создает запись в журнале запросов, позволяя через интерфейс системы просмотреть входящие и исходящие запросы, созданные вручную и/или автоматически.

С использованием журнала запросов могут быть созданы и исходящие запросы на сведения во внешних ВИС, например, запрос данных из ЕГРН. Настройками, доступными администратору системы, определяется состав параметров, которые пользователь должен указать при размещении запроса, и сценарий формирования сообщения для конкретной спецификации вида сведений. Сформированное сообщение передается в сервис интеграции и из него в адаптер СМЭВ.

Плюсы такой реализации - возможность настройки взаимодействия с внешними ВИС без переработки кода самой системы.

Минусы - смена спецификаций видов сведений без уведомления владельцев ВИС, организационные проблемы с подключением ВИС к видам сведений.

Пример интеграции ВИС посредством СМЭВ

Самый очевидный пример - взаимодействие ВИС посредством СМЭВ с ЕПГУ, который отрабатывался нами в Республике Бурятия. Сведения о заявках, размещаемых в ЕПГУ, поступают в адаптер СМЭВ, развернутый на стороне ГИСОГД, обрабатываются сервисами интеграции и обработки. В результате в ГИСОГД формируются Обращения с представлением структурированных данных заявки ЕПГУ. При подготовке документов по обращению происходит внесение в документ сведений из заявки и данных самой системы. Подготовленный документ размещается в обращении, передается через сервис интеграции в адаптер СМЭВ и далее в ЕПГУ по СМЭВ.

Наибольшая сложность в такой интеграции - организация заказчиком подключений ВИС к контурам СМЭВ. Заказчиком ВИС как правило выступает "отраслевая" структура (например, управление архитектуры, министерство строительства), в составе которых зачастую нет специалистов по IT,  и прочтение и применение на практике методических рекомендаций по подключению к СМЭВ представляет собой проблему. В связи с этим, конечно, хотелось бы, чтобы подобными задачами организации взаимодействия занимались бы "цифровые" кадры региона (например, министерства информационных/цифровых технологий или их подведомственные структуры).

3. Интеграция ВИС через API/сервисы

Это, пожалуй, один из наиболее затратных вариантов взаимодействия, в том плане, что под каждую внешнюю ВИС со своим API требуется специальная разработка. Даже если она использует какие-то наработанные функции и обращение к собственному API системы.

Плюсы: 1) решение отдельных задач взаимодействия без необходимости регистрации видов сведений в СМЭВ.  2) при наличии api у одной из ВИС потребуется доработка только "подключаемой" системы.

Минусы: 1) при отсутствии api требуется доработка обеих ВИС и возникает необходимость синхронизации работ различных разработчиков;  2) не тиражируемые решения стоят дороже.

Пример интеграции ВИС через api

1. В Республике Саха (Якутия) выполнялась интеграция РГИС ППиООС с ВИС «Аверс» и ВИС «Охота», из которых в систему природопользования поступали сведения об оказанных во внешних ВИС услугах. Для этого взаимодействия в РГИС ППиООС и этих внешних ВИС были разработаны сервисы интеграции.
2. К примерам взаимодействия посредством api можно отнести и интеграцию системы природопользования (РГИС ППиООС) с РПГУ в Республике Саха (Якутия). В Якутии взаимодействие с РПГУ было организовано не напрямую, а через Единую информационно-технологическую платформу (ЕИТП), у которой было свое api.  Со стороны РГИС ППиООС был разработан сервис, обращавшийся к api ЕИТП. Основная проблема, с которой мы столкнулись - отсутствие спецификаций, содержащих описание передаваемых сообщений. Чтобы справиться с ней, пришлось с оператором ЕИТП отрабатывать различные комбинации заполнения форм. При этом всплывали расхождения форм с регламентами, определявшими состав предоставляемых сведений; отсутствие унификации справочников между разными видами сведений; а также то, что формы заявок на РПГУ не были в должной мере структурированы, т.е. предполагали внесение текстом информации, тогда как в ВИС, которую мы делали, ожидалась автоматизированная обработка этих данных.
3. В Ленинградской области для ГИСОГД были разработаны сервисы предоставления данных о документах ГИСОГД и сведений об ограничениях на территории. Сервисы были подключены к нескольким ВИС - системе комитета стройнадзора, государственной информационной системе "Обеспечение деятельности межведомственной рабочей группы по рассмотрению вопросов, связанных с приведением в соответствие сведений Единого государственного реестра недвижимости и Государственного лесного реестра, на территории Ленинградской области"; порталу ГИСОГД в интернет.

Кстати, сейчас в формах на ЕПГУ, тоже есть проблема, связанная с тем, что местами вносятся текстовые данные, а не справочники и числовые значения, тогда как для последующей обработки нужны как раз такие данные. Но надо отдать должное  - бОльшая часть справочников, применяемых в разных видах сведений, унифицирована, что существенно упрощает настройку сервиса обработки на стороне ВИС.