Структурная схема методики Структурная схема этой методики включает в себя пять уровней: - области или домены (Domains) ИТ-архитектуры;
- дисциплины;
- технологические дисциплины;
- продуктовые компоненты;
- документы соответствия.
Области (домены) Области (домены) являются логическими блоками технологической архитектуры. Список доменов: - управление приложениями;
- управление данными;
- управление информацией;
- интеграция;
- управление пользователями и доступ;
- сети и коммуникации;
- платформы;
- управление системами;
- информационная безопасность и т.п.
Дисциплины Дисциплины обеспечивают логическое деление доменов на разделы. Каждая дисциплина содержит одну и более Технологических дисциплин. - Управление активами (Asset management).
- Управление изменениями (Change management).
- Управление событиями (Event Management).
- Поддержка пользователей (HelpDesk).
- Обеспечение непрерывности бизнеса (Business continuity) и др.
Технологические дисциплины Технологические дисциплины – это технические дисциплины, которые поддерживают функциональные технологические разделы архитектуры. Например, дисциплина «Управление Данными» может включать в себя такие Технологические Области, как: - реляционные СУБД;
- плоские файловые системы;
- настольные базы данных;
- модели данных.
Продуктовые компоненты Продуктовые компоненты включают протоколы, продукты (семейства продуктов) и конфигурации, которые специфичны для каждой технологической области. Примерами Продуктовых Компонент, которые могут быть идентифицированы в рамках технологической области «Модели Данных», являются такие продукты, как ERWin, Visio и Designer. Документы Соответствия Документы Соответствия определяют руководства, стандарты и регулирующие документы, которые связаны с Дисциплинами, Технологическими дисциплинами и/или Продуктовыми компонентами. Они предписывают необходимость соблюдения тех или иных международных рекомендаций (RFC), стандартов, законодательных актов – например, по применению сертифицированных средств ЭЦП, внутренних инструкций и т.п. Они могут присутствовать на каждом из уровней и обеспечивают основу для принятия важных решений о новых продуктах, протоколах, конфигурациях и т.д. Описание конкретного решения Для описания конкретного решения используются три типа шаблонов: - «обзор» (scope) – определяет область проекта, цели и подход;
- «требования» – содержит формализованные требования к решению, сгруппированные по типу, т.е. бизнес-требования, функциональные, по безопасности и т.п. В этой части организация шаблона схожа с разделом отечественного стандарта ГОСТ 34.698-90 «Техническое задание на АС»;
- «дизайн» – документирует существенные элементы предложенного решения, включая явные ссылки на соответствующие требования и другие существующие элементы бизнес-архитектуры, архитектуры информации или технологической архитектуры.
Модель «4+1» представления Архитектуры Модель «The 4+1 View Model of Architecture» была предложена Филиппом Кручтеном в 1995 году. Данная методика позиционировалась, прежде всего, как способ описания архитектуры систем, основанных на активном использовании программного обеспечения, хотя идеи, заложенные в эту методику, могут использоваться и в более широком контексте Архитектуры предприятия. Модель «4+1» Модель «4+1» Четырьмя основными представлениями в этой методике являются следующие: - Логическое представление. Является объектной моделью проектирования (в том случае, если используется объектно-ориентированная модель проектирования).
- Процессное представление. Описывает вопросы параллельного исполнения и синхронизации процессов.
- Физическое представление. Описывает размещение программных компонент системы на аппаратных платформах и аспекты, связанные с физическим расположением системы.
- Представление уровня разработки. Описывает статическую организацию программной системы в среде разработки.
Модель «4+1» Описание архитектуры системы на основе этих четырех представлений иллюстрируется и проходит проверку путем использования еще одного представления, которое содержит некоторые отобранные сценарии использования (use cases). |