Метод Развития Архитектуры (Architecture Development Method ADM) TOGAF

В TOGAF процессы создания и развития, управления изменениями, контроля реализации архитектурных решений интегрированы в единый архитектурный цикл Метод Развития Архитектуры (Architecture Development Method ADM). Данный метод можно и нужно адаптировать под задачи вашей компании на всех уровнях разработки архитектуры. При этом, нет необходимости делать все возможные документы. Не нужно погружаться во все детали. На каждом этапе ADM предлагает готовый набор техник, инструментов, шаблонов и чек листов. Метод Развития Архитектуры (ADM) содержит десять фаз. Каждая фаза, в свою очередь разбивается на под-процессы (этапы), отдельные работы и так далее.

Например, фаза D включает следующие основные под-процессы:

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

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

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

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

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

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

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

•Описание существующей системы в терминах TOGAF.

•Определение перспектив (представлений) архитектуры.

•Формирование модели целевой архитектуры.

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

•Подтверждение учета бизнес-требований.

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

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

Фазы и задачи Метода Развития Архитектуры

Предварительная фаза. Основные задачи:

•Создать архитектурную практику,

•подготовить компанию к запуску архитектурных проектов,

•заручиться поддержкой руководства,

•сформулировать архитектурные принципы,

•адаптировать методологию под цели и задачи компании

Фаза А – Видение архитектуры. Основные задачи:

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

•разработать «Устав проекта» и получить формальное подтверждение старта проекта.

Фаза 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 в значительной степени сводится к методике разработки архитектуры. В этом смысле компонента Базовой Архитектуры, содержащая набор служб и стандартов, является некоторой абстрактной реализацией ИТ-системы в целом. Архитектура Общих Систем реализуется путем выбора и интеграции определенных служб для формирования выделенных блоков, которые могут (возможно, повторно или в различных комбинациях) использоваться в различных функциональных областях, таких как архитектура безопасности, сетевая архитектура и т. п.

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

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

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

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

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

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

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

Рисунок: Архитектуры Предприятия «TOGAF»

Примеры принципов, используемых при создании архитектуры TOGAF (Название и содержание):

Пример использования – Сформулированные принципы управления ИТ применимы для всех случаев и подразделений организации.

Максимальная польза – Решения в области ИТ принимаются исходя из максимума пользы для организации в целом.

Привлечение всех – Управление информацией есть дело каждого.

Непрерывность бизнеса – Деятельность предприятия должна обеспечиваться, несмотря на возможные помехи в работе ИТ.

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

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

Ответственность ИТ-службы – ИТ-служба является ответственным владельцем ИТ-ресурсов и исполнителем процессов для удовлетворения требований бизнеса.

Защита интеллектуальной собственности – Обеспечение защиты интеллектуальной собственности организации должно быть реализовано на уровне архитектуры, процессов эксплуатации и управления ИТ.

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

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

Общие метаданные – Метаданные должны быть едиными в рамках предприятия и доступными для всех пользователей.

Безопасность данных – Данные должны быть защищены от неавторизованного использования и распространения.

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

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

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

Взаимодействие – Взаимодействие Компоненты программного и аппаратного обеспечения должны обеспечивать интеграцию между собой в соответствии с общими стандартами.

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

Данный текст является ознакомительным фрагментом.