DoDAF ( англ. Department of Defense Architecture Framework , Архитектурный фреймворк Министерства обороны США ) — это архитектурный, комплексный и всеобъемлющий фреймворк (методология), позволяющий Министерству обороны США облегчить управление на всех уровнях, что позволяет принимать более эффективные ключевые решения . Это достигается путем организации эффективной передачи информации через Департаменты, JCAs, Миссии, Компоненты и Программные связки ("Program boundaries"). Визуализация и отображение производится с помощью моделей (так называемых «продуктов» в предыдущих версиях фреймворка).

Модели в понимании DoDAF-методологии — это документы, таблицы и любые другие графические отображения, которые используются в роли шаблона для организации и отображения данных в более понятном виде. Когда данные собраны, заполнены и показаны в моделях, результат называют представлением («view»). Собрание таких представлений (часто – процессов , систем , сервисов , стандартов и так далее) относится к точкам зрения («viewpoints») и с соответствующими определениями все вместе называются Архитектурным Описанием.

DoDAF использует мета-модель данных (Data Meta-Model – DM2), которая является онтологией (набор структурированных данных), составленной из уровней, отражающих особенности представления информации для конкретных групп пользователей. При необходимости, DM2 может быть расширена.

Базовые принципы

Существует восемь базовых принципов (советов), руководствуясь которыми, можно успешно применять DoDAF:

1. Архитектурное описание должно быть чётко ориентировано на провозглашённые цели.
2. Архитектурное описание должно быть по возможности простым и понятным, но не упрощённым.
3. Архитектурное описание должно облегчать, а не затруднять процесс принятия решений.
4. Архитектурное описание должно быть составлено таким образом, чтобы его можно было использовать для сравнения различных архитектур. При составлении архитектурного описания должны в максимальной степени использоваться стандартные типы данных, определяемые в DM2.
5. Архитектурное описание должно выполняться в терминах самих данных, а не инструментальных средств работы с данными.
6. Архитектурные данные должны быть организованы в виде, удобном для групповой работы.
7. Архитектура информационных систем
8. Архитектурное описание должно быть построено таким образом, чтобы его можно было использовать в сетевой среде.

Точки зрения

Перечисленные ниже представления описывают все аспекты архитектурного контекста, которые относятся к ним.

Точки зрения на возможности системы (Capability Viewpoint)

Точка зрения описывает требования к возможностям системы; время, необходимое для развертывания системы; возможности развертки;

Точка зрения на данные и информацию (Data and Information Viewpoint)

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

Точка зрения на эксплуатацию (Operational Viewpoint)

Точка зрения включает операционный сценарий, активности и требования по поддержке Возможностей.

Проектная точка зрения (Project Viewpoint)

Точка зрения описывает отношения между операционными требованиями и требованиями к возможностям системы.

Сервисное представление (Services Viewpoint)

Точка зрения описывает идентификацию сервисов, сервисных элементов и их взаимодействий.

Точка зрения на стандарты (Standards Viewpoint)

Точка зрения описывает некоторые стандарты, которые используют в разработке решений.

Точка зрения на системы (Systems Viewpoint)

Точка зрения описывает системы , системы систем и соединения, поддерживающие работу Департамента Защиты.

Сравнение версии 1.5 и 2

• Основной упор в разработке архитектуры изменился с процесса, в котором продукт является основным звеном («product-centric process») на процесс, спроектированный с целью предоставить данные, которые могут повлиять на решения, в виде, понятном менеджеру
• Продукты были заменены представлениями («views»), которые показывают характерные типы презентации архитектурных данных и производной информации.

Этапы описания и построения архитектуры предприятия по DoDAF

Определить планируемое использование Архитектуры;

Данный шаг определяет то, как разрабатываемую Архитектуру будут использовать. Исследование проводится с целью покрыть требования по использованию на дальнейших шагах («Fit-for-Purpose»).

Определить контекст Архитектуры;

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

Определить данные, требуемые для поддержки разработки Архитектуры;

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

Собрать, организовать, привести в соответствие изначальному плану («correlate») и хранить данные Архитектуры;

Данный шаг включает в себя создание классификации данных: сбор и сортировку (классификацию) данных. На этом шаге и также проводятся работы по классификационному хранению отсортированных данных.

Провести анализ поддержки целей создания Архитектуры;

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

Представить результаты в соответствии с нуждами блока принятия решений;

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

Результат использования подхода

DoDAF предназначен для составления архитектурного описания системы. Результатом его применения будет являться набор документов, а не информационная система.

Ссылки

1. (неопр.) . Дата обращения: 8 марта 2017. 9 февраля 2017 года.
2. Стуктура фреймворка DoDAF v.2
3. Сравнение изменений в версии 2.0 относительно версии 1.5 DoDAF-фреймворка
4. Графическое представление этапов построения и описания архитектуры предприятия в методологии DoDAF