План работы 244 1 Организация работы по проведению административной реформы. 246 1 Организация работы экспертных групп. 249

Вид материалаОтчет

Содержание


8.4 Требования к средствам моделирования ЕФА и архитектуры отдельной организации. Содержательная структура репозитория ЕФА
8.4.2 Предпосылки к решению задачи комплексного архитектурного моделирования
8.4.3 Общий подход к организации средств и среды комплексного архитектурного моделирования
Блок элементарных объектов ЭП
Блок моделей архитектуры ЭП
8.4.4 Обобщенные требования к среде моделирования ЕФА и архитектуры отдельной организации
Общие требования.
8.4.5 Дополнительные обобщенные требования для среды моделирования ЕФА
8.4.6 Дополнительные обобщенные требования для среды моделирования архитектуры отдельной организации
8.4.7 Конкретные требования к стартовым средствам и среде моделирования ЕФА и архитектуры отдельной организации
8.4.7.1 Первый этап. Требования к стартовым средствам и среде моделирования ЕФА
8.4.7.2 Второй этап. Требования к стартовым средствам и среде моделирования ЕФА
8.4.7.3 Требования к стартовым средствам и среде моделирования архитектуры отдельной организации на первом и втором этапах.
На втором этапе
8.4.7.4 Третий этап развития среды моделирования ЕФА
8.4.8 Содержательная структура репозитория ЕФА
8.4.8.1 Область репозитория "Заинтересованные лица и пользователи ЕФА"
8.4.8.2 Область репозитория "Задачи и области целевого использования ЕФА"
8.4.8.3 Область репозитория "Информационные ресурсы ЕФА"
8.4.8.4 Очередность наполнения и способа представления информации в репозитории
...
Полное содержание
Подобный материал:
1   ...   8   9   10   11   12   13   14   15   ...   23

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

8.4.1 Предпосылки формулирования требований к средствам моделирования ЕФА


Среда моделирования ЕФА не может быть куплена на 100% готовой или разработана до конца в рамках одного локального проекта. Диапазон сложности и размерности задач и средств моделирования весьма велик. Достаточно широк и набор разработанных в настоящее время средств моделирования, хотя выбор адекватного (по возможностям, сложности, стоимости и др. параметрам) средства остается непростой проблемой. (К тому же этот процесс не завершен, и вполне прагматичные прикладные исследования и разработки продолжаются во всем мире, в том числе, и для целей ЭП и ЕФА).

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

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

8.4.2 Предпосылки к решению задачи комплексного архитектурного моделирования


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

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

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

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

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

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

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

8.4.3 Общий подход к организации средств и среды комплексного архитектурного моделирования


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

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

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

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

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

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

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

В развитие этого требования определим, что в общем случае среда моделирования архитектуры ЭП как обобщенной организации (обобщенного предприятия) должна включать следующие 4 компонента (сформулировано в соответствии с текущим уровнем развития методов моделирования рассматриваемого типа, см. например, Report on the State of the Art in Enterprise Modeling, University of Namur, 2002 [75]):

1) Блок элементарных объектов ЭП (также организации, надведомственной деятельности), а именно:
  • описания (представления) элементарных объектов (например, конкретного продукта/услуги, производимого на предприятии в настоящее время);
  • средства, используемые для порождения таких представлений (т.е. данных по объектам) согласно определенным правилам.

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

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

4) Блок языков мета-моделирования и методологий определения методологий моделирования (мета-методологий), соответственно, для описания концепции, синтаксиса и семантики языков моделирования, и методологий их применения, а также для описания процессов построения этих языков и методологий.

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

8.4.4 Обобщенные требования к среде моделирования ЕФА и архитектуры отдельной организации


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

Общие требования.

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

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

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

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

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

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

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

8.4.5 Дополнительные обобщенные требования для среды моделирования ЕФА


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

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

8.4.6 Дополнительные обобщенные требования для среды моделирования архитектуры отдельной организации


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

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

Степень детальности именно архитектурных моделей ограничивается принятым в конкретной организации стандартом на представление задач и требований, относимых к уровню архитектурного конструирования. Эти стандарты должны строиться с использованием положений, содержащихся в определениях соответствующих процессов и работ в стандартах ГОСТ Р ИСО/МЭК 12207:1999 [71] для процессов жизненного цикла программных продуктов и ISO/IEC 15288:2002 [70] для процессов жизненного цикла систем в целом.

В связи с этим в среду моделирования архитектуры отдельных организаций должен входить и

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

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

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

8.4.7 Конкретные требования к стартовым средствам и среде моделирования ЕФА и архитектуры отдельной организации


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

Стартовые средства моделирования ЕФА на первом этапе работ по формированию и использованию ЕФА целесообразно ограничить следующим набором общих методологических схем и типов моделей (см. раздел 7 данного отчета):
  • обобщенная схема ЕФА, включая ее назначение, руководящие принципы формирования, методологический состав и описание схем отдельных архитектурных моделей;
  • адаптированная схема Дж. Захмана (Zachman Framework), расширенная параметрами времени развития организации/системы (этапы жизненных циклов проектов, систем, организаций, ЭП в целом), в качестве универсальной методологической интегрирующей среды;
  • основные справочные (референсные) модели ЕФА (по мере их формирования), представленные в виде документированных классификационных схем и описаний;
  • руководящие методические материалы по построению и применению ЕФА в целом и по отдельным процессам формирования и использования моделей ЕФА.

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

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

На стартовом этапе указанные требования должны реализовываться представлением основной части документов ЕФА в файлах следующих форматов:
  • текстовые документы (включая таблицы и простейшие иллюстрации) в формате RTF;
  • то же в формате HTML-страниц и связанных совокупностей страниц.

Указанные форматы позволяют:
  • представлять практически весь объем моделей, необходимых для формирования первых версий методологических документов и референсных моделей ЕФА;
  • формировать и использовать документы в самых разных офисных средах и инструментах (MS Office, StarOffice, офисные программы и HTML-редакторы условно-бесплатного распространения, и др.).

Для обеспечения дополнительных изобразительных возможностей представления методик и моделей ЕФА на первом этапе допустить использование:
  • файлов MS PowerPoint для презентаций докладов и учебных материалов по ЕФА;
  • графических файлов формата JPG для показа иллюстративного материала (нетекстовые модели, которые не переводятся в формат HTML, нестандартные графические модели, использующие пиктограммы, двухмерные и трехмерные рисунки и схемы, фотографии и т.п.);
  • файлов с электронными таблицами MS Excel для представления шаблонов и примеров расчетов, если такие будут включены в первую версию ЕФА (например, для расчетов значений показателей эффективности/производительности проектов реализации ЭП).

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

Другие форматы (pdf Adobe Acrobat, плоские текстовые файлы, файлы формата DBF и др.) могут использоваться только в особых случаях как средство прямого обмена промежуточными архитектурными продуктами между разработчиками методик и моделей ЕФА и по согласованию с руководителями проектов ЕФА.
8.4.7.2 Второй этап. Требования к стартовым средствам и среде моделирования ЕФА

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

Эти средства должны позволить производить значительный набор операций по автоматизированному анализу совместимости и иных показателей качества архитектур - отдельных организаций и ЕФА.

Международная практика ряда организаций показывает, что таким формализованным представлением моделей ЕФА на определенном периоде ее использования вполне эффективно может быть:
  • на уровне схем моделей и типов объектов/связей - представление архитектурных моделей в виде моделей "сущность-связь" (диаграмм и описаний семантики и формата сущностей, связей и их атрибутов) или ER-моделей (причем такие модели применяются для представления моделей разных типов: функциональных, информационных, компонентных, эффективности и др.);
  • на уровне наполненных моделей и экземпляров объектов/связей - представление моделей в виде наполненных данными таблиц баз данных реляционных СУБД.

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

В связи с этим за время выполнения первого этапа моделирования ЕФА требуется выбрать минимальный набор совместимых нотаций (языков) представления моделей "сущность-связь" и такой формат (форматы) файлов этих моделей, которые позволят выбрать и применять наиболее дешевые и распространенные инструментальные средства построения моделей "сущность-связь" (минимальный список инструментальных систем), и осуществлять преобразования моделей из формата одной инструментальной системы в формат другой из выбранного списка систем. Существенно, что к настоящему моменту:
  • большинство организаций федерального и регионального уровня и значительное число местных органов управления уже обладает опытом работы с реляционными СУБД разных поставщиков;
  • меньшее, но все же значительное число организаций имеет опыт построения моделей "сущность-связь" в CASE-инструментах разных масштабов и поставщиков (начиная с пакета ERwin);
  • существуют форматы стандартных интерфейсов (например, JDBC, ODBC) для обращений (запросов) к БД, поддерживаемым различными реляционными СУБД;
  • наконец, существуют условно-бесплатные реляционные СУБД, возможностей которых может хватить для выполнения ограниченного, но существенного объема работ с моделями в небольших организациях.

Функциональные требования к инструментам на этом этапе:
  • включают те, что определены для первого этапа (методические руководства и текстовые описания референсных архитектурных моделей продолжают поддерживаться в указанных для первого этапа форматах);
  • дополняются требованием наличия возможностей преобразования моделей из формата одной инструментальной системы в формат другой из выбранного списка систем (возможно через промежуточные текстовые файлы с записями стандартизованной структуры);
  • расширяются возможностями управляемого доступа к информации архитектурных моделей, поддерживаемой в базах данных реляционных СУБД в виде таблиц и представлений языка SQL, причем средствами стандартизованного подмножества SQL, хорошо совместимого со стандартами, обеспечивающими интероперабельность данных в БД репозитория моделей ЕФА второго этапа.

Как дополнительное функциональное требование к выбираемым инструментальным средствам надо определить возможность осуществлять автоматизированное преобразование референсных архитектурных моделей ЕФА из нотации "сущность-связь" в формат схем реляционных баз данных SQL.

Дополнительная детализация и, возможно, дополнение требований должна производиться в течение выполнения первого этапа моделирования ЕФА и во время подготовки ко второму этапу.
8.4.7.3 Требования к стартовым средствам и среде моделирования архитектуры отдельной организации на первом и втором этапах.

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

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

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

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

На третьем этапе целесообразно перейти к использованию многомодельной расширяемой среды моделирования, которая позволяла бы:
  • интегрировать модели ЕФА и организаций предусмотренных видов (достаточно широкого диапазона);
  • работать с этими моделями в режимах их сочетания (например, для поиска, анализа и совершенствования общих для нескольких министерств деловых процессов и информационных ресурсов, для оценки согласованности архитектуры конкретного министерства и ЕФА, для решения других основных задач применения ЕФА);
  • достаточно оперативно, точно, открыто решать задачи, ради которых создается ЕФА и производится ее сочетание с архитектурами организаций;
  • использовать модели ЕФА и организаций (объединений последних) вне зависимости от того, где физически эти модели созданы и поддерживаются;
  • естественно, координировано и без избыточных затрат распространять этот архитектурный процесс на архитектурные модели ЭП регионов;
  • сохранять поступательную преемственность разработок систем для ЭП при смене/модификации моделей этих систем;
  • планировать и осуществлять автоматизированный процесс использования компонентов архитектуры многократного использования (моделей, прикладных сервисов, например) в подходе "Управляемые моделями" ("Model Driven"), то есть основываясь на доступности моделей компонентов и самих компонентов в необходимых режимах: от статического режима до динамического режима связывания моделей и выполнения приложений в системах организаций (в режиме Run Time).

Для этого параллельно с выполнением первых двух шагов ввода в действие среды моделирования ЕФА необходимо выполнить совокупность НИОКР предпосылки и требования к которым описаны ниже.

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

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

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

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

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

4) Должны быть разработаны критерии и методики оценки качества моделей как общесистемного, так и экономического характера.

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

В рамках исследовательского и, затем, пилотного проектов целесообразно детальное изучение языка UEML (Unified Enterprise Modeling Language) и других компонентов этой системы моделирования. Другим кандидатом на изучение и практическое опробование является система System Architect (Popkin Software), поддерживающая не только конкретные традиционные типы моделей, включая рекомендуемый для второго этапа моделирования ЕФА тип модели "сущность-связь", но и язык BPML и схему Захмана в целом.

Целесообразно объединить в одном проекте оба эти языка/инструмента для опробования реальной совместимости моделей ЕФА и конкретной организации. Целесообразно также включить в этот проект и хорошо известные средства для комплекса IDEF, начиная с пакета ERwin для поддержки моделей типа "сущность-связь", либо для другой равной по мощности моделирования нотации моделей этого типа.

Указанный список систем для включения в описываемый проект не является закрытым. Так, в случае детального планирования проекта можно рассмотреть включение в состав изучаемых систем системы METIS, охарактеризованной в первом разделе данного отчета. Для расширения метаязыковых средств среды моделирования надо рассмотреть мета-средства, разработанные некоммерческим консорциумом OMG, а также стандарты архитектурного моделирования этой организации, а именно:
  • MOF (Meta Object Facility), которое может быть кандидатом на средство описания метамоделей и репозитариев (в том числе - для представления архитектуры данных);
  • MDA (Model Driven Architecture), комплекс стандартов "Архитектура, управляемая моделями", который направлен на отделение деловых моделей от используемых технологических (компьютерных) платформ и использование шаблонов для ускорения процесса моделирования.

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

В качестве языка описания форматов обмена моделями целесообразно рассматривать язык XML.

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

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

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

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

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

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

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

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

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

8.4.8 Содержательная структура репозитория ЕФА


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

Репозиторий целесообразно организовать как несколько основных взаимосвязанных областей информации, требующейся не только для формирования моделей ЕФА, но и для полноценного ее использования. Эти области таковы:
  • заинтересованные лица и пользователи ЕФА;
  • задачи и области целевого использования ЕФА;
  • информационные ресурсы ЕФА.
8.4.8.1 Область репозитория "Заинтересованные лица и пользователи ЕФА"

В эту область включаются сведения о всех категориях лиц и лицах, получающих доступ к репозиторию. В категории лиц входят:
  • члены организаций, разрабатывающих методологию ЕФА, основные и вспомогательные документы ЕФА (включая справочные модели ЕФА), члены централизованного органа по их разработке;
  • члены централизованного органа по использованию ЕФА, его комитетов и рабочих групп (включая тех, кто управляет финансированием проектов),
  • эксперты-аудиторы;
  • члены отделов организаций, разрабатывающих архитектуры этих организаций:
  • руководители проектов и архитекторы конкретных систем;
  • аналитики и разработчики архитектур типовых ИКТ-решений;
  • другие пользователи.
8.4.8.2 Область репозитория "Задачи и области целевого использования ЕФА"

К каждой задаче/области целевого использования ЕФА могут обращаться разные категории лиц. Каждая задача/область целевого использования ЕФА связана со многими описаниями в области "Информационные ресурсы ЕФА". Разные задачи/области целевого использования ЕФА могут использовать одни и те же описания в области "Информационные ресурсы ЕФА". В "Задачи и области целевого использования ЕФА" входят:
  • межотраслевое сотрудничество, общие проекты;
  • улучшение производительности деловых процессов и систем;
  • выбор целостных компонентов архитектуры и решений;
  • выбор компонентов систем;
  • компоновка решений на основе компонентов архитектуры;
  • примеры передового опыта;
  • общая информация совместного использования.
8.4.8.3 Область репозитория "Информационные ресурсы ЕФА"

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

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

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

Целесообразно на верхнем уровне организации этой области репозитория группировать информационные ресурсы ЕФА на разделы следующим образом:
  • основополагающие документы ЕФА;
  • архитектура деятельности ЭП;
  • системная прикладная архитектура ЭП;
  • техническая архитектура ЭП;
  • архитектура непрерывности деятельности и безопасности ЭП;
  • архитектура производительности/эффективности ЭП;
  • архитектуры организаций;
  • архитектуры межведомственных инициатив и систем;
  • конкретные модели компонентов;
  • методы, средства моделирования и рекомендации по их использованию;
  • практика и уроки;
  • другое.

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

Очередность наполнения репозитория определяется очередностью разработки компонентов ЕФА. Первые ее этапы и шаги определены в разделе 7 данного отчета.

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