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

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

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

· хорошо определенная архитектура;

· общие методики;

· общие форматы и схемы данных.

Уровень интерфейса с клиентами

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

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

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

Особенности архитектуры государственных функций (бизнес-архитектуры)

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

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

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

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

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

Более детальный анализ процессов предоставления государственных услуг позволяет выявить следующее:

· Большое количество аналогичных или очень близких по формам реализации услуг, предоставляемых различными ведомствами. Например, в Германии почти 3/4 всех услуг федерального правительства (73%) принадлежат к услугам трех типов: "Сбор, обработка и предоставление общей и специализированной информации", "Общие процедуры обработки заявлений, поступающих в государственные ведомства", "Процедуры оказания содействия и помощи";

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

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

Архитектура общих сервисов

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

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

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

Общим сервисам уделяется существенное внимание в методике описания архитектуры электронного правительства Gartner, а также в таких методиках, как SAGA Федерального Правительства Германии и e-GIF Правительства Великобритании.

Когда мы говорим об общих сервисах (или компонентах), то можно выделить:

· централизованно спроектированные, но внедряемые локально общие сервисы;

· централизованно спроектированные и централизованно внедряемые общие сервисы.

При этом можно назвать две крупные категории общих сервисов [9.11]:

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

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

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

Информационное взаимодействие с гражданами и бизнесом:

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

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

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

Транзакционные процессы:

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

Процессы поставок:

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

· Управление складскими запасами.

Корпоративные процессы:

· Финансовые и бухгалтерские системы;

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

· Системы управления персоналом;

· Системы обучения персонала.

Специализированные процессы:

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

Следующие общие сервисы и системы можно отнести к категории обеспечивающих:

Многократно используемые инфраструктурные компоненты:

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

· Сервисы каталогов. Этот сервис может обеспечивать, например, единый, основанный на стандарте X.500 каталог с адресной информацией, телефонами, адресами электронной почты служащих и т.д. в интересах всех государственных ведомств;

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

Информационные сервисы:

· регистр населения;

· регистр хозяйствующих субъектов;

· регистр объектов недвижимости;

· земельный кадастр;

· геоинформационные системы;

· системы поддержки принятия решений.

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

Для успеха в реализации общих сервисов государство должно учитывать следующие четыре фактора:

· Как выбрать и обосновать реализацию тех или иных сервисов в качестве общих?

· Какую модель выбрать для реализации общих сервисов (организационные и прочие вопросы)?

· Как обеспечить переход ведомств на использование общих сервисов?

· Как обеспечить процессы улучшений в реализации и использовании общих сервисов?

Для ускорения процессов использования общих сервисов государство, ведомства и поставщики соответствующих сервисов могут придерживаться следующих рекомендаций [9.12]:

· продвижение общих для государства (региона стандартов) на электронные сообщения и документы (например, в форме утвержденных XML-схем);

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

· использование принципов сервис-ориентированной архитектуры для построения прикладных систем в форме многократно используемых модулей;

· использование стандартов web-сервисов;

· принятие единых стандартов безопасности на информационный обмен;

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

Общие сервисы являются первыми кандидатами на аутсорсинг этой части государственной инфраструктуры ИКТ.

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

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

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

Дело в том, что ключевые государственные информационные системы должны эксплуатироваться десятилетиями, в то время как цикл использования информационных технологий и отдельных продуктов измеряется годами. Персональные компьютеры устаревают за 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].

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

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

Определенную помощь оказывает разбиение этого сложного процесса на три отдельных, но взаимосвязанных этапа [9.15]. Эта условная схема представлена

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

· фаза построения основ;

· фаза создания общих правительственных информационных систем (в английском языке используется термин "корпоративная фаза" - Enterprise phase);

· фаза реализации специфических для ведомств и агентств проектов и систем.

Фаза построения основ



Рис. 5 Этапы реализации Архитектуры электронного правительства

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

Фаза построения основ включает создание следующих элементов:

· вычислительная инфраструктура: центры обработки данных, серверы, сети, настольные системы и т.д.;

· коммуникационная инфраструктура для передачи данных, голоса, видео, ТВ;

· основные сервисы, обеспечивающие продуктивность работы персонала: текстовые редакторы, электронная почта, телефонная связь, удаленный доступ и т.д.;

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

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

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

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

Примерами систем, которые создаются на этой фазе, являются:

· финансово-бюджетные системы;

· геоинформационные системы;

· центральные регистры и кадастры (населения, собственность, земля).

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 6 Методология Федеральной Архитектуры и ее компоненты

Двигатели архитектуры являются источниками изменений для архитектуры федерального предприятия и делятся на два типа:

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

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

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

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

3. Текущая архитектура (Current Architecture). Определяет архитектуру "как есть" и состоит из двух частей:

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

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

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

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

Основные примеры переходных процессов включают следующие:

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

o контроль и анализ инвестиционного управления - для поддержки процесса контроля используется информация относительно архитектуры предприятия;

o координация сегментов - координирование процесса интеграции архитектурных сегментов в единую Федеральную архитектуру;

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

o управление активами - управление всеми активами, которые связаны с реализацией Федеральной архитектуры;

o процессы закупок - согласование процессов закупок с архитектурой и с намеченными переходными процессами;

o управление архитектурой - координация усилий по сопровождению и управлению архитектурой.

6. Архитектурные сегменты (Architectural Segments). Отражают разбиение общей архитектуры на отдельные, существенные области деятельности, например:

o общие административные системы;

o области федеральных программ, таких как внешняя торговля или предоставление грантов;

o электронная торговля для проведения небольших закупок.

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

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

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

При этом рассматриваются бизнес-модели и модели технической среды (данных, прикладных систем, технологий):

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

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

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

Соответственно, если говорить о том, какие представления (домены) выделяются в методике Федеральной архитектуры США, то они следующие:

o бизнес-архитектура (функциональная архитектура деятельности правительства);

o архитектура информации (данных);

o архитектура приложений;

o архитектура инфраструктуры (технологическая или системная архитектура): аппаратное и системное программное обеспечение, коммуникации.

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

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



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

o Справочная модель эффективности (PRM - Performance Reference Model).

o Справочная модель описания бизнеса федеральной организации (BRM - Business Reference Model).

o Справочная модель сервисных компонент (SRM - Service Component Reference Model). Это описание компонент прикладных информационных систем, обеспечивающих реализацию государственных функций.

o Справочная модель описания данных (DRM - Data Reference Model).

o Технологическая справочная модель (TRM - Technology Reference Model).

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

Эти справочные модели являются, по сути дела, определенными руководствами, которые:

o обеспечивают общие архитектурные принципы при реализации межведомственных проектов;

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

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

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

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

· горизонтальные слои: Среда бизнес-взаимодействия, Стили бизнес-процессов, Шаблоны, "Строительные блоки" ("Кирпичики");

· вертикальные домены: Приложения, Данные, Интеграция, Доступ;

· вертикальные элементы технической архитектуры: Инфраструктура, Системное управление, Безопасность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Руководство является модульным набором документов, которые покрывают гораздо более широкий спектр проблем, чем в 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) [9.6]. Мы кратко рассматривали основные элементы этой методики в , в частности, то, что она определяет пять представлений: корпоративное, информационное, вычислительное, проектировочное и технологическое.