Оценка перспективности инвестиций в ИТ по методике TVO

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

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

Поэтому, в соответствии с точкой зрения аналитиков Gartner, приведенной в работе [8.14], более правильным является учет стратегического влияния результатов таких проектов на дальнейшее развитие систем и бизнеса в целом. Соответствующими показателями будут в данном случае являться рентабельность активов (ROA) и TVO (Total Value of Opportunity) – Ценность возможностей для бизнеса. Так как многие инвестиции в ИТ-архитектуру являются долгосрочными, то использование такого показателя как ROA, позволяет более корректно учитывать увеличение капитализации компании. Показатель TVO, хотя он не является чисто финансовым, позволяет связать реализацию данных проектов с расширениями возможностей бизнеса.

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

Рис. 5.2. Оценка эффективности инвестиций в ИТ по методике TVO

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

Применение методики TVO состоит из последовательного выполнения небольшого количества этапов:

Шаг 1: Четкая формулировка названия и целей проекта и идентификация типа инвестиций.Шаг 2: Оценка преимуществ для бизнеса, которые определяются в соответствии с некоторой моделью показателей, называемой Моделью эффективности бизнеса (Business Performance Framework) (см. ниже).Шаг 3: Идентификация функциональных возможностей (capabilities), реализуемых внедряемыми новыми технологиями.Шаг 4: Оценка влияния возможностей технологий на метрики, определенные в Модели эффективности бизнеса.Шаг 5: Оценка финансовой составляющей проекта, определяемой с учетом совокупной стоимости владения (TCO), включая скрытые и косвенные затраты.Шаг 6: Оценка возможностей предприятия с точки зрения конвертирования технологических преимуществ от реализации проекта в ощутимые выгоды для бизнеса.Шаг 7: Оценка косвенных выгод и неопределенностей, связанных с влиянием реализуемых решений на другие проекты в будущем.

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

При этом потенциальный проект относится к одному из четырех типов ИТ-инвестиций, из которых два связаны с инфраструктурой и еще два – с решениями (прикладными системами):

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

На втором шаге выбираются метрики для оценки отдачи от ИТ-проекта с точки зрения получения бизнес-преимуществ. Преимущества для бизнеса могут быть перечислены в рамках некоторой модели взаимосвязанных сгруппированных показателей (по аналогии с системой показателей Balanced Sсore Card – BSC). Компанией Gartner была разработана соответствующая Модель эффективности бизнеса (Business Performance Framework) [8.15], которая включает наборы показателей (метрики), покрывающие основные области деятельности организации, такие как адекватность требованиям рынка, эффективность процесса продаж и т.д. Очевидно, что не только технологии вносят вклад в достижение тех или иных показателей ведения бизнеса, однако, предлагаемые метрики позволяют построить причинно-следственные связи.

Примечания к таблице:

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

** Стоимость конверсии представляет собой отношение затрат на приобретение исходных материалов к стоимости произведенных товаров.

*** Величина Сигма связана с количеством дефектов произведенных товаров.

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

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

Базовые (10) – это те ИТ-сервисы, которые организация "обязана" иметь: гибкость, расширяемость, масштабируемость, надежность, доступность, требуемая производительность, возможность наращивания производительности, совместимость с имеющейся инфраструктурой, безопасность и защита частных данных, удобство обслуживания.Операционная поддержка и возможности снижения ТСО (8) – эти возможности связаны, в основном, с деятельностью самих ИТ-подразделений: стандартизация платформ, стандартизация поставщиков, стандартизация приложений, консолидация систем, уменьшение стоимости ИТ-процессов, ускорение ИТ-процессов, эффективность работы ИТ-персонала, стандартизация и интеграция ИТ-процессов.Прямые улучшения бизнеса (6) – это преимущества, которые напрямую получают бизнес-подразделения: уменьшение стоимости бизнес-процессов, ускорение бизнес-процессов, эффективность работы сотрудников, функциональные улучшения, требуемые изменения в структуре бизнес-процессов, обеспечение соблюдения требований законодательства и стандартов в области ведения бизнеса.Управление знаниями и информацией (7) – связанные с этим преимущества достигаются за счет более эффективного использования, распространения и доступа к информации: улучшение доступа, повышение точности информации, улучшения с точки зрения своевременности предоставления информации, улучшения в навигации и синтезе информации, улучшения в способах распространения информации и совместной работе, профилирование и персонализация информации, улучшения в принятии решений или рекомендаций.

Относительное позиционирование дисциплин и методик управления и аудита ИТ

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

Рис. 5.5. Условное позиционирование дисциплин управления и аудита ИТ

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

В таблице 5.3 приведены основные связи между указанными дисциплинами и предметом нашего рассмотрения.

Таблица 5.3. Сравнительное описание различных дисциплин управления и аудита ИТ

ИТ-стратегияИТ-архитектура

TCO	Стратегия может предусматривать оптимизацию TCO в качестве одной из целей развития ИС	Реализация корпоративной архитектуры объективно способствует снижению TCO
ITIL (ITSM, MOF)	Внедрение процессов, основанных на ITIL, часто предусматривается в качестве одной из стратегических целей организации	ITIL определяет лучшие практики реализации процессов управления ИТ, получающих преимущества при наличии корпоративной архитектуры
CMM (CMMI)	CMMI может использоваться для оценки зрелости процесса стратегического планирования, СMM-SW – для оценки зрелости процесса разработки программного обеспечения	CMM-подобные шкалы применяются для оценки зрелости корпоративной архитектуры в целом и отдельных компонент и/или процессов
COBIT	В СOBIT проводится оценка состояния процесса стратегического планирования	В СOBIT проводится оценка состояния процесса разработки и поддержки архитектуры
TVO	TVO может использоваться для определения взаимосвязей между ИТ- стратегией и бизнес-стратегией организации	Показатель TVO позволяет связать инвестиции в корпоративную архитектуру с расширениями возможностей бизнеса
BSC (Balanced Score Card)	Создание BSC для ИТ-службы и установление связей с общей BSC может предусматриваться в качестве одной из стратегических целей организации	Оптимизация архитектуры отражается в значениях показателей, входящих в BSC

Можно заметить, что рассмотренные методики и подходы частично "пересекаются" друг с другом, так что в отдельных аспектах анализа процесса управления ИТ становятся возможными неоднозначности в описаниях и рекомендациях. В работе [8.20] описана достаточно интересная попытка создания так называемой "объединенной рамочной модели" процессов управления (UPF – unified process framework), сфокусированной именно на обеспечении соответствия ИТ и бизнеса. Автор надеется, что такая методика, подкрепленная соответствующими инструментами, появится где-то к 2008 году.

Учет стоимости владения ИТ (TCO)

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

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

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

Зарубежный опыт решения задач оценки эффективности инвестиций в ИТ показывает, что одним из наиболее широко распространенных методов является применение концепции оценки Совокупной Стоимости Владения ИТ (Total Cost of Ownership – ТСО).

Концепция TCO была развита компанией Gartner в середине1990-х годов путем интеграции существовавших моделей Gartner и разработок приобретенной компании Interpose. Под показателем ТСО понимается сумма прямых и косвенных затрат организации на эксплуатацию своих информационных систем.

Здесь стоит особенно подчеркнуть наличие фактора косвенных затрат.

В отличие от ИТ-бюджетов, которые включают только прямые затраты, в показатель TCO включается и оценка затрат косвенных, связанных с недостатками в работе информационных систем, в том числе:

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

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

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

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

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

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

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

Модель TCO для распределенных вычислений выделяет 5 категорий затрат, составляющих Совокупную Стоимость Владения, три из которых относятся к прямым затратам, а две – к косвенным [8.8].

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

Косвенные затраты, связанные с распределенными вычислениями, включают, как отмечено выше, следующие категории:

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

Типичное распределение затрат TCO по категориям для распределенных вычислений (на настольных ПК используется операционная система Windows XP и офисные приложения Microsoft) показано на рис. 5.1. При этом величина TCO составляет около $4750 на пользователя в год.

Рис. 5.1. Типичное распределение TCO по категориям затрат

Важно обратить внимание, что TCO для распределенных вычислений существенным образом зависит от того, насколько эффективно ИТ-служба управляет инфраструктурой. Для средней организации, использующей Windows 2000/XP, этот показатель может быть на 11% меньше, чем в организации, в которой не реализованы процессы управления. А в организации, которая эффективно управляет ИТ-инфраструктурой, TCO может быть меньше на 37% [8.9]. От эффективности управления существенно (буквально, в несколько раз) зависит получение экономии прямых и косвенных затрат, связанных с переходом на более новые версии программного обеспечения.

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

В состав типового проекта по оценке TCO входят такие работы, как:

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

Более подробную информацию по TCO можно найти в Интернет, в т.ч. на сайте http://www3.gartner.com/4_decision_tools/measurement/decision_tools/tco/tco.html, а также в книге К. Скрипкина [8.10], посвященной анализу экономической эффективности информационных систем. Достаточно интересные примеры из практики расчетов по модели TCO, детальное обсуждение методических вопросов и примеры лучших практик по управлению TCO приведены в книге В. Баронова с соавторами [8.11]. Здесь, в частности, отмечается важность использования поправочных коэффициентов, отражающих российские реалии.

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

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

Управление ИТ-активами и инвестициями

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

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

Закупки оборудования и услуг, реализация проектов являются частью общего процесса управления инвестициями в информационные технологии, который предполагает соответствующее планирование, оперативное исполнение и последующую оценку эффективности. Для оценки качества этого процесса также нашла применение CMM-подобная модель зрелости. В частности, такая модель была рекомендована Финансово-контрольным управлением США (GAO) для использования во всех правительственных агентствах [8.16], а аналогичный подход предложен Giga Group [8.17]. Основными элементами этой модели являются этапы выбора, контроля и оценки, как показано на рис. 5.3.

Рис. 5.3. Основные этапы процесса управления инвестициями в ИТ

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

Таблица 5.2 является сопоставительной для оценки зрелости процессов управления ИТ-активами и инвестициями в ИТ по работам [8.18], [8.16].

Таблица 5.2. Шкала оценки уровня управления ИТ-активами

УровеньУправление ИТ-активамиУправление инвестициями в ИТ

1. Хаос	В организации отсутствует информация по имеющимся ИТ-активам. Неиспользуемое оборудование хранится на складе и не контролируется ответственными сотрудниками (речь идет об учете и контроле со стороны ИТ-службы: все оборудование, как правило, в любом случае учитывается в бухгалтерии и "числится" на материально-ответственном лице). В организации отсутствует централизованная служба закупок, они осуществляются подразделениями по мере надобности. Системы учета контрактов на закупку не существует, а сами договоры на поставку хранятся в картонных папках. Нет системы учета интеллектуального капитала организации и стратегии закупок. Отсутствует документированная ответственность за управление ИТ-активами	На предприятии нет общего понимания необходимости организации управления инвестициями в ИТ как процесса, равно как и методов управления инвестициями. Фактически применяемые процедуры обоснования проектов являются специально создаваемыми и могут изменяться от проекта к проекту. Отсутствует единая система измерения показателей эффективности достигаемых результатов. Процессы выбора проектов недетерминированы, а их эффективность непредсказуема
2. Реактивный	Для учета активов используются базы данных или электронные таблицы. Часть оборудования может идентифицироваться с применением автоматизированных средств. Однако такие процедуры, как установка, перемещение, изменение конфигурации отслеживаются далеко не всегда, тем самым данные теряют актуальность и точность. Отчеты служат только для перечисления активов и получения сводных величин, но не используются для выделения проблемных областей. Инвентаризация производится нерегулярно. Лицензии на программное обеспечение рассматриваются в отрыве от аппаратных средств. Данные по существующим активам только спорадически используются при планировании новых закупок	Методы инвестиционного управления четко определены и последовательно используются во всех реализуемых проектах. Произведена инвентаризация всех ИТ-активов. В организации созданы Советы по инвестициям в ИТ
3. Проактивный	Процессы управления активами четко определены и охватывают все этапы жизненного цикла. Существующая база данных по учету активов доступна для использования сервисной службой и интегрирована со средствами автоматической идентификации, а также связана с базой данных по контрактам. Это позволяет осуществлять оценку эффективности использования ресурса. Организация закупок осуществляется выделенной группой под руководством выделенного менеджера, подотчетного руководителю ИТ-службы и финансовой службе. Процессы управления пересматриваются при необходимости в установленном порядке	Все выполняемые проекты собраны в согласованный и сбалансированный портфель инвестиций в информационные технологии. Состав портфеля увязан с целями организации, стратегии их достижения – с определением получаемых преимуществ и критериев риска, а также с финансовыми возможностями компании
4. Сервисный	В дополнение к предыдущему уровню, эффективность процессов постоянно измеряется на основе количественных метрик, например, на основе TCO. Результаты постоянно проводимого анализа регулярно доводятся до сведения бизнес-подразделений для возможной оптимизации. Процессы закупок автоматизированы и интегрированы в общую логистическую цепочку организации. Используются средства оптимизации объемов закупок и содержимого склада	Управление инвестиционным портфелем организации обеспечивается путем последовательной оценки эффективности проектов и развития методов выбора проектов и оценки эффективности. Критичным элементом является проведение объективной оценки эффективности инвестиций после завершения проекта, в том числе относительно выполнения планов и ожиданий по получаемым выгодам. Эти результаты используются для оперативной корректировки текущего портфеля проектов
5. Оптимизированный	Управление ИТ-активами полностью интегрировано в управление всеми активами предприятия с учетом их специфики. Использование активов учитывается как расходы бизнес-подразделений. Оно непосредственно связано с оценкой эффективности и стоимости труда персонала	Мониторинг инвестиций в ИТ и методы управления распространяются на формирование и поддержку стратегических бизнес-результатов. Осуществляется постоянное сравнение существующих процедур и методов с лучшими практиками и конкурентами

<
По оценкам Gartner, на первых трех уровнях находятся соответственно порядка 30%, 45% и 20% организаций, а на 5-м уровне – только единичные организации. С другой стороны, внедрение средств управления активами позволяет обычно сэкономить до 30% стоимости активов в первый год и от 5 до 10% – в каждый последующий.

А к какому уровню зрелости можно отнести эти два процесса в известных вам организациях?

Эта модель управления инвестициями в ИТ, предложенная GAO (Финансово-контрольное управление США), строится таким образом, что каждая последующая стадия достигается путем использования предыдущей стадии в качестве "фундамента" и реализации определенных рекомендаций – так называемых "критических активностей". При этом каждая из пяти стадий зрелости, кроме первой, характеризуется определенным набором "критических" процессов, содержание которых по мере продвижения по стадиям меняется. Например, на стадии 2 определяются такие критические процессы, как "Деятельность Совета по инвестициям в ИТ", "Надзор за ИТ-проектами", "Управление ИТ-активами", "Идентификация потребностей бизнеса для ИТ – проектов" и "Выбор проектов для реализации".

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

Рис. 5.4. Основные элементы критического процесса по управлению ИТ-активами

Организационные и системные отличия и проблемы

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

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

Рис. 6.2. Модель деятельности государственных ведомств

Заметим, что государственный сектор наиболее подвержен рискам неэффективных решений, а отсутствие архитектуры и четкой стратегии становятся особо заметными. Мы уже отмечали, что, по данным американского Центра правительственных технологий, статистика провалов проектов в области ИТ в госсекторе в среднем составляет порядка 70–80% от общего числа по сравнению со значением 54% по всем отраслям в целом. При этом около трети неудач связаны с проблемами и недостатками проектирования архитектуры.

В частности, в 2004 финансовом году, по данным Административно-бюджетного управления США, 17 из 26-ти обследованных федеральных агентств и более половины из основных 1400 ИТ-проектов находились в области риска, более половины из 230-ти федеральных программ не могли продемонстрировать реальный эффект, а еще 20% оказались неэффективными.

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

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

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

К числу объективных факторов, обусловливающих такие негативные результаты, относятся:

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

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

Особенности использования понятия

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

Милтон Фридман

Ежели таковых областей, в коих градоначальники станут второго сорта законы сочинять, явится изрядное количество, то не произойдет ли от сего некоторого для архитектуры Российской Державы повреждения?

М. Е. Салтыков-Щедрин. "История одного города"

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

Все, о чем мы до сих пор говорили, относилось к корпоративной архитектуре уровня предприятия. По большому счету, государство есть совокупность ведомств, которые составляют некоторую "корпорацию", называемую государством. Возникает вопрос: "А нужно ли в таком случае рассматривать отдельно проблему формирования архитектуры информационных технологий государства в целом или архитектуру отдельного региона, города?" Ответ, однако, однозначно положительный – нужно. Тут мы снова имеем типичную ситуацию, когда "целое составляет нечто большее, чем механическая сумма составляющих" [9.1].

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

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

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

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

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

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

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

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

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

Если кратко, то государство отличается от корпораций (и даже крупных корпораций) тремя аспектами:

масштабом;интересами и целями;принципами распределения ответственности и влияния.

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

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

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

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

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

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

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

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

В последние годы появилась литература на русском языке, в которой содержится достаточно обширный материал по тематике архитектуры электронного правительства, большей частью основанный на зарубежном опыте таких стран, как США, Великобритания, Германия и ряд других [9.2], [9.3], [9.4], [9.5]. Несравненно большее количество публичной информации доступно на английском языке в Интернете. Соответствующие указания можно найти в Приложении в разделе "Ресурсы и полезные ссылки". Кроме того, достаточно важной отдельной областью, которая требует своего специального анализа и по которой также существуют обширные публикации, являются сравнительные оценки различных стран в области реализации "электронного правительства" и оценки готовности (readiness) к реализации таких проектов и к информационному обществу в целом. К сожалению, Россия пока, по разным критериям, занимает 50-70-е места в этих списках.

Мы же остановимся на вопросах, которые практически не отражены в литературе на русском языке:

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

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

Использование единых принципов и стандартов разработки архитектуры государственных организаций и архитектуры электронного правительства должно выполнять двуединую роль:

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

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

Разработка методологии описания архитектуры. Эта методология либо явно разрабатывается и формулируется, как это сделано в США в форме методологии Федеральной архитектуры, либо эта методология существует как бы неявно, но проявляется, в конечном итоге, в форме набора документов, описывающих различные аспекты архитектуры электронного правительства и заложенных в них принципов. Данная методология чаще всего создается не на пустом месте, а на основе других методик. Так, например, в Германии за основу взята Справочная Модель Открытых Распределенных Вычислений (RM-ODP – Reference Model of Open Distributed Processing) [9.6]. Как правило, разработка собственных методик реализуется на национальном уровне, для того чтобы, во-первых, учесть национальную специфику государственного устройства, уровень и характер используемых технологий, а во-вторых, обеспечить ведомствам, региональным и местным органам общие подходы и правила разработки собственных архитектур;Разработка собственно архитектуры. На этом этапе разработанная или принятая методология используется для описания и дальнейшего развития существующего и желаемого состояния архитектуры. Эта работа ведется на всех уровнях власти: национальном, уровне центральных ведомств, уровне регионов и т.д.

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

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

Отличия в критериях эффективности использования ИКТ

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

Услуги для граждан и бизнеса. Архитектура должна демонстрировать свою значимость с точки зрения улучшения качества и доступности государственных услуг;Операционная эффективность. Архитектура должна обеспечивать улучшение эффективности и продуктивности работы государства с использованием ИКТ;Политический эффект. То есть, это не традиционный возврат от инвестиций (ROI), а "политический возврат от инвестиций" (PROI – Political Return on Investment). Архитектура должна обеспечивать синхронизацию и выравнивание возможностей, предоставляемых информационными технологиями для реализации миссии, достижения целей и задач, сформулированных политическим руководством.

Рис. 6.3. Три измерения, определяющие ценность использования технологий государством

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

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

Проблема масштаба

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

наличие 13000 различных форм документов, которые государство использует для общения с гражданами и бизнесом;выполнение 5 млрд. различных транзакций ежегодно;наличие 20 крупных ведомств (министерств) на национальном уровне;более 200 меньших по размерам государственных агентств и организаций;480 местных органов власти и управления.

Далеко не каждая крупная коммерческая компания сталкивается с организационно-техническими проблемами такого масштаба. При этом большинство коммерческих компаний имеют обычно не более 10 (в среднем около 6) различных бизнес-процессов, которые включают в себя определенное количество подпроцессов [9.7]. Сколько же бизнес-процессов у государства?

На федеральном уровне Правительство США идентифицировало 487 бизнес-процессов (из них – 28 ключевых, укрупненных процессов). При этом надо заметить, что до недавнего времени госорганизации уделяли непростительно мало внимания анализу своих бизнес-процессов, в то время как реинжиниринг бизнес-процессов – горячая тема с начала 1990-х г.г. Приведем следующую цитату: "Обеспечение тесного соответствия (синхронизации) между ключевыми бизнес-процессами и ИТ-архитектурой является единственной наиболее важной работой по правильному созданию архитектуры" [9.8].

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

Проблема сроков реализации проектов и инкрементальной автоматизации

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

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

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

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

Проблема управления и контроля использования архитектуры (governance)

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

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

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

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

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

Разница в целях государственных и коммерческих организаций

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Федеративная или централизованно-децентрализованная модель архитектуры

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

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

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

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

Как справедливо отмечено в [9.10], два фактора являются обязательными для успеха федеративного принципа реализации архитектуры, который, с нашей точки зрения, является единственно возможным для крупных государственных структур управления:

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

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

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

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

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

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

хорошо определенная архитектура;общие методики;общие форматы и схемы данных.

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

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

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

В качестве примера можно привести концепцию Архитектуры электронного правительства Gartner [9.9], которая выделяет следующие представления:

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

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

Рис. 7.1. Концептуальная архитектура электронного правительства

Заметим, что данная концептуальная архитектура электронного правительства Gartner была опубликована еще в 2001 году и носит достаточно "традиционный" характер. В курсе "Архитектура предприятия" мы описывали несколько иную методику Gartner Group для описания архитектуры предприятия, которая впервые была опубликована в 2002 году. Она также применима к электронному правительству, и чуть позже мы рассмотрим особенности использования этой обновленной методики в отношении электронного правительства.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стандарт на метаданные электронного правительства (e-GMS – e-government Metadata Standard). Основан на так называемом Дублинском ядре и нужен, в частности, для стандартного описания всей информации, публикуемой государственными ведомствами, например, на государственных порталах.Список Категорий Правительственной информации (GCL – Government Category List). Просмотр категорий информации является, как правило, первым инструментом поиска, поэтому целесообразно иметь государственные стандарты в этой области.Каталог Стандартных Государственных Данных (GDSC – Government Data Standards Catalogue). Этот Каталог описывает элементы и типы данных, которые используются, например, в "Общей Информационной Модели Государственной Услуги", описанной в e-SDF (см. ниже), и в Справочной Модели Сообщений, определяющей форматы стандартных сообщений, которыми обмениваются государственные информационные системы. Каталог обеспечивает связь между функциональными требованиями с точки зрения описания услуг ("Общая Информационная Модель Государственных Услуг") и техническим описанием с точки зрения практической реализации (Справочная Модель Сообщений). По большому счету, Каталог Стандартных Государственных Данных описывает имена различных элементов (тэгов), используемых в различных государственных XML-документах (например, как будут именоваться тэги, используемые для описания "Фамилии", "Имени" гражданина, элементов адреса места жительства и пр.), какие типы данных при этом и меются в виду (текстовые, числовые и пр., а также их формат).XML-схемы. XML и XSL рассматриваются в качестве ключевых стандартов для интеграции и управления данными. Это включает механизмы централизованного согласования, создания и определения XML-схем, которые используются всеми государственными ведомствами.Каталог Технических Стандартов (TSC – Technical Standards Catalogue). Определяет технические стандарты и спецификации в четырех областях: взаимодействие систем, интеграция данных, метаданные управления контентом и доступ к электронным услугам. Это минимальный набор стандартов, которые требуются для обеспечения широкого спектра транзакций и услуг, предоставляемых государством, и для интеграции государственных информационных систем.Методика разработки электронных услуг (e-SDF – e-Services Development Framework). Содержит методики описания и разработки электронных государственных услуг, в том числе с применением конструкций языка UML, параметры стандартной модели сервисного взаимодействия государства и гражданина в процессе предоставления услуги, высокоуровневую архитектуру информации, которая включает Общую Информационную Модель Государственной услуги и Справочную Модель Сообщений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Задача 5: Искать дополнительные возможности экономии для пользователей услуг Департамента Информационных Технологий (ДИТ)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Регион, городСайтИспользованная методология

Штат Виржиния, США	http://www.cots.state.va.us/ea/eacomp.htm2.2	META Group5.29.3
Штат Северная Каролина, США	http://irm.state.nc.us/	META Group
Штат Коннектикут, США	http://www.ct.gov/doit/cwp/view.asp?A=1245&q=253976&doitnav=1	META Group
Штат Аризона, США	http://gita.state.az.us/enterprise_architecture/	META Group
Штат Мэн, США	http://www.state.me.us/CIO/ITstrat_plan/	Gartner
Штат Кентукки, США	http://enterpriseit.ky.gov/	Методология "4Front" Methodology of Deloitte & Touche Consulting Group
Штат Массачусетс, США	www.state.ma.us/itd/spg/publications/standards/archstan.htm	Нет информации о методике
Штат Огайо, США	http://das.ohio.gov/ITGD/EAHome.htm	Опубликованы отдельные политики в области ИТ
Штат Делавэр, США	www.state.de.us/dti/	Нет информации о методике
Штат Миссури, США	http://oit.mo.gov/e-government/e-government.html	Методика IBM
Штат Небраска, США	http://www.nitc.state.ne.us/	Нет информации о методике
Штат Нью-Йорк, США	http://www.oft.state.ny.us/	Собственная методика, основанная на методиках NASCIO, Gartner Group, META Group
Штат Монтана, США	http://www.discoveringmontana.com/itsd/	Нет информации о методике
Штат Вашингтон, США	http://dis.wa.gov/index.htm	META Group
г. Меса, США (штат Аризона)	http://www.ci.mesa.az.us/isd/strategy.asp	Нет информации о методике
г. Торонто, Канада	http://www.city.toronto.on.ca/city_hall/ecity.htm	Нет информации о методике
г. Оклэнд, США (штат Калифорния)	http://www.oaklandnet.com/government/vision/vision.html	Нет информации о методике
Штат Куинслэнд, Австралия	http://www.iie.qld.gov.au/site/gia/	META Group
Штат Андхра-Прадеш, Индия	http://www.ap-it.com	Price Waterhouse Coopers

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

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

Департамент энергетики США	http://cio.doe.gov/Publications/publications.html#architecture	Методология Enterprise Architecture Planning (EAP) Спивака
Министерство обороны США	http://www.defenselink.mil/nii/infosuper/Message.html	Методика Министерства обороны DoDAF
Департамент внутренних дел США (функции пожарной службы, охраны природы, охраны национальных меньшинств и т.п.)	http://www.dio.gov/oirm	Federal Enterprise Architecture Framework (FEAF)
Департамент юстиции США	http://www.usdoj.gov/jmd/ocio/ppp.htm	Federal Enterprise Architecture Framework (FEAF)
Федеральное казначейство США	http://www.ustreas.gov/offices/cio/teaf	TEAF, созданная на основе FEAF

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

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

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

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

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

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

При этом 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;использование разработанных централизованно базовых компонент (общих сервисов).

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

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

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

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

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

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

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

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

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

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

Рис. 8.5. Механизмы централизованного управления и децентрализованной реализации архитектуры электронного правительства Германии

Альтернативные взгляды на архитектуру предприятия

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

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

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

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

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

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

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

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

Короче, "Мир праху твоему, архитектура предприятия!".

Объединяем концепции и процессы

... не достигнув желаемого, они сделали вид,будто желали достигнутого.

М. Монтень

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

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

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

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

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

Рис. 9.1. Концепции и процессы, связанные с архитектурой

Большинство этих тем нашло отражение в соответствующих лекциях курса.

Заключительные замечания:"Архитектура предприятия мертва! Да здравствует архитектура предприятия!"

Ну что ж. Эта позиция критиков архитектурных подходов понятна, заслуживает внимания, а главное, извлечения положительных уроков. Попробуем это сделать и мы, сославшись на мнение авторитетов [10.2].

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

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

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

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

Мы уже говорили, что в основе концепций Архитектуры предприятия лежат работы Захмана, которые, в свою очередь, основаны на методиках IBM-планирования бизнес-систем (BSP – Business System Planning), разработанных в 70-х годах прошлого века. Они создавались для того, чтобы обеспечить механизмы оптимального инвестирования в ИТ-системы и разрабатывать оптимальные стратегии сопровождения и эксплуатации систем. Эти методики, в том числе, помогали организациям формализовывать и стандартизировать процессы еще до этапа их автоматизации. Мы все знаем, что когда автоматизированы плохие процессы, порядок вещей становится только хуже: все будет работать так же плохо, но только с большей скоростью и с еще большим отрицательным эффектом.

До начала 1990-х годов в своем первозданном виде Архитектура предприятия была адекватным подходом. Однако по мере того как развивалось программное обеспечение, по мере того как коммерческое программное обеспечение становилось независимой отраслью деятельности, аппаратное обеспечение также начинало становиться все более стандартным. На смену философии "никто никогда не был уволен за то, что он покупает IBM" пришла философия "программное обеспечение определяет выбор платформы".Эта смена философии привела к смене подходов по разработке Архитектуры предприятия. Разработка моделей данных в виде диаграмм "сущность-связи" в нормальных формах для всей информации, которую предприятие будет использовать в будущем, перестало быть адекватным подходом. Почему? В 1990-х годах появились корпоративные программные продукты, каждый со своими моделями данных: например, системы управления ресурсами предприятия (ERP), системы управления поставками (SCM), системы управления отношениями с заказчиками (CRM). Все, кто добровольно отказался в этих условиях от планирования через разработку Архитектуры предприятия, в полной мере испытали проблемы одновременного использования нескольких корпоративных систем внутри предприятия, имеющих перекрывающийся функционал и пересекающиеся наборы данных.

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

Мы уже говорили, ссылаясь на данные аналитических компаний, таких как META Group, что организации, которые используют стандарты в рамках единой Архитектуры предприятия, нередко достигают 30% экономии затрат на реализацию своих ИТ-систем.

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

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

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

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

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

Эти отличия между "старыми" и "новыми" представлениями об архитектуре приведены в таблице 9.1 ниже [10.3].

Таблица 9.1. Атрибуты "старой" и "новой" архитектуры

"Старая" архитектура ИТ"Новая" архитектура предприятия

Стандарты	"Один размер" подходит на все случаи жизни (узкий набор стандартов, применяемых всегда)	Ограниченный список стандартов, с возможностью выбора и рекомендациями по применению
Приоритеты/Цели	Уменьшение затрат. Уменьшение сложности	Уменьшение времени внедрения систем. Уменьшение сложности плюс источник экспертизы
Основная область внимания	Инфраструктура	Прикладные системы
Исследования	Продолжительный анализ для выбора стандартов	Быстрый процесс анализа, постоянные обновления для обеспечения текущих потребностей
Средства накопления знаний	Документация с описанием архитектуры	Web-сайты, содержащие информацию в форме руководств по использованию; архитектурные шаблоны; модели и примеры; программные продукты управления архитектурой
Консультирование	В ограниченной форме	Большее внимание консультированию по вопросам архитектуры
Структуры и процессы управления	"Полицейские" функции, недопущение исключений	Помощь в процессе проектирования систем, связь с другими процессами планирования на предприятии

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

Так что, "Архитектура предприятия мертва! Да здравствует Архитектура предприятия!"