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

2007 год ознаменовался 20-летним юбилеем методологий построения архитектуры предприятия. За это время было разработано множество методологий. Сегодня доминирующее положение занимают четыре методологии: структура Захмана для архитектуры предприятий, методология TOGAF (The Open Group Architecture Framework), архитектура федеральной организации (FEA) и методология Gartner (ранее именуемая Meta Framework).

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

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

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

· формальные (использующие общепринятые правила, нотации и средства) или неформальные;

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

· описательные - предназначенные только для восприятия человеком, или исполняемые, позволяющие исследовать поведение и использовать полученные результаты для выводов об исходной системе;

· статические – не учитывающие, что объект моделирования изменяется с течением времени и динамические, включающие этот фактор влияния.

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

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

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

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

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

Возвращаясь к истории развития общепризнанных моделей в сфере разработки архитектуры предприятия следует отметить, что все рассмотренные в данном пособии модели являются логическим продолжением одна другой, более того образуют вполне наблюдаемую траекторию развития (рис. 2.1). Причем после выпуска первой статьи Захмана, где он описал суть своего подхода и тем самым дал развитие всей дисциплине под названием «архитектура предприятия» исторически разработки новых методов и моделей разделились на 2 основных направления: первое было сосредоточено на государственных организациях и адаптации архитектурных подходов к ним, второе на развитие концепции «архитектуры предприятия» в корпоративной среде (методики IBM, Microsoft, Giga Group, Gartner и т.д.). Причем оба направления развивались параллельно.

Рис. 2.1. Исторические истоки моделей архитектуры предприятия

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

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

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

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

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

Рис. 2.2. Структура модели FEAF

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Иерархия Справочных Моделей в рамках Федеральной архитектуры показана на рис. 2.3.

 

Рис. 2.3. Эталонные модели в схеме FEAF

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

· создавать и организовывать информацию в общефедеральном масштабе;

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

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

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

· более качественно, быстрее и рентабельнее обслуживать потребности клиентов.

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

· предоставление агентствам средств совместного использования инфоресурсов;

· обеспечение для федеральных ведомств и агентств предпосылок для снижения затрат на ИТ;

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

· содействие росту интероперабельности между федеральными ведомствами и организациями.

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

· разработка и внедрение федеральных стандартов по обеспечению интероперабельности;

· координация инвестиций в ИТ в общефедеральном масштабе на базе федеральной архитектуры;

· минимизация усилий по сбору данных;

· гарантированное предотвращение несанкционированного доступа к федеральной информации;

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

· обеспечение эффективного и равноправного доступа к информации;

· применение проверенных жизнью технологий;

· выполнение требований закона о секретности от 1974 г.

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

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

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

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

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

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

· процесс создания архитектуры предприятия;

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

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

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

Очевидно, что FEA представляет собой нечто большее, чем набор моделей. Эта методология включает в себя все необходимое для построения архитектуры предприятия даже для самой сложной, пожалуй, организации в мире - Правительства США. По заявлению управления по реализации программы FEA (FEAPMO), методология FEA в целом обеспечивает:

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 2.4. Службы и сегменты в соответствии с моделью FEA

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

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

· этап 1. Анализ архитектуры: формирование простого и лаконичного представления сегмента с привязкой к плану организации;

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

· этап 3. Стратегия инвестиций и финансирования: рассмотрение способов финансирования проекта;

· этап 4. План управления программой и реализация проектов: создание плана управления проектом и его реализации, включающего контрольные точки и показатели производительности для оценки успешности проекта.

Структура FEA для оценки успеха в использовании архитектуры предприятия описана в документе «Структура оценки архитектуры предприятия по программе FEA 2.1». Уровень готовности федеральных агентств оценивается по трем категориям:

· завершенность архитектуры - уровень готовности собственно архитектуры;

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

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

Административно-бюджетное управление присваивает каждому агентству рейтинг успеха на основе оценок по каждой категории и совокупному показателю следующим образом:

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

· желтый - агентство показало хорошие результаты в области завершенности. Оно также добилось хороших показателей либо в области использования, либо в области результатов;

· красный - агентство либо не завершило разработку архитектуры, либо неэффективно использует разработанную архитектуру.

Эта структура применима и за пределами государственного сектора экономики. Рейтинги по категориям можно эффективно адаптировать ко многим предприятиям для оценки степени готовности их архитектуры. Например, на рис. 2.5 приведены рейтинги Административно-бюджетного управления для завершенности архитектуры, адаптированные для частного сектора экономики [(Р.Сешнс, 2007)]. Аналогичным образом можно адаптировать рейтинги для использования архитектуры и результатов использования архитектуры.

Рис. 2.5. Адаптация методики оценки завершенности архитектуры FEA для частного сектора

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

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

В случае с FEA, особенно на начальных этапах, какие-либо стандарты или методы, позволяющие проводить оценки текущего состояния и степени продвижения разработки вперед, отсутствовали. Поэтому в феврале 2001 г. была выпущена первая версия документа "Руководство по управлению разработкой архитектуры предприятия" (A Practical Guide to Federal Enterprise Architecture. - Chief Information Officer Council. Version 1.0, February 2001), которая и послужила таким стандартом. Данное руководство основано на базовых элементах (установленных в упоминавшемся выше руководстве CIO по созданию рамочной структуры FEAF), которые упорядочены по пяти иерархическим стадиям развития (или зрелости) FEA в соответствии с подразумеваемыми или имеющимися зависимостями между этими элементами. Были классифицированы группы атрибутов, необходимые для определения эффективности различных функций управления FEA. Затем все введенные базовые элементы были распределены по группам атрибутов, а среди них выделены четыре следующие группы:

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

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

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

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

Эта классификация (а фактически стандарт) получила название "Пять стадий зрелости архитектуры предприятия" (GAO's Five Stages of Enterprise Architecture Maturity, version 1.0) и рекомендована всем федеральным правительственным учреждениям. Она была полностью согласована с другими документами по FEA, в частности с разработанным центральным финансовым управлением (GAO) "Руководством по поддержке и улучшению процесса управления инвестициями в информационные технологии" (Information Technology Investment Management: A Framework for Assessing and Improving Process Maturity, Exposure Draft, GAO/AIMD-10.1.23, May 2000). Поскольку классификация занимает ключевое положение в вопросах оценки развития FEA и особенно в области управления инвестициями в ИТ, поддерживающими FEA, представляется целесообразным ознакомить читателей с обобщенным содержанием каждой из пяти устанавливаемых в этом стандарте стадий зрелости архитектуры.

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

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

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

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

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

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