Когда производится оплата и как отказаться от курса? |
NASCIO. Модели "4+1" и SAM. Методики Microsoft и другие. Выбор "оптимальной" методики
NASCIO Architecture Toolkit
Набор шаблонов IT Architecture Toolkit, разработанный американской ассоциацией CIO, первоначально позиционировался как специализированное средство для документирования ИТ-архитектуры организации. Основное преимущество его использования заключается в построении иерархической системы описаний элементов, удобной для поддержания жизненного цикла документа, т.е. в форме, предполагающей его возможные изменения в будущем по мере изменения требований бизнеса и совершенствования технологий. Однако в версии 3.0, опубликованной в октябре 2004 года [5.18], предмет его рассмотрения уже охватывает и область бизнес-архитектуры, так что он может рассматриваться наряду с другими универсальными рамочными моделями. Другим весьма полезным обстоятельством является большое количество реальных примеров из практики отдельных американских штатов и федеральных организаций.
Для наших целей сравнительного анализа интересно проследить эволюцию данного подхода, поэтому вначале мы рассмотрим основные идеи, заложенные в версию 2.0. В этой версии структурная схема этой методики включала в себя пять уровней:
- области или домены (Domains) ИТ-архитектуры;
- дисциплины;
- технологические дисциплины;
- продуктовые компоненты;
- документы соответствия.
Области (домены) являются логическими блоками технологической архитектуры. Каждая Область может включать одну и более дисциплин. Вся ИТ-архитектура подразделялась на набор областей верхнего уровня (доменов), описывающих отдельные аспекты ИТ-систем. В составе списка доменов предлагалось выделять такие области, как:
- управление приложениями;
- управление данными;
- управление информацией;
- интеграция;
- управление пользователями и доступ;
- сети и коммуникации;
- платформы;
- управление системами;
- информационная безопасность и т.п.
Дисциплины обеспечивают логическое деление доменов на разделы, которыми уже проще управлять, т.е. домены включают в себя несколько функциональных дисциплин. Дисциплины представляют собой достаточно связанные единицы в рамках соответствующей предметной области. Каждая дисциплина содержит одну и более Технологических дисциплин.
Например, в домен Управление системами входят, в том числе, следующие дисциплины:
- Управление активами (Asset management).
- Управление изменениями (Change management).
- Управление событиями (Event Management).
- Поддержка пользователей (HelpDesk).
- Обеспечение непрерывности бизнеса (Business continuity) и др.
Технологические дисциплины – это технические дисциплины, которые поддерживают функциональные технологические разделы архитектуры. В качестве примера (см. табл. 9.3 ниже) можно привести Дисциплину "Управление данными" (Data Management), которая является частью Области "Информация". Дисциплина "Управление Данными" может включать в себя такие Технологические Области, как:
- реляционные СУБД;
- плоские файловые системы;
- настольные базы данных;
- модели данных.
Каждая из этих технологических областей включает свои продукты, протоколы и связанные с ними конфигурации. Это детализируется на уровне "Продуктовые компоненты". С указанного уровня начинаются технические детали технологической архитектуры.
Продуктовые компоненты включают протоколы, продукты (семейства продуктов) и конфигурации, которые специфичны для каждой технологической области. Примерами Продуктовых Компонент, которые могут быть идентифицированы в рамках технологической области "Модели Данных", являются такие продукты, как ERWin, Visio и Designer 2000. Документация для каждой компоненты включает оценочные критерии, которые были использованы для включения продуктовой компоненты в общую технологическую архитектуру.
Документы Соответствия определяют руководства, стандарты и регулирующие документы, которые связаны с Дисциплинами, Технологическими дисциплинами и/или Продуктовыми компонентами. Они предписывают необходимость соблюдения тех или иных международных рекомендаций (RFC), стандартов, законодательных актов – например, по применению сертифицированных средств ЭЦП, внутренних инструкций и т.п.
Документы соответствия могут присутствовать на каждом из этих уровней и обеспечивают основу для принятия важных решений о новых продуктах, протоколах, конфигурациях и т.д.
Для элементов описания архитектуры в документе определяется следующее:
Область (домен) | Описание, область охвата, входящие функциональные области, принципы, лучшие практики, тренды |
Дисциплина | Описание, область охвата, ссылка на Домен, кросс-ссылки на другие функциональные области, методологии, Технологические Области, требования к документированию |
Технологическая дисциплина | Описание, ссылка на функциональную область, обоснование выбора единственного или множественных продуктов (вендоров, приложений) |
Продукты/приложения | Описание, ссылка на Технологическую область, информация о вендоре, классификация, условия использования, политика миграции |
Важным преимуществом такого подхода является возможность представления всего описания архитектуры в виде единой (гипертекстовой) базы данных, что позволяет эффективно организовать процессы управления жизненным циклом отдельных документов (см. ниже), а также эффективно разграничить права доступа к отдельным разделам (например, документам, описывающим применяемые средства защиты информации) при сохранении целостности и единства описания.
Пример приведен в табл. 9.2.
В таблице 9.3 дан пример модели технологической архитектуры, включающей в себя девять Областей, которые, в свою очередь, разбиты на 26 технических функциональных элементов или Дисциплин. Каждая организация должна определять свой набор технических дисциплин в зависимости от потребностей, но приведенный пример может служить отправной точкой.
В версии 3.0 набор включает в себя как процесс управления ИТ (IT Governance), так и следующие 4 взаимосвязанные архитектуры:
- бизнес-архитектуру;
- архитектуру информации;
- технологическую архитектуру (практически соответствует всей ИТ-архитектуре, рассмотренной в версии 2);
- архитектуру решений (Solution Architecture), поэтому структура модели частично изменилась.
Область (Домен) | Дисциплина | Технологическая дисциплина | Продуктовые компоненты | Документы Соответствия |
---|---|---|---|---|
Информация | Управление Данными |
|
|
|
|
|
|||
|
|
|
||
|
|
|