Мы уже отмечали, что на региональном уровне и уровне крупных муниципалитетов, как правило, отсутствует необходимость в разработке собственной методологии описания архитектуры. Таким образом, основная проблема состоит не в создании собственной методологии, а в обосновании перед руководством региона или города необходимости практической организации разработки архитектуры и обеспечении долгосрочной поддержки со стороны высшего руководства этих усилий. Ощутимые результаты могут быть получены не сразу, поэтому есть риск угасания интереса к работе, переключения на другие приоритеты и поиск другой "палочки-выручалочки", которая якобы "быстро и безболезненно" решит все проблемы создания, развития и использования информационно-коммуникационных технологий в городе или регионе.
Известные нам практические примеры – описание архитектуры уровня отдельных штатов США, отдельных городов Северной Америки и Европы – основаны на использовании какой-либо одной из известных на практике методологий. При этом нам встречались случаи, когда в основу работ были положены, например, методологии META Group или Gartner.
Спецификой органов государственного управления является то, что они в силу ряда причин должны более явно, четко и структурировано делать достоянием общественности информацию, описывающую практику использования информационных технологий. Это связано как с большей формальной подотчетностью органов власти перед обществом (публичная ответственность государства перед налогоплательщиками) и вышестоящими органами, так и с масштабами, т.е. необходимостью более четко распространять информацию об общей архитектуре, принятых стандартах и правилах достаточно большому количеству людей, рассредоточенных по различным ведомствам. То есть архитектура информационных технологий правительства соответствующего уровня – это механизм распространения информации о соответствующих, связанных с ИТ вопросах внутри ведомств, между ведомствами и с обществом. По крайней мере, так это выглядит в теории, чего нельзя сказать в полной мере об отечественной практике.
В курсе "Архитектура предприятия" в начале лекции, посвященной основным элементам архитектуры предприятия, мы отмечали, что это понятие включает формулировку принципов, целей, задач, стратегий, а также разработку моделей для отдельных доменов архитектуры и, наконец, связанные с ними стандарты, правила и т.д. Мы также приводили примеры архитектурных принципов, которые абсолютно применимы и для органов государственного управления любого уровня.
Остановимся на таких аспектах архитектуры, как цели, задачи и стратегии, и приведем соответствующие примеры. Цели, задачи и обеспечивающие эти задачи стратегии определяются уровнем развития информационных технологий и соответствующими потребностями в них. В качестве примера приведем выдержки с описаниями целей и стратегий Департамента информационных технологий штата Вашингтон, США. [9.18].
В этом документе сформулированы следующие высокоуровневые цели на 2005-2007 года:
Для достижения этих целей были сформулированы следующие задачи и обеспечивающие решение этих задач стратегии (мы комбинировали для краткости задачи и стратегии на 2003-2005 и 2005-2007 года).
Задача 1: Обеспечить бесперебойную работу основных ИТ-систем
Задача 2: Поддерживать передовые позиции в области электронного правительства через инновации
Задача 3: Обеспечить баланс контроля и инноваций в практике управления
Задача 4: Стимулировать и обеспечивать межведомственную и межфункциональную кооперацию
Задача 5: Искать дополнительные возможности экономии для пользователей услуг Департамента Информационных Технологий (ДИТ)
Задача 6: Продолжать использование эффективных и стратегических методов работы внутри ДИТ
Что касается описания отдельных представлений (доменов) архитектуры, то здесь могут использоваться все те методики и подходы, которые мы достаточно много уже обсуждали в курсе. Описание принятых на соответствующем уровне государственного управления политик, стандартов и процедур является существенной составляющей всего архитектурного процесса. Поэтому их разработку целесообразно вести в рамках отдельной специальной программы. Общее взаимодействие процессов представлено на диаграмме 8.7.

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