Архитектура взаимодействия электронного правительства Великобритании (e-GIF)

Архитектура взаимодействия электронного правительства (e-GIF – e-Government Interoperability Framework) устанавливает государственные технические политики и спецификации с целью достижения высокого уровня интеграции и взаимодействия информационных систем государственного сектора Великобритании. В апреле 2004 года опубликована уже шестая версия этой архитектуры . Оригинальные документы можно найти по адресу Офиса e-Envoy, который отвечает за проект электронного правительства Великобритании.

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

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

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

При этом e-GIF служит рамочным документом, который содержит высокоуровневые утверждения, описания технических политик и принципов управления, общие описания процессов внедрения и следования принципам e-GIF. Он дополняется рядом других документов, которые в совокупности описывают видение Архитектуры электронного правительства Великобритании:

Архитектурные модели (Architectural Models).

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

При этом рассматриваются бизнес-модели и модели технической среды (данных, прикладных систем, технологий):Бизнес-модели. Это модели, которые отражают появление бизнес-потребностей, инициированных бизнес-двигателями. Моделирование предполагает создание общего набора определений, диаграмм, а также, возможно, использование автоматизированных инструментальных средств, которые облегчают понимание бизнес-функций, применяемой информации, процессов и продуктов;Модели технической среды (Design Models). Модели технической среды включают модели данных, модели прикладных систем и технологические модели, которые требуются для того, чтобы поддержать реализацию бизнес-потребностей.

Архитектурные сегменты (Architectural Segments).

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

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

Каждый сегмент также характеризуется текущей и будущей архитектурой данного конкретного сегмента. Соответствующая информация и модели помещаются в базу данных (репозиторий) единой Федеральной архитектуры.

Архитектуры для государственных ведомств. Примеры Лекция из курса «ИТ-стратегия»

Данилин Александр Валентинович, Слюсаренко Андрей Иванович
Интернет-Университет Информационных Технологий, INTUIT.ru

Архитектуры для государственных ведомств. Примеры Лекция из курса «ИТ-стратегия»

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

Архитектуры для государственных ведомств. Примеры Лекция из курса «ИТ-стратегия»

В частности, предложена четырехуровневая модель государственных прикладных систем, включающая следующие уровни:

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

Клиентский уровень обеспечивает различные каналы доступа (Web-доступ, Мобильный доступ, доступ для внешних систем). Презентационный уровень отвечает за представление информации и взаимодействие систем с различными клиентами. Промежуточный слой является основным с точки зрения реализации логики приложений и интеграции с другими компонентами систем.

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

Архитектуры для государственных ведомств. Примеры Лекция из курса «ИТ-стратегия»

Целевая архитектура (Target Architecture).

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

Двигатели архитектуры (Architecture Drivers).

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

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

Эталонная модель прикладных систем SAGA

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

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

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

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

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

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

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

Каталог Стандартных Государственных Данных (GDSC – Government Data Standards Catalogue).

Этот Каталог описывает элементы и типы данных, которые используются, например, в "Общей Информационной Модели Государственной Услуги", описанной в e-SDF (см. ниже), и в Справочной Модели Сообщений, определяющей форматы стандартных сообщений, которыми обмениваются государственные информационные системы. Каталог обеспечивает связь между функциональными требованиями с точки зрения описания услуг ("Общая Информационная Модель Государственных Услуг") и техническим описанием с точки зрения практической реализации (Справочная Модель Сообщений). По большому счету, Каталог Стандартных Государственных Данных описывает имена различных элементов (тэгов), используемых в различных государственных XML-документах (например, как будут именоваться тэги, используемые для описания "Фамилии", "Имени" гражданина, элементов адреса места жительства и пр.), какие типы данных при этом и меются в виду (текстовые, числовые и пр., а также их формат).

Каталог Технических Стандартов (TSC – Technical Standards Catalogue).

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

Методика FEAF Федеральной Архитектуры США

В первую очередь при обсуждении методологий, которые изначально разрабатывались с учетом специфики государства, следует отметить методику Федеральной Архитектуры США (FEAF – Federal Enterprise Architecture Framework). Эта методика отличается высокой степенью комплексности политики, процессов и моделей, что отражает исторические традиции и уровень использования ИКТ в деятельности американского правительства. Методология FEAF рассматривается в качестве ориентира и многими европейскими странами, и Евросоюзом в целом. Оригинальные документы, описывающие методологию FEAF, представлены на сайте Офиса Управления Проектом Разработки Федеральной Архитектуры США (FEAPMO – Federal Enterprise Architecture Project Management Office) . Достаточно подробное описание методики FEAF на русском языке можно найти в книгах , , . Здесь мы отметим только самые главные моменты.

Совет руководителей информационных служб (CIO Council) начал разработку FEAF в апреле 1998 году. В основу был положен Стратегический план деятельности CIO Council, разработанный с учетом приоритетов Закона по реформированию системы управления информационными технологиями в органах государственной власти принятого в 1996 году (Information Technology Management Reform Act или, иначе, закон Клингера-Кохена), который определял направления разработки и использования Федеральной Архитектуры для максимизации отдачи от использования ИКТ в государстве под флагом "эффективности инвестиций денег налогоплательщиков в ИТ". Этот закон определил в качестве одной из обязанностей руководителей департаментов информационных технологий государственных ведомств разработку архитектуры информационных технологий.

Офис FEAPMO дает следующее определение Федеральной Архитектуры:

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

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

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

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

FEAF состоит из следующих восьми компонент, которые кратко описаны ниже и представлены на .

Методика разработки электронных услуг (e-SDF – e-Services Development Framework).

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

Совокупность документов, определяющих архитектуру электронного правительства Великобритании, представлена на .

Методологии описания архитектуры, ориентированные на государственные ведомства

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

Методология Gartner для архитектуры электронного правительства

В курсе "Архитектура предприятия" мы описывали сформулированную относительно недавно методику описания архитектуры Gartner, которая представляет собой как бы трехмерный куб, состоящий из следующих элементов:

горизонтальные слои: Среда бизнес-взаимодействия, Стили бизнес-процессов, Шаблоны, "Строительные блоки" ("Кирпичики");вертикальные домены: Приложения, Данные, Интеграция, Доступ;вертикальные элементы технической архитектуры: Инфраструктура, Системное управление, Безопасность.

Следует отметить, что данное представление архитектуры вполне применимо для описания Архитектуры электронного правительства , .

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

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

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

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

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

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

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

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

Методология META Group в применении к описанию архитектуры электронного правительства

В лекции 5 мы рассматривали методику описания и разработки архитектуры, предложенную консалтинговой компанией META Group. Данная лекция содержит ссылки на источники информации, содержащие документы, которые описывают практический опыт разработки архитектуры органами государственного управления различных уровней.

Случайно или нет, но большое количество публично доступной информации о проектах регионального уровня (уровня отдельных штатов США) связано с использованием методики META Group. Эти материалы могут использоваться как наглядные пособия, описывающие саму методику и ее практическое применение.

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

При этом применение самой методики для потребностей органов государственного управления и ведомств практически не требует какой-либо специальной ее адаптации.

Моделирование административных процессов и процессов предоставления услуг.

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

Моделирование данных.

Это означает методическое, стандартизованное описание данных, которые применяются в рамках процессов электронного правительства (прикладных систем), что также является важным фактором обеспечения взаимодействия систем и возможности многократного использования систем и процессов;

Оценка зрелости архитектуры государственной организации

Для оценки степени зрелости архитектуры государственных организаций может быть полезна следующая модель GAO (Финансово-контрольное управление США) , которая определяет 5 уровней зрелости. Рассматриваемый стандарт получил название "Пять стадий зрелости архитектуры Предприятия – GAO's Five Stages of Enterprise Architecture Maturity" и предназначен для использования во всех федеральных правительственных агентствах, департаментах и бюро США.

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

Уровни идентифицируются в соответствии со степенью реализации нескольких основных атрибутов, таких как:

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

В 2003 году была разработана новая, "более жесткая" версия 1.1 этого стандарта , которая предъявляет повышенные требования к организации процессов и, соответственно, к достижению того или иного уровня зрелости. Эти дополнительные требования появляются, начиная со стадии 2, и распространяются явно или неявно на последующие стадии. Примерами таких дополнительных требований служит необходимость разработки модели оценки эффективности как для существующего состояния информационных систем, так и для целевого состояния "как должно быть", или явное упоминание необходимости разработки метрик для количественных оценок. На стадии 4 отмечается необходимость проведения независимой оценки предлагаемых архитектурных решений и верификации правильности их реализации.

показывает распределение государственных ведомств США по различным стадиям зрелости реализованного в них архитектурного процесса, по состоянию на 2003 год. (были проанализированы 96 ведомств). Анализ показал, что многие агентства еще достаточно далеки от желаемого уровня. Фактически уровень 5 достигнут только в Администрации Президента США.

Определение технических профилей стандартов и архитектуры.

Это является основой для обеспечения взаимодействия и согласованности систем в процессе разработки приложений для электронного правительства и разработки базовых компонент;

Основные компоненты

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

Известные нам практические примеры – описание архитектуры уровня отдельных штатов США, отдельных городов Северной Америки и Европы – основаны на использовании какой-либо одной из известных на практике методологий. При этом нам встречались случаи, когда в основу работ были положены, например, методологии META Group или Gartner.

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

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

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

В этом документе сформулированы следующие высокоуровневые цели на 2005-2007 года:

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

Для достижения этих целей были сформулированы следующие задачи и обеспечивающие решение этих задач стратегии (мы комбинировали для краткости задачи и стратегии на 2003-2005 и 2005-2007 года).

Переходные процессы (Transitional Processes).

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

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

Представления, используемые для описания архитектуры

Представления, используемые для описания архитектуры электронного правительства в SAGA (модель RM-ODP)

Корпоративное представление включает два фундаментальных элемента: организационные структуры электронного правительства в целом и организационные модели приложений. Эта та область архитектуры, где описываются внешние факторы, требования к системам, ограничения. Здесь же даются определения того, что такое услуги (в данном случае это услуги государства для граждан и хозяйствующих субъектов и услуги одних ведомств для других), процедуры и административные процессы, правила их выполнения, акторы, а также их роли в процессах.

Существенное внимание в немецких подходах (как в самой SAGA, так и в Руководстве по электронному правительству) уделяется оптимизации и правилам описания административных и бизнес-процессов.

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

Информационное представление определяет структуру и семантику информации, которая обрабатывается системами. Механизм, используемый в Германии для обеспечения взаимодействия и интеграции систем, достаточно традиционен и также принят на вооружение многими другими странами (Великобританией, Данией и т.д.). Это создание центрального репозитория (каталога) государственных XML-схем документов, что обеспечивает разным ведомствам единые схемы данных и единые определения элементарных данных.

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

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

В данном разделе приведены в качестве примера краткие изложения конкретных подходов к описанию и разработке архитектур электронных правительств, в частности, таких стран, как Германия и Великобритания.

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

Программа разработки политик, стандартов и процедур

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

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

Примерами руководств служат руководства по управлению проектами, защите частной информации и т.д.

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

Разработка базовых компонент.

Базовые компоненты отобраны и специфицированы по таким критериям, как частота использования и достаточно общая применимость для большого количества процессов.

При этом SAGA носит достаточно прагматичный характер, так что описание архитектуры покрывает только те области, которые оказывают существенное влияние на решение перечисленных задач, т.е. не все элементы технической архитектуры включены в это описание. В дополнение к SAGA как к основному документу, по описанию архитектуры электронного правительства Германии, важную роль играет так называемое "Руководство по электронному правительству" (E-Government Manual), которое доступно на английском языке по адресу .

Руководство является модульным набором документов, которые покрывают гораздо более широкий спектр проблем, чем в SAGA. В SAGA имеются ссылки на это Руководство, в котором многие темы разбираются более детально и подробно. Имеется также ряд других документов архитектурного характера, например, V-Modell, который описывает процесс разработки прикладных систем; DOMEA (Document Management and Electronic Archiving), который излагает требования к системам работы с электронными документами и файлами, а также системам автоматизации потоков работ (woorkflow) и создания электронных архивов, что очень важно для государственных ведомств.

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

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

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

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

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

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

Важным является оценка прикладных систем на соответствие архитектуре, описанной в SAGA. Прикладная система оценивается на совместимость с архитектурой на основе моделей, процедур и стандартов, описанных в SAGA:

использование стандартных моделей процессов;использование и учет стандартных моделей данных;применение стандартов, утвержденных в SAGA, и соответствие архитектуре, описанной в SAGA;использование разработанных централизованно базовых компонент (общих сервисов).

Мы уже отмечали, что проекты систем в области "электронного правительства", не удовлетворяющих требованиям совместимости с SAGA, "по определению" не могут получить бюджетного финансирования.

В основе SAGA как описания архитектуры электронного правительства в целом, так и описания архитектуры отдельных систем, лежит Справочная Модель Открытых Распределенных Вычислений (RM-ODP – Reference Model of Open Distributed Processing) . Мы кратко рассматривали основные элементы этой методики в , в частности, то, что она определяет пять представлений: корпоративное, информационное, вычислительное, проектировочное и технологическое.

В отношении архитектуры электронного правительства это условно показано на .

Список Категорий Правительственной информации (GCL – Government Category List).

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

Справочные модели Федеральной архитектуры США

Справочные модели Федеральной архитектуры СШАСправочная модель эффективности (PRM – Performance Reference Model).Справочная модель описания бизнеса федеральной организации (BRM – Business Reference Model).Справочная модель сервисных компонент (SRM – Service Component Reference Model). Это описание компонент прикладных информационных систем, обеспечивающих реализацию государственных функций.Справочная модель описания данных (DRM – Data Reference Model).Технологическая справочная модель (TRM – Technology Reference Model).

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

Эти справочные модели являются, по сути дела, определенными руководствами, которые:обеспечивают общие архитектурные принципы при реализации межведомственных проектов;обеспечивают всем государственным организациям единую методологию при разработке собственных архитектур ИТ (Корпоративных архитектур).

Помимо самих справочных моделей, офис FEAPMO разрабатывает необходимые подробные методики по их практическому применению. Это в существенной степени перекликается с подходами, принятыми, например, в Германии и Великобритании.

Сравнительная оценка зрелости корпоративной архитектуры

Сравнительная оценка зрелости корпоративной архитектуры агентств 2003 года

Возникает естественный вопрос: а на каком уровне зрелости архитектуры находятся российские государственные ведомства?

Ссылки на примеры описания архитектур

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

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

Таблица 8.1. Ссылки на сайты с информацией о проектах разработки архитектуры электронного правительства регионального уровня и уровня крупного городаРегион, городСайтИспользованная методология

Штат Виржиния, США		META Group5.29.3
Штат Северная Каролина, США		META Group
Штат Коннектикут, США		META Group
Штат Аризона, США		META Group
Штат Мэн, США		Gartner
Штат Кентукки, США		Методология "4Front" Methodology of Deloitte & Touche Consulting Group
Штат Массачусетс, США		Нет информации о методике
Штат Огайо, США		Опубликованы отдельные политики в области ИТ
Штат Делавэр, США		Нет информации о методике
Штат Миссури, США		Методика IBM
Штат Небраска, США		Нет информации о методике
Штат Нью-Йорк, США		Собственная методика, основанная на методиках NASCIO, Gartner Group, META Group
Штат Монтана, США		Нет информации о методике
Штат Вашингтон, США		META Group
г. Меса, США (штат Аризона)		Нет информации о методике
г. Торонто, Канада		Нет информации о методике
г. Оклэнд, США (штат Калифорния)		Нет информации о методике
Штат Куинслэнд, Австралия		META Group
Штат Андхра-Прадеш, Индия		Price Waterhouse Coopers

В приведены ссылки на сайты с описанием архитектур отдельных государственных ведомств.

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

Департамент энергетики США		Методология Enterprise Architecture Planning (EAP) Спивака
Министерство обороны США		Методика Министерства обороны DoDAF
Департамент внутренних дел США (функции пожарной службы, охраны природы, охраны национальных меньшинств и т.п.)		Federal Enterprise Architecture Framework (FEAF)
Департамент юстиции США		Federal Enterprise Architecture Framework (FEAF)
Федеральное казначейство США		TEAF, созданная на основе FEAF

Таблица 8.3. Уровни зрелости архитектуры государственной организацииУровеньХарактеристика

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

Стандарт на метаданные электронного правительства (e-GMS – e-government Metadata Standard).

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

Стандарты и архитектура прикладных систем электронного правительства (SAGA) Германии

SAGA (Standards and Architecture for e-government Applications) является одновременно и методикой разработки, и описанием реализации электронного правительства Германии (переводится как "Стандарты и архитектура прикладных систем электронного правительства"). В декабре 2003 года была опубликована уже вторая версия этого документа, которая доступна по адресу .

В рамках инициативы BundOnline 2005, реализация которой началась в сентябре 2000 года, Германия планирует к 2005 году реализовать в электронной форме более 400 услуг федерального правительства. Базовыми принципами, декларируемыми в рамках немецкой программы BundOnline 2005, являются следующие: 1) децентрализованная реализация с централизованным мониторингом и обеспечением поддержки, и 2) взгляд на инициативу в целом с точки зрения предоставляемых государством услуг.

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

Стандарты (Standards).

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

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

В США ведется разработка и постоянное уточнение соответствующих взаимосвязанных так называемых Справочных (эталонных) Моделей (Reference Models) для каждой из перечисленных областей.

Иерархия Справочных Моделей в рамках Федеральной архитектуры показана на . Эта иерархия включает в себя следующие модели:

Стратегическое направление (Strategic Direction).

Руководство для разработки целевой архитектуры (см. ниже), которое содержит видение, принципы, цели и объекты.

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

Структура областей описания архитектуры электронного правительства Великобритании

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

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

Текущая архитектура (Current Architecture).

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

XML-схемы.

XML и XSL рассматриваются в качестве ключевых стандартов для интеграции и управления данными. Это включает механизмы централизованного согласования, создания и определения XML-схем, которые используются всеми государственными ведомствами.

Обеспечить бесперебойную работу основных ИТ-систем

Стратегия 1.1. Обеспечить инвестиции в возможности и устойчивость инфраструктуры.Стратегия 1.2. Обеспечить защиту критически важных бизнес-функций за счет инвестиции в безопасность сети.Стратегия 1.3. Инвестировать в средства обеспечения высокой доступности систем и web-технологии.Стратегия 1.4. Исследовать возможности географически распределенных вычислений для обеспечения устойчивости работы ИТ-систем.

Поддерживать передовые позиции в области электронного правительства через инновации

Стратегия 2.1. Обеспечить эффективность публикации информации на Web с помощью технологий управления контентом.Стратегия 2.2. Расширить возможности публичного и внутреннего портала.Стратегия 2.3. Продолжить развитие инфраструктуры публичных ключей и использование цифровых сертификатов.Стратегия 2.4. Обеспечить потребности в области предоставления видео-информации на рабочие места.Стратегия 2.5. Расширить возможности в области он-лайновых платежей.Стратегия 2.6. Расширить возможности и использование архитектуры корпоративного (в масштабах всего правительства штата) каталога Active Directory.Стратегия 2.7. Провести оценку беспроводных и мобильных технологий.

Обеспечить баланс контроля и инноваций в практике управления

Стратегия 3.1. Создать условия и политики, обеспечивающие быстрое внедрение новых технологий.Стратегия 3.2. Создать механизмы оценки для процесса замены устаревающих технологий с учетом имеющихся бюджетных ограничений.Стратегия 3.3. Обеспечить реализацию основных ИТ-проектов за счет стандартизации процессов управления проектами и обучения.Стратегия 3.4. Реализовать управление "портфелем портфелей проектов" различных ведомств на основе целостных для всего штата представлений об инвестициях в ИТ.

Стимулировать и обеспечивать межведомственную и межфункциональную кооперацию

Стратегия 4.1. Стимулировать создание и условия использования общей инфраструктуры.Стратегия 4.2. Создавать политики для лучшей поддержки межведомственных проектов.Стратегия 4.3. Помогать небольшим по размерам агентствам в использовании общих технологических ресурсов.

Искать дополнительные

Стратегия 5.1. Продолжать агрегирование закупок информационных технологий в целях получения ценовых преимуществ.Стратегия 5.2. Помогать пользователям услуг ДИТ в обмене идеями вместо обмена персоналом.Стратегия 5.3. Предоставлять своим потребителям и использовать внутри ДИТ лучшие практики в области ИТ-сервисов.

Продолжать использование эффективных и стратегических методов работы внутри ДИТ

Стратегия 6.1. Использовать результаты исследований для лучшего понимания потребностей потребителей услуг ДИТ, взаимодействия с ними и их обслуживания.Стратегия 6.2. Улучшить процессы расчетов за предоставляемые услуги.Стратегия 6.3. Создать финансовый контроль и процессы финансирования, обеспечивающие компенсацию затрат и развитие.Стратегия 6.4. Привлекать, развивать и удерживать необходимые для развития людские ресурсы.Стратегия 6.5. Использовать проактивные подходы в управлении рисками.

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