Особенности Архитектуры электронного правительства

Особенности домена данных в архитектуре электронного правительства

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

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

Дело в том, что ключевые государственные информационные системы должны эксплуатироваться десятилетиями, в то время как цикл использования информационных технологий и отдельных продуктов измеряется годами. Персональные компьютеры устаревают за 3 года; для таких бэк-офисных систем, как базы данных, жизненный цикл составляет 2-5 лет (после чего требуется сложный процесс обновления); языки программирования и другие элементы системной архитектуры (клиент/сервер, web-браузеры) "живут" примерно 10 лет. Напротив, в соответствии с законодательством, требуемый срок хранения данных по персоналу составляет 75 лет, а некоторые данные вообще должны храниться вечно.

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

К счастью, в настоящее время имеется консенсус по поводу лучшего способа обмена информацией – это XML. Можно сказать более того: XML является основой представления процессов, услуг и документов электронного правительства, потому что:

• он является открытым: им "не владеет" ни одна организация;
• он является "прозрачным" в том плане, что может читаться людьми и машинами;
• он обеспечивает необходимую гибкость за счет того, что по мере необходимости могут добавляться новые теги для описания новых типов данных.

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

Особенности архитектуры интеграции электронного правительства

Сложность проблемы интеграции информационных систем трудно переоценить. По оценкам аналитической компании ZapThink, до 70% процентов ИТ-бюджетов сегодня тратится на решение вопросов интеграции. При этом количество неудачных интеграционных проектов превышает количество успешных. Так, по оценкам Forrester Research, только 35% проектов по интеграции завершается в срок и в соответствии с бюджетом [9.13].

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

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

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

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

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

Большое количество стран на национальном уровне пошли именно по этому пути и создали соответствующую основу архитектуры интеграции в форме инфраструктуры, для которой используются в разных странах такие названия, как "правительственный шлюз" (Великобритания, Чехия, Болгария Румыния), "Брокер Государственных Сервисов" (PSB – Public Services Broker) в Ирландии и т.д. По большому счету, все эти решения основываются на принципах сервисной шины (в терминологии сервис-ориентированной архитектуры), на использовании интеграционного ПО пересылки сообщений (MOM – Message Oriented Middleware), согласованных схемах XML-сообщений.

Дополнительную информацию по архитектуре интеграции электронного правительства вообще и по ее практической реализации в Великобритании можно найти в [9.14].