Концепция единой архитектуры приложений электронного правительства

ВКСС.Connect №4 2005 г.  скaчать в PDF 

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

Рис. 1. Драйверы архитектуры приложений ЭП

Предпосылки разработки единой  программной архитектуры

Вопросы проектирования и разработки архитектуры электронного правительства освещены в аналитических исследованиях, международных и государственных стандартах [4, 5, 6, 7], что позволяет нам перейти от методологических исследований к практической реализации технической архитектуры, в частности, архитектуры приложений.

При проектировании архитектуры приложений, согласно рекомендациям [6], мы определили значимые технические  и бизнес-дрйверы, они изображены на Рис. 1.

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

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

Эволюционный путь развития электронного правительства проходит несколько этапов, от информационного к транзакционному взаимодействию [10]. Компания Accenture в 2003 году определила пять последовательных уровней зрелости ЭП:

• онлайновое присутствие (Online Presence);
• базовые возможности (Basic Capability);
• доступность услуг (Service Avaliability);
• зрелость доставки услуг (Mature Delivery).

В то же время специфика развития электронного государства в РФ делает эволюционное развитие неэффективным по следующим причинам:

• многие граждане РФ не подготовлены к использованию услуг электронного правительства, не имеют соответствующих технических возможностей и необходимых знаний;
• бизнес сегодня наиболее подготовлен к электронному взаимодействию, обладает необходимым техническим обеспечением и знаниями. Существует потребность со стороны бизнеса в повышение эффективности информационного взаимодействия с государством;
• существует проблема электронного взаимодействия различных ведомственных систем, их интеграции для обмена данными.

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

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

Проектируя  архитектуру приложений ЭП, необходимо не копировать существующие решения, а использовать возможность разработать более эффективную техническую архитектуру, учитывая  специфические условия, которые существуют в РФ, среди которых:

• высокий уровень централизации принятия решений => возможность централизованного проектирования и реализации архитектуры приложений ЭП.
• практическое отсутствие унаследованных систем (legacy systems) => возможность создания новых систем на основе современных технологий, а не адаптация унаследованных систем:
• высокий потенциал ИТ компаний => возможность практической реализации предлагаемой архитектуры.

Переход от целей и задач электронного правительства к его архитектуре, и от логической, функциональной архитектуры к технической архитектуре должен делаться на основе количественного сравнения альтернативных вариантов. Предлагаемая архитектура приложений является одним из таких вариантов.

Анализ практики внедрения и эксплуатации информационных систем показывает, что основные проблемы проявляются при интеграции приложений. Сложность интеграции, высокая стоимость, сложность внесения изменений обусловили цель минимизации количества интерфейсов при разработке архитектуры приложений ЭП.

При отсутствии единого проекта реформирования государственных информационных систем, архитектура приложений представляет совокупность информационных систем министерств, ведомств и региональных органов власти, разработанных с использованием различных технологий, которая характеризуется является высокой стоимостью эксплуатации, еще более высокой стоимостью интеграции и сложностью изменения. Для интеграции независимых систем  сегодня рекомендуется использовать обмен сообщениями на основе открытых стандартов (XML) и сервисов гарантированной доставки сообщений MOM (Messaging Queuing). Например, в концепции ОГИР [5] рекомендуется «абстрактная архитектура агентских систем» – вариант интеграции разрозненных приложений с использованием обмена сообщениями. Альтернативой может стать единая архитектура приложений, построенная на основе технологии SOA (Service Oriented Architecture).

Абстрактная модель архитектуры приложений

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

Рис. 2. Архитектура интегрированных приложений и единая техническая архитектура

Иерархическая модель сервисов в составе архитектуры приложений ЭП

Предлагаемая архитектура реализуется с помощью сервисов, которые реализуются на пяти уровнях. На Рис. 3 представлены выделенные нами концептуальные уровни сервисов единой архитектуры приложений.

Уровни выделены на основе направления взаимодействия (предоставление сервисов, использование сервисов либо и то и другое) и функционального назначения сервисов. Например, базовый уровень  только предоставляет сервисы, а транзакционный использует сервисы базового и предоставляет услуги процессным сервисам.

Рис. 3. Уровни, типы и интерфейсы сервисов единой технической архитектуры ЭП

Базовые сервисы: авторизация, извлечение информации из государственных реестров, доступ к нормативной информации. Например, обеспечение доступа к единому реестру населения, к реестру физических лиц, реестру автотранспортных средств, объектов недвижимости, а так же к разнообразным справочникам и классификаторам, таким как справочники ВЭД, географические справочники, классификаторы продукции, услуг, видов деятельности, тарифы и нормативы, используемые для фискальных расчетов и т.д. Основными функциями этих сервисов является внесение дополнений и изменений в справочники и реестры, а так же поиск и извлечение данных. Для определения состава сервисов можно использовать справочную модель данных и информации (Data & Information Reference Model — DRM) [6].

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

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

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

Сервисы приложений – сервисы, обеспечивающие работу конечных пользователей: чиновников государственных учреждений, граждан, сотрудников коммерческих организаций. Их отличием является наличие пользовательского интерфейса. Для определения состава сервисов может использоваться справочная модель сервисных компонентов (Service Component Reference Model — SRM) [6].

Концепция единой архитектуры приложений ЭП предполагает ограниченное использование реестров для обнаружения сервисов. Их состав, местоположение и интерфейсы должны быть достаточно стабильны, определяться в технических стандартах и электронных регламентах. Использование сервисов должно обеспечивать большую достоверность и практическую ценность реестров, например, интеграция реестров UDDI (Universal Description, Discovery and Integration) c реестрами физических лиц и общегосударственными справочниками и классификаторами.

Преимущества единой архитектуры приложений

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

Реализация единой архитектуры приложений

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

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

Реализация предлагаемой архитектуры предполагает последовательную замену существующих приложений на новые приложения, использующие иерархические сервисы. Анализ текущего состояния ГИС и ГИР, приведенный в [4], показывает, что значительное их большинство разработана без использования объектных технологий и не может использовать преимущества сервисной архитектуры без существенной доработки. Причем стоимость этой доработки сопоставима со стоимостью разработки нового приложения, реализующего ту же функциональность с использованием современных технологий.

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

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

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

Литература и источники

1. Концепция использования информационных технологий в деятельности федеральных органов государственной власти до 2010 года
2. Материалы конференции «Объединенные государственные информационные ресурсы как механизм поддержки принятия решений в рамках административной реформы и ФЦП «Электронная Россия», 16 мая 2003 года
3. Обзор технологий интеграции информационных систем Microsoft (http://www.microsoft.com/rus/government/analytics/integration/overview.asp)
4. Отчет о научно-исследовательской работе по теме: Создание комплекта проектов основных технических нормативных документов по взаимодействию среды с внешними системами и ИСАЭР.  ЗАО РесЭко.  2004 г. 412 с.
5. Отчет о научно-исследовательской работе: Разработка концепции Объединенных Государственных и муниципальных Информационных ресурсов (ОГИР) по теме: «Разработка предложений по созданию единой системы выявления, использования и внедрения объединенных государственных и муниципальных информационных ресурсов»  477 с.
6. Руководство по разработке архитектуры электронного правительства. Совет руководителей информационных служб CIO. 45 с. Центр компетенции  по электронному правительству при американской торгово-промышленной палате.
7. Стандарты и единая архитектура информационных технологий для проектов электронного правительства и межведомственных проектов Microsoft (http://www.microsoft.com/rus/government/analytics/integration/standart.asp)
8. Церенов Церен Валерьевич. Презентация ФЦП «Электронная Россия — инструмент совершенствования  государственного управления»
9. Шаронов Андрей Владимирович. Презентация «Эффективность бюджетных расходов» http://www.economy.gov.ru/webcontent/economy/www.economy.gov.ru/merit/obzor/mvk_sharonov_140703 МОСКВА 14 июля, 2003 
10. Электронное правительство: рекомендации по внедрению в Российской Федерации. Эко-Трендз, Москва 2004, 344 с.