Методика NASCIO Architecture Toolkit

Набор шаблонов IT Architecture Toolkit, разработанный американской ассоциацией CIO, первоначально позиционировался как специализированное средство для документирования ИТ-архитектуры организации. Основное преимущество его использования заключается в построении иерархической системы описаний элементов, удобной для поддержания жизненного цикла документа, т.е. в форме, предполагающей его возможные изменения в будущем по мере изменения требований бизнеса и совершенствования технологий. Однако в версии 3.0, опубликованной в октябре 2004 года, предмет его рассмотрения уже охватывает и область бизнес-архитектуры, так что он может рассматриваться наряду с другими универсальными рамочными моделями. Другим весьма полезным обстоятельством является большое количество реальных примеров из практики отдельных американских штатов и федеральных организаций.

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

· области или домены (Domains) ИТ-архитектуры;

· дисциплины;

· технологические дисциплины;

· продуктовые компоненты;

· документы соответствия.

Области (домены) являются логическими блоками технологической архитектуры. Каждая Область может включать одну и более дисциплин. Вся ИТ-архитектура подразделялась на набор областей верхнего уровня (доменов), описывающих отдельные аспекты ИТ-систем. В составе списка доменов предлагалось выделять такие области, как:

· управление приложениями;

· управление данными;

· управление информацией;

· интеграция;

· управление пользователями и доступ;

· сети и коммуникации;

· платформы;

· управление системами;

· информационная безопасность и т.п.

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

Например, в домен Управление системами входят, в том числе, следующие дисциплины:

· Управление активами (Asset management).

· Управление изменениями (Change management).

· Управление событиями (Event Management).

· Поддержка пользователей (HelpDesk).

· Обеспечение непрерывности бизнеса (Business continuity) и др.

Технологические дисциплины – это технические дисциплины, которые поддерживают функциональные технологические разделы архитектуры. В качестве примера (см. ниже) можно привести Дисциплину "Управление данными" (Data Management), которая является частью Области "Информация". Дисциплина "Управление Данными" может включать в себя такие Технологические Области, как:

· реляционные СУБД;

· плоские файловые системы;

· настольные базы данных;

· модели данных.

Каждая из этих технологических областей включает свои продукты, протоколы и связанные с ними конфигурации. Это детализируется на уровне "Продуктовые компоненты". С указанного уровня начинаются технические детали технологической архитектуры.

Продуктовые компоненты включают протоколы, продукты (семейства продуктов) и конфигурации, которые специфичны для каждой технологической области. Примерами Продуктовых Компонент, которые могут быть идентифицированы в рамках технологической области "Модели Данных", являются такие продукты, как ERWin, Visio и Designer 2000. Документация для каждой компоненты включает оценочные критерии, которые были использованы для включения продуктовой компоненты в общую технологическую архитектуру.

Документы Соответствия определяют руководства, стандарты и регулирующие документы, которые связаны с Дисциплинами, Технологическими дисциплинами и/или Продуктовыми компонентами. Они предписывают необходимость соблюдения тех или иных международных рекомендаций (RFC), стандартов, законодательных актов – например, по применению сертифицированных средств ЭЦП, внутренних инструкций и т.п.

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

Для элементов описания архитектуры в документе определяется следующее:

Таблица 3 – Элементы описания архитектуры

Область (домен)	Описание, область охвата, входящие функциональные области, принципы, лучшие практики, тренды
Дисциплина	Описание, область охвата, ссылка на Домен, кросс-ссылки на другие функциональные области, методологии, Технологические Области, требования к документированию
Технологическая дисциплина	Описание, ссылка на функциональную область, обоснование выбора единственного или множественных продуктов (вендоров, приложений)
Продукты/приложения	Описание, ссылка на Технологическую область, информация о вендоре, классификация, условия использования, политика миграции

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

Пример приведен в табл. 4.

Таблица 4 – Пример иерархии описания архитектуры в соответствии с рекомендациями NASCIO

Область (Домен)	Дисциплина	Технологическая дисциплина	Продуктовые компоненты	Документы Соответствия
Информация	Управление Данными	реляционные СУБД	MS SQL Oracle DB2	стандарты предприятия на именование хранимых процедур
плоские файловые системы		квоты на использование общего дискового пространства
настольные БД	MS Access	стандарты предприятия по защите БД Access
модели Данных	ERWin MS Visio Designer 2000	нормализация данных стандарты предприятия на именования таблиц и атрибутов

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

Таблица 5 – Области и Дисциплины

Область	Дисциплины
Информация	Управление данными (Data Management) Управление Знаниями Геоинформационные системы (GIS) Хранение данных
Приложения	Управление Средствами Разработки Приложений Электронные средства совместной работы
Интеграция	Функциональная интеграция Программное обеспечение промежуточного слоя (связующее ПО)
Доступ	Доступ Branding: например, рекомендации по внешнему виду web-сайта госорганизации Доступность
Сеть	Физическая сеть Управление сетью
Платформа	Платформа: аппаратное обеспечение (серверы, настольные системы, системы хранения) Управление конфигурациями: стандарты на операционные системы, утилиты, конфигурации аппаратного обеспечения
Системное Управление	Управление активами Управление изменениями Управление событиями Управление инцидентами и проблемами Непрерывность бизнеса (Business Continuity)
Частная информация	Профилирование Персонифицирование Обеспечение защиты частной информации
Безопасность	Корпоративная Безопасность Безопасность Безопасность серверов

В версии 3.0 набор включает в себя как процесс управления ИТ (IT Governance), так и следующие 4 взаимосвязанные архитектуры:

· бизнес-архитектуру;

· архитектуру информации;

· технологическую архитектуру (практически соответствует всей ИТ-архитектуре, рассмотренной в версии 2);

· архитектуру решений (Solution Architecture), поэтому структура модели частично изменилась.

В частности, в составе собственно бизнес-архитектуры предлагается выделить несколько бизнес-областей (доменов). Это разделение может производиться как по функциональному (например, образование /здравоохранение /социальное обеспечение), так и по некоторому "тематическому" признаку (например; услуги гражданам/взаимодействие с другими органами власти/внутренние процессы) или географическому признаку. В составе этих бизнес-доменов выделяются отдельные архитектурные компоненты, рассмотрение которых может вестись с различных "перспектив", соответствующих столбцам в модели Захмана и с фокусом на двух верхних уровнях (строках) этой модели. В руководстве указывается на возможную целесообразность объединения таких перспектив, как "Кто?" и "Зачем?", вообще говоря, различных с точки зрения модели Захмана, в одну общую – "Стратегический бизнес". Важно отметить, что одни и те же выбранные перспективы должны будут применяться ко всем бизнес-областям.

Для каждой бизнес-области в описании определяются существенные принципы, лучшие практики и существующие тенденции. Далее, в составе бизнес-области формируются подчиненные документы, описывающие ее компоненты, которые фактически соответствуют отдельным ячейкам в верхних двух уровнях модели Захмана. Таким образом, в состав компонент могут входить, например, описание ролей (должностей) и их ответственности в организации, важные с точки зрения предприятия события и циклы деятельности, расположения офисов и т.п. Важным атрибутом описания является индикация типа состояния компоненты, т.е. относится ли это описание к существующему или целевому состоянию. Здесь прослеживается некая аналогия с подходом группы Зиндера и выделением "стратегического времени", хотя и в ограниченной интерпретации из всего двух состояний.

Специальным типом компоненты являет так называемая Gap-компонента, которая описывает существующие расхождения между текущим и целевым состоянием. Эти компоненты не случайно выделены в отдельный тип, поскольку одна и та же "причина", такая, например, как используемая устаревшая технология доступа к данным, может оказывать влияние на целый ряд основных компонент, в том числе из различных функциональных или тематических бизнес-областей. Описания этих основных компонент и описания gap-компоненты дополняются соответствующими кросс-ссылками, позволяющими осуществлять необходимую навигацию.

Представленный ранее в предыдущей версии руководства в рамках общей ИТ-архитектуры домен "Информация" в новой версии выделен в отдельную архитектуру информации. В ее составе определяются следующие элементы:

· основные информационные сущности (information subject areas), такие как, например, Гражданин/Услуга/Платеж, которые специфичны для деятельности данной организации;

· процессы обработки информации, описывающие, в частности, каким образом, кем и в каком порядке используется, например, сущность "Гражданин";

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

Кроме того, как и в случае бизнес-архитектуры, здесь явно выделяются Gap-компоненты.

Новым понятием, которое требует некоторого комментария, является архитектура решений. В данном контексте под ней понимается "процесс в рамках общей архитектуры предприятия, который фокусируется на создании сервиса или решения в интересах всей организации". Фактически эта область во многом соответствует понятию слоя шаблонов из модели Gartner.

В отличие от остальных архитектур, описания элементов архитектуры решений не содержат такого признака, как "существующий" или "целевой". Фактически, все эти "решения" относятся как раз к стадии перехода от существующего состояния к целевому, так что по завершении соответствующего проекта они сохраняются со статусом "архивный".

Для описания конкретного решения используются три типа шаблонов:

· "обзор" (scope) – определяет область проекта, цели и подход;

· "требования" – содержит формализованные требования к решению, сгруппированные по типу, т.е. бизнес-требования, функциональные, по безопасности и т.п. В этой части организация шаблона схожа с разделом отечественного стандарта ГОСТ 34.698-90 "Техническое задание на АС";

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

Как уже отмечалось выше, наряду с описанием элементов архитектуры, в ходе процесса разработки определяется реализация применительно к конкретным особенностям предприятия стандартных процессов поддержки жизненного цикла архитектуры. К этим процессам относятся, в частности, такие:

· документирование;

· рецензирование;

· информирование;

· изменение;

· проверка соответствия;

· поддержка актуальности;

· организация и управление разработкой архитектуры, включая построение системы "IT Governance".

Диаграммы процессов строятся применительно к набору типовых предопределенных ролей (например, Рецензент, Документатор, Лидер и т.п.), которые присваиваются отдельным сотрудникам, должностям или подразделениям. Эти роли определяют права и ответственность данных участников процесса.

Дата добавления: 2013-12-14