CC BY
133
№ 5 (47) 2013
К. С. Дрогобыцкая, докт. экон. наук, профессор Финансового университета
при Правительстве РФ, г. Москва
Архитектурные аспекты электронного правительства
Концепция электронного правительства, уже нашедшая свое практическое воплощение в ряде зарубежных стран, используется для разработки и в отечественных проектах. Эффективность реализации проектов во многом определяется возможностью построения моделей на основе формального описания структуры правительственных организаций.
Введение
Архитектурное направление экономической науки возникло как естественная реакция на постоянное расширение, усложнение и углубление информатизации организационно-экономических систем. Для любой из них существует некий критический рубеж, выше которого обеспечить надежное функционирование и целенаправленное развитие системы без наличия ее архитектурного описания становится затруднительным. Число элементов системы — подразделений, людей, контрагентов, информационных единиц, компьютерных программ, каналов передачи данных — и способов их взаимодействия увеличивается настолько, что удержать их в памяти одного человека, а тем более развивать становится невозможно. Нужно некое формализованное описание этого строения, аккумулирующее весь коллективный интеллект организации, к которому каждый ее активный элемент (индивидуальный интеллект) имеет доступ и возможность использовать его для решения своих текущих задач.
Собственно таким формализованным описанием внутреннего строения организационно-экономической системы и обеспечения ее динамики является архитектура. Рассмотрение состава и содержания последней применительно к правительственным организациям и составляет предмет настоящей статьи.
Состав архитектуры электронного правительства
С точки зрения системного архитектора государство представляет собой совокупность ведомств с четко обозначенными функциями. При этом ведомства взаимодействуют с внешними образованиями: хозяйствующими субъектами, другими государственными ведомствами и гражданами. Отмеченные взаимодействия все чаще осуществляются в электронной форме, что влечет возникновение потребности в общих стандартах на информационные технологии в масштабах всего правительства для того, чтобы обеспечить целостность, надежность и гибкость выполнения государственных функций.
Следует заметить, что подходы к архитектурным построениям на уровне ведомств очень близки к применяемым на уровне отдельных организаций. Однако государство как институт обладает уникальными (эмерд-жентными) свойствами, отсутствующими у отдельных ведомств [1, с. 47]. Эта уникальность, в свою очередь, определяет специфические требования к архитектуре информационных технологий, применяемых в масштабах всего государства, или, как теперь принято говорить, архитектуре электронного правительства.
О той или иной степени общности архитектуры электронного правительства на уровне отдельных государственных организаций, органов государственной власти, ведомств
№ 5 (47) 2013
и государства в целом можно говорить только в отношении вычислительной платформы и вычислительной сети, т. е. в отношении домена «технологическая инфраструктура» [1]. В отношении остальных доменов — «организационная структура», «бизнес-архитектура», «архитектура информации» и «архитектура приложений» и т. д., связанных с прикладными системами поддержки исполнения государственных функций, такой общности не наблюдается. На рисунке 1 приведены домены первого плана архитектуры электронного правительства, выстроенные в порядке роста их индивидуализации (от основания до вершины).
¡о Рис. 1. Концептуальная архитектура
Ц электронного правительства
^ В первую очередь необходимо отметить <| децентрализованно-централизованную при-о роду приведенного построения, что означает § децентрализованную реализацию архитекту-^ ры электронного правительства различны-(5 ми министерствами, ведомства, агентствами 2 и государственными службами при центра* лизованной разработке методик описания, 5 анализа и оптимизации архитектуры, а также <ц технологических компонентов, обеспечивающих общие (повторяющиеся) функции. От-£ сюда следует, что министерства, ведомства и службы остаются «владельцами» процессов и несут ответственность за реализацию
собственных информационных систем, а также актуальность и точность информации. Интеграция решений достигается через идентификацию и реализацию общих принципов проектирования индивидуальных (ведомственных) систем и создание ограниченного набора общих технологических компонентов, использование которых призвано уменьшить дублирование на стадии разработки и обеспечить многократное применение на стадии эксплуатации. Следовательно, развитая модель архитектуры электронного правительства способна обеспечить механизмы не столько жесткого навязывания решений, сколько координации архитектур отдельных государственных структур и централизованного финансирования инфраструктурных проектов, которые требуются для реализации общих архитектурных компонентов.
Интерфейс с клиентами. Характерной особенностью электронного правительства является обеспечение множественных каналов взаимодействия граждан и бизнеса с государством. Уровень интерфейса позволяет отделить бизнес-логику от информационного взаимодействия и иметь к ней доступ с различных устройств. При этом процесс реализации государственной услуги посредством выполнения каких-либо административных регламентов внутри государственной организации остается неизменным независимо от канала доступа. Более того, данные об обратившимся лице, имеющиеся в распоряжении государства или конкретного ведомства, используются в целях предоставления индивидуализированных услуг.
Важной функцией этого домена архитектуры электронного правительства является реализация так называемых интеллектуальных агентов, обеспечивающих помощь пользователю государственных сервисов в прохождении сложных, многоэтапных транзакций, характерных для взаимодействия с государством. В идеале пользователь может обращаться за услугой, исходя из потребностей жизненного момента, не зная точно, в какие конкретно структуры органов власти он должен обратиться. Напри-
№ 5 (47) 2013
мер, для получения услуги пользователь может заполнить заявку на портале или распечатать ранее заполненную электронную форму и послать ее обычной почтой. Интеллектуальные агенты уровня интерфейса как опытные государственные служащие должны провести «пользователя» через все этапы взаимодействия с государством, даже если это в реальности связано с доступом к информационным системам нескольких ведомств.
Архитектура государственных функций. В рамках этого домена архитектуры электронного правительства должны быть описаны государственные функции, административные регламенты и услуги, представляемые гражданам и/или хозяйствующим субъектам. При этом реализация каждой услуги должна быть алгоритмизирована от начала до конца (от заполнения заявки до получения результата). Следовательно, формирование архитектуры электронного правительства предполагает проведение работ по выполнению функций органами государственной власти на уровне процессов и административных регламентов, что следует из прав и обязанностей граждан и хозяйствующих субъектов.
В период первого десятилетия текущего века в России проводились масштабные работы по инвентаризации и анализу государственных функций. В конечном итоге было выявлено большое количество аналогичных или близких услуг, предоставляемых различными ведомствами. Почти 3/4 услуг федерального правительства принадлежат одному из трех типов:
• сбор, обработка и предоставление информации;
• общие процедуры обработки заявлений, поступающих в государственные ведомства;
• процедуры оказания помощи и содействия.
Более того, оказалось, что предоставление различных услуг основано на использовании одних и тех же функциональных моделей, что создает предпосылки для сущест-
венной экономии и достижения синергети- 3 ческого эффекта при реализации проектов электронного правительства. В первую оче- | редь, это достигается за счет создания так называемых общих сервисов. ^
Архитектура общих сервисов. Общие сервисы обеспечивают необходимую поддержку государственных функций в различных системах, входящих в состав электронного правительства и при этом не содержат какой-либо специфической бизнес-логики конкретной предметной области деятельности того или другого государственного ведомства. Например, единый государственный сервис электронных платежей может быть использован различными государственными службами, а точнее их информационными системами для сбора налогов, оплаты штрафов, пошлин, пеней и др. платежей, предусмотренных нормативными документами за оказание государственных услуг.
Экономия от использования общих сервисов достигается за счет эффекта масштаба (большого объема транзакций), получения качественно более точной информации, исключения ее дублирования и в итоге более целостного взгляда на имеющиеся ресурсы и способы взаимодействия граждан и хозяйствующих субъектов с государством. Общие сервисы являются первыми кандидатами на аутсоурсинг.
Архитектура информации (данных). В проектах электронного правительства имеется большое число вовлеченных сторон (акторов) — министерств, ведомств, агентств, служб, организаций и граждан. Взаимодействие и коммуникационные связи между ними весьма разнообразны, что делает исключительно сложным процесс достижения соглашений о соответствующих схемах данных. Тем не менее именно данные служат основой как для реализации государственных информационных систем, что не является чем-то исключительным, так и для их интеграции, что представляет особую сложность для государства.
Дело в том, что ключевые государственные информационные системы должны экс-
№ 5 (47) 2013
плуатироваться десятилетиями, в то время как цикл использования конкретных информационных технологий и отдельных продуктов измеряется годами. Персональные компьютерные технологии устаревают за три года, жизненный цикл баз данных составляет от двух до пяти лет, языки программирования и другие элементы системной архитектуры (клиент/серверы, веб-браузеры) «живут» примерно 10 лет. В то же время, в соответствии с законодательством, требуемый срок хранения данных по персоналу составляет 75 лет, а некоторые данные вообще должны храниться вечно.
В этой связи единственная долговременная основа для создания и последующей интеграции государственных информационных систем — это структуры данных. Независимо от того, что случится с технологиями, люди будут получать свидетельства о рождении, паспорта, водительские удостоверения, создавать предприятия, работать и платить налоги, жениться, строить дома и покупать квартиры, а также, к сожалению, умирать. Следовательно, именно данные составляют и будут составлять основу системы электронного правительства.
Наилучшим средством моделирования информационных потоков и обмена данными между множеством информационных систем в рамках электронного правительства являются XML-файлы [4, 5]. ¡5 Архитектура интеграции. Сложность ■о проблемы интеграции информационных ^ систем трудно переоценить. По оценкам <| аналитиков, до 70% ИТ-бюджетов в настоя-о щее время тратится на решение вопросов § интеграции. При этом количество неудачных ^ интеграционных проектов превышает коли-(5 чество успешных (по оценкам тех же ана-2 литиков [1, 3] только 35% проектов по инте* грации завершается в срок и в соответствии 5 с бюджетом).
<ц На уровне правительства, региональной администрации или муниципального обра-£ зования эта ситуация носит особенно драматический характер в силу необходимости интеграции большого количества информа-
ционных систем, принадлежащих различным ведомствам. В этой связи явное выделение в архитектуре электронного правительства архитектуры интеграции в качестве отдельного домена носит обоснованный характер.
Основными барьерами межведомственной интеграции процессов, систем и услуг являются прежде всего юридические, организационные и процедурные проблемы. Жесткое навязывание единой технологии, внедрение решений «одним махом» по указанию сверху всегда встречают сопротивление властей всех уровней. Единственный способ решения этих проблем в реальных условиях работы — использование децентрализовано-централизованного подхода, когда министерства, ведомства, агентства и службы продолжают использовать собственные технологические решения, несколько общих сервисов и единую инфраструктуру, обеспечивающую электронный обмен между ведомственными информационными системами в виде электронных сообщений согласованных XML-форматов. Кроме быстрой реализации общих процессов и постепенной замены своих систем на «великие и идеальные» системы, разработанные централизованно, такой подход уменьшает требования, предъявляемые последними к государственным служащим и ИТ-специалистам. Именно по этому пути пошли многие страны, в том числе Россия, при создании своих электронных правительств.
Технологическая инфраструктура. По сравнению с традиционной архитектурой организации этот домен архитектуры электронного правительства имеет более широкую область действия и, следовательно, более растянутый процесс формирования. Помимо непосредственного формирования технологической инфраструктуры ведомственной информационной системы он охватывает еще комплексы работ (стадии) по созданию общих правительственных информационных систем (общих сервисов) и реализации специфических проектов и систем.
№ 5 (47) 2013
Формирование технологической инфраструктуры (на начальной стадии) заключается в создании общей для большинства ведомств технологической платформы электронного правительства, на которой, собственно, и базируются соответствующие прикладные системы. Платформа включает центры обработки данных, серверы, сети, настольные системы, коммуникации для передачи данных, голоса, видео и телевидение, электронную почту, удаленный доступ, процедуры и стандарты, определяющие то, как обеспечиваются, поддерживаются, применяются, защищаются, оцениваются системы и сервисы, а также проводится реинжиниринг и реорганизация работы ИТ-департаментов организации. Ввиду того, что на этой стадии еще не сформировалось целостное впечатление об архитектуре электронного правительства, работы по формированию технологической инфраструктуры продолжаются и плавно перетекают в корпоративную стадию создания общих правительственных информационных систем.
На этой стадии разрабатываются информационные системы и сервисы, перекрывающие организационные границы, имеющие большую базу пользователей и являющиеся критически важными с точки зрения реализации основных функций правительственного органа. В число таких систем входят бюджетно-финансовые системы, геоинформационные системы (ГИС), центральные регистры, кадастры, порталы, системы управления контентом, среда межведомственной интеграции, сервис электронных платежей и т. д. Собственно на описываемой стадии предпринимаются основные усилия по инициации разработки проекта архитектуры электронного правительства в целом.
На стадии реализации специфических проектов создаются системы, обеспечивающие реализацию совершенно конкретных функций отдельных министерств, ведомств, агентств и служб. Именно на этой стадии проводится основная работа по формиро-
ванию архитектуры отдельного государст- | венного органа, которая должна учитывать
общие архитектурные решения, принятые |
на уровне правительства в целом. §
CJ
описание архитектуры государственной организации
Известно несколько методик, специально разработанных для реализации инициатив в области электронного правительства. Все они вобрали в себя основные принципы и подходы описания архитектуры организации, скорректированные с учетом специфики реализации общегосударственных инициатив и достижения некоторой централизованной координации внедрения информационно-коммуникационных технологий в государственных органах.
В качестве ориентира разработки такой методики во многих европейских странах, в том числе в России, выступает методика федеральной архитектуры (Federal Enterprise Architecture Framework — FEAF) [1, с. 452]. В понимании ее создателей федеральная архитектура — это стратегический информационный актив, который определят целевую активность государственных организаций, информацию и технологии, необходимые для ее обеспечения, а также процессы преобразований, сопровождающие внедрение новых информационных технологий в ответ на меняющиеся потребности общества.
Важной особенностью проекта федеральной архитектуры является функциональный подход, проявляющийся в том, что все архитектурные построения описываются с позиций бизнес-процессов и функций, а не структуры федерального правительства и госорганов. При этом не предполагается переопределение и/или детализация функций отдельных органов и служб. Контекстные функциональные модели служат, по сути дела, определенными руководствами, обеспечивающими архитектурные принципы при реализации межведомственных проектов, а также предоставляют всем государст-
№ 5 (47) 2013
венным организациям единую методологию при разработке собственных архитектур.
На рисунке 2 приведен состав федеральной архитектуры: она включает семь основных компонентов — двигатели архитектуры, текущая архитектура, целевая архитектура, процессы миграции, архитектурные сегменты, стандарты, стратегические направления. Кратко остановимся на содержании каждого из них.
Двигатели архитектуры (Architecture drivers) отражают два главных источника или стимула изменения архитектуры: бизнес-стимулы и технологические стимулы. В качестве бизнес-стимулов могут выступать новые инициативы высших органов власти (президента, Правительства, Законодательного собрания), новое законодательство, бюджетные «вливания» для ускорения развития отдельных отраслей либо складывающийся вектор рыночных отношений. К числу технологических стимулов можно причислить новое (улучшенное) программное обеспечение, новые аппаратные средства, а также их всевозможные комбинации. Наиболее наглядным примером технологического стимула является Интернет.
Текущая архитектура (Current architecture) определяет архитектуру «как есть» и состоит из семи частей, рассмотренных ранее. Их можно сегментировать в два больших блока: текущая бизнес-архитектура и текущая ¡5 архитектура информационных технологий. ■о Текущая бизнес-архитектура фиксирует те-^ кущие потребности с точки зрения деятель-<| ности государственной организации и отра-о жает, как эти потребности осуществляются § информационными системами (в разрезе ^ функций, процессов и ресурсов). Текущая ар-(S хитектура информационных технологий или 2 совокупная архитектура данных, приложений ^ и технологической инфраструктуры отражает S текущее состояние возможностей информа-<ц ционных технологий по обеспечению деятельности государственной организации и слу-5; жит объектом для дальнейших изменений. s| Целевая архитектура (Target architecture) определяет архитектуру «как должно быть»
и также состоит их двух частей, объедин-ных в два блока: будущей бизнес-архитектуры и будущей архитектуры информационных технологий. Она дает представление о предполагаемых возможностях и технологиях, которые станут результатом очередных изменений.
Процессы миграции (Transitional processes) поддерживают процесс перехода от текущей архитектуры к целевой. Для правительственной организации миграционные процессы предполагают планирование инвестиций в ИТ, планирование изменений, управление изменениями и контроль за расходованием инвестируемых средств. Разумеется, что все перечисленные процедуры автоматически тиражируются на число проектов, реализация которых должна обеспечить желаемую миграцию, что, в свою очередь, предполагает надлежащую их координацию и по ресурсам, и по результатам.
Архитектурные сегменты (Architectural segments) отражают разбиение общей архитектуры на существенные области деятельности, характерные для данной правительственной организации. Как следует из рис. 2, в деятельности нашей гипотетической правительственной организации выделены три важных сегмента: общие административные системы, целевые федеральные программы и электронная торговля. Для другой организации эти сегменты могут быть другими.
При сегментировании архитектуры организации необходимо помнить, что каждый архитектурный сегмент должен быть достаточно важным с точки зрения самостоятельного рассмотрения, например, по критерию возвратности инвестиций, и должен рассматриваться в рамках общего контекста электронного правительства. За каждым сегментом должны стоять, по крайней мере, две архитектурные модели (текущая и будущая), которые помещаются в репозиторий электронного правительства. В совокупности архитектурные модели задают функциональную (бизнес-) архитектуру и архитектуру информационных технологий.
3
<
К)
ч
Рис. 2. Структура методики описания федеральной архитектуры
К. С. Дрогобыцкая
№ 5 (47) 2013
Стандарты (Standards) включают собственно стандарты, руководящие принципы и передовой опыт. Для каждого домена архитектуры электронного правительства ведется разработка и постоянное уточнение так называемых эталонных моделей (reference models). В число последних включают: модель эффективности, модель описания деловой активности правительственной организации, модель сервисных компонентов (описание компонентов прикладных информационных систем, обеспечивающих реализацию государственных функций), модель описания данных и технологическую модель. Отмеченные эталонные модели являются, по сути дела, определенными руководствами, обеспечивающими общие архитектурные принципы в процессе реализации межведомственных проектов и единую методологию при разработке собственных архитектур министерств, ведомств, агентств и служб. Со временем эволюционные модели могут трансформироваться в полноценные стандарты.
Стратегическое направление (Strategic direction) представляет собой руководство для разработки целевой архитектуры, включающее в себя видение будущего правительственной организации, сжатое описание стратегических целей развития ее архитектуры на ближайшую перспективу (обычно 5 лет), а также принципы и критерии управления этим развитием. Не трудно догадать-§ ся, что в основе руководства по разработке ■о стратегии развития государственной орга-^ низации лежит метод интерактивного моде-<1 лирования [2].
о Необходимо стремиться к как можно бо-§ лее полному и качественному описанию ком-^ понентов федеральной архитектуры на ка-(S ждой итерации архитектурного процесса. 2 Непреклонное следование этой установке ^ представляется необходимым условием по-S явления «рабочего» варианта архитектуры <ц государственной организации, способного го оказать значительную помощь в опреде-S; лении наиболее перспективных направле-s| ний ее развития в контексте как обеспечения быстрейшего возврата инвестиций, так
и повышения результативности ее функционирования.
Заключение
Для развития электронного правительства и повышения качества электронных услуг, предоставляемых гражданам, бизнесу и общественным организациям, необходимо иметь модельное описание его архитектуры. Рассмотренные в статье состав и содержание архитектуры электронного правительства призваны помочь читателю составить объективное мнение о ее роли и значимости в деле развития гражданского общества. Описание архитектуры каждой правительственной организации в семи рассмотренных разрезах следует интерпретировать как определение того, чем она должна стать в обозримой перспективе. Заметим, что помимо самой методики описания архитектуры электронного правительства, рассмотренной в настоящей статье, параллельно разрабатываются подробные методики по ее практическому применению. Можно полагать, что в недалекой перспективе все работы по созданию архитектур государственных, общественных и предпринимательских организаций превратятся в рутинные инженерные процедуры с небольшим «налетом» творчества. В настоящее время они носят больше творческий, чем инженерный характер.
Список литературы
1. Данилин А., Слюсаренко А. Архитектура и стратегия: «инь» и «янь» информационных технологий предприятия. М.: Интернет-университет Информационных технологий, 2009. — 504 с.
2. Дрогобыцкий И. Н. Системный анализ в экономике: учебник. 2-е изд., перераб. и доп. М.: ЮНИТИ-ДАНА, 2011. — 423 с.
3. Радаев А. Как сделать интеграцию бизнес-приложений эффективной. URL: http: //www.insapov.ru/ integration-busines-application.html.
4. Ere T. Service-Oriented Architecture: concepts. N.-Y.: Technology & Desing, 2008. — 217 p.
5. Vieira M. Depenbility Benchmarking to OLTP Systems. Saarbriicen: LAP LAMBERT, 2010. — 273 р.
