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), поэтому структура модели частично изменилась.