Всего за 400 руб. Купить полную версию
Предварительная фаза. Основные задачи:
Создать архитектурную практику,
подготовить компанию к запуску архитектурных проектов,
заручиться поддержкой руководства,
сформулировать архитектурные принципы,
адаптировать методологию под цели и задачи компании
Фаза А Видение архитектуры. Основные задачи:
Запустить архитектурный проект, определить цели и задачи, определить рамки, предположения и ограничения проекта, разработать видение архитектуры, определить всех заинтересованных лиц,
разработать «Устав проекта» и получить формальное подтверждение старта проекта.
Фаза B Бизнес Архитектура. Основные задачи:
Разработать архитектуру с описанием текущей и целевой архитектуры,
Анализ расхождений
Фаза C Архитектура Информационных Систем . Задачи:
Разработать архитектуру с описанием текущей и целевой архитектуры,
Анализ расхождений
Фаза D Техническая Архитектура. Основные задачи:
Разработать архитектуру с описанием текущей и целевой архитектуры,
Анализ расхождений
Фаза Е Возможности и решения. Основные задачи:
Выполнить начальное планирование реализации задач проекта.
Идентифицировать основные проекты внедрения и сгруппировать их в переходные архитектуры.
Фаза F Планирование миграции. Основные задачи:
Анализ затрат и рисков.
Разработка детального плана внедрения и миграции.
Фаза G Управление реализацией. Основные задачи:
Архитектурный надзор за проектами внедрения.
Подготовить архитектурные контракты.
Обеспечить соответствие архитектуре результатов проектов внедрения.
Фаза H Управление изменениями архитектуры. Задачи:
Подготовится к следующему витку жизненного цикла архитектуры.
Процесс управления изменениями должен обеспечить соответствие архитектуры актуальным потребностям бизнеса и дать максимальную ценность бизнесу.
Управление требованиями. Основные задачи:
На каждой фазе архитектурного проекта собираете и согласуете бизнес требования.
Требования должны быть идентифицированы, сохранены, определены приоритеты и использованы на соответствующих фазах архитектурного проекта.
Спецификация TOGAF также позволяет гибко работать с этапами. В самой спецификации говорится следующее:
Перед применением методики разработки архитектуры необходимо проверить компоненты на применимость, а затем связать их с конкретными обстоятельствами отдельного предприятия. Это позволяет создать методику разработки архитектуры для конкретного предприятия.
Модель TOGAF позволяет выполнять этапы частично, пропускать их, объединять, изменять порядок и вносить изменения в соответствии с конкретными требованиями. Неудивительно, что два сертифицированных консультанта по TOGAF могут разработать два совершенно различных процесса даже при работе с одной и той же организацией.
Модель TOGAF обладает еще большей гибкостью
в отношении созданной архитектуры. Фактически TOGAF, как это ни удивительно, «ничего не знает» об архитектуре. Окончательная архитектура может с одинаковым успехом быть хорошей, плохой или неопределенного качества. В TOGAF описывается, как создать архитектуру предприятия, но не описывается, как создать хорошую архитектуру. Качество конечного продукта зависит от опыта персонала компании и консультанта по TOGAF. Те, кто внедряет TOGAF в надежде получить чудодейственное средство, будут жестоко разочарованы (впрочем, как и при использовании любой одной методологии).
Базовая Архитектура (Foundation Architecture)
набор наиболее общих служб и функций, объединенных в Техническую Эталонную Модель (Technical reference model TRM);
набор элементарных архитектурных элементов, которые используются как «строительные блоки» при построении конкретных решений;
база данных стандартов (Standards Information Base).
Концепция использования Базовой архитектуры определяется в соответствии с иерархией архитектур, входящих в общий континуум определений. В TOGAF техническая эталонная модель рекомендуется к использованию, но не являются обязательной. В общем техническая эталонная модель, не лишена недостатков по следующей причине: она направлены на обеспечение переносимости приложений в ущерб их способности к взаимодействию и автономности. Для организаций модель TOGAF в значительной степени сводится к методике разработки архитектуры. В этом смысле компонента Базовой Архитектуры, содержащая набор служб и стандартов, является некоторой абстрактной реализацией ИТ-системы в целом. Архитектура Общих Систем реализуется путем выбора и интеграции определенных служб для формирования выделенных блоков, которые могут (возможно, повторно или в различных комбинациях) использоваться в различных функциональных областях, таких как архитектура безопасности, сетевая архитектура и т. п.
Следующая степень детализации реализуется на уровне Отраслевой Архитектуры, которая добавляет специфичные для каждой индустрии модели данных, приложения, стандарты, бизнес-правила, а также, при необходимости, процедуры взаимодействия различных отраслевых систем между собой. Наконец, на последнем уровне Архитектуры Организации формируется архитектура ИТ-систем конкретного предприятия, учитывающая все его особенности, в том числе наличие унаследованных систем, планы и возможности реализации, организацию данных на физическом уровне и т. п.