Опубликован: 07.05.2007 | Уровень: специалист | Доступ: платный
Лекция 8:

Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF

Методика TOGAF

Методика описания архитектуры TOGAF (сокращение от The Open Group Architecture Framework) была предложена некоммерческим объединением The Open Group, в которое входит ряд ведущих производителей информационных технологий, а также компаний из списка Fortune 1000. TOGAF позиционируется ее авторами не как некоторая эталонная модель, а как "средство для разработки архитектур информационных систем". Основное назначение – ускорить и облегчить процесс разработки архитектуры конкретной организации, обеспечивая при этом возможность будущего развития. В декабре 2003 года была опубликована версия 8.1 этой модели.

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

В состав модели TOGAF входят две основные компоненты – методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры, и Базовая Архитектура (Foundation Architecture). Она дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык ADML. Заметим, что в описании TOGAF добавлен специальный документ, поясняющий соответствие между понятиями TOGAF и моделью Захмана.

Общая структура TOGAF [5.17] показана на рис. 8.9.

Структура TOGAF

Рис. 8.9. Структура TOGAF

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

В соответствии с методикой ADM, процесс разработки архитектуры включает следующие фазы:

  • Подготовка: уточнение модели под особенности организации, определение принципов реализации проекта.
  • Фаза A: определение границ проекта, разработка общего представления (Vision) архитектуры; утверждение плана работ и подхода руководством.
  • Фаза B: разработка бизнес-архитектуры предприятия.
  • Фаза C: разработка архитектуры данных и архитектуры приложений.
  • Фаза D: разработка технологической архитектуры.
  • Фаза E: проверка возможности реализации предложенных решений.
  • Фаза F: планирование перехода к новой системе.
  • Фаза G: формирование системы управления преобразованиями.
  • Фаза H: управление изменением архитектуры.

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

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

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

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

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

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

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

Здравствуйте,при покупке печатной формы сертификата,будут ли выданы обе печатные сторны?

Vatslav Vatslav
Vatslav Vatslav
Россия, г. Калининград
Алексей Назаренко
Алексей Назаренко
Россия