Архитектура предприятия

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

Примерами таких сервисов являются управление контентом, серверы приложений, серверы выполнения бизнес-правил;

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

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

Этап 3 — разработка плана реализации, обеспечивающе-

го миграцию в сторону желаемого состояния архитектуры.

В полном описании методики META Group приводятся следующие разделы:

практическая реализация архитектуры через процесс управления корпоративными ИТ-программами и проектами;

вопросыуправления и контроля архитектурного процесса;

оценка зрелости архитектуры;

анализ технологических тенденций и планирование;

управление портфелем ИТ-активов и проектов. Подробное описание методики разработки архитектуры пред-

приятия META Group содержится в документе Enterprise Architecture Desk Reference.

4.4. Методика TOGAF

Методика описания архитектуры TOGAF (The Open Group Architecture Framework) [30] была предложена некоммерческим объединением The Open Group, которое входит ряд ведущих производителей информационных технологий, а также компаний

202 Глава 4. Обзор моделей и методик построения…

из списка «Fortune 1000»1 . TOGAF позиционируется ее авторами не как некоторая эталонная модель, а как «средство для разработки архитектур информационных систем». Основное назначение TOGAF — ускорить и облегчить процесс разработки архитектуры конкретной организации, обеспечивая при этом возможность будущего развития. В феврале 2009 года была опубликована девятая версия этой модели.

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

внеобходимой степени рассматриваются и эти смежные области.

Всостав модели TOGAF входят два основных компонента:

методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры, и базовая архитектура FA (Foundation Architecture). Базовая архитектура дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык ADML. Процесс разработки архитектуры по методике ADM включает следующие фазы:

подготовка — уточнение модели с учетом особенностей организации, определение принципов реализации проекта;

фаза A — определение границ проекта, разработка общего представления архитектуры; утверждение плана работ и подхода руководством;

фаза B — разработка бизнес-архитектуры предприятия;

фаза C — разработка архитектуры данных и архитектуры приложений;

1 Список самых крупных по уровню дохода компаний США по версии журнала «Fortune».

фаза D — разработка технологической архитектуры;

фаза E — проверка возможности реализации предложенных решений;

фаза F — планирование перехода к новой системе;

фаза G — формирование системы управления преобразованиями;

фаза H — управление изменением архитектуры.

Каждая фаза, в свою очередь, разбивается на подпроцессы (этапы), отдельные работы и так далее. Например, фаза D включает следующие основные подпроцессы:

описание существующей технологической архитектуры:

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

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

-выявление и описание элементарных архитектурных блоков — кандидатов на использование в новой архитектуре. Фактически, речь идет о возможных архитектурных шаблонах;

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

-направление черновика отчета на рецензирование, анализ комментариев и внесение, при необходимости, поправок;

формирование целевой технологической архитектуры:

-описаниесуществующейсистемыв терминах TOGAF;

-определение перспектив (представлений) архитектуры;

-формирование модели целевой архитектуры;

-определение ИТ-служб (сервисов);

-подтверждение учета бизнес-требований;

-определение архитектуры и используемых блоков (шаблонов);

-проведение анализа расхождений (gap analysis).

204 Глава 4. Обзор моделей и методик построения…

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

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

Важно отметить, что TOGAF распространяется свободно и может быть использована бесплатно любой организацией для разработки внутренних проектов. Лицензируется только коммерческое использование. В настоящее время с сайта The Open Group было загружено 90000 копий TOGAF. Количество проданных экземпляров серии TOGAF составило более 20000.

4.5. NASCIO1 Architecture Toolkit

Набор шаблонов IT Architecture Toolkit первоначально позиционировался как специализированное средство для документирования ИТ-архитектуры организации.

1 NASCIO (National Association of State Information Resource Executives) —

Национальная ассоциация руководителей государственных информационных ресурсов (США, 1969 г.).

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

В версии 2.0 данного подхода структурная схема методики включает пять уровней [1]:

1)области, или домены, ИТ-архитектуры;

2)дисциплины;

3)технологические дисциплины;

4)продуктовые компоненты;

5)документы соответствия.

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

управление приложениями;

управление данными;

управление информацией;

интеграцию;

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

сети и коммуникации;

платформы;

управление системами;

информационную безопасность и т. п.

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

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

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

В табл. 4.3. приведен пример иерархии описания архитектуры в соответствии с рекомендациями NASCIO.

Таблица 4.3

Пример иерархии описания архитектуры в соответствии с рекомендациями NASCIO

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

208 Глава 4. Обзор моделей и методик построения…

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

В версии 3.0 [31], опубликованной в октябре 2004 г., предмет рассмотрения охватывает уже и область бизнес-архитек- туры, так что набор шаблонов может рассматриваться наряду с другими универсальными рамочными моделями.

Таблица 4.4 Области и дисциплины модели технологической архитектуры

Набор шаблонов версии 3.0 включает пять взаимосвязанных архитектур:

1) архитектуру управления;

2)бизнес-архитектуру;

3)информационную архитектуру;

4)технологическую архитектуру (практически соответст-

вует всей ИТ-архитектуре, рассмотренной в версии 2);

5)архитектуру решений (Solution Architecture), обусловившую частичное изменение структуры модели.

Шаблоны «Архитектура управления» интересны специалистам, занимающимся процессом управления архитектурой предприятия или планирующим в будущем посвятить себя такой деятельности. В данной архитектуре наряду с описанием управления персоналом, ролями и обязанностями предлагаются инструменты оценки и типовые структуры организаций.

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

сдругими органами власти, внутренние процессы) или географическому признаку.

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

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

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

210 Глава 4. Обзор моделей и методик построения…

описания является индикация типа состояния компонента, т. е. принадлежности к существующему или целевому состоянию.

Информационная архитектура включает архитектуру дан-

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

Технологическая архитектура представляет типовые мо-

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

Новым понятием в наборе шаблонов IT Architecture Toolkit является архитектура решений, облегчающая описание ее элементов в пределах предприятия посредством определенного перечня предлагаемых архитектору направлений при формулировании требований к решениям, спецификации проекта и логическим моделям проекта. Фактически данная архитектура представляет слой шаблонов из модели Gartner (см. параграф 4.2). В отличие от остальных архитектур, описания элементов архитектуры решений не содержат такого признака, как «существующий» или «целевой». Фактически все эти «решения» относятся как раз к стадии перехода от существующего состояния к целевому, так что по завершении соответствующего проекта они сохраняются со статусом «архивный» [1]. Для описания конкретного решения используются три типа шаблонов:

1)«область» — тип шаблона, описывающий полное решение и связь решения с планом выполнения. Данный шаблон определяет концептуальную модель решения;

2)«требования» — тип шаблона, содержащий формализованные требования к наборам решений, сгруппированных по типам. Организация шаблона схожа с ГОСТ 34.698-9 «Техническое задание на АС»;