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

Этап 2 — разработка концептуальной архитектуры, оп-

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

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

•принципы представляют собой утверждения, которые касаются архитектурного процесса или содержания архитектуры;

•количество принципов ограничено, и они являются неизменным фундаментом для построения архитектуры;

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

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

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

•формулировку миссии и стратегических целей домена;

•описание компонентов домена с точки зрения единого представления включенных в домен технологий;

•принципы проектирования, принятые в домене. Они определяют правила, применяемые в процессе принятия решений

вотношении технологий домена;

•обоснования и последствия принятия принципов. Здесь могут быть построены матрицы соответствия между требованиями к

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

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

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

•примеры лучших практических реализаций;

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

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

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

пространением принципов сервис-ориентированной архитек-

туры. Это связано с описанием, например, сервисов презентации информации (порталов, настольных систем и пр.), сетевых сервисов (LAN, WAN, удаленного доступа), сервисов безопасности (управления пользователями, доступа), сервисов хранения данных (SAN — Storage Area Network, файловые системы), сервисов баз данных (OLTP — Online Transaction Processing), интеграци-

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

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

Примерами являются ПО пересылки сообщений промежуточного слоя, мониторы транзакций, сервисы каталогов;

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